stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity

partly or unimplemented features - now implemented

Browse Source
This commit is contained in:
master
2026-02-09 08:53:51 +02:00
parent 1bf6bbf395
commit 4bdc298ec1
674 changed files with 90194 additions and 2271 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
docs/features/unchecked/attestor/binary-fingerprint-store-and-trust-scoring.md Normal file
View File

@@ -0,0 +1,36 @@
# Binary Fingerprint Store and Trust Scoring
## Module
Attestor
## Status
IMPLEMENTED
## Description
Binary analysis commands exist in the CLI with score gating, confidence calculation is implemented in the Policy engine, and a Doctor plugin for binary analysis health checks exists. A full binary fingerprint database with ELF/PE section hashing, trust scores, and golden set as described is partially implemented through the existing binary analysis infrastructure.
## What's Implemented
- **Binary Fingerprint Evidence Generator**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Generators/BinaryFingerprintEvidenceGenerator.cs` (with `.Helpers`) -- generates binary fingerprint evidence from analyzed binaries.
- **Binary Identity Info**: `Predicates/BinaryIdentityInfo.cs` -- binary identity information (hash, file path, architecture).
- **Binary Vuln Match Info**: `Predicates/BinaryVulnMatchInfo.cs` -- vulnerability match data for binaries.
- **Backport Proof Generator**: `Generators/BackportProofGenerator.cs` (with `.Confidence`, `.Tier1`-`.Tier4`) -- confidence scoring for binary-level backport detection.
- **Trust Verdict Service**: `__Libraries/StellaOps.Attestor.TrustVerdict/Services/TrustVerdictService.cs` (with `.Scoring`) -- trust scoring infrastructure.
- **Evidence Summary**: `Generators/EvidenceSummary.cs` -- evidence summarization for binary analysis results.
## What's Missing
- **Dedicated binary fingerprint database**: No standalone fingerprint store with ELF/PE section-level hashing and content-addressed lookup. Current evidence is generated per-scan, not stored in a queryable fingerprint database.
- **Golden set management**: No mechanism to define and maintain a "golden set" of known-good binary fingerprints for comparison.
- **Section-level hashing**: ELF `.text`/`.rodata` section hashing and PE section-level fingerprinting are not distinctly implemented as reusable fingerprinting primitives.
- **Trust score decay**: Binary trust scores do not decay over time based on staleness; current trust scoring is evaluation-time only.
- **Fingerprint comparison API**: No REST endpoint for querying/comparing binary fingerprints against the golden set.
## Implementation Plan
- Create a `BinaryFingerprintStore` service with content-addressed storage for section-level hashes
- Implement ELF/PE section extraction and hashing as reusable utilities
- Add golden set management (import, compare, drift detection)
- Wire trust score decay into the `TrustVerdictService` scoring pipeline
- Add REST endpoint for fingerprint queries and comparisons
- Add tests for fingerprint store, section hashing, and golden set comparison
## Related Documentation
- Source: See feature catalog

37
docs/features/unchecked/attestor/cas-for-sbom-vex-attestation-artifacts.md Normal file
View File

@@ -0,0 +1,37 @@
# CAS for SBOM/VEX/Attestation Artifacts
## Module
Attestor
## Status
IMPLEMENTED
## Description
Content-addressed identifiers are implemented for proof chain artifacts. EvidenceLocker provides bundle building. Full OCI/MinIO CAS for SBOM/VEX blobs is not fully visible.
## What's Implemented
- **Content-Addressed ID Generator**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Identifiers/` -- ArtifactId, EvidenceId, ProofBundleId, VexVerdictId, GenericContentAddressedId, ContentAddressedIdGenerator (with `.Graph`), Sha256IdParser.
- **SBOM OCI Publisher**: `__Libraries/StellaOps.Attestor.Oci/Services/SbomOciPublisher.cs` -- publishes SBOMs to OCI registries.
- **ORAS Attestation Attacher**: `Oci/Services/OrasAttestationAttacher.cs` -- attaches attestations to OCI images.
- **Content-Addressed Tile Store**: `StellaOps.Attestor.TileProxy/Services/ContentAddressedTileStore.cs` -- content-addressed storage for tiles.
- **Evidence Pack Builder**: `__Libraries/StellaOps.Attestor.EvidencePack/ReleaseEvidencePackBuilder.cs` -- builds evidence packs.
- **Sigstore Bundle**: `__Libraries/StellaOps.Attestor.Bundle/Models/SigstoreBundle.cs` -- Sigstore bundle model.
## What's Missing
- **Unified CAS for all artifact types**: No single content-addressed storage service that handles SBOM, VEX, and attestation blobs uniformly. Current CAS is per-domain (tiles, OCI, proof chain IDs).
- **MinIO/S3 backend**: No MinIO or S3-compatible object storage backend for CAS. Current storage is either OCI registry or filesystem.
- **Deduplication service**: No cross-artifact deduplication by content hash (e.g., same SBOM ingested twice should resolve to one stored blob).
- **CAS garbage collection**: No garbage collection or retention policy for unreferenced CAS blobs.
- **CAS REST API**: No unified REST API for CAS operations (store, retrieve, exists, list by prefix).
## Implementation Plan
- Create a unified `IContentAddressedStore` interface with store/retrieve/exists operations
- Implement MinIO/S3 backend and filesystem backend behind the interface
- Add deduplication logic (check-before-store by content hash)
- Implement garbage collection with configurable retention policies
- Add REST endpoints for CAS operations
- Migrate existing per-domain storage to use the unified CAS
- Add tests for store/retrieve, deduplication, and GC
## Related Documentation
- Source: See feature catalog

44
docs/features/unchecked/attestor/crypto-sovereign-design.md Normal file
View File

