partly or unimplemented features - now implemented
This commit is contained in:
@@ -0,0 +1,22 @@
|
||||
# AI Codex / Zastava Companion
|
||||
|
||||
## Status
|
||||
NOT_FOUND
|
||||
|
||||
## Description
|
||||
The advisory AI module exists with policy studio and LatticeRuleGenerator, but the specific "AI Codex" or "Zastava Companion" branding/feature set described in the advisory is not found.
|
||||
|
||||
## Why Not Implemented
|
||||
- The specific "AI Codex" or "Zastava Companion" branding is not found, but substantial AI infrastructure exists:
|
||||
- `src/AdvisoryAI/` provides evidence-anchored explanation generation with `EvidenceAnchoredExplanationGenerator`, `ExplanationPromptTemplates`, replay golden tests, and a web service (`AdvisoryAI.WebService/Program.cs`)
|
||||
- `src/Zastava/StellaOps.Zastava.Observer/` exists as a runtime observer module
|
||||
- The Web UI has Ask Stella components under `src/Web/.../shared/components/ai/`
|
||||
- The "AI Codex" concept (a comprehensive AI assistant branded as "Zastava Companion") appears to be a product vision not yet realized as a unified feature, though its constituent parts (AI explanations, policy studio, LatticeRuleGenerator) exist separately
|
||||
|
||||
## Source
|
||||
- Feature matrix scan
|
||||
|
||||
## Notes
|
||||
- Module: AdvisoryAI
|
||||
- Modules referenced: `src/AdvisoryAI`, `src/Zastava/`
|
||||
- Related: `src/AdvisoryAI/StellaOps.AdvisoryAI/Explanation/` (explanation generation), `src/Zastava/` (observer)
|
||||
@@ -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
|
||||
@@ -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
44
docs/features/unchecked/attestor/crypto-sovereign-design.md
Normal 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
|
||||
@@ -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)
|
||||
@@ -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
35
docs/features/unchecked/attestor/dsse-wrapped-reach-maps.md
Normal 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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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)
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
38
docs/features/unchecked/attestor/noise-ledger.md
Normal 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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
36
docs/features/unchecked/attestor/vex-receipt-sidebar.md
Normal 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
|
||||
@@ -0,0 +1,40 @@
|
||||
# RFC-3161 TSA Client for CI/CD Timestamping
|
||||
|
||||
## Module
|
||||
Authority
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
RFC 3161 TSA client infrastructure for CI/CD timestamping. A comprehensive TSA client library exists in the Authority module with ASN.1 encoding/decoding, multi-provider failover, response caching, and certificate chain verification. The eIDAS plugin adds additional compliance support. Some CI/CD-specific integration features are still missing.
|
||||
|
||||
## What's Implemented
|
||||
- **TSA Client**: `src/Authority/__Libraries/StellaOps.Authority.Timestamping/HttpTsaClient.cs` (with partials `.GetTimeStamp.cs`, `.ProviderOrdering.cs`, `.ProviderRequest.cs`, `.Verification.cs`) -- full RFC 3161 HTTP-based TSA client implementing `ITimeStampAuthorityClient` with multi-provider failover and response verification.
|
||||
- **ASN.1 Request Encoding**: `src/Authority/__Libraries/StellaOps.Authority.Timestamping/Asn1/TimeStampReqEncoder.cs` (with partials `.Algorithms.cs`, `.Extensions.cs`, `.MessageImprint.cs`) -- encodes RFC 3161 TimeStampReq ASN.1 structures with algorithm selection and extension support.
|
||||
- **ASN.1 Response Decoding**: `src/Authority/__Libraries/StellaOps.Authority.Timestamping/Asn1/TimeStampRespDecoder.cs` -- decodes TimeStampResp ASN.1 structures.
|
||||
- **ASN.1 Token Decoding**: `src/Authority/__Libraries/StellaOps.Authority.Timestamping/Asn1/TimeStampTokenDecoder.cs` (with partials `.Accuracy.cs`, `.Certificates.cs`, `.SignedData.cs`, `.TstInfo.cs`, `.TstInfo.OptionalFields.cs`) -- decodes timestamp tokens including TSTInfo, signed data, and certificates.
|
||||
- **Token Verifier**: `src/Authority/__Libraries/StellaOps.Authority.Timestamping/TimeStampTokenVerifier.cs` (with partials `.CertificateChain.cs`, `.Signature.cs`, `.Validation.cs`, `.Warnings.cs`) -- full verification of timestamp tokens: signature, certificate chain, trust anchors, policy, and nonce checks.
|
||||
- **Provider Registry**: `src/Authority/__Libraries/StellaOps.Authority.Timestamping/TsaProviderRegistry.cs` (with partials `.HealthCheck.cs`, `.ProviderState.cs`, `.Providers.cs`, `.Reporting.cs`, `.Stats.cs`) -- manages multiple TSA providers with health monitoring, automatic failover, and statistics tracking.
|
||||
- **Response Caching**: `src/Authority/__Libraries/StellaOps.Authority.Timestamping/Caching/InMemoryTsaCacheStore.cs` (with `.Helpers.cs`), `ITsaCacheStore.cs` -- caches TSA responses to reduce provider load.
|
||||
- **Abstractions**: `src/Authority/__Libraries/StellaOps.Authority.Timestamping.Abstractions/` -- complete contract surface: `ITimeStampAuthorityClient.cs`, `TimeStampRequest.cs` (with `.Factory.cs`), `TimeStampResponse.cs`, `TimeStampToken.cs`, `TstInfo.cs`, `TstAccuracy.cs`, `TimeStampVerificationOptions.cs`, `TimeStampVerificationResult.cs`, `TsaClientOptions.cs`, `TsaProviderOptions.cs`, `FailoverStrategy.cs`, `PkiStatus.cs`, `PkiFailureInfo.cs`, verification error/warning enums.
|
||||
- **DI Extensions**: `src/Authority/__Libraries/StellaOps.Authority.Timestamping/TimestampingServiceCollectionExtensions.cs` (with `.CommonProviders.cs`, `.Provider.cs`) -- registers TSA client and providers in DI.
|
||||
- **Tests**: `src/Authority/__Tests/StellaOps.Authority.Timestamping.Tests/TimeStampReqEncoderTests.cs`, `TimeStampRespDecoderTests.cs`, `TimeStampTokenVerifierTests.cs`, `TsaProviderRegistryTests.cs`, `InMemoryTsaCacheStoreTests.cs`; `src/Authority/__Tests/StellaOps.Authority.Timestamping.Abstractions.Tests/` -- 9 test files covering requests, responses, tokens, options, TstInfo, TstAccuracy.
|
||||
|
||||
## What's Missing
|
||||
- **CI/CD pipeline integration hooks**: No dedicated middleware or service that automatically timestamps CI/CD build artifacts (e.g., SBOM, attestation, build log) as part of a pipeline step. The TSA client exists but is not wired into an automated CI/CD timestamping flow.
|
||||
- **Timestamped artifact registry**: No storage for mapping artifact digests to their timestamp tokens, enabling lookup of "when was this artifact timestamped?" across the platform.
|
||||
- **Pipeline-scoped timestamp policies**: No configuration for per-pipeline or per-environment timestamp requirements (e.g., "production releases require dual-provider timestamps").
|
||||
- **Timestamp receipt in release evidence**: The release orchestrator does not include timestamp receipts as evidence in the release decision chain.
|
||||
- **eIDAS/qualified TSA compliance checks**: While an eIDAS plugin exists in Cryptography, there is no validation that a timestamp meets qualified timestamp requirements per eIDAS Article 42.
|
||||
|
||||
## Implementation Plan
|
||||
- Create a `CiCdTimestampingService` that integrates with the Orchestrator/TaskRunner to automatically timestamp build artifacts
|
||||
- Add a timestamp artifact registry in the Evidence Locker for storing and querying artifact-to-timestamp mappings
|
||||
- Add pipeline-scoped timestamp policy configuration in the Policy module
|
||||
- Integrate timestamp receipts into the Release Orchestrator's evidence chain
|
||||
- Add eIDAS qualified timestamp compliance validation for regulated deployments
|
||||
- Add E2E tests for the CI/CD timestamping flow end-to-end
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
@@ -0,0 +1,34 @@
|
||||
# Vendor comparison / scanner parity tracking
|
||||
|
||||
## Module
|
||||
Bench
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Scanner analyzer benchmarks and golden-set diff comparisons exist, but a dedicated vendor-comparison dashboard or automated parity scoring system as described in the advisory is not visible.
|
||||
|
||||
## What's Implemented
|
||||
- **Scanner Analyzers Benchmark**: `src/Bench/StellaOps.Bench/Scanner.Analyzers/StellaOps.Bench.ScannerAnalyzers/` -- benchmark harness that evaluates scanner analyzers against ground-truth datasets, computing precision, recall, and F1 metrics per scanner.
|
||||
- **Baseline Loader**: `src/Bench/StellaOps.Bench/Scanner.Analyzers/StellaOps.Bench.ScannerAnalyzers/Baseline/BaselineLoader.cs` -- loads ground-truth baseline data for benchmark comparison, enabling diff detection between scanner runs.
|
||||
- **Baseline Entry**: `src/Bench/StellaOps.Bench/Scanner.Analyzers/StellaOps.Bench.ScannerAnalyzers/Baseline/BaselineEntry.cs` -- data model for a single baseline entry with expected findings, labels, and metadata.
|
||||
- **Benchmark Scenario Report**: `src/Bench/StellaOps.Bench/Scanner.Analyzers/StellaOps.Bench.ScannerAnalyzers/Reporting/BenchmarkScenarioReport.cs` -- produces per-scenario benchmark reports with precision/recall/F1 breakdowns.
|
||||
- **Benchmark JSON Writer**: `src/Bench/StellaOps.Bench/Scanner.Analyzers/StellaOps.Bench.ScannerAnalyzers/Reporting/BenchmarkJsonWriter.cs` -- serializes benchmark results to JSON for CI consumption and historical tracking.
|
||||
- **Prometheus Writer**: `src/Bench/StellaOps.Bench/Scanner.Analyzers/StellaOps.Bench.ScannerAnalyzers/Reporting/PrometheusWriter.cs` -- exports benchmark metrics to Prometheus format for dashboard visualization.
|
||||
|
||||
## What's Missing
|
||||
- **Vendor Comparison Dashboard**: No dedicated UI or API endpoint exists for side-by-side vendor scanner comparison. Current benchmarks evaluate StellaOps scanners against ground truth, but do not compare against third-party vendor scanner outputs.
|
||||
- **Automated Parity Scoring**: No automated system computes a parity score between StellaOps scanner results and vendor scanner results (e.g., Snyk, Grype, Trivy) for the same input images.
|
||||
- **Vendor Result Ingestion**: No ingestion pipeline exists to import vendor scanner outputs (SARIF, JSON) as baseline comparisons alongside StellaOps results.
|
||||
- **Regression Tracking Dashboard**: While `PrometheusWriter` exports metrics, no pre-built Grafana dashboard or equivalent exists for tracking scanner parity over time.
|
||||
|
||||
## Implementation Plan
|
||||
- Add a vendor result ingestion pipeline that imports SARIF/JSON from third-party scanners and normalizes findings to a common schema
|
||||
- Extend `BenchmarkScenarioReport` to include vendor comparison columns (StellaOps vs. vendor findings, unique to each, overlap percentage)
|
||||
- Build an automated parity scoring system that computes agreement/disagreement rates between scanner outputs
|
||||
- Create a dashboard (Grafana or Web UI) for visualizing parity trends over time
|
||||
|
||||
## Related Documentation
|
||||
- Scanner benchmark infrastructure: `src/Bench/StellaOps.Bench/Scanner.Analyzers/`
|
||||
- Reachability benchmark datasets: `src/__Tests/__Benchmarks/reachability-benchmark/`
|
||||
@@ -0,0 +1,37 @@
|
||||
# Cross-Distro Golden Set for Backport Validation
|
||||
|
||||
## Module
|
||||
BinaryIndex
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Golden set infrastructure exists in BinaryIndex with analysis pipeline and API. The advisory's detailed curated test cases (OpenSSL Heartbleed, sudo Baron Samedit, etc.) and specific database schema may not be fully populated yet.
|
||||
|
||||
## What's Implemented
|
||||
- **Golden Set Infrastructure**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.GoldenSet/` - full authoring, validation, storage, serialization
|
||||
- `GoldenSetExtractor`, `NvdGoldenSetExtractor` - extraction from NVD data
|
||||
- `GoldenSetEnrichmentService` - enriches golden sets with function hints
|
||||
- `GoldenSetValidator`, `ICveValidator` - validation pipeline
|
||||
- `PostgresGoldenSetStore` - PostgreSQL storage
|
||||
- `GoldenSetYamlSerializer` - YAML serialization
|
||||
- **Analysis Pipeline**: `GoldenSetAnalysisPipeline` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Analysis/`) - runs analysis against golden set definitions
|
||||
- **API Controller**: `GoldenSetController` (`src/BinaryIndex/StellaOps.BinaryIndex.WebService/Controllers/`) - CRUD and listing endpoints
|
||||
- **Corpus Connectors**: Alpine (`AlpineCorpusConnector`), Debian (`DebianCorpusConnector`), RPM (`RpmCorpusConnector`) for cross-distro support
|
||||
- **Validation Harness**: `ValidationHarness` and `ValidationHarnessService` for running golden set tests
|
||||
|
||||
## What's Missing
|
||||
- Curated cross-distro test cases for high-impact CVEs (OpenSSL Heartbleed CVE-2014-0160, sudo Baron Samedit CVE-2021-3156, etc.) may not be fully populated in the golden set database
|
||||
- Cross-distro coverage matrix (Alpine vs Debian vs RHEL backport variations for same CVE) may need population
|
||||
- Automated golden set population pipeline from NVD for new CVEs
|
||||
|
||||
## Implementation Plan
|
||||
- Populate golden set database with curated cross-distro test cases for high-impact CVEs
|
||||
- Validate backport detection accuracy across Alpine, Debian, and RHEL for each curated CVE
|
||||
- Build automated pipeline to generate cross-distro golden set entries from NVD advisories
|
||||
- Add cross-distro regression test suite using existing `ValidationHarness` infrastructure
|
||||
|
||||
## Related Documentation
|
||||
- Golden set schema: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.GoldenSet/Models/GoldenSetDefinition.cs`
|
||||
- Authoring workflow: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.GoldenSet/Authoring/`
|
||||
@@ -0,0 +1,41 @@
|
||||
# ELF Normalization and Delta Hashing
|
||||
|
||||
## Module
|
||||
BinaryIndex
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Low-entropy delta signatures over ELF segments with normalization (relocation zeroing, NOP canonicalization, jump table rewriting). Not yet implemented.
|
||||
|
||||
## What's Implemented
|
||||
- **Delta Signature Infrastructure**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/` - function-level delta signatures with V1 and V2 predicates exist
|
||||
- `DeltaSignatureGenerator` - generates delta signatures (function-level, not ELF-segment-level)
|
||||
- `DeltaSignatureMatcher` - matches delta signatures
|
||||
- `CfgExtractor` - extracts control flow graphs
|
||||
- `IrDiffGenerator` - IR-level diff generation
|
||||
- **Binary Diff Engine**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Diff/PatchDiffEngine.cs` - byte-level and function-level diffing
|
||||
- **ELF Feature Extraction**: `ElfFeatureExtractor` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Services/`) - extracts Build-ID and section info from ELF binaries
|
||||
- **Disassembly**: `B2R2DisassemblyPlugin`, `HybridDisassemblyService` - multi-backend disassembly infrastructure
|
||||
|
||||
## What's Missing
|
||||
- ELF segment-level normalization (relocation zeroing to eliminate position-dependent bytes)
|
||||
- NOP canonicalization (normalizing NOP sled variations across compilers)
|
||||
- Jump table rewriting (normalizing indirect jump table entries)
|
||||
- Low-entropy delta hashing over normalized ELF segments (currently delta-sig operates at function level, not segment level)
|
||||
- Segment-aware normalization that handles .text, .rodata, .data sections separately
|
||||
|
||||
## Implementation Plan
|
||||
- Add ELF segment normalization pass to `ElfFeatureExtractor` or new `ElfNormalizer` class
|
||||
- Implement relocation zeroing: identify and zero-out position-dependent bytes (GOT/PLT entries, absolute addresses)
|
||||
- Implement NOP canonicalization: normalize all NOP variants to canonical form
|
||||
- Implement jump table rewriting: normalize indirect jump table entries
|
||||
- Add segment-level delta hashing on normalized output
|
||||
- Integrate with existing `DeltaSignatureGenerator` for hybrid function+segment signatures
|
||||
- Add tests using known ELF binaries with position-dependent variations
|
||||
|
||||
## Related Documentation
|
||||
- Current delta-sig: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/`
|
||||
- ELF extraction: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Services/ElfFeatureExtractor.cs`
|
||||
- Disassembly: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Disassembly.B2R2/`
|
||||
37
docs/features/unchecked/cli/baseline-selection-logic.md
Normal file
37
docs/features/unchecked/cli/baseline-selection-logic.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Baseline Selection Logic (Last Green / Previous Release)
|
||||
|
||||
## Module
|
||||
Cli
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Compare feature infrastructure exists with services and CLI builder. The specific baseline selection logic (last green verdict, previous release tag) and its visibility to users may be partially implemented.
|
||||
|
||||
## What's Implemented
|
||||
- **Compare Command Builder**: `src/Cli/StellaOps.Cli/Commands/Compare/CompareCommandBuilder.cs` -- `CompareCommandBuilder` (internal static class)
|
||||
- Sprint: SPRINT_4200_0002_0004_cli_compare
|
||||
- Implements `stella compare --base <digest> --target <digest>` with options: `--output table|json|sarif`, `--output-file <path>`, `--include-unchanged`
|
||||
- Requires explicit `--base` and `--target` digest arguments (manual selection)
|
||||
- **Delta Scan**: `src/Cli/StellaOps.Cli/Commands/Scan/DeltaScanCommandGroup.cs` -- delta scan with baseline comparison
|
||||
- **VEX Gen Baseline**: `src/Cli/StellaOps.Cli/Commands/VexGenCommandGroup.cs` -- `--baseline <sealId>` option for facet drift baseline; defaults to latest seal for image
|
||||
- **Seal Store**: `IFacetSealStore.GetLatestSealAsync()` for retrieving most recent baseline
|
||||
|
||||
## What's Missing
|
||||
- **Automatic "last green" selection**: No command or flag like `--baseline last-green` that automatically selects the most recent scan digest with a passing verdict
|
||||
- **Previous release tag resolution**: No `--baseline previous-release` that resolves the previous release tag from SCM/registry metadata
|
||||
- **Baseline suggestion in output**: Compare results do not suggest a recommended baseline when none is specified
|
||||
- **UI baseline picker**: Web UI does not surface baseline selection with "last green" / "previous release" presets
|
||||
|
||||
## Implementation Plan
|
||||
- Add `--baseline-strategy last-green|previous-release|explicit` option to compare and delta-scan commands
|
||||
- Implement `IBaselineResolver` service with strategies for "last green verdict" (query verdict store for latest pass) and "previous release" (query registry for previous tag)
|
||||
- Wire baseline resolver into `CompareCommandBuilder` and `DeltaScanCommandGroup`
|
||||
- Add baseline suggestion panel to Web UI compare view
|
||||
- Add tests for each baseline strategy
|
||||
|
||||
## Related Documentation
|
||||
- Compare command: `src/Cli/StellaOps.Cli/Commands/Compare/CompareCommandBuilder.cs`
|
||||
- Delta scan: `src/Cli/StellaOps.Cli/Commands/Scan/DeltaScanCommandGroup.cs`
|
||||
- VEX gen baseline: `src/Cli/StellaOps.Cli/Commands/VexGenCommandGroup.cs`
|
||||
40
docs/features/unchecked/cli/cli-parity.md
Normal file
40
docs/features/unchecked/cli/cli-parity.md
Normal file
@@ -0,0 +1,40 @@
|
||||
# CLI Parity (stella advise)
|
||||
|
||||
## Module
|
||||
Cli
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
The CLI infrastructure is extensive but a dedicated `stella advise` command with `--evidence --no-action` flags as described is not explicitly found. However, the `stella advise ask` command does exist with these flags.
|
||||
|
||||
## What's Implemented
|
||||
- **Advise Chat Command Group**: `src/Cli/StellaOps.Cli/Commands/Advise/AdviseChatCommandGroup.cs` -- `AdviseChatCommandGroup` (internal static class)
|
||||
- Implements `stella advise ask <query>` with options:
|
||||
- `--image <ref>` / `--digest <digest>` / `--environment <env>` -- scope the advisory query
|
||||
- `--no-action` (`-n`) -- suppress proposed actions (read-only mode), default: true
|
||||
- `--evidence` -- include evidence links and citations in response
|
||||
- `--format table|json|markdown` -- output format
|
||||
- `--output <path>` -- write to file
|
||||
- `--conversation-id <id>` -- follow-up queries in same conversation
|
||||
- `--tenant <id>` -- tenant scoping
|
||||
- Chat rendering: `src/Cli/StellaOps.Cli/Commands/Advise/ChatRenderer.cs`
|
||||
- Services: `src/Cli/StellaOps.Cli/Services/Chat/` -- chat client services
|
||||
- **Chat sub-commands**: `chat-doctor` and `chat-settings` subcommands also registered
|
||||
|
||||
## What's Missing
|
||||
- **Full parity check**: Need to verify all advisory operations available in Web UI are also exposed through CLI
|
||||
- **Batch advisory queries**: No `--batch` or `--file` option for processing multiple queries from a file
|
||||
- **Advisory export**: No dedicated `stella advise export` for exporting advisory conversation history
|
||||
- **Advisory templates**: No `--template` option for pre-defined query templates
|
||||
|
||||
## Implementation Plan
|
||||
- Audit Web UI advisory features against CLI surface for parity gaps
|
||||
- Add batch query support via `--file <queries.jsonl>` option
|
||||
- Add conversation export command `stella advise export --conversation-id <id>`
|
||||
- Add template support if Web UI has pre-built query templates
|
||||
|
||||
## Related Documentation
|
||||
- Advise chat commands: `src/Cli/StellaOps.Cli/Commands/Advise/AdviseChatCommandGroup.cs`
|
||||
- Chat services: `src/Cli/StellaOps.Cli/Services/Chat/`
|
||||
@@ -0,0 +1,38 @@
|
||||
# Determinism Hash / Signature Verification in UI
|
||||
|
||||
## Module
|
||||
Cli
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Proofs and proof-studio UI features exist for browsing proof artifacts. Bundle verification exists in CLI. Full inline determinism hash and signature verification status display in the compare view may be partially wired up.
|
||||
|
||||
## What's Implemented
|
||||
- **Bundle Verification CLI**: `src/Cli/StellaOps.Cli/Commands/BundleVerifyCommand.cs` -- `BundleVerifyCommand` (static class)
|
||||
- Sprint: SPRINT_20260118_018_AirGap_router_integration (TASK-018-003)
|
||||
- Implements `stella bundle verify --bundle <path> [--trust-root <pem>] [--rekor-checkpoint <path>]`
|
||||
- Full cryptographic verification: checksums, DSSE signatures, Rekor proofs
|
||||
- Uses `StellaOps.Attestor.Core.Signing`, `StellaOps.Cryptography`
|
||||
- **Compare Command**: `src/Cli/StellaOps.Cli/Commands/Compare/CompareCommandBuilder.cs` -- compare with `--base` and `--target` digests
|
||||
- **Verdict Verification**: `src/Cli/StellaOps.Cli/Commands/VerdictCommandGroup.cs` -- `stella verdict verify <ref>` with `--sbom-digest`, `--feeds-digest`, `--policy-digest`, `--decision` verification
|
||||
- **Proof Command Group**: `src/Cli/StellaOps.Cli/Commands/Proof/ProofCommandGroup.cs` -- proof browsing and verification
|
||||
|
||||
## What's Missing
|
||||
- **Inline verification status in compare view**: The Web UI compare view does not display per-artifact hash verification status alongside diff results
|
||||
- **Signature verification badges in UI**: No visual badge/icon showing DSSE signature verification pass/fail for each evidence artifact in the proof studio
|
||||
- **Live re-verification**: No "re-verify now" button in UI that triggers determinism hash recomputation against stored evidence
|
||||
- **Determinism score integration**: CLI `stella determinism score` report not linked to compare view
|
||||
|
||||
## Implementation Plan
|
||||
- Add verification status column to Web UI compare view showing per-artifact hash match status
|
||||
- Add DSSE signature verification badge component to proof-studio evidence browser
|
||||
- Wire `BundleVerifyCommand` logic as a service callable from Web UI API
|
||||
- Add "verify" action button in proof-studio that triggers re-verification and displays results inline
|
||||
- Integrate determinism score into compare view header
|
||||
|
||||
## Related Documentation
|
||||
- Bundle verification: `src/Cli/StellaOps.Cli/Commands/BundleVerifyCommand.cs`
|
||||
- Verdict verification: `src/Cli/StellaOps.Cli/Commands/VerdictCommandGroup.cs`
|
||||
- Compare: `src/Cli/StellaOps.Cli/Commands/Compare/CompareCommandBuilder.cs`
|
||||
@@ -0,0 +1,43 @@
|
||||
# OCI Referrers for Evidence Storage (StellaBundle)
|
||||
|
||||
## Module
|
||||
Cli
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Bundle export, verification, and CLI commands exist. The pattern for storing evidence as OCI referrers is partially implemented through the bundle system and verifier module.
|
||||
|
||||
## What's Implemented
|
||||
- **Bundle Export**: `src/Cli/StellaOps.Cli/Commands/BundleExportCommand.cs` -- `BundleExportCommand` (static class)
|
||||
- Sprint: SPRINT_20260118_018_AirGap_router_integration (TASK-018-002)
|
||||
- Implements `stella evidence export-bundle --image <ref> [--output <path>] [--include-dsse] [--include-rekor-proof]`
|
||||
- Produces advisory-compliant bundles with DSSE envelopes, Rekor proofs, and OCI referrer metadata
|
||||
- **Bundle Verification**: `src/Cli/StellaOps.Cli/Commands/BundleVerifyCommand.cs` -- `BundleVerifyCommand` (static class)
|
||||
- Sprint: SPRINT_20260118_018_AirGap_router_integration (TASK-018-003)
|
||||
- Implements `stella bundle verify --bundle <path> [--trust-root <pem>] [--rekor-checkpoint <path>]`
|
||||
- Full offline cryptographic verification chain
|
||||
- **Bundle Command Group**: `src/Cli/StellaOps.Cli/Commands/BundleCommandGroup.cs` -- additional bundle operations
|
||||
- **Evidence Command Group**: `src/Cli/StellaOps.Cli/Commands/EvidenceCommandGroup.cs` -- evidence management commands
|
||||
- **Checkpoint Commands**: `src/Cli/StellaOps.Cli/Commands/CheckpointCommands.cs` -- checkpoint operations for bundle management
|
||||
- **Verifier Module**: `src/Verifier/` -- evidence verification backend
|
||||
|
||||
## What's Missing
|
||||
- **OCI Referrers API integration**: No direct `oras` or OCI Distribution API client for pushing/pulling evidence as OCI referrers (artifacts are stored as bundles, not native OCI referrers)
|
||||
- **`stella evidence push-referrer`**: No command to push evidence artifacts as OCI referrers to a registry using the OCI Referrers API
|
||||
- **`stella evidence list-referrers`**: No command to list all referrers attached to an OCI artifact digest
|
||||
- **Referrer discovery**: No automated discovery of evidence referrers when running verify commands against a registry
|
||||
- **ORAS integration**: No integration with ORAS library for native OCI artifact handling
|
||||
|
||||
## Implementation Plan
|
||||
- Add OCI Distribution client with Referrers API support (v2 manifest list)
|
||||
- Implement `stella evidence push-referrer --image <ref> --artifact-type <type> --file <path>` for pushing evidence as OCI referrers
|
||||
- Implement `stella evidence list-referrers <ref>` for listing attached referrers by artifact type
|
||||
- Add `--use-referrers` flag to `stella verify image` to auto-discover evidence from registry referrers
|
||||
- Integrate with existing bundle export to optionally push as OCI referrers instead of tar.gz
|
||||
|
||||
## Related Documentation
|
||||
- Bundle export: `src/Cli/StellaOps.Cli/Commands/BundleExportCommand.cs`
|
||||
- Bundle verify: `src/Cli/StellaOps.Cli/Commands/BundleVerifyCommand.cs`
|
||||
- Evidence commands: `src/Cli/StellaOps.Cli/Commands/EvidenceCommandGroup.cs`
|
||||
40
docs/features/unchecked/cli/unknowns-export-artifacts.md
Normal file
40
docs/features/unchecked/cli/unknowns-export-artifacts.md
Normal file
@@ -0,0 +1,40 @@
|
||||
# Unknowns Export Artifacts
|
||||
|
||||
## Module
|
||||
Cli
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Backend unknowns ranking and proof emission services exist along with CLI command group. However, explicit export schema artifacts for reproducible offline export of unknowns data were not located as standalone schema documents.
|
||||
|
||||
## What's Implemented
|
||||
- **Unknowns Command Group**: `src/Cli/StellaOps.Cli/Commands/UnknownsCommandGroup.cs` -- `UnknownsCommandGroup` (static class)
|
||||
- Sprint: SPRINT_3500_0004_0001_cli_verbs, SPRINT_5100_0004_0001_unknowns_budget_ci_gates, SPRINT_20260112_010_CLI_unknowns_grey_queue_cli
|
||||
- Implements: `stella unknowns list`, `escalate`, `resolve`, `budget check/status`, `summary`, `show`, `proof`, `export`, `triage`
|
||||
- Uses `StellaOps.Policy.Unknowns.Models` for DTOs
|
||||
- **Export Command**: `stella unknowns export` exists within the command group (BuildExportCommand)
|
||||
- **Proof Command**: `stella unknowns proof` for proof emission of unknowns data
|
||||
- **Budget Operations**: `stella unknowns budget check --scan-id <id>` and `stella unknowns budget status` for CI gate budget enforcement
|
||||
- **Backend**: `src/Unknowns/` -- unknowns registry and ranking services
|
||||
- **Policy Integration**: `src/Policy/__Libraries/StellaOps.Policy.Unknowns/` -- unknowns models and policy integration
|
||||
|
||||
## What's Missing
|
||||
- **Export schema document**: No standalone JSON Schema or specification document for the unknowns export format
|
||||
- **Deterministic export format**: Export output format not formally specified for reproducible offline comparison
|
||||
- **Export versioning**: No schema version header in exported data for forward compatibility
|
||||
- **Offline import**: No `stella unknowns import` command for ingesting previously exported unknowns data in air-gapped environments
|
||||
- **Export attestation**: Exported unknowns data not wrapped in a DSSE envelope for tamper evidence
|
||||
|
||||
## Implementation Plan
|
||||
- Define formal JSON Schema for unknowns export format with version field
|
||||
- Add `--schema-version` and `--format` options to `stella unknowns export`
|
||||
- Add DSSE signing to export output via `--sign` flag
|
||||
- Implement `stella unknowns import <file>` for air-gapped unknowns ingestion
|
||||
- Publish export schema as part of the API specification
|
||||
|
||||
## Related Documentation
|
||||
- Unknowns CLI: `src/Cli/StellaOps.Cli/Commands/UnknownsCommandGroup.cs`
|
||||
- Unknowns backend: `src/Unknowns/`
|
||||
- Policy unknowns library: `src/Policy/__Libraries/StellaOps.Policy.Unknowns/`
|
||||
@@ -0,0 +1,32 @@
|
||||
# Astra Linux OVAL Feed Connector
|
||||
|
||||
## Module
|
||||
Concelier
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Advisory feed connector for Astra Linux (Russian certified distro) implementing IFeedConnector interface. Includes OVAL XML feed research, plugin scaffold, AstraOptions configuration, and trust defaults. Reuses DebianVersionComparer for version comparison. OVAL XML parser is partially implemented.
|
||||
|
||||
## What's Implemented
|
||||
- **Connector Plugin**: `AstraConnectorPlugin` (`src/Concelier/__Connectors/StellaOps.Concelier.Connector.Astra/AstraConnectorPlugin.cs`) - `IConnectorPlugin` registration with DI
|
||||
- **Connector**: `AstraConnector` (`src/Concelier/__Connectors/StellaOps.Concelier.Connector.Astra/AstraConnector.cs`) - `IFeedConnector` implementation scaffold
|
||||
- **Documentation**: `IMPLEMENTATION_NOTES.md` and `README.md` in the connector directory
|
||||
|
||||
## What's Missing
|
||||
- Full OVAL XML parser for Astra Linux specific advisory format
|
||||
- Version comparison integration with DebianVersionComparer for Astra-specific version strings
|
||||
- Test coverage with sample Astra Linux OVAL feeds
|
||||
- Trust level calibration for Astra Linux as an advisory source
|
||||
|
||||
## Implementation Plan
|
||||
- Complete the OVAL XML parser to handle Astra Linux specific OVAL definitions
|
||||
- Integrate DebianVersionComparer for version range matching
|
||||
- Add unit tests with sample Astra OVAL XML feeds
|
||||
- Calibrate trust defaults based on Astra Linux advisory source quality
|
||||
- Add integration test with `ConnectorRegistrationService` for plugin discovery
|
||||
|
||||
## Related Documentation
|
||||
- Source: SPRINT_20251229_005_CONCEL_astra_connector.md
|
||||
- Implementation notes: `src/Concelier/__Connectors/StellaOps.Concelier.Connector.Astra/IMPLEMENTATION_NOTES.md`
|
||||
@@ -0,0 +1,33 @@
|
||||
# Feed Snapshot Coordinator
|
||||
|
||||
## Module
|
||||
Concelier
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Feed snapshot persistence and retrieval exists (repository, entity model). However, the advisory notes this as TODO (Feed Snapshot Coordinator for cross-platform pinning/coordination is still in progress).
|
||||
|
||||
## What's Implemented
|
||||
- **Persistence**: `FeedSnapshotRepository` (`src/Concelier/__Libraries/StellaOps.Concelier.Persistence/Postgres/Repositories/FeedSnapshotRepository.cs`) - PostgreSQL repository for feed snapshot storage and retrieval
|
||||
- **Entity Model**: `FeedSnapshotEntity` (`src/Concelier/__Libraries/StellaOps.Concelier.Persistence/Postgres/Models/FeedSnapshotEntity.cs`) - database entity for feed snapshots
|
||||
- **API Endpoints**: `FeedSnapshotEndpointExtensions` (`src/Concelier/StellaOps.Concelier.WebService/Extensions/FeedSnapshotEndpointExtensions.cs`) - REST endpoints for snapshot queries
|
||||
- **Options**: `FeedSnapshotOptions` (`src/Concelier/StellaOps.Concelier.WebService/Options/ConcelierOptions.cs`) - configuration for snapshot behavior
|
||||
|
||||
## What's Missing
|
||||
- Feed Snapshot Coordinator service that coordinates cross-platform feed pinning
|
||||
- Snapshot version pinning across multiple Concelier instances (for consistency in federated deployments)
|
||||
- Automatic snapshot rollback on ingestion failure
|
||||
- Snapshot comparison and diff reporting
|
||||
|
||||
## Implementation Plan
|
||||
- Create `FeedSnapshotCoordinator` service in `src/Concelier/__Libraries/StellaOps.Concelier.Core/` or `Federation/`
|
||||
- Implement cross-instance snapshot pinning using the `SyncLedgerRepository` for coordination
|
||||
- Add automatic rollback on ingestion failure to return to last-known-good snapshot
|
||||
- Add snapshot diff reporting for audit and troubleshooting
|
||||
- Add tests for coordinator logic with multi-instance scenarios
|
||||
|
||||
## Related Documentation
|
||||
- Persistence: `src/Concelier/__Libraries/StellaOps.Concelier.Persistence/Postgres/Repositories/FeedSnapshotRepository.cs`
|
||||
- API: `src/Concelier/StellaOps.Concelier.WebService/Extensions/FeedSnapshotEndpointExtensions.cs`
|
||||
@@ -0,0 +1,33 @@
|
||||
# CLI/UI Surfacing of Hidden Backend Capabilities
|
||||
|
||||
## Module
|
||||
ExportCenter
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
The advisory itself identifies this as a gap - backend capabilities are rich but CLI/UI coverage needs surfacing work. This is a meta-advisory about exposing existing features.
|
||||
|
||||
## What's Implemented
|
||||
- **Backend export API**: `src/ExportCenter/StellaOps.ExportCenter/StellaOps.ExportCenter.WebService/Api/ExportApiEndpoints.cs` -- full REST API for export operations
|
||||
- **SDK client**: `src/ExportCenter/StellaOps.ExportCenter/StellaOps.ExportCenter.Client/ExportCenterClient.cs`, `IExportCenterClient.cs` -- programmatic access to export capabilities
|
||||
- **Client lifecycle helper**: `src/ExportCenter/StellaOps.ExportCenter/StellaOps.ExportCenter.Client/Lifecycle/ExportJobLifecycleHelper.cs`
|
||||
- **Risk bundle builder**: `src/ExportCenter/StellaOps.ExportCenter.RiskBundles/RiskBundleBuilder.cs`
|
||||
- **OCI distribution**: full OCI referrer and distribution stack under `Distribution/Oci/`
|
||||
- **Evidence cache**: `src/ExportCenter/StellaOps.ExportCenter/StellaOps.ExportCenter.Core/EvidenceCache/`
|
||||
- **Simulation export**: `src/ExportCenter/StellaOps.ExportCenter/StellaOps.ExportCenter.WebService/SimulationExport/SimulationReportExporter.cs`
|
||||
- Source: Feature matrix scan
|
||||
|
||||
## What's Missing
|
||||
- CLI commands for export operations (risk bundles, OCI distribution, evidence cache management)
|
||||
- Web UI pages/components for triggering and managing exports
|
||||
- User-facing export wizard or dashboard surfacing available export types
|
||||
|
||||
## Implementation Plan
|
||||
- Add CLI commands wrapping ExportCenter SDK client operations
|
||||
- Build Web UI components for export management (list exports, trigger new exports, download artifacts)
|
||||
- Surface OCI referrer discovery results in UI for attestation browsing
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
@@ -0,0 +1,37 @@
|
||||
# Router Back-Pressure Middleware (Dual-Window Rate Limiting + Circuit Breaker)
|
||||
|
||||
## Module
|
||||
Gateway
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Rate limiting is present in the Gateway and Graph API services. The advisory's highly detailed dual-window rate limiter with Redis/Valkey-backed environment limiter, ring counter, and custom circuit breaker pattern is not implemented as described. Standard ASP.NET rate limiting is used instead.
|
||||
|
||||
## What's Implemented
|
||||
- Gateway middleware pipeline with request routing: `src/Gateway/StellaOps.Gateway.WebService/Middleware/RequestRoutingMiddleware.cs`
|
||||
- Sender constraint middleware: `src/Gateway/StellaOps.Gateway.WebService/Middleware/SenderConstraintMiddleware.cs`
|
||||
- Gateway options with configurable limits: `src/Gateway/StellaOps.Gateway.WebService/Configuration/GatewayOptions.cs`
|
||||
- Gateway metrics: `src/Gateway/StellaOps.Gateway.WebService/Services/GatewayMetrics.cs`
|
||||
- Standard ASP.NET rate limiting via middleware pipeline
|
||||
- **Router module has advanced rate limiting** (separate from Gateway):
|
||||
- `src/Router/__Libraries/StellaOps.Router.Gateway/RateLimit/EnvironmentRateLimiter.cs` -- Valkey-backed environment rate limiter with circuit breaker
|
||||
- `src/Router/__Libraries/StellaOps.Router.Gateway/RateLimit/InstanceRateLimiter.cs` -- per-instance rate limiting
|
||||
- `src/Router/__Libraries/StellaOps.Router.Gateway/RateLimit/RateLimitService.cs` -- rate limit service orchestrator
|
||||
- `src/Router/__Libraries/StellaOps.Messaging.Transport.Valkey/ValkeyRateLimiter.cs` -- Valkey-backed distributed rate limiter
|
||||
- Source: Feature matrix scan
|
||||
|
||||
## What's Missing
|
||||
- **Gateway integration with Router rate limiting**: The Router module has Valkey-backed rate limiting and circuit breaker, but the Gateway module does not consume these services. The Gateway still uses standard ASP.NET rate limiting.
|
||||
- Dual-window rate limiter with sliding window algorithm in the Gateway
|
||||
- Ring counter implementation for rate tracking in the Gateway
|
||||
- Unified rate limit configuration across Gateway and Router modules
|
||||
|
||||
## Implementation Plan
|
||||
- Evaluate whether standard ASP.NET rate limiting is sufficient for current scale
|
||||
- If needed, implement Redis/Valkey-backed rate limiting for distributed deployment
|
||||
- Add circuit breaker pattern for downstream service protection
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
@@ -0,0 +1,30 @@
|
||||
# StellaRouter Performance Testing Pipeline (k6 + Prometheus + Correlation IDs)
|
||||
|
||||
## Module
|
||||
Gateway
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
The StellaRouter gateway service exists but the advisory's proposed k6 performance testing scenarios (A-G), correlation ID instrumentation, and Prometheus metric dashboards for performance curve modeling are not present as source code artifacts. These may exist as devops artifacts outside src/.
|
||||
|
||||
## What's Implemented
|
||||
- Gateway service with full middleware pipeline: `src/Gateway/StellaOps.Gateway.WebService/`
|
||||
- Correlation ID middleware: `src/Gateway/StellaOps.Gateway.WebService/Middleware/CorrelationIdMiddleware.cs`
|
||||
- Gateway metrics: `src/Gateway/StellaOps.Gateway.WebService/Services/GatewayMetrics.cs` -- Prometheus-compatible metrics
|
||||
- Health monitoring: `src/Gateway/StellaOps.Gateway.WebService/Services/GatewayHealthMonitorService.cs`
|
||||
- Source: Feature matrix scan
|
||||
|
||||
## What's Missing
|
||||
- k6 performance testing scripts (scenarios A-G)
|
||||
- Prometheus metric dashboards for performance curve modeling
|
||||
- These may exist under `devops/` rather than `src/` -- check `devops/` directory
|
||||
|
||||
## Implementation Plan
|
||||
- Create k6 test scripts for Gateway performance scenarios
|
||||
- Add Grafana/Prometheus dashboards for Gateway metrics visualization
|
||||
- These are DevOps artifacts and may belong under `devops/perf/` or similar
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
@@ -0,0 +1,35 @@
|
||||
# Graph Edge Metadata with Reason/Evidence/Provenance
|
||||
|
||||
## Module
|
||||
Graph
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
EdgeReason and CallgraphEdge models exist in Signals with persistence projection, and EdgeBundle exists in Scanner reachability. However, the Graph module itself (src/Graph) does not contain EdgeReason/EdgeVia/ExplanationPayload types -- the human-readable explanation layer described in the advisory is not present in the Graph API.
|
||||
|
||||
## What's Implemented
|
||||
- **Graph API services**: `src/Graph/StellaOps.Graph.Api/Services/` -- query, search, path, diff, export, lineage, overlay services (all with in-memory implementations)
|
||||
- **Graph snapshot documents**: `src/Graph/StellaOps.Graph.Indexer/Documents/GraphSnapshot.cs`, `GraphSnapshotBuilder.cs` -- graph document model (nodes/edges with metadata)
|
||||
- **Graph document factory**: `src/Graph/StellaOps.Graph.Indexer/Schema/GraphDocumentFactory.cs` -- creates graph documents with identity
|
||||
- **Graph identity**: `src/Graph/StellaOps.Graph.Indexer/Schema/GraphIdentity.cs` -- content-addressed graph identity
|
||||
- **CVE observation nodes**: `src/Graph/__Libraries/StellaOps.Graph.Core/CveObservationNode.cs` -- CVE observation data on graph nodes
|
||||
- **Advisory linkset**: `src/Graph/StellaOps.Graph.Indexer/Ingestion/Advisory/AdvisoryLinksetProcessor.cs`, `AdvisoryLinksetTransformer.cs` -- advisory evidence linking to graph edges
|
||||
- **Inspector**: `src/Graph/StellaOps.Graph.Indexer/Ingestion/Inspector/GraphInspectorProcessor.cs`, `GraphInspectorTransformer.cs` -- inspection evidence on edges
|
||||
- **Postgres persistence**: `src/Graph/__Libraries/StellaOps.Graph.Indexer.Persistence/Postgres/Repositories/PostgresGraphDocumentWriter.cs`, `PostgresGraphSnapshotProvider.cs`
|
||||
- Source: Feature matrix scan
|
||||
|
||||
## What's Missing
|
||||
- `EdgeReason`/`EdgeVia`/`ExplanationPayload` types in Graph API -- human-readable explanation layer for why edges exist
|
||||
- Edge provenance metadata linking back to source evidence (SBOM provenance, scan evidence, attestation references)
|
||||
- Graph API endpoints to query edge-level metadata (reason, evidence, provenance)
|
||||
|
||||
## Implementation Plan
|
||||
- Add `EdgeReason`, `EdgeVia`, and `ExplanationPayload` types to `src/Graph/StellaOps.Graph.Api/`
|
||||
- Expose edge metadata through graph query and path APIs
|
||||
- Link edge metadata to Signals `EdgeReason` and Scanner `EdgeBundle` models
|
||||
- Add tests for edge metadata query and provenance tracking
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
33
docs/features/unchecked/integrations/ai-code-guard.md
Normal file
33
docs/features/unchecked/integrations/ai-code-guard.md
Normal file
@@ -0,0 +1,33 @@
|
||||
# AI Code Guard (Secrets Scanning + Attribution Check + License Hygiene)
|
||||
|
||||
## Module
|
||||
Integrations
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
AI Code Guard has policy signal binding and annotation services. Evidence provider interfaces and annotation contracts exist. The advisory's proposed `stella guard run` CLI and full YAML-driven pipeline checks are partially represented through policy signal binding rather than a standalone CLI tool.
|
||||
|
||||
## What's Implemented
|
||||
- **AI Code Guard annotation contracts**: `src/Integrations/__Libraries/StellaOps.Integrations.Contracts/AiCodeGuardAnnotationContracts.cs` -- annotation DTOs for AI code guard findings
|
||||
- **AI Code Guard annotation service**: `src/Integrations/__Libraries/StellaOps.Integrations.Services/AiCodeGuard/AiCodeGuardAnnotationService.cs` -- annotation generation service
|
||||
- **Tests**: `src/Integrations/__Libraries/__Tests/StellaOps.Integrations.Services.Tests/AiCodeGuard/AiCodeGuardAnnotationServiceTests.cs`
|
||||
- Policy signal binding exists in `src/Policy/` for AI code guard policy evaluation
|
||||
- Source: Feature matrix scan
|
||||
|
||||
## What's Missing
|
||||
- `stella guard run` CLI command for standalone execution
|
||||
- YAML-driven pipeline check configuration
|
||||
- Full secrets scanning engine (currently annotation-only)
|
||||
- Attribution check automation
|
||||
- License hygiene scanning and enforcement
|
||||
|
||||
## Implementation Plan
|
||||
- Add CLI command wrapping AI Code Guard annotation service
|
||||
- Implement YAML-driven check configuration loader
|
||||
- Build secrets scanning and attribution check engines
|
||||
- Integrate license hygiene with SBOM/licensing data
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
26
docs/features/unchecked/libraries/advisory-lens.md
Normal file
26
docs/features/unchecked/libraries/advisory-lens.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Advisory Lens (Core Library and UI)
|
||||
|
||||
## Status
|
||||
NOT_FOUND
|
||||
|
||||
## Description
|
||||
Proposed contextual copilot that learns from organizational data to surface explainable suggestions. Includes:
|
||||
- **Core library**: Semantic case matching engine (`StellaOps.AdvisoryLens`)
|
||||
- **UI components**: "Top 3 Suggestions Today" Lens Panel, inline hints, playbook drawer with dry-run preview
|
||||
|
||||
Not yet created; sprint tasks all at TODO status.
|
||||
|
||||
## Why Not Implemented
|
||||
- No `StellaOps.AdvisoryLens` library found under `src/__Libraries/` or anywhere in `src/`
|
||||
- No dedicated "Lens Panel", "Top 3 Suggestions", inline hint system, or playbook drawer components found in `src/Web/`
|
||||
- The AdvisoryAI module (`src/AdvisoryAI/`) provides AI-powered explanation generation (evidence-anchored explanations, replay, prompt templates) but does not implement the "Advisory Lens" semantic case-matching copilot concept
|
||||
- The Web UI has AI components (`src/Web/StellaOps.Web/src/app/shared/components/ai/`) including Ask Stella and AI explanation chips, but these are a different UX pattern from the Advisory Lens concept
|
||||
- Likely deferred to a future phase; the AdvisoryAI module may serve as foundation for eventual Advisory Lens work
|
||||
|
||||
## Source
|
||||
- Feature matrix scan
|
||||
|
||||
## Notes
|
||||
- Module: __Libraries
|
||||
- Modules referenced: `(planned for src/__Libraries/StellaOps.AdvisoryLens, src/Web)`
|
||||
- Related existing code: `src/AdvisoryAI/` (explanation generation), `src/Web/.../shared/components/ai/` (AI chips, Ask Stella)
|
||||
@@ -0,0 +1,53 @@
|
||||
# Provcache: Signer-Aware Invalidation, Evidence Chunk Paging, and Air-Gap Export
|
||||
|
||||
## Module
|
||||
__Libraries (Provcache)
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Large multi-wave feature: evidence chunk storage (with SHA-256 per-chunk verification and ChunkManifest for lazy fetching), paged evidence API (GetChunkRangeAsync), minimal proof bundle export (lite/standard/strict density), signer-aware cache invalidation (InvalidationType.SignerSetHash), feed epoch invalidation (InvalidationType.FeedEpochOlderThan), lazy evidence fetch (HTTP + sneakernet), revocation ledger with replay service, and CLI commands (stella prov export/import). Most waves DONE, but messaging bus subscription tasks and CLI e2e tests are BLOCKED pending service integration.
|
||||
|
||||
## What's Implemented
|
||||
- **ProvcacheService**: `src/__Libraries/StellaOps.Provcache/ProvcacheService.cs` -- multi-partial: `.Get.cs` (lookup by VeriKey), `.GetOrCompute.cs` (read-through pattern), `.Set.cs` (store with TTL), `.Invalidate.cs`/`.InvalidateBy.cs` (targeted invalidation), `.Prune.cs` (expired entry cleanup), `.Metrics.cs` (telemetry), `.Tracking.cs` (usage tracking)
|
||||
- **InvalidationRequest**: `src/__Libraries/StellaOps.Provcache/InvalidationRequest.cs` -- record with `Type` (InvalidationType), `Value`, `Reason`, `Actor`; factory methods: `ByPolicyHash(hash)`, `BySignerSetHash(hash)`, `ByFeedEpochOlderThan(epoch)`, `ByPattern(pattern)`
|
||||
- **InvalidationType**: `src/__Libraries/StellaOps.Provcache/InvalidationType.cs` -- enum: `PolicyHash`, `SignerSetHash`, `FeedEpochOlderThan`, `Pattern`, `Expired`
|
||||
- **InvalidationResult**: `src/__Libraries/StellaOps.Provcache/InvalidationResult.cs` -- result of invalidation operation
|
||||
- **EvidenceChunk**: `src/__Libraries/StellaOps.Provcache/EvidenceChunk.cs` -- record: `ChunkId` (Guid), `ProofRoot` (string), `ChunkIndex` (int, zero-based), `ChunkHash` (SHA-256), `Blob` (byte[]), `BlobSize` (int), `ContentType` (MIME), `CreatedAt`
|
||||
- **ChunkManifest**: `src/__Libraries/StellaOps.Provcache/ChunkManifest.cs` -- record: `ProofRoot`, `TotalChunks`, `TotalSize` (long bytes), `Chunks` (IReadOnlyList<ChunkMetadata>), `GeneratedAt`; used for lazy fetching where blobs are retrieved on demand
|
||||
- **ChunkMetadata**: `src/__Libraries/StellaOps.Provcache/ChunkMetadata.cs` -- metadata-only chunk descriptor
|
||||
- **IEvidenceChunkRepository**: `src/__Libraries/StellaOps.Provcache/IEvidenceChunkRepository.cs` -- interface: `GetChunksAsync(proofRoot)`, `GetChunkAsync(proofRoot, chunkIndex)`, `GetChunkRangeAsync(proofRoot, startIndex, count)` (paged retrieval), `GetManifestAsync(proofRoot)`, `StoreChunksAsync(proofRoot, chunks)`, `DeleteChunksAsync(proofRoot)`, `GetChunkCountAsync`, `GetTotalSizeAsync`
|
||||
- **ValkeyProvcacheStore**: `src/__Libraries/StellaOps.Provcache.Valkey/ValkeyProvcacheStore.cs` -- multi-partial: `.Get.cs`, `.GetMany.cs`, `.GetOrSet.cs`, `.Set.cs`, `.SetMany.cs`, `.Invalidate.cs`, `.InvalidateByPattern.cs`
|
||||
- **PostgresProvcacheRepository**: `src/__Libraries/StellaOps.Provcache.Postgres/PostgresProvcacheRepository.cs` -- multi-partial: `.Read.cs`, `.Upsert.cs`, `.Delete.cs`, `.DeleteFeedExpired.cs`, `.DeletePolicySigner.cs`, `.Revocations.cs`, `.Metrics.cs`, `.Mapping.cs`
|
||||
- **PostgresEvidenceChunkRepository**: `src/__Libraries/StellaOps.Provcache.Postgres/PostgresEvidenceChunkRepository.cs` -- multi-partial: `.Get.cs`, `.Manifest.cs`, `.Mapping.cs`, `.Metrics.cs`, `.Range.cs`, `.Store.cs`
|
||||
- **RevocationLedger**: `src/__Libraries/StellaOps.Provcache/Revocation/` -- `IRevocationLedger` (RecordAsync, GetEntriesSinceAsync, GetEntriesByTypeAsync, GetLatestSeqNoAsync, GetRevocationsForKeyAsync, GetStatsAsync), `InMemoryRevocationLedger` (multi-partial: `.Query.cs`, `.Stats.cs`), `RevocationEntry` (SeqNo, RevocationId, RevocationType, RevokedKey, Reason, EntriesInvalidated, Source, CorrelationId, RevokedAt, Metadata)
|
||||
- **RevocationReplayService**: `src/__Libraries/StellaOps.Provcache/Revocation/RevocationReplayService.cs` -- multi-partial: `.Apply.cs`, `.Checkpoint.cs`, `.Process.cs`, `.Replay.cs`, `.Result.cs`, `.State.cs`
|
||||
- **WriteBehindQueue**: `src/__Libraries/StellaOps.Provcache/WriteBehindQueue.cs` -- multi-partial: `.Enqueue.cs`, `.Drain.cs`, `.Batch.cs`, `.Run.cs`, `.Metrics.cs`
|
||||
- **Attestation Models**: `src/__Libraries/StellaOps.Provcache/` -- `ProvcacheOciAttestationRequest.cs`, `ProvcacheOciAttestationResult.cs`, `ProvcachePredicate.cs`, `ProvcacheStatement.cs`, `ProvcacheSubject.cs` for OCI attestation integration
|
||||
- **Telemetry**: `src/__Libraries/StellaOps.Provcache/ProvcacheTelemetry.cs` -- multi-partial covering activities, counters, gauges, histograms, and metrics
|
||||
- **Provenance Attestation Core**: `src/Provenance/StellaOps.Provenance.Attestation/` -- full attestation library with build models, promotion attestation, signers, and verification pipeline
|
||||
|
||||
## What's Missing
|
||||
- **SignerRevokedEvent handler**: No event handler listening for signer revocation events and invalidating cached provenance records signed by the revoked key. The signer infrastructure and `InvalidationType.SignerSetHash` exist but the messaging bus fan-out is not wired.
|
||||
- **FeedEpochAdvancedEvent handler**: No event handler listening for feed epoch advancement and invalidating stale provenance cache entries referencing the previous epoch's advisory data.
|
||||
- **Cross-module event bus integration**: The event-driven fan-out requires integration with the broader event bus (likely via the Scheduler or Orchestrator) which is not yet connected.
|
||||
- **CLI e2e tests**: No e2e test coverage for `stella prov export/import` commands (BLOCKED pending CLI integration).
|
||||
- **Air-gap export bundle with DSSE signing**: Partial -- sneakernet transport bundle needs DSSE signing for integrity verification before import.
|
||||
|
||||
## Implementation Plan
|
||||
- Integrate messaging bus subscriptions for `SignerRevokedEvent` triggering `InvalidationRequest.BySignerSetHash()`
|
||||
- Integrate messaging bus subscriptions for `FeedEpochAdvancedEvent` triggering `InvalidationRequest.ByFeedEpochOlderThan()`
|
||||
- Complete air-gap export bundle with DSSE signing for offline transport
|
||||
- Implement CLI e2e test coverage for provenance export/import commands
|
||||
- Verify revocation replay service correctly re-applies invalidation events after restore
|
||||
|
||||
## Related Documentation
|
||||
- Source: SPRINT_8200_0001_0002_provcache_invalidation_airgap.md
|
||||
- Provenance attestation library: `src/Provenance/StellaOps.Provenance.Attestation/`
|
||||
- Signer module: `src/Signer/`
|
||||
- Attestor proof chain (Merkle infrastructure): `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Merkle/`
|
||||
|
||||
## Merged From
|
||||
- `libraries/provcache-invalidation-and-evidence-chunk-paging.md` (deleted)
|
||||
- `provenance/provcache-invalidation-with-signerrevokedevent-and-feedepochadvancedevent-fan-ou.md` (deleted)
|
||||
32
docs/features/unchecked/mirror/mirror-creator.md
Normal file
32
docs/features/unchecked/mirror/mirror-creator.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# Mirror Creator
|
||||
|
||||
## Module
|
||||
Mirror
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Mirror creator module exists as a separate directory but appears to have limited implementation compared to the comprehensive AirGap module.
|
||||
|
||||
## What's Implemented
|
||||
- **Module Directory**: `src/Mirror/` -- directory exists in the source tree, indicating the module was planned and scaffolded.
|
||||
- **Related AirGap Functionality**: The `src/AirGap/` module provides comprehensive offline/air-gap mirroring capabilities including feed mirroring, registry mirroring, and offline bundle creation that may overlap with the intended Mirror module scope.
|
||||
- **Golden Pairs Mirror Service**: `src/Tools/GoldenPairs/StellaOps.Tools.GoldenPairs/Services/PackageMirrorService.cs` -- provides package mirroring for golden pair validation, which demonstrates the mirroring pattern but is scoped to the testing toolchain.
|
||||
|
||||
## What's Missing
|
||||
- **Mirror Creator Service**: No core service implementation exists in `src/Mirror/` -- the directory is empty with no C# source files, project files, or service definitions.
|
||||
- **Mirror Configuration**: No configuration models or API endpoints for defining mirror sources, schedules, or target registries.
|
||||
- **Mirror Sync Engine**: No synchronization engine for incrementally mirroring container images, SBOMs, VEX documents, or advisory feeds from upstream sources to local storage.
|
||||
- **Mirror Status Tracking**: No status tracking or progress reporting for active mirror operations.
|
||||
- **Mirror Attestation**: No attestation generation for mirrored content to verify integrity after transfer.
|
||||
|
||||
## Implementation Plan
|
||||
- Determine whether the Mirror module should be a standalone service or merged into the existing AirGap module (which already provides substantial mirroring capabilities)
|
||||
- If standalone: implement core mirror service with source configuration, sync engine, progress tracking, and attestation
|
||||
- If merged: archive the `src/Mirror/` directory and update documentation to point to `src/AirGap/` for all mirroring functionality
|
||||
- Add integration tests with Testcontainers OCI registry for mirror sync verification
|
||||
|
||||
## Related Documentation
|
||||
- AirGap module (existing mirror capabilities): `src/AirGap/`
|
||||
- Golden Pairs mirror pattern: `src/Tools/GoldenPairs/StellaOps.Tools.GoldenPairs/Services/PackageMirrorService.cs`
|
||||
@@ -0,0 +1,42 @@
|
||||
# Quota Governance and Circuit Breakers
|
||||
|
||||
## Module
|
||||
Orchestrator
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Job scheduling exists but dedicated quota governance services and circuit breaker automation were not found as separate implementations. May be embedded in scheduler logic.
|
||||
|
||||
## What's Implemented
|
||||
- `Quota` (`src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.Core/Domain/Quota.cs`) - quota entity with limits and allocation
|
||||
- `QuotaEndpoints` (`src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.WebService/Endpoints/QuotaEndpoints.cs`) - REST API for quota queries and adjustments
|
||||
- `QuotaContracts` (`src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.WebService/Contracts/QuotaContracts.cs`) - API contracts for quota operations
|
||||
- `Throttle` (`src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.Core/Domain/Throttle.cs`) - throttle configuration for rate limiting
|
||||
- `AdaptiveRateLimiter` (`src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.Core/RateLimiting/AdaptiveRateLimiter.cs`) - adaptive rate limiting based on system load
|
||||
- `ConcurrencyLimiter` (`src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.Core/RateLimiting/ConcurrencyLimiter.cs`) - limits concurrent job execution
|
||||
- `BackpressureHandler` (`src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.Core/RateLimiting/BackpressureHandler.cs`) - backpressure signaling
|
||||
- `LoadShedder` (`src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.Core/Scale/LoadShedder.cs`) - load shedding under saturation
|
||||
- `PostgresQuotaRepository` (`src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.Infrastructure/Postgres/PostgresQuotaRepository.cs`) - Postgres-backed quota storage
|
||||
- `PostgresThrottleRepository` (`src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.Infrastructure/Postgres/PostgresThrottleRepository.cs`) - Postgres-backed throttle storage
|
||||
|
||||
## What's Missing
|
||||
- **Dedicated quota governance service**: No standalone `QuotaGovernanceService` enforcing cross-tenant quota allocation, burst capacity, and fair scheduling across tenants
|
||||
- **Circuit breaker automation**: No automated circuit breaker that opens when a downstream service (e.g., scanner, attestor) fails repeatedly, preventing cascade failures across orchestrator jobs
|
||||
- **Quota allocation policies**: No configurable policies for quota allocation (e.g., proportional allocation, priority-based allocation, reserved capacity)
|
||||
- **Circuit breaker dashboard**: No UI showing circuit breaker states for each downstream service
|
||||
- **Quota usage alerts**: No alerting when tenants approach their quota limits via Notifier integration
|
||||
- **Circuit breaker state persistence**: No persistent storage for circuit breaker state across orchestrator restarts
|
||||
|
||||
## Implementation Plan
|
||||
- Create `QuotaGovernanceService` enforcing cross-tenant allocation policies
|
||||
- Implement circuit breaker pattern for downstream services (scanner, attestor, policy engine)
|
||||
- Add configurable quota allocation policies (proportional, priority-based)
|
||||
- Add circuit breaker state persistence in PostgreSQL
|
||||
- Build circuit breaker dashboard UI component
|
||||
- Add quota usage alerting via Notifier integration
|
||||
- Add tests for quota governance, circuit breaker state transitions, and allocation policies
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
@@ -0,0 +1,27 @@
|
||||
# Delta-If-Present Calculations for Missing Signals
|
||||
|
||||
## Status
|
||||
NOT_FOUND
|
||||
|
||||
## Description
|
||||
The advisory proposed computing "delta if present" values showing what would change if missing signals arrived (TSF-004). This was marked TODO and has not been implemented.
|
||||
|
||||
## Why Not Implemented
|
||||
- The specific "delta-if-present" calculation (TSF-004) for showing hypothetical score changes is not implemented as a standalone feature
|
||||
- However, related infrastructure exists in the Policy Determinization module:
|
||||
- `src/Policy/__Libraries/StellaOps.Policy.Determinization/Models/SignalGap.cs` -- models for missing/gap signals
|
||||
- `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/UncertaintyScoreCalculator.cs` -- calculates uncertainty from missing signals
|
||||
- `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/PriorDistribution.cs` -- prior distributions for gap handling
|
||||
- `src/Policy/__Libraries/StellaOps.Policy.Determinization/DeterminizationOptions.cs` -- configuration for determinization behavior
|
||||
- `src/Policy/StellaOps.Policy.Engine/Simulation/RiskSimulationBreakdown.cs` -- risk simulation with breakdown
|
||||
- Tests: `src/Policy/__Tests/StellaOps.Policy.Engine.Tests/Simulation/RiskSimulationBreakdownServiceTests.cs`
|
||||
- The Determinization module handles missing signals by computing uncertainty scores but does not project "what would change if signal X arrived" as a delta preview
|
||||
- Graph module also tracks missing signals: `src/Graph/__Libraries/StellaOps.Graph.Core/ICveObservationNodeRepository.cs`
|
||||
|
||||
## Source
|
||||
- Feature matrix scan
|
||||
|
||||
## Notes
|
||||
- Module: Policy
|
||||
- Modules referenced: `src/Policy`
|
||||
- Related: `src/Policy/__Libraries/StellaOps.Policy.Determinization/` (uncertainty scoring for gaps)
|
||||
@@ -0,0 +1,57 @@
|
||||
# Deterministic Trust Score Algebra and Vulnerability Scoring
|
||||
|
||||
## Module
|
||||
Policy (with Attestor TrustVerdict integration)
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Comprehensive scoring infrastructure exists across Policy and Attestor modules: EWS engine, Determinization system with 6-dimension normalizers (RCH/RTS/BKP/XPL/SRC/MIT), K4Lattice trust algebra (Belnap four-valued logic), TrustScoreAggregator with uncertainty penalty, DecayedConfidenceCalculator, ClaimScoreMerger with conflict penalization, ScorePolicy model with basis-point weights, TrustVerdictService with composite scoring, and BackportProofGenerator confidence calculations. The unified facade API composing all scoring subsystems and the Score.v1 predicate format are not yet built.
|
||||
|
||||
## What's Implemented
|
||||
- **TrustScoreAggregator**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/TrustScoreAggregator.cs` -- weighted-average aggregation of 6 signal types (VEX, EPSS, Reachability, Runtime, Backport, SBOMLineage) with uncertainty penalty: `adjustedScore = baseScore * (1.0 - entropy)`
|
||||
- **UncertaintyScoreCalculator**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/UncertaintyScoreCalculator.cs` -- entropy formula: `1.0 - (presentWeight / totalPossibleWeight)` with signal gap tracking
|
||||
- **SignalWeights**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/SignalWeights.cs` -- configurable 6-dimension weights: VEX=0.25, EPSS=0.15, Reachability=0.25, Runtime=0.15, Backport=0.10, SBOMLineage=0.10
|
||||
- **K4Lattice trust algebra**: `src/Policy/__Libraries/StellaOps.Policy/TrustLattice/K4Lattice.cs` -- Belnap four-valued logic: Unknown=0, True=1, False=2, Conflict=3; Join, Meet, LessOrEqual
|
||||
- **ClaimScoreMerger**: `src/Policy/__Libraries/StellaOps.Policy/TrustLattice/ClaimScoreMerger.cs` -- deterministic merge with conflict penalization (0.25 penalty), PreferSpecificity, RequireReplayProofOnConflict
|
||||
- **ScorePolicy model**: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScorePolicyModels.cs` -- 4-factor basis-points scoring: BaseSeverity=1000, Reachability=4500, Evidence=3000, Provenance=1500 (sum=10000)
|
||||
- **ConflictDetector**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/ConflictDetector.cs` (306 lines)
|
||||
- **DecayedConfidenceCalculator**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/DecayedConfidenceCalculator.cs` -- exponential decay: `max(floor, baseConfidence * exp(-ln(2) * ageDays / halfLifeDays))`
|
||||
- **Trust Verdict Service**: `src/Attestor/__Libraries/StellaOps.Attestor.TrustVerdict/Services/TrustVerdictService.cs` (with `.Scoring`, `.BuildPredicate`, `.Builders`, `.Generate`) -- trust scoring combining origin, freshness, reputation
|
||||
- **Trust Composite**: `TrustVerdict/Predicates/TrustComposite.cs` -- composite trust score model
|
||||
- **Backport Proof Confidence**: `Generators/BackportProofGenerator.Confidence.cs` -- deterministic confidence scoring (Tier1: 0.98, Tier2: 0.80-0.95, Tier3: 0.80-0.90, Tier4: 0.55-0.85)
|
||||
- **Evidence Summary**: `ProofChain/Generators/EvidenceSummary.cs` -- evidence count and type summary
|
||||
- **Reachability Witness Evidence**: `ProofChain/Predicates/MicroWitnessFunctionEvidence.cs` -- reachability evidence inputs for scoring
|
||||
|
||||
## What's Missing
|
||||
- **Unified facade API**: No single `ComputeTrustScore(artifact)` entry point composing TrustScoreAggregator + K4Lattice + ScorePolicy + TrustVerdictService into one deterministic pipeline (the "B+C+D composition" described in advisories)
|
||||
- **Score.v1 predicate format**: No standalone Score.v1 schema combining all scoring dimensions into a single DSSE-signable attestation format
|
||||
- **Basis-point fixed-point arithmetic**: Scoring uses floating-point doubles in some paths, not fixed-point basis-point representation for guaranteed bit-exact determinism across all dimensions
|
||||
- **ScoreGraph concept**: No graph-based score computation where each node contributes to a composite score with typed edges for score propagation
|
||||
- **Score replay verification**: No mechanism to replay a score computation with frozen inputs and verify it matches the original to the last basis point
|
||||
- **Score history and trending**: No persistence of score history for trend analysis over time
|
||||
- **Algebra verification tests**: No property-based tests proving commutativity, associativity, and idempotency of the trust score algebra
|
||||
- **Cross-scanner score normalization**: No normalization layer that maps different scanner confidence outputs to a unified scale
|
||||
- **Score attestation pipeline**: No pipeline producing DSSE-signed Score.v1 attestations as standalone evidence artifacts
|
||||
|
||||
## Implementation Plan
|
||||
- Create `TrustScoreAlgebraFacade` composing TrustScoreAggregator + K4Lattice + ScorePolicy into a single deterministic pipeline
|
||||
- Define Score.v1 predicate schema with basis-point fixed-point representation
|
||||
- Implement basis-point fixed-point arithmetic with determinism guarantees across all scoring paths
|
||||
- Add score replay verification using VerdictReceiptPayload
|
||||
- Add property-based tests proving algebraic invariants (commutativity of merge, idempotency of lattice join)
|
||||
- Create score attestation pipeline producing DSSE-signed Score.v1 attestations
|
||||
- Document the formal algebra specification in `docs/modules/policy/trust-score-algebra.md`
|
||||
- Implement score history persistence with PostgreSQL for trend analysis
|
||||
|
||||
## Related Documentation
|
||||
- Weight manifest: `etc/weights/v2026-01-22.weights.json`
|
||||
- Trust lattice engine: `src/Policy/__Libraries/StellaOps.Policy/TrustLattice/` (15 files)
|
||||
- Determinization library: `src/Policy/__Libraries/StellaOps.Policy.Determinization/`
|
||||
- TrustVerdict: `src/Attestor/__Libraries/StellaOps.Attestor.TrustVerdict/`
|
||||
|
||||
## Merged From
|
||||
- `attestor/deterministic-score-from-reachability-evidence-provenance.md` (deleted)
|
||||
- `attestor/deterministic-trust-score-and-vulnerability-scoring.md` (deleted)
|
||||
- `attestor/deterministic-vulnerability-scoring.md` (deleted)
|
||||
@@ -0,0 +1,65 @@
|
||||
# Evidence-Weighted Score (EWS) Model (6-Dimension Scoring)
|
||||
|
||||
## Module
|
||||
Policy
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Scoring infrastructure with policy-driven weights, profiles, and explanations exists. The advisory proposed a new unified 6-dimension model (RCH/RTS/BKP/XPL/SRC/MIT) to replace 4 independent scoring systems. Core normalizers and guardrails engine appear partially built; full unification is in progress.
|
||||
|
||||
## What's Implemented
|
||||
- **SignalWeights (6-dimension)**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/SignalWeights.cs`
|
||||
- 6 signal dimensions: VexWeight=0.25, EpssWeight=0.15, ReachabilityWeight=0.25, RuntimeWeight=0.15, BackportWeight=0.10, SbomLineageWeight=0.10
|
||||
- `TotalWeight` computed property, `IsNormalized(tolerance)` validation
|
||||
- **Weight manifest file**: `etc/weights/v2026-01-22.weights.json`
|
||||
- Legacy 6-dimension weights: RCH=0.30, RTS=0.25, BKP=0.15, XPL=0.15, SRC=0.10, MIT=0.10
|
||||
- Advisory 5-dimension weights: CVSS=0.25, EPSS=0.30, Reachability=0.20, ExploitMaturity=0.10, PatchProof=0.15
|
||||
- Guardrails: notAffectedCap (maxScore=15), runtimeFloor (minScore=60), speculativeCap (maxScore=45)
|
||||
- Buckets: actNowMin=90, scheduleNextMin=70, investigateMin=40
|
||||
- Subtractive dimensions: MIT, patchProof
|
||||
- **ScoringRulesSnapshot**: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScoringRulesSnapshot.cs`
|
||||
- 6-category ScoringWeights: Vulnerability=0.25, Exploitability=0.20, Reachability=0.20, Compliance=0.15, SupplyChain=0.10, Mitigation=0.10
|
||||
- GradeThresholds (A>=90, B>=80, C>=70, D>=60, F<60)
|
||||
- SeverityMultipliers: Critical=1.5, High=1.2, Medium=1.0, Low=0.8, Informational=0.5
|
||||
- FreshnessDecayConfig: sbomDecayStartHours=168, feedDecayStartHours=24, decayRatePerHour=0.001, minimumFreshness=0.5
|
||||
- CustomScoringRule support (Rego/SPL)
|
||||
- Content-addressed digest via SHA256
|
||||
- **ScoringProfile enum**: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScoringProfile.cs`
|
||||
- Simple (4-factor basis-points), Advanced (entropy + CVSS hybrid), Custom (user Rego)
|
||||
- **ScorePolicy (4-factor)**: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScorePolicyModels.cs`
|
||||
- WeightsBps: BaseSeverity=1000, Reachability=4500, Evidence=3000, Provenance=1500 (sum=10000)
|
||||
- ReachabilityPolicyConfig with HopBuckets and GateMultipliersBps
|
||||
- EvidencePolicyConfig with FreshnessBuckets (7d=100%, 30d=90%, 90d=70%, 180d=50%, 365d=30%, >1y=10%)
|
||||
- ProvenanceLevels: Unsigned=0, Signed=30, SignedWithSbom=60, SignedWithSbomAndAttestations=80, Reproducible=100
|
||||
- **ScorePolicyLoader**: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScorePolicyLoader.cs`
|
||||
- YAML loading with version validation ("score.v1"), weight sum validation (10000 bps)
|
||||
- **ScorePolicyValidator**: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScorePolicyValidator.cs`
|
||||
- JSON Schema validation against embedded score.v1 schema
|
||||
- **ScoreExplanation**: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScoreExplanation.cs`
|
||||
- Factor-based explanations: reachability (hops), evidence (points + freshness), provenance (level), baseSeverity (CVSS)
|
||||
- ScoreExplainBuilder with deterministic output (sorted by factor name)
|
||||
- **TrustSourceWeightService**: `src/Policy/__Libraries/StellaOps.Policy/Scoring/TrustSourceWeights.cs`
|
||||
- 14 KnownSources with per-source weights (NVD=0.90, CISA-KEV=0.98, OSV=0.75, etc.)
|
||||
- 7 SourceCategory weights (Government=0.95, Vendor=0.85, Distro=0.82, Community=0.70)
|
||||
- Modifiers: signed data boost (1.05x), stale data penalty (>7d: 0.95x, >30d: 0.90x)
|
||||
- Corroboration boost when multiple sources agree (1.1x per corroborating source, max 3)
|
||||
- WeightedMergeResult with weighted CVSS averaging
|
||||
|
||||
## What's Missing
|
||||
- **Unified 6-dimension RCH/RTS/BKP/XPL/SRC/MIT model**: The weight manifest defines both "legacy" (6D) and "advisory" (5D) weight sets, but there is no single unified normalizer that maps all signal inputs to the canonical 6-dimension space
|
||||
- **Dimension normalizers**: Individual signal-to-dimension normalization functions (e.g., raw EPSS probability -> XPL dimension score 0-100) are not formalized as pluggable normalizer interfaces
|
||||
- **Guardrails engine enforcement**: Weight manifest defines guardrails (notAffectedCap, runtimeFloor, speculativeCap) but the runtime engine that enforces these caps/floors during scoring is not confirmed as a standalone service
|
||||
- **Weight manifest loader integration**: `FileBasedWeightManifestLoader` exists in `src/Signals/StellaOps.Signals/EvidenceWeightedScore/` and `ScoringManifestVersioner` exists in `src/__Libraries/StellaOps.DeltaVerdict/Manifest/`, but neither is wired into the Policy scoring pipeline
|
||||
|
||||
## Implementation Plan
|
||||
- Create `EwsDimensionNormalizer` interface with implementations for each of the 6 dimensions
|
||||
- Build `GuardrailsEngine` that applies caps/floors from the weight manifest after scoring
|
||||
- Add `WeightManifestLoader` with version discovery, schema validation, and content-hash verification
|
||||
- Unify the two weight systems (legacy 6D + advisory 5D) into a single configurable scoring pipeline
|
||||
|
||||
## Related Documentation
|
||||
- Weight manifest: `etc/weights/v2026-01-22.weights.json`
|
||||
- Scoring rules snapshot: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScoringRulesSnapshot.cs`
|
||||
- Determinization scoring: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/`
|
||||
@@ -0,0 +1,45 @@
|
||||
# Impact Scoring for Unknowns
|
||||
|
||||
## Module
|
||||
Policy
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
The advisory proposed weighted impact scoring with factors like environment exposure, data sensitivity, fleet prevalence, SLA tier, and CVSS severity. UncertaintyScoreCalculator and TrustScoreAggregator with configurable SignalWeights exist in the Determinization library, and ReachabilityScoringService exists in Signals. The exact multi-factor impact formula (w_env * EnvExposure + w_data * DataSensitivity + ...) is partially reflected through the existing signal weights system, though the specific per-factor normalization described in the advisory is not confirmed.
|
||||
|
||||
## What's Implemented
|
||||
- **UncertaintyScoreCalculator**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/UncertaintyScoreCalculator.cs`
|
||||
- Entropy-based uncertainty: `1.0 - (presentSignalWeight / totalPossibleWeight)`
|
||||
- 6 signal gap categories: VEX, EPSS, Reachability, Runtime, Backport, SBOMLineage
|
||||
- OpenTelemetry histogram: `stellaops_determinization_uncertainty_entropy`
|
||||
- **SignalWeights**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/SignalWeights.cs`
|
||||
- Configurable per-signal weights (VEX=0.25, Reachability=0.25, EPSS=0.15, Runtime=0.15, Backport=0.10, SBOM=0.10)
|
||||
- **TrustScoreAggregator**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/TrustScoreAggregator.cs`
|
||||
- Weighted average of present signals with uncertainty penalty
|
||||
- No-signal fallback: `0.5 * (1.0 - entropy)`
|
||||
- **UnknownRanker** (from unchecked feature): scoring unknowns with two-factor formula `Uncertainty*50 + ExploitPressure*50`
|
||||
- Containment reduction (capped at 40%), band assignment (Hot>=75, Warm>=50, Cold>=25)
|
||||
- **DecayedConfidenceCalculator**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/DecayedConfidenceCalculator.cs`
|
||||
- Exponential decay applied to confidence based on observation age
|
||||
- **Weight manifest guardrails**: `etc/weights/v2026-01-22.weights.json`
|
||||
- Determinization thresholds: manualReviewEntropy=0.60, refreshEntropy=0.40
|
||||
|
||||
## What's Missing
|
||||
- **Multi-factor impact formula**: The advisory-specified formula `w_env * EnvExposure + w_data * DataSensitivity + w_fleet * FleetPrevalence + w_sla * SLATier + w_cvss * CVSSSeverity` is not implemented as a dedicated calculator
|
||||
- **Environment exposure scoring**: No service that maps environment type (production/staging/dev) to a normalized exposure score (0.0-1.0)
|
||||
- **Data sensitivity classification**: No integration with data sensitivity labels (PII, financial, healthcare) for impact scoring
|
||||
- **Fleet prevalence factor**: No calculator that determines what percentage of the fleet is affected by a given unknown
|
||||
- **SLA tier weighting**: No mapping from SLA tier (Gold/Silver/Bronze) to impact weight
|
||||
- **Per-factor normalization functions**: Individual normalizers for each impact factor are not implemented as pluggable components
|
||||
|
||||
## Implementation Plan
|
||||
- Create `ImpactScoreCalculator` with pluggable factor providers (EnvironmentExposure, DataSensitivity, FleetPrevalence, SLATier, CVSSSeverity)
|
||||
- Integrate with existing `UncertaintyScoreCalculator` to combine entropy-based uncertainty with multi-factor impact
|
||||
- Add environment exposure mapping service that reads from deployment metadata
|
||||
- Wire into `UnknownRanker` as an additional scoring dimension
|
||||
|
||||
## Related Documentation
|
||||
- Determinization scoring: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/`
|
||||
- Unknowns ranking (unchecked): `docs/features/unchecked/policy/unknowns-ranking-algorithm.md`
|
||||
60
docs/features/unchecked/policy/policy-dsl.md
Normal file
60
docs/features/unchecked/policy/policy-dsl.md
Normal file
@@ -0,0 +1,60 @@
|
||||
# Policy DSL (stella-dsl@1)
|
||||
|
||||
## Module
|
||||
Policy
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Policy loading and evaluation exist but the full `.stella` file DSL format with dedicated parser/compiler/simulator (stella policy lint/compile/simulate) was not found as a standalone tool. Policy evaluation is implemented through structured configuration. However, a full DSL parser/compiler exists in the `StellaOps.PolicyDsl` library.
|
||||
|
||||
## What's Implemented
|
||||
- **DslTokenizer**: `src/Policy/StellaOps.PolicyDsl/DslTokenizer.cs`
|
||||
- Full lexer with token types: braces, parens, brackets, comma, semicolon, colon, operators
|
||||
- Comment support: single-line (`//`) and multi-line (`/* */`)
|
||||
- Source location tracking (line, column) for diagnostics
|
||||
- `TokenizerResult` with tokens and diagnostics
|
||||
- **PolicyParser**: `src/Policy/StellaOps.PolicyDsl/PolicyParser.cs`
|
||||
- Parses token stream into `PolicyDocumentNode` AST
|
||||
- Metadata, settings, profiles, and rules sections
|
||||
- **PolicyCompiler**: `src/Policy/StellaOps.PolicyDsl/PolicyCompiler.cs`
|
||||
- `Compile(source)` -> `PolicyCompilationResult` with Success, IR Document, SHA256 Checksum, CanonicalRepresentation, Diagnostics
|
||||
- Pipeline: Parse -> Build IR -> Serialize canonical -> Compute SHA256 digest
|
||||
- Error collection: any `PolicyIssueSeverity.Error` diagnostic fails compilation
|
||||
- **PolicyIr / PolicyIrSerializer**: `src/Policy/StellaOps.PolicyDsl/PolicyIr.cs`, `PolicyIrSerializer.cs`
|
||||
- Intermediate representation: PolicyIrDocument, PolicyIrProfile (maps, envs, scalars), PolicyIrRule
|
||||
- Canonical binary serialization for digest computation
|
||||
- **PolicySyntaxNodes**: `src/Policy/StellaOps.PolicyDsl/PolicySyntaxNodes.cs`
|
||||
- AST node types for the DSL grammar
|
||||
- **DslCompletionProvider**: `src/Policy/StellaOps.PolicyDsl/DslCompletionProvider.cs`
|
||||
- IDE-style completion suggestions for the DSL
|
||||
- **SignalContext**: `src/Policy/StellaOps.PolicyDsl/SignalContext.cs`
|
||||
- Runtime signal value provider: HasSignal, GetSignal<T>, SetSignal
|
||||
- Extension methods: `SecretSignalContextExtensions.cs`, `AiCodeGuardSignalContextExtensions.cs`
|
||||
- **PolicyEngineFactory**: `src/Policy/StellaOps.PolicyDsl/PolicyEngineFactory.cs`
|
||||
- Factory for creating policy evaluation engines from compiled DSL
|
||||
- **DiagnosticCodes**: `src/Policy/StellaOps.PolicyDsl/DiagnosticCodes.cs`
|
||||
- Structured diagnostic codes for parser/compiler errors
|
||||
- **SourceLocation**: `src/Policy/StellaOps.PolicyDsl/SourceLocation.cs`
|
||||
- Position tracking (offset, line, column) for error reporting
|
||||
- **Tests**: `src/Policy/__Tests/StellaOps.PolicyDsl.Tests/` (7 test files)
|
||||
- PolicyCompilerTests, PolicyEngineTests, SignalContextTests, DslCompletionProviderTests
|
||||
|
||||
## What's Missing
|
||||
- **CLI commands**: No `stella policy lint`, `stella policy compile`, or `stella policy simulate` CLI commands wrapping the DSL library
|
||||
- **`.stella` file format specification**: No formal grammar specification or documentation of the DSL syntax
|
||||
- **Policy simulation with DSL**: The `PolicySimulationEngine` in the policy engine does not integrate with DSL-compiled policies
|
||||
- **DSL-to-PolicyPack bridge**: No converter from compiled DSL IR to the PolicyPackDocument format used by the interop framework
|
||||
- **Language server protocol (LSP)**: DslCompletionProvider exists but no LSP server for editor integration
|
||||
|
||||
## Implementation Plan
|
||||
- Add CLI commands (`stella policy lint/compile/simulate`) that wrap the PolicyDsl library
|
||||
- Create DSL grammar specification document
|
||||
- Build bridge from compiled PolicyIrDocument to PolicyPackDocument for interop
|
||||
- Integrate DSL compilation into the policy bundle build pipeline
|
||||
|
||||
## Related Documentation
|
||||
- PolicyDsl library: `src/Policy/StellaOps.PolicyDsl/` (16 source files)
|
||||
- PolicyDsl tests: `src/Policy/__Tests/StellaOps.PolicyDsl.Tests/`
|
||||
- Policy interop: `src/Policy/__Libraries/StellaOps.Policy.Interop/`
|
||||
68
docs/features/unchecked/policy/policy-interop-framework.md
Normal file
68
docs/features/unchecked/policy/policy-interop-framework.md
Normal file
@@ -0,0 +1,68 @@
|
||||
# Policy Interop Framework (JSON Export/Import)
|
||||
|
||||
## Module
|
||||
Policy
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Policy interoperability framework enabling bidirectional JSON export/import of policy rules. OPA/Rego export was planned but only JSON export confirmed in source. Includes PolicyPack document format for portable policy bundles. Full interop library exists with JSON import/export, Rego code generation, and schema validation.
|
||||
|
||||
## What's Implemented
|
||||
- **JsonPolicyExporter**: `src/Policy/__Libraries/StellaOps.Policy.Interop/Export/JsonPolicyExporter.cs`
|
||||
- `ExportToJsonAsync(PolicyPackDocument, PolicyExportRequest)`: canonical JSON export with deterministic output
|
||||
- Environment filtering: merges environment-specific config into base config
|
||||
- Remediation stripping option
|
||||
- Content-addressed digest: `sha256:{hex}` via SHA256 of canonical JSON
|
||||
- `ExportToRegoAsync()`: bridges to RegoCodeGenerator
|
||||
- `SerializeCanonical()` / `SerializeToString()` static helpers
|
||||
- **JsonPolicyImporter**: `src/Policy/__Libraries/StellaOps.Policy.Interop/Import/JsonPolicyImporter.cs`
|
||||
- `ImportAsync(Stream, PolicyImportOptions)` / `ImportFromStringAsync()`
|
||||
- Format detection via `FormatDetector` (auto-detect JSON vs Rego)
|
||||
- API version validation: `policy.stellaops.io/v2` (with v1 compatibility adapter warning)
|
||||
- Kind validation: `PolicyPack` or `PolicyOverride`
|
||||
- Structural validation: duplicate gate IDs, duplicate rule names
|
||||
- Remediation hint validation (code, actions)
|
||||
- Diagnostic codes: FORMAT_UNKNOWN, REGO_USE_IMPORTER, JSON_PARSE_ERROR, VERSION_UNKNOWN, KIND_INVALID, GATE_ID_DUPLICATE, RULE_NAME_DUPLICATE
|
||||
- `PolicyImportResult` with Success, Document, DetectedFormat, Diagnostics, GateCount, RuleCount
|
||||
- **RegoCodeGenerator**: `src/Policy/__Libraries/StellaOps.Policy.Interop/Rego/RegoCodeGenerator.cs`
|
||||
- Generates OPA Rego deny rules from PolicyPackDocument
|
||||
- Gate type mappings: CvssThreshold, SignatureRequired, EvidenceFreshness, SbomPresence, MinimumConfidence, UnknownsBudget, ReachabilityRequirement
|
||||
- Rego v1 syntax support (`import rego.v1`)
|
||||
- Environment-specific config extraction
|
||||
- Remediation hints as structured output rules
|
||||
- Content-addressed digest of generated Rego source
|
||||
- Warning collection for unmapped gate types
|
||||
- **RegoPolicyImporter**: `src/Policy/__Libraries/StellaOps.Policy.Interop/Import/RegoPolicyImporter.cs`
|
||||
- Imports Rego source back into PolicyPackDocument
|
||||
- **FormatDetector**: `src/Policy/__Libraries/StellaOps.Policy.Interop/Import/FormatDetector.cs`
|
||||
- Auto-detects policy format (JSON, Rego)
|
||||
- **PolicyPack v2 schema**: `src/Policy/__Libraries/StellaOps.Policy.Interop/Schemas/policy-pack-v2.schema.json`
|
||||
- **Abstractions**: `src/Policy/__Libraries/StellaOps.Policy.Interop/Abstractions/`
|
||||
- `IPolicyExporter`, `IPolicyImporter`, `IRegoCodeGenerator` interfaces
|
||||
- **Contracts**: `src/Policy/__Libraries/StellaOps.Policy.Interop/Contracts/`
|
||||
- `PolicyPackDocument`, `PolicyExportRequest`, `PolicyImportOptions`, `RegoGenerationOptions`, `RegoExportResult`, `PolicyDiagnostic`
|
||||
- **DI registration**: `src/Policy/__Libraries/StellaOps.Policy.Interop/DependencyInjection/PolicyInteropServiceCollectionExtensions.cs`
|
||||
- **Evaluation**: `src/Policy/__Libraries/StellaOps.Policy.Interop/Evaluation/`
|
||||
- **Tests**: `src/Policy/__Libraries/__Tests/StellaOps.Policy.Interop.Tests/`
|
||||
- JsonPolicyExporterTests, JsonPolicyImporterTests, RegoPolicyImporterTests, RegoCodeGeneratorTests, FormatDetectorTests, PolicySchemaValidatorTests
|
||||
- Golden file: `Fixtures/golden-policy-pack-v2.json`
|
||||
|
||||
## What's Missing
|
||||
- **YAML import/export**: Only JSON and Rego formats are supported; no YAML PolicyPack format
|
||||
- **Policy diff/merge**: No tool to diff two PolicyPackDocuments and produce a delta or merge two packs
|
||||
- **CLI integration**: No `stella policy export --format rego` or `stella policy import` CLI commands wrapping the interop library
|
||||
- **Round-trip validation**: No automated tests proving JSON -> Rego -> JSON round-trip produces identical PolicyPackDocument
|
||||
- **OPA evaluation bridge**: Rego code is generated but there is no OPA evaluation service that runs the generated Rego against actual inputs
|
||||
|
||||
## Implementation Plan
|
||||
- Add CLI commands wrapping export/import operations
|
||||
- Build round-trip test suite (JSON -> Rego -> JSON identity check)
|
||||
- Consider YAML format support using existing ScorePolicyLoader YAML infrastructure
|
||||
- Add policy diff/merge utility for comparing policy versions
|
||||
|
||||
## Related Documentation
|
||||
- Interop library: `src/Policy/__Libraries/StellaOps.Policy.Interop/` (6 subdirectories)
|
||||
- Interop tests: `src/Policy/__Libraries/__Tests/StellaOps.Policy.Interop.Tests/`
|
||||
- Policy registry: `src/Policy/StellaOps.Policy.Registry/`
|
||||
63
docs/features/unchecked/policy/proof-studio-ux.md
Normal file
63
docs/features/unchecked/policy/proof-studio-ux.md
Normal file
@@ -0,0 +1,63 @@
|
||||
# Proof Studio UX (Explainable Confidence Scoring)
|
||||
|
||||
## Module
|
||||
Policy
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Backend confidence calculation, verdict rationale rendering, and counterfactual engine exist. The advisory identified frontend proof studio UI as a remaining gap.
|
||||
|
||||
## What's Implemented
|
||||
- **VerdictRationaleRenderer**: `src/Policy/__Libraries/StellaOps.Policy.Explainability/VerdictRationaleRenderer.cs`
|
||||
- 4-line rationale template: Evidence, Policy Clause, Attestations, Decision
|
||||
- Multi-format output: RenderPlainText, RenderMarkdown, RenderJson (RFC 8785 canonical)
|
||||
- Content-addressed RationaleId: `rat:sha256:{hash}`
|
||||
- **VerdictRationale model**: `src/Policy/__Libraries/StellaOps.Policy.Explainability/VerdictRationale.cs`
|
||||
- Structured rationale: VerdictReference, RationaleEvidence (ComponentIdentity, ReachabilityDetail), RationalePolicyClause, RationaleAttestations (AttestationReference list), RationaleDecision (MitigationGuidance)
|
||||
- RationaleInputDigests for deterministic replay
|
||||
- **IVerdictRationaleRenderer**: `src/Policy/__Libraries/StellaOps.Policy.Explainability/IVerdictRationaleRenderer.cs`
|
||||
- Interface + VerdictRationaleInput record
|
||||
- **CounterfactualEngine**: `src/Policy/__Libraries/StellaOps.Policy/Counterfactuals/CounterfactualEngine.cs`
|
||||
- `ComputeAsync(finding, verdict, document, scoringConfig, options)` -> CounterfactualResult
|
||||
- 5 counterfactual path types: VexStatus, Exception, Reachability, VersionUpgrade, CompensatingControl
|
||||
- Each path: type, description, conditions (field/current/required), estimated effort (1-5), actor, action URI
|
||||
- Policy simulation: creates simulated findings with modified VEX/reachability tags and re-evaluates via `PolicyEvaluation.EvaluateFinding()`
|
||||
- Effort estimation: severity-based for exceptions (Critical=5, High=4, Medium=3, Low=2)
|
||||
- **CounterfactualResult**: `src/Policy/__Libraries/StellaOps.Policy/Counterfactuals/CounterfactualResult.cs`
|
||||
- AlreadyPassing / Blocked factory methods
|
||||
- RecommendedPath (lowest effort), HasPaths
|
||||
- 7 CounterfactualTypes: VexStatus, Exception, Reachability, VersionUpgrade, PolicyChange, ComponentRemoval, CompensatingControl
|
||||
- CounterfactualCondition: Field, CurrentValue, RequiredValue, IsMet
|
||||
- **ScoreExplanation**: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScoreExplanation.cs`
|
||||
- Per-factor explanation: Factor, Value (0-100), Reason, ContributingDigests
|
||||
- ScoreExplainBuilder: AddReachability, AddEvidence, AddProvenance, AddBaseSeverity
|
||||
- Deterministic output (sorted by factor name + digest)
|
||||
- **DecayedConfidenceCalculator**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/DecayedConfidenceCalculator.cs`
|
||||
- Exponential confidence decay for time-based scoring
|
||||
|
||||
## What's Missing
|
||||
- **Proof graph visualization**: No visual representation of the full evidence graph (ProofGraphNode/Edge/Path) in the UI -- the proof-studio has confidence breakdown but not the graph
|
||||
- **Interactive counterfactual explorer**: CounterfactualEngine exists in backend and `what-if-slider` component exists in proof-studio, but the full interactive "toggle what-if scenarios" UX may not be fully wired to the backend
|
||||
- **Score breakdown dashboard**: ScoreExplanation data exists but no dashboard visualizing per-factor contributions with charts
|
||||
- **Confidence timeline**: DecayedConfidenceCalculator computes decay but no UI showing confidence over time
|
||||
|
||||
## Additional Implementation Found
|
||||
- **Proof Studio Container**: `src/Web/StellaOps.Web/src/app/features/proof-studio/components/proof-studio-container/proof-studio-container.component.ts` -- main container component
|
||||
- **Confidence Breakdown**: `src/Web/StellaOps.Web/src/app/features/proof-studio/components/confidence-breakdown/confidence-breakdown.component.ts` -- per-factor confidence visualization
|
||||
- **Confidence Factor Chip**: `src/Web/StellaOps.Web/src/app/features/proof-studio/components/confidence-factor-chip/confidence-factor-chip.component.ts`
|
||||
- **What-If Slider**: `src/Web/StellaOps.Web/src/app/features/proof-studio/components/what-if-slider/what-if-slider.component.ts` -- counterfactual slider control
|
||||
- **Proof Studio Service**: `src/Web/StellaOps.Web/src/app/features/proof-studio/services/proof-studio.service.ts` -- API service
|
||||
- **Proof Trace Model**: `src/Web/StellaOps.Web/src/app/features/proof-studio/models/proof-trace.model.ts`
|
||||
|
||||
## Implementation Plan
|
||||
- Wire what-if-slider to CounterfactualEngine backend API
|
||||
- Add proof graph visualization using D3.js or similar for evidence graph rendering
|
||||
- Add confidence timeline chart using DecayedConfidenceCalculator data
|
||||
- Verify proof-studio-container is fully wired to VerdictRationale API endpoint
|
||||
|
||||
## Related Documentation
|
||||
- Explainability library: `src/Policy/__Libraries/StellaOps.Policy.Explainability/`
|
||||
- Counterfactuals: `src/Policy/__Libraries/StellaOps.Policy/Counterfactuals/`
|
||||
- Score explanations: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScoreExplanation.cs`
|
||||
@@ -0,0 +1,49 @@
|
||||
# Unknowns Decay and Triage Queue
|
||||
|
||||
## Module
|
||||
Policy
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Unknowns ranking and API endpoints exist. BlastRadius model present with database migration. The full time-based decay algorithm and containment signals ranking were identified as gaps in the archive manifest.
|
||||
|
||||
## What's Implemented
|
||||
- **DecayedConfidenceCalculator**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/DecayedConfidenceCalculator.cs`
|
||||
- Exponential decay formula: `max(floor, baseConfidence * exp(-ln(2) * ageDays / halfLifeDays))`
|
||||
- Configurable half-life (default 14 days) and floor
|
||||
- OpenTelemetry histogram: `stellaops_determinization_decay_multiplier`
|
||||
- **ObservationDecay**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Models/ObservationDecay.cs`
|
||||
- Per-observation decay state: BaseConfidence, ObservedAt, HalfLifeDays=14, Floor=0.35, StalenessThreshold=0.50
|
||||
- `CalculateDecay(now)`: computes current decayed confidence
|
||||
- `CheckIsStale(now)`: returns true when decayed confidence falls below staleness threshold
|
||||
- Factory methods: `Create()`, `Fresh()`, `WithSettings()`
|
||||
- **UnknownRanker** (from unchecked features): two-factor scoring `Uncertainty*50 + ExploitPressure*50`
|
||||
- Containment reduction capped at 40%
|
||||
- Band assignment: Hot>=75, Warm>=50, Cold>=25, Ice<25
|
||||
- **UncertaintyScoreCalculator**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/UncertaintyScoreCalculator.cs`
|
||||
- Entropy-based uncertainty from 6 signal dimensions
|
||||
- Signal gap tracking (which signals are missing)
|
||||
- **Risk budget API endpoints** (from unchecked features): budget tracking, ledger, Green/Yellow/Red/Exhausted thresholds
|
||||
- **Unknown budget policy enforcement** (from unchecked features): UncertaintyTierGate (gate 4 in pipeline)
|
||||
|
||||
## What's Missing
|
||||
- **Time-based decay triage queue**: No service that automatically re-queues unknowns for triage when their confidence decays below the staleness threshold
|
||||
- **Triage queue UI**: No frontend triage interface showing unknowns sorted by decay urgency
|
||||
- **Automated re-analysis triggering**: ObservationDecay tracks staleness but no event-driven mechanism triggers re-analysis when an unknown becomes stale
|
||||
- **Containment signal integration**: The advisory describes containment signals (WAF rules, network segmentation, runtime controls) reducing unknown scores -- this is partially in UnknownRanker but not connected to real containment data sources
|
||||
- **Decay notification**: No notification system alerting when high-priority unknowns decay below acceptable confidence
|
||||
- **Historical decay tracking**: DecayedConfidenceCalculator computes point-in-time decay but no ledger tracks confidence decay history over time
|
||||
|
||||
## Implementation Plan
|
||||
- Create `UnknownTriageQueueService` that periodically evaluates ObservationDecay.CheckIsStale() and queues stale unknowns for re-analysis
|
||||
- Add event-driven triggers (e.g., background job or message queue) when confidence drops below threshold
|
||||
- Build triage queue frontend component showing unknowns sorted by urgency (band + decay rate)
|
||||
- Integrate containment signal sources (WAF, network, runtime) as inputs to UnknownRanker
|
||||
- Add decay history ledger for audit trail
|
||||
|
||||
## Related Documentation
|
||||
- Decay calculator: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/DecayedConfidenceCalculator.cs`
|
||||
- Observation decay model: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Models/ObservationDecay.cs`
|
||||
- Unknowns ranking (unchecked): `docs/features/unchecked/policy/unknowns-ranking-algorithm.md`
|
||||
58
docs/features/unchecked/policy/versioned-weight-manifests.md
Normal file
58
docs/features/unchecked/policy/versioned-weight-manifests.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# Versioned Weight Manifests
|
||||
|
||||
## Module
|
||||
Policy
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Initial weight manifest file exists, but the weight manifest infrastructure (loading, versioning, hashing, CLI management) is marked TODO in the sprint (TSF-001).
|
||||
|
||||
## What's Implemented
|
||||
- **Weight manifest file**: `etc/weights/v2026-01-22.weights.json`
|
||||
- Schema: `https://stella-ops.org/schemas/weight-manifest/v1.0.0`
|
||||
- Schema version: 1.0.0, version: v2026-01-22, profile: production
|
||||
- Legacy 6-dimension weights: RCH=0.30, RTS=0.25, BKP=0.15, XPL=0.15, SRC=0.10, MIT=0.10
|
||||
- Advisory 5-dimension weights: CVSS=0.25, EPSS=0.30, Reachability=0.20, ExploitMaturity=0.10, PatchProof=0.15
|
||||
- Dimension names mapping (human-readable)
|
||||
- Subtractive dimensions: MIT, patchProof
|
||||
- Guardrails: notAffectedCap (maxScore=15, requires BKP>=1.0 and RTS<=0.6), runtimeFloor (minScore=60, requires RTS>=0.8), speculativeCap (maxScore=45, requires RCH<=0.0 and RTS<=0.0)
|
||||
- Priority buckets: actNowMin=90, scheduleNextMin=70, investigateMin=40
|
||||
- Determinization thresholds: manualReviewEntropy=0.60, refreshEntropy=0.40
|
||||
- Signal weights for entropy: VEX=0.25, Reachability=0.25, EPSS=0.15, Runtime=0.15, Backport=0.10, SBOMLineage=0.10
|
||||
- Content hash: `sha256:auto` (placeholder for computed hash)
|
||||
- Metadata: changelog, creation date, notes
|
||||
- **SignalWeights record**: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/SignalWeights.cs`
|
||||
- Matches the signalWeightsForEntropy values from the manifest
|
||||
- **ScoringRulesSnapshot**: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScoringRulesSnapshot.cs`
|
||||
- Content-addressed snapshots with SHA256 digest
|
||||
- Builder pattern with WithWeights, WithThresholds, WithSeverityMultipliers, etc.
|
||||
- `IScoringRulesSnapshotService` interface for CRUD operations
|
||||
- **ScorePolicyLoader**: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScorePolicyLoader.cs`
|
||||
- YAML policy loading with version and weight sum validation
|
||||
- **ScorePolicyValidator**: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScorePolicyValidator.cs`
|
||||
- JSON Schema validation for score policies
|
||||
|
||||
## Additional Implementation Found
|
||||
- **FileBasedWeightManifestLoader**: `src/Signals/StellaOps.Signals/EvidenceWeightedScore/FileBasedWeightManifestLoader.cs` -- loads manifests from `etc/weights/*.json` files, implements `IWeightManifestLoader`
|
||||
- **ScoringManifestVersioner**: `src/__Libraries/StellaOps.DeltaVerdict/Manifest/ScoringManifestVersioner.cs` (with `.Compare.cs`, `.Compare.Helpers.cs`) -- manifest versioning with compare, bump, and generate-next-version capabilities
|
||||
- **ScoringManifestSigningService**: `src/__Libraries/StellaOps.DeltaVerdict/` -- manifest signing with KMS integration and Rekor anchoring
|
||||
- **Extensive tests**: `src/__Libraries/__Tests/StellaOps.DeltaVerdict.Tests/Manifest/` -- 7 test files covering versioning, comparison, bumping, signing
|
||||
|
||||
## What's Missing
|
||||
- **CLI management commands**: No `stella weights list`, `stella weights validate`, `stella weights diff`, or `stella weights activate` CLI commands wrapping the existing loader/versioner
|
||||
- **Content hash auto-compute at build**: Manifest has `"contentHash": "sha256:auto"` placeholder -- no build step replaces it with actual computed hash
|
||||
- **Unified binding**: FileBasedWeightManifestLoader is in Signals, ScoringManifestVersioner is in DeltaVerdict; no unified service in the Policy module that binds manifest loading, versioning, signing, and runtime configuration together
|
||||
|
||||
## Implementation Plan
|
||||
- Create `WeightManifestLoader` service that discovers manifests in `etc/weights/`, validates schema, computes/verifies content hash, and selects by `effectiveFrom` date
|
||||
- Add build step to compute content hash and replace `sha256:auto` placeholder
|
||||
- Create CLI commands for manifest lifecycle management
|
||||
- Build manifest-to-runtime binding that configures SignalWeights and ScoringRulesSnapshot from the active manifest
|
||||
- Add manifest diff utility for comparing versions
|
||||
|
||||
## Related Documentation
|
||||
- Weight manifest: `etc/weights/v2026-01-22.weights.json`
|
||||
- Signal weights: `src/Policy/__Libraries/StellaOps.Policy.Determinization/Scoring/SignalWeights.cs`
|
||||
- Scoring rules snapshot: `src/Policy/__Libraries/StellaOps.Policy/Scoring/ScoringRulesSnapshot.cs`
|
||||
@@ -0,0 +1,30 @@
|
||||
# 8-State Reachability Lattice
|
||||
|
||||
## Module
|
||||
ReachGraph
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Reachability infrastructure exists with triage integration, but the full 8-state lattice model (U/SR/SU/RO/RU/CR/CU/X) with mathematical state transitions as described is not fully implemented as a distinct subsystem.
|
||||
|
||||
## What's Implemented
|
||||
- **LatticeState enum**: `src/__Libraries/StellaOps.Reachability.Core/LatticeState.cs` -- full 8-state model defined: Unknown (U), StaticReachable (SR), StaticUnreachable (SU), RuntimeObserved (RO), RuntimeUnobserved (RU), ConfirmedReachable (CR), ConfirmedUnreachable (CU), Contested (X); includes VEX mapping and confidence ranges per state
|
||||
- **ReachabilityLattice state machine**: `src/__Libraries/StellaOps.Reachability.Core/ReachabilityLattice.cs` -- `FrozenDictionary` transition table with evidence accumulation; transitions from all states including conflict detection (X state when static and runtime evidence contradict); confidence delta per transition
|
||||
- **ConfidenceCalculator**: `src/__Libraries/StellaOps.Reachability.Core/ConfidenceCalculator.cs` -- confidence score computation
|
||||
- **IReachabilityIndex**: `src/__Libraries/StellaOps.Reachability.Core/IReachabilityIndex.cs` -- `QueryHybridAsync` returns `HybridReachabilityResult` with lattice state
|
||||
- **HybridReachabilityResult**: `src/__Libraries/StellaOps.Reachability.Core/HybridReachabilityResult.cs` -- includes lattice state, confidence, and VEX recommendation
|
||||
|
||||
## What's Missing
|
||||
- The lattice state machine is implemented as a library but not fully integrated as a distinct subsystem with its own API surface for triage workflows
|
||||
- Triage-specific UI for lattice state visualization and manual state overrides
|
||||
- Lattice state persistence and audit trail for state transitions
|
||||
|
||||
## Implementation Plan
|
||||
- Expose lattice state transitions as an API for triage integration
|
||||
- Build UI for lattice state visualization and manual overrides
|
||||
- Add persistence layer for state transition history and audit trail
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
@@ -0,0 +1,36 @@
|
||||
# Reachability Core Library with Unified Query Interface
|
||||
|
||||
## Module
|
||||
ReachGraph
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
ReachGraph has a web service with store and slice services, but the unified `IReachabilityIndex` facade combining static + runtime evidence is not present as a distinct library.
|
||||
|
||||
## What's Implemented
|
||||
- **IReachabilityIndex interface**: `src/__Libraries/StellaOps.Reachability.Core/IReachabilityIndex.cs` -- unified facade with `QueryStaticAsync`, `QueryRuntimeAsync`, `QueryHybridAsync`, `QueryBatchAsync`; this IS the unified query interface
|
||||
- **ReachabilityIndex**: `src/__Libraries/StellaOps.Reachability.Core/ReachabilityIndex.cs` -- default implementation combining `IReachGraphAdapter` and `ISignalsAdapter`
|
||||
- **IReachGraphAdapter**: `src/__Libraries/StellaOps.Reachability.Core/IReachGraphAdapter.cs` -- adapter for static call graph data
|
||||
- **ISignalsAdapter**: `src/__Libraries/StellaOps.Reachability.Core/ISignalsAdapter.cs` -- adapter for runtime signal data
|
||||
- **HybridReachabilityResult**: `src/__Libraries/StellaOps.Reachability.Core/HybridReachabilityResult.cs` -- hybrid query result with lattice state
|
||||
- **HybridQueryOptions**: `src/__Libraries/StellaOps.Reachability.Core/HybridQueryOptions.cs` -- configurable query options
|
||||
- **StaticReachabilityResult / RuntimeReachabilityResult**: individual layer results
|
||||
- **SymbolRef, ConfidenceCalculator, EvidenceUriBuilder**: supporting types
|
||||
- **ServiceCollectionExtensions**: `src/__Libraries/StellaOps.Reachability.Core/ServiceCollectionExtensions.cs` -- DI registration
|
||||
- **Tests**: `src/__Libraries/__Tests/StellaOps.Reachability.Core.Tests/`
|
||||
|
||||
## What's Missing
|
||||
- The `IReachabilityIndex` facade exists but the ReachGraph web service (`src/ReachGraph/`) does not use it directly; the web service has its own store/slice/replay services
|
||||
- Missing: adapter implementations that wire `IReachabilityIndex` to the ReachGraph store and Signals services
|
||||
- Missing: unified query endpoint in the web service that delegates to `IReachabilityIndex`
|
||||
|
||||
## Implementation Plan
|
||||
- Implement `IReachGraphAdapter` backed by `IReachGraphStoreService`
|
||||
- Implement `ISignalsAdapter` backed by the Signals runtime data
|
||||
- Add unified query endpoint in ReachGraph web service that delegates to `IReachabilityIndex`
|
||||
- Wire up DI registration via `ServiceCollectionExtensions`
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
@@ -0,0 +1,31 @@
|
||||
# Release Orchestrator Performance Optimizations (Bulk Digest, Parallel Gates, Prefetch, Connection Pool, Baseline Tracking)
|
||||
|
||||
## Module
|
||||
ReleaseOrchestrator
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Performance optimization suite: batched OCI digest resolution, concurrent gate evaluation with configurable concurrency limits, predictive data prefetching for gate inputs/scan results/attestation data, connection pool management with idle timeouts, and performance baseline tracking with regression detection. Bulk digest resolver is partially implemented.
|
||||
|
||||
## What's Implemented
|
||||
- **Modules**: `src/ReleaseOrchestrator/__Libraries/StellaOps.ReleaseOrchestrator.Performance/`
|
||||
- **Key Classes**:
|
||||
- `BulkDigestResolver` (`src/ReleaseOrchestrator/__Libraries/StellaOps.ReleaseOrchestrator.Performance/Registry/BulkDigestResolver.cs`) - batched OCI digest resolution for multiple images
|
||||
- `ParallelGateEvaluator` (`src/ReleaseOrchestrator/__Libraries/StellaOps.ReleaseOrchestrator.Performance/Gates/ParallelGateEvaluator.cs`) - concurrent gate evaluation with configurable concurrency limits
|
||||
- **Source**: SPRINT_20260117_038_ReleaseOrchestrator_performance.md
|
||||
|
||||
## What's Missing
|
||||
- **Predictive data prefetching**: service to prefetch gate inputs, scan results, and attestation data before they are needed
|
||||
- **Connection pool management**: pool manager with idle timeouts for registry/agent connections
|
||||
- **Performance baseline tracking**: baseline recorder and regression detector comparing current metrics against historical baselines
|
||||
|
||||
## Implementation Plan
|
||||
- Implement `DataPrefetcher` service for predictive prefetching of gate inputs and scan results
|
||||
- Implement `ConnectionPoolManager` with configurable idle timeouts for registry and agent connections
|
||||
- Implement `PerformanceBaseline` tracker and `RegressionDetector` for baseline comparison
|
||||
- Add unit and integration tests for all new components
|
||||
|
||||
## Related Documentation
|
||||
- Source: SPRINT_20260117_038_ReleaseOrchestrator_performance.md
|
||||
@@ -0,0 +1,40 @@
|
||||
# Immutable Advisory Feed Snapshots
|
||||
|
||||
## Module
|
||||
Replay
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
The replay infrastructure supports input manifests and determinism tracking which conceptually align with point-in-time query capability, but a dedicated feed snapshotting system with per-provider immutable blobs and point-in-time advisory resolution is not directly implemented as described.
|
||||
|
||||
## What's Implemented
|
||||
- **Input Manifest Resolver**: `src/Replay/StellaOps.Replay.Core/InputManifestResolver.cs` -- resolves input manifests that capture the exact inputs (feed data, SBOM, VEX, policy) used for a verdict, enabling replay with identical inputs. This provides partial snapshot functionality by recording what feed data was consumed.
|
||||
- **Determinism Verifier**: `src/Replay/StellaOps.Replay.Core/DeterminismVerifier.cs` -- verifies that replaying a verdict with the same inputs produces the same output, which indirectly validates feed data consistency.
|
||||
- **Replay Executor**: `src/Replay/StellaOps.Replay.Core/ReplayExecutor.cs` -- executes verdict replay using captured input manifests, consuming the recorded feed data rather than live feeds.
|
||||
- **Policy Simulation Input Lock**: `src/Replay/StellaOps.Replay.Core/PolicySimulationInputLock.cs` -- locks policy simulation inputs to prevent mutation during replay, ensuring deterministic execution.
|
||||
- **Replay Job Queue**: `src/Replay/StellaOps.Replay.Core/ReplayJobQueue.cs` -- manages replay job scheduling and execution.
|
||||
- **Trace Anonymizer**: `src/Replay/StellaOps.Replay.Anonymization/TraceAnonymizer.cs` -- anonymizes replay traces for sharing without exposing sensitive feed data.
|
||||
- **Verdict Replay Endpoints**: `src/Replay/StellaOps.Replay.WebService/VerdictReplayEndpoints.cs` -- API endpoints for triggering and querying verdict replays.
|
||||
|
||||
## What's Missing
|
||||
- **Per-Provider Feed Snapshots**: No system exists to capture immutable snapshots of advisory feeds on a per-provider basis (e.g., NVD snapshot at epoch T, GHSA snapshot at epoch T). The input manifest records which feed data was used but does not create addressable, immutable blob snapshots.
|
||||
- **Point-in-Time Advisory Resolution**: No API exists to query "what was the advisory state for CVE-X at time T?" across all providers. Feed data is consumed in real-time; historical queries require replaying from input manifests.
|
||||
- **Feed Snapshot Storage**: No dedicated content-addressable storage for feed snapshots (e.g., immutable blobs with digest-based retrieval). Feed data flows through the pipeline but is not persisted as versioned snapshots.
|
||||
- **Snapshot Epoch Registry**: No registry that maps epoch identifiers to feed snapshot digests, enabling O(1) lookup of historical feed state.
|
||||
- **Snapshot Attestation**: No attestation mechanism for feed snapshots that proves the snapshot was captured at a specific time and has not been tampered with.
|
||||
|
||||
## Implementation Plan
|
||||
- Design a per-provider feed snapshot format (content-addressable blob with provider ID, epoch timestamp, digest)
|
||||
- Implement a snapshot capture service that creates immutable blobs when feed data is ingested, storing them in content-addressable storage
|
||||
- Build a snapshot epoch registry mapping epoch IDs to snapshot digests for all providers
|
||||
- Add point-in-time advisory resolution API that resolves advisory state by looking up the appropriate epoch snapshot
|
||||
- Add snapshot attestation (signed digest + timestamp) for tamper-evidence
|
||||
- Integrate with the existing `InputManifestResolver` so replay can reference snapshots by epoch/digest rather than inline data
|
||||
|
||||
## Related Documentation
|
||||
- Replay infrastructure: `src/Replay/StellaOps.Replay.Core/`
|
||||
- Feed ingestion (Concelier): `src/Concelier/`
|
||||
- Feed processing (Excititor): `src/Excititor/`
|
||||
- Determinism testing: `src/__Tests/__Libraries/StellaOps.Testing.Determinism/`
|
||||
@@ -0,0 +1,25 @@
|
||||
# Point-in-Time Vulnerability Query (As-Of Date)
|
||||
|
||||
## Status
|
||||
NOT_FOUND
|
||||
|
||||
## Description
|
||||
The ability to evaluate vulnerabilities against advisory data as of a specific historical date is not implemented. The replay system tracks inputs but does not provide temporal advisory queries.
|
||||
|
||||
## Why Not Implemented
|
||||
- No temporal/as-of-date vulnerability query API found in `src/`
|
||||
- The Replay module (`src/__Libraries/StellaOps.Replay.Core/`) and Unknowns module (`src/Unknowns/`) track historical state but do not provide temporal advisory queries
|
||||
- The Unknowns persistence layer has SQL migrations with `point_in_time` references: `src/Unknowns/__Libraries/StellaOps.Unknowns.Persistence/Migrations/001_initial_schema.sql`
|
||||
- `IUnknownRepository` has methods that could support temporal queries
|
||||
- The Facet module has `FacetSeal` with point-in-time concepts: `src/__Libraries/StellaOps.Facet/FacetSeal.cs`
|
||||
- The Scanner has historical data in Smart Diff tables: `src/Scanner/__Libraries/StellaOps.Scanner.Storage/Postgres/Migrations/005_smart_diff_tables.sql`
|
||||
- Key rotation service tracks historical keys: `src/Signer/__Libraries/StellaOps.Signer.KeyManagement/IKeyRotationService.cs`
|
||||
- Infrastructure for temporal queries exists but no unified "as-of date" API endpoint has been built
|
||||
|
||||
## Source
|
||||
- Feature matrix scan
|
||||
|
||||
## Notes
|
||||
- Module: Uncategorized
|
||||
- Modules referenced: N/A
|
||||
- Related: `src/Unknowns/` (historical tracking), `src/__Libraries/StellaOps.Facet/` (point-in-time seals), `src/__Libraries/StellaOps.Replay.Core/` (replay system)
|
||||
@@ -0,0 +1,33 @@
|
||||
# Exploit Maturity Mapping
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
No dedicated exploit maturity mapping service found. The EPSS provider in RiskEngine may partially cover this.
|
||||
|
||||
## Module
|
||||
RiskEngine
|
||||
|
||||
## What's Implemented
|
||||
- **EPSS provider**: `src/RiskEngine/StellaOps.RiskEngine/StellaOps.RiskEngine.Core/Providers/EpssProvider.cs` (implements `IRiskScoreProvider`)
|
||||
- **Combined CVSS+KEV+EPSS**: `CvssKevEpssProvider` in same file
|
||||
- **Scanner EPSS**: `src/Scanner/__Libraries/StellaOps.Scanner.Storage/Epss/EpssProvider.cs`
|
||||
- **EPSS API endpoints**: `src/Scanner/StellaOps.Scanner.WebService/Endpoints/EpssEndpoints.cs`
|
||||
- **Golden benchmark corpus**: `src/__Tests/__Benchmarks/golden-corpus/` (includes EPSS/KEV scoring)
|
||||
- **SBOM vulnerability assessment**: `src/Attestor/__Libraries/StellaOps.Attestor.StandardPredicates/Models/SbomVulnerabilityAssessmentType.cs`
|
||||
- **Policy-level exploit scoring**: `UnknownRanker` uses `EpssScore` for prioritization
|
||||
- **Tests**: `src/Scanner/__Tests/StellaOps.Scanner.Storage.Tests/EpssProviderTests.cs`
|
||||
|
||||
## What's Missing
|
||||
- Dedicated "exploit maturity mapping" service consolidating all maturity signals (EPSS, KEV, in-the-wild reports) into a unified maturity level (e.g., POC/Active/Weaponized)
|
||||
- Exploit maturity lifecycle tracking over time
|
||||
- Integration of in-the-wild exploitation reports beyond KEV
|
||||
|
||||
## Implementation Plan
|
||||
- Create unified exploit maturity service that combines EPSS, KEV, and in-the-wild signals
|
||||
- Define maturity level taxonomy (POC/Active/Weaponized)
|
||||
- Expose maturity level in finding detail UI
|
||||
|
||||
## Source
|
||||
- Feature matrix scan
|
||||
@@ -0,0 +1,58 @@
|
||||
# SBOM Lineage Graph Visualization
|
||||
|
||||
## Module
|
||||
SbomService
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
SBOM lineage graph with Git-like visualization. Architecture fully documented, UI components mostly built, but API endpoints not implemented and services use stubs.
|
||||
|
||||
## What's Implemented
|
||||
- **Backend lineage graph service**: `src/SbomService/StellaOps.SbomService/Services/SbomLineageGraphService.cs`, `ISbomLineageGraphService.cs` -- lineage graph query service
|
||||
- **Lineage controller**: `src/SbomService/StellaOps.SbomService/Controllers/LineageController.cs` -- REST API endpoints for lineage queries
|
||||
- **Compare service**: `src/SbomService/StellaOps.SbomService/Services/LineageCompareService.cs`, `ILineageCompareService.cs` -- diff computation between lineage nodes
|
||||
- **Export service**: `src/SbomService/StellaOps.SbomService/Services/LineageExportService.cs`, `ILineageExportService.cs` -- evidence pack export
|
||||
- **Hover cache**: `src/SbomService/StellaOps.SbomService/Services/LineageHoverCache.cs` -- Valkey-backed hover card caching
|
||||
- **Lineage library**: `src/SbomService/__Libraries/StellaOps.SbomService.Lineage/Services/LineageGraphService.cs`, `ILineageGraphService.cs` -- core lineage graph logic
|
||||
- **Frontend lineage feature** (extensive): `src/Web/StellaOps.Web/src/app/features/lineage/` -- 50+ components including:
|
||||
- Graph rendering: `lineage-graph/lineage-graph.component.ts`, `lineage-graph-container/lineage-graph-container.component.ts`
|
||||
- Node/edge rendering: `lineage-node/lineage-node.component.ts`, `lineage-edge/lineage-edge.component.ts`
|
||||
- Hover cards: `lineage-hover-card/lineage-hover-card.component.ts`
|
||||
- Timeline: `lineage-timeline-slider/lineage-timeline-slider.component.ts`, `timeline-slider/timeline-slider.component.ts`
|
||||
- Diff views: `lineage-sbom-diff/lineage-sbom-diff.component.ts`, `lineage-vex-diff/lineage-vex-diff.component.ts`, `lineage-component-diff/lineage-component-diff.component.ts`
|
||||
- Compare: `lineage-compare/lineage-compare.component.ts`, `lineage-compare-panel/lineage-compare-panel.component.ts`, `compare-panel/compare-panel.component.ts`
|
||||
- Detail panel: `lineage-detail-panel/lineage-detail-panel.component.ts`
|
||||
- Controls/minimap: `lineage-controls/lineage-controls.component.ts`, `lineage-minimap/lineage-minimap.component.ts`
|
||||
- Export: `lineage-export-buttons/lineage-export-buttons.component.ts`, `lineage-export-dialog/lineage-export-dialog.component.ts`
|
||||
- Why-safe panel: `why-safe-panel/why-safe-panel.component.ts`, `lineage-why-safe-panel/lineage-why-safe-panel.component.ts`
|
||||
- Provenance: `lineage-provenance-compare/lineage-provenance-compare.component.ts`, `lineage-provenance-chips/lineage-provenance-chips.component.ts`
|
||||
- Accessibility: `lineage-accessibility.scss`, directives for keyboard shortcuts and accessibility
|
||||
- Mobile support: `lineage-mobile-compare/lineage-mobile-compare.component.ts`, `lineage-mobile.styles.ts`
|
||||
- Services: `lineage-graph.service.ts`, `lineage-export.service.ts`
|
||||
- Routing: `lineage.routes.ts`, `lineage-compare-routing.guard.ts`
|
||||
- Integration docs: `INTEGRATION_GUIDE.md`, `LINEAGE_API_INTEGRATION.md`
|
||||
- Audit pack: `audit-pack-export/audit-pack-export.component.ts`, `export-options`, `merkle-display`, `signing-options`
|
||||
- Explainer: `explainer-timeline/explainer-timeline.component.ts`, `explainer-step/explainer-step.component.ts`
|
||||
- Badges: `cgs-badge/cgs-badge.component.ts`, `attestation-links/attestation-links.component.ts`
|
||||
- Diff table: `diff-table/diff-table.component.ts`
|
||||
- Services: `audit-pack.service.ts`, `explainer.service.ts`
|
||||
- **Tests**: `src/SbomService/__Tests/StellaOps.SbomService.Tests/Lineage/LineageDeterminismTests.cs`, `src/SbomService/__Tests/StellaOps.SbomService.Lineage.Tests/Domain/LineageModelsTests.cs`
|
||||
- Source: Feature matrix scan
|
||||
|
||||
## What's Missing
|
||||
- Backend API endpoints may still use stub/in-memory data for some queries (full PostgreSQL-backed graph traversal for all operations)
|
||||
- Real-time lineage update via WebSocket/SSE not confirmed
|
||||
- Performance optimization for large lineage graphs (hundreds of nodes)
|
||||
|
||||
## Implementation Plan
|
||||
- Verify all lineage API endpoints return live PostgreSQL data (not stubs)
|
||||
- Ensure graph traversal queries perform efficiently at scale
|
||||
- Add E2E tests covering full backend-frontend integration
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
|
||||
## Merged From
|
||||
- `web/sbom-lineage-lane-view.md` (deleted -- frontend-only subset of this feature)
|
||||
@@ -0,0 +1,48 @@
|
||||
# Ground-Truth Corpus with Reachability Tiers (R0-R4)
|
||||
|
||||
## Module
|
||||
Scanner
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
A curated corpus of small service applications ("toys") with manually-labeled reachability tiers (R0-R4) for every known vulnerability, enabling precision/recall measurement of the scanner's reachability analysis engine. Each toy service contains a known vulnerability at a specific reachability tier, with a labels.yaml defining the ground truth.
|
||||
|
||||
## What's Implemented
|
||||
- **Golden Fixture Tests**:
|
||||
- `src/Scanner/__Tests/StellaOps.Scanner.SmartDiff.Tests/` - Golden fixture tests comparing scanner output against expected results for diff-aware rescanning scenarios
|
||||
- `src/Scanner/__Tests/StellaOps.Scanner.Reachability.Tests/` - Reachability analysis tests with frozen call-graph fixtures and expected reachability classifications
|
||||
- **Reachability Tier Infrastructure**:
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Reachability/Slices/ReachabilitySlice.cs` - `ReachabilitySlice` model with confidence tiers (Confirmed, Likely, Present, Unreachable) used for classification
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Reachability/Surfaces/SurfaceAwareReachabilityAnalyzer.cs` - `SurfaceAwareReachabilityAnalyzer` performing reachability classification with boundary extractors
|
||||
- **Determinism Tests**:
|
||||
- Existing test infrastructure uses frozen JSON fixtures as inputs with expected output assertions, demonstrating the pattern needed for ground-truth corpus tests
|
||||
|
||||
## What's Missing
|
||||
- **Toy Service Corpus**: No `/toys/svc-XX-<name>/` directory structure containing small service applications with known vulnerabilities at specific reachability tiers
|
||||
- **labels.yaml Schema**: No `labels.yaml` file per toy service defining ground-truth reachability tier (R0=unreachable, R1=present-in-dependency, R2=imported-not-called, R3=called-not-reachable-from-entrypoint, R4=reachable-from-entrypoint) for each CVE
|
||||
- **Precision/Recall Measurement**: No test harness that runs the scanner against the corpus and computes precision, recall, and F1 score per reachability tier
|
||||
- **Corpus CI Job**: No dedicated CI job that runs corpus evaluation and fails on regression (precision/recall drop below threshold)
|
||||
- **Multi-Language Coverage**: Corpus should cover at least Java, Node.js, Python, Go, .NET, and Ruby to validate per-language call-graph extractors
|
||||
|
||||
## Implementation Plan
|
||||
1. Create `/toys/` directory with initial toy services: `svc-01-log4shell-java/`, `svc-02-prototype-pollution-node/`, `svc-03-pickle-deserialization-python/`, `svc-04-text-template-go/`, `svc-05-xmlserializer-dotnet/`, `svc-06-erb-injection-ruby/`
|
||||
2. For each toy service, create minimal source code with a known CVE at a specific reachability tier
|
||||
3. Create `labels.yaml` per service with CVE ID, expected reachability tier (R0-R4), and human explanation
|
||||
4. Create `StellaOps.Scanner.GroundTruth.Tests` project with a corpus runner that scans each toy service, extracts reachability classifications, and compares against labels.yaml
|
||||
5. Implement precision/recall/F1 computation per tier and per language
|
||||
6. Add CI job `scanner-ground-truth` that fails on regression below configurable thresholds
|
||||
7. Document corpus contribution guidelines for adding new toy services
|
||||
|
||||
## E2E Test Plan
|
||||
- [ ] Scan `svc-01-log4shell-java/` and verify the scanner classifies CVE-2021-44228 at the expected reachability tier from labels.yaml
|
||||
- [ ] Scan all toy services and verify precision >= 90% and recall >= 85% across all reachability tiers
|
||||
- [ ] Verify the corpus runner produces a summary report with per-tier and per-language precision/recall/F1 scores
|
||||
- [ ] Verify adding a new toy service with labels.yaml is automatically picked up by the corpus runner without code changes
|
||||
- [ ] Verify the CI job fails when a scanner change causes precision or recall to drop below the configured threshold
|
||||
- [ ] Verify the corpus covers at least 3 different languages and all 5 reachability tiers (R0-R4)
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
- Architecture: `docs/modules/scanner/architecture.md`
|
||||
@@ -0,0 +1,50 @@
|
||||
# Idempotent Attestation Submission
|
||||
|
||||
## Module
|
||||
Scanner
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Ensures that attestation submissions (verdict push to OCI registry, Rekor transparency log entries) are idempotent: resubmitting the same attestation produces no duplicate entries and returns the existing entry reference. Handles transient failures with retry logic that avoids creating duplicate transparency log entries.
|
||||
|
||||
## What's Implemented
|
||||
- **Verdict Push Stage**:
|
||||
- `src/Scanner/StellaOps.Scanner.Worker/Processing/VerdictPushStageExecutor.cs` - `VerdictPushStageExecutor` scan pipeline stage that pushes signed verdict attestations to the OCI registry and triggers downstream evidence publication
|
||||
- **OCI Verdict Publishing**:
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Storage.Oci/VerdictOciPublisher.cs` - `VerdictOciPublisher` publishing signed verdict DSSE envelopes to OCI registries as attestation artifacts
|
||||
- **Rekor Integration**:
|
||||
- `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Rekor/EnhancedRekorProofBuilder.Build.cs` - Builds Rekor inclusion proofs for attestations
|
||||
- `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Rekor/EnhancedRekorProofBuilder.Validate.cs` - Validates Rekor inclusion proofs
|
||||
- `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Pipeline/RekorEntry.cs` - `RekorEntry` model for transparency log entries
|
||||
- **Evidence Pipeline**:
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Evidence/` - Evidence collection and bundling infrastructure
|
||||
|
||||
## What's Missing
|
||||
- **Idempotency Key Generation**: No content-addressed idempotency key derived from attestation payload hash to detect duplicate submissions before sending to Rekor
|
||||
- **Rekor Duplicate Detection**: No pre-submission check against Rekor search API to verify whether an attestation with the same content hash already exists in the log
|
||||
- **Retry with Deduplication**: `VerdictPushStageExecutor` lacks explicit retry logic that distinguishes between "already submitted" (success) and "transient failure" (retry) responses from Rekor/OCI
|
||||
- **OCI Tag Idempotency**: `VerdictOciPublisher` does not check for existing attestation tags before pushing, potentially creating duplicate OCI artifacts
|
||||
- **Submission Receipt Cache**: No local cache of recently-submitted attestation hashes to short-circuit redundant submissions within the same scan session
|
||||
|
||||
## Implementation Plan
|
||||
1. Add `AttestationIdempotencyKey` generation in `StellaOps.Scanner.Evidence` using SHA-256 of the canonical DSSE envelope payload
|
||||
2. Add Rekor search-by-hash pre-check in `EnhancedRekorProofBuilder` before submitting new entries
|
||||
3. Add retry policy to `VerdictPushStageExecutor` with idempotency-aware error classification (409 Conflict = success, 5xx = retry, 4xx = fail)
|
||||
4. Add OCI manifest existence check in `VerdictOciPublisher` before pushing attestation artifacts
|
||||
5. Add in-memory submission receipt cache with TTL for short-circuiting redundant submissions
|
||||
6. Add unit tests for idempotency key generation, duplicate detection, and retry classification
|
||||
|
||||
## E2E Test Plan
|
||||
- [ ] Submit a verdict attestation to Rekor and verify a log entry is created with correct content hash
|
||||
- [ ] Resubmit the same attestation and verify no duplicate Rekor entry is created; the existing entry reference is returned
|
||||
- [ ] Simulate a transient Rekor failure (503) during submission and verify the retry logic resubmits successfully without creating duplicates
|
||||
- [ ] Push a verdict attestation to OCI and verify the artifact tag is created
|
||||
- [ ] Re-push the same attestation to OCI and verify no duplicate artifact is created
|
||||
- [ ] Verify the idempotency key is deterministically derived from the DSSE envelope payload (same payload = same key across scanner instances)
|
||||
- [ ] Verify the submission receipt cache prevents redundant network calls for attestations submitted within the same scan session
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
- Architecture: `docs/modules/scanner/architecture.md`
|
||||
@@ -0,0 +1,55 @@
|
||||
# Stack-Trace/Exploit Path View
|
||||
|
||||
## Module
|
||||
Scanner
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
A dedicated "Stack-Trace Lens" UX component that renders exploit paths as interactive stack-trace visualizations, allowing security engineers to trace the call chain from entrypoint to vulnerable function. Combines backend exploit path grouping with a frontend visualization component.
|
||||
|
||||
## What's Implemented
|
||||
- **Exploit Path Grouping (Backend)**:
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Triage/Services/IExploitPathGroupingService.cs` - `IExploitPathGroupingService` interface for grouping triage findings by their exploit path similarity
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Triage/Models/ExploitPath.cs` - `ExploitPath` model representing a call chain from entrypoint to vulnerable function
|
||||
- **Path Explanation (Backend)**:
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Reachability/Explanation/PathExplanationService.cs` - `PathExplanationService` generating human-readable explanations of reachability paths
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Reachability/Explanation/PathRenderer.cs` - `PathRenderer` rendering call-graph paths as structured output (text, JSON, diagram-ready format)
|
||||
- **Triage API**:
|
||||
- `src/Scanner/StellaOps.Scanner.WebService/Endpoints/Triage/TriageInboxEndpoints.cs` - `TriageInboxEndpoints` REST API serving triage findings with exploit path data to frontend consumers
|
||||
- **Call Path Models**:
|
||||
- `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Statements/WitnessCallPathNode.cs` - `WitnessCallPathNode` model for individual nodes in a call path
|
||||
- `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Statements/WitnessPathNode.cs` - `WitnessPathNode` model for path traversal nodes
|
||||
|
||||
## What's Missing
|
||||
- **Stack-Trace Lens UI Component**: No dedicated Angular component in `src/Web/` that renders exploit paths as interactive stack-trace visualizations with:
|
||||
- Collapsible call-chain frames (entrypoint -> intermediate calls -> vulnerable function)
|
||||
- Syntax-highlighted source snippets at each frame (when source mapping is available)
|
||||
- Reachability tier badge per frame (Confirmed/Likely/Present)
|
||||
- Click-to-expand frame details (file path, line number, function signature)
|
||||
- **Path Comparison View**: No side-by-side comparison of multiple exploit paths reaching the same vulnerable function from different entrypoints
|
||||
- **Path Sharing/Export**: No URL-addressable deep links to specific exploit paths for sharing in issue trackers
|
||||
- **Path Filtering**: No filtering of exploit paths by reachability confidence, entrypoint type, or path length
|
||||
|
||||
## Implementation Plan
|
||||
1. Create `ExploitPathViewComponent` in `src/Web/` as an Angular component consuming the TriageInboxEndpoints exploit path API
|
||||
2. Implement collapsible stack-frame rendering with entrypoint -> call chain -> sink visualization
|
||||
3. Add source snippet rendering using source-map data when available from the scanner
|
||||
4. Add reachability tier badges per frame using the PathExplanationService output
|
||||
5. Implement path comparison view for vulnerabilities with multiple exploit paths
|
||||
6. Add deep-link URL routing for direct navigation to specific exploit paths
|
||||
7. Add path filtering controls (confidence tier, entrypoint type, path length)
|
||||
|
||||
## E2E Test Plan
|
||||
- [ ] Navigate to a triage finding with a known exploit path and verify the Stack-Trace Lens component renders the full call chain from entrypoint to vulnerable function
|
||||
- [ ] Verify each frame in the stack trace shows the correct function signature, file path, and reachability tier badge
|
||||
- [ ] Click to expand a frame and verify source snippet is displayed (when source mapping is available)
|
||||
- [ ] Verify collapsing intermediate frames hides call chain details while keeping entrypoint and sink visible
|
||||
- [ ] Open the path comparison view for a vulnerability with multiple exploit paths and verify side-by-side rendering
|
||||
- [ ] Copy the deep link URL for a specific exploit path, navigate to it in a new browser tab, and verify the same path is displayed
|
||||
- [ ] Apply path filtering by reachability confidence and verify only paths matching the selected tier are shown
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
- Architecture: `docs/modules/scanner/architecture.md`
|
||||
@@ -0,0 +1,51 @@
|
||||
# VEX Decision Filter with Reachability
|
||||
|
||||
## Module
|
||||
Scanner
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
A dedicated reachability-aware VEX decision filter that combines VEX consensus data (from VexLens) with reachability classification to produce filtered vulnerability lists. Findings with "not_affected" VEX status and "unreachable" reachability classification are automatically suppressed, while findings with "exploitable" VEX status and "confirmed reachable" classification are elevated.
|
||||
|
||||
## What's Implemented
|
||||
- **VEX Integration**:
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.ChangeTrace/Integration/IVexLensClient.cs` - `IVexLensClient` interface for querying VEX consensus data from the VexLens service
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.ChangeTrace/TrustDeltaCalculator.cs` - `TrustDeltaCalculator` computing trust deltas that incorporate VEX status changes
|
||||
- **VEX Gate Service**:
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Gate/VexGateService.cs` - `VexGateService` pre-triage VEX gating with Pass/Warn/Block decisions based on VEX status
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Gate/VexGatePolicyEvaluator.cs` - `VexGatePolicyEvaluator` evaluating gate rules (block-exploitable-reachable, pass-vendor-not-affected, etc.)
|
||||
- **Reachability Classification**:
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Reachability/Slices/ReachabilitySlice.cs` - `ReachabilitySlice` with confidence tiers (Confirmed, Likely, Present, Unreachable)
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Reachability/Surfaces/SurfaceAwareReachabilityAnalyzer.cs` - `SurfaceAwareReachabilityAnalyzer` performing reachability classification
|
||||
- **Triage Queries**:
|
||||
- `src/Scanner/StellaOps.Scanner.WebService/Endpoints/Triage/TriageInboxEndpoints.cs` - Triage API returning findings that incorporate reachability data
|
||||
|
||||
## What's Missing
|
||||
- **Dedicated VEX+Reachability Filter Component**: No standalone `VexReachabilityDecisionFilter` that combines VEX consensus status with reachability classification into a single filtering decision (the current VexGateService evaluates VEX rules but does not deeply integrate reachability slice confidence tiers)
|
||||
- **Combined Score Matrix**: No explicit decision matrix mapping (VEX status x Reachability tier) -> filter action (suppress, elevate, pass-through, flag-for-review)
|
||||
- **Filter API Endpoint**: No REST endpoint that accepts a list of findings and returns the filtered list with VEX+reachability decision annotations
|
||||
- **Filter Audit Trail**: No audit logging of VEX+reachability filter decisions separate from the VEX gate audit trail
|
||||
- **Reachability-Weighted VEX Override**: No logic for reachability to override VEX decisions (e.g., vendor says "not_affected" but scanner detects confirmed reachable call path)
|
||||
|
||||
## Implementation Plan
|
||||
1. Create `VexReachabilityDecisionFilter` in `StellaOps.Scanner.Gate` or a new `StellaOps.Scanner.VexFilter` library that combines `IVexLensClient` data with `ReachabilitySlice` classification
|
||||
2. Define decision matrix: (not_affected + Unreachable) -> suppress, (exploitable + Confirmed) -> elevate, (not_affected + Confirmed) -> flag-for-review, etc.
|
||||
3. Add `VexReachabilityFilterEndpoints` in `StellaOps.Scanner.WebService` for querying filtered finding lists
|
||||
4. Add audit logging for filter decisions with VEX source, reachability tier, and resulting action
|
||||
5. Implement reachability override logic: when reachability contradicts VEX status, flag the finding for human review
|
||||
6. Add unit tests for all cells in the decision matrix
|
||||
|
||||
## E2E Test Plan
|
||||
- [ ] Submit a finding with VEX "not_affected" and reachability "Unreachable" and verify the filter suppresses it
|
||||
- [ ] Submit a finding with VEX "exploitable" and reachability "Confirmed" and verify the filter elevates it with highest priority
|
||||
- [ ] Submit a finding with VEX "not_affected" but reachability "Confirmed" (contradiction) and verify the filter flags it for human review
|
||||
- [ ] Submit a finding with no VEX data and reachability "Likely" and verify the filter passes it through with reachability-only annotation
|
||||
- [ ] Query the filter API endpoint with a batch of 50 findings and verify the response includes correct filter actions and decision annotations for each
|
||||
- [ ] Verify the audit trail captures each filter decision with VEX source, reachability tier, decision matrix cell, and timestamp
|
||||
- [ ] Verify the filter correctly handles findings where reachability data is unavailable (falls back to VEX-only decision)
|
||||
|
||||
## Related Documentation
|
||||
- Source: See feature catalog
|
||||
- Architecture: `docs/modules/scanner/architecture.md`
|
||||
@@ -0,0 +1,65 @@
|
||||
# Vulnerability-First Triage UX with Exploit Path Grouping and Proof Bundles
|
||||
|
||||
## Module
|
||||
Scanner (with Attestor proof bundle integration)
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
A vulnerability-first triage inbox where findings are grouped by exploit path similarity rather than by CVE or component. Security engineers see clusters of findings that share the same attack vector (entrypoint -> call chain -> sink), enabling batch triage. Backend triage service with DB context, reachability subgraph extraction, exploit path grouping, and proof generation exist. UI triage inbox and queue components are partially complete.
|
||||
|
||||
## What's Implemented
|
||||
- **Exploit Path Grouping (Backend)**:
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Triage/Services/IExploitPathGroupingService.cs` -- interface grouping findings by exploit path similarity
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Triage/Models/ExploitPath.cs` -- call chain from entrypoint to vulnerable function
|
||||
- `src/Scanner/__Tests/StellaOps.Scanner.Triage.Tests/` -- unit tests for exploit path grouping logic
|
||||
- **Triage Database and API**:
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Triage/Entities/TriageDbContext.cs` -- EF Core database context
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Triage/Entities/TriageFinding.cs` -- finding entity with reachability classification and exploit path reference
|
||||
- `src/Scanner/StellaOps.Scanner.WebService/Endpoints/Triage/TriageInboxEndpoints.cs` -- REST API with exploit path grouping support
|
||||
- **Triage Lanes**: `TriageEnums.cs` -- ACTIVE, BLOCKED, MUTED_REACH, MUTED_VEX
|
||||
- **Triage Status Service**: `TriageStatusService.cs` -- state transitions across lanes
|
||||
- **Evidence Integration**: `ProofBundleEndpoints.cs` -- evidence bundles for triage decisions
|
||||
- **Proof Graph Service**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Graph/InMemoryProofGraphService.cs` (with `.Mutation`, `.Queries`, `.Subgraph`) -- proof graph with subgraph extraction for evidence grouping
|
||||
- **Micro Witness Evidence**: `MicroWitnessFunctionEvidence.cs`, `MicroWitnessBinaryRef.cs`, `MicroWitnessCveRef.cs` -- function-level reachability evidence
|
||||
- **Reachability Witness Payload**: `ReachabilityWitnessPayload.cs` (with `.Path`), `WitnessCallPathNode.cs` -- witness payload with exploit call paths
|
||||
- **Proof Spine System**: `ProofSpineRequest.cs`, `ProofSpineResult.cs` -- proof spine for evidence bundle assembly
|
||||
- **Sigstore/Evidence Pack Builders**: `SigstoreBundleBuilder.cs`, `ReleaseEvidencePackBuilder.cs` -- builds proof bundles
|
||||
|
||||
## What's Missing
|
||||
- **Triage Inbox UI Component**: No Angular component implementing the vulnerability-first triage inbox with exploit path cluster view, batch triage actions, cluster expansion, sort/filter by cluster size/severity/reachability
|
||||
- **Exploit Path Similarity Algorithm**: The `IExploitPathGroupingService` interface exists but the clustering/similarity algorithm completeness is unclear
|
||||
- **Batch Triage API**: No REST endpoint for applying a single triage decision to all findings in an exploit path cluster
|
||||
- **Cluster Statistics**: No API endpoint returning per-cluster severity and reachability distributions
|
||||
- **Triage Dashboard**: No dashboard showing triage progress (clusters triaged vs. remaining, MTTR per cluster)
|
||||
- **Triage Action Workflow**: No triage action buttons (accept risk, suppress, escalate, remediate) with DSSE-signed action records
|
||||
- **Triage Priority Scoring**: No scoring that prioritizes vulnerabilities by exploit path depth and reachability confidence
|
||||
- **Inline Proof Bundle Viewer**: No inline viewer showing proof bundle contents (DSSE envelope, Rekor receipt, Merkle proof) within the triage UI
|
||||
|
||||
## Implementation Plan
|
||||
- Complete exploit path similarity algorithm using common call-chain prefix grouping with configurable similarity threshold
|
||||
- Add `BatchTriageEndpoints` for applying triage decisions to entire exploit path clusters
|
||||
- Add cluster statistics endpoint returning per-cluster severity and reachability distributions
|
||||
- Create `TriageInboxComponent` in `src/Web/` with exploit path cluster view, batch actions, and filtering
|
||||
- Implement triage action workflow with DSSE-signed action records
|
||||
- Add triage priority scoring based on path depth and confidence
|
||||
- Build inline proof bundle viewer
|
||||
- Create triage dashboard with progress metrics
|
||||
- Add e2e tests for grouping, triage actions, and batch operations
|
||||
|
||||
## E2E Test Plan
|
||||
- [ ] Open triage inbox and verify findings are grouped by exploit path similarity
|
||||
- [ ] Expand a cluster and verify all individual findings with CVE, severity, and reachability tier
|
||||
- [ ] Apply batch "mute" action to entire cluster and verify all findings move to MUTED_REACH lane
|
||||
- [ ] Sort clusters by highest severity and verify correct ordering
|
||||
- [ ] Filter clusters by reachability tier "Confirmed"
|
||||
- [ ] Open triage dashboard and verify correct counts
|
||||
- [ ] Verify batch triage API returns correct affected finding count
|
||||
|
||||
## Related Documentation
|
||||
- Triage infrastructure: `src/Scanner/__Libraries/StellaOps.Scanner.Triage/`
|
||||
- Proof graph: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Graph/`
|
||||
|
||||
## Merged From
|
||||
- `attestor/vulnerability-first-triage-ux-with-exploit-path-grouping-and-proof-bundles.md` (deleted)
|
||||
22
docs/features/unchecked/telemetry/dora-metrics.md
Normal file
22
docs/features/unchecked/telemetry/dora-metrics.md
Normal file
@@ -0,0 +1,22 @@
|
||||
# DORA Metrics
|
||||
|
||||
## Status
|
||||
NOT_FOUND
|
||||
|
||||
## Description
|
||||
No DORA metrics implementation found in the frontend or backend source code.
|
||||
|
||||
## Why Not Implemented
|
||||
- No DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR) implementation found
|
||||
- Search for DORA-related terms found only `EarnedCapacityReplenishment` in `src/Policy/__Libraries/StellaOps.Policy/Gates/` which is a policy gate concept, not DORA metrics
|
||||
- The Telemetry module (`src/Telemetry/`) tracks operational metrics (Time-to-Evidence, attestation metrics) but not standard DORA metrics
|
||||
- No DORA dashboard or reporting found in the Web UI
|
||||
- This appears to be a genuinely deferred feature with no partial implementation
|
||||
|
||||
## Source
|
||||
- Feature matrix scan
|
||||
|
||||
## Notes
|
||||
- Module: Uncategorized
|
||||
- Modules referenced: N/A
|
||||
- The Telemetry module could serve as a foundation for DORA metrics if implemented
|
||||
@@ -0,0 +1,23 @@
|
||||
# Outcome Analytics / Attribution
|
||||
|
||||
## Status
|
||||
NOT_FOUND
|
||||
|
||||
## Description
|
||||
The advisory's vision for outcome analytics with MTTR/MTTA attribution, cohort analysis, and executive reporting is not yet implemented.
|
||||
|
||||
## Why Not Implemented
|
||||
- No outcome analytics, MTTR/MTTA attribution, cohort analysis, or executive reporting found in `src/`
|
||||
- No `OutcomeAnalytics` or `Attribution` modules or namespaces exist
|
||||
- The Telemetry module (`src/Telemetry/`) tracks operational metrics but not outcome attribution
|
||||
- The Signals module provides unified scoring but not outcome/attribution analytics
|
||||
- This appears to be a genuinely deferred feature with no partial implementation
|
||||
- Would require significant new infrastructure for tracking remediation outcomes over time
|
||||
|
||||
## Source
|
||||
- Feature matrix scan
|
||||
|
||||
## Notes
|
||||
- Module: Uncategorized
|
||||
- Modules referenced: N/A
|
||||
- Could build on Telemetry (`src/Telemetry/`) and Timeline (`src/Timeline/`) infrastructure when implemented
|
||||
27
docs/features/unchecked/vexlens/vexlens-truth-table-tests.md
Normal file
27
docs/features/unchecked/vexlens/vexlens-truth-table-tests.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# VexLens Truth Table Tests
|
||||
|
||||
## Status
|
||||
NOT_FOUND
|
||||
|
||||
## Description
|
||||
Systematic truth table tests for VEX lattice merge correctness. The VexLens engine exists but comprehensive truth table test coverage is missing.
|
||||
|
||||
## Why Not Implemented
|
||||
- No systematic truth table tests for VEX lattice merge correctness found
|
||||
- The VexLens test infrastructure does exist:
|
||||
- `src/VexLens/__Tests/StellaOps.VexLens.Tests/` -- VexLens tests project
|
||||
- `src/VexLens/StellaOps.VexLens/__Tests/StellaOps.VexLens.Tests/` -- additional test project
|
||||
- `src/VexLens/StellaOps.VexLens/__Tests/StellaOps.VexLens.Core.Tests/` -- core tests
|
||||
- Tests cover: `NormalizerTests`, `PurlParserTests`, `ProductMapperTests`, `CpeParserTests`
|
||||
- `src/VexLens/__Libraries/__Tests/StellaOps.VexLens.Spdx3.Tests/` -- SPDX3 integration tests
|
||||
- The VexLens engine has merge logic (consensus projections, delta computation) but does not have exhaustive truth table tests covering all VEX status transition combinations
|
||||
- TASKS.md files in test directories indicate planned but incomplete test coverage
|
||||
- The advisory called for systematic coverage of all status pairs (affected/not_affected/fixed/under_investigation x all transitions)
|
||||
|
||||
## Source
|
||||
- Feature matrix scan
|
||||
|
||||
## Notes
|
||||
- Module: VexLens
|
||||
- Modules referenced: `src/VexLens`
|
||||
- Related: `src/VexLens/__Tests/` (existing tests cover parsing/mapping but not exhaustive lattice merge truth tables)
|
||||
@@ -0,0 +1,53 @@
|
||||
# Audit Trail "Why am I seeing this?" (Reason Capsule)
|
||||
|
||||
## Module
|
||||
Web
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
The advisory proposed a ReasonCapsuleComponent with per-row expandable explanations showing policy name, rule ID, graph revision ID, and inputs digest. Instead, verdict explanation is implemented via VerdictWhySummaryComponent (3-5 bullet driver explanations with evidence drill-down links) and WhySafePanels in the lineage feature. The exact ReasonCapsuleComponent name and API contract (/api/audit/reasons/:verdictId) were not found, but the concept is substantially realized under different component names.
|
||||
|
||||
## What's Implemented
|
||||
- **Existing components**:
|
||||
- `ai-code-guard-badge` (`src/Web/StellaOps.Web/src/app/features/triage/components/ai-code-guard-badge/ai-code-guard-badge.component.ts`)
|
||||
- `ai-recommendation-panel` (`src/Web/StellaOps.Web/src/app/features/triage/components/ai-recommendation-panel/ai-recommendation-panel.component.ts`)
|
||||
- `attestation-viewer` (`src/Web/StellaOps.Web/src/app/features/triage/components/attestation-viewer/attestation-viewer.component.ts`)
|
||||
- `bulk-action-modal` (`src/Web/StellaOps.Web/src/app/features/triage/components/bulk-action-modal/bulk-action-modal.component.ts`)
|
||||
- `case-header` (`src/Web/StellaOps.Web/src/app/features/triage/components/case-header/case-header.component.ts`)
|
||||
- `decision-drawer-enhanced` (`src/Web/StellaOps.Web/src/app/features/triage/components/decision-drawer/decision-drawer-enhanced.component.ts`)
|
||||
- `decision-drawer` (`src/Web/StellaOps.Web/src/app/features/triage/components/decision-drawer/decision-drawer.component.ts`)
|
||||
- `attestation-chain` (`src/Web/StellaOps.Web/src/app/features/triage/components/evidence-panel/attestation-chain.component.ts`)
|
||||
- `backport-verdict-badge` (`src/Web/StellaOps.Web/src/app/features/triage/components/evidence-panel/backport-verdict-badge.component.ts`)
|
||||
- `binary-diff-tab` (`src/Web/StellaOps.Web/src/app/features/triage/components/evidence-panel/binary-diff-tab.component.ts`)
|
||||
- **Existing services**:
|
||||
- `advisory-ai` (`src/Web/StellaOps.Web/src/app/features/triage/services/advisory-ai.service.ts`)
|
||||
- `binary-diff-evidence` (`src/Web/StellaOps.Web/src/app/features/triage/services/binary-diff-evidence.service.ts`)
|
||||
- `diff-evidence` (`src/Web/StellaOps.Web/src/app/features/triage/services/diff-evidence.service.ts`)
|
||||
- `display-preferences` (`src/Web/StellaOps.Web/src/app/features/triage/services/display-preferences.service.ts`)
|
||||
- `evidence-tab` (`src/Web/StellaOps.Web/src/app/features/triage/services/evidence-tab.service.ts`)
|
||||
|
||||
## What's Missing
|
||||
- **ReasonCapsuleComponent**: No per-row expandable component showing policy name, rule ID, graph revision ID, and inputs digest for each finding/verdict in table views
|
||||
- **Audit reasons API**: No `/api/audit/reasons/:verdictId` endpoint returning structured reason data for display
|
||||
- **Per-finding explanation inline**: VerdictWhySummaryComponent and WhySafePanels exist for verdict-level and lineage-level explanation, but no per-row inline "why" capsule in triage table views
|
||||
|
||||
## Implementation Plan
|
||||
- Create `ReasonCapsuleComponent` as expandable per-row explanation in triage/finding tables
|
||||
- Add `/api/audit/reasons/:verdictId` endpoint returning policy name, rule ID, graph revision, inputs digest
|
||||
- Wire capsule into triage table views for inline "why am I seeing this" explanation
|
||||
|
||||
## E2E Test Plan
|
||||
- **Setup**:
|
||||
- [ ] Log in with a user that has appropriate permissions
|
||||
- [ ] Navigate to `/triage/artifacts`
|
||||
- [ ] Ensure test data exists (scanned artifacts, SBOM data, or seed data as needed)
|
||||
- **Core verification**:
|
||||
- [ ] Verify the component renders correctly with sample data
|
||||
- [ ] Verify interactive elements respond to user input
|
||||
- [ ] Verify data is fetched and displayed from the correct API endpoints
|
||||
- **Edge cases**:
|
||||
- [ ] Verify graceful handling when backend API is unavailable (error state)
|
||||
- [ ] Verify responsive layout at different viewport sizes
|
||||
- [ ] Verify accessibility (keyboard navigation, screen reader labels, ARIA attributes)
|
||||
54
docs/features/unchecked/web/pack-registry-browser.md
Normal file
54
docs/features/unchecked/web/pack-registry-browser.md
Normal file
@@ -0,0 +1,54 @@
|
||||
# Pack Registry Browser
|
||||
|
||||
## Module
|
||||
Web
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
TaskRunner pack discovery and management with install/upgrade flows, compatibility checking, version history with changelogs, signature verification, and dependency graph. API client and models exist but dedicated feature module not found.
|
||||
|
||||
## What's Implemented
|
||||
- **Existing components**:
|
||||
- `conflict-visualizer` (`src/Web/StellaOps.Web/src/app/features/policy-studio/ai/conflict-visualizer.component.ts`)
|
||||
- `live-rule-preview` (`src/Web/StellaOps.Web/src/app/features/policy-studio/ai/live-rule-preview.component.ts`)
|
||||
- `test-case-panel` (`src/Web/StellaOps.Web/src/app/features/policy-studio/ai/test-case-panel.component.ts`)
|
||||
- `version-history` (`src/Web/StellaOps.Web/src/app/features/policy-studio/ai/version-history.component.ts`)
|
||||
- `policy-approvals` (`src/Web/StellaOps.Web/src/app/features/policy-studio/approvals/policy-approvals.component.ts`)
|
||||
- `policy-dashboard` (`src/Web/StellaOps.Web/src/app/features/policy-studio/dashboard/policy-dashboard.component.ts`)
|
||||
- `policy-editor` (`src/Web/StellaOps.Web/src/app/features/policy-studio/editor/policy-editor.component.ts`)
|
||||
- `policy-explain` (`src/Web/StellaOps.Web/src/app/features/policy-studio/explain/policy-explain.component.ts`)
|
||||
- `policy-nl-input` (`src/Web/StellaOps.Web/src/app/features/policy-studio/nl-input/policy-nl-input.component.ts`)
|
||||
- `policy-rule-builder` (`src/Web/StellaOps.Web/src/app/features/policy-studio/rule-builder/policy-rule-builder.component.ts`)
|
||||
- **Existing services**:
|
||||
- `monaco-loader` (`src/Web/StellaOps.Web/src/app/features/policy-studio/editor/monaco-loader.service.ts`)
|
||||
- `policy-api` (`src/Web/StellaOps.Web/src/app/features/policy-studio/services/policy-api.service.ts`)
|
||||
|
||||
## What's Missing
|
||||
- **Pack browser feature module**: No dedicated Angular feature module for browsing the TaskRunner pack registry (installed packs, available packs, version history)
|
||||
- **Pack install/upgrade flow**: No UI flow for installing or upgrading TaskRunner packs with compatibility checks
|
||||
- **Pack signature verification display**: No UI showing DSSE signature verification status for each pack
|
||||
- **Pack dependency graph**: No visual dependency graph for pack dependencies
|
||||
- **Pack changelog viewer**: No version history with changelog rendering per pack
|
||||
|
||||
## Implementation Plan
|
||||
- Create `pack-registry` Angular feature module under `src/Web/StellaOps.Web/src/app/features/`
|
||||
- Implement pack list view with install/upgrade actions
|
||||
- Add signature verification status badge per pack
|
||||
- Add version history/changelog component
|
||||
- Wire to TaskRunner pack management API endpoints
|
||||
|
||||
## E2E Test Plan
|
||||
- **Setup**:
|
||||
- [ ] Log in with a user that has appropriate permissions
|
||||
- [ ] Navigate to `/policy-studio/packs`
|
||||
- [ ] Ensure test data exists (scanned artifacts, SBOM data, or seed data as needed)
|
||||
- **Core verification**:
|
||||
- [ ] Verify the component renders correctly with sample data
|
||||
- [ ] Verify interactive elements respond to user input
|
||||
- [ ] Verify data is fetched and displayed from the correct API endpoints
|
||||
- **Edge cases**:
|
||||
- [ ] Verify graceful handling when backend API is unavailable (error state)
|
||||
- [ ] Verify responsive layout at different viewport sizes
|
||||
- [ ] Verify accessibility (keyboard navigation, screen reader labels, ARIA attributes)
|
||||
51
docs/features/unchecked/web/pipeline-run-centric-view.md
Normal file
51
docs/features/unchecked/web/pipeline-run-centric-view.md
Normal file
@@ -0,0 +1,51 @@
|
||||
# Pipeline/Run-Centric View
|
||||
|
||||
## Module
|
||||
Web
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Runs feature exists in the frontend with first-signal card components and prefetch services, but a full pipeline-centric view as described in the advisory is only partially present.
|
||||
|
||||
## What's Implemented
|
||||
- **Existing components**:
|
||||
- `approval-detail` (`src/Web/StellaOps.Web/src/app/features/release-orchestrator/approvals/approval-detail/approval-detail.component.ts`)
|
||||
- `approval-queue` (`src/Web/StellaOps.Web/src/app/features/release-orchestrator/approvals/approval-queue/approval-queue.component.ts`)
|
||||
- `promotion-request` (`src/Web/StellaOps.Web/src/app/features/release-orchestrator/approvals/promotion-request/promotion-request.component.ts`)
|
||||
- `active-deployments` (`src/Web/StellaOps.Web/src/app/features/release-orchestrator/dashboard/components/active-deployments/active-deployments.component.ts`)
|
||||
- `pending-approvals` (`src/Web/StellaOps.Web/src/app/features/release-orchestrator/dashboard/components/pending-approvals/pending-approvals.component.ts`)
|
||||
- `pipeline-overview` (`src/Web/StellaOps.Web/src/app/features/release-orchestrator/dashboard/components/pipeline-overview/pipeline-overview.component.ts`)
|
||||
- `recent-releases` (`src/Web/StellaOps.Web/src/app/features/release-orchestrator/dashboard/components/recent-releases/recent-releases.component.ts`)
|
||||
- `dashboard` (`src/Web/StellaOps.Web/src/app/features/release-orchestrator/dashboard/dashboard.component.ts`)
|
||||
- `deployment-list` (`src/Web/StellaOps.Web/src/app/features/release-orchestrator/deployments/deployment-list/deployment-list.component.ts`)
|
||||
- `deployment-monitor` (`src/Web/StellaOps.Web/src/app/features/release-orchestrator/deployments/deployment-monitor/deployment-monitor.component.ts`)
|
||||
- **Existing routes**: `approvals.routes.ts`, `dashboard.routes.ts`, `deployments.routes.ts`, `environments.routes.ts`, `evidence.routes.ts`, `releases.routes.ts`, `workflows.routes.ts`
|
||||
|
||||
## What's Missing
|
||||
- **Pipeline run detail view**: No dedicated "run detail" view showing a single pipeline execution with its stages, gates, evidence collection, and outcome
|
||||
- **Run-centric navigation**: Components exist for approvals, deployments, and releases but no unified "runs" listing that ties them together as a single pipeline execution
|
||||
- **First-signal card integration**: First-signal card components exist in the `runs/` feature but may not be integrated into the pipeline-centric view
|
||||
- **Backend API wiring**: Dashboard components may use stub/mock data pending backend endpoint integration
|
||||
- **Unit/E2E test coverage**: Components likely lack comprehensive test coverage
|
||||
|
||||
## Implementation Plan
|
||||
- Create a unified "pipeline run" detail view connecting scan, gate evaluation, approval, and deployment stages
|
||||
- Wire pipeline-overview component to backend API for live pipeline status
|
||||
- Add run-centric navigation linking approval, deployment, and evidence views
|
||||
- Add unit and E2E test coverage for pipeline dashboard components
|
||||
|
||||
## E2E Test Plan
|
||||
- **Setup**:
|
||||
- [ ] Log in with a user that has appropriate permissions
|
||||
- [ ] Navigate to `/release-orchestrator`
|
||||
- [ ] Ensure test data exists (scanned artifacts, SBOM data, or seed data as needed)
|
||||
- **Core verification**:
|
||||
- [ ] Verify the component renders correctly with sample data
|
||||
- [ ] Verify interactive elements respond to user input
|
||||
- [ ] Verify data is fetched and displayed from the correct API endpoints
|
||||
- **Edge cases**:
|
||||
- [ ] Verify graceful handling when backend API is unavailable (error state)
|
||||
- [ ] Verify responsive layout at different viewport sizes
|
||||
- [ ] Verify accessibility (keyboard navigation, screen reader labels, ARIA attributes)
|
||||
51
docs/features/unchecked/web/reachability-center-ui-view.md
Normal file
51
docs/features/unchecked/web/reachability-center-ui-view.md
Normal file
@@ -0,0 +1,51 @@
|
||||
# Reachability Center UI View
|
||||
|
||||
## Module
|
||||
Web
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Reachability Center view showing asset coverage, missing sensors, and stale reachability facts. Implemented with deterministic fixture data; pending official fixture bundle swap from Signals guild.
|
||||
|
||||
## What's Implemented
|
||||
- **Existing components**:
|
||||
- `path-viewer` (`src/Web/StellaOps.Web/src/app/features/reachability/components/path-viewer/path-viewer.component.ts`)
|
||||
- `risk-drift-card` (`src/Web/StellaOps.Web/src/app/features/reachability/components/risk-drift-card/risk-drift-card.component.ts`)
|
||||
- `poe-drawer` (`src/Web/StellaOps.Web/src/app/features/reachability/poe-drawer.component.ts`)
|
||||
- `reachability-center` (`src/Web/StellaOps.Web/src/app/features/reachability/reachability-center.component.ts`)
|
||||
- `reachability-explain-widget` (`src/Web/StellaOps.Web/src/app/features/reachability/reachability-explain-widget.component.ts`)
|
||||
- `reachability-explain` (`src/Web/StellaOps.Web/src/app/features/reachability/reachability-explain.component.ts`)
|
||||
- `reachability-why-drawer` (`src/Web/StellaOps.Web/src/app/features/reachability/reachability-why-drawer.component.ts`)
|
||||
- `witness-page` (`src/Web/StellaOps.Web/src/app/features/reachability/witness-page.component.ts`)
|
||||
- **Existing services**:
|
||||
- `drift-api` (`src/Web/StellaOps.Web/src/app/features/reachability/services/drift-api.service.ts`)
|
||||
|
||||
## What's Missing
|
||||
- **Official fixture bundle swap**: Currently using deterministic fixture data; pending official fixture bundle from Signals guild with real reachability data
|
||||
- **Asset coverage summary**: No dashboard-level summary showing percentage of assets with reachability analysis coverage
|
||||
- **Missing sensors indicator**: No visual indicator showing which assets lack runtime observation sensors
|
||||
- **Stale facts alerting**: `drift-api.service.ts` exists but no visual alerting when reachability facts become stale
|
||||
- **Unit/E2E test coverage**: Components exist but test coverage may be incomplete
|
||||
|
||||
## Implementation Plan
|
||||
- Swap fixture data for live API integration once Signals guild provides official fixture bundle
|
||||
- Add asset coverage summary widget to reachability-center component
|
||||
- Add missing sensor indicator to risk-drift-card
|
||||
- Add stale facts alerting using drift-api service data
|
||||
- Add unit and E2E test coverage for all reachability center components
|
||||
|
||||
## E2E Test Plan
|
||||
- **Setup**:
|
||||
- [ ] Log in with a user that has appropriate permissions
|
||||
- [ ] Navigate to `/reachability`
|
||||
- [ ] Ensure test data exists (scanned artifacts, SBOM data, or seed data as needed)
|
||||
- **Core verification**:
|
||||
- [ ] Verify the component renders correctly with sample data
|
||||
- [ ] Verify interactive elements respond to user input
|
||||
- [ ] Verify data is fetched and displayed from the correct API endpoints
|
||||
- **Edge cases**:
|
||||
- [ ] Verify graceful handling when backend API is unavailable (error state)
|
||||
- [ ] Verify responsive layout at different viewport sizes
|
||||
- [ ] Verify accessibility (keyboard navigation, screen reader labels, ARIA attributes)
|
||||
@@ -0,0 +1,49 @@
|
||||
# SBOM Graph Reachability Overlay with Time Slider
|
||||
|
||||
## Module
|
||||
Web
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
Reachability halo overlay on SBOM graph visualization with time slider for temporal reachability exploration and state legend. Uses deterministic stub data pending fixture bundle.
|
||||
|
||||
## What's Implemented
|
||||
- **Existing components**:
|
||||
- `graph-canvas` (`src/Web/StellaOps.Web/src/app/features/graph/graph-canvas.component.ts`)
|
||||
- `graph-explorer` (`src/Web/StellaOps.Web/src/app/features/graph/graph-explorer.component.ts`)
|
||||
- `graph-filters` (`src/Web/StellaOps.Web/src/app/features/graph/graph-filters.component.ts`)
|
||||
- `graph-hotkey-help` (`src/Web/StellaOps.Web/src/app/features/graph/graph-hotkey-help.component.ts`)
|
||||
- `graph-overlays` (`src/Web/StellaOps.Web/src/app/features/graph/graph-overlays.component.ts`)
|
||||
- `graph-side-panels` (`src/Web/StellaOps.Web/src/app/features/graph/graph-side-panels.component.ts`)
|
||||
- **Existing services**:
|
||||
- `graph-accessibility` (`src/Web/StellaOps.Web/src/app/features/graph/graph-accessibility.service.ts`)
|
||||
|
||||
## What's Missing
|
||||
- **Reachability halo overlay**: Graph overlay components exist but no dedicated reachability state halo (color-coded rings around nodes showing lattice state: SR/SU/RO/RU/CR/CU/X)
|
||||
- **Time slider for temporal reachability**: No time slider component enabling temporal exploration of how reachability states evolved over scan/signal events
|
||||
- **Lattice state legend**: No legend component mapping halo colors to reachability lattice states
|
||||
- **Backend API for temporal reachability**: No API endpoint returning reachability state snapshots at different points in time
|
||||
- **Deterministic fixture bundle**: Currently uses stub data; pending fixture bundle with real reachability overlay data
|
||||
|
||||
## Implementation Plan
|
||||
- Add reachability state halo overlay to graph-overlays component using lattice state colors
|
||||
- Create time slider component for temporal reachability exploration
|
||||
- Add lattice state legend component
|
||||
- Build backend API for temporal reachability snapshots
|
||||
- Wire overlay to live reachability data via graph service
|
||||
|
||||
## E2E Test Plan
|
||||
- **Setup**:
|
||||
- [ ] Log in with a user that has appropriate permissions
|
||||
- [ ] Navigate to `/graph`
|
||||
- [ ] Ensure test data exists (scanned artifacts, SBOM data, or seed data as needed)
|
||||
- **Core verification**:
|
||||
- [ ] Verify the visualization renders correctly with sample data
|
||||
- [ ] Verify interactive elements (hover tooltips, click-to-drill-down) work
|
||||
- [ ] Verify the visualization handles empty/minimal data gracefully
|
||||
- **Edge cases**:
|
||||
- [ ] Verify graceful handling when backend API is unavailable (error state)
|
||||
- [ ] Verify responsive layout at different viewport sizes
|
||||
- [ ] Verify accessibility (keyboard navigation, screen reader labels, ARIA attributes)
|
||||
50
docs/features/unchecked/web/signals-runtime-dashboard.md
Normal file
50
docs/features/unchecked/web/signals-runtime-dashboard.md
Normal file
@@ -0,0 +1,50 @@
|
||||
# Signals & Runtime Dashboard
|
||||
|
||||
## Module
|
||||
Web
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
eBPF/ETW/dyld probe status monitoring, signal collection metrics, anomaly alerts, host coverage map, and real-time event stream. API client and models exist but dedicated feature UI module not found as standalone directory.
|
||||
|
||||
## What's Implemented
|
||||
- **Existing components**:
|
||||
- `extension-slot` (`src/Web/StellaOps.Web/src/app/core/plugins/extension-slots/extension-slot.component.ts`)
|
||||
- **Existing services**:
|
||||
- `evidence-panel-metrics` (`src/Web/StellaOps.Web/src/app/core/analytics/evidence-panel-metrics.service.ts`)
|
||||
- `gateway-metrics` (`src/Web/StellaOps.Web/src/app/core/api/gateway-metrics.service.ts`)
|
||||
- `policy-interop` (`src/Web/StellaOps.Web/src/app/core/api/policy-interop.service.ts`)
|
||||
- `reachability-integration` (`src/Web/StellaOps.Web/src/app/core/api/reachability-integration.service.ts`)
|
||||
- `vuln-export-orchestrator` (`src/Web/StellaOps.Web/src/app/core/api/vuln-export-orchestrator.service.ts`)
|
||||
|
||||
## What's Missing
|
||||
- **Signals dashboard feature module**: No `src/Web/StellaOps.Web/src/app/features/signals/` directory with dedicated dashboard components
|
||||
- **Probe status monitoring**: No component showing eBPF/ETW/dyld probe health status per host
|
||||
- **Signal collection metrics**: No real-time metrics showing signals collected per second, error rates, latency
|
||||
- **Anomaly alerts panel**: No panel displaying detected anomalies from signal data
|
||||
- **Host coverage map**: No visualization showing which hosts have active runtime probes
|
||||
- **Real-time event stream**: No WebSocket/SSE-based live event feed component
|
||||
|
||||
## Implementation Plan
|
||||
- Create `features/signals/` module with route registration
|
||||
- Build probe status monitoring dashboard showing per-host probe health
|
||||
- Add signal collection metrics widget with real-time updates
|
||||
- Build anomaly alerts panel consuming anomaly events from Signals backend
|
||||
- Create host coverage map visualization
|
||||
- Add WebSocket/SSE integration for real-time event streaming
|
||||
|
||||
## E2E Test Plan
|
||||
- **Setup**:
|
||||
- [ ] Log in with a user that has appropriate permissions
|
||||
- [ ] Navigate to the relevant page/section where this feature appears
|
||||
- [ ] Ensure test data exists (scanned artifacts, SBOM data, or seed data as needed)
|
||||
- **Core verification**:
|
||||
- [ ] Verify the dashboard loads without errors and displays summary cards/metrics
|
||||
- [ ] Verify data refreshes correctly and loading states are shown
|
||||
- [ ] Verify empty state is displayed when no data is available
|
||||
- **Edge cases**:
|
||||
- [ ] Verify graceful handling when backend API is unavailable (error state)
|
||||
- [ ] Verify responsive layout at different viewport sizes
|
||||
- [ ] Verify accessibility (keyboard navigation, screen reader labels, ARIA attributes)
|
||||
56
docs/features/unchecked/web/vex-gate.md
Normal file
56
docs/features/unchecked/web/vex-gate.md
Normal file
@@ -0,0 +1,56 @@
|
||||
# VEX Gate (Inline Gated Action with Evidence Tiers)
|
||||
|
||||
## Module
|
||||
Web
|
||||
|
||||
## Status
|
||||
IMPLEMENTED
|
||||
|
||||
## Description
|
||||
The advisory proposed a VexGateButtonDirective that morphs primary action buttons into Green/Amber/Red gated actions with evidence sheets. VEX evidence and decision infrastructure exists (vex-evidence client, vex-decision-modal, evidence-ribbon). However, the specific VexGateButtonDirective and VexEvidenceSheetComponent with inline button morphing and tier-based gating were not found. The pattern is partially realized through separate VEX decision modals and evidence display components.
|
||||
|
||||
## What's Implemented
|
||||
- **Existing components**:
|
||||
- `ai-code-guard-badge` (`src/Web/StellaOps.Web/src/app/features/triage/components/ai-code-guard-badge/ai-code-guard-badge.component.ts`)
|
||||
- `ai-recommendation-panel` (`src/Web/StellaOps.Web/src/app/features/triage/components/ai-recommendation-panel/ai-recommendation-panel.component.ts`)
|
||||
- `attestation-viewer` (`src/Web/StellaOps.Web/src/app/features/triage/components/attestation-viewer/attestation-viewer.component.ts`)
|
||||
- `bulk-action-modal` (`src/Web/StellaOps.Web/src/app/features/triage/components/bulk-action-modal/bulk-action-modal.component.ts`)
|
||||
- `case-header` (`src/Web/StellaOps.Web/src/app/features/triage/components/case-header/case-header.component.ts`)
|
||||
- `decision-drawer-enhanced` (`src/Web/StellaOps.Web/src/app/features/triage/components/decision-drawer/decision-drawer-enhanced.component.ts`)
|
||||
- `decision-drawer` (`src/Web/StellaOps.Web/src/app/features/triage/components/decision-drawer/decision-drawer.component.ts`)
|
||||
- `attestation-chain` (`src/Web/StellaOps.Web/src/app/features/triage/components/evidence-panel/attestation-chain.component.ts`)
|
||||
- `backport-verdict-badge` (`src/Web/StellaOps.Web/src/app/features/triage/components/evidence-panel/backport-verdict-badge.component.ts`)
|
||||
- `binary-diff-tab` (`src/Web/StellaOps.Web/src/app/features/triage/components/evidence-panel/binary-diff-tab.component.ts`)
|
||||
- **Existing services**:
|
||||
- `advisory-ai` (`src/Web/StellaOps.Web/src/app/features/triage/services/advisory-ai.service.ts`)
|
||||
- `binary-diff-evidence` (`src/Web/StellaOps.Web/src/app/features/triage/services/binary-diff-evidence.service.ts`)
|
||||
- `diff-evidence` (`src/Web/StellaOps.Web/src/app/features/triage/services/diff-evidence.service.ts`)
|
||||
- `display-preferences` (`src/Web/StellaOps.Web/src/app/features/triage/services/display-preferences.service.ts`)
|
||||
- `evidence-tab` (`src/Web/StellaOps.Web/src/app/features/triage/services/evidence-tab.service.ts`)
|
||||
|
||||
## What's Missing
|
||||
- **VexGateButtonDirective**: No Angular directive that morphs primary action buttons (e.g., "Promote", "Release") into Green/Amber/Red gated states based on VEX verdict evidence tiers
|
||||
- **VexEvidenceSheetComponent**: No inline evidence sheet that expands from a gated button to show the VEX evidence supporting the gate decision
|
||||
- **Tier-based button color mapping**: No mapping from VEX evidence tier (Tier 1: full evidence, Tier 2: partial, Tier 3: no evidence) to button color states
|
||||
- **Gate override with justification**: No inline flow for overriding a Red/Amber gate with a required justification text
|
||||
|
||||
## Implementation Plan
|
||||
- Create `VexGateButtonDirective` that wraps action buttons with VEX gate logic and color state
|
||||
- Create `VexEvidenceSheetComponent` for inline evidence display on gate button expansion
|
||||
- Define evidence tier-to-color mapping (Green = all evidence, Amber = partial, Red = missing/contradictory)
|
||||
- Add gate override flow requiring justification text for Red/Amber overrides
|
||||
- Wire to existing `VexGateService` backend for gate evaluation data
|
||||
|
||||
## E2E Test Plan
|
||||
- **Setup**:
|
||||
- [ ] Log in with a user that has appropriate permissions
|
||||
- [ ] Navigate to `/triage/artifacts`
|
||||
- [ ] Ensure test data exists (scanned artifacts, SBOM data, or seed data as needed)
|
||||
- **Core verification**:
|
||||
- [ ] Verify the component renders correctly with sample data
|
||||
- [ ] Verify interactive elements respond to user input
|
||||
- [ ] Verify data is fetched and displayed from the correct API endpoints
|
||||
- **Edge cases**:
|
||||
- [ ] Verify graceful handling when backend API is unavailable (error state)
|
||||
- [ ] Verify responsive layout at different viewport sizes
|
||||
- [ ] Verify accessibility (keyboard navigation, screen reader labels, ARIA attributes)
|
||||
Reference in New Issue
Block a user