Create new roles and alter responsibilities for existing roles as needed to encompass all parts of the SDLC.Periodically review and maintain the defined roles and responsibilities, updating them as needed.

Designate a group of individuals as the code owners for each project, and review the list annually.

Specify which tools or tool types must or should be included in each toolchain to mitigate identified risks, as well as how the toolchain components are to be integrated with each other.

Use software factories and/or software templates to standardize the toolchain.

Can scaffold projects with pipelines-as-code and toolchains-as-code

Implements the In-toto framework using pipelines-as-code

CDEvents is a common specification for Continuous Delivery events, enabling interoperability in the complete software production ecosystem.

Follow recommended security practices to deploy, operate, and maintain tools and toolchains.

Use code-based configuration for toolchains (e.g., pipelines-as-code, toolchains-as-code).

Follow recommended security practices to deploy, operate, and maintain tools and toolchains.

Implement the technologies and processes needed for reproducible builds.

• pylock.toml

  (preferred, newest standard)

• uv

  (uses pylock.toml)

• conda

  (reproducible but less standard than pylock-toml)

• pip freeze to requirements.txt

  (not fully reproducible)

• npm package-lock.json

  created in the coding phase, combined with npm ci in the build phase

• yarn yarn.lock

• Maven
• Gradle

• NuGet lockfiles
• DotNet.ReproducibleBuilds

• Bazel

• Cargo

• Golang

Configure tools to generate artifacts of their support of secure software development practices as defined by the organization.

Use existing tooling (e.g., workflow tracking, issue tracking, value stream mapping) to create an audit trail of the secure development-related actions that are performed for continuous improvement purposes. Record security check approvals, rejections, and exception requests as part of the workflow and tracking system.

Define criteria for software security checks and track throughout the SDLC.

Add software security criteria to existing checks (e.g., the Definition of Done in agile SDLC methodologies).

Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria.

Collect audit logs for code repositories.

• Audit Logs

Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria.

Only allow authorized personnel to access the gathered information, and prevent any alteration or deletion of the information. Carefully manage the list of repository owners and organization owners who have the ability to view audit logs, delete organizations, and delete code repositories, and review the list annually.

• Roles in an Organization
• Github Repository Roles

• Roles and Permissions

Separate and protect each environment involved in software development.

Require multifactor authentication, SSH keys, signed commits, and code change approvals for code repositories at the organization level.

• requiring multifactor authentication
• requiring signed commits
• requiring code change approvals and protecting the main branch

• requiring multifactor authentication
• requiring signed commits via push rules
• requiring code change approvals by protecting the main branch

Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.

Store all source code and configuration-as-code in a code repository, and restrict access to it based on the nature of the code. For example, open source code intended for public access may need its integrity and availability protected; other code may also need its confidentiality protected.

Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.

Use version control features of the repository to track all changes made to the code with accountability to the individual account.

Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.

Use commit signing for code repositories to sign code.

Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.

Have the code owner review and approve all changes made to the code by others.

Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.

Use cryptography (e.g., cryptographic hashes) to help protect file integrity

Make software integrity verification information available to software acquirers.

Post cryptographic hashes for release files on a well-secured website.

Make software integrity verification information available to software acquirers.

Use an established certificate authority for code signing so that consumers’ operating systems or other tools and services can confirm the validity of signatures before use. Periodically review the code signing processes, including certificate renewal, rotation, revocation, and protection.

Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.

Store the release files, associated images, etc. in repositories following the organization’s established policy. Allow read-only access to them by necessary personnel and no access by anyone else.

Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.

Store and protect release integrity verification information and provenance data, such as by keeping it in a separate location from the release files or by signing the data.

Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a Software Bill of Materials (SBOM)).

Make the provenance data available to software acquirers in accordance with the organization’s policies, preferably using standards-based formats.

Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a Software Bill of Materials (SBOM)).

Make the provenance data available to the organization’s operations and response teams to aid them in mitigating software vulnerabilities.

Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a Software Bill of Materials (SBOM)).

Protect the integrity of provenance data, and provide a way for recipients to verify provenance data integrity.

Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a Software Bill of Materials (SBOM)).