@@ -0,0 +1,44 @@
# Crypto-Sovereign Design (eIDAS/FIPS/GOST/SM/PQC)
## Module
Attestor
## Status
IMPLEMENTED
## Description
SigningKeyProfile supports crypto-sovereign configurations. SM2 tests exist for Chinese crypto support. The signing key registry supports multiple profiles. Full eIDAS/GOST/PQC implementations appear to be partially supported through the profile system but not all crypto backends are fully implemented.
## What's Implemented
- **Signing Key Profile**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Signing/SigningKeyProfile.cs` -- key profile supporting multiple algorithm families and sovereign configurations.
- **ProofChain Signer**: `Signing/ProofChainSigner.cs` (with `.Verification`) -- signing with algorithm-agnostic interface.
- **IProofChainKeyStore**: `Signing/IProofChainKeyStore.cs` -- key store interface supporting multiple key types.
- **DSSE Signing**: `Signing/DsseEnvelope.cs`, `DsseSignature.cs`, `DssePreAuthenticationEncoding.cs` -- DSSE envelope signing.
- **Attestor Signing Key Registry**: `StellaOps.Attestor.Infrastructure/Signing/AttestorSigningKeyRegistry.cs` -- registry for multiple signing key profiles.
- **DSSE SPDX3 Signer**: `__Libraries/StellaOps.Attestor.Spdx3/DsseSpdx3Signer.cs` -- SPDX3-specific signing.
- **DSSE Signing Provider**: `Spdx3/IDsseSigningProvider.cs` -- provider interface for crypto operations.
## Additional Implementation Found (Cryptography Plugins)
The following crypto plugins exist under `src/Cryptography/` with a plugin architecture (`CryptoPluginBase.cs`, `MultiProfileSigner.cs`, `SignatureProfile.cs`):
- **GOST**: `src/Cryptography/StellaOps.Cryptography.Plugin.Gost/GostPlugin.cs` -- GOST R 34.10-2012 support
- **eIDAS**: `src/Cryptography/StellaOps.Cryptography.Plugin.Eidas/EidasPlugin.cs` -- includes ETSI conformance test vectors
- **SM2/SM3**: `src/Cryptography/StellaOps.Cryptography.Plugin.Sm/` -- SM2/SM3 support
- **FIPS**: `src/Cryptography/StellaOps.Cryptography.Plugin.Fips/` -- FIPS 140 compliance plugin
- **HSM**: `src/Cryptography/StellaOps.Cryptography.Plugin.Hsm/` -- HSM integration plugin
- **Tests**: `src/Cryptography/__Tests/` and `src/__Libraries/__Tests/StellaOps.Cryptography.Tests/`
## What's Missing
- **Post-Quantum Cryptography (PQC)**: No CRYSTALS-Dilithium, SPHINCS+, or other PQC algorithm support. The profile system can model PQC keys but no backend implements them. This is the only major crypto profile gap.
- **eIDAS qualified signature validation**: Plugin exists but validation that timestamps meet eIDAS Article 42 qualified timestamp requirements may not be complete.
- **Crypto provider integration with Attestor SigningKeyProfile**: The Cryptography plugin system and the Attestor `SigningKeyProfile` are not fully bridged -- Attestor signing uses its own key profiles rather than the Cryptography plugin registry.
- **Algorithm negotiation**: No cross-sovereign algorithm negotiation for interoperability between different crypto profiles.
## Implementation Plan
- Implement PQC plugin (CRYSTALS-Dilithium, SPHINCS+) following the existing CryptoPluginBase pattern
- Bridge Cryptography plugin registry with Attestor SigningKeyProfile for unified key management
- Add eIDAS Article 42 qualified timestamp validation
- Add algorithm negotiation for cross-sovereign interoperability
- Verify ETSI conformance test vectors pass end-to-end for eIDAS plugin
## Related Documentation
- Source: See feature catalog

52
docs/features/unchecked/attestor/dsse-envelope-size-management-and-gateway-traversal.md Normal file
View File

@@ -0,0 +1,52 @@
# DSSE Envelope Size Management (Guardrails, Chunking, Gateway Awareness)
## Module
Attestor (with CLI and Scanner integration)
## Status
IMPLEMENTED
## Description
DSSE envelope construction and Rekor submission exist, but no explicit size guardrails (70-100KB heuristic), automatic payload splitting/chunking, or gateway-aware sizing logic is implemented. The architecture stores full attestations internally and uses Rekor for hash-based inclusion proofs. Envelope size awareness exists in EPSS fetcher and delta-sig CLI commands, and bundling/queue options have configurable size limits.
## What's Implemented
- **Enhanced Rekor Proof Builder**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Rekor/EnhancedRekorProofBuilder.cs` (with `.Build`, `.Validate`) -- builds and validates Rekor proofs for DSSE envelopes.
- **DSSE Envelope**: `ProofChain/Signing/DsseEnvelope.cs`, `DsseSignature.cs` -- DSSE envelope models.
- **Rekor Queue Options**: `StellaOps.Attestor.Core/Options/RekorQueueOptions.cs` -- configurable queue options.
- **Rekor Submission Queue**: `Core/Queue/IRekorSubmissionQueue.cs` with `PostgresRekorSubmissionQueue.cs` -- submission queue.
- **Resilient Rekor Client**: `Infrastructure/Rekor/ResilientRekorClient.cs` -- resilient HTTP client with retry and circuit breaker.
- **Tile Proxy Options**: `StellaOps.Attestor.TileProxy/TileProxyOptions.cs` -- size-related configuration for tile caching.
- **Delta-Sig Attestation CLI**: `src/Cli/StellaOps.Cli/Commands/Binary/DeltaSigCommandGroup.cs` -- uses DSSE envelope creation and Rekor submission.
- **Bundle Export with DSSE**: `src/Cli/StellaOps.Cli/Commands/BundleExportCommand.cs` -- `--include-dsse` option for DSSE envelope inclusion.
- **Bundle Verify with DSSE**: `src/Cli/StellaOps.Cli/Commands/BundleVerifyCommand.cs` -- DSSE signature verification.
- **Witness DSSE**: `src/Cli/StellaOps.Cli/Commands/Witness/WitnessCoreCommandGroup.cs` -- `--format envelope` option.
## What's Missing
- **Explicit size guardrails**: No pre-submission validation rejecting DSSE envelopes exceeding a configurable size limit (70-100KB) before Rekor submission.
- **Hash-only mode fallback**: No automatic fallback to submitting only the payload hash (rather than full envelope) when size exceeds the limit.
- **Payload chunking/splitting**: No mechanism to split large DSSE payloads into smaller chunks with a manifest linking them, or Merkle-based sharding.
- **Per-predicate-type size budget**: No configurable size limits per predicate type (e.g., SBOM attestations can be larger than verdict attestations).
- **Gateway-aware sizing**: No NGINX/WAF request body size coordination. Infrastructure teams must manually align `client_max_body_size` with attestation sizes.
- **Streaming submission**: No chunked/streaming upload for large envelopes.
- **Size metrics and alerting**: No telemetry tracking envelope sizes and alerting when they approach the threshold.
- **Compression**: No optional payload compression (gzip) to reduce envelope size before submission.
- **CLI size warnings**: No warning in CLI when a generated envelope exceeds Rekor's size limit, no `--max-envelope-size` option.
## Implementation Plan
- Add size validation step in `EnhancedRekorProofBuilder.Validate` checking against configurable size limit (default 100KB)
- Implement hash-only submission mode as automatic fallback for oversized envelopes
- Add per-predicate-type size budget configuration
- Implement `IEnvelopeShardingService` for Merkle-based sharding of large attestations
- Add optional payload compression (gzip) for envelopes near the threshold
- Collect size metrics via existing telemetry infrastructure
- Add envelope size check to CLI attest/export commands with warning/error on oversized envelopes
- Document gateway configuration requirements (NGINX/WAF body size limits)
- Add tests for size validation, fallback behavior, chunking, and metrics collection
## Related Documentation
- Source: See feature catalog
## Merged From
- `attestor/dsse-envelope-size-awareness.md` (deleted)
- `attestor/rekor-envelope-size-guardrails.md` (deleted)
- `cli/dsse-envelope-size-management.md` (deleted)

36
docs/features/unchecked/attestor/dsse-signed-exception-objects-with-recheck-policy.md Normal file
View File

