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.

P.O.1.1: Identify and document all security requirements for the organization’s software development infrastructures and processes, and maintain the requirements over time.

PO.1.2 Identify and document all security requirements for organization-developed software to meet, and maintain the requirements over time.

Enforces security and compliance policies during build and deployment (e.g., blocking deployments if SBOM scan fails).

Uses OPA’s Rego language to test Kubernetes manifests, Terraform, and Dockerfiles against predefined security requirements.

Tests infrastructure and deployed applications against compliance frameworks (e.g., CIS Benchmarks, NIST 800-53).

Kubernetes-native policy engine to enforce secure configurations at deploy time.

Scans Infrastructure-as-Code (IaC) during build to ensure compliance with security requirements before deploy

Scans container images, IaC, and SBOMs for vulnerabilities and misconfigurations before deployment.

Static analysis for container images to ensure they meet security requirements before push to registry.

Vulnerability scanning for container images and filesystems to validate artifacts against policy before deploy.

OPA-based admission controller to enforce compliance on Kubernetes clusters before allowing deployment.

PO.2.2: Provide role-based training for all personnel with responsibilities that contribute to secure development. Periodically review personnel proficiency and role-based training, and update the training as needed

PO.2.3: Obtain upper management or authorizing official commitment to secure development, and convey that commitment to all with development related roles and responsibilities.

Open-source identity and access management for enforcing RBAC in CI/CD pipelines and deployment tools.

Federated OpenID Connect provider to integrate developer identities into build and deploy systems for role-based access.

Securely manages and controls access to secrets based on defined roles during builds and deployments.

GitOps deployment tool with RBAC to control who can sync, approve, or rollback deployments.

Adds fine-grained RBAC to Jenkins pipelines, limiting build and deployment actions to authorized roles.

Kubernetes-native CI/CD with Kubernetes RBAC to control pipeline execution permissions.

GitOps tool enforcing RBAC for deployment workflows and requiring approvals for changes.

Built-in access control to restrict who can deploy, modify, or delete workloads.

Self-hosted Git service with user roles and repository permissions to enforce approval and review workflows.

Provides audit logging for build and deploy actions, helping track compliance with assigned responsibilities.

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

PO.3.3: Configure tools to generate artifacts6 of their support of secure software development practices as defined by the organization.

Signs and verifies build artifacts to prevent deploying tampered software.

Ensures build provenance and verifies the integrity of artifacts before deploy.

Scans repos and build pipelines for secrets before build execution.

GitOps deployment tool with RBAC to control who can sync, approve, or rollback deployments.

Scans CI/CD tool containers and dependencies for vulnerabilities.

Generates SBOMs for build artifacts to track components used in the toolchain.

Analyzes container images used in builds/deploys for vulnerabilities.

Protects secrets used by build/deploy tools, ensuring they’re not exposed in pipelines.

Centralizes and tracks security testing results for build and deploy toolchains.

agent.org/ Enforces security rules on CI/CD and deployment workflows to prevent unsafe actions

Monitors and logs CI/CD toolchain activity for integrity and compliance.

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

Automates open-source dependency scanning in builds to enforce consistent vulnerability detection.

Static analysis integrated into builds to ensure consistent code security checks before deploy.

Python security linting in build pipelines to maintain consistent language-specific checks.

Consistent vulnerability and IaC scanning before deployment.

Maintains consistent vulnerability scanning for all build artifacts.

Automates compliance checks before deployment to ensure practices match organizational standards.

Standardizes artifact signing and verification so only trusted builds are deployed.

Enforces organization-wide deployment policies across all environments.

Centralizes and standardizes vulnerability tracking and remediation workflows across builds.

PO.5.2: Secure and harden development endpoints (i.e., endpoints for software designers, developers, testers, builders, etc.) to perform development-related tasks using a risk-based approach.

Secures Jenkins build servers with codified configs and RBAC to limit access to critical build jobs.

GitOps deployment with RBAC and signed commit enforcement for production deploys.

GitOps deployment with RBAC and signed commit enforcement for production deploys.

Protects secrets in build and deploy environments, preventing leakage in pipelines

Signs build artifacts and verifies them before deployment to ensure no tampering occurred.

Provides end-to-end software supply chain security, ensuring each step in build/deploy is signed and verified.

Runs ongoing compliance scans against development and build servers; enforce CIS/NIST benchmarks.