Update the provenance data every time any of the software’s components are updated.

PW.1.1: Use forms of risk modeling – such as threat modeling, attack modeling, or attack surface mapping – to help assess the security risk for the software.

PW.1.2: Track and maintain the software’s security requirements, risks, and design decisions.

PW.1.3: Where appropriate, build in support for using standardized security features and services (e.g., enabling software to integrate with existing log management, identity management, access control, and vulnerability management systems) instead of creating proprietary implementations of security features and services.

Used before coding to document system components, data flows, and trust boundaries, then enumerate threats and requirements.

Helps define security requirements by identifying known external dependencies, APIs, or services that code will interact with, which informs threat modeling and secure design.

Helps security teams and developers capture, manage, and trace security requirements from initial design through development, ensuring prebuild security alignment.

Enables “threat modeling as code” in prebuild, so security requirements can be automated and version-controlled alongside application code.

Centralizes and structures security requirements so they are available for threat modeling, design reviews, and early validation.

Useful at the design and planning phase to maintain a structured list of security requirements and link them to test cases, threat models, or code modules, ensuring security is addressed before coding.

In prebuild, it can define the exact RMF-derived security requirements the codebase must meet, including control baselines, and link them to design elements or development tasks.

PW.2.1: Have 1) a qualified person (or people) who were not involved with the design and/or 2) automated processes instantiated in the toolchain review the software design to confirm and enforce that it meets all of the security requirements and satisfactorily addresses the identified risk information.

Scans project dependencies (direct and transitive) against the National Vulnerability Database (NVD) and other sources to detect known vulnerabilities (CVEs). Helps confirm if a component meets security requirements before inclusion.

Automated dependency monitoring and update tool integrated with GitHub. Detects vulnerable dependencies and creates pull requests to update them, ensuring only secure versions are used.

Manages Risk Management Framework (RMF) compliance artifacts, including NIST 800-53 controls. Can be used to confirm that selected software components meet mandated security control baselines before approval.

JavaScript/TypeScript linter that enforces secure coding standards and flags insecure coding patterns before they reach production. Helps validate that custom code components align with secure coding requirements.

Automated code analysis platform for identifying vulnerabilities and code quality issues in multiple languages. Confirms code components meet security policies before integration.

Open-source vulnerability scanner for container images and file systems. Ensures that containerized components meet vulnerability and compliance requirements before deployment.

Static vulnerability analysis for container images. Integrates into CI/CD to detect vulnerabilities in base images and layered components before they’re promoted.

Comprehensive vulnerability scanner for container images, file systems, and Git repositories. Validates that selected components have no known vulnerabilities or misconfigurations.

Static analysis for Infrastructure as Code (IaC) to detect security misconfigurations (Terraform, Kubernetes, CloudFormation). Ensures that IaC components meet defined security baselines before use.

Policy-as-code scanner for Terraform, Kubernetes, Docker, and other IaC frameworks. Confirms that infrastructure components comply with security and compliance requirements.

Web-based code review tool. While not a vulnerability scanner, it enforces human review and approval workflows that can include security requirement validation checklists before component approval.

PW.4.1: Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, opensource, and other third-party developers for use by the organization’s software.

PW.4.2: Create and maintain well-secured software components in-house following SDLC processes to meet common internal software development needs that cannot be better met by third-party software components.

PW.4.3: Moved to PW.4.4

PW.4.4: Verify that acquired commercial, open-source, and all other third-party software components comply with the requirements, as defined by the organization, throughout their life cycles.

Generated during build/prebuild to validate component data against defined acceptance criteria.

Used to verify that all components meet licensing and security requirements before integration.

Ensures only vetted, signed, and policy-compliant packages are sourced for builds.

Acts as a controlled source for components meeting defined security standards.

Prevents use of components that fail security requirements or policy checks.

Enforces rules that only scanned, signed, and policy-compliant images are stored and used in builds.

nforces signed commit policy in merge requests before code is accepted.

Runs in CI to check code against predefined security queries before integration.

