5.4Secure OS, database, and application security

For an application security engineer or architect, "not introducing a vulnerability" and "detecting a vulnerability that was introduced" are two wheels of the same cart. The core of this section is judging which technique or testing method belongs at which stage of the development lifecycle. From OS-level access control through database and application-layer implementation measures and testing methods, this section organizes what each defensive layer can and cannot protect against.

5.4.1Secure OS (MAC, RBAC, least privilege)

• Mandatory Access Control (MAC) enforces access uniformly according to a policy set in advance by an administrator, based on security labels (classification level, etc.) attached to files and processes. The decisive difference from Discretionary Access Control (DAC, where the owner can set access rights at their own discretion) is that the file owner cannot change access rights at their own judgment. This is a core feature of a trusted OS: even malware or unauthorized operations cannot override the policy through owner privileges alone.
• RBAC (Role-Based Access Control) assigns permissions to roles rather than to individual users, and manages access by placing users into roles. When someone changes department or leaves, only their role assignment needs updating, giving greater operational consistency and auditability than configuring permissions individually for each person.
• The principle of least privilege grants users and processes only the minimum privilege necessary for their task. Even if an attacker takes over an account or process, the damage is confined to that privilege. A trusted OS is an OS with security features such as MAC built into the OS itself, evaluated and certified by an independent third party (e.g., Common Criteria).

5.4.2DB security, security by design, and threat modeling

• Database encryption encrypts data stored in the database, preventing raw data from being read directly if storage is stolen or accessed without authorization. However, a session that connects to the DB through legitimate authentication sees the decrypted data, so DB encryption alone cannot prevent information leakage via insider misuse or SQL injection—it must be combined with DB access control (permissions set per user/application, granting only the minimum necessary tables/columns).
• Security by design builds security requirements in from the planning/design stage of development (from the start, not bolted on afterward). Privacy by design similarly builds in personal-data-protection requirements from the design stage (collect only the minimum necessary, default to the most privacy-protective settings, etc.). Threat modeling systematically identifies threats to a system at the design stage (e.g., by analyzing data-flow diagrams) and prioritizes countermeasures. The earlier threats are identified, the lower the cost of rework.

5.4.3Secure programming and vulnerability detection (SAST/DAST/IAST/SCA)

• SAST (Static Application Security Testing) performs static analysis without executing source code or binaries, detecting vulnerable code patterns. It can be applied early in development (e.g., at commit time), keeping fix costs low, but tends to miss vulnerabilities arising from runtime behavior (misconfiguration, environment-dependent issues).
• DAST (Dynamic Application Security Testing) detects vulnerabilities by sending attack-like input from outside while actually running the application. It can catch issues stemming from the runtime environment or configuration, but it is harder to pinpoint the exact source-code location, and since it must exercise the target functionality comprehensively, it tends to happen later in the pipeline.
• IAST (Interactive Application Security Testing) embeds an agent inside the running application to observe internal execution paths while it runs, combining the advantages of SAST and DAST (seeing runtime behavior while still being able to pinpoint the corresponding code location). SCA (Software Composition Analysis) inventories known vulnerabilities (CVEs, etc.) in the open-source libraries and dependent components an application uses, addressing vulnerabilities in incorporated parts rather than in code the organization wrote itself.

Suppose a security lead on an application development team is planning vulnerability countermeasures for a new e-commerce site. At the design stage, they diagram the data flow including payment processing and perform threat modeling, identifying threats such as "an attacker sends malformed parameters to the payment API" or "customer personal data is left in logs in plaintext," and prioritize countermeasures before implementation begins. During implementation, SAST runs in the CI pipeline on every commit, catching places where SQL statements are built via string concatenation instead of placeholders (a classic SQL-injection-inducing pattern) early, while fix costs are still low. During testing, DAST runs against the staging environment while the application is actually operating, sending real payloads to confirm from an external viewpoint XSS (unescaped input reflected into the page) or runtime flaws around authentication. Additionally, for the open-source components used as the payment library, SCA inventories known CVEs and updates any vulnerable versions to the latest. For password storage, hashing alone is vulnerable to a rainbow-table attack, so a per-user salt is appended to make each hash value unique, and stretching—deliberately repeating the hash computation—raises the cost of a brute-force attack. Finally, on the front end, the team relies on the Same Origin Policy to prevent the payment API from being called by external scripts on a different origin, and configures CORS to explicitly allow only legitimate partner domains via an allowlist. Responding across the entire vulnerability lifecycle—from upstream threat modeling through implementation measures, multiple testing methods, and password-protection techniques—in layers is the practice of application security.

5.4.4Section summary

• MAC enforces uniform administrator policy that the owner cannot change (contrast with DAC); RBAC manages by role; least privilege grants only the minimum necessary
• DB encryption guards against stolen-data reads and must pair with DB access control. Threat modeling identifies threats at the design stage to lower rework cost
• SAST is early static analysis, DAST is runtime external testing, IAST combines both advantages, SCA inventories known OSS-dependency vulnerabilities. Salting and stretching serve different purposes and are best used together