Verifies build provenance, ensuring artifacts come from a trusted, uncompromised build environment.

Scans build/deploy infrastructure containers and images for vulnerabilities and misconfigurations.

Runtime security for build and deploy environments to detect malicious behavior or unauthorized activity.

Monitors build and deploy servers for file integrity changes, unauthorized access, and security events

Enforces Kubernetes security policies in deployment environments (e.g., no privileged pods).

PS.1.1: 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.

Sign build outputs (binaries, containers, SBOMs) and create attestations; verify in CI before promotion.

Require signed commits/tags and reject unsigned in CI to prevent unauthorized code from entering builds.

Issue short-lived certs (Fulcio) and record signatures/attestations in a transparency log (Rekor) to detect/trace tampering.

Emit and sign build provenance; verify who/what/where built the artifact before it can ship.

Define a supply-chain layout and verify each step’s materials/products to ensure nothing was tampered across the pipeline.

Automatically sign task results (images, files) in Tekton pipelines and store attestations (e.g., in Rekor).

Sign OCI artifacts (images, Helm charts) during build for later verification in registries and clusters.

Lock inputs and make builds deterministic so unauthorized changes are detectable by hash/provenance mismatch.

Lock inputs and make builds deterministic so unauthorized changes are detectable by hash/provenance mismatch.

Persist signatures, SBOMs, and policy metadata to audit build integrity across services..

Enforce content trust, robot accounts, and policy on who can push/pull; require signed artifacts before release..

Admission controller that blocks unsigned/incorrectly signed images; enforces key/issuer/subject policies.

Kubernetes policies that require image signatures, pin by digest, and forbid mutable tags in deployments.

Gate deployments with custom policies (e.g., “only signed images from approved registries/namespaces”).

Verifies OCI signatures/attestations (Cosign/Notation) at admission time and blocks anything that fails verification.

Kubernetes admission controller dedicated to verifying container image signatures before scheduling.

Verify signatures/attestations as a release gate in your CD pipeline prior to applying manifests.

Sign binaries, container images, SBOMs, and attestations during build; supports keyless signing.

Sign release tags to cryptographically tie the source to the built artifact.

Fulcio issues ephemeral signing certs; Rekor logs all signatures in a tamper-evident transparency log for downstream verification.

Automatically generate provenance metadata describing build origin, inputs, and process. Validates provenance files to ensure artifact integrity before distribution.

Defines a verifiable software supply chain layout; creates link metadata proving each build step.

Stores metadata (signatures, checksums, SBOMs) so it can be queried for verification.

Create and publish checksums for release artifacts so recipients can manually or automatically verify integrity.

Enforce content trust; ensure only signed images are stored and distributed with policy on who can push/pull; require signed artifacts before release.

Kubernetes admission controller enforcing signature/provenance policies before deployment. Admission controller that blocks unsigned/incorrectly signed images; enforces key/issuer/subject policies.

Kubernetes policies that require image signatures, pin by digest, and forbid mutable tags in deployments. Validates signatures and digests for container images before they are deployed.

Custom admission control to enforce artifact integrity and trusted signer policies.

Pluggable verification framework for OCI registries/images; works with Cosign, Notation, in-toto.

Kubernetes admission controller dedicated to signature verification and image trust policies.

Signs OCI artifacts (containers, Helm charts) and verifies them prior to install or deployment.

Used in CD pipelines or admission hooks to verify signatures and attestations match trusted keys/policies before promotion.

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

PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]).

Create immutable, signed tags for each release; preserves source snapshot for auditing

Store large binary release artifacts alongside source with integrity checks.

OSS Host and version control release artifacts (JARs, binaries, containers) with role-based access and checksum validation.

Archive build outputs in a controlled, versioned repository; supports checksums and retention policies.

Store container images with vulnerability scanning, RBAC, and signed content trust to preserve release integrity. Enforce immutable tags and prevent overwrites so deployed artifacts can always be traced back to the archived copy.

(ORT) Archive SBOMs, license files, and vulnerability reports alongside the release for compliance/audit.

Sign release artifacts before archiving so integrity can be checked later.

Enforce digest-pinned images to ensure deployments always match archived release versions.

Policy enforcement to ensure only archived, approved artifacts are deployed.

Verifies artifact signatures/attestations against archived release metadata before deployment..

Admission controller that enforces deployment of only signed images from the archived se

Long-term archival of deployed artifact versions for rollback or investigation.

