• 1:
• 1.1: Code and Prebuild Tasks
• 1.1.1: Prepare the Organization (PO)
• 1.1.2: Protect the Software (PS)
• 1.1.3: Produce Well-Secured Software (PW)
• 1.1.4: Respond to Vulnerabilities
• 1.2: Build and Deploy Tasks
• 1.2.1: Prepare the Organization (PO)
• 1.2.2: Protect the Software (PS)
• 1.2.3: Produce Well-Secured Software (PW)
• 1.2.4: Respond to Vulnerabilities (RV)
• 1.3: Post Deployment Tasks
• 1.3.1: Prepare the Organization (PO)
• 1.3.2: Protect the Software (PS)
• 1.3.3: Produce Well-Secured Software (PW)
• 1.3.4: Respond to Vulnerabilities (RV)
• 2:
• 2.1: Code and Prebuild Tasks
• 2.1.1: Security Risk Assessment - Code and Prebuild
• 2.1.2: Secure-by-Design Requirements - Code and Prebuild
• 2.1.3: Third-Party Dependency Due Diligence - Code and Prebuild
• 2.1.4: Vulnerability Disclousres Preperation - Code and Prebuild
• 2.1.5: Compliance Evidence Summary - Code and Prebuild
• 2.2: Build and Deploy Tasks
• 2.2.1: Artifact Integrity and Secure Distribution - Build and Deploy
• 2.2.2: Release Security Validation - Build and Deploy
• 2.2.3: SBOM Genearation and Management - Build and Deploy
• 2.2.4: Technical Documenatation and Evidence - Build and Deploy
• 2.3: Post Deployment Tasks
• 2.3.1: Affected-Product Identification - Post Deployment
• 2.3.2: Remediation and Security Update - Post Deployment
• 2.3.3: Continuous Vulernability Management - Post Deployment
• 2.3.4: Vulnerability Disclosure and Regulatory Reporting - Post Deployment
• 3:
• 3.1: Code and Prebuild
• 3.1.1: AI-Assisted Code Development
• 3.1.2: AI Agent Identity and Permissions
• 3.1.3: AI Application Threat Modeling
• 3.1.4: AI Model and Data Supply Chain
• 3.1.5: Prompt and Agent Configuration Security
• 3.2: Build and Deploy
• 3.2.1: AI-Generated Code Validation
• 3.2.2: AI Model and Artifact Integrity
• 3.2.3: AI Security Testing and Red Teaming
• 3.2.4: Secure AI Deployment
• 3.2.5: AI Release Evidence and Inventory
• 3.3: Post Deployment
• 3.3.1: AI Runtime Security Monitoring
• 3.3.2: Continuous AI Vulnerability Management
• 3.3.3: AI Agent Activity Monitoring
• 3.3.4: AI-Assisted Vulnerability Remediation
• 3.3.5: AI Incident Response and Recovery
• 4: Resources and Education
• 4.1: Free Linux Foundation Courses
• 4.2: NIST Resources
• 4.3: EU Cyber Resilience Act Resources

1 -

NIST Secure Software Development Framework (SSDF) — Overview

The Secure Software Development Framework, defined in NIST SP 800-218, provides a structured set of security practices designed to reduce software vulnerabilities throughout the software development lifecycle (SDLC). Rather than treating security as a final checkpoint before release, SSDF encourages organizations to integrate security into development, build, deployment, and ongoing maintenance activities. The framework establishes four core practice groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Together, these practices help organizations prevent vulnerabilities, protect software integrity, identify security risks, and respond to vulnerabilities that emerge after release.

Phase 1: Code and Prebuild

Primary objective: Prevent security weaknesses from entering the software supply chain. This phase focuses on establishing secure development practices before software enters the build process. It includes defining security requirements, protecting source code repositories, reviewing code, managing dependencies, and identifying vulnerabilities early through activities such as static application security testing (SAST), software composition analysis (SCA), and secrets detection.

Phase 2: Build and Deploy

Primary objective: Ensure software is built, packaged, and deployed through trusted, secure, and verifiable processes. This phase focuses on protecting the software build process and ensuring that only validated, trusted artifacts are deployed. Security practices include securing CI/CD infrastructure, controlling access to build systems, scanning dependencies and container images, generating Software Bills of Materials (SBOMs), signing artifacts, and verifying software provenance and integrity.

Phase 3: Post Deployment

Primary objective: Continuously detect, assess, and remediate vulnerabilities in deployed software throughout its operational lifecycle. This phase extends security beyond the CI/CD pipeline to address vulnerabilities discovered after software has been released. It includes continuous vulnerability monitoring, identifying affected deployed software, assessing exposure, performing dynamic application security testing (DAST), coordinating remediation, and maintaining vulnerability response processes as new threats emerge.

1.1 - Code and Prebuild Tasks

Achieving Code and Prebuild Tasks of the Secure Software Development Framework

This chapter focuses specifically on DevSecOps tooling and practices related to Code and Prebuild actions of the CI/CD pipeline to achieve tasks defined by the Secure Software Development Framework.

The Secure Software Development Framework, developed by the National Institute of Standards and Technology (NIST), provides a comprehensive approach to ensuring security across the software development process, from initial design through deployment and maintenance. The framework outlines key practices and guidelines that organizations can implement to secure their software development lifecycle (SDLC), with a particular emphasis on integrating security into automated processes.

1.1.1 - Prepare the Organization (PO)

Prepare the Organization (PO) for Code and Prebuild Tasks

Organizations should ensure that their people, processes, and technology are prepared to perform secure software development at the organization level. Many organizations will find some PO practices to also be applicable to subsets of their software development, like individual development groups or projects.

PO.2 Implement Roles and Responsibilities

Ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLC-related roles and responsibilities throughout the SDLC.

PO.3 Implement Supporting Toolchains

Use automation to reduce human effort and improve the accuracy, reproducibility, usability, and comprehensiveness of security practices throughout the SDLC, as well as provide a way to document and demonstrate the use of these practices. Toolchains and tools may be used at different levels of the organization, such as organization-wide or project-specific, and may address a particular part of the SDLC, like a build pipeline.

PO.4 Define and Use Criteria for Software Security Checks

Help ensure that the software resulting from the SDLC meets the organization’s expectations by defining and using criteria for checking the software’s security during development.

PO.5 Implement and Maintain Secure Environments for Software Development

Ensure that all components of the environments for software development are strongly protected from internal and external threats to prevent compromises of the environments or the software being developed or maintained within them. Examples of environments for software development include development, build, test, and distribution environments.

Note: Securely configure code repository and CI/CD servers - this is a complex topic, beyond the scope of this document. Securely configure development endpoints (i.e., developer laptops) - this is a complex topic, beyond the scope of this document.

1.1.2 - Protect the Software (PS)

Protect the Software (PS) Tasks for Code and Prebuild

Organizations should protect all components of their software from tampering and unauthorized access.

PS.1: Protect All Forms of Code from Unauthorized Access and Tampering

Help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of the software. For code that is not intended to be publicly accessible, this helps prevent theft of the software and may make it more difficult or time-consuming for attackers to find vulnerabilities in the software.

PS.2 Provide a Mechanism for Verifying Software Release Integrity

Help software acquirers ensure that the software they acquire is legitimate and has not been tampered with.

PS.3 Archive and Protect Each Software Release

Preserve software releases in order to help identify, analyze, and eliminate vulnerabilities discovered in the software after release.

1.1.3 - Produce Well-Secured Software (PW)

Produce Well-Secured Software (PW) Tasks for Code and Prebuild

Organizations should produce well-secured software with minimal security vulnerabilities in its releases.

PW.1

Design Software to Meet Security Requirements and Mitigate Security Risks: Identify and evaluate the security requirements for the software; determine what security risks the software is likely to face during operation and how the software’s design and architecture should mitigate those risks; and justify any cases where risk-based analysis indicates that security requirements should be relaxed or waived. Addressing security requirements and risks during software design (secure by design) is key for improving software security and also helps improve development efficiency.

PW.2

Review the Software Design to Verify Compliance with Security Requirements and Risk Information: Help ensure that the software will meet the security requirements and satisfactorily address the identified risk information.

PW.4

Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating FunctionalityLower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software by reusing software modules and services that have already had their security posture checked. This is particularly important for software that implements security functionality, such as cryptographic modules and protocols.

PW.5 Create Source Code by Adhering to Secure Coding Practices: Decrease the number of security vulnerabilities in the software, and reduce costs by minimizing vulnerabilities introduced during source code creation that meet or exceed organization-defined vulnerability severity criteria.

PW.6 Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security: Decrease the number of security vulnerabilities in the software and reduce costs by eliminating vulnerabilities before testing occurs.

PW.7

Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements: Help identify vulnerabilities so that they can be corrected before the software is released to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities. Human-readable code includes source code, scripts, and any other form of code that an organization deems humanreadable.

PW.8

Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements: Help identify vulnerabilities so that they can be corrected before the software is released in order to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities and improves traceability and repeatability. Executable code includes binaries, directly executed bytecode and source code, and any other form of code that an organization deems executable.

PW.9

Configure Software to Have Secure Settings by Default: Help improve the security of the software at the time of installation to reduce the likelihood of the software being deployed with weak security settings, putting it at greater risk of compromise.

1.1.4 - Respond to Vulnerabilities

Respond to Vulnerabilities (RV) for Code and Prebuild Tasks

Respond to Vulnerabilities (RV): Organizations should identify residual vulnerabilities in their software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.

RV.1

Identify and Confirm Vulnerabilities on an Ongoing Basis: Help ensure that vulnerabilities are identified more quickly so that they can be remediated more quickly in accordance with risk, reducing the window of opportunity for attackers.

To satisfy SSDF RV.1 in a code and prebuild context using open-source tools, the focus shifts to detecting and remediating vulnerabilities before any artifact is built, so fixes happen in code/manifest PRs, not after packaging.

RV.2

Assess, Prioritize, and Remediate Vulnerabilities: Help ensure that vulnerabilities are remediated in accordance with risk to reduce the window of opportunity for attackers.

To satisfy SSDF RV.2 in a code and prebuild context using open-source tools, the focus shifts to:

• Recording each vulnerability

• Analyze risk (exploitability & impact)

• Choose responses, publish advisories, and deliver remediations via trusted mechanisms; include temporary mitigations where needed.

RV.3

Analyze Vulnerabilities to Identify Their Root Causes: Help reduce the frequency of vulnerabilities in the future.

To satisfy SSDF RV.3 in a code and prebuild context using open-source tools, the focus shifts to:

• Identify vulnerabilities in source code and dependency manifests before building, using SBOM generation, SCA, and SAST

• Confirming findings by removing false positives and documenting minimal evidence for remediation

• Enforcing early guardrails such as version pinning, deny-lists, and secret scanning to block known risks

• Normalize, de-duplicate, and prioritize findings based on severity, exploitability, and usage context

• Apply policy-driven gates in PRs to block high-risk vulnerabilities and automate safe dependency updates

• Assign ownership, require disposition for each finding, and govern exceptions with time-bound waivers or VEX records

1.2 - Build and Deploy Tasks

Achieving Build and Deploy Tasks of the Secure Software Development Framework

This chapter focuses specifically on DevSecOps tooling and practices related to Build and Deploy actions of the CI/CD pipeline to achieve tasks defined by the Secure Software Development Framework.

The Secure Software Development Framework, developed by the National Institute of Standards and Technology (NIST), provides a comprehensive approach to ensuring security across the software development process, from initial design through deployment and maintenance. The framework outlines key practices and guidelines that organizations can implement to secure their software development lifecycle (SDLC), with a particular emphasis on integrating security into automated processes.

1.2.1 - Prepare the Organization (PO)

Prepare the Organization (PO) Build and Deploy Tasks

Organizations should ensure that their people, processes, and technology are prepared to perform secure software development at the organization level. Many organizations will find some PO practices to also be applicable to subsets of their software development, like individual development groups or projects.

PO.1 Define Security Requirements for Software Development: Ensure that security requirements for software development are known at all times so that they can be taken into account throughout the SDLC and duplication of effort can be minimized because the requirements information can be collected once and shared. This includes requirements from internal sources (e.g., the organization’s policies, business objectives, and risk management strategy) and external sources (e.g., applicable laws and regulations).

To satisfy SSDF PO.1 in a Build and Deploy context using open-source tools, the focus shifts from just defining to:

• Enforcing security policies on dependencies, code, and configurations.

• Verifying compliance with established security baselines before deployment.

• Ensuring artifacts meet DoD, NIST, or organizational security requirements.

PO.2

Implement Roles and Responsibilities: Ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLC-related roles and responsibilities throughout the SDLC.

To satisfy SSDF PO.2 in a Build and Deploy context using open-source tools, the focus shifts to:

• Enforcing role-based access control (RBAC) to limit who can trigger builds, approve changes, and deploy.

• Providing audit logs and traceability of actions for accountability.

• Ensuring code changes and deployments are reviewed by authorized personnel.

PO.3

Implement Supporting Toolchains: Use automation to reduce human effort and improve the accuracy, reproducibility, usability, and comprehensiveness of security practices throughout the SDLC, as well as provide a way to document and demonstrate the use of these practices. Toolchains and tools may be used at different levels of the organization, such as organization-wide or project-specific, and may address a particular part of the SDLC, like a build pipeline.

To satisfy SSDF PO.3 in a Build and Deploy context using open-source tools, the focus shifts to:

• Ensuring build and deployment tools are configured securely and kept patched.

• Protecting against supply chain attacks targeting the CI/CD pipeline.

• Verifying the integrity of tools and artifacts before use.

• Controlling and monitoring access to toolchains.

PO.4 Define and Use Criteria for Software Security Checks: Help ensure that the software resulting from the SDLC meets the organization’s expectations by defining and using criteria for checking the software’s security during development.

To satisfy SSDF PO.4 in a Build and Deploy context using open-source tools, the focus shifts to:

