Contracts with software suppliers should state your security requirements in terms that can be checked: how they handle and disclose vulnerabilities, what provenance and integrity data they provide, whether they supply an SBOM, and what they attest to. Have engineering write the technical requirements and legal wrap them.
What the sources say
CSF 2.0 outcome GV.SC-05 says requirements to address supply chain cybersecurity risks are established, prioritized and integrated into contracts and other agreements with suppliers and other relevant third parties.
SSDF practice PO.1.3 says to communicate requirements to all third parties who will provide commercial software components for reuse. Its examples include: define a core set of security requirements for software components and include them in acquisition documents and contracts; define selection criteria, which can include the third party's vulnerability disclosure program and product security incident response capabilities; require third parties to attest that their software complies with your requirements; and require third parties to provide provenance data and integrity verification mechanisms for components.
A requirements menu
| Area | What to ask | Why |
|---|---|---|
| Vulnerability handling | Published disclosure channel; stated response practice | You know where to report and what to expect |
| Notification | Timely notice of incidents that affect your use | Feeds your own incident response. See GV.SC-08 |
| Transparency | SBOM for delivered software, at agreed frequency and depth | Inventory and license checks. See SBOM governance |
| Integrity | Signed releases or other integrity verification | Detect tampering |
| Provenance | Data on where and how components were built | Trace issues to source |
| Attestation | Statement that the supplier follows named practices | Clear accountability |
| End of life | Notice period before support ends | Plan replacement |
| Exit | What happens to data and access when the contract ends. See GV.SC-10 | Clean offboarding |
Tier the requirements
Not every supplier needs every row. Use your criticality tiers: critical suppliers get the full menu, routine suppliers get the basics. See how to tier suppliers and components.
Practical tips
- Write requirements as testable statements, not goals. "Provide a machine-readable SBOM for each release" is testable; "we value transparency" is not.
- Keep a standard security schedule that procurement can attach. Do not renegotiate it every time.
- Decide in advance what you will do if a supplier refuses. Options include compensating controls, shorter terms, or a different supplier. Record the decision as an exception.
- Verify some claims. An attestation is a statement, not proof. Sample the evidence for critical suppliers.
- Review the standard schedule yearly.
Common pitfalls
- Copying a long questionnaire into the contract with no way to check answers.
- Asking for artifacts nobody on your side will read.
- Forgetting open source. There is no contract, so the controls move into your intake and monitoring process.
This is general information, not legal advice. Have counsel review contract language.
Try it yourself
Click through it at your own pace, or open it full screen. See how one requirement can map to several framework outcomes.
Safeguard offers SBOM and dependency scanning and compliance and evidence automation, which can help you check supplier-delivered components and keep the records.
Quick check
Is a supplier attestation enough?
It is a start. For critical suppliers, sample the supporting evidence.
Who writes the technical requirements?
Engineering and security, with legal and procurement handling the contract terms.
Sources
Last reviewed: 19 October 2026.
