DevSecOps & Secure SDLC

Instead of a security guard checking your work right before it ships, put a security checkpoint at every step of building it.

At a glance

• What it is: embedding automated security checks (static analysis, dependency scanning, secrets scanning, dynamic testing) directly into the CI/CD pipeline, so vulnerabilities are caught while code is being written, not after release.
• Why it matters: a vulnerability caught in a code review or CI gate costs minutes to fix; the same vulnerability found in production after an incident costs far more — in time, trust, and sometimes real damage.
• For developers: a failed security scan on your pull request is the same kind of gate as a failed test — treat it as something to fix before merging, not something to override.
• When to use it: for every codebase with a CI/CD pipeline — the scans should run on every pull request, not just before major releases.
• When not to use it: a throwaway prototype with no path to production has less urgency, but anything expected to ship should have these gates from day one.
• Prerequisites: Threat Modeling & Risk Assessment to help decide which scan findings are actually worth blocking a merge over.

Mental model

flowchart LR
    C[Code committed] --> S[SAST: static code scan]
    C --> D[Dependency / SCA scan]
    C --> SEC[Secrets scan]
    S --> G{All checks pass?}
    D --> G
    SEC --> G
    G -- No --> B[Block merge, report finding]
    G -- Yes --> M[Merge allowed]
    M --> DAST[DAST: dynamic scan in staging]

Step-by-step walkthrough

1. Add static application security testing (SAST) to the pipeline, scanning code for common vulnerability patterns on every pull request.
2. Add software composition analysis (SCA)/dependency scanning to catch known-vulnerable (CVE) third-party libraries before they merge.
3. Add secrets scanning so credentials or keys accidentally committed are caught before they reach a shared branch.
4. Run dynamic application security testing (DAST) against a staging environment to catch issues static analysis can’t see (e.g. runtime misconfigurations).
5. Set clear severity thresholds for what blocks a merge versus what’s logged for later triage — not every finding needs to halt shipping.

Worked example

A known-CVE version of a logging library reaches the checkout service in production because nothing in the pipeline scanned dependencies before merge — the same class of gap the team’s threat-modeling session (see Threat Modeling & Risk Assessment) had flagged as a likely, high-impact risk.

• Input: a pull request that adds a new dependency with a publicly known, high-severity vulnerability, merged with no automated check catching it.
• Process: the team adds a dependency/SCA scanning gate to CI that blocks merges introducing dependencies above a defined severity threshold, and backfills a scan of existing dependencies to catch what’s already in production.
• Output: the vulnerable library is patched before the next release, and any future pull request introducing a similarly severe known vulnerability is blocked automatically instead of relying on someone noticing. On Azure DevOps/GitHub, this is GitHub Advanced Security (or Microsoft Defender for DevOps) enabled as a required check — CodeQL for SAST, Dependabot/SCA for known-CVE dependencies, and secret scanning, all gating the pull request before merge.

Common use cases

Use case	When to use	Notes
Adding a new third-party dependency	On every pull request	Run SCA/dependency scanning as a required CI check
Writing new application code	On every pull request	Run SAST to catch common vulnerability patterns before review
Accidentally committing a credential	Immediately, before merge	Secrets scanning should block the merge and flag the credential for rotation
Testing a deployed staging environment	Before promoting to production	Run DAST to catch runtime issues static analysis can’t detect

Advanced details

• SAST vs. DAST: SAST analyzes source code without running it; DAST tests a running application from the outside — the two catch different classes of issues and are complementary, not interchangeable.
• SCA (software composition analysis): identifies known-vulnerable versions of third-party dependencies, often the single highest-value scan to add first given how much of an application is typically third-party code.
• Severity-based gating: blocking every finding regardless of severity trains teams to route around the gate; blocking only above a defined threshold keeps the gate credible and enforced.
• OWASP Top 10 names what these scans are actually looking for: the current OWASP Top 10:2025 gives each scan type a concrete target instead of a vague “vulnerabilities” — SCA maps directly to A03:2025 Software Supply Chain Failures (the exact class of gap in the worked example above), SAST commonly catches patterns behind A05:2025 Injection, and DAST is well-suited to runtime issues like A02:2025 Security Misconfiguration that static analysis can’t see.

Quick reference

Term	Meaning
SAST	Static Application Security Testing — scans source code without running it
DAST	Dynamic Application Security Testing — tests a running application from the outside
SCA	Software Composition Analysis — finds known-vulnerable third-party dependencies
Secrets scanning	Detecting credentials/keys accidentally committed to source control
Severity threshold	The finding severity level above which a merge is blocked
OWASP Top 10	The standard awareness list of the most critical web application security risks (current version: 2025)

Troubleshooting

Symptom	Likely cause	Fix
A known-vulnerable dependency reaches production	No SCA/dependency scanning gate in CI	Add a dependency scan that blocks merges above a defined severity
Developers routinely override or ignore scan findings	Every finding blocks the merge regardless of severity, causing gate fatigue	Gate only on findings above an agreed severity threshold; log the rest for triage
A committed credential isn’t caught until much later	No secrets scanning in the pipeline	Add secrets scanning as a required, blocking CI check

Check your understanding

• Why is scanning dependencies (SCA) often the highest-value first scan to add to a pipeline?
• Why might blocking a merge on every single scan finding, regardless of severity, backfire?

Related pages

Part of Introduction to Security Architecture. See also Threat Modeling & Risk Assessment, Security by Design (Application-Level), Incident Response & Security Operations, and the Glossary.