The SSDF, practiced in the pull request.
NIST SP 800-218, the Secure Software Development Framework (SSDF), is a set of practices for producing secure software, grouped in four: prepare the organization (PO), protect the software (PS), produce well-secured software (PW), and respond to vulnerabilities (RV). Most of PO is policy and people. PS, PW and RV are where the practices meet a repository, and where a single change can quietly stop practicing them.
Nobody certifies you against the SSDF.
There is no SSDF certification. Software producers describe, and when a customer asks, attest to, the practices they follow, and the framework leaves the how to them: each practice comes with tasks and notional examples, not a required tool. That makes the evidence the practice itself, visible in how changes are actually made. This page cites SSDF v1.1, the current version; the Rev. 1 draft keeps the practice structure these pages use.
Review againstNIST_800_218is available when it is explicitly selected in your heyGRC organization configuration. Unconfigured installations review against ISO 27001, SOC 2, and GDPR until someone saves a selection.
The SSDF practices a review can actually catch.
Each row is a real practice reference and the kind of change that trips it. heygrc cites the practice on the finding.
- PS.1protect all forms of code
Required review is removed for a path, a code-owner rule is deleted, or a deploy key gains write access, so code can change without the protection it had.
- PW.4reuse well-secured software
A dependency is pulled from a moving branch or an unvetted fork instead of a released, pinned version, or a vendored copy of a library is edited in place.
- PW.5secure coding practices
New code builds a query, command, or path from untrusted input, or handles secrets and errors in a way the secure coding standard rules out.
- PW.7review and analyze human-readable code
A code-analysis finding is silenced inline instead of triaged, a review requirement is bypassed, or analysis stops covering part of the codebase.
- PW.8test executable code
Security tests are skipped or deleted, or a release pipeline stops running the dynamic tests it used to run before shipping.
- PW.9secure settings by default
A default flips to the permissive option: debug on, verification off, a feature exposed unless someone turns it off.
- RV.1identify and confirm vulnerabilities
Dependency or vulnerability monitoring is disabled for a repository, or alerts are routed to nowhere, so new vulnerabilities stop being noticed.
Per-practice deep dives:
A dependency pulled from a moving branch.
A fix the team needs has landed in a library but is not released yet. To ship today, a change points the dependency at the fork's main branch. Every future install now takes whatever that branch holds at the time.
"dependencies": {- "pdf-render": "4.2.1",+ "pdf-render": "github:some-contributor/pdf-render#main", }This replaces a released, pinned version with a personal fork's main branch. The code installed from now on is whatever that branch holds at install time, from a source nobody vetted, with no version to review or roll back to. PW.4 expects reused components to be well-secured and acquired deliberately. Pin to a commit you have reviewed, or vendor the patch, until the fix is released upstream.
A review, not an attestation.
heygrc flags changes that touch an SSDF practice and cites the practice so the fix happens in the pull request. It does not write your secure development policy, sign an attestation, or decide which practices you follow. It catches the change that stops a practice, at the diff.