partly or unimplemented features - now implemented
This commit is contained in:
master
@@ -402,14 +402,33 @@ When configured, the worker runs the `reachability-analysis` stage to infer depe
|
||||
|
||||
Configuration lives in `src/Scanner/docs/sbom-reachability-filtering.md`, including policy schema, metadata keys, and report outputs.
|
||||
|
||||
### 5.5.6 VEX decision filter with reachability (Sprint 20260208_062)
|
||||
|
||||
Scanner now exposes a deterministic VEX+reachability matrix filter for triage pre-processing:
|
||||
|
||||
- Gate matrix component: `StellaOps.Scanner.Gate/VexReachabilityDecisionFilter` evaluates `(vendorStatus, reachabilityTier)` and returns one of `suppress`, `elevate`, `pass_through`, or `flag_for_review`.
|
||||
- Matrix examples: `(not_affected, unreachable) -> suppress`, `(affected, confirmed|likely) -> elevate`, `(not_affected, confirmed|likely) -> flag_for_review`.
|
||||
- API surface: `POST /api/v1/scans/vex-reachability/filter` accepts finding batches and returns annotated decisions plus action summary counts.
|
||||
- Determinism: batch order is preserved, rule IDs are explicit, and no network lookups are required for matrix evaluation.
|
||||
|
||||
### 5.5.7 Vulnerability-first triage clustering APIs (Sprint 20260208_063)
|
||||
|
||||
Scanner triage now includes deterministic exploit-path clustering primitives for vulnerability-first triage workflows:
|
||||
|
||||
- Core clustering service: `StellaOps.Scanner.Triage/Services/ExploitPathGroupingService` groups findings using common call-chain prefix similarity with configurable thresholds.
|
||||
- Inbox enhancements: `GET /api/v1/triage/inbox` supports `similarityThreshold`, `sortBy`, and `descending` for deterministic cluster filtering/sorting.
|
||||
- Cluster statistics: `GET /api/v1/triage/inbox/clusters/stats` returns per-cluster severity counts, reachability distribution, and priority scores.
|
||||
- Batch triage actions: `POST /api/v1/triage/inbox/clusters/{pathId}/actions` applies one action to all findings in the cluster and emits deterministic action records.
|
||||
- Offline/determinism posture: no network calls, stable ordering by IDs/path IDs, deterministic path-ID hashing, and replayable batch payload digests.
|
||||
|
||||
### 5.6 DSSE attestation (via Signer/Attestor)
|
||||
|
||||
* WebService constructs **predicate** with `image_digest`, `stellaops_version`, `license_id`, `policy_digest?` (when emitting **final reports**), timestamps.
|
||||
* Calls **Signer** (requires **OpTok + PoE**); Signer verifies **entitlement + scanner image integrity** and returns **DSSE bundle**.
|
||||
* **Attestor** logs to **Rekor v2**; returns `{uuid,index,proof}` → stored in `artifacts.rekor`.
|
||||
* **Verdict OCI idempotency**: `push-verdict` computes `sha256` idempotency from DSSE envelope bytes, writes `org.stellaops.idempotency.key`, uses stable `verdict-<hash>` manifest tags, retries transient push failures (429/5xx/timeouts), and treats conflict/already-submitted responses as success.
|
||||
* **Hybrid reachability attestations**: graph-level DSSE (mandatory) plus optional edge-bundle DSSEs for runtime/init/contested edges. See [`docs/modules/reach-graph/guides/hybrid-attestation.md`](../reach-graph/guides/hybrid-attestation.md) for verification runbooks and Rekor guidance.
|
||||
* Operator enablement runbooks (toggles, env-var map, rollout guidance) live in [`operations/dsse-rekor-operator-guide.md`](operations/dsse-rekor-operator-guide.md) per SCANNER-ENG-0015.
|
||||
* WebService constructs **predicate** with `image_digest`, `stellaops_version`, `license_id`, `policy_digest?` (when emitting **final reports**), timestamps.
|
||||
* Calls **Signer** (requires **OpTok + PoE**); Signer verifies **entitlement + scanner image integrity** and returns **DSSE bundle**.
|
||||
* **Attestor** logs to **Rekor v2**; returns `{uuid,index,proof}` → stored in `artifacts.rekor`.
|
||||
* **Verdict OCI idempotency**: `push-verdict` computes `sha256` idempotency from DSSE envelope bytes, writes `org.stellaops.idempotency.key`, uses stable `verdict-<hash>` manifest tags, retries transient push failures (429/5xx/timeouts), and treats conflict/already-submitted responses as success.
|
||||
* **Hybrid reachability attestations**: graph-level DSSE (mandatory) plus optional edge-bundle DSSEs for runtime/init/contested edges. See [`docs/modules/reach-graph/guides/hybrid-attestation.md`](../reach-graph/guides/hybrid-attestation.md) for verification runbooks and Rekor guidance.
|
||||
* Operator enablement runbooks (toggles, env-var map, rollout guidance) live in [`operations/dsse-rekor-operator-guide.md`](operations/dsse-rekor-operator-guide.md) per SCANNER-ENG-0015.
|
||||
|
||||
---
|
||||
|
||||
@@ -641,7 +660,7 @@ Diagnostics drive two metrics published by `EntryTraceMetrics`:
|
||||
|
||||
Structured logs include `entrytrace.path`, `entrytrace.command`, `entrytrace.reason`, and `entrytrace.depth`, all correlated with scan/job IDs. Timestamps are normalized to UTC (microsecond precision) to keep DSSE attestations and UI traces explainable.
|
||||
|
||||
### Appendix B — BOM‑Index sidecar
|
||||
### Appendix B — BOM‑Index sidecar
|
||||
|
||||
```
|
||||
struct Header { magic, version, imageDigest, createdAt }
|
||||
@@ -649,3 +668,43 @@ vector<string> purls
|
||||
map<purlIndex, roaring_bitmap> components
|
||||
optional map<purlIndex, roaring_bitmap> usedByEntrypoint
|
||||
```
|
||||
|
||||
### Appendix C — Stack-Trace Exploit Path View (Sprint 061)
|
||||
|
||||
The Triage library provides a stack-trace–style visualization layer on top of `ExploitPath`
|
||||
clusters, designed for UI rendering as collapsible call-chain frames.
|
||||
|
||||
#### Models (`StellaOps.Scanner.Triage.Models`)
|
||||
|
||||
| Type | Purpose |
|
||||
|------|---------|
|
||||
| `StackTraceExploitPathView` | Root view: ordered frames, CVE IDs, severity label, collapsed state |
|
||||
| `StackTraceFrame` | Single frame: symbol, role, source location, snippet, gate label |
|
||||
| `SourceSnippet` | Syntax-highlighted source extract at a frame location |
|
||||
| `FrameRole` | Entrypoint / Intermediate / Sink / GatedIntermediate |
|
||||
| `StackTraceViewRequest` | Build request with source mappings and gate labels |
|
||||
|
||||
#### Frame Role Assignment
|
||||
|
||||
| Position | Has Gate | Role |
|
||||
|----------|----------|------|
|
||||
| First | — | Entrypoint |
|
||||
| Last | — | Sink |
|
||||
| Middle | No | Intermediate |
|
||||
| Middle | Yes | GatedIntermediate |
|
||||
|
||||
#### Collapse Heuristic
|
||||
|
||||
Paths with > 3 frames are collapsed by default in the UI (showing only entrypoint + sink).
|
||||
The user can expand to see the full call chain.
|
||||
|
||||
#### Service (`IStackTraceExploitPathViewService`)
|
||||
|
||||
- `BuildView(StackTraceViewRequest)` — transforms a single `ExploitPath` into a `StackTraceExploitPathView`
|
||||
- `BuildViews(IReadOnlyList<StackTraceViewRequest>)` — batch transformation, ordered by priority score descending then path ID for determinism
|
||||
|
||||
#### Source Snippet Integration
|
||||
|
||||
When source mappings are provided (keyed by `file:line`), the service attaches
|
||||
`SourceSnippet` records to matching frames. This enables syntax-highlighted code
|
||||
display in the UI without requiring the scanner to store full source files.
|
||||
|
||||
Reference in New Issue
Block a user