• Applying consistent security testing and validation practices before release.

• Automating security checks in CI/CD pipelines.

• Using standardized processes for verifying, signing, and tracking artifacts.

• Integrating security gates so no insecure artifact is deployed.

PO.5 Implement and Maintain Secure Environments for Software Development: Ensure that all components of the environments for software development are strongly protected from internal and external threats to prevent compromises of the environments or the software being developed or maintained within them. Examples of environments for software development include development, build, test, and distribution environments.

To satisfy SSDF PO.5 in a Build and Deploy context using open-source tools, the focus shifts to:

• Protecting CI/CD infrastructure from internal and external threats.

• Hardening build servers, container registries, and deployment systems.

• Ensuring build and deploy environments are patched, monitored, and access-controlled.

• Preventing malicious code or tampering in the software supply chain.

1.2.2 - Protect the Software (PS)

Protect the Software (PS) for Build and Deploy Tasks

Protect the Software (PS): Organizations should protect all components of their software from tampering and unauthorized access.

PS.1

Protect All Forms of Code from Unauthorized Access and Tampering : Help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of the software. For code that is not intended to be publicly accessible, this helps prevent theft of the software and may make it more difficult or time-consuming for attackers to find vulnerabilities in the software.

To satisfy SSDF PS.1 in a build and deploy context using open-source tools, the focus shifts from just defining to:

• Secure the CI/CD pipeline itself – ensure only trusted, authenticated processes can produce build outputs.

• Protect source inputs and dependencies, lock versions, use checksums, and prevent injection of malicious code into the build process.

• Sign artifacts and record provenance, generate cryptographically verifiable metadata proving what was built, from which source, and by whom.

• Enforce reproducible builds so that any tampering results in a hash/signature mismatch.

• Restrict build system access and enforce role-based permissions, MFA, and least privilege for build servers

PS.2

Provide a Mechanism for Verifying Software Release Integrity: Help software acquirers ensure that the software they acquire is legitimate and has not been tampered with. Make software integrity verification information available to software acquirers.

To satisfy SSDF PS.2 in a build and deploy context using open-source tools, the focus shifts to:

• Generate integrity artifacts for every release

• Bind artifacts to versioned source

• Publish verification materials

• Require integrity checks as a release gate

• Expose verification data to consumers

• Admission control based on integrity

PS.3

Archive and Protect Each Software Release: Preserve software releases in order to help identify, analyze, and eliminate vulnerabilities discovered in the software after release.

To satisfy SSDF PS.3 in a build and deploy context using open-source tools, the focus shifts to:

• Build: The emphasis is on capturing, storing, and securing every official release (source, binaries, SBOM, signatures, provenance) in immutable, versioned storage.

• Deploy: The emphasis is on ensuring only those archived, protected releases are used in production with immutability, digest pinning, and signature/provenance verification as enforcement mechanisms.

1.2.3 - Produce Well-Secured Software (PW)

Produce Well-Secured Software (PW) for Build and Deploy Tasks

Organizations should produce well-secured software with minimal security vulnerabilities in its releases.

PW.1

Design Software to Meet Security Requirements and Mitigate Security Risks: Identify and evaluate the security requirements for the software; determine what security risks the software is likely to face during operation and how the software’s design and architecture should mitigate those risks; and justify any cases where risk-based analysis indicates that security requirements should be relaxed or waived. Addressing security requirements and risks during software design (secure by design) is key for improving software security and also helps improve development efficiency.

To satisfy SSDF PW.1 in a build and deploy context using open-source tools, the focus shifts to:

• Embedding security controls directly into the build process

• Validating that build outputs (binaries, containers, packages) are hardened and free from known design-level weaknesses

• Preserving traceability from design requirements to deployed artifacts

PW.2

Review the Software Design to Verify Compliance with Security Requirements and Risk Information:Help ensure that the software will meet the security requirements and satisfactorily address the identified risk information.

To satisfy SSDF PW.2 in a the build and deploy context using open-source tools, the is:

• Validating security architecture decisions before deploying

• Reviewing IaC and CI/CD configs to ensure they meet security baselines

• Enforcing design rules automatically in build pipelines

• Catching misconfigurations and security gaps before release

PW.4

Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality : Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software by reusing software modules and services that have already had their security posture checked. This is particularly important for software that implements security functionality, such as cryptographic modules and protocols.

Note: PW.3 moved to PW.4

To satisfy SSDF PW.4 in a build and deploy context using open-source tools, the focus shifts to:

• Baking secure defaults into application code, containers, and deployment manifests

• Removing insecure, legacy, or unnecessary features from build artifacts

• Automatically applying baseline security settings during deployment

• Enforcing hardening standards before release

PW.5

Create Source Code by Adhering to Secure Coding Practices: Decrease the number of security vulnerabilities in the software, and reduce costs by minimizing vulnerabilities introduced during source code creation that meet or exceed organization-defined vulnerability severity criteria.

To satisfy SSDF PW.5 in a build and deploy context using open-source tools, the focus shifts to:

• Software artifacts are stored in secure, controlled repositories.

• Only approved, verified builds get stored and deployed.

• Repository access is restricted and auditable.

• Provenance and integrity checks are enforced before artifacts are accepted or deployed.

PW.6

Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security: Decrease the number of security vulnerabilities in the software and reduce costs by eliminating vulnerabilities before testing occurs.

To satisfy SSDF PW.6 in a build and deploy context using open-source tools, the focus shifts to make security testing continuous and automatic so every build and every deployment candidate is evaluated against a security bar, with evidence captured for audit and release gates.:

PW.7

Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements: Help identify vulnerabilities so that they can be corrected before the software is released to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities. Human-readable code includes source code, scripts, and any other form of code that an organization deems human readable.

To satisfy SSDF PW.7 in a build and deploy context using open-source tools, the focus shifts to:

• Running automated code scanning in CI

• Ensuring manual/peer review requirements are enforced before merging to release branches

• Verifying code matches security policies defined earlier in PW.1 and validated in PW.2- Capturing audit evidence that review was completed before build artifacts are promoted

PW.8

Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements: Help identify vulnerabilities so that they can be corrected before the software is released in order to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities and improves traceability and repeatability. Executable code includes binaries, directly executed bytecode and source code, and any other form of code that an organization deems executable.

To satisfy SSDF PW.8 in a post-deployment context using open-source tools, the focus shifts to:

• Running security tests against the final artifact in staging or pre-deployment environments

• Validating runtime configuration, dependencies, and permissions of the artifact

• Ensuring compliance with security baselines at the executable level

• Capturing evidence of artifact test results for compliance gates

PW.9

Configure Software to Have Secure Settings by Default: Help improve the security of the software at the time of installation to reduce the likelihood of the software being deployed with weak security settings, putting it at greater risk of compromise.

To satisfy SSDF PW.9 in a build and deploy context using open-source tools, the focus shifts to:

• Embedding secure configs into container images, binaries, and IaC

• Removing insecure or unused features before packaging

• Applying security baselines (CIS, STIG, NIST) in the build process

• Validating those defaults as part of CI/CD

• Preventing insecure defaults from slipping into release candidates

1.2.4 - Respond to Vulnerabilities (RV)

Respond to Vulnerabilities (RV) for Build and Deploy Tasks

Respond to Vulnerabilities (RV): Organizations should identify residual vulnerabilities in their software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.

RV.1

Identify and Confirm Vulnerabilities on an Ongoing Basis: Help ensure that vulnerabilities are identified more quickly so that they can be remediated more quickly in accordance with risk, reducing the window of opportunity for attackers.

To satisfy SSDF RV.1 in a build and deploy context using open-source tools, the focus shifts to continuously gathering vulnerability intel (VDP + public sources), monitor components, and confirm issues across supported releases.

RV.2

Assess, Prioritize, and Remediate Vulnerabilities: Help ensure that vulnerabilities are remediated in accordance with risk to reduce the window of opportunity for attackers.

To satisfy SSDF RV.2 in a build and deploy context using open-source tools, the focus shifts to:

• Recording each vulnerability

• Analyze risk (exploitability & impact)

• Choose responses, publish advisories, and deliver remediations via trusted mechanisms; include temporary mitigations where needed.\

RV.3

Analyze Vulnerabilities to Identify Their Root Causes: Help reduce the frequency of vulnerabilities in the future.

To satisfy SSDF RV.3 in a build and deploy context using open-source tools, the focus shifts to:

• Capturing root causes & lessons learned

• Detecting recurring patterns over time

1.3 - Post Deployment Tasks

Achieving Post Deploy Tasks of the Secure Software Development Framework

This chapter focuses specifically on DevSecOps tooling and practices related to Post Deploy actions of the CI/CD pipeline to achieve tasks defined by the Secure Software Development Framework.

The Secure Software Development Framework, developed by the National Institute of Standards and Technology (NIST), provides a comprehensive approach to ensuring security across the software development process, from initial design through deployment and maintenance. The framework outlines key practices and guidelines that organizations can implement to secure their software development lifecycle (SDLC), with a particular emphasis on integrating security into automated processes.

1.3.1 - Prepare the Organization (PO)

Prepare the Organization (PO) Post Deploy Tasks

Organizations should ensure that their people, processes, and technology are prepared to perform secure software development at the organization level. Many organizations will find some PO practices to also be applicable to subsets of their software development, like individual development groups or projects.

PO.1 Define Security Requirements for Software Development: Ensure that security requirements for software development are known at all times so that they can be taken into account throughout the SDLC and duplication of effort can be minimized because the requirements information can be collected once and shared. This includes requirements from internal sources (e.g., the organization’s policies, business objectives, and risk management strategy) and external sources (e.g., applicable laws and regulations).

To satisfy SSDF PO.1 in a post-deployment context using open-source tools, the focus shifts from just defining to:

• Maintaining and enforcing PO tasks in live systems.

• Making task requirements visible and traceable across deployed environments.

• Auditing and updating methods and procedures as internal and external policies change.

PO.2 Implement Roles and Responsibilities: Ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLC-related roles and responsibilities throughout the SDLC.

To satisfy SSDF PO.2 in a post-deployment context using open-source tools, the focus shifts to:

• Defining and assigning roles for who is responsible for remediation and runtime configurations.

• Maintaining evidence of what was deployed, who deployed it, and impact across all software assets.

• Ensuring security and patch management with restricted post-deployment actions.

PO.3 Implement Supporting Toolchains: Use automation to reduce human effort and improve the accuracy, reproducibility, usability, and comprehensiveness of security practices throughout the SDLC, as well as provide a way to document and demonstrate the use of these practices. Toolchains and tools may be used at different levels of the organization, such as organization-wide or project-specific, and may address a particular part of the SDLC, like a build pipeline.

To satisfy SSDF PO.3 in a post-deployment context using open-source tools, the focus shifts to:

• Ensuring toolchains support vulnerability detection, SBOM tracking, compliance, and policy enforcement to function after release.

• Keeping automation tooling secure, updated, and integrated with the live environment.

• Maintaining evidence that the toolchain’s outputs (e.g., SBOMs, scan reports) remain trustworthy and current.

PO.4 Define and Use Criteria for Software Security Checks: Help ensure that the software resulting from the SDLC meets the organization’s expectations by defining and using criteria for checking the software’s security during development.

To satisfy SSDF PO.4 in a post-deployment context using open-source tools, the focus shifts to:

• Ensuring that security data continues to be collected after release.

• Logs, SBOMs, and scan results are preserved and tamper-resistant.

• Data is safeguarded to prevent unauthorized access or modification.

• Data is retrievable for audits, investigations, and compliance checks

PO.5 Implement and Maintain Secure Environments for Software Development: Ensure that all components of the environments for software development are strongly protected from internal and external threats to prevent compromises of the environments or the software being developed or maintained within them. Examples of environments for software development include development, build, test, and distribution environments.

To satisfy SSDF PO.5 in a post-deployment context using open-source tools, the focus shifts to:

• The security requirements for your development infrastructure are still relevant and enforced after software is released.

• Your build, deployment, and monitoring environments remain hardened and compliant.

• You continuously validate that your development infrastructure hasn’t drifted from its secure baseline.

1.3.2 - Protect the Software (PS)

Protect the Software (PS) for Post Deploy Tasks

Protect the Software (PS): Organizations should protect all components of their software from tampering and unauthorized access.

PS.1

Protect All Forms of Code from Unauthorized Access and Tampering : Help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of the software. For code that is not intended to be publicly accessible, this helps prevent theft of the software and may make it more difficult or time-consuming for attackers to find vulnerabilities in the software.

To satisfy SSDF PS.1 in a post-deployment context using open-source tools, the focus shifts from just defining to:

• Protecting deployed artifacts (binaries, containers, scripts, configs) from being altered in production

• Ensuring post-deployment code integrity is verifiable at any time

• Maintaining secure storage, transport, and retrieval of code and artifacts

• Keeping an audit trail for all modifications and access

PS.2

Provide a Mechanism for Verifying Software Release Integrity: Help software acquirers ensure that the software they acquire is legitimate and has not been tampered with. Make software integrity verification information available to software acquirers.

To satisfy SSDF PS.2 in a post-deployment context using open-source tools, the focus shifts to:

• Keeping exact copies of every release artifact (binaries, containers, configs, SBOMs)

• Recording and publishing cryptographic verification data (signatures, hashes, attestations)

• Ensuring acquirers can confirm that what they have matches the trusted, official release

PS.3

Archive and Protect Each Software Release: Preserve software releases in order to help identify, analyze, and eliminate vulnerabilities discovered in the software after release.

To satisfy SSDF PS.3 in a post-deployment context using open-source tools, the focus shifts to:

• Keeping a tamper-proof record of every software component in each release

• Ensuring provenance data remains accessible for audits, investigations, and vulnerability response

• Allowing acquirers and downstream users to independently verify the origin and integrity of every component

1.3.3 - Produce Well-Secured Software (PW)

