Use this to evaluate where security already lives in your development process, and where the gaps actually are.
Security decisions made during design are far cheaper to implement than security fixes made after code is written and shipped. Threat modeling before code exists lets your team think through what could go wrong architecturally, before those decisions are locked in by implementation.
Security requirements should be defined alongside functional requirements from the start, not bolted on as a separate, later concern, and any data your system will handle should be classified by sensitivity early, since that classification drives a lot of downstream decisions.
Code review that includes a genuine security lens — not just style and logic — catches a different category of issue than functional review alone. Static analysis integrated directly into the development workflow catches classes of bugs automatically, without depending on a reviewer noticing manually.
Dependency scanning deserves particular attention, since a huge share of real-world vulnerabilities come through third-party libraries rather than code your own team wrote.
Security checks need to run automatically in CI/CD, not as a manual gate someone has to remember to trigger — manual steps get skipped under deadline pressure, automated ones don't.
Secrets management is a common gap even in otherwise mature pipelines — hardcoded credentials in source code or configuration files remain a surprisingly common finding. And every deployment needs a rollback plan in case a security issue surfaces post-deployment; discovering the problem is only useful if you can act on it quickly.
No — most teams add these checks incrementally into an existing pipeline rather than rebuilding it from scratch. Start with the highest-leverage gap, usually dependency scanning or basic static analysis, and build from there.
Design-phase threat modeling tends to have the highest leverage, since issues caught there are the cheapest to fix. But if your codebase already exists, build-phase code review and scanning often surface the most immediately actionable findings.