Why does software provenance matter more than vendor questionnaires for concentration risk?

Questionnaires describe supplier posture, but provenance shows what actually ships and where shared dependencies live. If two organisations buy from the same trusted vendor, but one has deeper transitive exposure or a more concentrated build path, the real risk profile is different. Provenance turns governance from trust into evidence.

Why provenance beats questionnaires for concentration risk

Vendor questionnaires are useful for screening, but they are still self-reported posture. Provenance answers a different question: what actually shipped, how it was built, and whether multiple buyers are unknowingly exposed to the same upstream components, build path, or maintainer decisions. That is why provenance is the stronger signal when you are trying to understand concentration risk.

What concentration risk looks like in the software supply chain

Concentration risk appears when many organisations depend on the same vendor, the same build pipeline, the same package ecosystem, or the same transitive dependency set. The surface may look diversified because the contracts differ, but the underlying failure point can still be shared. When that shared layer breaks, the impact fans out across all downstream consumers at once.

Questionnaires rarely reveal that shape of dependency. A supplier may answer that it has secure controls, multiple reviews, and a mature programme, yet still ship the same library versions, the same signing process, or the same hosting dependency to every customer. Provenance is what lets buyers see whether the real dependency graph is narrow, duplicated, or dangerously concentrated.

How provenance changes the control decision

Provenance is evidence about origin, transformation, and integrity. It tells you whether the artifact was built from the code you expected, whether the build was repeatable, whether the signing chain is trustworthy, and whether a change in one upstream component affects many downstream products. That evidence is especially valuable when you need to compare two suppliers that look similar on paper but differ materially in shared dependency depth.

This is also where SLSA is directly relevant, because the framework is built around software artifact provenance and build integrity. If your procurement question is really about how much shared upstream exposure exists, then the control question is not “did the vendor say it is secure?” but “can we verify what was built, from what, and through which pipeline?”

Questionnaires can still help with governance, but they are a weak proxy for concentrated technical exposure. Provenance gives you the ability to compare suppliers on their actual dependency structure, not just their stated assurance posture. That difference matters most when the same trusted vendor or ecosystem is embedded across many organisations and a single shared weakness could affect all of them.

Risk and Threat Considerations

Concentration risk becomes material when a shared artifact, dependency, maintainer, or build step creates correlated failure across many buyers. A questionnaire can say a vendor has controls, but it cannot show whether the same vulnerable component, compromised package, or fragile release path is reused across multiple products and tenants.

Failure mechanism: Trusting supplier attestations alone can hide common-mode failure, where one upstream compromise or dependency defect propagates through many downstream environments before buyers realise they share the same exposure.

Impact: The result is wider blast radius, slower detection, and weaker incident containment, because organisations believe they are diversified when they are actually exposed to the same source of failure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
SLSA	Supply chain levels for software artifacts	Provenance and build integrity are the core subject of concentration risk here.
Recommendation — Adopt SLSA-aligned provenance checks before trusting supplier assurances.
NIST SP 800-53 Rev 5	SR-11 — Component Authenticity	Shared upstream components are the concentration risk mechanism in this question.
	SA-12 — Supply Chain Protection	The question is about why provenance beats vendor questionnaires in supply-chain concentration analysis.
Recommendation — Verify component authenticity to reduce common-mode supplier exposure. Require supply-chain provenance evidence in supplier assurance reviews.
CIS Controls v8	14 — Security Awareness and Skills Training	Teams assessing supplier risk need disciplined review of evidence versus claims.
Recommendation — Train reviewers to distinguish attestations from verifiable provenance evidence.
ISO/IEC 27001:2022	A.5.21 — Managing information security in the ICT supply chain	Supplier concentration and shared dependencies are supply-chain governance issues.
Recommendation — Include provenance evidence in ICT supply-chain assurance reviews.

Practitioner Guidance

What to prioritise: Treat provenance evidence as the first-line input for concentration analysis, then use questionnaires only as supporting context. If two suppliers answer identically but one exposes a denser shared dependency chain, the more concentrated path deserves the higher-risk classification.

What to verify: Confirm artifact lineage, dependency recursion, build reproducibility, and signing trust before accepting vendor assurance at face value. If the buyer cannot trace the artifact back to a verifiable build and source set, the procurement answer is incomplete.

Practitioner takeaway: Questionnaires tell you what a supplier claims; provenance tells you what the market will actually inherit if that supplier, dependency, or build path fails.