Helpful first: Application trust boundaries: why the client UI is never a security gate · Threat modeling a service: data flows, trust boundaries, and STRIDE
Key points
- Compare security integration across Waterfall, Agile, Spiral, DevSecOps, and the five CMMI maturity levels.
- Enforce database ACID transaction properties, distinguish Aggregation from Inference attacks, and explain Polyinstantiation.
- Remediate SQL Injection, Cross-Site Scripting (XSS), CSRF, SSRF, Buffer Overflows, and Time-of-Check to Time-of-Use (TOCTOU) race conditions at their root architectural boundaries.
SDLC models and CMMI capability maturity
Fixing a security defect during requirements or architecture costs orders of magnitude less than patching it after production release. Regardless of whether an organization follows Waterfall (linear sequential phases with formal gates), Spiral (iterative risk-driven prototypes invented by Barry Boehm), Agile (short sprints with security user stories), or DevSecOps (automated CI/CD guardrails), security activities must map to every phase: threat modeling in design, secure coding and SAST in implementation, DAST and fuzzing in verification, and configuration hardening in deployment.
The Capability Maturity Model Integration (CMMI) measures process maturity across five levels: Level 1 Initial (unpredictable, ad hoc heroics), Level 2 Managed (project-level repeatable tracking), Level 3 Defined (proactive organization-wide standard processes), Level 4 Quantitatively Managed (statistical measurement and quantitative quality control), and Level 5 Optimizing (continuous defect prevention and process innovation).
Database security: ACID, Inference, Aggregation, and Polyinstantiation
Relational databases rely on referential integrity (every foreign key must match an existing primary key or be null) and ACID transactions: Atomicity (all operations in a transaction succeed or the entire transaction rolls back), Consistency (constraints and rules are preserved before and after the transaction), Isolation (concurrent transactions execute as if serialized without leaking intermediate state), and Durability (committed transactions are written to non-volatile logs so they survive crashes).
In multi-level secure databases, two subtle information leaks occur even when row-level permissions are enforced. Aggregation occurs when a user collects many low-sensitivity records that, combined, exceed the classification of the individual records. Inference occurs when a user logically deduces a restricted high-classification fact from available low-classification responses. Polyinstantiation counters inference channels by permitting multiple rows to share the same primary key at different classification levels, so a lower-cleared user inserting a conflicting key does not receive an error revealing that a secret record already exists.
| Vulnerability Class | Root Cause | Primary Architectural Remediation |
|---|---|---|
| SQL / Command Injection | Untrusted input concatenated into interpreter command string | Parameterized queries (prepared statements) and strict APIs |
| Cross-Site Scripting (XSS) | Untrusted data rendered in browser DOM without escaping | Context-aware output encoding and Content Security Policy (CSP) |
| Cross-Site Request Forgery (CSRF) | Browser automatically attaches ambient session cookies to cross-origin state-changing requests | Anti-CSRF cryptographic tokens and SameSite cookie attributes |
| TOCTOU Race Condition | State changes between separate authorization check and resource use steps | Atomic check-and-use operations and mutex/transactional row locks |
| Buffer Overflow | Writing past allocated memory bounds to overwrite adjacent stack/heap pointers | Memory-safe languages, bounds checking, ASLR, and DEP/NX bits |
Remediating injection, memory corruption, and race conditions
Injection vulnerabilities arise whenever untrusted data is concatenated into a command or query parser. Parameterized queries (prepared statements) solve SQL injection structurally: the database compiles the SQL syntax tree first and binds user parameters strictly as scalar values, making it impossible for input characters like single quotes or semicolons to alter query logic.
Time-of-Check to Time-of-Use (TOCTOU) is a race condition in which a system checks a security precondition (such as verifying account balance or file ownership) at time T1 and uses the resource at time T2, allowing an attacker to swap the file symlink or issue a concurrent request in the window between T1 and T2. Eliminating TOCTOU requires making the check and the action a single atomic operation protected by an exclusive lock or serializable database transaction.
CHECK YOUR JUDGMENT