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

GitHub CODEOWNERS is a repository feature that lets teams formally define who owns which parts of the codebase and who must review changes before they’re merged.

GitLab CODEOWNERS

GitLab CODEOWNERS is a repository feature that lets teams formally define who owns which parts of the codebase and who must review changes before they’re merged.

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

Backstage Software Templates are a scaffolding and standardization mechanism that help teams create new services, pipelines, and infrastructure in a consistent, compliant way. Backstage Software Templates let platform teams define golden paths for creating software components. A template captures best practices, required tooling, and organizational standards, then generates repositories, configs, and documentation automatically.

Konflux-ci software factory for Tekton

The Konflux software factory for Tekton is a secure, standardized CI build system that sits on top of Tekton to turn raw pipelines into a trusted software supply-chain factory. Konflux is Tekton with guardrails. Tekton provides the pipeline engine (tasks, pipelines, Kubernetes execution). Konflux adds the factory layer that enforces how those pipelines are allowed to run so the outputs can be trusted. Implements the in-toto framework.

CDF CDEvents

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

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

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

Jenkins Jenkinsfile

A Jenkins Jenkinsfile is a declarative or scripted definition of a CI/CD pipeline, written as code and stored directly in a source repository. A Jenkinsfile describes how software is built, tested, scanned, packaged, and deployed. Because it lives alongside the application code, it enables pipeline-as-code—versioned, reviewable, and auditable automation.

GitHub Actions (.github/workflows)

The GitHub Actions .github/workflows directory is the central location where CI/CD automation is defined as code for a GitHub repository. The directory contains YAML files that define workflows. Each workflow describes when automation should run and what jobs and steps are executed in response to repository events.

GitLab CI/CD (.gitlab-ci.yml)

The GitLab CI/CD .gitlab-ci.yml file is the single, authoritative pipeline definition that tells GitLab how to build, test, secure, and deploy an application. .gitlab-ci.yml is a YAML-based, pipeline-as-code configuration file stored at the root of a repository. It defines what jobs run, in what order, and under which conditions whenever code changes occur.

Spinnaker Dinghy

Spinnaker Dinghy is a configuration-as-code service that lets teams define and manage Spinnaker deployment pipelines using Git, instead of clicking through the UI. Dinghy allows Spinnaker pipelines to be written as JSON or YAML files and stored in a source repository. When changes are committed, Dinghy automatically syncs those pipeline definitions into Spinnaker, keeping deployments consistent and versioned.

Argo CD

Argo CD is a GitOps-based continuous delivery tool for Kubernetes that automatically deploys and keeps applications in sync with what’s declared in Git. Argo CD treats Git as the single source of truth for Kubernetes applications. Instead of pushing deployments from a CI pipeline, Argo CD pulls desired state from Git and continuously reconciles running clusters to match it.

Tekton Pipelines-as-Code

Tekton Pipelines-as-Code is a Git-driven way to define and run Tekton CI/CD pipelines directly from pull requests—treating pipelines as first-class code artifacts.

OpenTofu

OpenTofu is an open-source Infrastructure as Code (IaC) tool used to define, provision, and manage cloud and on-prem infrastructure using declarative configuration files.

Konflux-ci

Konflux is an open-source, cloud-native CI platform designed to produce trusted, reproducible, and verifiable software artifacts for modern software supply chains. It prioritizes build integrity, provenance, and repeatability, making it well-suited for regulated, enterprise, and critical-infrastructure environments.

Python: pylock.toml (preferred, newest standard)

• uv — uses pylock.toml
• conda-lock — reproducible, less standard
• pip freeze — not fully reproducible

JavaScript:

• package-lock.json — use with npm ci
• yarn.lock

Java / Kotlin / Groovy: Maven, Gradle

C# / .NET: NuGet lock files , DotNet.ReproducibleBuilds

C++: Bazel

Rust: Cargo

Golang: Go reproducible builds

PHP Composer

Composer is the standard dependency manager for PHP, used to declare, install, and manage third-party libraries required by a PHP application. Composer lets developers define which PHP packages their project depends on and automatically resolves, downloads, and installs the correct versions. It ensures that every environment—developer laptops, CI systems, and production—uses the same dependency set.

SLSA Framework

The SLSA Framework (Supply-chain Levels for Software Artifacts) is a security framework that defines how to build software in a way that is verifiable, tamper-resistant, and trustworthy.

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

GitHub Issues is a built-in tracking system used to manage work, bugs, feature requests, and discussions directly within a GitHub repository.

GitLab work tracking

