Before you buy a security tool, ask how the vendor secures its own software. NIST SP 800-218, the Secure Software Development Framework, gives you a shared vocabulary of four practice groups, and CISA publishes a self-attestation form built on it. Both help you ask specific questions and judge the answers.
Why ask at all
A scanner that runs in your pipeline or reads your repositories becomes part of your supply chain. If its build process is weak, you have added risk while trying to remove it. The SSDF describes itself as a core set of high level secure development practices that suppliers and purchasers can use as common language, and it explicitly names software acquirers as an audience.
The four groups as a question frame
The SSDF organizes practices into Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. You can map ten questions across them.
Prepare the Organization
- Which roles at the vendor are responsible for secure development, and how are developers trained?
- What security requirements apply to every release, and where are they written down?
Protect the Software
- How is source code access controlled and how are changes reviewed before merge?
- How do you protect build and release integrity, for example signed artifacts or recorded build provenance?
- Can you provide an SBOM for the product you are selling us?
Produce Well-Secured Software
- What testing runs on your own code before release (static analysis, dependency checks, dynamic testing)?
- How do you handle third party components, including selecting, updating, and retiring them?
Respond to Vulnerabilities
- How do customers report a vulnerability, and what is your target response process?
- How do you notify customers of fixed vulnerabilities in your product?
- What happens after a vulnerability is fixed: do you look for the same class of flaw elsewhere?
The last question echoes the SSDF description of the response group, which talks about preventing similar vulnerabilities in future.
How to read the CISA attestation form
CISA hosts a Secure Software Development Attestation Common Form, based on SSDF version 1.1, with a revision date of 14 May 2024 on the page we checked. The page says agencies may use the form and may ask producers for a current SBOM. It does not make the form a universal requirement for private buyers, so treat it as a useful template, not a rule that applies to your deal. If you are a federal contractor, read the current agency guidance directly.
Ask the vendor whether they have completed the form for other customers and whether they will share it. A vendor that has already done the work answers in a day. One that has not may still be fine, but the answers should come with evidence.
Judging the answers
Look for specifics. "We follow industry best practices" is a non-answer. "Every merge needs a second reviewer, and release builds run on a hosted pipeline that records provenance" is checkable. Ask for a sample, a screenshot, or a policy excerpt for at least three answers and note who produced it.
A self-attestation is a statement by the vendor, not an independent audit. Score it as useful evidence, and weigh it below an independent report or a test you ran yourself.
Sources
- NIST SP 800-218, Secure Software Development Framework version 1.1
- CISA Secure Software Development Attestation Form
Quick check
Is the SSDF a certification?
No. It is a set of recommended practices. There is no SSDF certificate, so ask for evidence of the practices instead.
Does a self-attestation prove a vendor is secure?
No. It is the vendor's own statement. Use it as a starting point and verify the claims that matter.
Last reviewed: 19 October 2026.
