Produce Well-Secured Software (PW)
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
Tasks | Tools |
---|---|
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. |
|
Semgrep
Prevents insecure code from being packaged and deployed. |
|
Trivy
Ensures that deployed artifacts align with secure baseline configurations |
|
Zap (Zed Attack Proxy)
Enforces approved component lists and security baselines before deployment. |
|
Syft
Generates SBOMs for deployed applications for ongoing monitoring. |
|
OWASP Dependency-Track
Enforces approved component lists and security baselines before deployment. |
|
Grype
Focused vulnerability scanning for deployed artifacts. |
|
Nix
Guarantees that build artifacts match the security-approved design exactly, with no drift or environmental differences. |
|
GNU Guix
Ensures that all deployed artifacts are built from a traceable, verifiable environment that aligns with design security baselines. |
|
Bazel
Enforces secure build rules, prevents unauthorized changes, and produces identical outputs across build agents. |
|
Reproducible Builds Framework
Strengthens supply chain security by detecting unauthorized modifications between source and deployment. |
|
Apko (Chainguard)
Implements secure design principles like minimal attack surface and verified dependency selection. |
|
Sigstore(Cosign,Fulcio, Rekor)
Ensures artifacts come from a trusted, verified build process and haven’t been altered. |
|
Notary
Provides cryptographic assurance that deployed artifacts are authentic and untampered. |
|
In-Toto
Enforces integrity and accountability across the entire build-to-deploy pipeline. |
|
The Update Framework (TUF)
Protects the integrity of deployment and update distribution channels. |
|
OpenSSL
Generate and manage keys for signing build artifacts. Implement TLS/SSL for secure communication between build agents and artifact repositories. |
|
GnuPG
Sign source code, commits, and build outputs and verify signatures before deploying artifacts. |
|
Bouncy Castle
Embed cryptographic signing and verification into Java/.NET build pipelines. |
|
Keylime
Validate that deployment environments meet hardware-based integrity requirements before deployment. |
|
Ethereum Attestation Service (EAS)
Publish cryptographic attestations of build provenance or deployment approvals and provide a decentralized, tamper-proof audit log of artifact trust data. |
|
Kyverno
Enforce secure deployment design policies (e.g., approved base images, disallowed configurations). |
|
OPA
Enforce security design requirements at build time (e.g., dependency approval, CVE thresholds). Apply consistent policy enforcement from build pipelines to runtime. |
|
SPIFFE/SPIRE
Ensure that deployed workloads meet security requirements for mutual authentication and zero trust and bind workload identity to build-time provenance for deployment integrity. |
|
OWASP Threat Dragon
Embeds threat models into CI/CD, ensuring security requirements are tied to architectural components before build. (Meets PW.1.1 and PW.1.2) |
|
OWASP Amass
Helps to refine security requirements around network exposure and asset inventory. (Meets PW.1.1) |
|
CAIRIS
Integrates security requirements into system models, which can then be validated in build & deploy. (Meets PW.1.1) |
|
Threagile
Embeds threat models into CI/CD, ensuring security requirements are tied to architectural components before build. (Meets PW.1.1) |
|
Open-Needs
Requirements management tool for defining, tracking, and validating security requirements. Documents security requirements and links them to commits and build outputs.(Meets PW.1.1 and PW.1.2) |
|
rmtoo
Requirements management tool using plain text and version control for traceability. Supports traceability from design through build, ensuring requirements are carried into final artifacts.(Meets PW.1.2) |
|
OpenRMF® OSS
Open-source compliance and risk management framework tool for tracking RMF (NIST 800-37) controls. Security requirements map to formal compliance controls that can be verified in build & deploy artifacts. (Meets PW1.2) |
PW.2
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
-
atching misconfigurations and security gaps before release
Tasks | Tools |
---|---|
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. |
|
OPA
Automated design compliance gate in CI/CD |
|
Kyverno
Validates deployment configurations match approved security architecture. |
|
Checkov
Enforce network segmentation rules, encryption requirements, and secure defaults. |
|
KICS (Keeping Infrastructure as Code Secure)
Adds IaC review automation to the build process. |
|
Semgrep
Automated code review for alignment with security design requirements. |
|
Trivy (Config Scanning)
Config compliance verification before deploying. |
|
ThreatSpec
Ensures threat model-driven design requirements are implemented. |
|
Cartography
Post-build/pre-deploy architecture verification. Detect deviations from intended architecture. |
|
kube-score
Review Kubernetes manifests for design compliance before deployment.Ensures pod security settings match approved deployment designs. |
|
Dependabot
Automated dependency update PRs with vulnerability alerts. Helps verify dependencies meet security requirements (e.g., no known CVEs, minimum versions). |
|
OpenRMF
Open Risk Management Framework tracking tool. Can map design-level security requirements to NIST 800-53 controls and verify those controls are implemented in build configs. |
|
ESLint
Runs in CI/CD pipelines or as a pre-commit hook to block merges if code violates the approved security or architectural rules before build. | |
Grype
SBOM-driven vulnerability scanner for images/filesystems. Validates that dependencies in the build match security baselines and are free from disallowed components. |
|
Clair
Static vulnerability analysis for container images. Confirms final images meet design security requirements before deployment. |
|
Terrascan
IaC scanning and policy enforcement (OPA-based). Enforces approved security design in Terraform, Kubernetes, Docker, and AWS CloudFormation configs before deploy. |
|
Gerrit
Code review and approval workflow tool. Enforces human review against design and security requirements before merge to release branches. |
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
Tasks | Tools |
---|---|
PW.4.1: Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, opensource, and other third-party developers for use by the organization’s software. PW.4.2: Create and maintain well-secured software components in-house following SDLC processes to meet common internal software development needs that cannot be better met by third-party software components. PW.4.3: Moved to PW.1.3 PW.4.4: Verify that acquired commercial, open-source, and all other third-party software components comply with the requirements, as defined by the organization, throughout their life cycles. |
|
Kyverno
Ensures manifests meet secure baseline defaults before deployment. |
|
OPA
Validates default configurations meet security requirements. |
|
Checkovn
Detects and blocks insecure defaults in Terraform, Helm, or CloudFormation before release. |
|
KICS (Keeping Infrastructure as Code Secure)
Validates hardened defaults in cloud infrastructure provisioning. |
|
Trivy
Automated config compliance check during CI/CD. |
|
CIS-CAT Lite
Automates compliance testing for secure defaults. |
|
DevSec Hardening Framework
Bakes hardened defaults into container or VM images before release. |
|
kube-score
Pre-deployment validation of secure defaults in manifests. |
|
OpenSCAP
Ensures deployed OS images meet hardened defaults. |
|
CycloneDX
SBOM format for documenting exact components/configurations in final build; helps verify secure defaults are present. |
|
SPDX
SBOM standard to record all components, licenses, and provenance; can confirm inclusion of hardened dependencies. |
|
ArtifactHub
Catalog of verified Helm charts, OLM operators, etc.; can enforce use of curated, secure-by-default packages. |
|
JFrog Artifactory OSS
Repository manager for storing signed, verified artifacts with access controls. |
|
Sonartype Nexus OSS
Host artifacts and enforce policy checks before they’re promoted. |
|
Harbor
OCI registry with vulnerability scanning, content signing, and policy enforcement for images. |
|
GitLab Signing
Commit/tag signing in GitLab CE for provenance. |
|
GitHub CodeQL
Detects code patterns violating security requirements. |
|
AquaSec Trivy
Scans container images, IaC, and configs for insecure defaults. |
|
Allstar
GitHub App enforcing security policies in repos. |
|
OWASP SAMM
Security maturity model to guide secure default practices. |
|
OWASP ASVS
Application security requirements to verify secure defaults. |
|
OWASP Defectdojo
Central vulnerability tracking; ensures issues found in builds are fixed before release. |
|
OWASP Dependency-Check
Detects known-vulnerable dependencies in builds. |
|
Gitea
Self-hosted Git service with signing/policy support. |
|
GitLab (Community Edition)
Git platform with signing, scanning, CI/CD policy integration. |
|
Pytest
Automated testing to confirm defaults work. |
|
Selenium
Functional/UI test automation to verify secure settings. |
|
Playwright
Functional/UI test automation to verify secure settings. |
|
OWASP ZAP
DAST scanner to verify app defaults are not exploitable. |
|
TestNG
Java test framework for security/functional checks |
|
Cucumber
BDD framework for verifying functional + security requirements. |
|
Clair
Image vulnerability scanner for OCI registries. |
|
Grype
SBOM-driven vuln scanner for builds and images |
|
Bandit for Python
Detects insecure code patterns/defaults in Python. |
|
Semgrep
Finds policy-violating patterns in code. |
|
Brakeman
Detects Rails-specific security issues/defaults. |
|
Gitleaks
Detects secrets in code (prevents default creds exposure). |
|
TruffleHog
Finds secrets in repos/history to avoid insecure defaults. |
|
OWASP Dependency-Check
Detects known-vulnerable dependencies in builds.> |
|
OSS Review Toolkit (ORT)
Automates license/security checks; blocks noncompliant components. |
|
FOSSA (Community Edition)
License/dependency scanning; ensures compliance with default policies. |
|
ScanCode Toolkit
Detects license, copyright, and security metadata in artifacts. |
|
Tern
Container image inspection for dependency/component details. |
|
Open Policy Agent (OPA)
Policy-as-code for build & deploy; blocks insecure defaults in configs/manifests. |
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.
Tasks | Tools |
---|---|
PW.5.1: Follow all secure coding practices that are appropriate to the development languages and environment to meet the organization’s requirements. |
|
Artifactory Community Edition
Acts as the central trusted artifact repository. |
|
Nexus Repository OSS
Acts as the central trusted artifact repository. |
|
Harbor
Acts as the central trusted artifact repository. |
|
Sigstore(Cosign,Fulcio, Rekor)
Ensures repository contents are authentic and tamper-free. |
|
Clair
Ensures stored artifacts meet vulnerability requirements before deployment |
|
In-Toto
Enforces provenance checks at repository ingestion. |
|
The Update Framework (TUF)
Protects against repository and update tampering. |
|
Notary (v2)
Controls supply chain intake and internal artifact storage. |
|
Tekton Chains
Ties repository artifacts back to secure build pipelines. |
|
Semgrep
Runs as part of the CI pipeline to automatically scan code for security flaws, policy violations, and unsafe patterns before artifacts are built. Supports rule-as-code to enforce secure build policies. |
|
Bandit for Python
Python-focused static analyzer that checks for insecure functions, weak crypto, and common security issues before packaging or deployment. |
|
FindBugs
Legacy Java static analysis; can be used to flag known insecure code patterns before build. Superseded by SpotBugs. |
|
SpotBugs
Modern replacement for FindBugs. Java bytecode scanner to enforce safe code practices before compiling final artifacts. |
|
SonarQube
Comprehensive SAST platform; can be integrated in CI/CD to enforce quality gates, stopping builds that fail security rules. |
|
OWASP ZAP
Runs against built/staged applications in pre-deployment environments to detect exploitable vulnerabilities, ensuring no insecure version is promoted. |
|
Arachni
Web application vulnerability scanner that can be part of a build’s QA stage to ensure secure release readiness. |
|
OWASP Dependency-Check
Scans for known-vulnerable dependencies in the build, blocking insecure versions from being 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.:
Tasks | Tools |
---|---|
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. |
|
Semgrep
Fast rule-based SAST with CI integration. |
|
SonarQube Community
General code quality + basic security rules. |
|
Bandit
Python SAST linters. |
|
Gosec
Go SAST linters. |
|
Brakeman
Rails SAST linters. |
|
FindSecBugs
Java SAST linters. |
|
Trivy
Vulnerability scan images/filesystems against SBOMs. |
|
Grype
Vulnerability scan images/filesystems against SBOMs. |
|
Syft
Generate SBOMs (SPDX/CycloneDX) during build. |
|
OWASP Dependency Track
Continuous SBOM monitoring and alerting post-build./p> |
|
Gitleaks
Block commits/builds that contain secrets; run in CI and as pre-commit hooks. |
|
Reproducible Builds
Provides methods, guidelines, and supporting tools for deterministic builds, ensuring integrity and verifiability of source-to-binary outputs. |
|
Bazel
Build system with hermetic (sandboxed) execution and explicit dependency tracking, preventing hidden or unverified dependencies. |
|
Meson
High-speed, deterministic build system that supports reproducibility and strict configuration-as-code. |
|
Apache Maven
Enforces controlled dependency resolution and supports reproducible builds for Java and JVM-based projects. |
|
Yocto Project
Creates reproducible, controlled build environments for embedded Linux images, preventing environmental drift. |
|
AOSP Build System
Uses prebuilt toolchains and sandboxed environments for secure, reproducible Android builds. |
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
Tasks | Tools |
---|---|
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. |
|
Semgrep
Runs automatically in CI before building deployment artifact. |
|
SonarQube Community Edition
Integrates with CI/CD to enforce clean code before release |
|
CodeQL
Detect SQL injection, XSS, or unsafe deserialization patterns in codebase. |
|
GitLeaks
Protects against secret leakage in deployed artifacts |
|
GitHub and GitLab
Require two reviewers for any code changes in security-critical modules. |
|
DefectDojo
Provides verifiable audit trail for security review completion. |
|
Sigstore Cosign
Provides verifiable audit trail for security review completion. |
|
OWASP Dependency-Check
Continuously scans dependencies in each build for new CVEs. Can run on every commit or nightly in CI/CD. |
|
OWASP ZAP
Can be automated in CI/CD to re-test staging environments for vulnerabilities as new code is deployed. |
|
Retire.js
Focused on JavaScript libraries; detects newly disclosed vulnerabilities in frontend/back-end packages during builds. |
|
Fossa
Scans dependencies for vulnerabilities and license issues, integrating with builds to catch new findings. |
|
Bandit for Python
Runs in CI/CD for Python projects to catch newly introduced security issues. |
|
Checkmarx KICS
Detecting Known Vulnerabilities – Compares IaC components and configurations against known security best practices and compliance frameworks (CIS Benchmarks, NIST, PCI-DSS). |
|
Cppcheck for C++
Re-scans C/C++ code after every build to ensure no new issues were introduced. |
|
FindSecBugs
Extension to SpotBugs that catches security flaws in Java bytecode continuously during the build cycle. |
|
GitHub CodeQL
Performs continuous security queries on code with each pull request or scheduled scan. |
|
PMD
Runs code quality and security rule checks on every commit/build. |
|
SpotBugs
Java static analysis integrated into the build pipeline for continuous vulnerability detection. |
|
Danger JS
Automates security-related PR review rules, preventing unsafe code from merging. |
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
Tasks | Tools |
---|---|
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. |
|
Trivy
Run as a CI step after image build, before push to registry |
|
Grype
Confirms that final executable meets vulnerability thresholds. |
|
Syft
Feeds SBOM into SCA tools like Dependency-Track for ongoing monitoring | |
OpenSCAP
Ensures final artifact matches secure configuration requirements. |
|
CIS-CAT Lite
Baseline enforcement step before promotion to production. |
|
Zap (Zed Attack Proxy)
Pre-release runtime security testing. |
|
In-toto + Sigstore Cosign Attestations
Provides verifiable evidence for compliance and audits. |
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
Tasks | Tools |
---|---|
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. |
|
DevSec Hardening Framework
Automates baseline hardening during image creation. |
|
Chainguard Apko
Produces secure-by-default container images. |
|
Trivy
CI gate to block insecure defaults from being built/deployed. |
|
Checkov
Prevents insecure IaC defaults from reaching deployment. |
|
KICS
Prevents insecure IaC defaults from reaching deployment. |
|
OpenSCAP
Produces compliance evidence before artifact promotion. |
|
Sigstore Cosign + In-Toto
Ensures only hardened, verified artifacts can be deployed. |
|
CIS-CAT Lite
Verify hardened defaults match CIS requirements before release. |
|
Kyverno
Policy enforcement for manifests and configs at build time. |
|
OPA Conftest
Codifies secure defaults as enforceable CI/CD policies. |