Retain build provenance in a transparency log so deployed releases can be cross-verified with archived originals

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.

Prevents insecure code from being packaged and deployed.

Ensures that deployed artifacts align with secure baseline configurations

Enforces approved component lists and security baselines before deployment.

Generates SBOMs for deployed applications for ongoing monitoring.

Enforces approved component lists and security baselines before deployment.

Focused vulnerability scanning for deployed artifacts.

Guarantees that build artifacts match the security-approved design exactly, with no drift or environmental differences.

Ensures that all deployed artifacts are built from a traceable, verifiable environment that aligns with design security baselines.

Enforces secure build rules, prevents unauthorized changes, and produces identical outputs across build agents.

Strengthens supply chain security by detecting unauthorized modifications between source and deployment.

Implements secure design principles like minimal attack surface and verified dependency selection.

Ensures artifacts come from a trusted, verified build process and haven’t been altered.

Provides cryptographic assurance that deployed artifacts are authentic and untampered.

Enforces integrity and accountability across the entire build-to-deploy pipeline.

Protects the integrity of deployment and update distribution channels.

Generate and manage keys for signing build artifacts. Implement TLS/SSL for secure communication between build agents and artifact repositories.

Sign source code, commits, and build outputs and verify signatures before deploying artifacts.

Embed cryptographic signing and verification into Java/.NET build pipelines.

Validate that deployment environments meet hardware-based integrity requirements before deployment.

Publish cryptographic attestations of build provenance or deployment approvals and provide a decentralized, tamper-proof audit log of artifact trust data.

Enforce secure deployment design policies (e.g., approved base images, disallowed configurations).

Enforce security design requirements at build time (e.g., dependency approval, CVE thresholds). Apply consistent policy enforcement from build pipelines to runtime.

Ensure that deployed workloads meet security requirements for mutual authentication and zero trust and bind workload identity to build-time provenance for deployment integrity.

Embeds threat models into CI/CD, ensuring security requirements are tied to architectural components before build. (Meets PW.1.1 and PW.1.2)

Helps to refine security requirements around network exposure and asset inventory. (Meets PW.1.1)

Integrates security requirements into system models, which can then be validated in build & deploy. (Meets PW.1.1)

Embeds threat models into CI/CD, ensuring security requirements are tied to architectural components before build. (Meets PW.1.1)

Requirements management tool for defining, tracking, and validating security requirements. Documents security requirements and links them to commits and build outputs.(Meets PW.1.1 and PW.1.2)

Requirements management tool using plain text and version control for traceability. Supports traceability from design through build, ensuring requirements are carried into final artifacts.(Meets PW.1.2)

Open-source compliance and risk management framework tool for tracking RMF (NIST 800-37) controls. Security requirements map to formal compliance controls that can be verified in build & deploy artifacts. (Meets PW1.2)

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.

Automated design compliance gate in CI/CD

Validates deployment configurations match approved security architecture.

Enforce network segmentation rules, encryption requirements, and secure defaults.

Adds IaC review automation to the build process.

Automated code review for alignment with security design requirements.

Config compliance verification before deploying.

Ensures threat model-driven design requirements are implemented.

Post-build/pre-deploy architecture verification. Detect deviations from intended architecture.

Review Kubernetes manifests for design compliance before deployment.Ensures pod security settings match approved deployment designs.

Automated dependency update PRs with vulnerability alerts. Helps verify dependencies meet security requirements (e.g., no known CVEs, minimum versions).

Open Risk Management Framework tracking tool. Can map design-level security requirements to NIST 800-53 controls and verify those controls are implemented in build configs.

Runs in CI/CD pipelines or as a pre-commit hook to block merges if code violates the approved security or architectural rules before build.

SBOM-driven vulnerability scanner for images/filesystems. Validates that dependencies in the build match security baselines and are free from disallowed components.

Static vulnerability analysis for container images. Confirms final images meet design security requirements before deployment.

IaC scanning and policy enforcement (OPA-based). Enforces approved security design in Terraform, Kubernetes, Docker, and AWS CloudFormation configs before deploy.

Code review and approval workflow tool. Enforces human review against design and security requirements before merge to release branches.

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.1.3

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.

Ensures manifests meet secure baseline defaults before deployment.

Validates default configurations meet security requirements.

Detects and blocks insecure defaults in Terraform, Helm, or CloudFormation before release.

Validates hardened defaults in cloud infrastructure provisioning.

Automated config compliance check during CI/CD.

Automates compliance testing for secure defaults.

Bakes hardened defaults into container or VM images before release.

Pre-deployment validation of secure defaults in manifests.

Ensures deployed OS images meet hardened defaults.

SBOM format for documenting exact components/configurations in final build; helps verify secure defaults are present.

SBOM standard to record all components, licenses, and provenance; can confirm inclusion of hardened dependencies.

Catalog of verified Helm charts, OLM operators, etc.; can enforce use of curated, secure-by-default packages.

Repository manager for storing signed, verified artifacts with access controls.

Host artifacts and enforce policy checks before they’re promoted.

OCI registry with vulnerability scanning, content signing, and policy enforcement for images.

Commit/tag signing in GitLab CE for provenance.

Detects code patterns violating security requirements.

Scans container images, IaC, and configs for insecure defaults.

GitHub App enforcing security policies in repos.

Security maturity model to guide secure default practices.

Application security requirements to verify secure defaults.

Central vulnerability tracking; ensures issues found in builds are fixed before release.

Detects known-vulnerable dependencies in builds.

Self-hosted Git service with signing/policy support.

Git platform with signing, scanning, CI/CD policy integration.

Automated testing to confirm defaults work.

Functional/UI test automation to verify secure settings.

Functional/UI test automation to verify secure settings.

DAST scanner to verify app defaults are not exploitable.

Java test framework for security/functional checks

BDD framework for verifying functional + security requirements.

Image vulnerability scanner for OCI registries.

SBOM-driven vuln scanner for builds and images

Detects insecure code patterns/defaults in Python.

Finds policy-violating patterns in code.

Detects Rails-specific security issues/defaults.

Detects secrets in code (prevents default creds exposure).

Finds secrets in repos/history to avoid insecure defaults.

Detects known-vulnerable dependencies in builds.>

Automates license/security checks; blocks noncompliant components.

License/dependency scanning; ensures compliance with default policies.

Detects license, copyright, and security metadata in artifacts.

Container image inspection for dependency/component details.

Policy-as-code for build & deploy; blocks insecure defaults in configs/manifests.

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

Acts as the central trusted artifact repository.

Acts as the central trusted artifact repository.

Acts as the central trusted artifact repository.

Ensures repository contents are authentic and tamper-free.

Ensures stored artifacts meet vulnerability requirements before deployment

Enforces provenance checks at repository ingestion.

Protects against repository and update tampering.

Controls supply chain intake and internal artifact storage.

Ties repository artifacts back to secure build pipelines.

Runs as part of the CI pipeline to automatically scan code for security flaws, policy violations, and unsafe patterns before artifacts are built. Supports rule-as-code to enforce secure build policies.

Python-focused static analyzer that checks for insecure functions, weak crypto, and common security issues before packaging or deployment.

Legacy Java static analysis; can be used to flag known insecure code patterns before build. Superseded by SpotBugs.

Modern replacement for FindBugs. Java bytecode scanner to enforce safe code practices before compiling final artifacts.

Comprehensive SAST platform; can be integrated in CI/CD to enforce quality gates, stopping builds that fail security rules.

Runs against built/staged applications in pre-deployment environments to detect exploitable vulnerabilities, ensuring no insecure version is promoted.

Web application vulnerability scanner that can be part of a build’s QA stage to ensure secure release readiness.

Scans for known-vulnerable dependencies in the build, blocking insecure versions from being deployed.

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.

Fast rule-based SAST with CI integration.

General code quality + basic security rules.

Python SAST linters.

Vulnerability scan images/filesystems against SBOMs.

Vulnerability scan images/filesystems against SBOMs.

Generate SBOMs (SPDX/CycloneDX) during build.

Continuous SBOM monitoring and alerting post-build./p>

Block commits/builds that contain secrets; run in CI and as pre-commit hooks.

Provides methods, guidelines, and supporting tools for deterministic builds, ensuring integrity and verifiability of source-to-binary outputs.

Build system with hermetic (sandboxed) execution and explicit dependency tracking, preventing hidden or unverified dependencies.

High-speed, deterministic build system that supports reproducibility and strict configuration-as-code.

Enforces controlled dependency resolution and supports reproducible builds for Java and JVM-based projects.

Creates reproducible, controlled build environments for embedded Linux images, preventing environmental drift.

Uses prebuilt toolchains and sandboxed environments for secure, reproducible Android builds.

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.

Runs automatically in CI before building deployment artifact.

Integrates with CI/CD to enforce clean code before release

Detect SQL injection, XSS, or unsafe deserialization patterns in codebase.

Protects against secret leakage in deployed artifacts

Require two reviewers for any code changes in security-critical modules.

Provides verifiable audit trail for security review completion.

Provides verifiable audit trail for security review completion.

Continuously scans dependencies in each build for new CVEs. Can run on every commit or nightly in CI/CD.

Can be automated in CI/CD to re-test staging environments for vulnerabilities as new code is deployed.

Focused on JavaScript libraries; detects newly disclosed vulnerabilities in frontend/back-end packages during builds.

Scans dependencies for vulnerabilities and license issues, integrating with builds to catch new findings.

Runs in CI/CD for Python projects to catch newly introduced security issues.

Detecting Known Vulnerabilities – Compares IaC components and configurations against known security best practices and compliance frameworks (CIS Benchmarks, NIST, PCI-DSS).

Re-scans C/C++ code after every build to ensure no new issues were introduced.

Extension to SpotBugs that catches security flaws in Java bytecode continuously during the build cycle.

Performs continuous security queries on code with each pull request or scheduled scan.

Runs code quality and security rule checks on every commit/build.

Java static analysis integrated into the build pipeline for continuous vulnerability detection.

Automates security-related PR review rules, preventing unsafe code from merging.

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.

Run as a CI step after image build, before push to registry

Confirms that final executable meets vulnerability thresholds.

Feeds SBOM into SCA tools like Dependency-Track for ongoing monitoring

Ensures final artifact matches secure configuration requirements.

Baseline enforcement step before promotion to production.

Pre-release runtime security testing.

Provides verifiable evidence for compliance and audits.

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.

Automates baseline hardening during image creation.

Produces secure-by-default container images.

CI gate to block insecure defaults from being built/deployed.

Prevents insecure IaC defaults from reaching deployment.

Prevents insecure IaC defaults from reaching deployment.

Produces compliance evidence before artifact promotion.

Ensures only hardened, verified artifacts can be deployed.

Verify hardened defaults match CIS requirements before release.

Policy enforcement for manifests and configs at build time.

Codifies secure defaults as enforceable CI/CD policies.

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.

Continuously scans manifests/locks against OSV; great for confirming new disclosures across all supported releases..

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

Queries the OSV.dev vulnerability database for open-source package CVEs.

Scans container images and SBOMs for known vulnerabilities.

Aggregates multiple public vulnerability feeds.

Checks installed binaries for known CVEs.

SAST for multiple languages; customizable rules. Run on merge to main branch.

Python security linting. Add to Python project build stage.

SAST & quality checks. Run in build step; block deploy if high-severity issues found.

DAST; quick passive scan on deployed staging app.

Public policy location for reporters.

Vulnerability Disclosure Program.

Playbook for implementing disclosure.

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.

Exposes the blast radius of each vulnerability across live environments.

Centralizes vulnerabilities from SAST/DAST/SCA tools; adds risk scoring.

SBOM-based vuln tracking, includes CVSS scoring and metadata.

Rates probability of exploitation for CVEs (risk-based prioritization).

Provides exploit links, PoCs, and additional context per CVE.

Standardized impact scoring to support triage decisions.

Sign remediated builds before deploying (trusted delivery mechanism).

Temporary WAF rules to mitigate unpatched web vulns.

Runtime detection and mitigation for unpatched container/Kubernetes issues.

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.

Write org-specific rules to detect the root-cause pattern; scan repos to eradicate classes of bugs.

Deep code queries to identify the precise coding constructs leading to vulns.

Provides issue traces, rule violations, and hotspots including root cause indicators.

Tracks vulns + metadata, allows attaching root cause notes per issue.

Long-term tracking of vulnerable components to see recurring dependency issues.

Metadata API for tracking security events across builds/releases.

Detects weakness patterns (CWEs) in binaries, useful for compiled artifacts.

Open-source code analysis platform for hunting bug patterns at scale.

Framework to improve secure dev lifecycle practices.

Automates repo security health checks (branch protection, dependency pinning, CI hardening).

Standard for documenting compliance + SDLC security improvements.

Enforces security policies across GitHub orgs/repos.

