Search every question across sub-FAQs

Use code scanning when your secure development process calls for code analysis, code review, or executable testing to find issues before release. NIST SP 800-218 recommends deciding whether review and analysis should be used, and it also recommends testing executable code to find vulnerabilities not identified earlier.

Tie the decision to the organization's secure coding standards, software stage, technology, threat model, and security-check criteria. Static analysis is one PW.7.2 example; PW.8 examples also include dynamic testing, fuzz testing, functional security testing, and penetration testing for high-risk scenarios when resources permit.

If scanning or testing is selected, define the covered repositories, branches, components, builds, and releases. Record tool and ruleset versions, relevant configuration, exclusions, results, triage, recommended remediations, fixes, retests, and approved risk responses in the team's workflow or issue tracker.

A reviewer should be able to tell what was scanned or tested, which criteria and configuration applied, what the tool could not cover, who triaged the output, how each material issue was handled, and whether the affected release was approved.

Include a software library, module, middleware, framework, service, reusable in-house module, or other dependency when it is part of the covered software or its operation and falls under the organization's component requirements. Distinguish shipped components from build-only dependencies and hosted or platform services, then document who performs each applicable SSDF task under the delivery model.

For each governed component, record its source and supplier, exact version or other identifier, expected use, applicable requirements, integrity and provenance information, evaluation result, secure configuration, approval or exception, maintenance status, known-vulnerability status, and the releases that use it. An SBOM can carry part of this inventory and provenance, but it does not replace evaluation, approval, or vulnerability response.

Re-evaluate a component when its expected use changes materially. Continue checking whether it is maintained, whether known vulnerabilities remain unaddressed, and whether integrity can still be confirmed. Record an update, replacement, mitigation, or other risk response for unsupported or vulnerable components.

Evidence should let a reviewer trace the component from source and approval to each affected release and later vulnerability decision. Keep supplier representations and inherited platform or service evidence separate from work performed by the software producer.

For a component that cannot meet a requirement, record the gap, affected software, decision authority, chosen risk response, compensating action, owner, and reassessment trigger. SSDF does not make every component defect an automatic release block; the organization's documented criteria and risk decision control.

A release gate should answer a defined decision: whether this identified release meets the organization's documented security-check criteria or has an authorized risk response for each unmet criterion. The evidence depends on the software and may include design-review findings, component decisions, code review or analysis, executable testing, build configuration, unresolved vulnerabilities, integrity-verification information, provenance, and required archives.

PO.4.1 recommends tracking criteria throughout the SDLC and recording approvals, rejections, and exception requests in the workflow. PO.4.2 recommends gathering and safeguarding the information used for those decisions. A gate can be automated, manual, or mixed; the organization should periodically review automated decision logic.

When criteria are not met, record the unresolved finding, affected release, decision authority, risk response, temporary or compensating action, owner, and expiry or reassessment trigger. A passed gate means the organization's stated decision criteria were met or excepted. It does not prove that the software is vulnerability-free or certify compliance with SSDF.

Test the gate against one planned release and one failed criterion. The workflow should identify the exact artifact, applicable checks, current evidence, decision authority, outcome, exception path, and post-release obligations without relying on an undocumented judgment.

Define the software and release scope, assets and sensitive data, operating assumptions, trust boundaries, external dependencies, entry points, threat actors or abuse cases relevant to the product, and the risk criteria used. Apply more rigorous assessment to higher-risk areas when the organization's analysis calls for it.

Convert material findings into security requirements, design changes, tests, monitoring, or another documented risk response. Record the rationale for mitigations and approved exceptions. PW.2.1 recommends review by a qualified person not involved in the design and/or by automated processes in the toolchain.

Review the model when architecture, data flows, dependencies, deployment conditions, security requirements, threat information, or material vulnerabilities change. A calendar can support that process, but SP 800-218 does not set a universal review interval.

The evidence should show the model's scope and assumptions, identified risks, security requirements, chosen responses, design-review findings, owners, exceptions, and update history. A diagram without decisions or follow-through is incomplete evidence.

