Phase 03 - Application Security and Secure SDLC
Duration: 4 weeks (Month 7)
Objective: turn security from late findings into repeatable product and delivery controls.
Deep guides: WARMUP.md models product security as a lifecycle control system; HITCHHIKERS-GUIDE.md hardens CI runners, build identity, artifacts, exceptions, and emergency releases.
Theory and Objectives
- Secure discovery, security requirements, misuse/abuse cases, DFDs, trust boundaries, STRIDE, attack trees, privacy review, and architecture decision records.
- Manual code review and the strengths/limits of SAST, DAST, IAST, SCA, secret, container, IaC, and API scanning.
- SBOMs, dependency graphs, provenance, SLSA concepts, Sigstore, artifact signing, hermetic builds, release separation of duties, and rollback.
- Vulnerability intake, deduplication, reachability, exploitability, asset criticality, compensating controls, SLAs, exceptions, retest, and metrics.
- Secure defaults, paved roads, developer enablement, executive communication, and risk acceptance.
Labs
Use the Phase 02 application as the product under review.
| Lab | Deliverable |
|---|---|
| 03.1 Threat model | context/DFD diagrams, assets, actors, trust boundaries, 20 abuse cases, prioritized mitigations |
| 03.2 Design review | architecture questions, assumptions, findings, ADRs, residual-risk register |
| 03.3 Product checklist | short stage-specific checklist with owner and verification method |
| 03.4 Security CI | lint/tests plus SAST, SCA, secret, IaC, container, and DAST stages |
| 03.5 Triage tuning | seeded findings, true/false-positive decisions, suppressions with expiry |
| 03.6 SBOM/provenance | CycloneDX or SPDX SBOM, signed artifact, verification and tamper test |
| 03.7 Vulnerability workflow | intake-to-closure states, severity rubric, SLA, exception and retest |
| 03.8 Developer training | 20-minute lesson using one real lab root cause and fixed code |
| 03.9 Executive memo | one-page risk, options, recommendation, investment, owner, success metric |
| 03.10 Release review | evidence-based release gate with documented emergency exception path |
Runnable lab portfolio
The labs test release policy, threat quality, exception expiry, SBOM/provenance/signature evidence, and artifact/source/builder tampering.
Capstone - Secure SDLC for Aegis Transit Cloud
Deliver:
- product security charter and engagement model;
- threat model and secure design review;
- working CI security pipeline with version-pinned tools and test fixtures;
- SBOM, provenance, signing, and verification;
- vulnerability workflow and prioritized remediation backlog;
- secure coding guidance and developer workshop;
- executive dashboard showing coverage, aging, recurrence, and control health;
- release checklist, exception process, and 90-day adoption roadmap.
The pipeline must fail on deliberately seeded critical cases and stay green on approved fixtures. Scanner output by itself is not a capstone.
Tools
Semgrep/CodeQL-style SAST, OWASP ZAP, dependency and secret scanners, Trivy, Checkov, Syft, CycloneDX/SPDX, Cosign/Sigstore, OPA/Conftest, CI platform of choice, issue tracker.
Recommended Sources
OWASP SAMM and ASVS, NIST SSDF, SLSA specification, Sigstore documentation, OpenSSF Scorecard, CycloneDX/SPDX specifications, Threat Modeling: Designing for Security, and selected supply-chain incident postmortems.
Measures
- 100% critical components have an owner, DFD, data classification, and release evidence.
- CI detects all seeded test cases; false-positive exceptions have owner and expiry.
- Median critical-finding triage under one business day in simulation.
- Recurrence tests exist for every accepted critical/high finding.
- Executive metrics report business exposure and control health, not raw scanner totals.
Evaluation Checklist
- Threats connect assets, actors, boundaries, preconditions, and mitigations.
- Review separates design issues from implementation defects.
- CI permissions, tokens, runners, caches, dependencies, and artifacts are threat-modeled.
- Emergency release and risk-acceptance paths are usable and auditable.
- Developer guidance gives precise fixes and verification.
- Executive memo presents options and a decision, not technical noise.
Common Mistakes and Interview Questions
Mistakes: checklist-only threat modeling, blocking builds on untuned tools, vulnerability-count vanity metrics, permanent suppressions, unsigned-but-unverified artifacts, and a central security team that becomes the delivery bottleneck.
Questions:
- Threat-model a multi-tenant SaaS export feature.
- Which security checks belong pre-commit, CI, deployment, and runtime?
- How do you prioritize 10,000 dependency findings?
- Design a defensible exception process.
- How would you persuade a product VP to fund a platform-level fix?
Portfolio and Stretch
Publish sanitized diagrams, CI fixtures, an example signed release, scorecard, and developer workshop. Stretch: build a custom policy pack, implement reproducible builds, measure scanner precision/recall on a labeled corpus, or run a cross-team threat-model workshop.