save checkpoint: save features

This commit is contained in:
master
2026-02-12 10:27:23 +02:00
parent dca86e1248
commit 5bca406787
8837 changed files with 1796879 additions and 5294 deletions

View File

@@ -0,0 +1,48 @@
# ASN.1-Native RFC 3161 Timestamp Token Parsing
## Module
Attestor
## Status
PARTIALLY_IMPLEMENTED
## Description
Native ASN.1 parsing of RFC 3161 timestamp tokens using System.Formats.Asn1 (no BouncyCastle dependency). Includes request encoding, response decoding, TstInfo extraction, certificate chain parsing, and signature verification. This is the low-level implementation detail behind the known "RFC-3161 TSA Client" entry.
## Implementation Details
- **Timestamp Service**: `src/Attestor/__Libraries/StellaOps.Attestor.Timestamping/AttestationTimestampService.cs` (with `.Helpers`, `.Timestamp`, `.Verify` partials) -- core service handling RFC 3161 timestamp request/response lifecycle.
- **IAttestationTimestampService**: `IAttestationTimestampService.cs` -- interface for timestamp operations.
- **Timestamp Policy**: `TimestampPolicy.cs`, `TimestampPolicyEvaluator.cs`, `TimestampPolicyResult.cs` -- policy evaluation for timestamp requirements.
- **TSA Certificate Validation**: `TsaCertificateStatus.cs` -- certificate chain status. `TstVerificationStatus.cs` -- TstInfo verification result.
- **Time Correlation**: `TimeCorrelationValidator.cs` (with `.Async`, `.GapChecks`, `.Validate` partials) -- validates timestamp consistency across multiple TSA sources. `TimeCorrelationPolicy.cs`, `TimeCorrelationResult.cs`, `TimeCorrelationStatus.cs` define correlation rules.
- **Time Consistency**: `TimeConsistencyResult.cs` -- result of cross-TSA time consistency checks.
- **Multi-Provider Fallback**: `src/Attestor/__Libraries/StellaOps.Attestor.Infrastructure/Timestamping/TsaMultiProvider.cs` -- fallback chain across multiple TSA providers.
- **Configuration**: `AttestationTimestampOptions.cs`, `AttestationTimestampServiceOptions.cs`, `AttestationTimestampVerificationOptions.cs`, `AttestationTimestampPolicyContext.cs`.
- **Timestamped Attestation**: `TimestampedAttestation.cs` -- wraps an attestation with its timestamp token.
- **Tests**: `src/Attestor/StellaOps.Attestor/StellaOps.Attestor.Tests/Timestamping/AttestationTimestampServiceTests.cs`, `src/Attestor/StellaOps.Attestor/StellaOps.Attestor.Tests/Timestamping/AttestationTimestampPolicyTests.cs`, `src/Attestor/StellaOps.Attestor/StellaOps.Attestor.Tests/Timestamping/TimeCorrelationValidatorTests.cs`
## E2E Test Plan
- [ ] Create a timestamp request for a SHA-256 hash via `AttestationTimestampService`, send to a TSA endpoint, and verify the response contains a valid TstInfo with matching hash
- [ ] Parse an RFC 3161 timestamp token response and verify certificate chain extraction produces valid `TsaCertificateStatus`
- [ ] Verify a timestamp token signature against the TSA certificate and confirm `TstVerificationStatus` indicates success
- [ ] Configure `TimeCorrelationValidator` with two TSA sources and verify `TimeConsistencyResult` passes when timestamps are within configured gap tolerance
- [ ] Configure `TimeCorrelationValidator` with a strict gap threshold and submit timestamps with drift exceeding the threshold, verifying `TimeCorrelationStatus` indicates failure
- [ ] Test `TsaMultiProvider` fallback by configuring a primary TSA that fails and a secondary that succeeds, verifying the timestamp is obtained from the fallback provider
- [ ] Create a `TimestampedAttestation` wrapping a DSSE envelope and verify the timestamp token is correctly associated
## Implementation Gaps (2026-02-11)
- `AttestationTimestampService.Helpers` still uses placeholder methods for RFC-3161 request/parse/verify flow (`RequestTimestampAsync`, `ParseTstInfo`, `VerifyImprintAsync`, `VerifyTstSignatureAsync`) instead of native ASN.1 token parsing and verification.
- `TsaMultiProvider` request/response handling is marked as simplified placeholder and references hypothetical BouncyCastle integration rather than implemented native ASN.1 parsing.
- Current timestamping tests validate digest/policy scaffolding but do not exercise real RFC-3161 token decode, certificate-chain extraction, CMS signature verification, or fallback-provider behavior with realistic responses.
## Verification
- Evaluated on 2026-02-11 via `run-001`.
- Tier 0 source checks were `partial` only due legacy test path references in the feature dossier; active timestamping source/test files were present.
- Tier 1 and Tier 2 executed successfully for existing timestamping behavior tests (`12/12` class-scoped), but claim parity review failed because RFC-3161 ASN.1 parse/verification paths are still placeholders.
- Feature terminalized as `not_implemented` and moved from `unchecked` to `unimplemented`.
- Evidence:
- `docs/qa/feature-checks/runs/attestor/asn-1-native-rfc-3161-timestamp-token-parsing/run-001/tier0-source-check.json`
- `docs/qa/feature-checks/runs/attestor/asn-1-native-rfc-3161-timestamp-token-parsing/run-001/tier1-build-check.json`
- `docs/qa/feature-checks/runs/attestor/asn-1-native-rfc-3161-timestamp-token-parsing/run-001/tier2-integration-check.json`
- `docs/qa/feature-checks/runs/attestor/asn-1-native-rfc-3161-timestamp-token-parsing/run-001/triage.json`
- `docs/qa/feature-checks/runs/attestor/asn-1-native-rfc-3161-timestamp-token-parsing/run-001/confirmation.json`

View File

@@ -0,0 +1,50 @@
# Attestable Exception Objects with Expiries and Audit Trails
## Module
Attestor
## Status
PARTIALLY_IMPLEMENTED
## Description
Exceptions are modeled as auditable objects with IDs, owners, expiry dates, and audit trails. The exception ledger UI shows active/pending/expiring counts. Signed override badges indicate cryptographic attestation of exceptions.
## Implementation Details
- **Exception Reference**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Services/ExceptionRef.cs` -- models exception objects with ID, owner, and expiry metadata.
- **Budget Exception Entry**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Statements/BudgetExceptionEntry.cs` -- exception entry within the uncertainty budget system, tracking exception scope and validity period.
- **Budget System Integration**: `BudgetDefinition.cs`, `BudgetObservation.cs`, `BudgetViolationEntry.cs` -- exceptions integrate with the uncertainty budget to allow controlled risk acceptance.
- **VEX Override System**: `src/Attestor/__Libraries/StellaOps.Attestor.StandardPredicates/VexOverride/VexOverridePredicate.cs` -- signed VEX overrides serve as attestable exceptions. `VexOverridePredicateBuilder.cs` (with `.Build`, `.Serialize`, `.WithMethods` partials) constructs override predicates. `VexOverrideDecision.cs` captures the decision rationale.
- **Evidence Reference**: `VexOverride/EvidenceReference.cs` -- links exception decisions to supporting evidence.
- **Audit Trail**: `src/Attestor/__Libraries/StellaOps.Attestor.ProofChain/Audit/AuditHashLogger.cs` (with `.Validation` partial) logs hash-based audit records. `HashAuditRecord.cs` captures individual audit entries. `AuditArtifactTypes.cs` defines auditable artifact types.
- **Persistence**: `src/Attestor/__Libraries/StellaOps.Attestor.Persistence/Entities/AuditLogEntity.cs` -- database entity for audit log persistence.
- **DSSE Signing**: Exceptions are signed via `ProofChainSigner` to produce cryptographic attestation (signed override badges).
## E2E Test Plan
- [ ] Create an exception via `BudgetExceptionEntry` with owner, expiry date, and justification, then verify all fields serialize correctly
- [ ] Build a `VexOverridePredicate` with `VexOverridePredicateBuilder`, sign it via DSSE, and verify the signed envelope contains the override decision
- [ ] Create an exception with an expiry date in the past and verify budget evaluation treats it as expired (no longer valid)
- [ ] Create an exception with a future expiry and verify it is counted as active in the budget check
- [ ] Log exception creation via `AuditHashLogger` and verify `HashAuditRecord` captures the artifact type, timestamp, and hash
- [ ] Query audit trail for a specific exception ID and verify the complete history of changes is returned
- [ ] Verify that `ExceptionRef` correctly links to `EvidenceReference` for evidence-backed exception justification
## Implementation Gaps (2026-02-11)
- `ExceptionRef` currently contains only `ExceptionId`, `Status`, and `CoveredReasonCodes`; it does not model owner/expiry metadata or evidence references as described by the feature claim.
- A concrete `IProofChainRepository` implementation for querying complete audit history by exception ID was not found in `StellaOps.Attestor.Persistence`; only the interface contract exists.
- Core DSSE exception signing and hash audit logging behaviors are implemented and tested, but claim-parity fails for full exception-reference and audit-query workflow coverage.
## Verification
- Evaluated on 2026-02-11 via `run-001`.
- Tier 0 source checks passed, Tier 1 build/tests passed (`52/52` scoped tests), but Tier 1 code review and Tier 2 behavioral claim parity failed on missing exception-reference and audit-query implementation pieces.
- Feature terminalized as `not_implemented` and moved from `unchecked` to `unimplemented`.
- Evidence:
- `docs/qa/feature-checks/runs/attestor/attestable-exception-objects-with-expiries-and-audit-trails/run-001/tier0-source-check.json`
- `docs/qa/feature-checks/runs/attestor/attestable-exception-objects-with-expiries-and-audit-trails/run-001/tier1-build-check.json`
- `docs/qa/feature-checks/runs/attestor/attestable-exception-objects-with-expiries-and-audit-trails/run-001/tier2-integration-check.json`
- `docs/qa/feature-checks/runs/attestor/attestable-exception-objects-with-expiries-and-audit-trails/run-001/triage.json`
## Not Implemented Findings
- Tier 0 and Tier 1 pass for core exception-signing and audit-hash behavior, but claim parity review found gaps in exception reference modeling and audit-history query implementation.
- ExceptionRef currently contains ExceptionId, Status, and covered reason codes only; owner/expiry/evidence linkage promised by this feature dossier is not modeled in this contract.
- IProofChainRepository exposes audit-log query methods, but no concrete proof-chain repository implementation was found to fulfill complete history retrieval semantics by exception ID in this feature scope.

View File