@@ -0,0 +1,36 @@
# DSSE-Signed Exception Objects with Recheck Policy
## Module
Attestor
## Status
IMPLEMENTED
## Description
Policy exceptions framework with models, repositories, and services exists. DSSE signing infrastructure is available. Full UI exception modal with recheck policy enforcement is partially complete.
## What's Implemented
- **Budget Exception Entry**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Statements/BudgetExceptionEntry.cs` -- exception entry model.
- **Exception Ref**: `ProofChain/Services/ExceptionRef.cs` -- reference to an approved exception.
- **VEX Override System**: `__Libraries/StellaOps.Attestor.StandardPredicates/VexOverride/` -- VexOverridePredicateBuilder (with `.Build`, `.Serialize`, `.WithMethods`), VexOverrideDecision, EvidenceReference -- structured override/exception with evidence.
- **DSSE Signing Infrastructure**: `ProofChain/Signing/ProofChainSigner.cs`, `DsseEnvelope.cs` -- available DSSE signing.
- **Policy Decision**: `Predicates/PolicyDecision.cs` -- policy decision referencing exceptions.
## What's Missing
- **DSSE-signed exception objects**: Exceptions are not individually DSSE-signed as standalone attestation artifacts. They exist as records within larger predicates but are not independently verifiable.
- **Recheck policy enforcement**: No automated recheck scheduling that re-evaluates exceptions at configured intervals (e.g., 30-day review cycle).
- **Exception expiry enforcement**: No automated enforcement of exception expiry dates with re-approval workflow.
- **Exception approval workflow**: No multi-party approval flow for exception creation (e.g., two approvers required for critical CVE exceptions).
- **Exception audit trail**: No dedicated audit trail for exception lifecycle (created, approved, rechecked, expired, revoked).
## Implementation Plan
- Create `DsseSignedException` model wrapping exception objects in DSSE envelopes
- Implement recheck policy with configurable intervals (Scheduler integration)
- Add exception expiry enforcement with notification before expiry
- Build multi-party approval workflow for high-severity exceptions
- Create exception audit trail using the existing AuditHashLogger infrastructure
- Add UI exception modal with recheck policy configuration
- Add tests for signing, recheck scheduling, and expiry enforcement
## Related Documentation
- Source: See feature catalog

35
docs/features/unchecked/attestor/dsse-wrapped-reach-maps.md Normal file
View File

@@ -0,0 +1,35 @@
# DSSE-Wrapped Reach-Maps
## Module
Attestor
## Status
IMPLEMENTED
## Description
Rich graphs and suppression witnesses exist with signing infrastructure available, but a specific "signed reach-map artifact" as a standalone DSSE-wrapped output is not distinctly implemented as described.
## What's Implemented
- **Reachability Witness Payload**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Statements/ReachabilityWitnessPayload.cs` (with `.Path`) -- reachability witness data with call paths.
- **Witness Path Nodes**: `Statements/WitnessCallPathNode.cs`, `WitnessPathNode.cs` -- call path node models.
- **Micro Witness Evidence**: `Predicates/MicroWitnessFunctionEvidence.cs`, `MicroWitnessBinaryRef.cs`, `MicroWitnessCveRef.cs`, `MicroWitnessSbomRef.cs` -- function-level reachability evidence.
- **DSSE Signing**: `Signing/ProofChainSigner.cs`, `DsseEnvelope.cs` -- available signing infrastructure.
- **Proof Graph**: `Graph/InMemoryProofGraphService.cs` (with `.Mutation`, `.Queries`, `.Subgraph`) -- graph model for proof evidence.
## What's Missing
- **Standalone reach-map artifact**: No dedicated reach-map document type that captures the full reachability graph (all functions, edges, and reachability status) as a single DSSE-wrapped artifact.
- **Reach-map predicate type**: No registered predicate type URI (e.g., `https://stellaops.org/attestation/reachmap/v1`) for reach-map attestations.
- **Full graph serialization**: Reachability evidence is captured per-CVE (micro-witness) not as a complete call graph that can be independently verified.
- **Reach-map versioning**: No mechanism to version reach-maps and detect changes between scans.
- **Reach-map OCI attachment**: No pipeline to attach DSSE-signed reach-maps to OCI images as referrers.
## Implementation Plan
- Define a reach-map predicate type with full call graph serialization
- Create a `ReachMapBuilder` that aggregates all micro-witness data into a single reach-map document
- Implement DSSE signing for reach-map documents using existing `ProofChainSigner`
- Add reach-map versioning with diff detection between scans
- Wire OCI attachment via existing `OrasAttestationAttacher`
- Add tests for reach-map building, signing, and versioning
## Related Documentation
- Source: See feature catalog

37
docs/features/unchecked/attestor/evidence-coverage-score-for-ai-gating.md Normal file
View File

@@ -0,0 +1,37 @@
# Evidence Coverage Score for AI Gating
## Module
Attestor
## Status
IMPLEMENTED
## Description
The concept of gating AI output behind evidence quality exists via the AIAuthorityClassifier which scores explanation, remediation, VEX draft, and policy draft quality. The specific UX badge component and coverage scoring service described in the advisory are not implemented as standalone features.
## What's Implemented
- **AI Authority Classifier**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Predicates/AI/AIAuthorityClassifier.cs` -- classifies AI artifacts by authority level (Suggestion, EvidenceBacked, AuthorityThreshold).
- **AI Authority Scoring**: `AI/AIAuthorityClassifier.Explanation.cs`, `.ExplanationScore.cs`, `.Remediation.cs`, `.RemediationScore.cs`, `.VexDraft.cs`, `.VexDraftScore.cs`, `.PolicyDraft.cs`, `.PolicyDraftScore.cs` -- per-artifact-type scoring.
- **AI Authority Thresholds**: `AI/AIAuthorityThresholds.cs` -- configurable thresholds for authority classification.
- **AI Artifact Verification Step**: `Verification/AIArtifactVerificationStep.cs` (with `.Classify`, `.Execute`, `.Helpers`, `.Summary`, `.VerifyParse`, `.VerifyValidation`) -- verification step for AI-generated artifacts.
- **AI Artifact Authority**: `AI/AIArtifactAuthority.cs` -- authority level model.
- **AI Authority Classification Result**: `AI/AIAuthorityClassificationResult.cs` -- classification result model.
## What's Missing
- **Evidence coverage scoring service**: No dedicated service that computes an overall evidence coverage score (0-100%) across all evidence types for a given subject.
- **Coverage badge UX component**: No frontend badge component showing coverage level (e.g., green/yellow/red) based on evidence completeness.
- **AI gating policy**: No policy that blocks AI outputs below a configurable coverage threshold from being promoted to verdicts.
- **Coverage gap analysis**: No analysis identifying which evidence types are missing (e.g., "reachability evidence missing" or "no binary analysis") for a subject.
- **Coverage scoring predicates**: No predicate type for attestable coverage scores.
## Implementation Plan
- Create `EvidenceCoverageScorer` service computing coverage across all evidence types
- Define coverage dimensions (reachability, binary analysis, SBOM completeness, VEX coverage, provenance)
- Implement AI gating policy that requires minimum coverage before promoting AI outputs
- Build coverage gap analysis reporting missing evidence types
- Create coverage score predicate type for attestation
- Add UX badge component with color-coded coverage level
- Add tests for coverage scoring, gap analysis, and AI gating
## Related Documentation
- Source: See feature catalog

36
docs/features/unchecked/attestor/evidence-subgraph-ui-visualization.md Normal file
View File

@@ -0,0 +1,36 @@
# Evidence Subgraph UI Visualization
## Module
Attestor
## Status
IMPLEMENTED
## Description
Backend proof graph model is implemented (nodes, edges, subgraphs, paths). Evidence panel e2e tests exist. Full frontend visualization component status unclear from source search alone.
## What's Implemented
- **Proof Graph Model**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Graph/InMemoryProofGraphService.cs` (with `.Mutation`, `.Queries`, `.Subgraph`) -- graph service with node/edge management, subgraph extraction, and path queries.
- **Graph Node**: `Graph/ProofGraphNode.cs` -- node model with type and metadata.
- **Graph Edge**: `Graph/ProofGraphEdge.cs` -- edge model with type linking nodes.
- **Graph Node/Edge Types**: `Graph/ProofGraphNodeType.cs`, `Graph/ProofGraphEdgeType.cs` -- typed node and edge enumerations.
- **Graph Path**: `Graph/ProofGraphPath.cs` -- path through the proof graph.
- **Graph Subgraph**: `Graph/ProofGraphSubgraph.cs` -- extracted subgraph for a specific subject.
## What's Missing
- **Frontend graph visualization component**: No Angular component rendering the proof graph as an interactive visualization (nodes as circles/rectangles, edges as arrows).
- **Interactive exploration**: No click-to-expand, zoom, pan, or filter functionality for graph navigation in the UI.
- **Subgraph API endpoint**: The WebService controllers do not expose a dedicated endpoint for fetching proof graph subgraphs for a given subject.
- **Graph layout algorithm**: No force-directed or hierarchical layout algorithm for rendering the graph in 2D.
- **Evidence node detail panel**: No side panel showing node details (attestation content, verification status) when a node is selected.
## Implementation Plan
- Add a REST endpoint in `ProofChainController` for subgraph queries by subject
- Create an Angular component using a graph visualization library (e.g., D3.js or Cytoscape.js)
- Implement interactive exploration (zoom, pan, click-to-expand, filtering by node/edge type)
- Add a node detail panel showing attestation content and verification status
- Implement graph layout algorithm (hierarchical for proof chains, force-directed for evidence graphs)
- Add e2e tests for graph rendering and interaction
## Related Documentation
- Source: See feature catalog