P.O.1.1: Identify and document all security requirements for the organization’s software development infrastructures and processes, and maintain the requirements over time.

PO.1.2 Identify and document all security requirements for organization-developed software to meet, and maintain the requirements over time.

Supports definitions of security policies as code and enforce them in pipelines, CI/CD, and runtime. Enforces runtime policies via integrations with Kubernetes, Terraform, and CI/CD platforms.

Periodically audits deployed environments against internal and external security standards.

Associate and version security requirement metadata per service and deployment, enabling continuous visibility.

Maps security findings back to specific policy controls or regulatory frameworks.

PO.2.1: 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.

PO.2.2: Provide role-based training for all personnel with responsibilities that contribute to secure development. Periodically review personnel proficiency and role-based training, and update the training as needed.

PO.2.3: Obtain upper management or authorizing official commitment to secure development, and convey that commitment to all with development related roles and responsibilities.

Tracks authorship and code reviewers, and tags releases and documents who triggered them.

Associates deployed services with responsible individuals or teams, with historical record of changes, deployments and roles.

Lists service owners, on-call teams and escalation paths making post-deployment responsibility transparent across the organization.

Track security findings and assign resolution responsibilities.

Enforces access policies and role boundaries in runtime environments.

Ensures only authorized commits/deployments affect production and logs every promotion and rollback.

Detects unauthorized activity at runtime.

Alerts based on ownership/roles

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

PO.3.3: Configure tools to generate artifacts6 of their support of secure software development practices as defined by the organization.

Continuously monitors SBOMs for newly disclosed CVEs in deployed software.

Maintains a historical record of deployed software, components, and their SBOMs; links to owners for accountability.

Generates SBOMs from deployed container images or filesystems on-demand.

Post-deployment container, filesystem, and package vulnerability scanning; also generates SBOMs.

Continuous scanning of container registries for vulnerabilities.

Fast vulnerability scanner for container images and filesystems.

Validates that deployed artifacts match the cryptographic attestations from the build process.

Verifies signatures of deployed artifacts; ensures they match approved builds.

Provides a public, immutable log for signatures and provenance data.

Enforce security and compliance policies on deployed systems (e.g., Kubernetes clusters).

Audit deployed infrastructure and applications against security baselines and compliance requirements.

Incident response platform for post-deployment security events.

Track vulnerabilities and assign remediation tasks; integrate with scanners for continuous updates.

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

Runtime security detection for containers and hosts; generates event logs for suspicious behavior.

Captures system-level security events for Linux.

Endpoint telemetry and configuration monitoring.

Collect and store metrics and logs in a queryable format.

Maintains versioned SBOMs linked to each deployment.

Generates SBOMs from deployed artifacts for ongoing monitoring./p>

Collects and stores compliance scan data.

SIEM with audit logging, threat detection, and compliance monitoring.

Detects CVEs in deployed images and file systems.

Validates that deployed artifacts match the cryptographic attestations from the build process.

Provides a public, immutable log for signatures and provenance data.

Audit deployed infrastructure and applications against security baselines and compliance requirements.

Continuous vulnerability scanning + SBOM generation for running systems.

Stores and organizes security scan results; integrates with Trivy, Grype, and Dependency-Track.

PO.5.2: Secure and harden development endpoints (i.e., endpoints for software designers, developers, testers, builders, etc.) to perform development-related tasks using a risk-based approach.

Runs ongoing compliance scans against development and build servers; enforce CIS/NIST benchmarks.

Check infrastructure against defined security baselines.

Monitor build and deployment nodes for unauthorized changes.

Validates Kubernetes-based build/test clusters meet CIS benchmarks.

Enforce rules for infrastructure configuration (Kubernetes, Terraform, CI/CD).

Kubernetes-native policy enforcement for cluster security./p>

Hardened CI/CD pipelines with access controls and audit logs.

Securely store build artifacts post-deployment; apply access controls.

Container registry with built-in vulnerability scanning and RBAC.

Ingests infrastructure security logs and alerts on violations.

Detect unauthorized activity in build/deployment clusters or runner nodes.

Monitor infrastructure security metrics and trigger notifications.

Validates that deployed artifacts match the cryptographic attestations from the build process.

Maintain an immutable, tamper-evident log of signed infrastructure configuration files.

PS.1.1: 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.

Sign and verify container images, binaries, and other artifacts.

Immutable public transparency log for signatures and metadata.

