Anchor your RFP in public standards, because they give neutral wording that any vendor can be tested against. Useful ones are CycloneDX and SPDX for SBOMs, VEX for vulnerability status, SLSA for build provenance, NIST SSDF for secure development and OWASP SCVS for component verification.
Why standards help
An analyst feature list reflects one firm's view at one point in time. A public standard is something both sides can read, and a test can pass or fail against it. That turns "supports SBOM" into "exports a valid CycloneDX document that our tool can parse."
The standards, in plain terms
- CycloneDX. An extensible specification for supply chain information, covering components, services, dependencies and vulnerabilities. Version 1.7 was released 2025-10-21 and it was published as ECMA-424 on 2025-12-10. It supports JSON, XML and Protocol Buffers.
- SPDX. An open standard for sharing SBOM data, hosted by the Linux Foundation and recognised as ISO/IEC 5962.
- VEX. CISA describes a VEX document as an attestation, a form of security advisory, indicating whether products are affected by known vulnerabilities. CycloneDX says it suits VEX use cases.
- SLSA. A specification for describing and incrementally improving supply chain security, organized in levels with provenance as a recommended attestation. Check the current version before citing it, since its 1.0 page is marked retired.
- NIST SSDF, SP 800-218. A core set of high-level secure software development practices that gives producers and purchasers a shared vocabulary, including in acquisitions.
- OWASP SCVS. The Software Component Verification Standard, an OWASP lab project, available in several file formats.
Turning them into RFP lines
Write requirements as tests.
- "Export an SBOM for a named sample project in CycloneDX and SPDX. We will validate the files."
- "Import and export VEX statements and show how they change reported findings."
- "Describe which SSDF practices your product helps us evidence, and show the evidence it produces."
- "State which SLSA version and level your own build process targets, if any, and how you prove it."
The fourth is about the vendor's own build, which is a supply chain question you can fairly ask.
What standards do not do
They define formats and practices, not quality. A valid SBOM can still be incomplete. A vendor can claim an SSDF mapping without producing useful evidence. Keep testing outputs on your own code.
Using both together
Standards give you the floor. Analyst research can help you find questions beyond it. Put the standards-based tests in your must-have column and treat the analyst-derived questions as differentiators.
Try it yourself
Open the demo and look at what a dependency inventory contains. Ask what each field would need to look like to pass your RFP test.
Click through it at your own pace, or open it full screen.
Safeguard provides SBOM and dependency scanning and compliance and evidence automation, and the free scan at gold.safeguard.sh/scan can produce output for you to inspect.
Quick check
Do I need both CycloneDX and SPDX?
It depends on your consumers. If customers or regulators ask for one specifically, require that one and test it.
Are standards a substitute for a proof of concept?
No. They make your test criteria clearer, but you still need to run the product.
Sources
- CycloneDX specification overview
- SPDX about
- CISA SBOM
- SLSA specification v1.0
- NIST SP 800-218
- OWASP Software Component Verification Standard
Last reviewed: 19 October 2026.