GitLab Work Tracking is GitLab’s integrated system for planning, tracking, and managing work—from ideas and requirements to code, security fixes, and delivery.

Bugzilla

Bugzilla is an open-source bug tracking and issue management system used to report, track, and manage software defects and enhancement requests throughout the development lifecycle.

Redmine

Redmine is an open-source project management and issue-tracking tool used by software teams to plan work, track bugs and tasks, and manage projects over time.

Mantis Bug Tracker

Mantis Bug Tracker (often called MantisBT) is an open-source, web-based bug and issue tracking system designed to be simple, fast, and lightweight.

Trac

Trac is an open-source, web-based project management and issue-tracking system that tightly integrates tickets, a wiki, and source-code browsing. It’s known for being lightweight, text-centric, and developer-friendly.

in-toto framework

in-toto is an open-source framework for securing the software supply chain by cryptographically recording and verifying every step of how software is built, tested, and released.

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

GitHub Issue Templates are predefined forms and guidelines that appear when someone opens a new issue in a repository. They help teams collect consistent, high-quality information for bugs, feature requests, security issues, or questions.

GitLab Description Templates

GitLab Description Templates are predefined Markdown templates that automatically populate the description field when someone creates a GitLab Issue, Merge Request (MR), or Epics.

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

Collect audit logs for code repositories.

GitHub

• Audit Logs

GitLab

Audit Logs

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

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

GitHub

• Roles in an Organization
• GitHub Repository Roles

GitLab

• Roles and Permissions

Separate and protect each environment involved in software development.

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

GitHub Organization Settings

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

GitLab

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

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

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

Provides a centralized source code repository with access control, auditability, and workflow enforcement supporting SSDF practices for secure code management and change control.

Delivers integrated source control, CI/CD, and security workflows that enable SSDF-aligned governance, traceability, and secure development processes.

Supports SSDF by managing source code with role-based access, commit integrity options, and mandatory review workflows.

Hosts and distributes open-source projects with version control and release management supporting SSDF requirements for code provenance and transparency.

Provides centralized version control enabling SSDF practices for change tracking, audit trails, and controlled access to source code.

Enables immutable history, traceability, and distributed development workflows foundational to SSDF source integrity and accountability.

Offers Git-based repository hosting with access control and collaboration features supporting SSDF secure development governance.

Provides lightweight, self-hosted Git repositories that support SSDF requirements for controlled source management and auditability.

Strengthens SSDF compliance by enforcing cryptographic policies and verifiable trust metadata over Git repositories and workflows.

Ensures SSDF-aligned source integrity by cryptographically verifying the identity of commit authors.

Enables SSDF-aligned artifact and commit verification through keyless, auditable cryptographic signing and transparency logs.

Enforces SSDF role separation and accountability by requiring designated owners to review and approve code changes.

Supports SSDF secure development by enforcing peer review, policy checks, and approval gates before code integration.

Implements SSDF responsibility assignment by automatically routing changes to accountable reviewers.

Establishes SSDF-aligned review standards that reduce defects and security risks prior to merging code.

Make software integrity verification information available to software acquirers.

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

Supports SSDF by ensuring that Apache software releases are cryptographically signed and verifiable, establishing trusted provenance and protecting against tampered distribution artifacts.

Provides SSDF-aligned cryptographic mechanisms for signing and verifying code and artifacts to ensure authenticity, integrity, and non-repudiation.

Implements OpenPGP standards to enable SSDF practices for signing source code, commits, and releases with verifiable developer identity.

Supports SSDF secure delivery by issuing free, automated TLS certificates that protect software distribution channels and developer services from interception and tampering.

Enables SSDF compliance by providing an open-source PKI for managing certificates used to authenticate developers, systems, and software artifacts.

Supports SSDF trust and identity requirements by issuing and managing digital certificates for secure software signing and infrastructure authentication.

Provides SSDF-aligned certificate lifecycle management to establish, audit, and enforce trust across software development and release pipelines.

Enables SSDF automation of cryptographic identity by issuing short-lived certificates for developers, CI/CD systems, and software signing workflows.

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.

Enforces SSDF role-based access control by restricting who can view, modify, or administer source code repositories.

Supports SSDF governance by defining granular roles that enforce least privilege and separation of duties across the SDLC.

Implements SSDF organizational controls by standardizing permission levels across teams and repositories.

Implements SSDF organizational controls by standardizing permission levels across teams and repositories.

Extends SSDF controls beyond source code by enforcing access, traceability, and accountability over deployed software, SBOMs, and live environment metadata through a deployment-centric digital twin.

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.