Produce Well-Secured Software (PW) for Post Deploy Tasks

Organizations should produce well-secured software with minimal security vulnerabilities in its releases.

PW.1

Design Software to Meet Security Requirements and Mitigate Security Risks: Identify and evaluate the security requirements for the software; determine what security risks the software is likely to face during operation and how the software’s design and architecture should mitigate those risks; and justify any cases where risk-based analysis indicates that security requirements should be relaxed or waived. Addressing security requirements and risks during software design (secure by design) is key for improving software security and also helps improve development efficiency.

To satisfy SSDF PW.1 in a post-deployment context using open-source tools, the focus shifts to:

• Keeping a tamper-proof record of every software component in each release

• Ensuring provenance data remains accessible for audits, investigations, and vulnerability response

• Allowing acquirers and downstream users to independently verify the origin and integrity of every component

PW.2

Review the Software Design to Verify Compliance with Security Requirements and Risk Information:Help ensure that the software will meet the security requirements and satisfactorily address the identified risk information.

To satisfy SSDF PW.2 in a post-deployment context using open-source tools, the focus shifts to:

• Continuous verification that deployed code (source or binary) hasn’t been tampered with.

• Ongoing vulnerability assessment of deployed applications and components.

• Post-release code review triggers when a vulnerability or incident is detected.

• Auditable evidence that deployed software matches approved, reviewed code.

PW.4

Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality : Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software by reusing software modules and services that have already had their security posture checked. This is particularly important for software that implements security functionality, such as cryptographic modules and protocols.

Note: PW.3 moved to PW.4

To satisfy SSDF PW.4 in a post-deployment context using open-source tools, the focus shifts to:

• Vulnerability detection runs continuously on production or production-equivalent environments.

• Results are triaged and assigned quickly.

• There is an automated or semi-automated path to remediation (e.g., patching, image rebuild, or component upgrade).

• All activity is auditable and linked to release artifacts.

PW.5

Create Source Code by Adhering to Secure Coding Practices: Decrease the number of security vulnerabilities in the software, and reduce costs by minimizing vulnerabilities introduced during source code creation that meet or exceed organization-defined vulnerability severity criteria.

To satisfy SSDF PW.5 in a post-deployment context using open-source tools, the focus shifts to:

• Ongoing verification of integrity, compliance, and security posture for deployed software.

• Continuous checks to ensure that the running software still meets the security requirements it had at release.

• Detecting drift, newly introduced vulnerabilities, and configuration changes.

• Maintaining verifiable evidence of these checks over time.

PW.6

Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security: Decrease the number of security vulnerabilities in the software and reduce costs by eliminating vulnerabilities before testing occurs.

To satisfy SSDF PW.6 in a post-deployment context using open-source tools, the focus shifts to:

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

• Maintain SBOMs for deployed software; monitor for new CVEs.

• Score findings (CVSS, EPSS); prioritize fixes based on severity & exploitability.

• Auto-rebuild/redeploy when patched images are available.

PW.7

Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements: Help identify vulnerabilities so that they can be corrected before the software is released to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities. Human-readable code includes source code, scripts, and any other form of code that an organization deems human readable.

To satisfy SSDF PW.7 in a post-deployment context using open-source tools, the focus shifts to:

• Maintain a record showing that the deployed version went through the organization’s required code review and/or automated analysis process.

• Ensure all emergency/hotfix patches pushed post-deployment are also reviewed or analyzed — even if done after release.

• Maintain Audit-Ready Evidence

PW.8

Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements: Help identify vulnerabilities so that they can be corrected before the software is released in order to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities and improves traceability and repeatability. Executable code includes binaries, directly executed bytecode and source code, and any other form of code that an organization deems executable.

To satisfy SSDF PW.8 in a post-deployment context using open-source tools, the focus shifts to:

• Continuously Test Deployed Executables for Vulnerabilities

• Verify Compliance with Security Requirements

• Feed Findings Back into Development

PW.9

Configure Software to Have Secure Settings by Default: Help improve the security of the software at the time of installation to reduce the likelihood of the software being deployed with weak security settings, putting it at greater risk of compromise.

To satisfy SSDF PW.9 in a post-deployment context using open-source tools, the focus shifts to:

• Check deployed software and infrastructure against the organization’s secure configuration baseline (e.g., NIST 800-53, CIS Benchmarks, DISA STIGs).

• Use policy-as-code and configuration management tools to keep deployed systems in compliance.

• Integrate configuration checks into runtime monitoring

1.3.4 - Respond to Vulnerabilities (RV)

Respond to Vulnerabilities (RV) Post Deploy Tasks

Respond to Vulnerabilities (RV): Organizations should identify residual vulnerabilities in their software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.

RV.1

Identify and Confirm Vulnerabilities on an Ongoing Basis: Help ensure that vulnerabilities are identified more quickly so that they can be remediated more quickly in accordance with risk, reducing the window of opportunity for attackers.

To satisfy SSDF RV.1 in a post-deployment context using open-source tools, the focus shifts to:

• Continuously scanning live environments for new vulnerabilities

• Correlating detected vulnerabilities to deployed components and SBOM data

• Validating whether vulnerabilities are exploitable in the specific environment

• Prioritizing remediation based on severity, exploitability, and operational impact

RV.2

Assess, Prioritize, and Remediate Vulnerabilities: Help ensure that vulnerabilities are remediated in accordance with risk to reduce the window of opportunity for attackers.

To satisfy SSDF RV.2 in a post-deployment context using open-source tools, the focus shifts to:

• Determining which vulnerabilities matter most in the deployed context

• Using exploitability, business impact, and compliance requirements for prioritization

• Executing timely remediation or mitigation actions in live environments

• Tracking remediation status to closure with audit-ready records

RV.3

Analyze Vulnerabilities to Identify Their Root Causes: Help reduce the frequency of vulnerabilities in the future.

To satisfy SSDF RV.3 in a post-deployment context using open-source tools, the focus shifts to:

• Determining whether it originated in coding, dependencies, build processes, or deployment configurations

• Documenting lessons learned to prevent recurrence

• Feeding analysis results back into security requirements, pipelines, and developer training

2 -

The Cyber Reslience Act (CRA) - Overview

The European Union Cyber Resilience Act (CRA) is a regulation designed to strengthen the cybersecurity of products with digital elements throughout their entire lifecycle. It establishes mandatory cybersecurity requirements for manufacturers, including secure-by-design development, cybersecurity risk assessments, software component transparency, vulnerability management, security updates, and coordinated vulnerability disclosure. Unlike traditional security practices that focus primarily on development and release, the CRA emphasizes continuous security after deployment, requiring manufacturers to identify, assess, and remediate vulnerabilities throughout a product’s support period. The regulation also establishes requirements for reporting actively exploited vulnerabilities and severe security incidents. For DevOps and platform engineering teams, the CRA reinforces the need to integrate cybersecurity practices across the entire CI/CD lifecycle—from Code and Prebuild through Build and Deploy to Post Deployment—while maintaining the evidence necessary to demonstrate compliance.

The CRA requirements which are addressed by this guide are principally found in Article 13, Article 14, Annex I Part I, Annex I Part II, and Annex VII. These requirements span several phases, so the mapping below assigns each activity to its primary implementation point.

Phase 1 — Code and Prebuild

Objective: Prevent cybersecurity risks from being introduced during product planning, design, coding, and dependency selection. The CRA requires manufacturers to assess cybersecurity risks throughout the product lifecycle and design products with security appropriate to those risks. For DevOps teams, Phase 1 converts these requirements into development policies, threat modeling, dependency governance, secure coding practices, and vulnerability disclosure procedures.

Phase 2 - Build and Deploy

Objective: Produce, validate, and distribute software releases that meet the product’s applicable cybersecurity requirements. Phase 2 ensures that security requirements established during development are verified before a software release is made available. The CRA requires products to meet applicable security requirements, including the absence of known exploitable vulnerabilities when placed on the market, subject to the product risk assessment and regulatory provisions.

Post Deployment

Objective: Continuously identify and address vulnerabilities, maintain security throughout the support period, and provide required disclosures and incident notifications. This phase deserves particular attention. The CRA does not treat security as complete when a software release passes its build-time checks. Manufacturers must operate vulnerability handling processes throughout the applicable support period, including handling vulnerabilities in third-party components and making security updates available.

2.1 - Code and Prebuild Tasks

Achieving Code and Prebuild Tasks of the Cyber Resilence Act

The European Union Cyber Resilience Act (CRA) establishes cybersecurity requirements for products with digital elements throughout their lifecycle. During Code and Prebuild, organizations should incorporate cybersecurity risk assessments, secure-by-design principles, third-party dependency reviews, and vulnerability disclosure planning into their software development practices.

This phase focuses on preventing security vulnerabilities before software enters the build pipeline. By integrating CRA-aligned practices into developer workflows, organizations can identify risks earlier, reduce dependency exposure, and establish the processes needed to maintain product security after deployment.

The following activities map CRA requirements to actionable CI/CD practices and suggested open-source tools. The tools are illustrative and are not mandated by the regulation.

2.1.1 - Security Risk Assessment - Code and Prebuild

CRA Security Risk Assessment - Phase 1: Code and Prebuild

The European Union Cyber Resilience Act (CRA) establishes cybersecurity requirements for products with digital elements throughout their lifecycle. During Code and Prebuild, organizations should incorporate cybersecurity risk assessments, secure-by-design principles, third-party dependency reviews, and vulnerability disclosure planning into their software development practices.

This phase focuses on preventing security vulnerabilities before software enters the build pipeline. By integrating CRA-aligned practices into developer workflows, organizations can identify risks earlier, reduce dependency exposure, and establish the processes needed to maintain product security after deployment.

The following activities map CRA requirements to actionable CI/CD practices and suggested open-source tools. The tools are illustrative and are not mandated by the regulation.

CRA Security Risk Assessment

Objective: Identify, evaluate, and document cybersecurity risks before software development and throughout the product lifecycle.

Article 13 requires manufacturers to perform cybersecurity risk assessments that consider the intended purpose, reasonably foreseeable use, operational environment, and expected lifetime of products with digital elements. These assessments inform the selection of appropriate cybersecurity controls and must be documented and updated as appropriate during the product’s support period.

For DevOps teams, risk assessments should be integrated into application planning, architecture reviews, and development workflows. Threat modeling can help identify potential attack vectors, vulnerable components, insecure configurations, and risks introduced by software dependencies. Identified risks should be tracked as development tasks, with appropriate mitigation strategies and documented decisions.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Documented cybersecurity risk assessments.
• Threat models and architectural security reviews.
• Security requirements derived from identified risks.
• Risk mitigation decisions and assigned responsibilities.
• Records of risk assessment updates.

2.1.2 - Secure-by-Design Requirements - Code and Prebuild

Secure-by-Design Requirements - Phase 1: Code and Prebuild

Objective: Integrate security requirements directly into software architecture, coding practices, and configuration management.

The CRA establishes essential cybersecurity requirements designed to reduce vulnerabilities and ensure products provide an appropriate level of security. These include secure default configurations, protection against unauthorized access, data confidentiality and integrity, minimization of attack surfaces, and mechanisms for addressing vulnerabilities through security updates.

During Code and Prebuild, development teams should define security requirements before implementation and incorporate automated security checks into developer workflows. Secure coding practices, static application security testing (SAST), secret detection, and policy validation help identify potential weaknesses before software is committed or promoted to the build pipeline.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Secure coding standards and development policies.
• Application security architecture documentation.
• Static analysis and secrets scanning results.
• Configuration policy definitions and validation results.
• Security-focused code review records.
• Documented security update design requirements.

2.1.3 - Third-Party Dependency Due Diligence - Code and Prebuild

Third-Party Dependency Due Diligence - Phase 1: Code and Prebuild

Objective: Reduce software supply chain risks by evaluating open-source and commercial dependencies before they are incorporated into products.

Article 13(5) requires manufacturers to exercise due diligence when integrating third-party components, including free and open-source software, to ensure those components do not compromise product cybersecurity.

For DevOps teams, this means establishing dependency governance practices that evaluate known vulnerabilities, project maintenance, security practices, and dependency provenance before adding new libraries, frameworks, or packages.

Dependency inventories should be maintained throughout development and should provide the foundation for generating a machine-readable Software Bill of Materials (SBOM) during the build process. Automated scanning can identify known vulnerabilities, while project security assessments can help teams understand risks associated with open-source components.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Approved dependency inventories.
• Third-party component security assessments.
• Open-source project risk evaluations.
• Dependency vulnerability scanning results.
• Dependency upgrade and remediation records.
• Documented component selection and exception decisions.

2.1.4 - Vulnerability Disclousres Preperation - Code and Prebuild

Vulnerability Disclosure Preparation - Phase 1: Code and Prebuild

Objective: Establish processes for receiving, evaluating, coordinating, and responding to vulnerability reports before a product is released.

The CRA requires manufacturers to establish and enforce coordinated vulnerability disclosure policies and provide mechanisms for reporting potential vulnerabilities in their products and included third-party components.

During Code and Prebuild, organizations should define how security researchers, customers, developers, and external contributors can report vulnerabilities. These processes should include a published security contact, confidential reporting channels, vulnerability triage procedures, and clear responsibilities for investigation and remediation.

For DevOps teams, disclosure preparation should integrate with development issue tracking, dependency management, and security response workflows. Establishing these processes early ensures that vulnerabilities discovered after deployment can be evaluated, assigned, and addressed efficiently.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Published coordinated vulnerability disclosure policy.
• Documented vulnerability reporting contact and channels.
• Vulnerability triage and response procedures.
• Defined vulnerability remediation responsibilities.
• Security advisory templates and disclosure workflows.
• Regulatory incident escalation and reporting procedures.

2.1.5 - Compliance Evidence Summary - Code and Prebuild

Compliance Evidence Summary - Phase 1: Code and Prebuild

