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.