Enforces security acceptance criteria (e.g., no critical CVEs) before promoting components.

Creates PRs to meet policy-defined security versions.

Ensures repositories meet defined configuration criteria before allowing merges.

Provides a framework to define security assurance practices and maturity targets. Helps establish criteria for secure development processes, including prebuild checks.

Defines detailed security verification requirements for applications. Can be used as a benchmark for automated and manual prebuild security tests.

Vulnerability management and security test orchestration platform. Centralizes results from scanners and ensures issues are tracked against acceptance criteria.

Scans project dependencies for known vulnerabilities (CVEs) and fails builds if they don’t meet criteria.

VCS that supports commit signing and hooks to enforce prebuild checks (linting, security scans).

Lightweight, self-hosted Git service with repository policy enforcement (e.g., signed commits, review requirements).

Git platform with CI/CD integration for running security checks before merging.

Supports extensions for linting, vulnerability scanning, and code signing enforcement pre-commit.

Java IDE with plugins for static analysis, dependency scanning, and secure coding rule enforcement.

Java IDE with plugins for static analysis, secure coding, and SBOM generation.

Java unit testing framework; can integrate with security test suites.

NET testing framework; supports integration with security validation tests.

Python testing framework; can run security rule-based tests as part of CI.

Automated browser testing tool; can validate secure behavior (e.g., auth flows).

End-to-end browser testing with support for security-focused scenarios.

Dynamic Application Security Testing (DAST) tool for finding security issues in running apps during testing stages.

Testing framework for Java; integrates with security automation.

BDD testing framework; can define security acceptance tests in plain language.

Scans containers, file systems, and repos for vulnerabilities and misconfigurations.

Static vulnerability scanning for container images before deployment.

Vulnerability scanner for containers and filesystems.

Python-specific static analyzer for common security issues.

Multi-language static analysis using custom or predefined security rules.

Rails-specific static analyzer for security vulnerabilities.

Detects hardcoded secrets in Git repositories pre-commit or in CI.

Detects secrets and sensitive information in code history and commits.

Open-source framework for signing software artifacts (commits, containers) using cryptographic proofs.

Scans project dependencies (direct and transitive) for known CVEs using NVD and other sources. Can enforce “no critical/high vulnerabilities” criteria before the build passes.

Ensures that selected components meet license and security criteria before merging into mainline.

Can block merges or builds that violate licensing rules or contain known vulnerabilities.

Ensures licensing criteria are met before components are accepted into the build.

Provides component inventory to validate against predefined acceptance criteria.

Enforces security, compliance, and configuration policies during CI/CD gates before release.

PW.5.1 Follow all secure coding practices that are appropriate to the development languages and environment to meet the organization’s requirements.

egrated into CI to scan changed code and block merges if rules fail; can also run locally for pre-commit checks.

Runs in prebuild to fail pipelines when high-severity issues are found in Python code.

Scans Java code before packaging to find vulnerabilities and bad coding practices.

Integrated into CI to detect Java vulnerabilities pre-release.

Runs in CI to flag security issues before merges; supports quality gates for enforcement.

Can run in test environments before production release to catch runtime security issues.

Runs against staging/test instances before deployment to catch exploitable issues.

Blocks builds that include components with vulnerabilities exceeding severity thresholds.

PW.6.1: Use compiler, interpreter, and build tools that offer features to improve executable security

PW.6.2: Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations.

Signs and verifies the integrity/authenticity of source code and pre-built dependencies before compiling.

Verifies cryptographic signatures of source tarballs and dependencies before build.

Scans and audits dependencies for licensing and security issues before they are included in a build.

Integrated into CI to detect Java vulnerabilities pre-release.

Analyzes container image layers to identify open-source components and licensing before using as a base for builds.

Detects licenses, copyrights, and packages in source code before build to ensure compliance and security.

Scans source code and container base images for known vulnerabilities before they are included in builds.

Generates SBOMs from source code and dependencies before build to document and verify components.

PW.7.1 Determine whether code review (a person looks directly at the code to find issues) and/or code analysis (tools are used to find issues in code, either in a fully automated way or in conjunction with a person) should be used, as defined by the organization.