Code and Prebuild activities should establish a documented foundation for cybersecurity risk management and secure software development.

Organizations should retain evidence demonstrating that product risks, security requirements, third-party dependencies, and vulnerability disclosure processes were addressed before software entered the build pipeline.

These records should be maintained and updated as appropriate throughout the product lifecycle and should support the technical documentation and vulnerability handling obligations established by the CRA.

References

• EU Cyber Resilience Act — Regulation (EU) 2024/2847
• European Commission — Cyber Resilience Act Summary
• NIST Secure Software Development Framework

Implementation Note: The CRA establishes legal obligations for covered products and economic operators. The open-source tools listed above are examples of possible engineering implementations. Their use does not independently demonstrate CRA compliance, and individual security controls should be selected according to the documented product cybersecurity risk assessment.

2.2 - Build and Deploy Tasks

Achieving Build and Deploy Tasks of the The Cyber Reslience Act

The European Union Cyber Resilience Act (CRA) establishes cybersecurity requirements for products with digital elements throughout their lifecycle. During Build and Deploy, organizations should validate product security, generate and maintain Software Bills of Materials (SBOMs), protect software artifact integrity, and collect the technical evidence necessary to demonstrate compliance.

This phase focuses on ensuring that software releases satisfy applicable cybersecurity requirements before they are distributed or placed on the market. By integrating security testing, vulnerability scanning, SBOM generation, artifact verification, and evidence collection into CI/CD workflows, organizations can identify security weaknesses, prevent the release of insecure artifacts, and establish traceability between source code, builds, releases, and deployed products.

The following activities map CRA requirements to actionable CI/CD practices and suggested open-source tools. The tools are illustrative and are not mandated by the regulation.

2.2.1 - Artifact Integrity and Secure Distribution - Build and Deploy

Artifact Integrity and Secure Distribution - Phase 2: Build and Deploy

Objective: Protect software artifacts against unauthorized modification and establish secure mechanisms for distributing products and security updates.

The CRA requires manufacturers to protect the integrity of products with digital elements and provide mechanisms for securely distributing security updates. These requirements help ensure that software received by users has not been tampered with and that product updates can be delivered securely.

During Build and Deploy, DevOps teams should establish controls that verify the authenticity and integrity of software artifacts as they move through build pipelines, artifact repositories, distribution channels, and deployment environments.

Artifact signing, cryptographic verification, software supply chain attestations, and deployment policy enforcement can support these objectives. Organizations should also validate that security updates can be delivered reliably and that update mechanisms protect against unauthorized modifications.

Although the CRA does not mandate specific artifact signing or provenance technologies, these practices can provide supporting evidence of software integrity and secure distribution controls.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Signed software artifacts and verification records.
• Build provenance and software supply chain attestations.
• Artifact repository access and integrity records.
• Secure update validation and distribution test results.
• Deployment policy enforcement logs.
• Release version and artifact traceability information.
• Documented software update and rollback procedures.

2.2.2 - Release Security Validation - Build and Deploy

CRA Release Security Validation - Phase 2: Build and Deploy

Objective: Verify that software releases satisfy applicable cybersecurity requirements and that known exploitable vulnerabilities are addressed before release.

The CRA requires manufacturers to ensure that products with digital elements meet essential cybersecurity requirements appropriate to their intended purpose and documented cybersecurity risk assessment. These requirements include making products available without known exploitable vulnerabilities, providing secure default configurations, protecting against unauthorized access, and maintaining product integrity and availability.

During Build and Deploy, DevOps teams should integrate automated security testing and vulnerability scanning into CI/CD pipelines. Release security gates should evaluate identified vulnerabilities, validate security configurations, and verify that software meets established security requirements before artifacts are promoted to production or distribution environments.

Security validation should include documented decisions regarding identified vulnerabilities, remediation outcomes, and any remaining risks requiring further evaluation.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Software vulnerability scanning reports.
• Static and dynamic application security testing results.
• Security configuration validation results.
• Identified vulnerability remediation records.
• Release security approval decisions.
• Documented security exceptions and supporting risk assessments.
• CI/CD security gate execution logs.

2.2.3 - SBOM Genearation and Management - Build and Deploy

SBOM Genearation and Management - Phase 2: Build and Deploy

Objective: Establish software component transparency by generating, validating, and maintaining machine-readable Software Bills of Materials.

The CRA requires manufacturers to identify and document vulnerabilities and components contained in their products, including by creating a Software Bill of Materials (SBOM) in a commonly used, machine-readable format covering at least the product’s top-level dependencies.

For DevOps teams, SBOM generation should be integrated into automated build processes. SBOMs should identify software components and dependencies associated with each release and provide a foundation for vulnerability assessment, dependency tracking, and future security updates.

Organizations should maintain version-specific SBOMs and associate them with corresponding build artifacts, release identifiers, and product versions. While the CRA establishes minimum SBOM requirements, including transitive dependencies and retaining deployment associations can improve vulnerability impact analysis and remediation efficiency.

SBOMs should be stored securely, maintained as appropriate throughout the product support period, and made available to competent authorities when legally required.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Machine-readable SBOMs associated with product releases.
• Software component and dependency inventories.
• SBOM generation and validation records.
• Component vulnerability assessment reports.
• Product version and SBOM traceability records.
• Documented SBOM retention and access procedures.
• Third-party component identification records.

2.2.4 - Technical Documenatation and Evidence - Build and Deploy

Technical Documenatation and Evidence - Phase 2: Build and Deploy

Objective: Maintain the technical records and supporting security evidence needed to demonstrate conformity with applicable CRA requirements.

The CRA requires manufacturers to prepare technical documentation before placing covered products with digital elements on the EU market. This documentation must demonstrate how the product and its associated vulnerability handling processes satisfy applicable essential cybersecurity requirements.

Article 31 and Annex VII establish requirements for technical documentation, including product descriptions, software architecture, cybersecurity risk assessments, vulnerability handling procedures, security testing results, and relevant conformity information.

During Build and Deploy, CI/CD pipelines can automate the collection of evidence generated throughout development and release processes. Security scan results, SBOMs, build attestations, test reports, and release metadata can be associated with specific product versions to establish an auditable record of security activities.

This evidence supports the manufacturer’s conformity assessment obligations, but automated evidence generation does not independently establish CRA conformity. Manufacturers must complete the applicable assessment procedures, prepare the EU declaration of conformity, and affix CE marking when required.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Product technical documentation and architecture descriptions.
• Version-specific SBOMs and software inventories.
• Cybersecurity risk assessment documentation.
• Security testing and vulnerability scanning reports.
• Artifact integrity and build provenance records.
• Vulnerability handling and secure update procedures.
• Records of applied cybersecurity standards and specifications.
• EU declaration of conformity and applicable conformity assessment records.
• Documentation maintenance and retention policies.

Compliance Evidence Summary

Build and Deploy activities should establish a verifiable record demonstrating that cybersecurity requirements were evaluated and appropriate security controls were applied before a product was distributed or placed on the market.

Organizations should integrate evidence generation into their CI/CD pipelines wherever practical, linking security validation results, SBOMs, signed artifacts, and technical documentation to specific product versions and releases.

These records should support vulnerability management throughout the product support period, enable investigation of newly discovered security issues, and provide traceable documentation for applicable CRA conformity assessment requirements.

References

• EU Cyber Resilience Act — Regulation (EU) 2024/2847
• European Commission — Cyber Resilience Act Summary
• NIST Secure Software Development Framework
• OpenSSF Supply Chain Integrity

Implementation Note: The CRA establishes legal obligations for manufacturers and other covered economic operators. The suggested tools represent possible technical implementations and supporting evidence-generation mechanisms. They are not individually mandated by the CRA, and their use alone does not establish regulatory conformity.

2.3 - Post Deployment Tasks

Achieving Post Deploy Tasks of the Secure Software Development Framework

The European Union Cyber Resilience Act (CRA) establishes cybersecurity obligations that extend beyond software development and initial release. Manufacturers of covered products with digital elements must maintain processes for identifying, evaluating, and addressing vulnerabilities throughout the applicable product support period. These responsibilities include monitoring software components for newly disclosed vulnerabilities, determining which products are affected, distributing security updates, and coordinating vulnerability disclosures.

During Post Deployment, organizations must be prepared to respond to vulnerabilities discovered after software has been released. A software component that was considered secure during development may become vulnerable when a new Common Vulnerabilities and Exposures (CVE) record is published. Build-time scanning alone cannot identify every future vulnerability.

For DevOps and platform engineering teams, continuous vulnerability management should extend the CI/CD pipeline into operational environments. By correlating software component inventories, SBOMs, product versions, and deployment records with emerging vulnerability intelligence, organizations can identify affected products, prioritize remediation, and maintain evidence demonstrating ongoing security activities.

The following sections map CRA requirements to actionable Post Deployment practices and suggested open-source tooling. The tools are illustrative and are not mandated by the regulation.

2.3.1 - Affected-Product Identification - Post Deployment

Affected-Product Identification - Phase 3: Post Deployment

Objective: Identify which released products, software versions, and operational deployments are affected when new vulnerabilities are disclosed.

The CRA requires manufacturers to identify and document vulnerabilities and components contained in their products and to assess vulnerabilities according to the risks they pose. Effective vulnerability handling depends on understanding which products contain affected components and whether those components introduce exploitable security risks.

For DevOps teams, this requires establishing traceability between software components, SBOMs, product versions, release artifacts, and the environments where software is deployed.

An SBOM identifies the components contained in a software product or release, but an SBOM alone does not necessarily identify where affected software is currently running. Correlating component inventories with release and deployment metadata provides additional visibility into the operational impact of newly disclosed vulnerabilities.

This process, commonly referred to as vulnerability impact analysis or blast-radius assessment, helps organizations distinguish vulnerabilities affecting actively deployed products from vulnerabilities associated with obsolete or unused releases.

Where deployment information is available, teams can associate affected products with specific environments, endpoints, applications, and responsible owners. This supports faster investigation, targeted remediation, and improved communication with affected users.

While the CRA does not explicitly mandate endpoint-level deployment mapping, this capability can strengthen vulnerability handling and provide supporting evidence of product-specific risk assessment.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Component-to-product vulnerability mappings.
• Product and release version inventories.
• SBOM-to-release associations.
• Available deployment and endpoint inventory records.
• Affected-product and vulnerability impact assessments.
• Product-specific vulnerability status statements.
• Assigned remediation ownership and tracking records.
• Documented decisions concerning product exposure and exploitability.

2.3.2 - Remediation and Security Update - Post Deployment

Remediation and Security Update - Phase 3: Post Deployment

Objective: Address identified vulnerabilities without delay and securely distribute appropriate security updates to affected products.

The CRA requires manufacturers to address and remediate vulnerabilities in relation to the risks they pose to their products. Remediation may involve updating vulnerable dependencies, modifying application code, applying configuration changes, replacing affected components, or implementing other appropriate mitigation measures.

Where technically feasible, security updates must be provided separately from functionality updates. The CRA also establishes requirements for securely distributing security updates and making them available without delay and, subject to specified exceptions, free of charge.

For DevOps teams, vulnerability remediation should connect Post Deployment monitoring with development and build workflows. When a vulnerability is identified, teams should evaluate available fixes, determine compatibility with affected products, create remediation changes, and validate those changes through automated build and security testing.

Remediation workflows should support dependency upgrades, application changes, regression testing, release approval, and controlled deployment of security updates.

Where applicable, organizations should maintain records demonstrating that fixes were developed, tested, released, and communicated to affected users. Deployment verification provides additional operational assurance that updated software has reached the intended environments.

Automating these workflows can reduce remediation delays while maintaining required security reviews and release authorization controls.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Vulnerability remediation records and assigned responsibilities.
• Dependency upgrade and application modification history.
• Security update build and test results.
• Documented remediation risk assessments.
• Security update release and distribution records.
• Signed update artifacts and integrity verification results.
• User notification and security advisory records.
• Product version and deployment verification records.
• Security update availability and retention records.
• Documented mitigation decisions for vulnerabilities that cannot be immediately patched.

2.3.3 - Continuous Vulernability Management - Post Deployment

Continuous Vulernability Management - Phase 3: Post Deployment

Objective: Continuously identify, assess, and track newly discovered vulnerabilities affecting released software throughout the product support period.

The CRA requires manufacturers to maintain effective vulnerability handling processes and address cybersecurity risks associated with their products and integrated components. These responsibilities extend throughout the applicable product support period and include regularly reviewing product security, identifying newly disclosed vulnerabilities, and taking appropriate remediation measures.

For DevOps teams, continuous vulnerability management requires maintaining visibility into software components after release. SBOMs generated during Build and Deploy should be retained and monitored against evolving vulnerability intelligence from sources such as the National Vulnerability Database (NVD), OSV, and other security advisory databases.

When new vulnerabilities are identified, organizations should determine whether affected components are included in supported product versions, evaluate their potential exploitability and impact, and assign remediation activities to responsible teams.

Automated vulnerability correlation, risk-based prioritization, and integration with development issue tracking can help reduce the time between vulnerability disclosure and remediation.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Maintained product SBOMs and component inventories.
• Continuous vulnerability monitoring records.
• Newly identified vulnerability assessment reports.
• Product-specific vulnerability risk and exploitability determinations.
• Vulnerability remediation assignments and tracking history.
• Periodic security test and review results.
• Evidence of vulnerability handling activities throughout the product support period.

2.3.4 - Vulnerability Disclosure and Regulatory Reporting - Post Deployment

Vulnerability Disclosure and Regulatory Reporting - Phase 3: Post Deployment

Objective: Establish processes for coordinated vulnerability disclosure, communicate security information to affected users, and satisfy applicable CRA regulatory reporting obligations.

The CRA requires manufacturers to maintain coordinated vulnerability disclosure processes and provide mechanisms through which security researchers, customers, and other parties can report potential product vulnerabilities.

