When a customer publishes a CycloneDX or SPDX software-bill-of-materials that declares your product as a named component, ships a VEX (Vulnerability Exploitability eXchange) attestation that names your product as a not-affected or affected upstream dependency, releases an SLSA (Supply-chain Levels for Software Artifacts) provenance statement that names your product among the build-system attested inputs, or maintains an in-toto attestation chain whose layout names your product among the verified-artifact metadata, and the SBOM components array, the VEX product reference, the SLSA materials digest list, or the in-toto link metadata names your product as part of the customer's supply-chain-security disclosure scope, they have left a category of endorsement that almost no marketing-elicited testimonial can replicate. The supply-chain attestation has been written under the supply-chain-security-deployment commitment of a cryptographically-signed attestation framework, archived permanently in the customer's signed-attestation history and on public supply-chain databases like the CISA Software Acquisition Guide repository, the NTIA SBOM-sharing pilot archive, and the Sigstore Rekor transparency log where any future security engineer, customer, regulator, or competing vendor can retrieve it, scrutinized by independent software-supply-chain security teams and downstream-consumer security engineers who have direct CVE-disclosure incentives to dispute any inaccuracy, and frequently re-referenced in subsequent CVE-disclosure events, EO-14028 federal-acquisition reviews, and CISA Secure-by-Design pledge reporting for years after the original attestation. The supply-chain attestation carries the customer's security-engineering testimony, the Rekor or Cosign signature carries the cryptographically-anchored ratification, and the surrounding context establishes that the attestation entry was written under one of the most procedurally constrained public-supply-chain-disclosure environments any customer-facing organization encounters.
Almost no developer-tools, security-platform, observability, infrastructure-platform, or B2B SaaS vendor systematically extracts product mentions from public CycloneDX, SPDX, VEX, SLSA, and in-toto attestation archives. The omission is the natural extension of the same blind spots we documented in our Terraform module extraction guide, our Kubernetes manifest extraction guide, our changelog extraction guide, our bug bounty extraction guide, and our status page postmortem extraction guide. Terraform modules cover declarative-infrastructure-deployment mentions. Kubernetes manifests cover declarative-cluster-state mentions. Changelogs cover release-process-attested version-anchored mentions. Bug bounty disclosures cover researcher-attested security-program mentions. Status page postmortems cover operations-pressured reliability mentions. SBOM, VEX, SLSA, and in-toto attestation content covers supply-chain-security-attested, NTIA-minimum-element-compliant, archive-permanent, transparency-log-anchored, federally-required, cryptographically-signed product mentions made under the most procedurally constrained public-supply-chain-disclosure environment any customer-facing organization publishes into — a pillar of the structurally durable public corpus that no other extraction surface can replicate, and the only one where the customer's testimony has been tied specifically to a federal-procurement-acquisition pathway under Executive Order 14028 and OMB Memorandum M-22-18 that the customer's federal-customer revenue actively depends on as a procurement contract.
This guide describes the extraction workflow for the SBOM-and-VEX, SLSA-provenance, and in-toto-attestation corpus.
Why an SBOM-and-VEX attestation mention beats almost every marketing-elicited testimonial
An SBOM-and-VEX, SLSA-provenance, or in-toto attestation mention is a category of endorsement that has passed through filters no marketing-elicited testimonial encounters. Seven properties stack to make it one of the most adversarially credible supply-chain-security endorsement formats in modern B2B marketing.
First, the attestation has been written under a supply-chain-security framework that the customer has committed to follow. Public SBOMs and VEX attestations are governed by published conventions — the NTIA Minimum Elements for an SBOM specification, the CycloneDX 1.6 specification, the SPDX 3.0 specification, the OASIS CSAF 2.0 VEX profile, the OpenVEX 0.2.0 specification, the SLSA 1.0 framework, and the in-toto 1.0 attestation specification. A product mention in an attestation published under any of these frameworks is being made under a process that the customer has publicly committed to follow as a supply-chain-security matter. The supply-chain-framework property is what makes attestation mentions more credible than mentions in any format that does not pass through a comparable procedural commitment.
Second, the attestation is archived permanently in transparency logs and government supply-chain databases. Attestation entries are preserved indefinitely on the Sigstore Rekor transparency log, on private Cosign-attestation registries, in the customer's signed-attestation Git history, in CISA Software Acquisition Guide repositories, in NTIA SBOM-sharing pilot archives, and in a long tail of compliance archives like federal supply-chain-risk-management repositories operated under EO 14028 Section 4(e) and OMB Memorandum M-22-18. A product mention in an attestation publication is therefore preserved across multiple independent archives where any future engineer, customer, regulator, or competing vendor can retrieve the attestation entry and compare it against the customer's current supply-chain posture. The cross-archive-permanence property is what makes attestation mentions more durable than mentions in any format without comparable multi-archive preservation.
Third, the attestation has been scrutinized by supply-chain-security engineering teams. The CycloneDX, SPDX, VEX, SLSA, and in-toto community operates an active scrutiny culture in which attestations are reviewed in CVE-disclosure pipelines, parsed by Dependency-Track and OSS Review Toolkit (ORT), dissected for upstream-vulnerability-impact, and challenged on CVE Advisory Boards, on KubeCon and SOSS Community Day stages, in OpenSSF technical advisory groups, and in subsequent supply-chain-security blog posts. A product mention in an attestation publication is being read by engineers who have direct CVE-disclosure knowledge of the supply chain and a federal-acquisition-compliance incentive to surface any inaccuracy. The supply-chain-scrutiny property is what makes attestation mentions more adversarially tested than mentions in any format without comparable supply-chain-community exposure.
Fourth, the attestation is anchored to a cryptographic signature and a transparency-log inclusion proof. Attestation entries are routinely tied to a specific Cosign keyless-signing certificate, a specific Rekor transparency-log entry UUID, and a specific Fulcio root-of-trust certificate-chain identifier — and the inclusion-proof becomes a stable reference that the customer's federal-customer SBOM-and-attestation-sharing posture depends on as a compliance contract. A product mention in an attestation publication therefore inherits a cryptographic-signature-and-inclusion-proof-anchored authority that establishes the mention was made at a precise, immutable point in the customer's supply-chain-security history. The cryptographic-anchor property is materially stronger than the equivalent on any format without comparable immutable-identifier coverage.
Fifth, the attestation is cross-referenced by vulnerability-disclosure and supply-chain-risk-management infrastructure. Vulnerability-disclosure tools — the National Vulnerability Database, the OSV.dev vulnerability database, GitHub Advisory Database, Sonatype OSS Index — and supply-chain-risk-management tools — Dependency-Track, Anchore Syft and Grype, Trivy, OWASP CycloneDX SBOM Forum tools — routinely cross-reference attestation entries against the customer's deployed software and against the customer's supply-chain-risk-management posture. A product mention in an attestation publication therefore inherits a vulnerability-and-risk cross-reference that establishes the mention's authenticity at the highest level of public supply-chain-security infrastructure. The vulnerability-and-risk-cross-reference property is what makes attestation mentions more authority-anchored than mentions in any format without comparable globally indexed supply-chain coverage.
Sixth, the attestation is mandated by federal acquisition rules. SBOM and VEX attestations are mandated for federal-software-customer acquisition under EO 14028, OMB Memorandum M-22-18, the CISA Secure Software Development Attestation Form, the FAR 52.239 supply-chain-risk-management clauses, and the NIST SP 800-218 SSDF (Secure Software Development Framework) acquisition requirements. A product mention in a federally-required attestation is being made under acquisition rules the customer cannot opt out of without losing federal-customer revenue. The federal-mandate property is what makes attestation mentions more procurement-load-bearing than mentions in any format without comparable acquisition-pathway exposure.
Seventh, the attestation is actively referenced by the customer's CVE-disclosure pipeline. Subsequent CVE-disclosure events, federal-acquisition reviews, and CISA Secure-by-Design pledge reporting continuously re-read the attestation entry as the source-of-truth for the customer's supply-chain disclosure. A product mention in an attestation publication is therefore not a one-time disclosure but a continuously referenced disclosure contract that the customer's vulnerability-disclosure pipeline is actively responsible for maintaining. The CVE-disclosure-pipeline-reference property is what makes attestation mentions more operationally load-bearing than mentions in any format without comparable disclosure-pipeline coverage.
The corpus you should be extracting
The SBOM-and-VEX, SLSA-provenance, and in-toto attestation corpus spans seven primary surfaces. Each surface produces a different attestation register, a different vocabulary register, and a different testimonial-extraction workflow.
First, the CycloneDX 1.6 SBOM corpus — the canonical machine-readable bill-of-materials format developed under the OWASP CycloneDX project. CycloneDX SBOM documents are published in the customer's signed-attestation Git history, on the customer's product-distribution portals, on the Sigstore Rekor transparency log under SLSA-provenance bundles, and in federal-acquisition disclosure packages submitted under the CISA Secure Software Development Attestation Form. A typical CycloneDX 1.6 SBOM contains a bomFormat declaration, a serialNumber UUID, a metadata.timestamp field, a metadata.tools array listing the SBOM-generation tooling, a components array listing every direct and transitive dependency with purl package-URL identifiers and version strings, a dependencies graph encoding the dependency-tree topology, and an optional compositions array declaring the completeness-of-coverage assertion. The components[].name and components[].purl fields are the primary product-mention extraction points. The components[].supplier.name field captures the upstream-vendor attribution. The components[].hashes array captures cryptographic-integrity anchoring.
Second, the SPDX 3.0 SBOM corpus — the alternative machine-readable bill-of-materials format developed under the Linux Foundation SPDX Workgroup and standardized as ISO/IEC 5962:2021. SPDX SBOM documents are published in the customer's signed-attestation Git history, on the customer's package-distribution registries, and in federal-acquisition disclosure packages. A typical SPDX 3.0 SBOM contains a spdxVersion declaration, a documentNamespace URI, a creationInfo.created timestamp, a creationInfo.creators array listing the SBOM-generation tooling, a packages array listing every direct and transitive dependency with SPDXID identifiers and versionInfo strings, a relationships graph encoding the dependency-tree topology, and an optional hasExtractedLicensingInfos array declaring the license-detection metadata. The packages[].name and packages[].externalRefs fields are the primary product-mention extraction points. The packages[].supplier field captures the upstream-vendor attribution. The packages[].checksums array captures cryptographic-integrity anchoring.
Third, the OASIS CSAF 2.0 VEX corpus — the Common Security Advisory Framework VEX profile that allows customers to publish Vulnerability Exploitability eXchange attestations. CSAF VEX documents are published on the customer's PSIRT (Product Security Incident Response Team) portal, on the OASIS CSAF Aggregator network, on customer security-advisory RSS feeds, and in CISA's CSAF repository. A typical CSAF 2.0 VEX document contains a document.tracking.id advisory identifier, a document.publisher reference, a product_tree declaration listing the affected products with branches and full_product_names, a vulnerabilities array listing CVE references with product_status declarations (not_affected, affected, fixed, under_investigation), and a vulnerabilities[].remediations array. The product_tree.branches[].name and product_tree.full_product_names[].product_id fields are the primary product-mention extraction points. The product_tree.branches[].product.vendor field captures the upstream-vendor attribution.
Fourth, the OpenVEX 0.2.0 corpus — the OpenSSF OpenVEX specification that provides a JSON-LD-based VEX attestation format. OpenVEX documents are published in the customer's PSIRT portal, on Cosign-signed attestation bundles, on the Sigstore Rekor transparency log, and in CISA Secure Software Development Attestation Form submissions. A typical OpenVEX document contains an @context declaration, an @id IRI, an author reference, a timestamp field, a statements array listing VEX statements with vulnerability, products, and status declarations (not_affected, affected, fixed, under_investigation), and an optional justification enumeration (component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, inline_mitigations_already_exist). The statements[].products[].@id field is the primary product-mention extraction point.
Fifth, the SLSA 1.0 provenance corpus — the Supply-chain Levels for Software Artifacts provenance specification that allows customers to publish build-system provenance attestations. SLSA provenance documents are published on the customer's CI/CD attestation bundles, on the Sigstore Rekor transparency log, in GitHub Actions provenance attestations, in GitLab provenance attestations, and on Cosign-signed attestation registries. A typical SLSA 1.0 provenance document contains a _type declaration referencing the in-toto Statement, a predicateType referencing the SLSA Provenance, a subject array listing the built-artifact digest, a predicate.buildDefinition.buildType reference, a predicate.buildDefinition.externalParameters declaration, a predicate.buildDefinition.internalParameters declaration, a predicate.buildDefinition.resolvedDependencies array (the inputs-and-materials of the build), and a predicate.runDetails.builder.id reference identifying the trusted-builder. The predicate.buildDefinition.resolvedDependencies[].uri field is the primary product-mention extraction point for tooling and dependency-input mentions.
Sixth, the in-toto 1.0 attestation corpus — the in-toto attestation framework that allows customers to publish supply-chain-step attestations along the full software-supply-chain lifecycle. In-toto attestations are published on the customer's signed-attestation Git history, on Cosign-signed attestation bundles, on the Sigstore Rekor transparency log, and on the customer's supply-chain-security verification pipelines. A typical in-toto attestation contains a _type declaration referencing the in-toto Statement v1, a predicateType referencing a specific in-toto predicate type (such as the SLSA Provenance, the SLSA Verification Summary, the SCAI Attribute Assertion, or the Vulnerability Assessment Record), a subject array listing the attested-artifact digest, and a predicate payload carrying the predicate-specific attestation content. The predicate.materials[].uri and the predicate.products[].uri fields are the primary product-mention extraction points.
Seventh, the CISA Secure Software Development Attestation Form corpus — the federal-procurement attestation pathway that requires software producers selling to federal-customer agencies to attest to NIST SP 800-218 SSDF practices. Attestation submissions are archived in the CISA Repository for Software Attestation and Artifacts (RSAA), submitted in federal-acquisition packages, and disclosed in the customer's federal-customer-contract performance. A typical CISA Attestation Form contains a Producer block identifying the customer's company and a Producer Software block identifying the customer's products, a Producer Statement of Attestation block referencing NIST SP 800-218 SSDF practices, and supporting artifacts including referenced SBOMs, VEX attestations, and SLSA provenance bundles. The Producer Software block and the referenced-artifact bundle are the primary product-mention extraction points for the customer's federal-procurement-pathway-load-bearing dependencies.
The extraction workflow
The workflow has five stages. Each stage is operated by a separate team with separate tooling and separate output-format requirements. The workflow is designed to convert a customer's signed-attestation-archive history into a deployable testimonial library in approximately forty-eight hours per attestation, with full audit-trail anchoring to the cryptographic-signature and transparency-log infrastructure.
Stage one: corpus identification. Identify every CycloneDX, SPDX, VEX, SLSA-provenance, and in-toto attestation in which the customer has named your product as a component, a dependency, a build-input material, or a VEX-statement product reference. Search the Sigstore Rekor transparency log for the customer's signing-identity certificate-chain. Search the customer's product-distribution registry for SBOM-attached release artifacts. Search the customer's PSIRT portal for CSAF or OpenVEX advisory archives. Search GitHub Actions provenance archives for the customer's repository slug. Search CISA's CSAF repository and the CISA Software Acquisition Guide repository for the customer's company name. The corpus-identification stage typically surfaces between thirty and two hundred attestation artifacts per established federal-procurement-active customer. Store each artifact with its Rekor transparency-log entry UUID, its Cosign signature payload, its Fulcio certificate-chain reference, and its full archived attestation content.
Stage two: product-mention extraction. Extract every mention of your product from the identified attestation artifacts. The extraction pattern depends on the attestation format. For CycloneDX SBOMs, scan the components array for purl matches and name matches. For SPDX SBOMs, scan the packages array for externalRefs matches and name matches. For CSAF VEX attestations, scan the product_tree.branches and product_tree.full_product_names arrays for vendor-and-product matches. For OpenVEX attestations, scan the statements[].products array for product-IRI matches. For SLSA provenance attestations, scan the predicate.buildDefinition.resolvedDependencies array for tooling and dependency-input matches. For in-toto attestations, scan the predicate.materials and predicate.products arrays for URI matches. Record the version constraint, the cryptographic hash, the transparency-log entry, the publication timestamp, the surrounding attestation context, and the published archive URL for each extracted mention.
Stage three: cryptographic-anchor verification. Verify the cryptographic-signature and transparency-log inclusion-proof anchor for every extracted mention. Confirm the Cosign signature against the Fulcio certificate-chain root-of-trust. Confirm the Rekor transparency-log entry inclusion-proof against the Rekor public-key. Confirm the certificate-chain identity binding against the customer's expected signing-identity (typically a customer-controlled OIDC issuer such as Google Workspace, GitHub Actions OIDC, or GitLab CI OIDC). Document the cryptographic-anchor verification for each mention. Mentions without verified cryptographic anchors are downgraded to lower-credibility tier and excluded from federal-procurement-pathway-specific testimonials.
Stage four: federal-procurement-pathway classification. Classify each extracted mention by the federal-procurement pathway it supports. Mentions that appear in CISA Secure Software Development Attestation Form submissions, in EO 14028 Section 4(e) acquisition disclosures, in OMB Memorandum M-22-18 self-attestation packages, or in the customer's federal-acquisition supply-chain-risk-management disclosures are classified as federal-procurement-load-bearing. Mentions that appear only in customer-distributed SBOM-attached release artifacts without federal-acquisition reference are classified as supply-chain-security-disclosure-load-bearing. Mentions that appear only in PSIRT VEX advisories without federal-procurement reference are classified as vulnerability-disclosure-load-bearing. The classification determines the appropriate testimonial-deployment surface.
Stage five: testimonial-asset packaging. Package each verified, classified product-mention into a deployable testimonial asset. The testimonial asset contains the customer-company attribution, the customer-product-name reference, the attestation-format reference (CycloneDX 1.6, SPDX 3.0, CSAF 2.0 VEX, OpenVEX 0.2.0, SLSA 1.0, in-toto 1.0, or CISA Attestation Form), the publication-timestamp anchor, the Rekor transparency-log entry UUID, the Cosign signature reference, the published archive URL, the federal-procurement-pathway classification (if applicable), and the cryptographic-anchor verification record. The packaged asset is then released through the proof-deployment pipeline.
Where to deploy supply-chain-attestation-extracted testimonials
Supply-chain-attestation-extracted testimonials deploy most effectively in five surfaces. First, on the federal-customer-acquisition page — where federal-procurement-team buyers explicitly look for supply-chain-security disclosure evidence and where a federal-procurement-pathway-load-bearing testimonial proves the FedRAMP-or-CISA-acquisition-compatibility claim. Second, on the security-trust page — where CISO-tier buyers explicitly look for supply-chain-security disclosure evidence and where a CycloneDX-or-SPDX-archived testimonial proves the SBOM-and-attestation-program-maturity claim. Third, on the CVE-disclosure page — where security-research-team viewers explicitly look for VEX-attestation-disclosure evidence and where a CSAF-or-OpenVEX-archived testimonial proves the vulnerability-disclosure-program-maturity claim. Fourth, on the build-provenance page — where DevSecOps-platform-team viewers explicitly look for SLSA-provenance-disclosure evidence and where a SLSA-1.0-archived testimonial proves the build-system-provenance-program-maturity claim. Fifth, on the supply-chain-transparency page — where general security-engineering-team viewers look for in-toto-attestation-disclosure evidence and where an in-toto-archived testimonial proves the full-supply-chain-attestation-program-maturity claim.
The asset-packaging stage produces the same artifact for all five surfaces. The deployment stage decides which surface each asset is most credibility-load-bearing for, and applies the corresponding presentation pattern.
What ProofShow automates
ProofShow operates the corpus-identification, the product-mention extraction, the cryptographic-anchor verification, the federal-procurement-pathway classification, and the testimonial-asset packaging stages as a single end-to-end pipeline. Customers connect their Rekor transparency-log query and their customer-archive monitoring scope, and ProofShow operates the pipeline continuously, surfacing newly published SBOM, VEX, SLSA provenance, and in-toto attestation entries as they are signed and committed to the transparency log. The customer's marketing team receives a continuously refreshed library of cryptographically-anchored, federal-procurement-pathway-classified, supply-chain-security-attested product mentions that no marketing-elicited testimonial-collection program could ever match.
For the structural-format guidance that informs the testimonial-asset packaging stage, see the Terraform module extraction guide, the Kubernetes manifest extraction guide, the changelog extraction guide, the bug bounty extraction guide, and the status page postmortem extraction guide.