git.stella-ops.org/docs/28_LEGAL_COMPLIANCE.md

Regulator-Grade Threat & Evidence Model

Supply-Chain Risk Decisioning Platform (Reference: “Stella Ops”)

Document version: 1.0 Date: 2025-12-19 Intended audience: Regulators, third-party auditors, internal security/compliance, and engineering leadership Scope: Threat model + evidence model for a platform that ingests SBOM/VEX and other supply-chain signals, produces risk decisions, and preserves an audit-grade evidence trail.

---

1. Purpose and Objectives

This document defines:

1. A threat model for a supply-chain risk decisioning platform (“the Platform”) and its critical workflows.
2. An evidence model describing what records must exist, how they must be protected, and how they must be presented to support regulator-grade auditability and non-repudiation.

The model is designed to support the supply-chain transparency goals behind SBOM/VEX and secure software development expectations (e.g., SSDF), and to be compatible with supply-chain risk management (C‑SCRM) and control-based assessments (e.g., NIST control catalogs).

---

2. Scope, System Boundary, and Assumptions

2.1 In-scope system functions

The Platform performs the following high-level functions:

• Ingest software transparency artifacts (e.g., SBOMs, VEX documents), scan results, provenance attestations, and policy inputs.
• Normalize to a canonical internal representation (component identity graph + vulnerability/impact graph).
• Evaluate with a deterministic policy engine to produce decisions (e.g., allow/deny, risk tier, required remediation).
• Record an audit-grade evidence package supporting each decision.
• Export reports and attestations suitable for procurement, regulator review, and downstream consumption.

2.2 Deployment models supported by this model

This model is written to cover:

• On‑prem / air‑gapped deployments (offline evidence and curated vulnerability feeds).
• Dedicated single-tenant hosted deployments.
• Multi-tenant SaaS deployments (requires stronger tenant isolation controls and evidence).

2.3 Core assumptions

• SBOM is treated as a formal inventory and relationship record for components used to build software.
• VEX is treated as a machine-readable assertion of vulnerability status for a product, including “not affected / affected / fixed / under investigation.”
• The Platform must be able to demonstrate traceability from decision → inputs → transformations → outputs, and preserve “known unknowns” (explicitly tracked uncertainty).
• If the Platform is used in US federal acquisition contexts, it must anticipate evolving SBOM minimum element guidance; CISA’s 2025 SBOM minimum elements draft guidance explicitly aims to update the 2021 NTIA baseline to reflect tooling and maturity improvements. (Federal Register)

---

3. Normative and Informative References

This model is aligned to the concepts and terminology used by the following:

• SBOM minimum elements baseline (2021 NTIA) and the “data fields / automation support / practices and processes” structure.

• CISA 2025 SBOM minimum elements draft guidance (published for comment; successor guidance to NTIA baseline per the Federal Register notice). (Federal Register)

• VEX overview and statuses (NTIA one-page summary).

• NIST SSDF (SP 800‑218; includes recent Rev.1 IPD for SSDF v1.2). (NIST Computer Security Resource Center)

• NIST C‑SCRM guidance (SP 800‑161 Rev.1). (NIST Computer Security Resource Center)

• NIST security and privacy controls catalog (SP 800‑53 Rev.5, including its supply chain control family). (NIST Computer Security Resource Center)

• SLSA supply-chain threat model and mitigations (pipeline threat clustering A–I; verification threats). (SLSA)

• Attestation and transparency building blocks:

  • in‑toto (supply-chain metadata standard). (in-toto)
  • DSSE (typed signing envelope to reduce confusion attacks). (GitHub)
  • Sigstore Rekor (signature transparency log). (Sigstore)

• SBOM and VEX formats:

  • CycloneDX (ECMA‑424; SBOM/BOM standard). (GitHub)
  • SPDX (ISO/IEC 5962:2021; SBOM standard). (ISO)
  • CSAF v2.0 VEX profile (structured security advisories with VEX profile requirements). (OASIS Documents)
  • OpenVEX (minimal VEX implementation). (GitHub)

