VCRI is building a nonprofit clearinghouse for vendor cybersecurity posture — a trusted third party that makes the invisible supply chain legible to CISOs, procurement teams, regulators, and insurers. Our core problem is the Alpha (α) score: how do we make a vendor's assessed security posture cryptographically binding to the evidence that produced it, so downstream consumers can trust the score without trusting only us?
The answer is cryptographic attestation — tamper-evident, independently verifiable, queryable trust. This document describes the technical requirements any attestation layer in VCRI's pipeline must satisfy: what gets anchored, how it gets queried, what must be protected, and how it integrates with VCRI's data infrastructure.
Attestation Requirements
1. What Gets Attested — The Atomic Unit
VCRI operates on a 150-cell CAM matrix: 6 TIPPSS security dimensions (Trust, Identity, Privacy, Protection, Safety, Security) × 5 asset classes (Devices, Applications, Networks, Data, Users) × CMM maturity levels 1–5. Each cell represents a vendor's assessed maturity in one dimension for one asset class.
The provenance chain has three layers, all of which need attestation:
ATT-01 — Critical
Vendor Evidence Submission
A vendor's submitted Provenance Pack (Bills of Materials: SBOM, HBOM, FBOM + supporting telemetry) must be cryptographically anchored at time of ingestion. Timestamp, submitting entity, and content hash must be tamper-evident. This is the raw evidence substrate from which the Alpha score is derived.
ATT-02 — Critical
VCRI Assessment Result
The CAM score produced by VCRI's pipeline from a given evidence submission must be cryptographically linked back to ATT-01. A downstream consumer must be able to verify: "VCRI produced score X from evidence bundle Y, at time T, and neither has been altered since." VCRI's role as assessor must be verifiable without requiring the consumer to trust VCRI alone.
ATT-03 — High
Score Delta / Update Chain
As vendors are reassessed over time, each update must extend the attestation chain — not replace it. A consumer should be able to query a vendor's full score history with each point cryptographically anchored. This supports Theta (θ) recency scoring: a score's age and update frequency must be independently verifiable.
2. Query Model Requirements
VCRI's downstream consumers — CISOs, procurement officers, regulators, insurers — need to be able to verify a vendor score without calling VCRI. The attestation layer must support:
QRY-01 — Critical
Independent Verification Without VCRI Intermediation
A consumer must be able to answer: "Is this vendor's current VCRI score cryptographically bound to real, unaltered evidence?" without VCRI being in the verification loop. VCRI cannot be a single point of trust — or of failure.
QRY-02 — High
Point-in-Time Query
Regulatory and legal contexts require: "What was this vendor's attested score as of date X?" Attestation must support historical point-in-time retrieval with immutable proof of state at that moment.
QRY-03 — Standard
Portable Trust Profile
A vendor with a strong Alpha score should be able to carry a verified trust artifact across all their customer relationships — not just within VCRI's platform. The attestation layer should support a vendor-held, customer-verifiable credential.
3. Tamper-Evidence Requirements
The adversarial scenarios attestation must defend against:
- Vendor retroactive alteration — vendor modifies evidence after submission to improve a score under re-review
- VCRI insider manipulation — VCRI staff alter an assessment result (our nonprofit model reduces incentive, but the technical guarantee must not depend on our goodwill)
- Score gaming — vendor curates a selective data package that passes assessment but doesn't reflect real posture
- Staleness misrepresentation — an old score is presented as current; Theta decay must be independently verifiable
- Regulatory challenge — a consumer or regulator disputes a score; attestation must provide legally defensible proof of state at a prior date
4. Data Sensitivity Requirements
SENS-01 — Critical
Evidence Sensitivity — What Gets Anchored vs. What Gets Exposed
Vendor Provenance Packs contain competitively sensitive and security-sensitive details (specific CVEs, configuration data, internal system inventories). VCRI's CRIBL pipeline strips these before storage. The attestation layer must be able to anchor a hash of the full sensitive bundle without exposing the contents. Selective disclosure of the sanitized score — without revealing the raw evidence — is required.
5. Integration Requirements
INT-01 — High
CRIBL Pipeline Integration
VCRI's data pipeline runs on CRIBL. The attestation call must be embeddable as a pipeline stage — ideally as an API call that can be triggered at ingestion and at score publication without manual intervention. Automated = higher Beta (β) score for the whole system.
INT-02 — Standard
Scale
Current pilot: dozens of vendors. 12-month target: hundreds. Long-term: potentially thousands of vendors, each with multiple assessment cycles per year, and a portable trust artifact per vendor usable across millions of consumer queries. The attestation layer must scale on this trajectory.
Attestation Partner Criteria
6. What VCRI Requires From Any Attestation Partner
Any attestation layer that becomes part of VCRI's pipeline must satisfy the requirements above (ATT-01 through INT-02) and meet the following governance criteria:
GOV-01 — Critical
Registry Independence
VCRI's trust model cannot depend on a single party's continuity. The attestation registry must either be decentralized, or have clear portability/exit provisions such that VCRI and its consumers retain access to attestation records regardless of any single organization's operational status.
GOV-02 — Critical
Selective Disclosure Without Content Exposure
The attestation layer must support anchoring a cryptographic hash of sensitive evidence without exposing the contents. Vendor Provenance Packs contain competitively and security-sensitive data. Verification must be possible — "this evidence existed, was unaltered, and produced this score" — without revealing what the evidence contained.
GOV-03 — High
Pipeline Embeddability
Attestation calls must be automatable as a stage in VCRI's CRIBL data pipeline — not as a manual step. An attestation layer that requires human-in-the-loop anchoring is incompatible with VCRI's continuous monitoring model. API or webhook integration with pipeline tooling is required.
GOV-04 — High
Production-Grade Scale
The attestation layer must be production-ready, not research-grade. VCRI's pilot target is dozens of vendors with multiple assessment cycles per year; 12-month target is hundreds. Any integration partner must demonstrate production deployment at relevant scale or a credible path to it.
GOV-05 — Standard
Open or Auditable Architecture
For VCRI to represent the attestation infrastructure credibly to government and institutional stakeholders, the attestation layer's trust model must be independently auditable. Proprietary black-box attestation is incompatible with VCRI's governance requirements. Open source is preferred; independently audited proprietary systems are acceptable.
Organizations interested in serving as an attestation layer for VCRI's pipeline should review the full requirements (ATT-01 through GOV-05) and contact VCRI to discuss technical fit.
This document should be read alongside the Technical Overview and Data Security Brief for full pipeline context.