@@ -0,0 +1,37 @@
# Binary Call-Graph Extraction and Reachability Analysis
## Module
BinaryIndex
## Status
PARTIALLY_IMPLEMENTED
## Description
Binary call-graph extraction with BinaryCallGraphExtractor, reachability lifting via BinaryReachabilityLifter, dedicated BinaryIndex analysis module, and CLI binary commands.
## Implementation Details
- **Modules**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Analysis/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Semantic/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/`
- **Key Classes**:
- `ReachGraphBinaryReachabilityService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Analysis/ReachGraphBinaryReachabilityService.cs`) - binary-level reachability integration with ReachGraph
- `TaintGateExtractor` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Analysis/TaintGateExtractor.cs`) - extracts taint gates (bounds checks, null checks, auth checks, permission checks, type checks) from binary call paths
- `CfgExtractor` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/CfgExtractor.cs`) - control flow graph extraction from disassembled binaries
- `CallNgramGenerator` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Semantic/CallNgramGenerator.cs`) - generates call-sequence n-grams from lifted IR for call graph analysis
- `CallGraphMatcherAdapter` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Validation/Matchers/MatcherAdapters.cs`) - adapter for call graph matching in validation harness
- **Interfaces**: `ICallNgramGenerator`, `IBinaryFeatureExtractor`
## E2E Test Plan
- [ ] Submit an ELF binary and verify call-graph extraction produces a valid set of function nodes and edges
- [ ] Verify `TaintGateExtractor` classifies conditions correctly (bounds check, null check, auth check, permission check, type check)
- [ ] Verify `CfgExtractor` produces control flow graphs from disassembled functions
- [ ] Verify `CallNgramGenerator` generates n-grams (n=2,3,4) from lifted function IR and computes Jaccard similarity
- [ ] Verify `ReachGraphBinaryReachabilityService` integrates with the ReachGraph module for function-level exploitability assessment
- [ ] Verify call-graph-based reachability results feed into the ensemble decision engine
## Verification Outcome (run-001)
- Tier 0/1/2 artifacts: docs/qa/feature-checks/runs/binaryindex/binary-call-graph-extraction-and-reachability-analysis/run-001/
- Result: not implemented at claim parity.
- Missing behavior:
- TaintGateExtractor.ExtractAsync returns empty output and does not perform binary/disassembly path extraction.
- CallGraphMatcherAdapter is placeholder logic with fixed score and TODO comments.
- ReachGraphBinaryReachabilityService.FindPathsAsync currently constructs simplified placeholder paths.
- No focused behavioral tests prove call-graph matcher/reachability adapter semantics end-to-end.

View File

@@ -0,0 +1,37 @@
# Binary Identity Extraction (Build-ID Based)
## Module
BinaryIndex
## Status
PARTIALLY_IMPLEMENTED
## Description
Binary identity extraction using Build-IDs and symbol observations for ELF binary identification, with ground-truth validation and SBOM stability verification.
## Implementation Details
- **Modules**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Persistence/`
- **Key Classes**:
- `BinaryIdentityService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Services/BinaryIdentityService.cs`) - main service for extracting binary identity from ELF/PE/Mach-O binaries
- `ElfFeatureExtractor` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Services/ElfFeatureExtractor.cs`) - extracts Build-ID, symbol tables, and section info from ELF binaries
- `PeFeatureExtractor` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Services/PeFeatureExtractor.cs`) - extracts CodeView GUID from Windows PE binaries
- `MachoFeatureExtractor` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Services/MachoFeatureExtractor.cs`) - extracts LC_UUID from Mach-O binaries
- `StreamGuard` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Services/StreamGuard.cs`) - safe stream handling for non-seekable streams
- **Interfaces**: `IBinaryFeatureExtractor` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Services/IBinaryFeatureExtractor.cs`)
- **Models**: `BinaryIdentity` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Models/BinaryIdentity.cs`)
## E2E Test Plan
- [ ] Submit an ELF binary with a known Build-ID and verify the extracted identity matches
- [ ] Submit a Windows PE binary and verify CodeView GUID extraction via `PeFeatureExtractor`
- [ ] Submit a Mach-O binary and verify LC_UUID extraction via `MachoFeatureExtractor`
- [ ] Verify that non-seekable streams are handled correctly via `StreamGuard`
- [ ] Verify that binaries without Build-IDs fall back to symbol-based identification
- [ ] Verify extracted identities are persisted and queryable through `BinaryVulnerabilityService`
## Verification Outcome (run-001)
- Tier 0/1/2 artifacts: docs/qa/feature-checks/runs/binaryindex/binary-identity-extraction/run-001/
- Result: not implemented at claim parity.
- Missing behavior:
- Build-ID-missing fallback path uses file hash, not symbol-observation-based identity as claimed.
- Ground-truth validation and SBOM stability verification are not implemented in the documented extraction flow.
- Existing behavioral tests do not explicitly prove PE CodeView GUID / Mach-O LC_UUID extraction semantics.

View File

@@ -0,0 +1,38 @@
# Binary Intelligence Graph / Binary Identity Indexing
## Module
BinaryIndex
## Status
PARTIALLY_IMPLEMENTED
## Description
Complete BinaryIndex module with binary identity indexing, ELF feature extraction, vulnerability fingerprint matching, and reachability status tracking. Advisory marked as SUPERSEDED by this implementation.
## Implementation Details
- **Modules**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Persistence/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Analysis/`
- **Key Classes**:
- `BinaryIdentityService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Services/BinaryIdentityService.cs`) - binary identity management
- `ElfFeatureExtractor` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Services/ElfFeatureExtractor.cs`) - ELF feature extraction
- `BinaryVulnerabilityService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Persistence/Services/BinaryVulnerabilityService.cs`) - vulnerability matching with Build-ID catalog lookups
- `SignatureMatcher` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Analysis/SignatureMatcher.cs`) - signature-based vulnerability fingerprint matching
- `ReachGraphBinaryReachabilityService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Analysis/ReachGraphBinaryReachabilityService.cs`) - reachability status tracking
- **Models**: `BinaryIdentity`, `FixModels` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Models/`)
- **Persistence**: `IBinaryVulnAssertionRepository`, `IBinaryVulnerabilityService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Services/`)
## E2E Test Plan
- [ ] Verify end-to-end flow: submit binary, extract identity, index in the graph, and query by Build-ID
- [ ] Verify vulnerability fingerprint matching via `SignatureMatcher` returns correct match scores
- [ ] Verify reachability status tracking integrates with ReachGraph
- [ ] Verify `BinaryVulnerabilityService` correctly maps match methods (buildid_catalog, delta_signature, etc.)
- [ ] Verify binary identity indexing supports multi-tenant contexts via `ITenantContext`
## Verification
- Run: `docs/qa/feature-checks/runs/binaryindex/binary-intelligence-graph-binary-identity-indexing/run-001/`
- Date (UTC): 2026-02-11
- Verdict: `not_implemented`
## Missing / Mismatched Behavior
- Default WebService runtime composition wires `IBinaryVulnerabilityService` to `InMemoryBinaryVulnerabilityService`, so live resolution API behavior does not exercise full persistence-backed vulnerability matching.
- Analysis service registration defaults to `NullBinaryReachabilityService` unless explicitly overridden, so ReachGraph-backed reachability tracking is not active by default.
- `BinaryVulnerabilityService` method mapping does not explicitly include `delta_signature` in `MapMethod`, which mismatches the documented match-method coverage claim.

View File

@@ -0,0 +1,36 @@
# Binary Proof Verification Pipeline
## Module
BinaryIndex
## Status
PARTIALLY_IMPLEMENTED
## Description
Full binary proof verification with ground truth sources (buildinfo, debuginfod, reproducible builds), validation, and golden set testing.
## Implementation Details
- **Modules**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.GroundTruth.Reproducible/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Validation/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Validation.Abstractions/`
- **Key Classes**:
- `ValidationHarnessService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.GroundTruth.Reproducible/ValidationHarnessService.cs`) - orchestrates reproducible-build-based validation runs
- `ValidationHarness` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Validation/ValidationHarness.cs`) - main validation harness with matcher adapter factory integration
- `KpiRegressionService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.GroundTruth.Reproducible/Services/KpiRegressionService.cs`) - KPI regression detection across validation runs
- `GroundTruthProvenanceResolver` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/Provenance/GroundTruthProvenanceResolver.cs`) - resolves symbol provenance from ground truth sources
- **Interfaces**: `IValidationHarness` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Validation.Abstractions/IValidationHarness.cs`), `IKpiRegressionService`, `ISymbolProvenanceResolver`
- **Registration**: `ServiceCollectionExtensions.AddCorpusBundleExport/Import` for bundle exchange
## E2E Test Plan
- [ ] Run a validation harness against a known binary pair and verify proof correctness
- [ ] Verify ground truth resolution from buildinfo sources produces correct provenance data
- [ ] Verify KPI regression service detects accuracy drops between validation runs
- [ ] Verify golden set validation produces deterministic, reproducible results
- [ ] Verify corpus bundle export/import round-trips correctly
- [ ] Verify validation run attestor generates valid attestation predicates with corpus snapshot IDs
## Verification Outcome (run-001)
- Tier 0/1/2 artifacts: docs/qa/feature-checks/runs/binaryindex/binary-proof-verification-pipeline/run-001/
- Result: not implemented at claim parity.
- Missing behavior:
- ValidationHarnessService still uses placeholder stubs for symbol recovery, IR lifting, fingerprint generation, function matching, and SBOM hash calculation.
- Validation matcher adapters (SemanticDiff, InstructionHash, CallGraph) are TODO-backed placeholders with synthetic scores instead of production matching logic.
- Current tests explicitly validate scaffold behavior (skeleton contract), so passing suites do not prove the full proof-verification contract described in this dossier.

View File