End-to-end supply chain verification to ensure deployed artifacts came from trusted sources.

Sign and verify any file type, including tarballs and configuration files.

Container registry with built-in vulnerability scanning, content signing, and RBAC.

Secure artifact repository with access controls.

Manages binary repositories with fine-grained permissions.

Monitors filesystem for unauthorized changes.

Creates a baseline of files and detects alterations.

Detects suspicious activity in Kubernetes or container environments, including file changes.

Enforces role-based policies for container image deployment.

Centralized authentication/authorization for artifact registries and CI/CD systems.

SIEM platform that monitors access logs and alerts on anomalies.

Tracks which version of a service is deployed where, and links to its signed SBOM.

Generates SBOMs for deployed artifacts for later verification.

Monitors components in deployed artifacts against CVE feeds.

Container registry with image retention policies, RBAC, and content trust.

Artifact repository for storing binaries and dependencies.

Binary management with retention and access control.

Tag and store release binaries, SBOMs, and checksums.

Sign and verify container images, SBOMs, and other artifacts.

Immutable transparency log for all signed artifacts and metadata.

Sign and verify tarballs, binaries, or SBOM files.

Provide end-to-end build provenance verification.

Maps deployed services to specific versions and their SBOMs.

Generates SBOMs from deployed artifacts.

Continuously monitors SBOMs for new CVEs in preserved releases.

Filesystem integrity checker to detect changes in stored artifacts.

Baseline and monitor stored release directories for modifications.

SIEM that audits artifact repository activity.

Linux-level auditing for access to preserved release files.

Restrict who can upload or modify artifacts in registries.

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

PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]).

Generate SBOMs from deployed containers, VMs, or file systems (SPDX & CycloneDX formats).

Create SBOMs and scan for vulnerabilities in deployed systems.

Record build steps and supply chain metadata as signed “link” files.

Capture build and deployment provenance as signed attestations.

Sign SBOMs and metadata for offline or private distribution.

Store signatures and attestations in an immutable, public transparency log.

Detect unauthorized changes in locally stored provenance archives.

Detect unauthorized changes in locally stored provenance archives.

Version and track deployed services and their SBOMs; link them to environments and releases. API/UI access for sharing SBOM and component history for specific releases.

Continuously monitor preserved SBOMs for new CVEs.

Attach SBOMs and signatures to container images in a registry.

Host and validate SBOMs in a web-accessible interface.

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.

Static and Dynamic Analysis that an be run against deployed codebases in staging mirrors to detect insecure patterns.

Web application security scanner for deployed apps.

Active and passive testing of live apps for vulnerabilities.

Validates that deployed applications meet secure coding standards.

10 minute synchronizing to OSV.dev for new vulnerability detection in deployed artifacts.

Scans systems for compliance with security coding-related baselines.

Logging and Monitoring - Detects insecure behavior at runtime (e.g., unsafe system calls).

Monitors application and OS logs for security-related events.

Captures low-level system calls related to code execution.

Generates SBOMs for deployed applications for ongoing monitoring.

Continuously tracks SBOMs for new vulnerabilities

Scans deployed containers/filesystems for known CVEs in code and dependencies.

Focused vulnerability scanning for deployed artifacts.

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.

Verify deployed containers and binaries were signed at build time.

Store verification data and attestations in a tamper-evident log.

Ensure deployed code matches the reviewed build pipeline steps.

Monitor deployed files for unauthorized changes.

Review mirrored deployed code for security issues or policy violations.

Advanced code queries to detect vulnerability patterns.

Web vulnerability scanning against deployed endpoints.

Track vulnerabilities to live endpoints for quick remediation times.

Automated and manual DAST testing for live applications.

Server-focused vulnerability scanning.

Map results to compliance baselines.

Track vulnerabilities found during post-deployment reviews and link to remediation./p>

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.1.3

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.

Stores signed vulnerability reports and patch commit metadata.

Logs scan results, remediations, and signatures immutably.

Audit and evidence retention tracks which environments are running which version, enabling targeted redeployment of patched builds.

Scans running containers, filesystems, and Kubernetes clusters; also generates SBOMs.

SBOM-driven vulnerability scanning for images and directories.

Monitors container registries for vulnerable images.

Network and host vulnerability scanning.

Generates SBOMs from deployed environments.

CWatches SBOMs for new CVEs and policy violations.

Nix-based vulnerability scanning from SBOM input.