38
docs/features/unchecked/attestor/field-level-ownership-map-for-receipts-and-bundles.md Normal file
View File

@@ -0,0 +1,38 @@
# Field-Level Ownership Map for Receipts and Bundles
## Module
Attestor
## Status
IMPLEMENTED
## Description
Rekor entry and receipt models exist with structured fields, but a formal field-level ownership map document (checklist page) linking fields to specific module responsibilities was not found as a standalone artifact.
## What's Implemented
- **Verification Receipt**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Receipts/VerificationReceipt.cs` -- receipt model with structured fields.
- **Verification Check**: `Receipts/VerificationCheck.cs` -- individual verification check within a receipt.
- **Verification Context**: `Receipts/VerificationContext.cs` -- context for verification operations.
- **Verification Result**: `Receipts/VerificationResult.cs` -- verification outcome.
- **Sigstore Bundle**: `__Libraries/StellaOps.Attestor.Bundle/Models/SigstoreBundle.cs` -- Sigstore bundle model.
- **Verification Material**: `Bundle/Models/VerificationMaterial.cs` -- material used for verification.
- **Transparency Log Entry**: `Bundle/Models/TransparencyLogEntry.cs` -- log entry within bundles.
- **Rekor Receipt**: `StellaOps.Attestor.Core/Rekor/RekorReceipt.cs` -- Rekor receipt model.
## What's Missing
- **Field-level ownership map document**: No machine-readable or human-readable document mapping each field in receipts/bundles to the responsible module (e.g., "signature" -> Signing module, "inclusion_proof" -> Rekor module).
- **Ownership validation**: No automated check that each field in a receipt/bundle is populated by its designated owner module.
- **Ownership-aware serialization**: No serialization that tracks which module wrote each field for audit purposes.
- **Ownership documentation generator**: No tool to auto-generate ownership documentation from code annotations.
- **Cross-module field conflict detection**: No mechanism to detect when two modules attempt to populate the same field.
## Implementation Plan
- Define a field-level ownership schema mapping fields to module responsibilities
- Annotate receipt/bundle models with `[OwnedBy("ModuleName")]` attributes
- Create a documentation generator that extracts ownership annotations into a readable map
- Implement ownership validation ensuring fields are only populated by designated modules
- Add conflict detection for duplicate field population
- Add tests for ownership validation and documentation generation
## Related Documentation
- Source: See feature catalog

37
docs/features/unchecked/attestor/idempotent-sbom-attestation-apis.md Normal file
View File

@@ -0,0 +1,37 @@
# Idempotent SBOM/Attestation APIs
## Module
Attestor
## Status
IMPLEMENTED
## Description
Content-addressed identification for artifacts is implemented. Full idempotent REST API endpoints (POST /sbom/ingest, POST /attest/verify) are not clearly visible as standalone web service endpoints.
## What's Implemented
- **Content-Addressed IDs**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Identifiers/` -- ArtifactId, EvidenceId, ProofBundleId, GenericContentAddressedId, ContentAddressedIdGenerator (with `.Graph`), Sha256IdParser -- SHA-256 based content-addressed identification.
- **Proof Chain REST API**: `StellaOps.Attestor.WebService/Controllers/ProofChainController.cs` -- existing proof chain API endpoints.
- **Bundles Controller**: `WebService/Controllers/BundlesController.cs` -- bundle management endpoints.
- **Verify Controller**: `WebService/Controllers/VerifyController.cs` -- verification endpoints.
- **Chain Controller**: `WebService/Controllers/ChainController.cs` -- chain query endpoints.
- **SBOM OCI Publisher**: `__Libraries/StellaOps.Attestor.Oci/Services/SbomOciPublisher.cs` -- publishes SBOMs to OCI registries.
## What's Missing
- **Idempotent SBOM ingest endpoint**: No `POST /sbom/ingest` endpoint that accepts an SBOM and returns the same content-addressed ID on duplicate submissions without creating duplicate records.
- **Idempotent attestation verify endpoint**: No `POST /attest/verify` endpoint that caches verification results by content hash for repeat submissions.
- **Idempotency key support**: No HTTP idempotency key header (`Idempotency-Key`) support for POST endpoints.
- **Content-addressed deduplication at API level**: Content-addressed IDs exist at the library level but API endpoints do not use them for deduplication (checking if content already exists before processing).
- **Conditional response (ETag/304)**: No ETag-based conditional responses for GET endpoints to avoid re-fetching unchanged content.
## Implementation Plan
- Add `POST /sbom/ingest` endpoint with content-hash-based deduplication
- Add `POST /attest/verify` endpoint with cached verification results
- Implement idempotency key support for all POST endpoints
- Add content-addressed deduplication at the API layer (check-before-store)
- Add ETag support for GET endpoints
- Add tests for idempotency (duplicate submissions return same result)
## Related Documentation
- Source: See feature catalog
- Related: `scanner/idempotent-attestation-submission.md` (scanner-side submission idempotency)