@@ -0,0 +1,34 @@
# Binary Reachability Analysis
## Module
BinaryIndex
## Status
PARTIALLY_IMPLEMENTED
## Description
Binary-level reachability analysis integrating with the ReachGraph and taint gate extraction for function-level exploitability assessment.
## Implementation Details
- **Modules**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Analysis/`
- **Key Classes**:
- `ReachGraphBinaryReachabilityService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Analysis/ReachGraphBinaryReachabilityService.cs`) - connects binary analysis to the ReachGraph module for function-level reachability
- `TaintGateExtractor` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Analysis/TaintGateExtractor.cs`) - identifies taint gate types (BoundsCheck, NullCheck, AuthCheck, PermissionCheck, TypeCheck) from condition strings
- `SignatureMatcher` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Analysis/SignatureMatcher.cs`) - matches vulnerability signatures at the binary level
- **Models**: `AnalysisResultModels`, `FingerprintModels`, `SignatureIndexModels` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Analysis/Models/`)
- **Interfaces**: defined in `Interfaces.cs`, implementations in `Implementations.cs`
## E2E Test Plan
- [ ] Submit a binary with a known vulnerable function and verify reachability analysis identifies it as reachable from entry points
- [ ] Verify `TaintGateExtractor` correctly classifies all gate types (bounds, null, auth, permission, type checks)
- [ ] Verify that unreachable vulnerable functions reduce the exploitability score
- [ ] Verify integration between `ReachGraphBinaryReachabilityService` and the ReachGraph module
- [ ] Verify that taint gate presence between entry point and vulnerable function is reflected in the analysis result
## Verification Outcome (run-001)
- Tier 0/1/2 artifacts: docs/qa/feature-checks/runs/binaryindex/binary-reachability-analysis/run-001/
- Result: not implemented at claim parity.
- Missing behavior:
- Implementations.cs still contains NotImplementedException stubs for fingerprint extraction and related reachability pipeline contracts.
- Service registration defaults to stub/null analysis components (FingerprintExtractor, ReachabilityAnalyzer, NullBinaryReachabilityService) rather than full production reachability wiring.
- ReachGraphBinaryReachabilityService.FindPathsAsync uses simplified two-node path construction, not full graph-path tracing semantics claimed by the feature.

View File

@@ -0,0 +1,38 @@
# Binary Resolution API with Cache Layer
## Module
BinaryIndex
## Status
PARTIALLY_IMPLEMENTED
## Description
REST API endpoints (`POST /api/v1/resolve/vuln` and `/vuln/batch`) for querying whether a CVE is resolved through binary-level backport detection. Includes Valkey-backed response caching, rate limiting middleware, and telemetry instrumentation.
## Implementation Details
- **Modules**: `src/BinaryIndex/StellaOps.BinaryIndex.WebService/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Cache/`
- **Key Classes**:
- `ResolutionController` (`src/BinaryIndex/StellaOps.BinaryIndex.WebService/Controllers/ResolutionController.cs`) - REST API controller with `POST /api/v1/resolve/vuln` and `/vuln/batch` endpoints
- `ResolutionService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Resolution/ResolutionService.cs`) - core resolution logic
- `CachedResolutionService` (`src/BinaryIndex/StellaOps.BinaryIndex.WebService/Services/CachedResolutionService.cs`) - decorator adding Valkey-backed caching around ResolutionService
- `ResolutionCacheService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Cache/ResolutionCacheService.cs`) - Valkey cache operations for resolution results
- `RateLimitingMiddleware` (`src/BinaryIndex/StellaOps.BinaryIndex.WebService/Middleware/RateLimitingMiddleware.cs`) - per-tenant rate limiting with X-RateLimit headers
- `ResolutionTelemetry` (`src/BinaryIndex/StellaOps.BinaryIndex.WebService/Telemetry/ResolutionTelemetry.cs`) - OpenTelemetry metrics for resolution requests, cache hits, rate limits
- **Contracts**: `VulnResolutionRequest/Response`, `ResolutionMatchTypes` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Contracts/Resolution/VulnResolutionContracts.cs`)
- **Cache Options**: `BinaryCacheOptions`, `CacheOptionsValidation` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Cache/`)
## E2E Test Plan
- [ ] Send `POST /api/v1/resolve/vuln` with a known CVE and package purl, verify resolution response contains match type (BuildId, DeltaSignature, etc.)
- [ ] Send batch request to `/api/v1/resolve/vuln/batch` with multiple packages and verify all are resolved
- [ ] Verify cache hit: send same request twice and confirm second response comes from cache (check telemetry counters)
- [ ] Verify rate limiting: exceed the configured request limit and confirm 429 response with X-RateLimit headers
- [ ] Verify telemetry: confirm resolution metrics are emitted (request count, cache hit ratio, latency histogram)
- [ ] Verify disabled rate limiting mode passes requests through without headers
## Verification Outcome
- Tier 0/1/2 artifacts: `docs/qa/feature-checks/runs/binaryindex/binary-resolution-api-with-cache-layer/run-002/`.
- Result: not implemented at claim parity.
- Missing behavior:
- Default runtime wiring uses `InMemoryBinaryVulnerabilityService`, so real BuildId/DeltaSignature vulnerability matching claims are not realized.
- Resolution telemetry counters are not invoked end-to-end from controller/service request flow.
- Tier 2 endpoint responses validate HTTP status behavior but do not establish production-grade CVE resolution semantics.

View File

@@ -0,0 +1,40 @@
# BinaryIndex User Configuration System
## Module
BinaryIndex
## Status
PARTIALLY_IMPLEMENTED
## Description
Comprehensive user configuration for B2R2 lifter pooling, LowUIR enablement, Valkey function cache behavior, PostgreSQL persistence, with ops endpoints for health/bench/cache/config and redaction rules for operator visibility.
## Implementation Details
- **Modules**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Configuration/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Disassembly.B2R2/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Cache/`
- **Key Classes**:
- `BinaryIndexOptions` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Configuration/BinaryIndexOptions.cs`) - top-level config with sections for B2R2Pool, SemanticLifting, cache, persistence
- `B2R2PoolOptions` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Disassembly.B2R2/B2R2LifterPoolOptions.cs`) - MaxPoolSizePerIsa (1-64), EnableWarmPreload, AcquireTimeout, EnableMetrics, WarmPreloadIsas
- `SemanticLiftingOptions` - B2R2Version, Enabled flag, function limits
- `BinaryCacheOptions` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Cache/BinaryCacheOptions.cs`) - Valkey cache configuration
- `CacheOptionsValidation` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Cache/CacheOptionsValidation.cs`) - validates cache config at startup
- `FunctionIrCacheOptions` - function IR cache TTL and size limits
- `BinaryIndexOpsOptions` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Configuration/BinaryIndexOpsModels.cs`) - redacted keys list for operator visibility, bench rate limits
- **Source**: SPRINT_20260112_007_BINIDX_binaryindex_user_config.md
## E2E Test Plan
- [ ] Configure B2R2 pool with custom MaxPoolSizePerIsa and verify pool initializes with correct size
- [ ] Configure SemanticLifting as disabled and verify LowUIR lifting is skipped
- [ ] Configure Valkey cache options and verify function IR cache respects TTL settings
- [ ] Verify configuration binding from `StellaOps:BinaryIndex:*` config sections
- [ ] Verify redacted keys do not appear in ops config endpoint responses
- [ ] Verify CacheOptionsValidation rejects invalid configuration at startup
## Verification
- Run: `docs/qa/feature-checks/runs/binaryindex/binaryindex-user-configuration-system/run-001/`
- Date (UTC): 2026-02-11
- Verdict: `not_implemented`
## Missing / Mismatched Behavior
- Live Tier 2 probe with overridden `StellaOps__BinaryIndex__*` values did not affect `/api/v1/ops/binaryindex/config` output (values remained defaults).
- Runtime WebService composition does not bind the full `BinaryIndexOptions` (`StellaOps:BinaryIndex:*`) contract into the active ops endpoint path.
- Ops config response surface is narrower than the documented comprehensive user-configuration model (notably persistence/operator-oriented sectioning and redaction-oriented view semantics).

View File

@@ -0,0 +1,35 @@
# Byte-Level Binary Diffing with Rolling Hash Windows
## Module
BinaryIndex
## Status
PARTIALLY_IMPLEMENTED
## Description
Byte-level binary comparison using rolling hash windows that identifies exactly which byte ranges changed between binary versions. Produces binary proof snippets with section analysis and privacy controls to strip raw bytes. Supports stream and file-based comparison.
## Implementation Details
- **Modules**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Diff/`
- **Key Classes**:
- `PatchDiffEngine` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Diff/PatchDiffEngine.cs`) - core diffing engine computing byte-level differences between binary versions using function fingerprints
- `FunctionDiffer` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Diff/FunctionDiffer.cs`) - function-level comparison with semantic analysis option and call-graph edge diffing
- `FunctionRenameDetector` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Diff/FunctionRenameDetector.cs`) - detects function renames between versions using fingerprint similarity
- `VerdictCalculator` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Diff/VerdictCalculator.cs`) - computes patch verification verdicts from diff results
- `InMemoryDiffResultStore` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Diff/Storage/InMemoryDiffResultStore.cs`) - stores diff results with content-addressed IDs
- **Models**: `PatchDiffModels`, `DiffEvidenceModels`, `BinaryReference` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Diff/Models/`)
- **Interfaces**: `IPatchDiffEngine`, `IDiffResultStore` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Diff/`)
- **Source**: SPRINT_20260112_200_004_CHGTRC_byte_diffing.md
## E2E Test Plan
- [ ] Submit two binary versions and verify byte-range differences are identified with correct offsets
- [ ] Verify section analysis identifies which ELF sections changed (.text, .data, .rodata)
- [ ] Verify privacy controls strip raw bytes from proof snippets when configured
- [ ] Verify `FunctionRenameDetector` correctly identifies renamed functions between versions
- [ ] Verify `VerdictCalculator` produces correct patch verification verdict (patched vs unpatched)
- [ ] Verify diff results are stored with deterministic content-addressed IDs
## Implementation Gaps (QA 2026-02-11)
- Current diff engine is function/CFG-level (`PatchDiffEngine` + `FunctionDiffer`) and does not implement byte-range rolling-window outputs with exact offsets.
- Section-aware diff outputs (`.text/.data/.rodata`) and privacy controls to strip raw proof bytes are not present in exposed models/engine behavior.
- `InMemoryDiffResultStore` stores results using `Guid.NewGuid()` rather than deterministic content-addressed IDs.

View File