• Vulnerability intelligence format:

  • OSV schema maps vulnerabilities to package versions/commit ranges. (OSV.dev)

---

4. System Overview

4.1 Logical architecture

Core components:

1. Ingestion Gateway

   • Accepts SBOM, VEX, provenance attestations, scan outputs, and configuration inputs.
   • Performs syntactic validation, content hashing, and initial authenticity checks.

2. Normalization & Identity Resolution

   • Converts formats (SPDX, CycloneDX, proprietary) into a canonical internal model.
   • Resolves component IDs (purl/CPE/name+version), dependency graph, and artifact digests.

3. Evidence Store

   • Content-addressable object store for raw artifacts plus derived artifacts.
   • Append-only metadata index (event log) referencing objects by hash.

4. Policy & Decision Engine

   • Deterministic evaluation engine for risk policy.
   • Produces a decision plus a structured explanation and “unknowns.”

5. Attestation & Export Service

   • Packages decisions and evidence references as signed statements (DSSE/in‑toto compatible). (GitHub)
   • Optional transparency publication (e.g., Rekor or private transparency log). (Sigstore)

4.2 Trust boundaries

Primary trust boundaries:

• TB‑1: External submitter → Ingestion Gateway
• TB‑2: Customer environment → Platform environment (for hosted)
• TB‑3: Policy authoring plane → decision execution plane
• TB‑4: Evidence Store (write path) → Evidence Store (read/audit path)
• TB‑5: Platform signing keys / KMS / HSM boundary → application services
• TB‑6: External intelligence feeds (vulnerability databases, advisories) → internal curated dataset

---

5. Threat Model

5.1 Methodology

This model combines:

• STRIDE for platform/system threats (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege).
• SLSA threat clustering (A–I) for supply-chain pipeline threats relevant to artifacts being evaluated and to the Platform’s own supply chain. (SLSA)

Threats are evaluated as: Impact × Likelihood, with controls grouped into Prevent / Detect / Respond.

5.2 Assets (what must be protected)

A‑1: Decision integrity assets

• Final decision outputs (allow/deny, risk scores, exceptions).
• Decision explanations and traces.
• Policy rules and parameters (including weights/thresholds).

A‑2: Evidence integrity assets

• Original input artifacts (SBOM, VEX, provenance, scan outputs).
• Derived artifacts (normalized graphs, reachability proofs, diff outputs).
• Evidence index and chain-of-custody metadata.

A‑3: Confidentiality assets

• Customer source code and binaries (if ingested).
• Private SBOMs/VEX that reveal internal dependencies.
• Customer environment identifiers and incident details.

A‑4: Trust anchor assets

• Signing keys (decision attestations, evidence hashes, transparency submissions).
• Root of trust configuration (certificate chains, allowed issuers).
• Time source and timestamping configuration.

A‑5: Availability assets

• Evidence store accessibility.
• Policy engine uptime.
• Interface endpoints and batch processing capacity.

5.3 Threat actors

• External attacker seeking to:

  • Push a malicious component into the supply chain,
  • Falsify transparency artifacts,
  • Or compromise the Platform to manipulate decisions/evidence.

• Malicious insider (customer or Platform operator) seeking to:

  • Hide vulnerable components,
  • Suppress detections,
  • Or retroactively alter records.

• Compromised CI/CD or registry affecting provenance and artifact integrity (SLSA build/distribution threats). (SLSA)

• Curious but non-malicious parties who should not gain access to sensitive SBOM details (confidentiality and least privilege).

5.4 Key threat scenarios and required mitigations

Below are regulator-relevant threats that materially affect auditability and trust.

---

T‑1: Spoofing of submitter identity (STRIDE: S)

Scenario: An attacker submits forged SBOM/VEX/provenance claiming to be a trusted supplier.

Impact: Decisions are based on untrusted artifacts; audit trail is misleading.

Controls (shall):

• Enforce strong authentication for ingestion (mTLS/OIDC + scoped tokens).
• Require artifact signatures for “trusted supplier” classification; verify signature chain and allowed issuers.
• Bind submitter identity to evidence record at ingestion time (AU-style accountability expectations). (NIST Computer Security Resource Center)

Evidence required:

• Auth event logs (who/when/what).
• Signature verification results (certificate chain, key ID).
• Hash of submitted artifact (content-addressable ID).

---

T‑2: Tampering with stored evidence (STRIDE: T)

Scenario: An attacker modifies an SBOM, a reachability artifact, or an evaluation trace after the decision, to change what regulators/auditors see.

Impact: Non-repudiation and auditability collapse; regulator confidence lost.

Controls (shall):

• Evidence objects stored as content-addressed blobs (hash = identifier).
• Append-only metadata log referencing evidence hashes (no in-place edits).
• Cryptographically sign the “evidence package manifest” for each decision.
• Optional transparency log anchoring (public Rekor or private equivalent). (Sigstore)

Evidence required:

• Object store digest list and integrity proofs.
• Signed manifest (DSSE envelope recommended to bind payload type). (GitHub)
• Inclusion proof or anchor reference if using a transparency log. (Sigstore)

---

T‑3: Repudiation of decisions or approvals (STRIDE: R)

Scenario: A policy author or approver claims they did not approve a policy change or a high-risk exception.

Impact: Weak governance; cannot establish accountability.

Controls (shall):

• Two-person approval workflow for policy changes and exceptions.
• Immutable audit logs capturing: identity, time, action, object, outcome (aligned with audit record content expectations). (NIST Computer Security Resource Center)
• Sign policy versions and exception artifacts.

Evidence required:

• Signed policy version artifacts.
• Approval records linked to identity provider logs.
• Change diff + rationale.

---

T‑4: Information disclosure via SBOM/VEX outputs (STRIDE: I)

Scenario: An auditor-facing export inadvertently reveals proprietary component lists, internal repo URLs, or sensitive dependency relationships.

Impact: Confidentiality breach; contractual/regulatory exposure; risk of targeted exploitation.

Controls (shall):

• Role-based access control for evidence and exports.
• Redaction profiles (“regulator view,” “customer view,” “internal view”) with deterministic transformation rules.
• Separate encryption domains (tenant-specific keys).
• Secure export channels; optional offline export bundles for air-gapped review.

Evidence required:

• Access-control policy snapshots and enforcement logs.
• Export redaction policy version and redaction transformation log.

---

T‑5: Denial of service against evaluation pipeline (STRIDE: D)

Scenario: A malicious party floods ingestion endpoints or submits pathological SBOM graphs causing excessive compute and preventing timely decisions.

Impact: Availability and timeliness failures; missed gates/releases.

Controls (shall):

• Input size limits, graph complexity limits, and bounded parsing.
• Quotas and rate limiting (per tenant or per submitter).
• Separate async pipeline for heavy analysis; protect decision critical path.

Evidence required:

• Rate limit logs and rejection metrics.
• Capacity monitoring evidence (for availability obligations).

---

T‑6: Elevation of privilege to policy/admin plane (STRIDE: E)

Scenario: An attacker compromises a service account and gains ability to modify policy, disable controls, or access evidence across tenants.

Impact: Complete compromise of decision integrity and confidentiality.

Controls (shall):

• Strict separation of duties: policy authoring vs execution vs auditing.
• Least privilege IAM for services (scoped tokens; short-lived credentials).
• Strong hardening of signing key boundary (KMS/HSM boundary; key usage constrained by attestation policy).

Evidence required:

• IAM policy snapshots and access review logs.
• Key management logs (rotation, access, signing operations).

---

T‑7: Supply-chain compromise of artifacts being evaluated (SLSA A–I)

Scenario: The software under evaluation is compromised via source manipulation, build pipeline compromise, dependency compromise, or distribution channel compromise.

Impact: Customer receives malicious/vulnerable software; Platform may miss it without sufficient provenance and identity proofs.

Controls (should / shall depending on assurance target):

• Require/provide provenance attestations and verify them against expectations (SLSA-style verification). (SLSA)
• Verify artifact identity by digest and signed provenance.
• Enforce policy constraints for “minimum acceptable provenance” for high-criticality deployments.

Evidence required:

• Verified provenance statement(s) (in‑toto compatible) describing how artifacts were produced. (in-toto)
• Build and publication step attestations, with cryptographic binding to artifact digests.
• Evidence of expectation configuration and verification outcomes (SLSA “verification threats” include tampering with expectations). (SLSA)

---

T‑8: Vulnerability intelligence poisoning / drift

Scenario: The Platform’s vulnerability feed is manipulated or changes over time such that a past decision cannot be reproduced.

Impact: Regulator cannot validate basis of decision at time-of-decision; inconsistent results over time.

Controls (shall):

• Snapshot all external intelligence inputs used in an evaluation (source + version + timestamp + digest).
• In offline mode, use curated signed feed bundles and record their hashes.
• Maintain deterministic evaluation by tying each decision to the exact dataset snapshot.

Evidence required:

• Feed snapshot manifest (hashes, source identifiers, effective date range).
• Verification record of feed authenticity (signature or trust chain).

(OSV schema design, for example, emphasizes mapping to precise versions/commits; this supports deterministic matching when captured correctly.) (OSV.dev)

---

6. Evidence Model

6.1 Evidence principles (regulator-grade properties)

All evidence objects in the Platform shall satisfy:

1. Integrity: Evidence cannot be modified without detection (hashing + immutability).
2. Authenticity: Evidence is attributable to its source (signatures, verified identity).
3. Traceability: Decisions link to specific input artifacts and transformation steps.
4. Reproducibility: A decision can be replayed deterministically given the same inputs and dataset snapshots.
5. Non‑repudiation: Critical actions (policy updates, exceptions, decision signing) are attributable and auditable.
6. Confidentiality: Sensitive evidence is access-controlled and export-redactable.
7. Completeness with “Known Unknowns”: The Platform explicitly records unknown or unresolved data elements rather than silently dropping them.

6.2 Evidence object taxonomy

The Platform should model evidence as a graph of typed objects.

E‑1: Input artifact evidence

• SBOM documents (SPDX/CycloneDX), including dependency relationships and identifiers.
• VEX documents (CSAF VEX, OpenVEX, CycloneDX VEX) with vulnerability status assertions.
• Provenance/attestations (SLSA-style provenance, in‑toto statements). (SLSA)
• Scan outputs (SCA, container/image scans, static/dynamic analysis outputs).

E‑2: Normalization and resolution evidence

• Parsing/validation logs (schema validation results; warnings).
• Canonical “component graph” and “vulnerability mapping” artifacts.
• Identity resolution records: how name/version/IDs were mapped.

E‑3: Analysis evidence

• Vulnerability match outputs (CVE/OSV IDs, version ranges, scoring).
• Reachability artifacts (if supported): call graph results, dependency path proofs, or “not reachable” justification artifacts.
• Diff artifacts: changes between SBOM versions (component added/removed/upgraded; license changes; vulnerability deltas).

E‑4: Policy and governance evidence

• Policy definitions and versions (rules, thresholds).
• Exception records with approver identity and rationale.
• Approval workflow records and change control logs.

E‑5: Decision evidence

• Decision outcome (e.g., pass/fail/risk tier).
• Deterministic decision trace (which rules fired, which inputs were used).
• Unknowns/assumptions list.
• Signed decision statement + manifest of linked evidence objects.

E‑6: Operational security evidence

• Authentication/authorization logs.
• Key management and signing logs.
• Evidence store integrity monitoring logs.
• Incident response records (if applicable).

6.3 Common metadata schema (minimum required fields)

Every evidence object shall include at least:

• EvidenceID: content-addressable ID (e.g., SHA‑256 digest of canonical bytes).
• EvidenceType: enumerated type (SBOM, VEX, Provenance, ScanResult, Policy, Decision, etc.).
• Producer: tool/system identity that generated the evidence (name, version).
• Timestamp: time created + time ingested (with time source information).
• Subject: the software artifact(s) the evidence applies to (artifact digest(s), package IDs).
• Chain links: parent EvidenceIDs (inputs/precedents).
• Tenant / confidentiality labels: access classification and redaction profile applicability.

This aligns with the SBOM minimum elements emphasis on baseline data, automation support, and practices/processes including known unknowns and access control.

6.4 Evidence integrity and signing

6.4.1 Hashing and immutability

• Raw evidence artifacts shall be stored as immutable blobs.
• Derived evidence shall be stored as separate immutable blobs.
• The evidence index shall be append-only and reference blobs by hash.

6.4.2 Signed envelopes and type binding

• For high-assurance use, the Platform shall sign:

  • Decision statements,
  • Per-decision evidence manifests,
  • Policy versions and exception approvals.

• Use a signing format that binds the payload type to the signature to reduce confusion attacks; DSSE is explicitly designed to authenticate both message and type. (GitHub)

6.4.3 Attestation model

• Use in‑toto-compatible statements to standardize subjects (artifact digests) and predicates (decision, SBOM, provenance). (in-toto)
• CycloneDX explicitly recognizes an official predicate type for BOM attestations, which can be leveraged for standardized evidence typing. (CycloneDX)

6.4.4 Transparency anchoring (optional but strong for regulators)

• Publish signed decision manifests to a transparency log to provide additional tamper-evidence and public verifiability (or use a private transparency log for sensitive contexts). Rekor is Sigstore’s signature transparency log service. (Sigstore)

6.5 Evidence for VEX and “not affected” assertions

Because VEX is specifically intended to prevent wasted effort on non-exploitable upstream vulnerabilities and is machine-readable for automation, the Platform must treat VEX as first-class evidence.

Minimum required behaviors:

• Maintain the original VEX document and signature (if present).

• Track the VEX status (not affected / affected / fixed / under investigation) for each vulnerability–product association.

• If the Platform generates VEX-like conclusions (e.g., “not affected” based on reachability), it shall:

  • Record the analytical basis as evidence (reachability proof, configuration assumptions),
  • Mark the assertion as Platform-authored (not vendor-authored),
  • Provide an explicit confidence level and unknowns.

For CSAF-based VEX documents, the Platform should validate conformance to the CSAF VEX profile requirements. (OASIS Documents)

6.6 Reproducibility and determinism controls

Each decision must be reproducible. Therefore each decision record shall include:

• Algorithm version (policy engine + scoring logic version).
• Policy version and policy hash.
• All inputs by digest (SBOM/VEX/provenance/scan outputs).
• External dataset snapshot identifiers (vulnerability DB snapshot digest(s), advisory feeds, scoring inputs).
• Execution environment ID (runtime build of the Platform component that evaluated).
• Determinism proof fields (e.g., “random seed = fixed/none”, stable sort order used, canonicalization rules used).

This supports regulator expectations for traceability and for consistent evaluation in supply-chain risk management programs. (NIST Computer Security Resource Center)

6.7 Retention, legal hold, and audit packaging

Retention (shall):

• Evidence packages supporting released decisions must be retained for a defined minimum period (set by sector/regulator/contract), with:

  • Immutable storage and integrity monitoring,
  • Controlled deletion only through approved retention workflows,
  • Legal hold support.

Audit package export (shall): For any decision, the Platform must be able to export an “Audit Package” containing:

1. Decision statement (signed)
2. Evidence manifest (signed) listing all evidence objects by hash
3. Inputs (SBOM/VEX/provenance/etc.) or references to controlled-access retrieval
4. Transformation chain (normalization and mapping records)
5. Policy version and evaluation trace
6. External dataset snapshot manifests
7. Access-control and integrity verification records (to prove custody)

---

7. Threat-to-Evidence Traceability (Minimal Regulator View)

This section provides a compact mapping from key threat classes to the evidence that must exist to satisfy audit and non-repudiation expectations.

Threat Class	Primary Risk	“Must-have” Evidence Outputs
Spoofing submitter	Untrusted artifacts used	Auth logs + signature verification + artifact digests
Tampering with evidence	Retroactive manipulation	Content-addressed evidence + append-only index + signed manifest (+ optional transparency anchor)
Repudiation	Denial of approval/changes	Signed policy + approval workflow logs + immutable audit trail
Information disclosure	Sensitive SBOM leakage	Access-control evidence + redaction policy version + export logs
DoS	Missed gates / delayed response	Rate limiting logs + capacity metrics + bounded parsing evidence
Privilege escalation	Policy/evidence compromise	IAM snapshots + key access logs + segregation-of-duty records
Supply-chain pipeline compromise	Malicious artifact	Provenance attestations + verification results + artifact digest binding
Vulnerability feed drift	Non-reproducible decisions	Feed snapshot manifests + digests + authenticity verification

(Where the threat concerns the wider software supply chain, SLSA’s threat taxonomy provides an established clustering for where pipeline threats occur and the role of verification. (SLSA))

---

8. Governance, Control Testing, and Continuous Compliance

To be regulator-grade, the Platform’s security and evidence integrity controls must be governed and tested.

8.1 Governance expectations

• Maintain a control mapping to a recognized catalog (e.g., NIST SP 800‑53) for access control, auditing, integrity, and supply-chain risk management. (NIST Computer Security Resource Center)
• Maintain a supply-chain risk posture aligned with C‑SCRM guidance (e.g., NIST SP 800‑161 Rev.1). (NIST Computer Security Resource Center)
• Align secure development practices to SSDF expectations and terminology, noting SSDF has an active Rev.1 IPD (v1.2) publication process at NIST. (NIST Computer Security Resource Center)

8.2 Control testing (shall)

At minimum, perform and retain evidence of:

• Periodic integrity tests of evidence store immutability and hash verification.
• Key management audits (signing operations, rotation, restricted usage).
• Access review audits (especially multi-tenant isolation).
• Reproducibility tests: re-run evaluation from historical evidence package and confirm identical results.

---

Appendix A: Example Signed Decision Statement Structure (Conceptual)

This is a conceptual structure (not a normative schema) showing the minimum linkage needed:

• Subject: artifact digest(s) + identifiers
• Predicate type: .../decision (Platform-defined)
• Predicate: decision outcome + rationale + policy hash + dataset snapshot hashes
• Envelope: DSSE signature with payload type binding (GitHub)
• Optional transparency anchor: Rekor entry UUID / inclusion proof (Sigstore)

---

Appendix B: Practical Notes for SBOM/VEX Interoperability

• Support both SPDX and CycloneDX ingestion and preservation; both are referenced in SBOM minimum elements discussion and are widely used.
• Treat CSAF VEX and OpenVEX as acceptable VEX carriers; validate schema and preserve original artifacts. (OASIS Documents)
• Capture “known unknowns” explicitly rather than forcing false precision; this is part of SBOM minimum elements’ practices/processes framing and is directly relevant to regulator-grade audit transparency.

---

What you can do next with this model

If you want, I can produce any of the following artifacts derived directly from this model (without changing its underlying assertions):

1. A control-to-evidence crosswalk (NIST 800‑53 / SSDF / C‑SCRM oriented).
2. A test plan (control testing, evidence integrity validation, reproducibility drills).
3. A formal evidence schema (JSON schema for evidence objects + DSSE envelopes + manifest format).
4. A regulator-ready “Audit Package” template you can hand to third parties (including redaction tiers).