39
docs/features/unchecked/attestor/immutable-evidence-storage-and-regulatory-alignment.md Normal file
View File

@@ -0,0 +1,39 @@
# Immutable Evidence Storage and Regulatory Alignment (NIS2/DORA/ISO-27001)
## Module
Attestor
## Status
IMPLEMENTED
## Description
The underlying evidence storage and proof chain infrastructure exists. Specific regulatory compliance mapping (NIS2, DORA, ISO-27001 report templates) not found as distinct modules.
## What's Implemented
- **Append-Only Verdict Ledger**: `src/Attestor/__Libraries/StellaOps.Attestor.Persistence/Repositories/PostgresVerdictLedgerRepository.cs` -- append-only storage with hash chain integrity.
- **Verdict Ledger Entry**: `Persistence/Entities/VerdictLedgerEntry.cs` -- ledger entry with previous hash.
- **Audit Hash Logger**: `__Libraries/StellaOps.Attestor.ProofChain/Audit/AuditHashLogger.cs` (with `.Validation`) -- tamper-evident audit logging.
- **Hash Audit Record**: `Audit/HashAuditRecord.cs` -- individual audit record.
- **Evidence Pack Builder**: `__Libraries/StellaOps.Attestor.EvidencePack/ReleaseEvidencePackBuilder.cs` -- builds evidence packs for release decisions.
- **Evidence Pack Serializer**: `EvidencePack/ReleaseEvidencePackSerializer.cs` -- serializes evidence packs.
- **Merkle Tree Proofs**: `ProofChain/Merkle/DeterministicMerkleTreeBuilder.cs` -- Merkle binding of evidence.
- **Trust Evidence Chain**: `__Libraries/StellaOps.Attestor.TrustVerdict/Evidence/TrustEvidenceChain.cs` -- evidence chain with Merkle proofs.
## What's Missing
- **NIS2 compliance report template**: No report template mapping evidence artifacts to NIS2 requirements (incident reporting, risk management, supply chain security).
- **DORA compliance report template**: No report template for DORA requirements (ICT risk management, incident classification, third-party risk).
- **ISO-27001 control mapping**: No mapping of evidence artifacts to ISO-27001 Annex A controls.
- **Retention policy enforcement**: No automated retention policy enforcing minimum evidence retention periods required by regulations.
- **Evidence completeness checker**: No service verifying that all required evidence artifacts exist for a given regulatory framework.
- **Regulatory export format**: No standardized export format for regulatory auditors (structured PDF/HTML reports with evidence links).
## Implementation Plan
- Define regulatory control mappings (NIS2, DORA, ISO-27001) as configuration
- Implement report templates that map stored evidence to regulatory controls
- Add retention policy enforcement with configurable minimum periods per regulation
- Create evidence completeness checker verifying all required artifacts exist
- Build export service generating structured audit reports
- Add tests for compliance mapping, retention enforcement, and report generation
## Related Documentation
- Source: See feature catalog

43
docs/features/unchecked/attestor/in-toto-link-attestation-capture.md Normal file
View File

@@ -0,0 +1,43 @@
# In-toto Link Attestation Capture
## Module
Attestor
## Status
IMPLEMENTED
## Description
The attestation pipeline supports DSSE-wrapped statements and proof chains, which follow in-toto patterns. However, the specific per-step in-toto link capture with `in-toto-run` wrappers as described is not directly implemented.
## What's Implemented
- **In-Toto Link Model**: `src/Attestor/StellaOps.Attestor/StellaOps.Attestor.Core/InToto/InTotoLink.cs` -- in-toto link data model.
- **In-Toto Link Predicate**: `InToto/InTotoLinkPredicate.cs` -- link predicate with materials and products.
- **Link Builder**: `InToto/LinkBuilder.cs` -- builder for constructing in-toto links.
- **Link Recorder**: `InToto/LinkRecorder.cs` -- records link data during step execution. Implements `ILinkRecorder.cs`.
- **In-Toto Link Emitter**: `InToto/IInTotoLinkEmitter.cs` -- interface for emitting captured links.
- **In-Toto Link Signing Service**: `InToto/IInTotoLinkSigningService.cs` with `Infrastructure/InToto/InTotoLinkSigningService.cs` -- signs captured links.
- **In-Toto Layout**: `InToto/Layout/InTotoLayout.cs` -- layout defining expected supply chain steps.
- **Layout Verifier**: `InToto/Layout/LayoutVerifier.cs` -- verifies links against layout. Implements `ILayoutVerifier.cs`.
- **Artifact Digests**: `InToto/ArtifactDigests.cs` -- input/output artifact digest tracking.
- **Material Spec**: `InToto/MaterialSpec.cs` -- material specification for links.
- **In-Toto Statement**: `__Libraries/StellaOps.Attestor.ProofChain/Statements/InTotoStatement.cs` -- generic in-toto statement.
- **Link Contracts**: `WebService/Contracts/InTotoLinkContracts.cs` -- API contracts for link operations.
- **Tests**: `Core.Tests/InToto/InTotoLinkTests.cs`, `InTotoGoldenTests.cs`, `ProofChain.Tests/Statements/InTotoStatementSnapshotTests.cs`
## What's Missing
- **`in-toto-run` wrapper**: No CLI wrapper that automatically captures materials before and products after command execution (analogous to `in-toto-run` from the reference implementation).
- **Automatic link capture in CI**: No CI integration that automatically records links for each pipeline step.
- **Link storage and retrieval API**: No REST endpoint for storing and querying captured links by step name or functionary.
- **Multi-functionary layout verification**: Layout verification exists but multi-functionary threshold verification (k-of-n) may not be fully wired.
- **Link chain verification**: No end-to-end verification that all links in a layout chain are present and valid.
## Implementation Plan
- Implement an `in-toto-run` CLI command wrapping command execution with automatic material/product capture
- Add CI step link capture via webhook or plugin integration
- Create REST endpoints for link storage and retrieval in `ProofChainController`
- Complete multi-functionary threshold verification in `LayoutVerifier`
- Implement end-to-end link chain verification
- Add tests for CLI wrapper, CI capture, and chain verification
## Related Documentation
- Source: See feature catalog

39
docs/features/unchecked/attestor/monthly-bundle-rotation-and-re-signing.md Normal file
View File

