save checkpoint: save features
This commit is contained in:
master
39
docs/features/unimplemented/findings/admin-audit-trails.md
Normal file
39
docs/features/unimplemented/findings/admin-audit-trails.md
Normal 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.
|
||||
@@ -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.
|
||||
36
docs/features/unimplemented/findings/cvss-vex-sorting.md
Normal file
36
docs/features/unimplemented/findings/cvss-vex-sorting.md
Normal 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.
|
||||
37
docs/features/unimplemented/findings/ledger-projections.md
Normal file
37
docs/features/unimplemented/findings/ledger-projections.md
Normal 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.
|
||||
Reference in New Issue
Block a user