Supports SSDF by automatically generating and maintaining accurate software bills of materials that improve component visibility and vulnerability traceability across the SDLC.

Enables SSDF-aligned component transparency by providing a standardized SBOM format optimized for security, integrity, and risk analysis.

Support SSDF practices by uniquely identifying installed software components to enable asset inventory, provenance tracking, and vulnerability correlation.

Provides an SSDF-compliant standard for documenting software components, licenses, and relationships to support supply-chain transparency and compliance.

Supports SSDF SBOM consumption by validating, querying, and managing SBOMs throughout build and release workflows.

Enables SSDF vulnerability detection by identifying known CVEs in third-party dependencies during development and build phases.

Supports SSDF risk management by continuously analyzing SBOMs to monitor component vulnerabilities and policy compliance.

Contributes to SSDF by scanning container images for known vulnerabilities prior to deployment.

Supports SSDF secure build practices by detecting known vulnerabilities in container images and file systems using SBOM data.

Extends SSDF beyond build time by correlating and aggregating SBOMs, vulnerabilities, and deployment metadata to identify which live environments are actually at risk.

Supports SSDF interoperability by providing reusable libraries and tools for generating and transforming SBOMs across formats.

Enables SSDF component discovery by generating SBOMs from source code, containers, and runtime artifacts.

Supports SSDF SBOM sharing and discovery by enabling secure distribution and retrieval of SBOM artifacts.

Contributes to SSDF transparency by analyzing container images to produce detailed component inventories and SBOMs.

Supports SSDF secure development by scanning for vulnerabilities, misconfigurations, and exposed secrets across code and artifacts.

Enables SSDF compliance validation by verifying the integrity and authenticity of open-source artifacts.

Supports SSDF provenance by enabling cryptographically verifiable signing of artifacts and SBOMs with transparency logs.

Contributes to SSDF trust by providing cryptographic proof of data integrity for externally retrieved security and dependency metadata.

Enables SSDF automation by embedding security checks, SBOM generation, and policy enforcement directly into CI workflows.

Jenkins is a fully open-source automation server, released under the MIT License, with an extensible plugin ecosystem governed by the Jenkins community and widely used to implement SSDF-aligned CI/CD security controls.

Supports SSDF remediation by automating dependency, configuration, and policy updates in a controlled and auditable manner.

Enables SSDF secure maintenance by automatically updating vulnerable dependencies while preserving review and approval controls.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PW.4.3: Moved to PW.4.4

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

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

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

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

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

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

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

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

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

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

Creates PRs to meet policy-defined security versions.

Ensures repositories meet defined configuration criteria before allowing merges.

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

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

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

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

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

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

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

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

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

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

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

NET testing framework; supports integration with security validation tests.

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

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

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

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

Testing framework for Java; integrates with security automation.

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

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

Static vulnerability scanning for container images before deployment.

Vulnerability scanner for containers and filesystems.

Python-specific static analyzer for common security issues.

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

Rails-specific static analyzer for security vulnerabilities.

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

Detects secrets and sensitive information in code history and commits.

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

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

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

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

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

Provides component inventory to validate against predefined acceptance criteria.

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

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

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

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

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

Integrated into CI to detect Java vulnerabilities pre-release.

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

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

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

Blocks builds that include components with vulnerabilities exceeding severity thresholds.

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

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

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

Verifies cryptographic signatures of source tarballs and dependencies before build.

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

Integrated into CI to detect Java vulnerabilities pre-release.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Semantic code analysis to find vulnerabilities before build.

SCA tool that identifies vulnerable dependencies in manifests before packaging.

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

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

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

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

Searches code and git history for secrets before build.

Searches code and git history for secrets before build.

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

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

Finds misconfigurations and insecure defaults in IaC files before build.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Vulnerability scanner specifically designed for Ruby on Rails applications.

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

Prevent hardcoded secrets in code and configs.

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

Hoppr is an SBOM / supply-chain utility kit—SBOM processing and movement of supply-chain “materials” aligns to provenance collection/maintenance/sharing.

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

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

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

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

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

Exposes the blast radius of each vulnerability across live environments.

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

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

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

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

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

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

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

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

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

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

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

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

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

Tracks vulnerable components and shows recurring dependency-related issues.

A vulnerability scanner for container images and file systems.

Correlates SBOMs across releases to identify repeated dependency issues.

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

Finds repeated insecure coding practices in Rails apps.

Enforces code quality/security hooks before commits.

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

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

Adds IaC guardrails to prevent insecure configurations at commit time.

Finds security vulnerabilities, compliance issues, and infrastructure misconfigurations.