@@ -0,0 +1,39 @@
# Monthly Bundle Rotation and Re-Signing
## Module
Attestor
## Status
IMPLEMENTED
## Description
The attestation and signing infrastructure exists but the specific monthly bundle re-signing workflow is a planned sprint task.
## What's Implemented
- **DSSE Signing**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Signing/ProofChainSigner.cs` (with `.Verification`) -- DSSE signing and verification.
- **Signing Key Profile**: `Signing/SigningKeyProfile.cs` -- key profile with algorithm and key material.
- **Attestor Signing Key Registry**: `StellaOps.Attestor.Infrastructure/Signing/AttestorSigningKeyRegistry.cs` -- multi-key registry.
- **Sigstore Bundle Builder**: `__Libraries/StellaOps.Attestor.Bundle/Builder/SigstoreBundleBuilder.cs` -- builds Sigstore bundles.
- **Sigstore Bundle Verifier**: `Bundle/Verification/SigstoreBundleVerifier.cs` -- verifies bundle integrity.
- **Sigstore Bundle Serializer**: `Bundle/Serialization/SigstoreBundleSerializer.cs` -- serializes bundles.
- **Timestamping Service**: `__Libraries/StellaOps.Attestor.Timestamping/AttestationTimestampService.cs` -- timestamping for re-signing evidence.
## What's Missing
- **Monthly rotation scheduler**: No scheduled job that triggers bundle rotation on a monthly cadence.
- **Re-signing workflow**: No workflow that takes existing bundles, verifies them with the old key, and re-signs with a new key.
- **Key rotation ceremony**: No key rotation ceremony process (generate new key, sign transition attestation, update trust anchors).
- **Bundle version tracking**: No mechanism to track bundle versions and maintain a history of re-signed bundles.
- **Re-signing attestation**: No attestation type recording that a bundle was re-signed (old key ID, new key ID, rotation reason).
- **Automated trust anchor update**: No automation to update trust anchors when keys rotate.
## Implementation Plan
- Create a `BundleRotationJob` scheduled monthly via Scheduler integration
- Implement re-signing workflow (verify old -> sign with new -> update references)
- Define a re-signing attestation predicate recording rotation metadata
- Add key rotation ceremony process with multi-party approval
- Implement bundle version tracking with rotation history
- Automate trust anchor updates on key rotation
- Add tests for rotation workflow, re-signing, and trust anchor updates
## Related Documentation
- Source: See feature catalog

38
docs/features/unchecked/attestor/noise-ledger.md Normal file
View File

@@ -0,0 +1,38 @@
# Noise Ledger (Audit Log of Suppressions)
## Module
Attestor
## Status
IMPLEMENTED
## Description
Suppression witnesses and audit hash logging exist in the backend. CLI audit commands exist. A dedicated "Noise Ledger" UX component is not present, though the underlying audit/suppression infrastructure is in place.
## What's Implemented
- **Audit Hash Logger**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Audit/AuditHashLogger.cs` (with `.Validation`) -- tamper-evident audit logging for all actions including suppressions.
- **Hash Audit Record**: `Audit/HashAuditRecord.cs` -- individual audit record with hash chain.
- **Audit Artifact Types**: `Audit/AuditArtifactTypes.cs` -- enumeration of auditable artifact types.
- **VEX Override System**: `__Libraries/StellaOps.Attestor.StandardPredicates/VexOverride/` -- structured VEX overrides (suppressions) with evidence and justification.
- **Change Trace Attestation Service**: `ProofChain/ChangeTrace/ChangeTraceAttestationService.cs` -- tracks changes including suppressions.
- **VEX Delta Tracking**: `Predicates/VexDeltaPredicate.cs`, `VexDeltaChange.cs` -- tracks VEX status transitions.
## What's Missing
- **Dedicated Noise Ledger service**: No standalone service aggregating all suppression/noise decisions into a queryable ledger.
- **Noise Ledger UI component**: No frontend page showing a filterable, sortable list of all suppressions with justifications and evidence.
- **Suppression statistics**: No aggregated statistics (suppressions per severity, per component, per time period).
- **Suppression review workflow**: No periodic review workflow that surfaces suppressions due for re-evaluation.
- **Suppression export**: No dedicated export format for suppression audit trail (e.g., for compliance reporting).
- **Noise pattern detection**: No automated detection of noise patterns (e.g., same CVE suppressed across all environments).
## Implementation Plan
- Create `NoiseLedgerService` aggregating suppressions from VEX overrides, audit logs, and change traces
- Add REST endpoints for querying the noise ledger with filtering/pagination
- Build Angular UI component showing suppression list with details, justification, and evidence links
- Implement suppression statistics and trend analysis
- Add periodic review workflow surfacing stale suppressions
- Add export functionality for compliance auditors
- Add tests for ledger aggregation, statistics, and review scheduling
## Related Documentation
- Source: See feature catalog

41
docs/features/unchecked/attestor/postgresql-persistence-layer.md Normal file
View File

@@ -0,0 +1,41 @@
# PostgreSQL Persistence Layer (Per-Module Schemas, Migrations, RLS)
## Module
Attestor
## Status
IMPLEMENTED
## Description
PostgreSQL persistence is implemented for Attestor, Scanner, Policy, and TrustVerdict modules with Npgsql, migrations, and repository patterns. Full blueprint (RLS scaffolds, temporal tables for Unknowns, materialized views for triage) is partially realized; not all modules have dedicated schemas.
## What's Implemented
- **Proof Chain DB Context**: `src/Attestor/__Libraries/StellaOps.Attestor.Persistence/ProofChainDbContext.cs` -- EF Core DbContext for proof chain entities.
- **Proof Chain Repository**: `Persistence/Repositories/IProofChainRepository.cs` -- repository interface for proof chain operations.
- **Verdict Ledger Repository**: `Persistence/Repositories/PostgresVerdictLedgerRepository.cs` -- PostgreSQL verdict ledger with append-only semantics.
- **Trust Verdict Repository**: `__Libraries/StellaOps.Attestor.TrustVerdict/Persistence/PostgresTrustVerdictRepository.cs` (with `.Store`, `.GetById`, `.Query`, `.Delete`, `.Stats`) -- PostgreSQL trust verdict persistence.
- **Watchlist Repository**: `__Libraries/StellaOps.Attestor.Watchlist/Storage/PostgresWatchlistRepository.cs` (with `.List`, `.Mapping`, `.Sql`, `.Upsert`) -- PostgreSQL watchlist persistence.
- **Rekor Checkpoint Store**: `StellaOps.Attestor.Storage/Rekor/PostgresRekorCheckpointStore.cs` -- Rekor checkpoint persistence.
- **Rekor Submission Queue**: `Infrastructure/Queue/PostgresRekorSubmissionQueue.cs` -- PostgreSQL-backed submission queue.
- **Persistence Entities**: `Persistence/Entities/` -- VerdictLedgerEntry, RekorEntryEntity, TrustAnchorEntity, and others.
- **Migrations**: `TrustVerdict/Migrations/` -- database migration files.
## What's Missing
- **Per-module schema isolation**: Not all modules use dedicated PostgreSQL schemas (e.g., `attestor.`, `verdict.`, `watchlist.`). Some share the default schema.
- **Row-Level Security (RLS)**: RLS policies for multi-tenant isolation are not scaffolded. Tenant filtering relies on application-level WHERE clauses.
- **Temporal tables for Unknowns**: No temporal table implementation for tracking unknown state over time with system-versioned history.
- **Materialized views for triage**: No materialized views aggregating triage data for fast dashboard queries.
- **Connection pooling configuration**: No explicit PgBouncer or Npgsql connection pool tuning for high-concurrency workloads.
- **Database health checks**: No dedicated PostgreSQL health check beyond basic connectivity.
## Implementation Plan
- Implement per-module schema isolation with schema-qualified table names
- Scaffold RLS policies for tenant isolation with PostgreSQL policies
- Add temporal tables for Unknowns module using PostgreSQL system versioning
- Create materialized views for triage dashboard aggregation
- Configure connection pooling with Npgsql tuning parameters
- Add PostgreSQL health checks with latency and connection pool monitoring
- Add migration tests validating schema changes
## Related Documentation
- Source: See feature catalog