PW.7.2: Perform the code review and/or code analysis based on the organization’s secure coding standards, and record and triage all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.

Scans project dependencies (e.g., Maven, npm, Python) against the NVD for known CVEs before build, enabling early remediation of vulnerable libraries.

Primarily a dynamic application security testing (DAST) tool, but in a pre-build sense, it’s not generally used — can be run against local development builds for early runtime flaw detection. Limited PW.7 pre-build applicability.

Performs SAST and code quality checks for many languages, detecting vulnerabilities, bugs, and code smells before compilation or integration.

Scans JavaScript code and package manifests for known vulnerable libraries before packaging.

Performs dependency scanning for license and vulnerability issues before build. Commercial SaaS version is proprietary.

Lightweight, customizable SAST tool. Uses rules to detect security issues and anti-patterns in source code before build.

Scans Python source for common security issues before build (e.g., insecure function usage, hardcoded passwords).

Static analysis tool for IaC (Terraform, Kubernetes YAML, etc.) to find misconfigurations before deployment.

Static analysis for C/C++ source to catch undefined behavior, memory issues, and common security flaws before compilation.

A plugin for SpotBugs to detect Java-specific security vulnerabilities before build.

Performs deep semantic code analysis using a query language to detect vulnerabilities before build. Excellent for automated SAST in CI pipelines.

Scans Java, Apex, JavaScript, XML, and other code for bugs, unused code, and potential security issues before compilation.

Static analysis for Java bytecode; detects bug patterns and potential vulnerabilities pre-build (when run on compiled class files in CI before packaging).

Automates pull request checks — enforces security/contribution guidelines, prevents insecure patterns from merging into code before build.

PW.8.1: Determine whether executable code testing should be performed to find vulnerabilities not identified by previous reviews, analysis, or testing and, if so, which types of testing should be used.

PW.8.2: Scope the testing, design the tests, perform the testing, and document the results, including recording and triaging all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.

SAST engine that scans source code against security rules before build, catching vulnerabilities early.

Static analysis for Python code to find common security issues before packaging.

Security plugin for SpotBugs to detect vulnerabilities in Java/Scala/Groovy code pre-build.

Static analysis for C/C++ to detect security flaws before compilation artifacts are built.

Rule-based static analysis for Java, Apex, JavaScript, and XML for vulnerabilities and coding issues.

General bug and vulnerability detection in Java code before build output.

Semantic code analysis to find vulnerabilities before build.

SCA tool that identifies vulnerable dependencies in manifests before packaging.

Scans JavaScript and Node.js dependencies for known vulnerabilities before release.

SSCA tool for scanning source code dependencies and base images pre-build for CVEs.

Generates SBOMs from source code before build to verify component inventory.

Scans Infrastructure-as-Code files for misconfigurations before deployment.

Searches code and git history for secrets before build.

Searches code and git history for secrets before build.

PW.9.1: Define a secure baseline by determining how to configure each setting that has an effect on security or a security-related setting so that the default settings are secure and do not weaken the security functions provided by the platform, network infrastructure, or services.

PW.9.2: Implement the default settings (or groups of default settings, if applicable), and document each setting for software administrators.

Finds misconfigurations and insecure defaults in IaC files before build.

Policy-as-code engine to enforce secure configuration rules in pre-build pipelines.

Validates YAML configuration files, ensuring structure correctness before further security rule checks.

RV.1.1: Gather information from software acquirers, users, and public sources on potential vulnerabilities in the software and third-party components that the software uses, and investigate all credible reports.

RV.1.2: Review, analyze, and/or test the software’s code to identify or confirm the presence of previously undetected vulnerabilities.

RV.1.3: Have a policy that addresses vulnerability disclosure and remediation, and implement the roles, responsibilities, and processes needed to support that policy.

Scans source trees and manifest/lock files against OSV for known vulnerabilities for discovery early in development.

Continuously synchronizes Software Bill of Material versions of built artifacts to OSV.dev reporting on vulnerabilities discovered post-build.