Kubernetes-native admission controller enforcing vulnerability thresholds.

Detects runtime anomalies that may indicate exploitation.

Server-focused vulnerability scanning.

Automates container redeployments when a new image is pushed.

Automated Kubernetes node reboots for kernel patching.

Centralizes vulnerability data from scanners; assigns remediation tasks and tracks SLAs./p>

Incident response and coordination for urgent vulnerability events./p>

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

Ongoing scans of deployed containers, filesystems, and Kubernetes clusters.

Detect CVEs in deployed SBOMs or images.

Continuous vulnerability scanning for registry images.

Generate SBOMs from running systems for ongoing monitoring.

Define and run compliance checks (CIS, NIST, org-specific policies) against deployed environments.

Evaluate running systems against security baselines.

Validate Kubernetes deployments against CIS benchmarks.

Identify potential attack paths in deployed Kubernetes clusters.

Detect runtime changes to files, processes, and network behavior.

File integrity monitoring to ensure binaries/configs aren’t altered.

Query system state to detect unauthorized configuration changes.

Enforce continuous compliance policies at runtime.

Kubernetes-native policy engine to prevent insecure updates.

Centralize verification results and track issues over time./p>

Store signed verification reports in a tamper-proof ledger.

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.

Trivy runs weekly scans on all production container images and hosts → results are signed and logged in Rekor.

Regenerates SBOMs for deployed artifacts, and flags new CVEs.

CVSS scoring + SLA assignment to owners./p>

Auto-rebuild/redeploy when patched images are available

Automated Kubernetes node reboots for kernel patching.

Use canary/staged rollouts for patched versions.

Run scheduled scans on running containers, VMs, and registries; integrate with SBOM monitoring

Store signed records of detection, triage, fix, and verification

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.

Run SAST against the exact code linked to deployed binaries; include dependency scanning

Re-run code analysis on production mirrors.

Keeps immutable records of all reviews, approvals, and automated analysis runs

Signed commits, protected branch history, scan results.

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.

Scans deployed containers/filesystems for known CVEs in code and dependencies.

Focused vulnerability scanning for deployed artifacts.

10 minute synchronizing to OSV.dev for new vulnerability detection in deployed artifacts.

Network and host vulnerability scanning.

Map scan results to security standards (NIST, CIS, OWASP ASVS)

Compliance scan outputs, baseline profiles, exception docs.

DAST, fuzzing, and runtime monitoring to detect insecure behavior

DAST/fuzzing reports.

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.

Continuously monitors drift in container configurations.

Compare deployed systems against secure configuration baselines (NIST, CIS, STIG)

Compare deployed systems against secure configuration baselines (NIST, CIS, STIG).

Continuously monitor config changes; alert or auto-remediate deviations.

Drift detection logs, remediation actions.

Policy-as-code and config management to ensure all deployments match baseline

Config playbooks, enforcement logs, policy change history.

Store signed scan results and drift detection records in tamper-evident systems.

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.

Integrates with live SBOMs to detect and alert on vulnerabilities after release.

Links detected vulnerabilities directly to deployed service versions for traceability.

Central vulnerability management hub with metrics and tracking.

Identify vulnerabilities in images already deployed in Kubernetes or Docker environments.

Works with Syft-generated SBOMs to continuously check for new CVEs.

Provide scheduled compliance scans alongside vulnerability checks.

Helps teams prioritize remediation by filtering out non-exploitable vulnerabilities.

MFeed live SBOMs into scanners like Dependency-Track or Grype.

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.

Centralizes risk scoring, workflow management, and reporting for remediation progress.

Provides real-time vulnerability prioritization and integrates with issue tracking systems.

Enables environment-specific remediation prioritization and impact assessment.

Enforce remediation SLAs and automate rollouts of fixed versions.

Continuous scanning plus integration with CI/CD to push patched artifacts.

Ensures no vulnerability is left without a tracked remediation action.

Provides real-time signals to prioritize operational security fixes.

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.

Supports forensic analysis by tracking when and where a vulnerable component entered the system.

Maintains historical data to identify trends in vulnerability origins.

Supports forensic traceability and accountability in root cause analysis.

nables version-diff SBOM analysis for root cause investigations.

Assists in determining whether vulnerabilities stem from code-level issues.

Enables root cause mapping to configuration weaknesses.

Provides temporal context for root cause timelines.

Supports deep inspection during vulnerability forensics.