23
docs/features/unchecked/attestor/s3-minio-gcs-object-storage-for-tiles.md Normal file
View File

@@ -0,0 +1,23 @@
# S3/MinIO/GCS Object Storage for Tiles
## Status
NOT_FOUND
## Description
Advisory proposed object storage (S3/MinIO/GCS) for large tile blobs as an alternative to filesystem cache. This was explicitly deferred as a low-priority future enhancement.
## Why Not Implemented
- No S3, MinIO, or GCS client libraries or storage providers found in `src/`
- No object storage abstraction layer or blob storage service exists
- The Attestor module stores artifacts using local filesystem and PostgreSQL persistence, not object storage
- The Evidence Locker (`src/EvidenceLocker/`) and tile systems use database-backed storage
- This was explicitly described as a low-priority future enhancement in the advisory
- The offline-first posture makes cloud object storage (S3/GCS) less aligned with core architecture; MinIO would be the more appropriate option for self-hosted deployments
## Source
- Feature matrix scan
## Notes
- Module: Attestor
- Modules referenced: `src/Attestor`
- Deferred by design; current filesystem+PostgreSQL storage is sufficient for initial deployment

36
docs/features/unchecked/attestor/score-replay-and-verification.md Normal file
View File

@@ -0,0 +1,36 @@
# Score Replay and Verification
## Module
Attestor
## Status
IMPLEMENTED
## Description
Replay subsystem exists with a dedicated module, ProofChain replay models, and CLI commands. However, the specific `/score/{id}/replay` REST endpoint and DSSE-signed replay attestation with payload type `application/vnd.stella.score+json` are not yet wired up (sprint tasks TSF-011, TSF-007).
## What's Implemented
- **Replay Models**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Replay/` -- ReplayInputArtifact, ReplayPromptTemplate, ReplayResult, ReplayStatus, ReplayVerificationResult, AIArtifactReplayManifest, IAIArtifactReplayer.
- **Verdict Receipt Payload**: `Statements/VerdictReceiptPayload.cs` -- captures verdict inputs for replay.
- **Verification Replay Log Builder**: `__Libraries/StellaOps.Attestor.EvidencePack/Services/VerificationReplayLogBuilder.cs` -- builds replay logs.
- **Verification Replay Log**: `EvidencePack/Models/VerificationReplayLog.cs` -- structured replay log.
- **Trust Verdict Service**: `__Libraries/StellaOps.Attestor.TrustVerdict/Services/TrustVerdictService.cs` (with `.Scoring`) -- scoring logic that could be replayed.
## What's Missing
- **`/score/{id}/replay` REST endpoint**: No REST API endpoint for triggering score replay by verdict ID.
- **DSSE-signed replay attestation**: No pipeline producing a DSSE-signed attestation with payload type `application/vnd.stella.score+json` for replayed scores.
- **Score comparison service**: No service that compares original and replayed scores, quantifying divergence.
- **Replay scheduling**: No scheduled replay of scores for regression detection (e.g., nightly replay of recent verdicts).
- **Replay dashboard**: No UI showing replay history, divergence rates, and failed replays.
## Implementation Plan
- Add `/score/{id}/replay` endpoint to `VerdictController` or a new `ReplayController`
- Implement score replay service that re-executes scoring with captured inputs
- Create DSSE-signed replay attestation with `application/vnd.stella.score+json` payload type
- Build score comparison service quantifying divergence between original and replay
- Add scheduled replay job for regression detection
- Build replay dashboard showing history and divergence rates
- Add tests for replay endpoint, comparison, and attestation signing
## Related Documentation
- Source: See feature catalog

41
docs/features/unchecked/attestor/snapshot-export-import-for-air-gap.md Normal file
View File

@@ -0,0 +1,41 @@
# Snapshot Export/Import for Air-Gap
## Module
Attestor
## Status
IMPLEMENTED
## Description
Offline verification and evidence pack serialization exists. Full standalone snapshot export/import bundle format (Level B/C portable snapshots) may still be evolving based on evidence pack infrastructure.
## What's Implemented
- **Offline Verifier**: `src/Attestor/__Libraries/StellaOps.Attestor.Offline/Services/OfflineVerifier.cs` -- offline verification without network access. Implements `IOfflineVerifier.cs`.
- **File System Root Store**: `Offline/Services/FileSystemRootStore.cs` -- filesystem-backed root store for offline verification. Implements `IOfflineRootStore.cs`.
- **Rule Bundle Signature Verifier**: `Offline/Services/RuleBundleSignatureVerifier.cs` -- verifies rule bundle signatures offline.
- **Offline Verification Result**: `Offline/Models/OfflineVerificationResult.cs` -- result model for offline verification.
- **Evidence Pack Builder**: `__Libraries/StellaOps.Attestor.EvidencePack/ReleaseEvidencePackBuilder.cs` -- builds portable evidence packs.
- **Evidence Pack Serializer**: `EvidencePack/ReleaseEvidencePackSerializer.cs` -- serializes evidence packs.
- **Evidence Pack Manifest**: `EvidencePack/Models/ReleaseEvidencePackManifest.cs` -- manifest for evidence packs.
- **Verify Templates**: `EvidencePack/Templates/VERIFY.md.template`, `verify-unix.template`, `verify.ps1.template` -- self-contained verification scripts.
- **Tile Caching**: `StellaOps.Attestor.Core/Rekor/FileSystemRekorTileCache.cs` -- cached tiles for offline use.
## What's Missing
- **Level B/C snapshot format**: No formalized snapshot level classification (Level B: evidence + verification material, Level C: full state including policies and trust anchors).
- **Snapshot export CLI command**: No `stella snapshot export` command producing a portable archive.
- **Snapshot import CLI command**: No `stella snapshot import` command ingesting a portable archive on an air-gapped system.
- **Snapshot completeness validation**: No validation ensuring the snapshot contains all required artifacts for standalone verification.
- **Differential snapshots**: No mechanism for exporting only changes since the last snapshot (incremental export).
- **Snapshot signing**: No DSSE signing of the snapshot archive itself for integrity verification before import.
## Implementation Plan
- Define snapshot format specification with Level B/C classification
- Implement `stella snapshot export` CLI command producing signed, portable archives
- Implement `stella snapshot import` CLI command with integrity validation
- Add completeness validation ensuring all required artifacts are included
- Implement differential/incremental snapshot export
- Add DSSE signing of snapshot archives
- Add tests for export, import, completeness validation, and differential snapshots
## Related Documentation
- Source: See feature catalog

38
docs/features/unchecked/attestor/unknowns-five-dimensional-triage-scoring.md Normal file
View File

@@ -0,0 +1,38 @@
# Unknowns Five-Dimensional Triage Scoring (P/E/U/C/S with Hot/Warm/Cold Bands)
## Module
Attestor
## Status
IMPLEMENTED
## Description
Unknowns aggregation with item model and aggregator service exist. The full five-dimensional weighted scoring formula (P/E/U/C/S) with Hot/Warm/Cold banding and Scheduler-driven triage automation is partially implemented.
## What's Implemented
- **IUnknownsAggregator**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Services/IUnknownsAggregator.cs` -- interface for unknowns aggregation.
- **UnknownsAggregator**: `Services/UnknownsAggregator.cs` -- aggregation with deduplication and ranking.
- **UnknownItem**: `Services/UnknownItem.cs` -- unknown item record with source, severity, category.
- **Budget Check Result**: `Services/BudgetCheckResult.cs` -- budget checking.
- **Unknowns Budget Predicate**: `Predicates/UnknownsBudgetPredicate.cs` -- attestation predicate for unknowns.
- **Uncertainty State Entry**: `Statements/UncertaintyStateEntry.cs` -- per-finding uncertainty state.
## What's Missing
- **Five-dimensional scoring formula**: No P (Probability) / E (Exposure) / U (Uncertainty) / C (Consequence) / S (Signal freshness) weighted scoring formula. Current ranking is severity-based only.
- **Hot/Warm/Cold banding**: No classification of unknowns into temperature bands based on their composite score (Hot: requires immediate triage, Warm: scheduled review, Cold: archive).
- **Configurable dimension weights**: No configuration for dimension weights (e.g., P=0.3, E=0.25, U=0.2, C=0.15, S=0.1).
- **Scheduler-driven triage automation**: No integration with Scheduler to automatically assign Hot unknowns to triage queues.
- **Score decay over time**: No temporal decay that moves unknowns from Hot to Warm to Cold based on aging.
- **Triage queue UI**: No frontend triage queue component sorted by five-dimensional score.
## Implementation Plan
- Define five-dimensional scoring formula with configurable weights per dimension
- Implement `UnknownsTriageScorer` computing P/E/U/C/S composite scores
- Add Hot/Warm/Cold banding with configurable thresholds
- Integrate with Scheduler for automated Hot triage assignment
- Implement temporal score decay moving unknowns between bands
- Build triage queue UI component sorted by composite score
- Add tests for scoring formula, banding, decay, and scheduler integration
## Related Documentation
- Source: See feature catalog

39
docs/features/unchecked/attestor/vex-findings-api-with-proof-artifacts.md Normal file
View File

@@ -0,0 +1,39 @@
# VEX Findings API with Proof Artifacts
## Module
Attestor
## Status
IMPLEMENTED
## Description
VEX verdict models, VEX delta predicates, and a VexProofSpineService exist in the backend, but the full API contract (GET /vex/findings/:id with proof artifacts) is not visible as a standalone endpoint.
## What's Implemented
- **VEX Attestation Predicate**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Predicates/VexAttestationPredicate.cs` -- VEX verdict predicate with proof references.
- **VEX Verdict Summary**: `Predicates/VexVerdictSummary.cs` -- VEX verdict summary model.
- **VEX Proof Integrator**: `Generators/VexProofIntegrator.cs` (with `.Helpers`, `.Metadata`) -- proof integration for VEX verdicts.
- **VEX Verdict Proof Payload**: `Generators/VexVerdictProofPayload.cs` -- proof-carrying VEX verdict payload.
- **VEX Verdict Statement**: `Statements/VexVerdictStatement.cs` -- in-toto statement for VEX verdicts.
- **VEX Verdict ID**: `Identifiers/VexVerdictId.cs` -- content-addressed VEX verdict identifier.
- **Proof Spine System**: `Assembly/ProofSpineRequest.cs`, `ProofSpineResult.cs`, `ProofSpineSubject.cs` -- proof spine for evidence assembly.
- **Verdict Controller**: `StellaOps.Attestor.WebService/Controllers/VerdictController.cs` -- existing verdict API.
- **Proofs Controller**: `WebService/Controllers/ProofsController.cs` -- existing proofs API.
## What's Missing
- **`GET /vex/findings/:id` endpoint**: No REST endpoint returning VEX findings with attached proof artifacts for a specific finding ID.
- **Proof artifact packaging**: No service that packages proof artifacts (DSSE signatures, Rekor receipts, Merkle proofs) alongside VEX findings in API responses.
- **Finding-level proof resolution**: No resolver that collects all proof artifacts for a specific finding (CVE + component combination).
- **Proof artifact download**: No endpoint for downloading individual proof artifacts as files.
- **Finding search with proof status filter**: No search endpoint filtering findings by proof availability (e.g., "show only findings with proof").
## Implementation Plan
- Add `GET /vex/findings/:id` endpoint returning finding details with proof artifacts
- Create a proof artifact resolver collecting all proofs for a finding
- Add proof artifact packaging in API responses (inline or as download links)
- Add `GET /vex/findings/:id/proofs` endpoint for downloading proof artifacts
- Implement finding search with proof status filtering
- Add tests for finding retrieval, proof packaging, and search filtering
## Related Documentation
- Source: See feature catalog

36
docs/features/unchecked/attestor/vex-receipt-sidebar.md Normal file
View File

@@ -0,0 +1,36 @@
# VEX Receipt Sidebar
## Module
Attestor
## Status
IMPLEMENTED
## Description
Backend VEX receipt model and verdict receipt statement exist. VEX hub feature exists in frontend but a dedicated "sidebar" UX for individual VEX receipts is not a standalone component.
## What's Implemented
- **Verdict Receipt Payload**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Statements/VerdictReceiptPayload.cs` -- receipt payload with verdict inputs, decision, and outputs.
- **Verdict Receipt Statement**: `Statements/VerdictReceiptStatement.cs` -- in-toto statement wrapping verdict receipts.
- **Verification Receipt**: `Receipts/VerificationReceipt.cs` -- verification receipt model.
- **Verification Check**: `Receipts/VerificationCheck.cs` -- individual check within a receipt.
- **VEX Verdict Summary**: `Predicates/VexVerdictSummary.cs` -- summary of VEX verdicts.
- **VEX Override Decision**: `__Libraries/StellaOps.Attestor.StandardPredicates/VexOverride/VexOverrideDecision.cs` -- VEX override decision model.
## What's Missing
- **VEX receipt sidebar Angular component**: No dedicated sidebar component showing VEX receipt details (decision, justification, evidence, verification status) when a VEX entry is selected.
- **Receipt detail API endpoint**: No API endpoint returning receipt details formatted for sidebar rendering.
- **Receipt verification status display**: No UI element showing whether the receipt's DSSE signature and Rekor inclusion have been verified.
- **Receipt history timeline**: No timeline view showing receipt history for a given CVE/component pair.
- **Receipt export/share**: No functionality to export a receipt as a standalone verifiable document or share it via link.
## Implementation Plan
- Create Angular sidebar component for VEX receipt display
- Add API endpoint returning receipt details with verification status
- Implement verification status indicator (signed, anchored, verified)
- Add receipt history timeline for per-CVE/component receipt evolution
- Implement receipt export as standalone verifiable document
- Add e2e tests for sidebar rendering, interaction, and receipt display
## Related Documentation
- Source: See feature catalog