Rule-based SAST in PRs/CI for previously undetected vulnerabilities. Static analysis tool used for searching code, finding bugs, and enforcing code standards at various stages of the development cycle (editor, commit, and continuous integration - CI). 

SCA for many ecosystems; runs in CI, outputs SARIF/HTML. CVE-based dependency matching for code-time feedback.

Can source/lockfiles and IaC before build. All-in-one SCA + IaC misconfig checks pre-build.

Generate SBOMs (CycloneDX/SPDX) directly from source. Composition/provenance data to power RV.1 discovery.

Scan source directories or Software Bill of Materials (from Syft) for vulnerabilities. Accurate matching via SBOM + flexible CI integration.

Developers can continuously inspect code quality to detect bugs, code smells, and security vulnerabilities without executing the code.

Developed by GitHub, developers and security researchers can analyze codebases for security vulnerabilities, bugs, and other code quality issues.

A static analysis tool designed to identify common security vulnerabilities in Python code.

Vulnerability scanner specifically designed for Ruby on Rails applications.

Static code analysis tool designed for Java applications, used to identify potential security vulnerabilities within the code.

Prevent hardcoded secrets in code and configs.

Conftest is a utility to help you write tests against structured configuration data.

RV.2.1: Analyze each vulnerability to gather sufficient information about risk to plan its remediation or other risk response.

RV.2.2: Plan and implement risk responses for vulnerabilities.

Aggregates SBOMs, attestations, and vulns to understand blast radius and prioritize fixes.

Automates dependency upgrades/patch PRs with risk-aware policies.

Ingest scanner results (Semgrep/Grype/Trivy/etc.) for de-dupe, severity, ownership, and workflow. Central vulnerability triage and risk tracking tied to repos.

Exposes the blast radius of each vulnerability across live environments.

Agentless vulnerability scanner that analyzes installed packages and maps to CVE data with CVSS scoring. Provides severity, exploitability, and remediation recommendations; can integrate with patch workflows.

Continuous SBOM-based component analysis platform. Enriches vulnerabilities with metadata (severity, exploitability, policy impact).

VEX bridges the gap between identifying potential vulnerabilities (SBOM) and determining their actual risk in a specific environment. Allows organizations to prioritize remediation efforts by focusing on vulnerabilities that are truly exploitable and require immediate attention.

RV.3.1: Analyze identified vulnerabilities to determine their root causes.

RV.3.2: Analyze the root causes over time to identify patterns, such as a particular secure coding practice not being followed consistently.

RV.3.3: Review the software for similar vulnerabilities to eradicate a class of vulnerabilities, and proactively fix them rather than waiting for external reports.

RV.3.4: Review the SDLC process, and update it if appropriate to prevent (or reduce the likelihood of) the root cause recurring in updates to the software or in new software that is created.

Maintains a “guardrail” ruleset for historical issues. Provides pattern-class eradication across modules.

Encode RCAs as rules (e.g., ban insecure APIs, enforce sanitizers) and run in PRs. Catches the class of bug that caused the incident.

Monitor repo hygiene signals (Branch protection, dependency-pinning, fuzzing, etc.) and bake improvements into SDLC. Preventative controls aligned to root-cause themes.

Query codebases to trace vulnerability origins (e.g., find all injection points).

Identifies code quality/security rule violations that may indicate systemic coding issues.

Aggregates scanner results so patterns in vulnerability types are easier to spot.

Tracks vulnerable components and shows recurring dependency-related issues.

A vulnerability scanner for container images and file systems.

Correlates SBOMs across releases to identify repeated dependency issues.

Language-specific security scanner to identify same flaw across multiple files.

Finds repeated insecure coding practices in Rails apps.

Enforces code quality/security hooks before commits.

Git hook automation for JavaScript/TypeScript projects to enforce checks.

Prevents misconfigurations from being deployed by embedding into existing developer workflows.

Adds IaC guardrails to prevent insecure configurations at commit time.

Finds security vulnerabilities, compliance issues, and infrastructure misconfigurations.