@@ -0,0 +1,41 @@
# Call-Ngram Fingerprinting for Binary Similarity Analysis
## Module
BinaryIndex
## Status
PARTIALLY_IMPLEMENTED
## Description
Call-sequence n-gram extraction from lifted IR for improved cross-compiler binary similarity matching. Generates n-grams (n=2,3,4) from function call sequences and integrates into the semantic fingerprint pipeline with configurable dimension weights (instruction 0.4, CFG 0.3, call-ngram 0.2, semantic 0.1).
## Implementation Details
- **Modules**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Semantic/`
- **Key Classes**:
- `CallNgramGenerator` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Semantic/CallNgramGenerator.cs`) - generates `CallNgramFingerprint` from `LiftedFunction` call sequences; computes Jaccard similarity between fingerprints
- `CallNgramFingerprint` (record in same file) - contains n-gram hash sets and metadata; has `Empty` sentinel for functions without calls
- **Interfaces**: `ICallNgramGenerator` (defined in `CallNgramGenerator.cs`) - `Generate(LiftedFunction)` and `ComputeSimilarity(CallNgramFingerprint, CallNgramFingerprint)`
- **Integration**: Used by `EnsembleDecisionEngine` and `FunctionAnalysisBuilder` as one of the matching dimensions with 0.2 default weight
- **Source**: SPRINT_20260118_026_BinaryIndex_deltasig_enhancements.md
## E2E Test Plan
- [ ] Generate call-ngram fingerprint from a function with known call sequences and verify correct n-gram extraction (n=2,3,4)
- [ ] Compute similarity between identical call sequences and verify similarity = 1.0
- [ ] Compute similarity between disjoint call sequences and verify similarity = 0.0
- [ ] Verify `CallNgramFingerprint.Empty` is returned for functions without call instructions
- [ ] Verify call-ngram dimension integrates into ensemble scoring with configurable weight (default 0.2)
- [ ] Verify cross-compiler similarity: same source compiled with GCC vs Clang should produce similar call n-grams
## Implementation Gaps (QA 2026-02-11)
- `CallNgramGenerator` is present, but no dedicated call-ngram behavioral tests exist in `src/BinaryIndex/__Tests/StellaOps.BinaryIndex.Semantic.Tests/`.
- `EnsembleDecisionEngine` currently combines syntactic/semantic/embedding signals only and does not expose a call-ngram signal or the claimed default 0.2 call-ngram weight path.
- `FunctionAnalysisBuilder` does not compute or attach call-ngram fingerprints into the ensemble analysis pipeline.
- `CallNgramOptions.MinCallCount` is not enforced in generator output flow.
## Verification Outcome
- Tier 0/1/2 artifacts: `docs/qa/feature-checks/runs/binaryindex/call-ngram-fingerprinting-for-binary-similarity-analysis/run-001/`.
- Result: not implemented at claim parity.
- Missing behavior:
- `CallNgramGenerator` exists, but no first-class integration path wires call-ngram fingerprints into `FunctionAnalysisBuilder` outputs.
- `EnsembleDecisionEngine` and `EnsembleOptions` expose only syntactic/semantic/embedding dimensions; no call-ngram dimension with claimed default weight.
- No dedicated call-ngram generator behavioral tests verify n=2/3/4 extraction and similarity semantics as described by the dossier.

View File

@@ -0,0 +1,36 @@
# Delta signature matching and patch coverage analysis
## Module
BinaryIndex
## Status
PARTIALLY_IMPLEMENTED
## Description
Delta signature matching traces symbol-level changes between vulnerable and fixed builds. PatchCoverageController exposes an API for patch coverage assessment.
## Implementation Details
- **Modules**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/`, `src/BinaryIndex/StellaOps.BinaryIndex.WebService/Controllers/`
- **Key Classes**:
- `DeltaSignatureMatcher` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/DeltaSignatureMatcher.cs`) - matches delta signatures against target binaries
- `DeltaSignatureGenerator` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/DeltaSignatureGenerator.cs`) - generates delta signatures from binary pairs
- `DeltaSigService` / `DeltaSigServiceV2` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/`) - service layer for delta signature operations (V2 adds IR diffs)
- `PatchCoverageController` (`src/BinaryIndex/StellaOps.BinaryIndex.WebService/Controllers/PatchCoverageController.cs`) - REST API for patch coverage queries using `IDeltaSignatureRepository`
- `SymbolChangeTracer` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/SymbolChangeTracer.cs`) - traces symbol-level changes between builds
- `DeltaScopePolicyGate` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/Policy/DeltaScopePolicyGate.cs`) - policy gate for delta scope enforcement
- **Interfaces**: `IDeltaSigService`, `IDeltaSignatureGenerator`, `IDeltaSignatureMatcher`, `ISymbolChangeTracer`
- **IR Diff**: `IrDiffGenerator` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/IrDiff/`) - generates IR-level diffs between function versions
## E2E Test Plan
- [ ] Generate a delta signature from known vulnerable/fixed binary pair and verify signature captures changed functions
- [ ] Match the generated delta signature against a target binary and verify correct patch status detection
- [ ] Query `PatchCoverageController` API for patch coverage and verify coverage percentage
- [ ] Verify `SymbolChangeTracer` identifies added, removed, and modified symbols
- [ ] Verify `DeltaScopePolicyGate` enforces delta scope policies
- [ ] Verify IR-level diff generation captures semantic function changes beyond byte-level diffs
## Verification
- Run: `run-002` (2026-02-11 UTC).
- Tier 1 build/test projects passed after remediation, including new `PatchCoverageController` behavior tests and deterministic `IDeltaSignatureRepository` fallback wiring in WebService.
- Tier 2 API checks now pass for positive and negative flows on `/api/v1/stats/patch-coverage*` endpoints.
- Claim parity remains incomplete for this feature because `IrDiffGenerator` still uses placeholder diff payload generation (`GenerateSingleDiffAsync`) instead of real lifted-IR semantic diff extraction, so the full advertised IR-diff capability is not implemented.

View File

@@ -0,0 +1,50 @@
# ELF Normalization and Delta Hashing
## Module
BinaryIndex
## Status
PARTIALLY_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/`
## Verification
- Tier 0/1/2 artifacts: `docs/qa/feature-checks/runs/binaryindex/elf-normalization-and-delta-hashing/run-001/`.
- Result: not implemented at claim parity.
- Confirmed missing behavior:
- `ElfNormalizer`/segment normalization pipeline is absent (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Core/Services/ElfNormalizer.cs` missing).
- No relocation-zeroing, NOP-canonicalization, or jump-table rewriting implementation was found in Core/DeltaSig/Diff libraries.
- Existing behavior remains function-level delta signatures plus ELF metadata extraction, not segment-level low-entropy delta hashing.

View File

@@ -0,0 +1,37 @@
# Ensemble decision engine for multi-tier matching
## Module
BinaryIndex
## Status
PARTIALLY_IMPLEMENTED
## Description
Ensemble decision engine combines multiple matching tiers (range match, Build-ID, fingerprint) with configurable weight tuning for vulnerability classification.
## Implementation Details
- **Modules**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Ensemble/`
- **Key Classes**:
- `EnsembleDecisionEngine` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Ensemble/EnsembleDecisionEngine.cs`) - combines multiple matching signals with configurable weights into a final vulnerability classification decision
- `FunctionAnalysisBuilder` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Ensemble/FunctionAnalysisBuilder.cs`) - builds function analysis inputs including optional ML embeddings
- `WeightTuningService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Ensemble/WeightTuningService.cs`) - tunes ensemble weights based on golden set validation results
- `EnsembleOptions` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Ensemble/Models.cs`) - configurable weights and thresholds for matching tiers
- `MlEmbeddingMatcherAdapter` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.ML/Training/MlEmbeddingMatcherAdapter.cs`) - adapts ML function embeddings for ensemble use
- **Interfaces**: `IEnsembleDecisionEngine` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Ensemble/IEnsembleDecisionEngine.cs`)
- **Registration**: `EnsembleServiceCollectionExtensions.AddBinarySimilarityServices()` for full pipeline setup
- **Benchmarks**: `EnsembleAccuracyBenchmarks`, `EnsembleLatencyBenchmarks` (`src/BinaryIndex/__Tests/StellaOps.BinaryIndex.Benchmarks/`)
## E2E Test Plan
- [ ] Submit a binary with known vulnerability and verify ensemble produces correct classification
- [ ] Verify weight tuning: adjust instruction weight to 0.6 and verify it changes classification outcomes
- [ ] Verify multi-tier integration: Build-ID match, fingerprint match, and ML embedding all contribute to score
- [ ] Verify `FunctionAnalysisBuilder` correctly assembles all matching dimensions
- [ ] Verify `WeightTuningService` optimizes weights based on golden set validation accuracy
- [ ] Run accuracy benchmark and verify F1 score meets minimum threshold
## Verification
- Run: `run-001` (2026-02-11 UTC).
- Tier 1/2 builds and tests passed (`37/37`), but parity review found contract mismatch and missing coverage for key claims.
- Ensemble signal model currently exposes syntactic, semantic, embedding, and exact-hash signals, but the feature contract claims range-match, Build-ID, and fingerprint tiers (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Ensemble/Models.cs:232`).
- `FunctionAnalysisBuilder` explicitly retains a simplified semantic-graph path when binary data is unavailable (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Ensemble/FunctionAnalysisBuilder.cs:87`).
- No direct tests were found for `FunctionAnalysisBuilder` or `MlEmbeddingMatcherAdapter` in `src/BinaryIndex/__Tests/StellaOps.BinaryIndex.Ensemble.Tests`.

View File

@@ -0,0 +1,40 @@
# Symbol Change Tracking in Binary Diffs (SymbolChangeTracer)
## Module
BinaryIndex
## Status
PARTIALLY_IMPLEMENTED
## Description
Extends BinaryIndex DeltaSignature module to track which specific symbols changed between binary versions (not just whether they match). Adds change metadata to SymbolMatchResult and provides detailed CFG hash and instruction hash comparison for symbol-level binary change forensics.
## Implementation Details
- **Modules**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/`
- **Key Classes**:
- `SymbolChangeTracer` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/SymbolChangeTracer.cs`) - traces symbol-level changes between binary versions with detailed CFG hash and instruction hash comparison
- `DeltaSignatureGenerator` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/DeltaSignatureGenerator.cs`) - generates delta signatures capturing symbol change metadata
- `DeltaSignatureMatcher` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/DeltaSignatureMatcher.cs`) - matches signatures with change tracking awareness
- `CfgExtractor` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/Cfg/CfgExtractor.cs`) - extracts CFG for hash comparison
- `IrDiffGenerator` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/IrDiff/IrDiffGenerator.cs`) - generates IR-level diffs for detailed change analysis
- **Interfaces**: `ISymbolChangeTracer` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig/ISymbolChangeTracer.cs`)
- **Models**: `SymbolMatchResult` with change metadata in `Models.cs`
- **Source**: SPRINT_20260112_200_003_BINDEX_symbol_tracking.md
## E2E Test Plan
- [ ] Compare two binary versions with known symbol changes and verify `SymbolChangeTracer` identifies which symbols changed
- [ ] Verify CFG hash comparison detects control flow changes in modified functions
- [ ] Verify instruction hash comparison detects instruction-level changes
- [ ] Verify `SymbolMatchResult` includes change metadata (added, removed, modified symbols)
- [ ] Verify IR-level diff captures semantic changes beyond byte-level differences
- [ ] Verify unchanged symbols are correctly identified as stable between versions
## Verification Outcome (run-001)
- Tier 0/1/2 artifacts: `docs/qa/feature-checks/runs/binaryindex/symbol-change-tracking-in-binary-diffs/run-001/`
- Result: not implemented at full claim parity.
- Verified behavior:
- `SymbolChangeTracer` and related tests cover added/removed/modified/unchanged classification, patched heuristics, and chunk-index metadata.
- `SymbolMatchResult` metadata fields are populated and exercised by the DeltaSig test suite.
- Missing behavior:
- `IrDiffGenerator` remains placeholder-backed (`In a real implementation` path with zeroed diff summary and placeholder digest), so the dossier's semantic IR-diff-forensics claim is not fully implemented.
- No dedicated `IrDiffGenerator` behavioral tests were found in `StellaOps.BinaryIndex.DeltaSig.Tests`, so IR-level diff semantics are not verified by tests.

