MODEL
Threat model → SSDF in-scope tasks.
VibeReview reads your repo against the SSDF practice catalogue and names the PO, PS, PW, and RV tasks that apply to each service.
NIST SP 800-218 · FOR SOFTWARE FACTORIES
SSDF attestation evidence, generated where the code is written.
Software factories shipping to the US government need SSDF attestation under EO 14028. VibeReview maps every guardrail to a specific SSDF practice and task — PO, PS, PW, RV — so each PR ships with the per-task evidence your CISA self-attestation form needs.
14-day free trial · No card required
You prompting Cursor · app/api/uploads/sbom.py
"Take an SBOM upload, store it, and let downstream services pull it later."
VibeReview matched 3 SSDF tasks · invisibly - ✓ PW.4.1 — pin and verify third-party components by hash
- ✓ PW.5.1 — parameterized writes; reject path traversal in artifact_id
- ✓ RV.1.1 — emit structured event so SBOM ingest is monitorable
@app.post("/uploads/sbom")
def upload_sbom(
file: UploadFile,
actor = Depends(auth),
):
artifact_id = safe_id(file.filename) # PW.5.1
digest = verify_digest(
file, expected=request.headers["x-sha256"]
) # PW.4.1
storage.put(
f"sboms/{artifact_id}.json",
file.read(),
metadata={"sha256": digest},
)
audit.log(
"sbom.ingested", # RV.1.1
actor=actor.id,
artifact_id=artifact_id,
sha256=digest,
)✓ Components pinned (PW.4.1), inputs sanitised (PW.5.1), ingest observable (RV.1.1). Three SSDF tasks attested on the first prompt.
ENFORCE
Guardrails → PW, PS, RV task IDs.
Every guardrail in your library carries the SSDF task it satisfies — PW.4 component reuse, PW.5 secure coding, PW.7 review, PW.8 testing, RV.1/2/3 response.
EVIDENCE
PR review → per-task evidence trail.
Each pull-request review names the SSDF task evaluated, the file changed, and the outcome. The audit log is your evidence trail.
ATTEST
Attestation pack → CISA form-ready.
Mapping reports follow the CISA Secure Software Development Attestation Form layout. Hand it to your federal sponsor or 3PAO without rework.
WHAT'S COVERED
NIST SSDF practices and the VibeReview guardrails behind them.
Mapped against SP 800-218 v1.1. Coverage is repo-dependent; your attestation pack names the tasks enforced for each service.
- PO — Prepare the Organization: PO.1 (security requirements), PO.3 (toolchain), and PO.5 (secure environments) wired to repo configuration, CI tooling, and branch-protection patterns. Threat-model output captures the security requirement set per service.
- PS — Protect the Software: PS.1 (protect code from tampering) and PS.2 (provenance: SBOM, signed artifacts) enforced through commit-signing guardrails, SBOM-emission patterns, and dependency-pinning rules. PS.3 archive/protect rules covered for release artifacts.
- PW.4 — Reuse existing, well-secured software: Component pinning by hash, allow-listed registries, license + provenance checks. Every dependency change cites PW.4.1 / PW.4.4 evidence.
- PW.5 — Create source code by adhering to secure coding practices: Input validation, output encoding, parameterized queries, safe deserialization, secrets-handling. Generated by the IDE before the diff exists.
- PW.6 — Configure build, interpreter, and compilation processes: Compiler hardening flags, reproducible builds, dependency lockfiles. Build-config guardrails enforced as code.
- PW.7 — Review and analyse code: Every diff runs the matching guardrails as a per-change review. The PR review log is direct PW.7.1 / PW.7.2 evidence.
- PW.8 — Test executable code: Test-generation guardrails ensure negative-path coverage for each finding class. Coverage stamped against PW.8.1 / PW.8.2.
- PW.9 — Configure software to have secure settings by default: Secure-by-default framework patterns, headers, auth defaults, encryption-at-rest. Each scaffolded service ships with PW.9-aligned defaults.
- RV.1 — Identify and confirm vulnerabilities on an ongoing basis: PR-time review surfaces issues at the moment of authoring. RV.1.1 / RV.1.2 evidence written for every reviewed change.
- RV.2 — Assess, prioritise, and remediate: Findings carry severity, CWE, and the suggested remediation patch in-IDE. Decision and disposition are logged.
- RV.3 — Root-cause and prevent recurrence: Each closed finding generates or updates a guardrail so the same class can't reappear. The guardrail Git history is your RV.3 trail.
- EO 14028 attestation: Per-task evidence rolls up into the CISA Secure Software Development Attestation Form structure. Designed for software factories selling to federal agencies and integrators serving DoD, civilian, and IC customers.
Ready your software factory for SSDF attestation.
We walk you through SSDF task coverage for your repos and the evidence pack your federal sponsor or 3PAO needs. Bring your compliance lead.