Secure Software Development (NIST SP 800-218 SSDF)

Date: 2026-10-11 Version: 1.1 Framework: NIST SP 800-218 v1.1, Secure Software Development Framework (SSDF)

1. Purpose

Map each SSDF practice to the evidence in this repository, so a federal buyer, an assessor, or the officer who signs CISA’s Secure Software Development Attestation Form can check it rather than take it on trust.

NIST doesn’t certify software against the SSDF. A US federal agency buying software asks its producer to attest to the SSDF practices (OMB M-22-18 and M-23-16), on CISA’s Secure Software Development Attestation Form, signed by the producer’s CEO or a designee. For NeuralMind that is Cheval-Volant LLC. This document is the evidence behind that signature. It isn’t the attestation itself.

For the other NIST documents (FIPS 140-3, SP 800-171, SP 800-53, AI RMF) and what’s planned, see NIST.md.

2. How to verify a release yourself

Every release from the version that ships this document onward is signed and carries build provenance. These commands need no access to the repository beyond reading it:

# The container image: a keyless Sigstore signature from the release workflow
cosign verify ghcr.io/dfrostar/neuralmind:vX.Y.Z \
  --certificate-identity-regexp '^https://github\.com/dfrostar/neuralmind/\.github/workflows/docker-publish\.yml@refs/(heads/main|tags/v[0-9]+\.[0-9]+\.[0-9]+)$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

# Its build provenance (which workflow, commit and runner built it)
gh attestation verify oci://ghcr.io/dfrostar/neuralmind:vX.Y.Z --repo dfrostar/neuralmind \
  --cert-identity-regex '^https://github\.com/dfrostar/neuralmind/\.github/workflows/docker-publish\.yml@refs/(heads/main|tags/v[0-9]+\.[0-9]+\.[0-9]+)$'

# The wheel or sdist you downloaded
pip download --no-deps neuralmind==X.Y.Z -d dist/
gh attestation verify dist/neuralmind-X.Y.Z-py3-none-any.whl --repo dfrostar/neuralmind \
  --cert-identity-regex '^https://github\.com/dfrostar/neuralmind/\.github/workflows/release\.yml@refs/(heads/main|tags/v[0-9]+\.[0-9]+\.[0-9]+)$'

The identity patterns pin both the workflow and the git ref it ran from: main, where release-please dispatches releases, or a vX.Y.Z tag. A signature from the same workflow run on any other branch fails them. --repo alone would accept it.

The release workflow runs the first two against every image it publishes and fails before :latest moves if either doesn’t verify.

3. Practice-by-practice evidence

“Evidence” is what the repository shows. “Not shown here” is what the SSDF asks for that a repository can’t demonstrate, such as account security and settings outside version control. The attesting officer confirms those directly.

PO: Prepare the Organization

PS: Protect the Software

PW: Produce Well-Secured Software

RV: Respond to Vulnerabilities

4. The VEX document

security/neuralmind.openvex.json is an OpenVEX document listing the advisories in NeuralMind’s dependencies that NeuralMind is not affected by, and why. Today those are the four ChromaDB advisories argued in SECURITY.md: ChromaDB is an opt-in extra, and NeuralMind uses only its local PersistentClient. Feed it to a scanner that reads VEX (Grype --vex, Trivy --vex) together with the release SBOM, and those advisories are shown as not affected rather than open.

Three things keep it honest:

• CI’s pip-audit ignores exactly the advisories it lists (scripts/vex_ignores.py). Any other advisory fails the build.
• tests/test_vex.py fails if an entry lacks an argument in SECURITY.md, or if the list drifts from the advisories chromadb-cve-watch.yml watches.
• When ChromaDB ships a fix, the watch files an issue. The statement then comes out of VEX, and the pin moves.