Official intent
Integrate security early in the development lifecycle so weaknesses are caught in the pipeline, not in production. The official source remains authoritative.
Read the official campaign ↗Security bolted on at the end is expensive and leaky. Building it in — threat modeling, secure coding standards, automated testing in the pipeline, dependency and secret scanning, and reviewed changes — catches weaknesses when they are cheap to fix. This applies whether you ship software products or just maintain scripts, pipelines, and cloud infrastructure-as-code.
Who this applies to: Applies well beyond software product companies. If you maintain scripts, pipelines, or infrastructure-as-code, this practice applies to you — usually in the lighter form described in the small-business path.
Why it matters
A flaw found in design costs a fraction of the same flaw found in production after a breach. Wiring security checks into the development and deployment pipeline makes the secure path the default path, reduces the vulnerabilities you ship, and gives you evidence that changes were tested and reviewed.
Risks this reduces
- Vulnerabilities shipped into production that were cheap to fix in design
- Secrets committed to source control and reachable long after rotation
- Vulnerable third-party dependencies pulled in without review
- Unreviewed infrastructure-as-code changes that weaken the environment silently
Who owns it
Engineering lead
Developers, Security lead, DevOps/platform
Medium
Medium
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: IT-02 — Asset inventory
- Source control with enforceable branch protection
- A build pipeline that can fail a build
- A secrets store that developers will actually use
Action timeline
- Confirm no secrets are committed in source control
- Verify changes require peer review before merge
- Turn on secret scanning across every repository and rotate anything it finds
- Require peer review before merge on the repositories that touch production
- Add dependency (SCA) and secret scanning to the pipeline
- Adopt a secure-coding standard for your primary language/stack
- Add static analysis (SAST) and fail the build on critical findings
- Threat-model your most sensitive application or pipeline
- Track findings to closure with owners and dates
- Verify build integrity (pinned dependencies, signed artifacts)
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Require peer review for code and infrastructure-as-code changes, and keep secrets in a vault, not in repos.
- Add automated checks to the pipeline: static analysis, dependency/SCA scanning, and secret scanning.
- Adopt a secure-coding standard and threat-model the most sensitive components.
- Fail builds on critical findings so insecure changes cannot ship silently.
- Track findings to closure and feed recurring issues back into standards and training.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
Changes ship without review, and nobody knows whether secrets are in the repositories.
Is there anything at all — a tool, a document, a person who owns it? - Documented
A secure development standard exists and names the required checks and review rules.
Is the intent written down, with a named owner and a scope? - Configured
Static analysis, dependency, and secret scanning are configured in the pipeline for at least one repository.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
The gates run across every repository that reaches production, and critical findings block the build.
Does it cover everything in scope, with the exceptions written down? - Measured
Findings by severity, time to closure, and blocked-build counts are tracked, and recurring issues feed the standard.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
The standard is owned and reviewed, threat modeling is scheduled for sensitive components, and build integrity is verifiable.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- Attempt to commit a test secret — the pipeline should detect and block it.
- Confirm a build with a known-critical dependency vulnerability fails as configured.
- Review recent merges to verify each had a reviewer and passed the security gates.
Evidence to retain
Secure development standard and change-review policy
Pipeline configuration showing SAST/SCA/secret-scanning gates
Findings backlog with owners and closure dates
Records of blocked builds and merge reviews
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Pipeline gate coverage | Production-bound repositories with SAST, dependency, and secret scanning enabled ÷ all such repositories. | 100%. |
| Secrets in source control | Live credentials detected in repositories or history. | Zero; every historical finding rotated. |
| Critical findings past window | Critical pipeline findings open beyond the agreed remediation window. | Zero. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
Security scanning that runs but never blocks, secrets committed to repos and only rotated after a leak, and threat modeling done once for a slide and never again. A gate that always lets the build through is not a gate.
Two sized paths
If you have a handful of repositories, three settings cover most of the value: require a reviewer before merge, turn on the secret scanning your source-control platform already offers, and enable dependency alerts. Put credentials in a secrets manager rather than a config file. That is a day of work, not a programme.
Make gates enforcing rather than advisory, add threat modeling for sensitive components, verify build integrity with pinned dependencies and signed artifacts, and route findings into the same backlog and ownership model as the rest of the vulnerability programme.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
Turning gates from advisory to blocking will stop builds on day one. Run them in report-only mode long enough to clear the existing backlog, agree the blocking threshold with engineering, then enforce — and keep a documented break-glass path for genuine emergencies.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The SSDF practices for reviewing code, testing executable code, and identifying vulnerabilities describe this practice directly.
What this does not claim: The SSDF is guidance for software producers. Applicability depends on your contracts; it is not automatically imposed.
Why: The same reasoning carries to the inherited CMMC practice for change tracking and review.
What this does not claim: Supports the requirement; it does not satisfy it on its own and does not establish an assessment outcome. Scope, implementation quality, and evidence decide that.
Why: The application software security control covers secure development processes and vetting third-party components.
What this does not claim: CIS is a voluntary benchmark. Alignment with it carries no contractual weight.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.4.3Change tracking and approvalPartial implementation supportModerate
Why: Merge review and pipeline gates are change tracking, review, approval, and logging operationalized for code and infrastructure-as-code: every change carries an author, a reviewer, a decision, and an immutable record.
What this does not claim: 800-171 contains no secure-development requirement, so this is a reasoned relationship applied to one class of change. Systems changed outside the pipeline — network gear, hand-managed servers, SaaS configuration — are exactly where this practice's records stop, and the requirement does not.
Review status: Technical review complete.
Open the 3.4.3 page →3.4.4Security impact analysisPartial implementation supportModerate
Why: Pre-merge security scanning and review examine a change's security consequences before it ships — impact analysis performed where it is cheapest, in the pipeline rather than in production.
What this does not claim: Automated scanners assess the code in front of them, not the architectural consequences of a change — a new external integration can pass every gate while altering the boundary. The analysis also covers only changes that flow through the pipeline; infrastructure and configuration changes made elsewhere need their own impact review.
Review status: Pending NIST SME review.
Open the 3.4.4 page →NIST SP 800-171 Rev. 3
03.16.01Security Engineering PrinciplesPartial implementation supportModerate
Why: Integrating security early in the development lifecycle is the application of engineering principles where the organization builds: threat modeling before design freeze, secure defaults in templates, testing gates in the pipeline. For the developed portion of the system, the practice works the requirement's substance.
What this does not claim: May partially address the requirement, whose scope is the whole system — network architecture, commercial product selection and configuration, integrations — not only the software the organization writes. An organization with a strong pipeline and an unexamined architecture has implemented the pipeline slice of this requirement and no more.
Review status: Pending NIST SME review.
Open the 03.16.01 page →Review status
| Technical review | Reviewed |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.0 |