Publish or otherwise provide a reporting path, preserve the submission, acknowledge it under the organization's policy, and investigate credible reports. Correlate the report with internal testing and public or supplier information, then identify affected products, supported releases, versions, and third-party components.

Analyze each confirmed vulnerability far enough to plan a risk response. Record exploitability, potential impact, relevant deployment conditions, available mitigation, and other criteria used by the organization. Decide whether to remediate, temporarily mitigate, accept, transfer, or otherwise address the risk, and prioritize the work.

When acquirers need to act, provide useful information such as the affected software, how to identify it, available patches or other remediations, configuration changes, and temporary workarounds. Deliver remediations through a trusted mechanism. Then record root cause, look for similar vulnerabilities, and update the SDLC when appropriate.

RV.1.3 recommends a vulnerability-disclosure and remediation policy plus supporting roles, responsibilities, and processes. It does not set a universal acknowledgment, remediation, publication, or embargo deadline; contracts, laws, sector rules, and coordinated-disclosure arrangements may add separate obligations.

The evidence should let a reviewer follow each report from receipt to closure without exposing sensitive reporter or vulnerability information unnecessarily. Keep the credibility decision, affected scope, risk analysis, response, remediation verification, communication, root-cause work, and final status connected.

For the build process, retain the approved compiler, interpreter, and build-tool versions and configuration; evidence that the approved configuration ran; relevant access, change, and integrity records for the build environment and toolchain; and the identifier of the source and dependencies used. PW.6.2 gives a dedicated, highly controlled build environment as a notional example, not a universal implementation requirement.

For the distributed release, retain the release identifier and files, integrity-verification information made available to acquirers, and the protected archive required by organizational policy. PS.2.1 gives cryptographic hashes and code signing as examples. The organization chooses the mechanism and should protect the selected signing or hash-publication process.

Component provenance, including an SBOM, supports origin and affected-release analysis under PS.3.2. It does not by itself show that an approved build ran or that the final artifact was not altered. Reproducible builds and build attestations may add assurance, but SP 800-218 lists reproducible builds only as a notional toolchain example and does not require a specific attestation scheme.

Select a released artifact and trace it backward. The record should identify the distributed file, its integrity-verification information, the build run and approved configuration, the source and components, the decision that allowed release, and the protected archive.

Start with the organization's requirements and the practices appropriate to the development languages and environment. PW.5.1 covers creating source code with those practices. PW.7 covers human-readable code review or analysis, and PW.8 covers executable-code testing when the organization determines those activities are needed.

Keep the records that demonstrate those decisions and results: the applicable coding standard or checklist; the covered repository, component, commit, build, or release; reviewer or tool identity and configuration; findings and recommended remediations; triage status; fixes and retest results; and the rationale and approver for any accepted exception. Training records can support PO.2.2 when role-based training is part of the implementation, but training alone does not show that a release followed secure coding practices.

PO.3.3 recommends configuring tools to generate artifacts defined by the organization. The evidence may be a pull-request record, issue, scan result, test report, signed workflow event, or another protected record. It should be traceable to the software decision it supports rather than collected as an unlinked screenshot.

Review one covered change or release from requirement to outcome. A reviewer should be able to identify the applicable rule, see the review or test that ran, follow every material finding to its disposition, and tell which unresolved risks were accepted for that release.

Release-specific provenance helps an acquirer check component origin and helps operations and response teams determine whether a new component vulnerability affects a deployed release. Update the record whenever a release component changes, protect it from unauthorized alteration, and give recipients a way to verify its integrity.

An SBOM can list release components and related identifiers, but useful provenance also depends on enough source, supplier, version, and change information to identify the component and affected releases. The organization sets the format, access, sharing, and retention policy; SSDF Version 1.1 does not mandate one SBOM standard.

If the assurance question concerns how the final artifact was built, link separate build-run or build-process evidence to the release. Component provenance alone does not prove that an approved build ran, that the artifact was not altered, that the release was approved, or that the producer implemented the wider SSDF.