View File

@@ -0,0 +1,39 @@
# Symbol Source Connectors (Debuginfod, Buildinfo, Ddeb, SecDb)
## Module
BinaryIndex
## Status
PARTIALLY_IMPLEMENTED
## Description
Four symbol source connector implementations (Debuginfod, Debian Buildinfo, Ubuntu Ddeb, Alpine SecDb), each with plugin registration and configuration support.
## Implementation Details
- **Modules**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Corpus/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Corpus.Alpine/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Corpus.Debian/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Corpus.Rpm/`
- **Key Classes**:
- **Alpine SecDb**: `AlpineCorpusConnector` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Corpus.Alpine/AlpineCorpusConnector.cs`) - connects to Alpine security database; `ApkBuildSecfixesExtractor` - extracts secfixes from APK build files
- **Debian Buildinfo**: `DebianCorpusConnector` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Corpus.Debian/DebianCorpusConnector.cs`) - connects to Debian buildinfo sources; `DebianMirrorPackageSource` - mirrors Debian repositories
- **RPM**: `RpmCorpusConnector` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Corpus.Rpm/RpmCorpusConnector.cs`) - connects to RPM repositories; `SrpmChangelogExtractor` - extracts changelogs from source RPMs
- **Library-specific**: `CurlCorpusConnector`, `GlibcCorpusConnector`, `OpenSslCorpusConnector`, `ZlibCorpusConnector` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Corpus/Connectors/`)
- **Interfaces**: `IBinaryCorpusConnector`, `ILibraryCorpusConnector`, `IAlpinePackageSource`, `IDebianPackageSource`, `IRpmPackageSource`
- **Package Extractors**: `AlpinePackageExtractor`, `DebianPackageExtractor`, `RpmPackageExtractor` - extract binaries from packages using `IBinaryFeatureExtractor`
## E2E Test Plan
- [ ] Connect via `AlpineCorpusConnector` and verify secfixes data is extracted from APK builds
- [ ] Connect via `DebianCorpusConnector` and verify buildinfo data is retrieved from Debian mirrors
- [ ] Connect via `RpmCorpusConnector` and verify RPM changelog extraction works
- [ ] Verify library-specific connectors (OpenSSL, glibc, curl, zlib) retrieve correct binary versions
- [ ] Verify all connectors produce `CorpusSnapshot` with consistent snapshot IDs
- [ ] Verify package extractors use `IBinaryFeatureExtractor` to extract identity features from packages
## Verification Outcome (run-001)
- Tier 0/1/2 artifacts: `docs/qa/feature-checks/runs/binaryindex/symbol-source-connectors/run-001/`
- Result: not implemented at full claim parity.
- Verified behavior:
- Alpine, Debian, and RPM mirror package source/parsing and package extractor suites execute successfully with deterministic cache-fallback behavior.
- Corpus contracts and package extractors pass local behavioral tests.
- Missing behavior:
- No Debuginfod/Buildinfo/Ddeb connector implementation classes were found in the declared module paths, despite the feature claim naming those connector families.
- Library-specific connector extraction flows remain placeholder-backed (`CurlCorpusConnector`, `GlibcCorpusConnector`, `OpenSslCorpusConnector`, `ZlibCorpusConnector`), with deb/apk extraction paths returning `null`.
- No dedicated tests were found for these library-specific connector classes, so end-to-end retrieval behavior for those connectors is not verified.

View File

@@ -0,0 +1,29 @@
# Validation Harness and Reproducibility Verification
## Module
BinaryIndex
## Status
IMPLEMENTED
## Description
Validation harness with determinism validation, SBOM stability checking, and reproducible build verification. Includes local rebuild backend and bundle export/import.
## Implementation Details
- **Modules**: `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Validation/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.GroundTruth.Reproducible/`, `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Builders/`
- **Key Classes**:
- `ValidationHarness` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.Validation/ValidationHarness.cs`) - main validation harness with `IMatcherAdapterFactory` for pluggable matching
- `ValidationHarnessService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.GroundTruth.Reproducible/ValidationHarnessService.cs`) - reproducible-build validation with `ValidationRunContext`
- `ReproducibleBuildJob` (`src/BinaryIndex/StellaOps.BinaryIndex.Worker/Jobs/ReproducibleBuildJob.cs`) - local rebuild backend
- `KpiRegressionService` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.GroundTruth.Reproducible/Services/KpiRegressionService.cs`) - SBOM stability and KPI regression tracking
- **Bundle Export/Import**: `ServiceCollectionExtensions.AddCorpusBundleExport/Import` (`src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.GroundTruth.Reproducible/ServiceCollectionExtensions.cs`)
- **Interfaces**: `IValidationHarness`, `IKpiRegressionService`, `IReproducibleBuildJob`
- **Registration**: `ValidationServiceCollectionExtensions.AddValidationHarness()`
## E2E Test Plan
- [ ] Run validation harness and verify deterministic results for identical inputs
- [ ] Verify SBOM stability checking detects unstable hash generation
- [ ] Verify reproducible build verification: rebuild from source and compare against original binary
- [ ] Verify bundle export produces a self-contained archive importable on air-gapped systems
- [ ] Verify bundle import restores corpus data and enables offline validation
- [ ] Verify KPI regression tracking across multiple validation harness runs

View File

@@ -0,0 +1,31 @@
# Doctor Check Quality Improvements (Real Diagnostics Replacing Mocks)
## Module
Doctor
## Status
PARTIALLY_IMPLEMENTED
## Description
Replaced mock implementations in PolicyEngineHealthCheck, OidcProviderConnectivityCheck, and FipsComplianceCheck with real diagnostic logic. Added discriminating evidence fields for AI reasoning and safety annotations (IsDestructive/DryRunVariant) for destructive remediation commands.
## Implementation Details
- **Policy engine check**: `src/Doctor/__Plugins/StellaOps.Doctor.Plugin.Policy/Checks/PolicyEngineHealthCheck.cs`
- **OIDC connectivity check**: `src/Doctor/__Plugins/StellaOps.Doctor.Plugin.Auth/Checks/OidcProviderConnectivityCheck.cs`
- **FIPS compliance check**: `src/Doctor/__Plugins/StellaOps.Doctor.Plugin.Crypto/Checks/FipsComplianceCheck.cs`
- **Other crypto checks**: eIDAS (`EidasComplianceCheck.cs`), GOST (`GostAvailabilityCheck.cs`), HSM (`HsmPkcs11AvailabilityCheck.cs`), SM crypto (`SmCryptoAvailabilityCheck.cs`)
- **Remediation models**: `src/__Libraries/StellaOps.Doctor/Models/RemediationStep.cs` -- includes IsDestructive/DryRunVariant safety annotations
- **Source**: SPRINT_20260118_015_Doctor_check_quality_improvements.md
## E2E Test Plan
- [ ] Verify PolicyEngineHealthCheck performs real diagnostic (not mock)
- [ ] Test OidcProviderConnectivityCheck actually probes OIDC endpoint
- [ ] Verify FipsComplianceCheck validates FIPS mode status
- [ ] Test remediation commands include safety annotations (IsDestructive, DryRunVariant)
## Verification Outcome
- Run:
un-001 on 2026-02-11 UTC.
- Tier 1 code review found claim parity gaps: Policy/Crypto plugin project roots are missing and runtime registration does not expose check.policy.engine, check.auth.oidc, or check.crypto.fips.
- Tier 2 API verification was blocked because Doctor WebService startup fails DI validation in timestamping plugin dependencies, preventing endpoint-level validation.

View File

@@ -0,0 +1,33 @@
# Doctor Diagnostic Bundle Export for Support Tickets
## Module
Doctor
## Status
PARTIALLY_IMPLEMENTED
## Description
Generates comprehensive shareable diagnostic bundles (.zip) for support tickets containing doctor check results, system configuration, evidence, and remediation suggestions. Enables self-service troubleshooting without support escalation.
## Implementation Details
- **Report storage**: `src/Doctor/StellaOps.Doctor.WebService/Services/IReportStorageService.cs` -- report storage interface
- **In-memory storage**: `src/Doctor/StellaOps.Doctor.WebService/Services/InMemoryReportStorageService.cs`
- **Postgres storage**: `src/Doctor/StellaOps.Doctor.WebService/Services/PostgresReportStorageService.cs`
- **Doctor run service**: `src/Doctor/StellaOps.Doctor.WebService/Services/DoctorRunService.cs` -- orchestrates diagnostic runs
- **Doctor endpoints**: `src/Doctor/StellaOps.Doctor.WebService/Endpoints/DoctorEndpoints.cs` -- API endpoints for triggering runs and retrieving results
- **Models**: `src/Doctor/StellaOps.Doctor.WebService/Contracts/DoctorModels.cs` -- diagnostic bundle models
- **Tests**: `src/Doctor/__Tests/StellaOps.Doctor.WebService.Tests/Services/InMemoryReportStorageServiceTests.cs`, `DoctorRunServiceTests.cs`
- **Source**: SPRINT_20260112_001_009_DOCTOR_self_service.md
## E2E Test Plan
- [ ] Verify diagnostic bundle export generates valid .zip file
- [ ] Test bundle includes check results, configuration, and remediation suggestions
- [ ] Verify bundle can be stored/retrieved via both in-memory and Postgres backends
- [ ] Test Doctor API endpoints for triggering runs and downloading bundles
## Verification Outcome
- Run: run-001 on 2026-02-11 UTC.
- Tier 1 claim-parity review showed no user-surface API endpoint for diagnostic bundle ZIP export/download and no runtime selection path for Postgres report storage.
- Tier 2 API verification was blocked because Doctor WebService startup currently fails timestamping DI validation, preventing endpoint-level behavioral checks.

View File

@@ -0,0 +1,39 @@
# Doctor Diagnostics Runner
## Module
Doctor
## Status
IMPLEMENTED
## Description
Doctor plugin infrastructure with multiple plugins (Vex, BinaryAnalysis, Notify, Observability, Timestamping) providing health checks, diagnostics, and remediation commands is implemented.
## Implementation Details
- **Plugin interface**: `src/Doctor/__Plugins/StellaOps.Doctor.Plugins.Core/IDoctorPlugin.cs` -- base plugin contract
- **Plugins** (14 total):
- Agent: `AgentDoctorPlugin.cs` -- agent health (capacity, heartbeat, version, certificates, cluster, task queue)
- Attestor: `AttestorDoctorPlugin.cs` -- Rekor, cosign, signing key, transparency log checks
- Auth: `AuthDoctorPlugin.cs` -- OIDC, signing key, token service checks
- BinaryAnalysis: `BinaryAnalysisDoctorPlugin.cs` -- debuginfod, buildinfo cache, corpus mirror, symbol recovery
- Compliance: `CompliancePlugin.cs` -- audit readiness, evidence tamper, provenance completeness, attestation signing
- Crypto: eIDAS, FIPS, GOST, HSM, SM crypto, cert chain validation checks
- Environment: `EnvironmentDoctorPlugin.cs` -- connectivity, capacity, drift, secrets, network policy
- EvidenceLocker: `EvidenceLockerDoctorPlugin.cs` -- evidence index, Merkle anchor, provenance chain
- Notify: `NotifyDoctorPlugin.cs` -- Slack, Teams, Email, Webhook connectivity checks
- Observability: `ObservabilityDoctorPlugin.cs` -- OTLP, Prometheus, log directory checks
- Operations: `OperationsDoctorPlugin.cs` -- job queue, dead letter queue, scheduler checks
- Policy: `PolicyEngineHealthCheck.cs`
- Postgres: `PostgresDoctorPlugin.cs` -- connectivity, connection pool, migration status
- Release: `ReleaseDoctorPlugin.cs` -- active release, environment readiness, promotion gates, rollback
- Scanner: `ScannerDoctorPlugin.cs` -- SBOM generation, vulnerability scan, reachability, slice cache, witness graph
- Storage: `StorageDoctorPlugin.cs` -- disk space, backup directory, evidence locker write
- Timestamping: `TimestampingHealthCheckPlugin.cs` -- TSA, OCSP, CRL, time skew, evidence staleness
- Vex: `VexDoctorPlugin.cs` -- VEX document validation, issuer trust, schema compliance
- **Source**: Feature matrix scan
## E2E Test Plan
- [ ] Verify all 14+ plugins register and execute successfully
- [ ] Test plugin discovery and loading mechanism
- [ ] Verify each plugin category produces valid health check results
- [ ] Test failure scenarios for each check type

View File

@@ -0,0 +1,35 @@
# Doctor Health Checks for Integrations
## Module
Doctor
## Status
PARTIALLY_IMPLEMENTED
## Description
Individual health checks for webhooks, Slack, Teams, email, OTLP endpoints, debuginfod, corpus mirrors, and more are implemented as pluggable Doctor checks.
## Implementation Details
- **Webhook checks**: `src/Doctor/__Plugins/StellaOps.Doctor.Plugin.Notify/Checks/WebhookConfiguredCheck.cs`, `WebhookConnectivityCheck.cs`
- **Slack checks**: `SlackConfiguredCheck.cs`, `SlackConnectivityCheck.cs`
- **Teams checks**: `TeamsConfiguredCheck.cs`, `TeamsConnectivityCheck.cs`
- **Email checks**: `EmailConfiguredCheck.cs`, `EmailConnectivityCheck.cs`
- **Queue checks**: `NotifyQueueHealthCheck.cs`
- **OTLP check**: `src/Doctor/__Plugins/StellaOps.Doctor.Plugin.Observability/Checks/OtlpEndpointCheck.cs`
- **Prometheus check**: `PrometheusScrapeCheck.cs`
- **Debuginfod check**: `src/Doctor/__Plugins/StellaOps.Doctor.Plugin.BinaryAnalysis/Checks/DebuginfodAvailabilityCheck.cs`
- **Corpus mirror check**: `CorpusMirrorFreshnessCheck.cs`
- **Tests**: `src/Doctor/__Tests/StellaOps.Doctor.Plugin.Notify.Tests/`, `StellaOps.Doctor.Plugin.Observability.Tests/`, `StellaOps.Doctor.Plugin.BinaryAnalysis.Tests/`
- **Source**: Feature matrix scan
## E2E Test Plan
- [ ] Verify webhook connectivity check probes configured endpoint
- [ ] Test Slack/Teams/Email configured checks detect missing configuration
- [ ] Verify OTLP and Prometheus checks validate endpoint reachability
- [ ] Test debuginfod and corpus mirror freshness checks
## Verification
Run: run-001 (2026-02-11)
- Tier 1 builds/tests passed for referenced plugin projects, but claim parity failed: active Doctor WebService runtime composes integration/observability plugins from src/__Libraries and does not reference src/Doctor/__Plugins/StellaOps.Doctor.Plugin.Notify.
- Tier 2 API probe confirmed service startup and health endpoints (/healthz, /readyz = 200), but /api/v1/doctor/checks returned 401 without scope-bearing auth; runtime check catalog parity could not be validated anonymously.
- Terminal outcome for this dossier: `not_implemented` (runtime claim mismatch).

View File

@@ -0,0 +1,39 @@
# Admin audit trails (comprehensive logging of changes)
## Module
Findings
## Status
PARTIALLY_IMPLEMENTED
## Description
Policy evaluation trace snapshots, evidence graph builder, and exception event auditing provide admin-level audit trails for governance.
## Implementation Details
- **Ledger Event Write Service**: `src/Findings/StellaOps.Findings.Ledger/Services/LedgerEventWriteService.cs` -- writes append-only ledger events; every finding state change, VEX decision, and policy evaluation is recorded as an immutable event with timestamp, actor, and payload.
- **Evidence Graph Builder**: `src/Findings/StellaOps.Findings.Ledger.WebService/Services/EvidenceGraphBuilder.cs` -- constructs evidence subgraphs from ledger events and attestation pointers for audit visualization.
- **Attestation Pointer Service**: `src/Findings/StellaOps.Findings.Ledger/Services/AttestationPointerService.cs` -- links findings to their attestation evidence for audit chain tracking.
- **Attestation Status Calculator**: `src/Findings/StellaOps.Findings.Ledger/Infrastructure/Attestation/AttestationStatusCalculator.cs` -- computes attestation coverage status for audit dashboards.
- **Decision Service**: `src/Findings/StellaOps.Findings.Ledger/Services/DecisionService.cs` (implements `IDecisionService`) -- records policy decisions with full trace context.
- **Decision Hook Interface**: `src/Findings/StellaOps.Findings.Ledger/Services/IDecisionHook.cs` -- extension point for hooking into decision events for custom audit processing.
- **Ledger Incident Coordinator**: `src/Findings/StellaOps.Findings.Ledger/Services/Incident/LedgerIncidentCoordinator.cs` -- coordinates incident response workflows with audit trail recording.
- **Ledger Telemetry**: `src/Findings/StellaOps.Findings.Ledger/Observability/LedgerTelemetry.cs` -- OpenTelemetry instrumentation for ledger operations providing trace-level audit visibility.
- **Ledger Timeline**: `src/Findings/StellaOps.Findings.Ledger/Observability/LedgerTimeline.cs` -- timeline view of ledger events for audit review.
- **Tests**: `src/Findings/StellaOps.Findings.Ledger.Tests/FindingsLedgerIntegrationTests.cs`, `src/Findings/__Tests/StellaOps.Findings.Ledger.Tests/LedgerEventWriteServiceTests.cs`, `src/Findings/__Tests/StellaOps.Findings.Ledger.Tests/Services/LedgerEventWriteServiceIncidentTests.cs`, `src/Findings/StellaOps.Findings.Ledger.Tests/Observability/LedgerTelemetryTests.cs`, `LedgerTimelineTests.cs`
## E2E Test Plan
- [ ] Submit a finding state change via `LedgerEventWriteService` and verify the event is recorded with correct timestamp, actor, and payload in the append-only ledger
- [ ] Query the evidence graph for a finding that has multiple audit events and verify the graph shows the chronological chain of state changes
- [ ] Trigger a policy decision and verify `DecisionService` records the full trace context (rule name, inputs, outcome) as an auditable event
- [ ] Verify incident coordination audit: create an incident via `LedgerIncidentCoordinator` and confirm the incident creation, status changes, and resolution are all recorded in the ledger
- [ ] Verify telemetry integration: perform a ledger operation and confirm OpenTelemetry spans are emitted with the correct operation name and attributes
## Verification
- Run: `docs/qa/feature-checks/runs/findings/admin-audit-trails/run-001/`
- Date (UTC): 2026-02-11
- Verdict: `not_implemented`
## Missing / Mismatched Behavior
- `DecisionService.RecordAsync` creates drafts with `SequenceNumber = 0`, but `LedgerEventWriteService` requires strict expected sequence values, so decision append behavior is not fully wired for production audit trails.
- `DecisionService.GetHistoryAsync` currently returns an empty list stub, so audit timeline retrieval is not fully implemented.
- Active WebService runtime wiring uses `NullEvidenceRepository` and `InMemoryFindingRepository`, so evidence graph and related admin audit views are scaffolded but not backed by persisted runtime data.

View File

@@ -0,0 +1,37 @@
# Attested Reduction Scoring in Findings Ledger
## Module
Findings
## Status
PARTIALLY_IMPLEMENTED
## Description
Anchor-aware evidence wiring into Findings Ledger scoring with reduction profile metadata, hard-fail flag, short-circuit reason, and anchor metadata (DSSE envelope digest, Rekor log index/entry) in API responses.
## Implementation Details
- **Finding Scoring Service**: `src/Findings/StellaOps.Findings.Ledger.WebService/Services/FindingScoringService.cs` -- computes attested reduction scores combining CVSS base score with reachability, VEX, and attestation evidence; includes anchor metadata (DSSE digest, Rekor index) in the score breakdown.
- **Finding Evidence Provider**: `src/Findings/StellaOps.Findings.Ledger.WebService/Services/FindingEvidenceProvider.cs` -- resolves evidence artifacts for scoring, including attestation anchors and proof chain references.
- **Scoring Contracts**: `src/Findings/StellaOps.Findings.Ledger.WebService/Contracts/ScoringContracts.cs` -- API DTOs including reduction profile, hard-fail flag, short-circuit reason, and anchor metadata fields.
- **Attestation Contracts**: `src/Findings/StellaOps.Findings.Ledger.WebService/Contracts/AttestationContracts.cs` -- DTOs for attestation evidence references in scoring responses.
- **Attestation Pointer Contracts**: `src/Findings/StellaOps.Findings.Ledger.WebService/Contracts/AttestationPointerContracts.cs` -- DTOs for attestation pointer queries.
- **Attestation Query Service**: `src/Findings/StellaOps.Findings.Ledger.WebService/Services/AttestationQueryService.cs` -- queries attestation evidence linked to findings for scoring input.
- **Scoring Endpoints**: `src/Findings/StellaOps.Findings.Ledger.WebService/Endpoints/ScoringEndpoints.cs` -- REST endpoints exposing scored findings with attested reduction metadata.
- **Tests**: `src/Findings/__Tests/StellaOps.Findings.Ledger.Tests/Services/FindingScoringServiceTests.cs`, `src/Findings/StellaOps.Findings.Ledger.Tests/Exports/AttestationQueryServiceTests.cs`, `src/Findings/__Tests/StellaOps.Findings.Ledger.Tests/Integration/ScoringEndpointsIntegrationTests.cs`
## E2E Test Plan
- [ ] Submit a finding with a DSSE-attested reachability proof and verify the scoring response includes the reduction from the attestation with anchor metadata (DSSE digest, Rekor log index)
- [ ] Submit a finding with a hard-fail attestation (e.g., missing required evidence) and verify the score response includes `hardFail: true` with the short-circuit reason
- [ ] Verify reduction profile: submit a finding with multiple evidence types and verify the response includes a breakdown of each reduction source and its contribution percentage
- [ ] Verify the scoring endpoint returns anchor metadata: query a scored finding and confirm the response includes `dsseEnvelopeDigest` and `rekorLogIndex` fields
- [ ] Verify short-circuit: submit a finding with an "affected" VEX status and verify scoring short-circuits with the appropriate reason without evaluating further reductions
## Verification
- Run: `docs/qa/feature-checks/runs/findings/attested-reduction-scoring-in-findings-ledger/run-001/`
- Date (UTC): 2026-02-11
- Verdict: `not_implemented`
## Missing / Mismatched Behavior
- Active runtime wiring in `Program.cs` uses `NullEvidenceRepository` and `NullAttestationVerifier`, so attested evidence/anchor metadata is not reliably sourced from persisted data paths.
- `AnchoredFindingEvidenceProvider` currently requires a GUID-resolvable finding ID to load evidence; common finding ID formats used by scoring endpoints can fall through to null evidence.
- Scoring endpoint integration tests currently allow `401/404` outcomes and do not enforce anchor metadata field presence on successful payloads, so end-to-end claim coverage remains incomplete.

View File

@@ -0,0 +1,36 @@
# CVSS/VEX Sorting (Multi-Dimension)
## Module
Findings
## Status
PARTIALLY_IMPLEMENTED
## Description
CVSS v4.0 scoring engine combined with findings summary builder supports multi-dimensional sorting by CVSS and VEX status.
## Implementation Details
- **Finding Summary Builder**: `src/Findings/StellaOps.Findings.Ledger.WebService/Services/FindingSummaryBuilder.cs` -- builds finding summaries with sortable dimensions including CVSS score, VEX status, severity, and component name.
- **Finding Summary Service**: `src/Findings/StellaOps.Findings.Ledger.WebService/Services/FindingSummaryService.cs` -- queries and sorts finding summaries by multiple dimensions.
- **Finding Summary Endpoints**: `src/Findings/StellaOps.Findings.Ledger.WebService/Endpoints/FindingSummaryEndpoints.cs` -- REST endpoints for querying sorted finding summaries with multi-dimension ordering.
- **Finding Summary DTO**: `src/Findings/StellaOps.Findings.Ledger.WebService/Contracts/FindingSummary.cs` -- API response model including CVSS score, VEX status, severity level, and component identity.
- **VEX Consensus Service**: `src/Findings/StellaOps.Findings.Ledger.WebService/Services/VexConsensusService.cs` -- aggregates VEX decisions across multiple sources to determine consensus status for sorting.
- **VEX Lens Contracts**: `src/Findings/StellaOps.Findings.Ledger.WebService/Contracts/VexLensContracts.cs` -- DTOs for VEX status data used in multi-dimension sorting.
- **Tests**: `src/Findings/__Tests/StellaOps.Findings.Ledger.Tests/Services/FindingSummaryBuilderTests.cs`, `src/Findings/__Tests/StellaOps.Findings.Ledger.Tests/ScoredFindingsQueryServiceTests.cs`
## E2E Test Plan
- [ ] Query finding summaries sorted by CVSS score descending and verify the results are ordered from highest to lowest CVSS score
- [ ] Query finding summaries sorted by VEX status and verify findings are grouped by status (affected, not_affected, under_investigation, fixed)
- [ ] Apply multi-dimension sorting (primary: VEX status, secondary: CVSS score) and verify the ordering respects both dimensions
- [ ] Verify findings with no VEX status are sorted correctly (treated as "no_vex" or equivalent default)
- [ ] Submit findings with mixed CVSS v3.1 and v4.0 scores and verify the summary builder normalizes them for consistent sorting
## Verification
- Run: `docs/qa/feature-checks/runs/findings/cvss-vex-sorting/run-001/`
- Date (UTC): 2026-02-11
- Verdict: `not_implemented`
## Missing / Mismatched Behavior
- Current summary API/service surface does not expose sort field/direction inputs required for CVSS/VEX multi-dimension ordering.
- Active runtime composition still uses an in-memory finding repository that returns empty/null data, so asserted sort semantics are not realized through user-surface paths.
- Tier 2 probe validates request/response status paths, but claim-level ordering semantics (VEX-primary, CVSS-secondary) are not implemented end-to-end.

View File

@@ -0,0 +1,37 @@
# Ledger Projections
## Module
Findings
## Status
PARTIALLY_IMPLEMENTED
## Description
Projection worker that materializes event streams into queryable read models.
## Implementation Details
- **Ledger Projection Worker**: `src/Findings/StellaOps.Findings.Ledger/Infrastructure/Projection/LedgerProjectionWorker.cs` -- background worker that consumes ledger event streams and materializes them into queryable projection read models.
- **Ledger Projection Reducer**: `src/Findings/StellaOps.Findings.Ledger/Services/LedgerProjectionReducer.cs` -- reduces event sequences into projection state, applying each event to build the current finding state from its event history.
- **Projection Models**: `src/Findings/StellaOps.Findings.Ledger/Domain/ProjectionModels.cs` -- read-side projection models materialized from events (finding state, VEX status, scoring state).
- **Projection Hashing**: `src/Findings/StellaOps.Findings.Ledger/Hashing/ProjectionHashing.cs` -- computes deterministic hashes of projection state for consistency verification between replays.
- **Finding Projection Repository Interface**: `src/Findings/StellaOps.Findings.Ledger/Infrastructure/IFindingProjectionRepository.cs` -- persistence contract for materialized projections.
- **Postgres Finding Projection Repository**: `src/Findings/StellaOps.Findings.Ledger/Infrastructure/Postgres/PostgresFindingProjectionRepository.cs` -- PostgreSQL persistence for projection read models.
- **Tests**: `src/Findings/__Tests/StellaOps.Findings.Ledger.Tests/LedgerProjectionReducerTests.cs`, `src/Findings/StellaOps.Findings.Ledger.Tests/ProjectionHashingTests.cs`
## E2E Test Plan
- [ ] Submit a sequence of finding events (create, update VEX, add attestation) and verify the projection worker materializes the final finding state with correct VEX status and attestation references
- [ ] Verify projection consistency: replay the same event sequence twice and confirm the projection hashes match (deterministic projection)
- [ ] Verify projection catch-up: stop the projection worker, submit events, restart the worker, and confirm it processes all missed events and reaches the correct state
- [ ] Verify the projection reducer correctly handles out-of-order event delivery by ordering events by sequence number before applying
- [ ] Query the materialized projection via the finding query endpoints and verify the response matches the expected state from the event history
## Verification
- Run: `docs/qa/feature-checks/runs/findings/ledger-projections/run-001/`
- Date (UTC): 2026-02-11
- Verdict: `not_implemented`
## Missing / Mismatched Behavior
- The feature claim for out-of-order event handling is not satisfied in current runtime flow.
- `LedgerProjectionWorker` applies events in received batch order without sequence reordering before reduction (`src/Findings/StellaOps.Findings.Ledger/Infrastructure/Projection/LedgerProjectionWorker.cs`).
- `LedgerProjectionReducer` reduces one event at a time and does not perform ordering itself (`src/Findings/StellaOps.Findings.Ledger/Services/LedgerProjectionReducer.cs`).
- Existing determinism tests include an ordering-sensitive path, reinforcing that ordering is caller-controlled rather than runtime-enforced for projection catch-up/out-of-order handling.

View File

@@ -0,0 +1,38 @@
# Advisory Locks / LISTEN-NOTIFY
## Module
Platform
## Status
NOT_IMPLEMENTED
## Description
Advisory lock patterns are used in classification history for safe concurrent updates; LISTEN/NOTIFY patterns support real-time event propagation.
## Implementation Details
- **PlatformAnalyticsMaintenanceService**: `src/Platform/StellaOps.Platform.WebService/Services/PlatformAnalyticsMaintenanceService.cs` -- BackgroundService using PeriodicTimer to run analytics maintenance; calls `REFRESH MATERIALIZED VIEW CONCURRENTLY` for `analytics.mv_supplier_concentration`, `analytics.mv_license_distribution`, `analytics.mv_vuln_exposure`, `analytics.mv_attestation_coverage`; uses `SELECT analytics.compute_daily_rollups(@date)` for daily rollup computation
- **AnalyticsIngestionDataSource**: `src/Platform/StellaOps.Platform.Analytics/Services/AnalyticsIngestionDataSource.cs` -- PostgreSQL data source for analytics with connection management
- **VulnerabilityCorrelationService**: `src/Platform/StellaOps.Platform.Analytics/Services/VulnerabilityCorrelationService.cs` -- correlates vulnerabilities with SBOM components using PURL matching
- **ScannerOrchestratorEvents**: `src/Platform/StellaOps.Platform.Analytics/Models/ScannerOrchestratorEvents.cs` -- event models for scanner report ready / scan completed events via event streams
- **Source**: Feature matrix scan
## E2E Test Plan
- [ ] Verify advisory locks prevent concurrent classification history updates
- [ ] Test LISTEN/NOTIFY propagates real-time events to subscribers
- [ ] Verify materialized view concurrent refresh completes without locking reads
- [ ] Test daily rollup computation produces correct aggregates for a given date
## Verification
- Re-verified on 2026-02-11 via `run-002`.
- Confirmed implemented behavior:
- `PlatformAnalyticsMaintenanceService` executes `SELECT analytics.compute_daily_rollups(@date)` and `REFRESH MATERIALIZED VIEW CONCURRENTLY ...` commands.
- `PlatformAnalyticsMaintenanceServiceTests` and `AnalyticsSchemaIntegrationTests` pass for rollup/materialized-view behavior (`23/23` in scoped runs).
- Missing behavior relative to feature claim:
- No advisory lock implementation signal (`pg_advisory*`) found under `src/Platform`.
- No PostgreSQL LISTEN/NOTIFY implementation signal (`LISTEN`, `NOTIFY`, `NpgsqlConnection.Notification`) found under `src/Platform`.
- Classification: feature claim is partially implemented and terminalized as `not_implemented` until advisory lock and LISTEN/NOTIFY behavior is actually implemented.
- Evidence:
- `docs/qa/feature-checks/runs/platform/advisory-locks-listen-notify/run-002/tier0-source-check.json`
- `docs/qa/feature-checks/runs/platform/advisory-locks-listen-notify/run-002/tier1-build-check.json`
- `docs/qa/feature-checks/runs/platform/advisory-locks-listen-notify/run-002/tier2-integration-check.json`
- `docs/qa/feature-checks/runs/platform/advisory-locks-listen-notify/run-002/evidence/04b-missing-advisory-listen-notify-signal.txt`

View File

@@ -0,0 +1,31 @@
# Base Image Detection and Recommendations
## Module
Scanner
## Status
IMPLEMENTED
## Description
Base image detection via layer diffID fingerprinting with PostgreSQL-backed fingerprint database, in-memory index, exact layer match and fuzzy matching, and bulk detection support. Interface `IBaseImageDetector` with full `BaseImageDetector` implementation.
## Implementation Details
- **Core Detection**:
- `src/Scanner/__Libraries/StellaOps.Scanner.Manifest/Resolution/IBaseImageDetector.cs` - `IBaseImageDetector` interface
- `src/Scanner/__Libraries/StellaOps.Scanner.Manifest/Resolution/BaseImageDetector.cs` - `BaseImageDetector` with exact layer match and fuzzy matching, bulk detection support
- **Layer Resolution**:
- `src/Scanner/__Libraries/StellaOps.Scanner.Manifest/Resolution/ILayerDigestResolver.cs` - Interface for resolving layer digests
- `src/Scanner/__Libraries/StellaOps.Scanner.Manifest/Resolution/LayerDigestResolver.cs` - Resolves layer diffIDs for fingerprint matching
- `src/Scanner/__Libraries/StellaOps.Scanner.Manifest/Resolution/LayerProvenance.cs` - Layer provenance tracking for base image attribution
- **Layer Reuse Detection**:
- `src/Scanner/__Libraries/StellaOps.Scanner.Manifest/Reuse/ILayerReuseDetector.cs` - Interface for layer reuse detection
- `src/Scanner/__Libraries/StellaOps.Scanner.Manifest/Reuse/LayerReuseDetector.cs` - Detects shared layers between images for base image identification
- **DI Registration**: `src/Scanner/__Libraries/StellaOps.Scanner.Manifest/ManifestServiceCollectionExtensions.cs`
## E2E Test Plan
- [ ] Scan an image built on a known base image (e.g., `debian:bookworm`) and verify `IBaseImageDetector` identifies the correct base image
- [ ] Verify exact layer match identifies base images by diffID fingerprint comparison
- [ ] Test fuzzy matching with a slightly modified base image (e.g., additional layer) and verify partial match is returned with confidence score
- [ ] Test bulk detection by submitting multiple image references and verify all base images are identified in a single operation
- [ ] Verify base image detection results appear in the scan report and SBOM metadata
- [ ] Verify layer provenance tracking attributes vulnerability findings to base image vs application layers

View File

@@ -0,0 +1,36 @@
# Scheduler Exception Lifecycle Worker
## Module
Scheduler
## Status
PARTIALLY_IMPLEMENTED
## Description
Background worker that monitors exception expiries and triggers policy re-evaluation when exceptions lapse, enforcing time-bounded risk acceptance.
## Implementation Details
- **Exception Lifecycle Worker**: `src/Scheduler/StellaOps.Scheduler.WebService/ExceptionLifecycle/ExceptionLifecycleWorker.cs` -- background `IHostedService` that periodically scans for expiring or expired policy exceptions and triggers re-evaluation of affected findings.
- **Exception Lifecycle Endpoints**: `src/Scheduler/StellaOps.Scheduler.WebService/ExceptionLifecycle/ExceptionLifecycleEndpointExtensions.cs` -- REST endpoints for querying exception status and managing exception lifecycle.
- **Exception Lifecycle Contracts**: `src/Scheduler/StellaOps.Scheduler.WebService/ExceptionLifecycle/ExceptionLifecycleContracts.cs` -- DTOs for exception status, expiry notifications, and lifecycle transitions.
- **Exception Repository**: `src/Scheduler/StellaOps.Scheduler.WebService/ExceptionLifecycle/IExceptionRepository.cs` -- persistence contract for policy exceptions with expiry tracking.
- **Failure Signature Endpoints**: `src/Scheduler/StellaOps.Scheduler.WebService/FailureSignatures/FailureSignatureEndpoints.cs` -- endpoints for managing failure signatures that may trigger exception expiry.
- **Webhook Endpoints**: `src/Scheduler/StellaOps.Scheduler.WebService/EventWebhooks/EventWebhookEndpointExtensions.cs` -- webhook endpoints for notifying external systems of exception lifecycle events.
- **Tests**: `src/Scheduler/__Tests/StellaOps.Scheduler.WebService.Tests/ExceptionLifecycle/ExceptionLifecycleWorkerTests.cs`, `ExceptionLifecycleEndpointsTests.cs`
## E2E Test Plan
- [ ] Create a policy exception with a 1-minute expiry; after expiry, verify the exception lifecycle worker triggers a re-evaluation event for the affected finding
- [ ] Query the exception lifecycle endpoint and verify active exceptions are listed with their remaining TTL
- [ ] Verify exception renewal: extend an exception's expiry before it lapses and confirm the worker does not trigger re-evaluation
- [ ] Verify webhook notification: configure a webhook endpoint and confirm it receives a notification when an exception expires
- [ ] Create multiple exceptions with staggered expiries and verify the worker processes them in expiry order
## Not Implemented Findings
- Tier 0 source verification (run-002) found 6/8 referenced files missing (ratio: 0.75).
- WebService exception-lifecycle endpoint/contracts/repository files referenced by this feature are absent.
- Referenced exception-lifecycle WebService test files are absent.
- Worker code exists at `src/Scheduler/__Libraries/StellaOps.Scheduler.Worker/Exception/ExceptionLifecycleWorker.cs`, but the documented end-user API surface is not present.
## Verification
- Classified as `not_implemented` at Tier 0 on 2026-02-11 (run-002).
- Evidence: `docs/qa/feature-checks/runs/scheduler/scheduler-exception-lifecycle-worker/run-002/tier0-source-check.json`

View File

@@ -0,0 +1,32 @@
# Scheduler ImpactIndex and Surface.FS Pointers
## Module
Scheduler
## Status
PARTIALLY_IMPLEMENTED
## Description
ImpactIndex computation for prioritizing scheduled vulnerability evaluations, with Surface.FS pointers linking scheduler jobs to filesystem-level SBOM surface data for efficient incremental rescans.
## Implementation Details
- **Impact Index Service**: `src/Scheduler/StellaOps.Scheduler.WebService/ImpactIndex/ImpactIndexService.cs` -- computes impact index scores for scheduled jobs based on vulnerability severity, component exposure, and deployment topology.
- **Impact Index Endpoints**: `src/Scheduler/StellaOps.Scheduler.WebService/ImpactIndex/ImpactIndexEndpointExtensions.cs` -- REST endpoints for querying and updating impact index scores.
- **Impact Index Contracts**: `src/Scheduler/StellaOps.Scheduler.WebService/ImpactIndex/ImpactIndexContracts.cs` -- DTOs for impact index query/update operations.
- **Surface FS Pointers**: `src/Scheduler/StellaOps.Scheduler.WebService/SurfaceFs/SurfaceFsPointerService.cs` -- manages filesystem-level pointers linking SBOM surface data to scheduler jobs for incremental rescan optimization.
- **Surface FS Endpoints**: `src/Scheduler/StellaOps.Scheduler.WebService/SurfaceFs/SurfaceFsEndpointExtensions.cs` -- REST endpoints for managing Surface.FS pointers.
- **Surface FS Contracts**: `src/Scheduler/StellaOps.Scheduler.WebService/SurfaceFs/SurfaceFsContracts.cs` -- DTOs for Surface.FS pointer operations.
- **Scan Schedule Service**: `src/Scheduler/StellaOps.Scheduler.WebService/Scheduling/ScanScheduleService.cs` -- schedules vulnerability rescans prioritized by impact index.
- **Tests**: `src/Scheduler/__Tests/StellaOps.Scheduler.WebService.Tests/ImpactIndex/ImpactIndexServiceTests.cs`, `ImpactIndexEndpointsTests.cs`; `src/Scheduler/__Tests/StellaOps.Scheduler.WebService.Tests/SurfaceFs/SurfaceFsPointerServiceTests.cs`
## E2E Test Plan
- [ ] Compute an impact index for a component with a critical CVE in a production deployment and verify the score is higher than for the same CVE in a staging deployment.
- [ ] Create a Surface.FS pointer linking a scheduler job to an SBOM surface file and verify pointer lookup by job ID.
- [ ] Verify incremental rescan behavior for changed components only.
- [ ] Verify impact-based prioritization order for queued jobs.
- [ ] Query impact index scores via REST and verify descending sort.
## Missing Implementation Evidence
- Tier 0 run-001 found 7/7 referenced implementation files missing under `src/Scheduler/StellaOps.Scheduler.WebService/ImpactIndex`, `src/Scheduler/StellaOps.Scheduler.WebService/SurfaceFs`, and `src/Scheduler/StellaOps.Scheduler.WebService/Scheduling`.
- Classification: `not_implemented` per FLOW (>50% key file references absent).
- Evidence: `docs/qa/feature-checks/runs/scheduler/scheduler-impactindex-and-surface-fs-pointers/run-001/tier0-source-check.json`