Manufacturers must also disclose appropriate information about fixed vulnerabilities once a security update becomes available, subject to the regulation’s provisions concerning disclosure timing and security risks. Such information includes affected products, vulnerability impact and severity, and actions users can take to remediate the issue.

In addition, Article 14 establishes mandatory regulatory reporting obligations for qualifying actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.

These reporting requirements have applied to manufacturers since September 11, 2026. They require early warning notifications within 24 hours of awareness, followed by more detailed notifications within 72 hours. Final reporting deadlines vary depending on whether the report concerns an actively exploited vulnerability or a severe security incident.

For DevOps and security operations teams, disclosure and reporting processes should integrate vulnerability intelligence, incident investigation, affected-product identification, remediation tracking, and communication workflows.

Organizations should establish procedures for determining whether a vulnerability meets the CRA’s regulatory reporting criteria, collecting required information, and submitting notifications through the designated reporting mechanisms.

Not every newly disclosed CVE triggers regulatory reporting. Article 14 applies to the specific categories of reportable vulnerabilities and incidents defined by the regulation.

CRA Requirements and Open-Source Tooling

CRA Regulatory Reporting Deadlines

The following timelines apply to qualifying actively exploited vulnerabilities and severe security incidents under Article 14.

Mandatory notifications are submitted through the ENISA CRA Single Reporting Platform.

Reporting deadlines are triggered by awareness of qualifying events, rather than the publication of every CVE.

Expected Compliance Evidence

• Published coordinated vulnerability disclosure policy.
• Documented vulnerability reporting contacts and channels.
• Vulnerability reports and investigation records.
• Published security advisories and disclosure history.
• Affected-product identification and impact assessments.
• Reportability assessments for actively exploited vulnerabilities and severe incidents.
• Regulatory notification timestamps and submission records.
• Security incident investigation and root-cause analysis records.
• Remediation decisions and corrective action records.
• User notification and security update communication records.

Phase 3 Compliance Evidence Summary

Post Deployment activities should establish a continuous and traceable process for identifying vulnerabilities, determining affected products, implementing remediation, and communicating security information throughout the product support period.

Organizations should integrate SBOM monitoring, vulnerability intelligence, release inventories, and available deployment records to maintain visibility into software security after release.

When vulnerabilities are discovered, teams should document their relevance to supported products, assess exploitability and impact, assign remediation responsibilities, and preserve records of corrective actions.

Where practical, correlating vulnerable components with deployed product versions and operational endpoints can improve remediation prioritization and reduce the time required to identify affected environments.

For qualifying actively exploited vulnerabilities and severe security incidents, organizations must also maintain procedures capable of supporting statutory CRA reporting deadlines.

The resulting evidence should demonstrate that vulnerability handling is an ongoing operational process rather than a one-time activity performed during software development or release.

References

• EU Cyber Resilience Act — Regulation (EU) 2024/2847
• European Commission — Cyber Resilience Act Summary
• European Commission — CRA Reporting Obligations
• ENISA — CRA Single Reporting Platform
• NIST Secure Software Development Framework

Implementation Note: The CRA establishes obligations for covered manufacturers and, where applicable, other economic operators and open-source software stewards. The open-source tools listed are illustrative technica

3 -

AI Security in the CI/CD Pipeline - Overview

Artificial intelligence (AI) is transforming how software is designed, developed, tested, deployed, and maintained. AI coding assistants generate application code, autonomous agents modify repositories and dependencies, and AI models are increasingly integrated into production applications. While these capabilities accelerate software delivery, they introduce new cybersecurity risks that traditional CI/CD security practices may not fully address. These include vulnerable AI-generated code, excessive agent permissions, prompt injection, compromised AI models, sensitive information exposure, and unauthorized automated actions.

Securing AI requires extending established DevSecOps practices to address both software developed using AI and AI-powered applications deployed into production. AI-generated code must be validated, autonomous agents must operate within controlled security boundaries, AI models and dependencies must be verified, and deployed AI applications must be continuously monitored for emerging threats. For DevOps and platform engineering teams, AI security reinforces the need to integrate cybersecurity controls across the entire CI/CD lifecycle—from Code and Prebuild through Build and Deploy to Post Deployment—while maintaining security evidence, traceability, and appropriate human oversight.

Related Security Frameworks

The following frameworks provide guidance relevant to AI security activities.

These references provide security guidance for AI-assisted development and AI applications. They do not all establish mandatory compliance requirements.

This guide maps AI security activities to three primary phases of the CI/CD pipeline, identifying practical security controls and open-source tooling that can support their implementation. These phases are:

3.1 - Code and Prebuild

Securing AI-Assisted Development and AI Application Design

Artificial intelligence is changing how software is designed and developed. AI coding assistants generate application code, autonomous agents modify repositories and dependencies, and AI models are increasingly incorporated into software applications. While these capabilities accelerate development, they introduce security risks that traditional development practices may not fully address.

Phase 1: Code and Prebuild focuses on establishing security controls before code, AI models, prompts, datasets, or autonomous agents enter the CI/CD delivery pipeline.

This phase extends established secure development practices to address AI-generated code, agent permissions, AI application threat modeling, model and data supply chain security, and the protection of AI configurations.

The objective is to identify and reduce security risks early in the software development lifecycle, before vulnerabilities or unsafe configurations are introduced into build and deployment processes.

Code and Prebuild Outcomes

By implementing these practices, development teams establish a security foundation for AI-assisted software development and AI application design.

Expected outcomes include:

• AI-generated code is subject to established secure development practices.
• Autonomous development agents operate with controlled identities and permissions.
• AI-specific application threats are identified before implementation.
• AI models, datasets, and dependencies are evaluated for security and provenance.
• Prompts, agent instructions, and configurations are protected through version control and review.
• Security requirements are documented for validation during build and deployment.

These outcomes prepare development artifacts for the automated security validation activities described in Phase 2: Build and Deploy.

Why AI Security Begins Before the Build

Traditional secure development practices focus on source code quality, dependency management, secrets protection, and secure application design. AI-assisted development introduces additional considerations. This phase will cover:

3.1.1 - AI-Assisted Code Development

AI-Assisted Code Development - Code and Prebuild

Securing AI-Generated Code During Software Development

Artificial intelligence is increasingly used to generate application code, recommend dependencies, create configuration files, and automate software development tasks. While AI-assisted development can accelerate delivery, generated code may introduce security vulnerabilities, insecure coding patterns, outdated dependencies, exposed credentials, or licensing concerns.

During Code and Prebuild, organizations should apply established secure development practices to all AI-generated code and changes. AI coding assistants and autonomous development agents should operate within defined security boundaries, and their output should be subject to the same security requirements as human-written code.

This activity focuses on identifying and preventing security vulnerabilities before AI-generated changes enter trusted source code repositories or proceed through the CI/CD build pipeline.

The following activities map NIST Secure Software Development Framework (SSDF), the AI SSDF Profile (NIST SP 800-218A), and OWASP security guidance to actionable CI/CD practices and suggested open-source tools. The tools are illustrative and are not mandated by these frameworks.

AI-Assisted Code Development

Objective: Ensure AI-generated code is reviewed, tested, and validated for security vulnerabilities, unsafe dependencies, exposed secrets, and licensing risks before being incorporated into the software delivery pipeline.

The NIST Secure Software Development Framework (SSDF) establishes secure coding, code review, vulnerability analysis, and software verification practices that apply to both human-written and AI-generated software.

NIST SP 800-218A, the AI SSDF Profile, extends these practices to address additional security considerations associated with AI development.

AI-generated code should not be treated as inherently secure or trusted simply because it was produced by an automated system. Development teams remain responsible for verifying that generated code meets their security requirements.

For DevOps teams, AI-generated changes should be incorporated into existing source code management, peer review, static analysis, dependency scanning, and vulnerability management workflows. Automated security checks should identify potential weaknesses before code is merged, while policies should prevent AI agents from bypassing required reviews or security gates.

Particular attention should be given to generated dependencies, insecure API usage, authentication and authorization logic, secrets handling, and changes to security-sensitive configurations.

AI-assisted development should accelerate coding activities without weakening established secure software development controls.

AI Security Requirements and Open-Source Tooling

Framework references identify relevant security practices. Tool selection and implementation depend on the organization’s development environment and security requirements.

Expected Security Evidence

• Documented secure coding requirements applicable to AI-generated code.
• Records of code reviews and approvals for AI-generated changes.
• Static application security testing results.
• Dependency vulnerability scanning reports.
• Secrets detection results and remediation records.
• Automated test execution and validation results.
• Software component inventories identifying introduced dependencies.
• License analysis reports for applicable third-party software.
• Records of security policy enforcement and rejected changes.
• Traceable pull requests linking generated changes to review and validation outcomes.

These artifacts provide evidence that AI-assisted development follows established secure software development practices and that generated code is evaluated before entering the build and deployment process.

Security findings identified during Phase 1 should be resolved or appropriately documented before the affected changes proceed to Phase 2: Build and Deploy.

Additional Resources

• NIST Secure Software Development Framework (SP 800-218)
• NIST AI SSDF Profile (SP 800-218A)
• OWASP Top 10 for LLM Applications
• OpenSSF Best Practices
• OpenSSF Security Tooling

3.1.2 - AI Agent Identity and Permissions

AI Agent Identity and Permissions - Phase 1: Code and Prebuild

Artificial intelligence agents are increasingly used to generate code, modify repositories, update dependencies, execute commands, and automate software development activities. Unlike traditional coding assistants, autonomous agents may perform actions directly within development environments and interact with external tools and services.

These capabilities introduce security risks when agents are granted excessive permissions, unrestricted tool access, or credentials that provide access to sensitive resources.

During Code and Prebuild, organizations should establish identity, authentication, authorization, and access control requirements for AI agents before they are integrated into development workflows.

This phase focuses on preventing unauthorized agent activity, protecting credentials, and ensuring that AI agents operate within explicitly defined security boundaries.

The following activities map NIST Secure Software Development Framework (SSDF) practices and OWASP AI security guidance to actionable CI/CD practices and suggested open-source tools. The tools are illustrative and are not mandated by these frameworks.

AI Agent Identity and Permissions

Objective: Ensure autonomous AI agents operate with verified identities, least-privilege permissions, controlled access to development resources, and appropriate authorization for security-sensitive actions.

The NIST Secure Software Development Framework (SSDF) emphasizes protecting development environments, securing software development processes, and preventing unauthorized changes to software artifacts.

The OWASP Top 10 for LLM Applications identifies excessive agency as a risk when AI systems are granted unnecessary functionality, permissions, or autonomy.

For DevOps teams, AI agent access should be treated similarly to other automated service identities. Agents should use dedicated identities where supported, receive only the permissions required for their assigned tasks, and operate within controlled execution environments.

Agent-generated instructions should never replace independent access control decisions. Permissions must be enforced by repository platforms, identity services, execution environments, and other trusted systems.

AI Security Requirements and Open-Source Tooling

Framework references identify relevant security practices and risk categories. Specific agent access controls are implementation recommendations rather than requirements explicitly prescribed for agents by every referenced framework.

Expected Security Evidence

• Documented AI agent identities and assigned responsibilities.
• Defined access control policies for repositories, tools, and services.
• Records demonstrating least-privilege permissions.
• Credential management and secrets protection configurations.
• Approved agent tool and command allowlists.
• Security policies for agent execution environments.
• Records of required reviews and approvals for agent-generated changes.
• Agent activity logs and security-relevant execution records.
• Evidence of authentication and authorization policy enforcement.

These artifacts provide evidence that autonomous AI agents are operating within controlled security boundaries and that development teams retain accountability for agent-initiated actions.

Agent security requirements established during Phase 1 should be validated during Phase 2: Build and Deploy and monitored throughout Phase 3: Post Deploy.

Additional Resources

• NIST Secure Software Development Framework
• NIST AI SSDF Profile
• OWASP Top 10 for LLM Applications
• OWASP Agentic AI Security
• SPIFFE and SPIRE

3.1.3 - AI Application Threat Modeling

AI Application Threat Modeling - Phase 1: Code and Prebuild

Artificial intelligence applications introduce security risks that extend beyond those found in traditional software architectures. Applications incorporating large language models (LLMs), retrieval-augmented generation (RAG), autonomous agents, external data sources, and tool integrations create new attack surfaces and trust relationships.

These systems may process untrusted prompts, retrieve external content, invoke privileged tools, and generate outputs that influence application behavior.

During Code and Prebuild, organizations should perform AI-specific threat modeling to identify potential vulnerabilities before application components are implemented or integrated into the CI/CD pipeline.

This phase focuses on identifying attack paths, evaluating security boundaries, and establishing controls to prevent unauthorized model behavior, sensitive information disclosure, and unsafe agent actions.

The following activities map NIST security guidance and OWASP AI risk categories to actionable threat modeling practices and suggested open-source tools.

AI Application Threat Modeling

Objective: Identify and document AI-specific attack surfaces, trust boundaries, potential threats, and appropriate security controls before developing or deploying AI-enabled applications.

The NIST Secure Software Development Framework (SSDF) emphasizes integrating security requirements and risk analysis into software design and development activities.

The NIST AI Risk Management Framework provides guidance for identifying, measuring, and managing risks associated with AI systems.

The OWASP Top 10 for LLM Applications identifies risks including prompt injection, sensitive information disclosure, supply chain vulnerabilities, improper output handling, and excessive agency.

For DevOps teams, threat modeling should be integrated into application architecture reviews, development planning, and security requirements definition.

AI components should be evaluated as part of the complete application architecture rather than as isolated models.

Threat models should identify how users, models, agents, retrieved information, and external services interact and where trust boundaries must be enforced.

AI Security Requirements and Open-Source Tooling

Threat modeling tools support risk identification and documentation. Testing tools such as Promptfoo and Garak can help validate selected threats but do not replace architectural threat modeling.

Expected Security Evidence

