This is the multi-page printable view of this section.
Click here to print.
Return to the regular view of this page.
CI/CD Security Guide
Securing your Continuous Integration and Continuous Deployment (CI/CD) pipeline is no longer optional—it’s essential. This guide is your go-to resource for building, implementing, and optimizing secure CI/CD workflows. Whether you’re a developer, DevOps engineer, or security professional, we provide information on the open-source tools and guidance you need to model security at every stage of your pipeline. From securing code and builds to monitoring post-deployment environments, our hub empowers teams to integrate security seamlessly into their workflows without sacrificing speed or agility. Explore, learn, and transform your CI/CD processes into a fortress of innovation and resilience.
Why this Guide
This guide helps DevOps engineers build security-compliant CI/CD pipelines by mapping new open-source automation tools to evolving security frameworks. As security standards evolve, pipeline updates are essential to ensure safer software development. This guide explores the intersection of security tooling and the CI/CD pipeline, identifying key security practices, tools, and strategies that align with accepted frameworks such as the Secure Software Development Framework and the NIST Cybersecurity Framework. This guide aligns framework-defined tasks with open-source tools to accomplish them.
This CI/CD Cybersecurity Guide has been segmented into three 3 major chapters:
- CI/CD Code and Prebuild - this section includes security tooling for the earliest points in the CI/CD workflow.
- CI/CD Build and Deploy - this section covers security tooling for both the build step and deployment step, regardless of where the deployment is occurring (test or production).
- CI/CD Post Deploy - security does not stop after the binaries have been deployed. This section covers continuous vulnerability management and Dynamic Application Security Testing (DAST).
For more information on Security Frameworks or Public Security Policy, visit the OpenSSF Public Policy or EU Cybersecurity Resilience Act pages.
You can also learn about the OpenSSF Open Source Manifesto to help along the journey.
Compliance Goals
Compliance Policies and Practices are being defined across both public and private sectors. Specifically, the US Executive Order (EO) on Improving the Nation’s Cybersecurity and the EU Cyber Resilience Act (CRA) aim to define how to manage threats and vulnerabilities by establishing standardized frameworks for cybersecurity requirements. These frameworks cover the complete software development process, from design through ongoing monitoring of production software assets.
The inclusion of security tooling in the Continuous Integration and Continuous Deployment (CI/CD) pipeline is one crucial area where policy and practices can be implemented and automated. With the rapid pace of development and deployment in modern DevOps environments, security must be seamlessly embedded into each phase of the pipeline to protect applications and data from vulnerabilities and attacks.This is the new job of the DevOps team. This guide is intended to help the DevOps teams easily navigate the new frameworks and understand the tooling needed to achieve the stated compliance goals.
1 - Phase 1: Code and Prebuild
Security Compliance for Code and Prebuild
Introduction
Integrating security into every stage of the Software Development Life Cycle (SDLC) is more critical than ever. The code and prebuild stage is foundational to creating secure, reliable, and high-performing applications. Failing to address vulnerabilities early can lead to costly fixes, data breaches, and reputational damage down the line.
This section provides a comprehensive guide to the essential security tools that developers and DevOps teams should use during the code and prebuild phase to ensure vulnerabilities are identified and mitigated before they can cause harm. From Static Application Security Testing (SAST) to dependency scanning and secure CI/CD pipelines, the right tools can help you adopt a proactive approach to software security while maintaining development velocity. Following are guidelines from industry frameworks with suggested open source tooling needed to achieve the compliance goals.
1.1 - Secure Software Development Framework
Secure Software Development Framework and Code/Prebuild CI/CD Steps
Achieving Code and Prebuild Tasks of 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. This chapter focuses specifically on DevSecOps tooling and practices related to Code and Prebuild actions of the CI/CD pipeline to achieve:
|
|
| Prepare the Organization (PO) |
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. |
| Protect the Software (PS) |
Organizations should protect all components of their software from tampering and unauthorized access. |
| Produce Well-Secured Software (PW) |
Organizations should produce well-secured software with minimal security vulnerabilities in its releases. |
| 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. |
1.1.1 - Protect the Organization (PO)
Protect the Organization (PO) CI/CD Steps
Protect the Organization (PO)
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.
| Tasks |
Tools |
|
PO.2.1:
Create new roles and alter responsibilities for existing roles as needed to encompass all parts of the SDLC.Periodically review and maintain the defined roles and responsibilities, updating them as needed.
Designate a group of individuals as the code owners for each project, and review the list annually.
|
Github CODEOWNERS
|
|
Gitlab CODEOWNERS
|
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.
| Tasks |
Tools |
|
PO.3.1:
Specify which tools or tool types must or should be included in each toolchain to mitigate identified risks, as well as how the toolchain components are to be integrated with each other.
Use software factories and/or software templates to standardize the toolchain.
|
Backstage Software Templates
Can scaffold projects with pipelines-as-code and toolchains-as-code
|
|
Konflux-ci software factory for Tekton
Implements the In-toto framework using pipelines-as-code
|
|
CDF CDEvents
CDEvents is a common specification for Continuous Delivery events, enabling interoperability in the complete software production ecosystem.
|
|
PO.3.2:
Follow recommended security practices to deploy, operate, and maintain tools and toolchains.
Use code-based configuration for toolchains (e.g., pipelines-as-code, toolchains-as-code).
|
Jenkins Jenkinsfile
|
|
Github Actions .github/workflows directory
|
|
Gitlab CI/CD .gitlab-ci.yml file
|
|
Spinnaker Dinghy
|
|
Argo CD
|
|
Tekton pipelines-as-code
|
|
OpenTofu
|
|
PO.3.2:
Follow recommended security practices to deploy, operate, and maintain tools and toolchains.
Implement the technologies and processes needed for reproducible builds.
|
Hermetic builds with Konflux-ci
|
|
Python
|
|
Javascript
|
|
Java/Kotlin/Groovy
|
|
C#/.NET
|
|
C++
|
|
Rust
|
|
Golang
|
|
PHP Composer
|
|
SLSA Framework
|
|
PO.3.3:
Configure tools to generate artifacts of their support of secure software development practices as defined by the organization.
Use existing tooling (e.g., workflow tracking, issue tracking, value stream mapping) to create an audit trail of the secure development-related actions that are performed for continuous improvement purposes. Record security check approvals, rejections, and exception requests as part of the workflow and tracking system.
|
Github Issues
|
|
Gitlab work tracking
|
|
Bugzilla
|
|
Redmine
|
|
Mantis Bug Tracker
|
|
Trac
|
|
In-toto framework
|
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.
| Tasks |
Tools |
|
PO.4.1:
Define criteria for software security checks and track throughout the SDLC.
Add software security criteria to existing checks (e.g., the Definition of Done in agile SDLC methodologies).
|
Github Issue Templates
|
|
Gitlab Description Templates
|
|
PO.4.2:
Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria.
Collect audit logs for code repositories.
|
GitHub
|
|
GitLab
Audit Logs
|
|
PO.4.2:
Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria.
Only allow authorized personnel to access the gathered information, and prevent any alteration or deletion of the information. Carefully manage the list of repository owners and organization owners who have the ability to view audit logs, delete organizations, and delete code repositories, and review the list annually.
|
GitHub
|
|
GitHub
|
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.
| Tasks |
Tools |
|
PO.5.1:
Separate and protect each environment involved in software development.
Require multifactor authentication, SSH keys, signed commits, and code change approvals for code repositories at the organization level.
|
GitHub Organization Settings
|
|
GitLab
|
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) CI/CD Steps
Protect the Software (PS)
Organizations should protect all components of their software from tampering and unauthorized access.
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.
| Tasks |
Tools |
|
PS.1.1:
Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.
Store all source code and configuration-as-code in a code repository, and restrict access to it based on the nature of the code. For example, open source code intended for public access may need its integrity and availability protected; other code may also need its confidentiality protected.
|
GitHub
|
|
GitLab
|
|
Bitbucket
|
|
SourceForge
|
|
Subversion
|
|
PS.1.1:
Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.
Use version control features of the repository to track all changes made to the code with accountability to the individual account.
|
Git
|
|
GitHub
|
|
GitLab
|
|
Bitbucket
|
|
SourceForge
|
|
Subversion
|
|
GitBucket
|
|
Gitea
|
|
gittuf
|
|
PS.1.1:
Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.
Use commit signing for code repositories to sign code.
|
GitHub Signing Commits
|
|
About commit signature verification
|
|
GitLab Signed Commits
|
|
Bitbucket Sign Commits and Tags with SSH keys
|
|
Bitbucket Sign Commits and Tags with X.509 certificates
|
|
Bitbucket Using GPG Keys
|
|
Sigstore
|
|
PS.1.1:
Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.
Have the code owner review and approve all changes made to the code by others.
|
Github CODEOWNERS
|
|
GitHub Code Review
|
|
Gitlab CODEOWNERS
|
|
Gitlab Code Review Guidelines
|
|
Bitbucket Set Up and Use Code Owners
|
|
Bitbucket Code Review
|
|
PS.1.1:
Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.
Use cryptography (e.g., cryptographic hashes) to help protect file integrity
|
GitHub About Commits
|
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.
| Tasks |
Tools |
|
PS.2.1:
Make software integrity verification information available to software acquirers.
Post cryptographic hashes for release files on a well-secured website.
|
Apache Infrastructure Signing Releases
|
|
OpenPGP
|
|
The GNU Privacy Guard
|
|
PS.2.1:
Make software integrity verification information available to software acquirers.
Use an established certificate authority for code signing so that consumers’ operating systems or other tools and services can confirm the validity of signatures before use. Periodically review the code signing processes, including certificate renewal, rotation, revocation, and protection.
|
Let's Encrypt
|
|
EJBCA Community
|
|
Dogtag Certificate System
|
|
OpenXPKI
|
|
Step-CA
|
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.
| Tasks |
Tools |
|
PS.3.1:
Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.
Store the release files, associated images, etc. in repositories following the organization’s established policy. Allow read-only access to them by necessary personnel and no access by anyone else.
|
Access Permissions on GitHub
|
|
GitLab Roles and Permissions
|
|
Bitbucket Grant Repository Access to Users and Groups
|
|
PS.3.1:
Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.
Store and protect release integrity verification information and provenance data, such as by keeping it in a separate location from the release files or by signing the data.
|
GitHub Repository Roles for an Organization
|
|
GitLab Roles and Permissions
|
|
Bitbucket Grant Access to a Workspace
|
|
Ortelius
|
|
PS.3.2:
Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a Software Bill of Materials (SBOM)).
Make the provenance data available to software acquirers in accordance with the organization’s policies, preferably using standards-based formats.
|
AI SBOM Generator
|
|
CycloneDX
|
|
Software Identification (SWID) Tagging Tools and Utilities
|
|
SPDX
|
|
PS.3.2:
Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a Software Bill of Materials (SBOM)).
Make the provenance data available to the organization’s operations and response teams to aid them in mitigating software vulnerabilities.
|
bomctl
|
|
OWASP Dependency-Check
|
|
Dependency-Track
|
|
Clair
|
|
Grype
|
|
Ortelius
|
|
Protobom
|
|
Syft
|
|
Tern
|
|
Trivy
|
|
PS.3.2:
Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a Software Bill of Materials (SBOM)).
Protect the integrity of provenance data, and provide a way for recipients to verify provenance data integrity.
|
aoss-verifier
|
|
Sigstore
|
|
TLSNotary Protocol
|
|
PS.3.2:
Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a Software Bill of Materials (SBOM)).
Update the provenance data every time any of the software’s components are updated.
|
GitHub Actions
|
|
GitLab CI/CD
|
|
Bitbucket Pipelines
|
|
CircleCI
|
|
Travis CI
|
|
Updatecli
|
|
Renovate
|
1.1.3 - Produce Well-Secured Software (PW)
Produce Well-Secured Software (PW) CI/CD Steps
Produce Well-Secured Software (PW)
PW.4.1 Acquire and Maintain Well-secured Software
Ensure safe use of components (e.g., software libraries, modules, middleware, frameworks) from commercial, open-source, and other third-party developers for use by the organization’s software. Implement a Software Bill of Materials (SBOM) scan to obtain provenance information for each software component. Establish one or more software repositories to host sanctioned and vetted open-source components.
Open-Source Tools to Achieve:
SBOM Generation and Attestation Tools:
Binary Repositories:
Git Commit Signing:
Repo Security Scanning
PW.7 Review and/or Analyze Human-Readable Code
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.
Open-Source Tools to Achieve:
1.1.4 - Respond to Vulnerabilites
Respond to Vulnerabilities (RV) CI/CD Steps
Respond to Vulnerabilities (RV)
Task: Identify and Respond to Vulnerabilities
How to Achieve: 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
Open-Source Tools to Achieve:
Identify Vulnerabilities
Static Application Security Testing (SAST):
Dynamic Application Security Testing (DAST):
Software Composition Analysis (SCA):
RV.2 Assess, Prioritize, and Remediate Vulnerabilities
RV.3 Identify Root Cause and help to reduce frequency of vulnerabilities in the future
2 - Phase 2: Build and Deploy
Security Compliance for Build and Deploy
Introduction
As software moves from development to production, the build and deploy stages play a pivotal role in maintaining the integrity, security, and provenance of your application. These phases involve compiling, packaging, and preparing your application for its live environment, making them prime targets for supply chain attacks, unauthorized modifications, and hidden vulnerabilities.
Integrating security into these phases ensures that your code is not only functional but also safeguarded against threats. From dynamic analysis during builds to automated scans for container security and misconfigurations, the right tools can help identify risks before deployment. Moreover, secure deployment pipelines prevent unauthorized changes, enforce compliance, and enable safe rollouts. Compliance for Build and Deploy steps include:
|
|
| Reproducible and Deterministic Builds |
Ensure that software artifacts can be independently verified and reproduced to prevent tampering. |
| Automated Threat Detection and Compliance Enforcement |
Integrate continuous security analysis to detect misconfigurations, vulnerabilities, and unauthorized dependencies before deployment. |
| Policy-Enforced Deployments |
Enforce verifiable security policies ensuring only compliant, attested software reaches production. |
| Trusted Execution Environments (TEEs) |
Secure build environments against tampering using hardware-backed execution environments. |
| Cryptographic Attestation |
Use digital signatures and cryptographic proofs to verify the authenticity and integrity of builds and deployments. |
Following are guidelines from industry frameworks with suggested open source tooling needed to achieve the compliance goals.
2.1 - Secure Software Development Framework
Secure Software Development Framework and Build/Deploy CI/CD Steps
Achieving Build and Deploy Tasks of 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. This chapter focuses specifically on DevSecOps tooling and practices related to Build and Deploy actions of the CI/CD pipeline to achieve:
|
|
| Prepare the Organization (PO) |
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. |
| Protect the Software (PS) |
Organizations should protect all components of their software from tampering and unauthorized access. |
| Produce Well-Secured Software (PW) |
Organizations should produce well-secured software with minimal security vulnerabilities in its releases. |
| 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. |
2.1.1 - Protect the Organization (PO)
Protect the Organization (PO) CI/CD Steps
Protect the Organization (PO)
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.
2.1.2 - Protect the Software (PS)
Protect the Software (PS) CI/CD Steps
Protect the Software (PS)
2.1.3 - Produce Well-Secured Software (PW)
Produce Well-Secured Software (PW) CI/CD Steps
Produce Well-Secured Software (PW)
A Software Bill of Materials (SBOM) provides visibility into software components, dependencies, and security risks**. When combined with attestation mechanisms, SBOMs enhance trust and traceability across the software supply chain.
Open Source Build Signing and Verification
Ensuring software artifacts remain authentic and unmodified** is essential for a trusted software supply chain**. The following tools provide cryptographic verification** to protect against supply chain attacks**.
Beyond open-source tools, a secure build and deploy pipeline relies on trusted execution environments, deterministic build systems, cryptographic verification, and policy-enforced deployment mechanisms. These technologies provide tamper-proof guarantees, verifiable attestations, and automated security policies to strengthen the software supply chain.
1. Reproducible and Deterministic Build Systems
Ensuring that software builds are reproducible enhances security by allowing independent verification of artifacts. These systems minimize non-determinism and ensure that a given input always produces the same output.
2. Trusted Execution Environments (TEEs) and Confidential Computing
Trusted Execution Environments (TEEs) provide hardware-backed isolation to secure the build process, key management, and code execution. These environments ensure confidentiality and integrity in the build and deploy process and can be found in major cloud providers.
3. Cryptographic Signing and Verification ensures authenticity, integrity, and provenance in the software supply chain.
4. Secure Build and Deployment Policies
Automated security policy enforcement in CI/CD pipelines ensures only verifiably secure software is built and deployed.
.
2.1.4 - Respond to Vulnerabilities (RV)
Respond to Vulnerabilities (RV) CI/CD Steps
Respond to Vulnerabilities (RV)
3 - Phase 3: Post Deploy
Security Compliance for Post Deployment
Introduction
The post-deploy stage of your software delivery pipeline is where your application is live and actively serving users. While much of the focus in DevSecOps is on securing code, builds, and deployments, ensuring robust security doesn’t end there. The post-deploy phase is critical for monitoring, maintaining, and adapting to new threats in real time.
This phase includes tools and practices for continuous monitoring, vulnerability patch management, and incident response. From runtime application self-protection (RASP) to real-time threat detection and log analysis, post-deploy security ensures your application remains secure, compliant, and reliable in production.
Following are guidelines from industry frameworks with suggested open source tooling needed to achieve the compliance goals.
3.1 - Secure Software Development Framework
Secure Software Development Framework Post Build CI/CD Steps
Achieving Post Deploy Tasks of 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. This chapter focuses specifically on DevSecOps tooling and practices related to Post Deploy actions of the CI/CD pipeline to achieve:
|
|
| Prepare the Organization (PO) |
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. |
| Protect the Software (PS) |
Organizations should protect all components of their software from tampering and unauthorized access. |
| Produce Well-Secured Software (PW) |
Organizations should produce well-secured software with minimal security vulnerabilities in its releases. |
| 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. |
3.1.1 - Protect the Organization (PO)
Protect the Organization (PO) CI/CD Steps
Protect the Organization (PO)
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.
Open-Source Tools to Achieve:
3.1.2 - Protect the Software (PS)
Protect the Software (PS) CI/CD Steps
Protect the Software (PS)
Post Build Software Bill of Material Tools
DAST
Vulnerability Databases
Continuous Vulnerability Patch Management
Application Security Compliance Reporting
3.1.3 - Produce Well-Secured Software (PW)
Produce Well-Secured Software (PW) CI/CD Steps
Produce Well-Secured Software (PW)
3.1.4 - Respond to Vulnerabilities (RV)
Respond to Vulnerabilities (RV) CI/CD Steps
Respond to Vulnerabilities (RV)
Task: Identify and Respond to Vulnerabilities
How to Achieve: 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.
Open-Source Tools to Achieve: