Add tests for SBOM generation determinism across multiple formats
- Created `StellaOps.TestKit.Tests` project for unit tests related to determinism. - Implemented `DeterminismManifestTests` to validate deterministic output for canonical bytes and strings, file read/write operations, and error handling for invalid schema versions. - Added `SbomDeterminismTests` to ensure identical inputs produce consistent SBOMs across SPDX 3.0.1 and CycloneDX 1.6/1.7 formats, including parallel execution tests. - Updated project references in `StellaOps.Integration.Determinism` to include the new determinism testing library.
This commit is contained in:
46
docs2/provenance/attestation-workflow.md
Normal file
46
docs2/provenance/attestation-workflow.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# Attestation workflow
|
||||
|
||||
Purpose
|
||||
- Ensure all exported evidence includes DSSE signatures and transparency proofs.
|
||||
- Provide deterministic verification for online and air-gapped environments.
|
||||
|
||||
Workflow overview
|
||||
- Producer emits a payload and requests signing.
|
||||
- Signer validates policy and signs with tenant or keyless credentials.
|
||||
- Attestor wraps the payload in DSSE, records transparency data, and publishes bundles.
|
||||
- Export Center and Evidence Locker embed bundles in export artifacts.
|
||||
- Verifiers (CLI, services, auditors) validate signatures and proofs.
|
||||
|
||||
Payload types
|
||||
- StellaOps.BuildProvenance@1
|
||||
- StellaOps.SBOMAttestation@1
|
||||
- StellaOps.ScanResults@1
|
||||
- StellaOps.PolicyEvaluation@1
|
||||
- StellaOps.VEXAttestation@1
|
||||
- StellaOps.RiskProfileEvidence@1
|
||||
- StellaOps.PromotionAttestation@1
|
||||
|
||||
Signing and storage controls
|
||||
- Default is short-lived keyless signing; tenant KMS keys are supported.
|
||||
- Ed25519 and ECDSA P-256 are supported.
|
||||
- Payloads must exclude PII and secrets; redaction is required before signing.
|
||||
- Evidence Locker stores immutable copies with retention and legal hold.
|
||||
|
||||
Verification steps
|
||||
- Verify DSSE signature against trusted roots.
|
||||
- Confirm subject digest matches expected artifact.
|
||||
- Verify transparency proof when available.
|
||||
- Enforce freshness using attestation.max_age_days policy.
|
||||
- Record verification results in timeline events.
|
||||
|
||||
Offline posture
|
||||
- Bundles include DSSE, transparency proofs, and certificate chains.
|
||||
- Offline verification uses embedded proofs and cached trust roots.
|
||||
- Pending transparency entries are replayed when connectivity returns.
|
||||
|
||||
Related references
|
||||
- provenance/inline-provenance.md
|
||||
- security/forensics-and-evidence-locker.md
|
||||
- docs/modules/attestor/architecture.md
|
||||
- docs/modules/signer/architecture.md
|
||||
- docs/modules/export-center/architecture.md
|
||||
24
docs2/provenance/backfill.md
Normal file
24
docs2/provenance/backfill.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Provenance backfill
|
||||
|
||||
Purpose
|
||||
- Backfill missing provenance records with deterministic ordering.
|
||||
|
||||
Inputs
|
||||
- Attestation inventory (NDJSON) with subject and digest data.
|
||||
- Subject to Rekor map for resolving transparency entries.
|
||||
|
||||
Procedure
|
||||
1. Validate inventory records (UUID or ULID and digest formats).
|
||||
2. Resolve each subject to a Rekor entry; record gaps and skip if missing.
|
||||
3. Emit backfilled provenance events using a backfill mode that preserves ordering.
|
||||
4. Log every backfilled subject and Rekor digest pair as NDJSON.
|
||||
5. Repeat until gaps are zero and record completion in audit logs.
|
||||
|
||||
Determinism
|
||||
- Sort by subject then Rekor entry before processing.
|
||||
- Use canonical JSON writers and UTC timestamps.
|
||||
|
||||
Related references
|
||||
- provenance/inline-provenance.md
|
||||
- provenance/attestation-workflow.md
|
||||
- docs/provenance/prov-backfill-plan.md
|
||||
34
docs2/provenance/rekor-policy.md
Normal file
34
docs2/provenance/rekor-policy.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Rekor submission policy
|
||||
|
||||
Purpose
|
||||
- Balance transparency log usage with budget limits and offline safety.
|
||||
|
||||
Submission tiers
|
||||
- Tier 1: graph-level attestations per scan (default).
|
||||
- Tier 2: edge bundle attestations for escalations.
|
||||
|
||||
Budgets
|
||||
- Hourly limits for graph submissions.
|
||||
- Daily limits for edge bundle submissions.
|
||||
- Burst windows for Tier 1 only.
|
||||
|
||||
Enforcement
|
||||
- Queue excess submissions with backpressure.
|
||||
- Retry failed submissions with backoff.
|
||||
- Store overflow locally for later submission.
|
||||
|
||||
Offline behavior
|
||||
- Queue submissions in attestor.rekor_offline_queue.
|
||||
- Bundle pending submissions in offline kits.
|
||||
- Drain queue when connectivity returns.
|
||||
|
||||
Monitoring
|
||||
- attestor_rekor_submissions_total
|
||||
- attestor_rekor_submission_latency_seconds
|
||||
- attestor_rekor_queue_depth
|
||||
- attestor_rekor_budget_remaining
|
||||
|
||||
Related references
|
||||
- provenance/attestation-workflow.md
|
||||
- security/crypto-and-trust.md
|
||||
- docs/operations/rekor-policy.md
|
||||
Reference in New Issue
Block a user