• Documented AI application threat models.
• Architecture diagrams identifying AI components and external services.
• Data flow diagrams showing model inputs, outputs, and tool interactions.
• Identified trust boundaries and security-sensitive integration points.
• Prompt injection and agent misuse risk assessments.
• Sensitive information exposure assessments.
• Documented AI security risks and assigned risk owners.
• Security requirements and mitigation plans derived from identified threats.
• Records of architecture reviews and threat model updates.

These artifacts provide evidence that AI-specific security risks were considered during application planning and design.

Threat models developed during Phase 1 should inform the automated AI security testing and release validation activities performed during Phase 2: Build and Deploy.

Additional Resources

• NIST Secure Software Development Framework
• NIST AI SSDF Profile
• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• OWASP Threat Dragon
• MITRE ATLAS

3.1.4 - AI Model and Data Supply Chain

AI Model and Data Supply Chain - Phase 1: Code and Prebuild

AI-enabled applications increasingly depend on externally sourced models, training datasets, machine learning frameworks, model repositories, and third-party software components.

These dependencies introduce security risks beyond traditional software package management. AI models may originate from untrusted sources, datasets may contain malicious or manipulated content, and model files may include unsafe serialization formats or dependencies.

During Code and Prebuild, organizations should establish processes for evaluating the provenance, integrity, licensing, and security of AI models and data before incorporating them into applications.

This phase focuses on identifying supply chain risks early, maintaining visibility into AI dependencies, and establishing trusted sources for AI components.

The following activities map NIST Secure Software Development Framework (SSDF), the AI SSDF Profile, and OWASP AI security guidance to actionable CI/CD practices and suggested open-source tools.

AI Model and Data Supply Chain

Objective: Ensure AI models, datasets, frameworks, and third-party dependencies are evaluated for provenance, integrity, vulnerabilities, licensing, and supply chain risks before entering the software delivery pipeline.

The NIST Secure Software Development Framework (SSDF) establishes practices for identifying, evaluating, and securing third-party software components.

The NIST AI SSDF Profile (SP 800-218A) extends secure development guidance to address additional security considerations associated with AI model development and integration.

The OWASP Top 10 for LLM Applications identifies AI supply chain vulnerabilities and data and model poisoning as significant risks.

For DevOps teams, AI model and data dependencies should be evaluated before being introduced into trusted development environments.

This includes verifying component sources, reviewing applicable licenses, identifying known vulnerabilities, and documenting dependencies between models, datasets, frameworks, and application components.

Organizations should also establish requirements for maintaining accurate inventories of AI assets so they can be tracked throughout the build, deployment, and operational lifecycle.

AI Security Requirements and Open-Source Tooling

These tools address different aspects of AI supply chain security. Traditional SBOM tools do not necessarily capture complete model, dataset, or prompt inventories. Model provenance, dataset security, and licensing may require additional records and specialized validation.

Expected Security Evidence

• Inventory of approved AI models and associated versions.
• Records identifying model sources, repositories, and provenance.
• Model integrity verification results and available signatures.
• Dataset source records and integrity assessments.
• Documented assessments of data and model poisoning risks.
• Software dependency vulnerability scanning results.
• Model file security scan results.
• Third-party component license and usage reviews.
• AI component inventories and applicable SBOMs.
• Records of rejected or unapproved AI components.
• Traceable relationships between models, datasets, dependencies, and application development artifacts.

These artifacts provide evidence that AI models and supporting dependencies have been evaluated before entering the software delivery process.

Supply chain records created during Phase 1 should support model verification and artifact integrity controls in Phase 2: Build and Deploy, as well as continuous vulnerability management during Phase 3: Post Deploy.

Additional Resources

• NIST Secure Software Development Framework
• NIST AI SSDF Profile
• OWASP Top 10 for LLM Applications
• OpenSSF Model Signing
• CycloneDX
• OpenSSF

3.1.5 - Prompt and Agent Configuration Security

Prompt and Agent Configuration Security - Phase 1: Code and Prebuild

AI-enabled applications rely on system prompts, agent instructions, tool definitions, and configuration files to determine how models interact with users, applications, and external services.

These artifacts can directly influence application behavior, data access, tool execution, and security boundaries.

Unlike traditional source code, prompts and agent configurations may be modified independently of application binaries. Unauthorized or poorly reviewed changes can introduce security risks even when the underlying application code remains unchanged.

During Code and Prebuild, organizations should treat security-sensitive prompts, agent instructions, and configurations as managed development artifacts.

This phase focuses on protecting AI configurations against unauthorized modification, establishing secure review processes, and ensuring that agent capabilities remain aligned with approved security policies.

The following activities map NIST security guidance and OWASP AI risk categories to actionable CI/CD practices and suggested open-source tools.

Prompt and Agent Configuration Security

Objective: Ensure system prompts, agent instructions, tool configurations, and AI application settings are version-controlled, reviewed, protected against unauthorized changes, and aligned with established security requirements.

The NIST Secure Software Development Framework (SSDF) establishes practices for protecting software artifacts, controlling changes, and integrating security requirements into development workflows.

The OWASP Top 10 for LLM Applications identifies prompt injection, system prompt leakage, and excessive agency as security concerns affecting AI-enabled applications.

For DevOps teams, prompts and agent configurations should be managed using established source control and change management practices.

Security-sensitive changes should be reviewed before acceptance, and automated policies should prevent unauthorized modifications to agent permissions, tool access, and execution settings.

System prompts should not be treated as a security boundary. Authorization must be enforced by trusted application and infrastructure controls independently of model instructions.

AI Security Requirements and Open-Source Tooling

The referenced frameworks provide relevant software security practices and AI risk categories. The implementation recommendations translate those practices into CI/CD controls for prompts, agent instructions, and configuration artifacts.

Expected Security Evidence

• Version-controlled system prompts and agent instructions.
• Approved tool definitions and agent configuration records.
• Security review and approval records for configuration changes.
• Documented policies restricting agent permissions and tool access.
• Configuration validation and policy enforcement results.
• Secrets scanning results for prompts and configuration files.
• Prompt injection testing results and identified security findings.
• Records of unauthorized or rejected configuration modifications.
• Traceable configuration versions associated with application changes.
• Documented procedures for updating and restoring approved AI configurations.

These artifacts provide evidence that AI instructions and configurations are managed through controlled development processes.

Configuration controls established during Phase 1 should support security testing and release verification during Phase 2: Build and Deploy.

After deployment, changes to AI instructions, tools, and permissions should remain subject to authorization, monitoring, and audit requirements.

Additional Resources

• NIST Secure Software Development Framework
• NIST AI SSDF Profile
• OWASP Top 10 for LLM Applications
• OWASP Generative AI Security Project
• Open Policy Agent
• Promptfoo

3.2 - Build and Deploy

Validating AI Artifacts and Securing AI-Enabled Software Delivery

Artificial intelligence introduces new security considerations into the build and deployment process. AI-generated code, machine learning models, prompts, agent configurations, and supporting dependencies must be validated before they are incorporated into production software.

Phase 2: Build and Deploy focuses on ensuring that AI-generated code and AI application components are securely built, tested, verified, and authorized for deployment.

This phase extends traditional CI/CD security practices to address AI-specific vulnerabilities, model integrity, adversarial testing, agent permissions, and the traceability of AI-related software artifacts.

The objective is to establish automated security controls that verify the integrity and security of AI-enabled software before it reaches production.

Phase 2 Outcomes

By implementing these practices, DevOps teams establish automated security controls for validating and deploying AI-enabled software.

Expected outcomes include:

• AI-generated code is validated using established secure development and testing practices.
• AI models and supporting artifacts are verified for integrity and provenance.
• AI applications are tested for prompt injection, unsafe behavior, and unauthorized tool execution.
• Autonomous agents and AI services operate within defined deployment permissions.
• Software releases include traceable AI artifacts, dependencies, and security evaluation results.
• Deployment authorization and security policies are consistently enforced.
• Security evidence is available for ongoing vulnerability management and compliance assessments.

These outcomes help ensure that AI-enabled applications enter production with verified artifacts, tested security controls, and traceable release information.

Related Security Frameworks

The following frameworks provide guidance relevant to Phase 2 AI security activities.

These frameworks and projects provide guidance and technical capabilities that can support AI security controls. They do not all establish mandatory regulatory compliance requirements.

Integrating AI Security into the CI/CD Pipeline

AI security controls should be incorporated into existing CI/CD automation rather than implemented as disconnected manual processes.

This section will cover a typical AI-enabled software delivery workflow to include:

3.2.1 - AI-Generated Code Validation

AI-Generated Code Validation - Phase 2: Build and Deploy

Artificial intelligence is increasingly used to generate source code, update dependencies, modify configurations, and create pull requests. These changes can accelerate software delivery but may introduce vulnerabilities, insecure coding patterns, compatibility problems, and unintended functionality.

During Build and Deploy, organizations should independently validate AI-generated changes using established security testing and software quality controls.

AI-generated code should not be trusted solely because an AI assistant or autonomous agent reports that its changes are secure or functional.

This activity focuses on incorporating automated scanning, testing, and release authorization into CI/CD workflows to ensure AI-generated code meets established security requirements before deployment.

AI-Generated Code Validation

Objective: Ensure AI-generated code and configuration changes are independently tested, reviewed, and validated for security vulnerabilities, vulnerable dependencies, exposed secrets, and unintended functionality before software is released.

The NIST Secure Software Development Framework (SSDF) establishes practices for reviewing, analyzing, and testing software to identify vulnerabilities before release.

The NIST AI SSDF Profile (SP 800-218A) extends secure development guidance to address AI-related development considerations.

For DevOps teams, automated CI/CD validation provides an independent security control between AI-generated changes and production deployment.

Security gates should prevent code from progressing when required validation fails. Human review or authorized policy decisions should determine whether changes are accepted, rejected, or returned for remediation.

AI Security Requirements and Open-Source Tooling

These mappings apply established secure software development practices to AI-generated changes. AI-generated code remains subject to the same security requirements as human-written code.

Expected Security Evidence

• Automated static application security testing reports.
• Dependency vulnerability scanning results.
• Secrets detection and remediation records.
• Unit, integration, and regression test results.
• Build and dependency compatibility validation logs.
• Records of rejected or failed AI-generated changes.
• Code review and release approval records.
• Security policy enforcement results.
• Artifact verification and provenance records.
• Traceable pull requests linking AI-generated changes to validation results.

These artifacts demonstrate that AI-generated changes have been independently validated before entering production.

Security findings should be resolved, rejected, or formally accepted through an authorized risk management process before deployment.

Additional Resources

• NIST Secure Software Development Framework
• NIST AI SSDF Profile
• OpenSSF
• OWASP ZAP
• Open Policy Agent

3.2.2 - AI Model and Artifact Integrity

AI Model and Artifact Integrity - Phase 2: Build and Deploy

AI-enabled applications increasingly incorporate pretrained models, fine-tuned models, embeddings, model adapters, and supporting software artifacts obtained from external repositories.

These artifacts introduce supply chain security risks, including compromised models, unauthorized modifications, unsafe serialization formats, and untrusted dependencies.

During Build and Deploy, organizations should verify that AI models and supporting artifacts originate from approved sources and have not been modified unexpectedly.

This activity extends established software supply chain security practices to AI models, associated dependencies, and release artifacts.

AI Model and Artifact Integrity

Objective: Ensure AI models and supporting software artifacts are verified for provenance, integrity, authenticity, and known security risks before packaging or deployment.

The NIST Secure Software Development Framework (SSDF) establishes practices for protecting software artifacts and verifying software integrity.

The NIST AI SSDF Profile (SP 800-218A) addresses additional security considerations associated with AI model development and integration.

The OpenSSF Model Signing project provides open-source capabilities for signing and verifying AI model artifacts.

For DevOps teams, model verification should become an automated CI/CD activity similar to container signature verification, dependency scanning, and software artifact validation.

Model signatures and checksums help establish artifact integrity, but do not independently prove that a model is free of malicious behavior or vulnerabilities. Additional security assessments remain necessary.

AI Security Requirements and Open-Source Tooling

Artifact integrity and model security are related but distinct. Signature verification establishes properties of the artifact and its origin, while behavioral evaluations and vulnerability scanning assess different security risks.

Expected Security Evidence

• Inventory of approved AI models and artifact versions.
• Model provenance and source verification records.
• Model checksum and signature verification results.
• Model file security scanning reports.
• Software dependency vulnerability reports.
• Model and software component inventories.
• Build provenance and release attestations.
• Records of approved and rejected model artifacts.
• Deployment policy enforcement results.
• Traceable relationships between model artifacts and application releases.

These artifacts provide evidence that AI model integrity and provenance are evaluated before deployment.

Verified model records should be retained for post-deployment inventory management, vulnerability analysis, and incident investigation.

Additional Resources

• NIST Secure Software Development Framework
• NIST AI SSDF Profile
• OpenSSF Model Signing
• SLSA
• Sigstore
• CycloneDX

3.2.3 - AI Security Testing and Red Teaming

AI Security Testing and Red Teaming - Phase 2: Build and Deploy

AI-enabled applications introduce security risks that traditional application security testing may not fully identify.

Large language models (LLMs), retrieval-augmented generation (RAG) systems, and autonomous AI agents process dynamic inputs, interact with external information, and may invoke tools or execute actions.

These capabilities create attack surfaces involving prompt injection, sensitive information disclosure, unauthorized tool execution, insecure output handling, and excessive agency.

During Build and Deploy, organizations should incorporate AI-specific security evaluations and adversarial testing into CI/CD workflows.

This activity focuses on identifying unsafe AI application behavior before production deployment and establishing repeatable security testing practices.

AI Security Testing and Red Teaming

Objective: Identify AI-specific vulnerabilities and unsafe behavior through automated security evaluations, adversarial testing, and independently enforced release acceptance criteria.

The NIST Secure Software Development Framework (SSDF) establishes security testing and vulnerability identification practices for software releases.

The NIST AI Risk Management Framework emphasizes evaluating and managing risks throughout the AI system lifecycle.

The OWASP Top 10 for LLM Applications identifies common AI application security risks, including prompt injection, sensitive information disclosure, improper output handling, and excessive agency.

For DevOps teams, AI security evaluations should be automated wherever practical and incorporated into existing build and release validation processes.

Security testing should evaluate not only the model’s responses but also whether the application enforces access controls, protects sensitive information, and prevents unauthorized tool actions.

Because AI behavior may be nondeterministic, teams should define repeatable test scenarios, execution parameters, evaluation criteria, and acceptable failure thresholds.

AI Security Requirements and Open-Source Tooling

AI security testing tools have different capabilities and coverage. No single testing tool can establish that an AI application is free of vulnerabilities or unsafe behaviors.

Expected Security Evidence

• AI application security test plans and acceptance criteria.
• Prompt injection testing results.
• Sensitive information disclosure evaluation reports.
• Agent permission and tool execution test results.
• RAG and retrieval security testing records.
• Resource consumption and abuse testing results.
• Security regression test results.
• Records of identified vulnerabilities and remediation activities.
• Automated security gate results.
• Approved exceptions and documented residual risks.
• Traceable AI evaluation results associated with application releases.

These artifacts demonstrate that AI applications have undergone defined security evaluations before deployment.

Security testing should be repeated when significant changes occur to models, prompts, agent permissions, retrieval sources, or connected tools.

Additional Resources

• NIST Secure Software Development Framework
• NIST AI SSDF Profile
• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• MITRE ATLAS
• Inspect AI

3.2.4 - Secure AI Deployment

Secure AI Deployment - Phase 2: Build and Deploy

AI-enabled applications often depend on models, external APIs, vector databases, retrieval services, and autonomous agents that interact with other applications and infrastructure.

These integrations introduce security risks when deployed applications or agents receive excessive permissions, unrestricted network access, sensitive credentials, or unauthorized tool capabilities.

During Build and Deploy, organizations should ensure AI applications and autonomous agents are deployed within controlled environments that enforce access policies, workload isolation, secure configuration, and release authorization.

This activity extends established CI/CD deployment security practices to address the operational capabilities and security requirements of AI-enabled applications.

Secure AI Deployment

Objective: Ensure AI applications, models, and autonomous agents are deployed using verified artifacts, controlled identities, least-privilege permissions, protected credentials, and independently enforced security policies.

The NIST Secure Software Development Framework (SSDF) establishes practices for protecting software development environments and ensuring the integrity of software releases.

The OWASP Top 10 for LLM Applications identifies excessive agency, prompt injection, and improper output handling as risks that can affect deployed AI applications.

For DevOps teams, secure deployment should ensure that AI services and agents operate only within approved access and execution boundaries.

AI-generated instructions must not independently grant permissions or authorize privileged operations. Access decisions should be enforced by trusted application, identity, and infrastructure controls.

AI Security Requirements and Open-Source Tooling

These controls apply established software security and infrastructure practices to AI-enabled applications. Deployment authorization and infrastructure security controls should operate independently of model-generated decisions.

Expected Security Evidence

• Approved AI deployment configurations.
• Workload identity and authentication records.
• Agent permission and authorization policies.
• Secrets management and credential access configurations.
• Workload isolation and network security policies.
• Verified container and artifact signatures.
• Deployment policy enforcement records.
• Release approval and change authorization evidence.
• Deployment configuration and version history.
• Records of rejected or unauthorized deployment attempts.

These artifacts provide evidence that AI applications and agents are deployed within controlled environments and operate under defined security restrictions.

Deployment evidence should be retained for continuous security monitoring, vulnerability management, and incident response during Phase 3: Post Deploy.

Additional Resources

• NIST Secure Software Development Framework
• NIST AI SSDF Profile
• OWASP Top 10 for LLM Applications
• Open Policy Agent
• SPIFFE and SPIRE
• Kubernetes Security

3.2.5 - AI Release Evidence and Inventory

AI Release Evidence and Inventory - Phase 2: Build and Deploy

AI-enabled software releases may include more than traditional source code, libraries, and container images.

Applications can depend on AI models, prompts, agent configurations, retrieval components, external services, and supporting datasets that influence their behavior.

Without an accurate inventory of these components, organizations may struggle to identify which AI assets are deployed, determine which systems are affected by security findings, or reproduce the configuration of a previous release.

During Build and Deploy, organizations should create and retain inventories and security evidence that associate AI components with their application releases and deployment records.

This activity focuses on establishing traceability across the AI software supply chain and ensuring security evidence remains available after deployment.

AI Release Evidence and Inventory

Objective: Maintain accurate, traceable records of AI models, prompts, agent configurations, software dependencies, security evaluations, and deployment artifacts associated with each software release.

The NIST Secure Software Development Framework (SSDF) establishes practices for preserving software integrity, tracking software components, and generating evidence associated with secure development.

The NIST AI SSDF Profile (SP 800-218A) extends secure development guidance to address AI model development and lifecycle considerations.

For DevOps teams, release inventories should extend beyond traditional Software Bills of Materials (SBOMs) to include relevant AI assets and their relationships to deployed applications.

An SBOM identifies software components and dependencies, but may not fully capture models, datasets, prompts, and agent configurations. Additional AI-specific inventories or metadata may therefore be necessary.

The resulting release evidence should enable teams to determine what was built, what was tested, what was approved, and what was deployed.

AI Security Requirements and Open-Source Tooling

Release inventories may require multiple complementary formats and tools. SBOMs, model metadata, provenance attestations, security evaluation results, and deployment records serve different purposes and should be linked using stable identifiers wherever practical.

Expected Security Evidence

• Software Bills of Materials for applicable software artifacts.
• AI model inventories identifying model names, versions, and sources.
• Model integrity verification records.
• Approved prompt and agent configuration versions.
• AI dependency and component relationship records.
• Build provenance and artifact attestations.
• AI security testing and evaluation reports.
• Vulnerability scanning and remediation records.
• Release approvals and authorization decisions.
• Deployment records identifying target environments and application versions.
• Traceable links between AI artifacts, application releases, and deployed systems.
• Retained security evidence supporting investigation, audits, and vulnerability management.

These artifacts provide a record of the software and AI components included in each release and the security controls applied before deployment.

Release inventories should remain available after deployment so newly discovered vulnerabilities can be correlated with affected software components, AI models, applications, and environments.

This information provides the foundation for continuous vulnerability management, affected-system identification, and incident response during Phase 3: Post Deploy.

Additional Resources

• NIST Secure Software Development Framework
• NIST AI SSDF Profile
• CycloneDX
• SLSA
• Sigstore
• GUAC
• OpenSSF Model Signing

3.3 - Post Deployment

Continuous AI Security Monitoring and Controlled Remediation

Security does not stop when an AI-enabled application reaches production. New vulnerabilities are discovered, AI models and dependencies change, autonomous agents interact with external systems, and emerging threats can affect applications long after their initial deployment.

Phase 3: Post Deploy focuses on maintaining continuous security visibility into deployed AI applications, models, agents, and their supporting software components.

This phase extends traditional vulnerability management and runtime security practices to address AI-specific threats, including prompt injection, unauthorized agent activity, sensitive information disclosure, model compromise, and unsafe automated actions.

It also explores how artificial intelligence can support vulnerability analysis and remediation while maintaining independent validation, human oversight, and auditable security controls.

The objective is to ensure that deployed AI-enabled software remains secure throughout its operational lifecycle.

Why AI Security Must Continue After Deployment

Traditional post-deployment security activities focus on monitoring applications, identifying vulnerabilities, detecting suspicious behavior, and applying security updates.

AI-enabled applications introduce additional challenges:

• Changing AI Threats: Newly discovered attack techniques can affect deployed AI applications without requiring changes to their underlying source code.
• Autonomous Agent Activity: AI agents may execute commands, access APIs, modify resources, or interact with external systems during production operations.
• Model and Dependency Vulnerabilities: Deployed AI services depend on models, frameworks, libraries, containers, and supporting infrastructure that may develop new security exposures.
• Prompt Injection and Data Exposure: Malicious inputs and untrusted external content can manipulate model behavior or expose sensitive information.
• Limited Deployment Visibility: Organizations may lack an accurate inventory of which AI models, prompts, dependencies, and configurations are running in production.
• AI-Assisted Remediation Risks: AI-generated security fixes may introduce compatibility issues, unintended changes, or new vulnerabilities if applied without validation.

Addressing these challenges requires continuous security monitoring, accurate deployed asset inventories, and controlled remediation workflows.

Phase 3: Post Deployment Outcomes

By implementing these practices, DevOps and security teams establish continuous security oversight for deployed AI-enabled software.

Expected outcomes include:

• Deployed AI applications are monitored for suspicious behavior, unauthorized access, and emerging threats.
• AI agents operate with observable and auditable execution histories.
• Newly disclosed software vulnerabilities are correlated with affected production applications and dependencies.
• AI-specific behavioral risks are assessed alongside traditional software vulnerabilities.
• AI-assisted remediation changes are independently tested and approved before release.
• Compromised models, agents, and applications can be isolated, rolled back, or recovered.
• Security evidence supports incident investigation, vulnerability management, and compliance assessments.
• Production security findings provide feedback into earlier CI/CD security activities.

These outcomes support a continuous security model in which monitoring, vulnerability identification, remediation, and verification extend throughout the operational lifecycle.

Related Security Frameworks

The following frameworks provide guidance relevant to Phase 3 AI security activities.

These frameworks provide guidance for implementing and managing AI security controls. They do not all establish mandatory regulatory compliance requirements.

Integrating AI Security into the CI/CD Pipeline

AI security controls should be incorporated into existing CI/CD automation rather than implemented as disconnected manual processes.

This section will cover a typical AI-enabled software delivery workflow to include:

3.3.1 - AI Runtime Security Monitoring

AI Runtime Security Monitoring - Phase 3: Post Deploy

Artificial intelligence applications introduce runtime behaviors that traditional application security monitoring may not fully capture. Large language models (LLMs), retrieval-augmented generation (RAG) systems, and autonomous agents interact with users, external data sources, APIs, and supporting services in ways that can create additional security risks.

These risks include prompt injection, sensitive information disclosure, unauthorized tool execution, model manipulation, and resource abuse.

During Post Deploy, organizations should continuously monitor AI applications to identify suspicious activity, detect security policy violations, and respond to emerging threats.

This activity extends established runtime security monitoring practices to include AI-specific behavior, model interactions, and application security events.

AI Runtime Security Monitoring

Objective: Detect and investigate suspicious AI application behavior, unauthorized access, prompt injection attempts, sensitive information exposure, and runtime security policy violations.

The NIST AI Risk Management Framework emphasizes ongoing measurement, monitoring, and management of risks associated with AI systems.

The NIST Cybersecurity Framework 2.0 provides guidance for identifying, detecting, responding to, and recovering from cybersecurity threats.

The OWASP Top 10 for LLM Applications identifies AI-specific threats including prompt injection, sensitive information disclosure, excessive agency, and unbounded consumption.

For DevOps teams, runtime monitoring should combine application telemetry, infrastructure security events, AI interaction traces, and independently enforced security policies.

Monitoring should collect sufficient information to investigate suspicious behavior while protecting confidential prompts, user information, credentials, and sensitive model outputs.

AI-generated explanations of suspicious activity should not replace independently collected security evidence.

AI Security Requirements and Open-Source Tooling

Observability tools collect and analyze runtime information but do not automatically detect every AI-specific attack. Prompt injection testing tools primarily support security evaluations and require additional integration for continuous monitoring.

Expected Security Evidence

• AI application runtime monitoring configurations.
• AI service traces, metrics, and security event records.
• Records of detected suspicious input or application behavior.
• Unauthorized tool execution and access violation alerts.
• Sensitive information exposure detection results.
• Resource usage and abnormal consumption monitoring reports.
• Infrastructure and container runtime security findings.
• Correlated application and security event records.
• Security incident investigation records.
• Runtime policy enforcement and alert response evidence.

These artifacts demonstrate that deployed AI applications are subject to continuous security monitoring and that security-relevant events can be investigated.

Monitoring findings should feed into vulnerability management, incident response, and the security requirements applied during earlier CI/CD phases.

Additional Resources

• NIST AI Risk Management Framework
• NIST Cybersecurity Framework 2.0
• OWASP Top 10 for LLM Applications
• OpenTelemetry
• Falco
• MITRE ATLAS

3.3.2 - Continuous AI Vulnerability Management

Continuous AI Vulnerability Management - Phase 3: Post Deploy

AI-enabled applications depend on software frameworks, model-serving infrastructure, libraries, containers, APIs, and supporting services that may become vulnerable after deployment.

A software component that passes security testing during development may later be affected by a newly disclosed Common Vulnerabilities and Exposures (CVE) record.

Traditional pre-deployment scanning cannot detect vulnerabilities that become known after software has already been released.

AI applications also introduce behavioral security risks, including prompt injection, excessive agent permissions, sensitive information disclosure, and manipulation of model outputs. These weaknesses may not have CVE identifiers and cannot always be addressed through traditional software patching.

During Post Deploy, organizations should continuously monitor both newly disclosed software vulnerabilities and AI-specific behavioral security risks.

This activity focuses on maintaining deployed software visibility, identifying affected environments, assessing AI-specific threats, prioritizing remediation, and verifying that corrective actions reach affected production systems.

Continuous AI Vulnerability Management

Objective: Continuously identify, assess, prioritize, and remediate software vulnerabilities and AI-specific behavioral security weaknesses affecting deployed AI applications, dependencies, agents, and supporting infrastructure.

The NIST Secure Software Development Framework (SSDF) establishes practices for identifying vulnerabilities in released software, assessing their impact, and implementing appropriate responses.

The NIST AI SSDF Profile (SP 800-218A) extends secure development guidance to address AI model development and integration.

The NIST Cybersecurity Framework 2.0 provides guidance for identifying technology assets, managing vulnerabilities, assessing risks, and implementing appropriate responses.

The NIST AI Risk Management Framework provides guidance for identifying, measuring, monitoring, and managing risks associated with AI systems.

The OWASP Top 10 for LLM Applications identifies AI-specific security risks, including prompt injection, sensitive information disclosure, improper output handling, and excessive agency.

For DevOps teams, continuous AI security requires two complementary practices:

1. Software Vulnerability Management: Identify known software vulnerabilities, correlate findings with deployed components, and verify remediation.
2. AI Behavioral Risk Management: Identify and mitigate AI-specific weaknesses through adversarial testing, runtime monitoring, access controls, and application security improvements.

These practices should share application inventory, ownership, and deployment information while maintaining distinct methods for assessing and remediating security findings.

Software Vulnerability Management - NIST SSDF

Software vulnerability management focuses on identifying, assessing, and remediating known vulnerabilities in deployed software components, including AI frameworks, libraries, containers, model-serving infrastructure, and supporting services.

NIST SSDF practices RV.1 and RV.2 establish processes for identifying and responding to vulnerabilities in released software.

For DevOps teams, vulnerability management must extend beyond creating Software Bills of Materials (SBOMs) and scanning release artifacts.

SBOM information should be associated with application versions and deployment metadata so teams can identify which vulnerable components are actually running, where they are deployed, and who is responsible for remediation.

Continuous monitoring of vulnerability intelligence sources enables organizations to identify vulnerabilities disclosed after deployment and determine their potential impact on production applications.

Remediation should be prioritized based on severity, known exploitation, exposure, affected production systems, and operational risk.

Software Vulnerability Management Requirements and Open-Source Tooling

Vulnerability discovery, software supply chain correlation, and deployment inventory are complementary capabilities. An SBOM scanner identifies software components and may detect known vulnerabilities, while deployment correlation is needed to determine which applications and environments are affected.

Software Vulnerability Management - Expected Security Evidence

• Inventory of deployed AI applications and supporting software components.
• SBOMs associated with released application versions.
• Deployment records identifying environments and affected assets.
• Newly disclosed CVE detection records.
• Correlations between vulnerable packages and deployed applications.
• Vulnerability severity, exploitability, and exposure assessments.
• Documented vulnerability ownership and prioritization decisions.
• Remediation tracking records and assigned corrective actions.
• Post-remediation vulnerability scanning results.
• Evidence confirming deployment of corrected software versions.

These artifacts provide evidence that software vulnerability management continues after deployment and that newly disclosed vulnerabilities can be associated with affected production systems.

Vulnerability findings should initiate appropriate remediation workflows, including the AI-assisted remediation activities described in this phase.

AI Behavioral Risk Management - OWASP and NIST AI RMF

AI-enabled applications introduce behavioral security weaknesses that may not be associated with a known CVE or vulnerable software package. These weaknesses arise from how AI systems process instructions, interact with external content, access tools, and make decisions.

Examples include prompt injection, excessive agency, sensitive information disclosure, unsafe output handling, and manipulation of retrieved information.

Unlike traditional software vulnerabilities, these issues may require changes to application architecture, trust boundaries, authorization policies, model configurations, prompts, or agent permissions rather than dependency upgrades.The OWASP Top 10 for LLM Applications identifies common AI-specific security risks, while the NIST AI Risk Management Framework provides guidance for assessing, monitoring, and managing AI risks throughout the operational lifecycle.

For DevOps teams, AI behavioral risk management should be integrated into continuous security testing, runtime monitoring, application configuration management, and incident response processes. Security findings should be associated with affected AI applications, model versions, agent configurations, and deployed environments whenever possible.

AI Behavioral Risk Management Requirements and Open-Source Tooling

OWASP identifies AI application security risk categories, while NIST AI RMF provides processes for managing AI risks. The suggested controls and tools are implementation examples rather than mandatory requirements specified by these frameworks.

AI Behavioral Risk Management - Expected Security Evidence

• AI application threat models and behavioral risk assessments.
• Prompt injection testing and evaluation results.
• Sensitive information disclosure assessments.
• Agent permission and authorization validation records.
• Security testing results for retrieval and external tool integrations.
• AI model and application evaluation reports.
• Runtime monitoring and security event records.
• Documented AI behavioral weaknesses and affected applications.
• AI security risk ownership and prioritization decisions.
• Mitigation plans and security configuration changes.
• Post-mitigation security testing and validation results.
• Records of accepted, unresolved, or escalated AI security risks.

These artifacts provide evidence that AI-specific behavioral security risks are being assessed and managed throughout the operational lifecycle. Because AI behavior may vary with model versions, prompts, retrieved content, and external integrations, security evaluations should be repeated when significant changes occur.

Coordinating Software Vulnerabilities and AI Behavioral Risks

Software vulnerability management and AI behavioral risk management should operate as complementary security processes. A deployed AI application may contain vulnerable software dependencies while also exhibiting unsafe behavior caused by excessive agent permissions, prompt injection, or insecure application design.

Both categories of findings should be linked to the affected applications and deployment environments, but their detection and remediation requirements may differ.

For DevOps and platform engineering teams, maintaining a connection between these security processes improves visibility into the complete security posture of deployed AI applications.

A common application inventory, ownership model, and deployment record can help correlate findings while preserving the distinct evaluation and remediation workflows required for each risk category.

Additional Resources

• NIST Secure Software Development Framework
• NIST AI SSDF Profile
• NIST Cybersecurity Framework 2.0
• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• MITRE ATLAS
• OSV
• GUAC
• Ortelius
• CycloneDX

3.3.3 - AI Agent Activity Monitoring

AI Agent Activity Monitoring - Phase 3: Post Deploy

Autonomous AI agents introduce security risks because they can execute actions rather than simply generate responses. Production agents may interact with APIs, access databases, execute commands, modify files, invoke external tools, and communicate with other agents. These capabilities create security concerns when agents perform unauthorized actions, exceed assigned permissions, expose sensitive information, or respond to manipulated instructions.

During Post Deploy, organizations should continuously monitor AI agent activity to detect suspicious behavior, enforce authorization boundaries, and maintain auditable records of agent operations.

This activity focuses on establishing visibility into agent identities, tool calls, permissions, execution history, and security-sensitive actions.

AI Agent Activity Monitoring

Objective: Ensure autonomous AI agent activity is observable, attributable, and auditable, with controls capable of detecting unauthorized actions, excessive permissions, and security policy violations.

The NIST AI Risk Management Framework provides guidance for monitoring and managing AI-related risks throughout system operation.

The NIST Cybersecurity Framework 2.0 establishes practices for monitoring systems, detecting suspicious activity, and managing access-related security risks.

The OWASP Top 10 for LLM Applications identifies excessive agency as a security risk when AI systems have unnecessary functionality, permissions, or autonomy.

For DevOps teams, autonomous agents should be monitored similarly to other privileged automated services, with additional visibility into model-directed tool selection and execution.

Security controls should record which agent initiated an action, what resource was accessed, which tool was invoked, and whether the action was authorized.

Agent-generated explanations should not replace independent audit logs, access control records, and execution telemetry.

AI Security Requirements and Open-Source Tooling

Agent observability and authorization are separate controls. Monitoring records what an agent attempted or performed, while trusted authorization systems must independently determine which actions are permitted.

Expected Security Evidence

• Inventory of active AI agents and assigned identities.
• Agent authentication and authorization records.
• Agent tool invocation and execution logs.
• Records of access to protected APIs and services.
• Alerts identifying unauthorized or suspicious agent actions.
• Agent permission and policy enforcement results.
• Runtime process execution and infrastructure security events.
• Correlated agent activity and application security records.
• Records of suspended agents and revoked credentials.
• Security investigation and remediation records.
• Audit trails linking agent actions to initiating requests and execution contexts.

These artifacts demonstrate that autonomous AI agents operate under monitored and enforceable security controls.

Agent monitoring should support timely investigation of unauthorized operations while retaining sufficient evidence to establish which actions occurred and what systems were affected.

Additional Resources

• NIST AI Risk Management Framework
• NIST Cybersecurity Framework 2.0
• OWASP Excessive Agency
• OpenTelemetry
• Falco
• Open Policy Agent

3.3.4 - AI-Assisted Vulnerability Remediation

AI-Assisted Vulnerability Remediation - Phase 3: Post Deploy

Traditional vulnerability management tools identify vulnerable software packages and report security findings, but correcting those vulnerabilities frequently requires manual investigation, dependency analysis, code modifications, compatibility testing, and deployment coordination.

AI-assisted remediation introduces opportunities to reduce this effort by analyzing vulnerability information, identifying candidate fixes, and generating proposed software changes.

However, AI-generated remediation may introduce breaking changes, dependency conflicts, functional regressions, or new vulnerabilities.

During Post Deploy, organizations should integrate AI-assisted remediation into controlled CI/CD workflows that independently validate proposed changes before they are accepted or deployed.

This activity focuses on connecting deployed vulnerability detection with AI-assisted analysis, remediation preparation, automated validation, and authorized software delivery.

AI-Assisted Vulnerability Remediation

Objective: Accelerate vulnerability remediation through AI-assisted analysis and code generation while ensuring that proposed fixes are independently tested, reviewed, and authorized before deployment.

The NIST Secure Software Development Framework (SSDF) establishes practices for identifying and addressing vulnerabilities in released software.

The NIST AI SSDF Profile (SP 800-218A) extends secure development guidance to AI-related systems and development practices.

The NIST Cybersecurity Framework 2.0 provides guidance for managing cybersecurity risks and implementing appropriate corrective actions.

For DevOps teams, AI-assisted remediation should begin with an identified vulnerability and sufficient information about affected software components, dependency relationships, and deployment environments.

AI may analyze the vulnerability and prepare candidate updates, but independent tools and authorized reviewers should determine whether the proposed changes are acceptable.

Remediation workflows should not allow AI agents to bypass testing, change approval, or production deployment controls.

AI Security Requirements and Open-Source Tooling

The listed AI development tools can assist with code changes, but they do not independently provide a complete vulnerability remediation system. Organizations must integrate vulnerability intelligence, dependency analysis, testing, authorization, and deployment verification.

Controlled AI Remediation Workflow

AI-assisted remediation should distinguish three possible outcomes:

1. Safe Dependency Upgrade

A vulnerability has a known patched version that is compatible with the application.

The AI proposes an update, and independent build, security, and regression tests confirm the change satisfies release requirements.

The proposed fix is submitted for review and authorization before deployment.

2. Unsafe Dependency Upgrade

A patched version is available, but upgrading introduces breaking changes, dependency conflicts, or failed tests.

The proposed change is blocked or revised. The workflow records the failure and may generate a tracked issue for further investigation.

3. Ambiguous or Unresolved Vulnerability

A vulnerability cannot be safely corrected because the available evidence is insufficient, a compatible patch does not exist, or the remediation risk is unacceptable.

The workflow preserves the vulnerability finding, documents the available alternatives, and creates an issue for human investigation.

These outcomes ensure AI-assisted remediation produces auditable decisions rather than uncontrolled changes to production software.

Expected Security Evidence

• Original vulnerability findings and identifiers.
• Records identifying affected packages, applications, and deployments.
• AI-generated vulnerability analysis and candidate remediation recommendations.
• Proposed dependency changes and source code modifications.
• Dependency compatibility analysis results.
• Build, security scanning, and regression testing results.
• Records of rejected or unsuccessful remediation attempts.
• Pull requests containing validated remediation changes.
• Issues documenting unresolved vulnerabilities.
• Human review and approval records.
• Release and deployment records for corrected software.
• Post-deployment verification showing remediation status.
• Records of AI recommendations and independent validation outcomes.

These artifacts provide evidence that AI-assisted vulnerability remediation follows controlled software development and deployment practices.

The objective is to reduce the time required to investigate and prepare vulnerability corrections without weakening security validation or production change authorization.

Additional Resources

• NIST Secure Software Development Framework
• NIST AI SSDF Profile
• NIST Cybersecurity Framework 2.0
• OSV
• Renovate
• OpenHands
• Ortelius

3.3.5 - AI Incident Response and Recovery

AI Incident Response and Recovery - Phase 3: Post Deploy

AI-enabled applications introduce security incident scenarios that may differ from traditional application and infrastructure compromises.

Incidents can involve prompt injection, unauthorized agent execution, compromised model artifacts, manipulated retrieval content, sensitive information exposure, or abuse of external tools and services.

These incidents may affect application behavior even when the underlying software binaries remain unchanged.

During Post Deploy, organizations should extend established cybersecurity incident response procedures to include AI-specific threats, affected assets, and recovery requirements.

This activity focuses on detecting and investigating AI security incidents, containing affected systems, preserving evidence, restoring trusted configurations, and incorporating lessons learned into CI/CD security practices.

AI Incident Response and Recovery

Objective: Establish repeatable processes for detecting, investigating, containing, recovering from, and documenting AI-related security incidents while preserving reliable security evidence and preventing recurrence.

The NIST Cybersecurity Framework 2.0 establishes a lifecycle approach to cybersecurity risk management, including detection, response, and recovery.

NIST SP 800-61 Rev. 3 provides incident response recommendations aligned with the NIST Cybersecurity Framework.

The NIST AI Risk Management Framework provides guidance for measuring and managing risks associated with AI systems.

For DevOps teams, incident response should incorporate AI application telemetry, agent execution records, model and configuration inventories, deployment evidence, and software dependency information.

Security teams should be able to identify which AI components were involved, which actions occurred, which resources were affected, and whether the incident involved compromised software, manipulated model behavior, or unauthorized agent activity.

Recovery must restore both trusted software artifacts and approved AI configurations, permissions, models, and data sources.

AI Security Requirements and Open-Source Tooling