stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity
Files
b07d27772e768cc6ec312cab207b1f2a977b7a81
git.stella-ops.org/docs/modules/ui/v2-rewire/pack-17.md
master c2f13fe588 preparation for ui re-shelling
2026-02-18 23:03:07 +02:00

32 KiB
Raw Blame History

Pack 17 — Approvals upgraded: SBOM + Crit‑Reachable by env, SBOM freshness/coverage, Hybrid Reachability (B/I/R), and Data Integrity confidence (feeds/jobs/integrations) shown inside the approval flow

This pack does not add new top-level areas. It upgrades Approvals so approvers can make defensible decisions without hunting across Security/Ops/Integrations.

17.1 Approvals menu graph (Mermaid)

flowchart TD
  APPR[Approvals] --> Q[Approvals Queue]
  Q --> AD[Approval Detail]

  AD --> AD_OV[Overview]
  AD --> AD_G[Gate Trace]
  AD --> AD_S[Security\n(SBOM + Findings)]
  AD --> AD_R[Reachability\n(Hybrid B/I/R)]
  AD --> AD_D[Ops/Data Health\n(Data Integrity)]
  AD --> AD_E[Evidence\n(Decision Packet)]
  AD --> AD_RV[Replay/Verify]
  AD --> AD_H[History]

  %% Cross-links (2nd-class, not duplication)
  AD_D -. "links to" .-> DI[Operations: Data Integrity]
  AD_S -. "links to" .-> FIND[Security: Findings]
  AD_S -. "links to" .-> VEX[Security: VEX Hub]
  AD_E -. "links to" .-> EXPORT[Evidence: Export Center]
  AD_G -. "links to" .-> GOV[Release Control: Governance]
  AD_R -. "links to" .-> RCENV[Release Control: Env Detail]
  AD_OV -. "links to" .-> BV[Bundle Version Detail]

17.2 Screen — Approvals Queue (v2)

Formerly

  • Approvals (/approvals) Cards/rows: bundle/release, env path, policy PASS/BLOCK, approvals count, approve/reject.

Why changed like this

You asked for:

  • “X environments with critical reachable issues” surfaced early,
  • “nightly jobs status when SBOM rescan/CVE feeds/integrations are broken,”
  • “hybrid reachability as second-class (not buried).”

So the queue now shows, per approval item:

  • Target env risk snapshot (Crit reachable counts in that env)
  • SBOM freshness/coverage (so you can see “stale/unknown” immediately)
  • Hybrid reachability coverage (Build/Image/Runtime) as a compact confidence indicator
  • Data Integrity confidence (feeds/jobs/integrations) as a banner/badge

Queue screen graph (Mermaid)

flowchart LR
  Q[Approvals Queue] --> F[Filters\n(region/env/status/risk/data-health)]
  Q --> AD[Open Approval Detail]
  Q --> BV[Open Bundle Version Detail]
  Q --> DI[Open Ops: Data Integrity (filtered)]
  Q --> FIND[Open Findings (filtered)]
  Q --> RCENV[Open Env Detail]

ASCII mock — Approvals Queue (v2)

┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ APPROVALS                                                                                      │
│ Formerly: Approvals (/approvals)                                                               │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filters: Status [Pending]  Region [All]  Env [All]  Risk [All]  Data Health [All]             │
│ Banner: Data Integrity WARN — NVD stale 3h | SBOM rescan FAILED | Runtime ingest lagging       │
│         [Open Data Integrity]                                                                  │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌───────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Platform Release 1.3.0-rc1  (manifest sha256:beef...)                                       │ │
│ │ Target: EU-West  eu-stage → eu-prod                                                         │ │
│ │ Justification: scheduled release (rate limiting + bug fixes)                                 │ │
│ │ Gates: BLOCK (2/4)   Approvals: 0/2                                                          │ │
│ │ Target-env risk: eu-prod → CritR=1 | HighR=0 | HighNR=3 | VEX=62%                             │ │
│ │ SBOM status: 1 pending scan | freshness: WARN (26h)                                          │ │
│ │ Hybrid reach: Build 78% | Image 100% | Runtime 35%                                           │ │
│ │ Data health: WARN (NVD stale; rescan failed)                                                 │ │
│ │ Actions: [View Details] [Approve]* [Reject] [Open Env] [Open Findings]                       │ │
│ │ *Approve disabled until blocking gates resolved OR exception approved                         │ │
│ └───────────────────────────────────────────────────────────────────────────────────────────┘ │
│ ┌───────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Hotfix Bundle 1.2.4  (manifest sha256:abcd...)                                               │ │
│ │ Target: US-East  us-stage → us-prod                                                          │ │
│ │ Justification: critical auth timeout fix                                                      │ │
│ │ Gates: PASS (4/4)   Approvals: 1/2                                                           │ │
│ │ Target-env risk: us-prod → clean                                                             │ │
│ │ SBOM status: OK | freshness: OK (2h)                                                         │ │
│ │ Hybrid reach: Build 100% | Image 100% | Runtime 80%                                          │ │
│ │ Data health: OK                                                                              │ │
│ │ Actions: [View Details] [Approve] [Reject]                                                   │ │
│ └───────────────────────────────────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────────────────────────────┘

17.3 Screen — Approval Detail: Overview (v2)

Formerly

  • “View Details” from Approvals cards (not fully structured), with some gate summary.

Why changed like this

Approver needs a single-page decision briefing:

  • What is being approved: Bundle Version + manifest digest
  • Where: region + env path
  • Risk: Crit reachable in target env + delta vs current
  • Confidence: SBOM freshness/coverage + hybrid reachability coverage + data integrity
  • Audit: quick link to decision packet and replay/verify

Overview screen graph (Mermaid)

flowchart TD
  AD[Approval Detail] --> OV[Overview]
  OV --> G[Gates tab]
  OV --> S[Security tab]
  OV --> R[Reachability tab]
  OV --> D[Ops/Data tab]
  OV --> E[Evidence tab]
  OV --> RV[Replay/Verify tab]
  OV --> H[History tab]

  OV --> BV[Bundle Version Detail]
  OV --> RCENV[Env Detail]
  OV --> DI[Data Integrity (filtered)]

ASCII mock — Approval Detail Overview (v2)

┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ APPROVAL DETAIL                                                                                │
│ Formerly: Approvals → “View Details” card (limited context)                                    │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Bundle Version: Platform Release 1.3.0-rc1   manifest sha256:beef...                           │
│ Target: EU-West  eu-stage → eu-prod       Workflow: Canary 10→50→100                           │
│ Requested by: alice.johnson   Requested: 36d ago                                                │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Decision readiness                                                                              │
│  Gates: BLOCK (2/4)  | Approvals: 0/2                                                           │
│  Target-env risk (eu-prod): CritR=1 | HighR=0 | HighNR=3 | VEX=62%                               │
│  SBOM: 1 component pending scan | freshness WARN (26h)                                          │
│  Hybrid reach coverage: Build 78% | Image 100% | Runtime 35%                                    │
│  Data Integrity: WARN (NVD stale 3h; rescan job FAIL; Jenkins degraded)                         │
│                                                                                                 │
│ Actions: [Approve]* [Reject] [Request Exception] [Export Decision Packet] [Replay/Verify]      │
│ *Approve disabled until blocking gates resolved or exception approved                           │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Tabs: [Gates] [Security] [Reachability] [Ops/Data] [Evidence] [Replay/Verify] [History]        │
└──────────────────────────────────────────────────────────────────────────────────────────────┘

17.4 Screen — Approval Detail: Gates (Trace + “why” + timestamps)

Formerly

  • PASS/BLOCK indicator, sometimes with a short reason.

Why changed like this

Approver must see:

  • which gate failed,
  • exactly why,
  • which datasets/timestamps were used,
  • whether results are “hard fail” vs “warn due to missing confidence”,
  • and where to fix (links to Data Integrity / Env Inputs / Findings / Exceptions).

Gates screen graph (Mermaid)

flowchart TD
  G[Gates tab] --> GT[Gate table (PASS/WARN/BLOCK)]
  GT --> GD[Gate detail trace (inputs, timestamps, hashes)]
  G --> GOV[Release Control: Governance baseline/rules]
  G --> DI[Ops: Data Integrity (why stale?)]
  G --> FIND[Security: Findings (blocking CVE)]
  G --> EX[Security: Exceptions (request/track)]
  G --> RV[Replay/Verify this gate evaluation]

ASCII mock — Gates (Trace)

┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Gates (Trace)                                                                                  │
│ Formerly: PASS/BLOCK on approvals card, limited trace                                           │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Baseline: Prod-EU-West   Evaluated: Feb 18, 08:30                                               │
│ Data snapshot: OSV 20m | NVD 3h (WARN) | SBOM rescan FAIL (stale>24h present)                   │
│ Decision digest: sha256:dd77...   (exported in Evidence tab)                                    │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Gate                          Result   Why                                                     │
│------------------------------------------------------------------------------------------------│
│ Inputs materialized            PASS     Vault/Consul resolved, 0 missing bindings              │
│ SBOM completeness              BLOCK    worker digest pending scan (required for prod)         │
│ Critical reachable CVEs        BLOCK    CVE-2026-1234 reachable in eu-prod; no VEX             │
│ Feed freshness                 WARN     NVD stale 3h (baseline threshold 2h)                   │
│ Runtime reach coverage         WARN     runtime evidence 35% (baseline: warn)                  │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Fix links: [Trigger SBOM Scan] [Open Finding] [Request Exception] [Open Data Integrity]        │
│ Forensics: [Replay Gate Eval] [Open Governance Rules]                                           │
└──────────────────────────────────────────────────────────────────────────────────────────────┘

17.5 Screen — Approval Detail: Security (SBOM + Findings, by env, with delta)

Formerly

  • Security findings were under Security → Findings, detached from the approval.

Why changed like this

Approver must see:

  • which env is impacted (eu-prod vs eu-stage)
  • whether the promotion introduces the risk or it already exists
  • SBOM status per component (missing/pending/stale)
  • VEX coverage and exceptions posture

Hybrid reachability remains separate tab; here we focus on “what the SBOM says + what the scanner says.”

Security tab graph (Mermaid)

flowchart TD
  S[Security tab] --> SUM[Summary by severity + reachability class]
  S --> ENV[By-environment breakdown]
  S --> DELTA[Delta vs currently deployed in target env]
  S --> CVE[Top CVEs / packages list]
  S --> VEX[VEX Hub (filtered)]
  S --> FIND[Findings (filtered)]
  S --> EX[Exceptions (filtered)]

ASCII mock — Security tab

┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Security (SBOM + Findings)                                                                     │
│ Formerly: Security → Findings / Overview (manual filtering from approvals)                      │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Target env: EU-West / eu-prod                                                                  │
│ Summary: CritR=1 | HighR=0 | HighNR=3 | VEX coverage=62% | SBOM freshness WARN (26h)           │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ By environment                                                                                 │
│  eu-stage: CritR=0  (clean)                                                                    │
│  eu-prod : CritR=1  (CVE-2026-1234 in user-service sha256:2222...)                             │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Delta vs currently deployed in eu-prod                                                         │
│  +1 Critical reachable introduced by this bundle version                                       │
│  +2 High not reachable unchanged                                                               │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Top issues (click to open finding detail)                                                      │
│  - CVE-2026-1234  package: openssl  component: user-service  reach: reachable  VEX: none       │
│  - CVE-2026-9001  package: log4j    component: api-gateway   reach: not reachable VEX: present │
│ Links: [Open Findings (filtered)] [Open VEX Hub] [Open Exceptions]                             │
└──────────────────────────────────────────────────────────────────────────────────────────────┘

17.6 Screen — Approval Detail: Reachability (Hybrid B/I/R)

Formerly

  • Reachability referenced in approvals but not clearly broken down by evidence source.

Why changed like this

You require:

  • reachability from image (Dover),
  • from build,
  • from running environment. This tab makes it explicit and also signals confidence (coverage + evidence age) without being top-level.

Reachability tab graph (Mermaid)

flowchart TD
  R[Reachability tab] --> COV[Coverage: Build/Image/Runtime]
  R --> AGE[Evidence age per source]
  R --> COMP[Per-component B/I/R matrix]
  R --> POL[Policy interpretation (warn/block)]
  R --> DI[Ops: Data Integrity → Reachability ingest health]

ASCII mock — Reachability tab

┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Reachability (Hybrid B/I/R)                                                                    │
│ Formerly: referenced in approvals/gates, not clearly sourced                                    │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Coverage: Build 78% | Image 100% | Runtime 35%                                                  │
│ Evidence age: Build 7h | Image 1h | Runtime 26h                                                 │
│ Policy: runtime coverage < 50% → WARN (does not block)                                         │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Component matrix                                                                              │
│  api-gateway   sha256:1111...   Build ✓  Image ✓  Runtime ✗                                     │
│  user-service  sha256:2222...   Build ✗  Image ✓  Runtime ✗                                     │
│  web-frontend  sha256:3333...   Build ✓  Image ✓  Runtime ✓                                     │
│ Links: [Open Reachability Ingest Health] [Open Env Detail]                                     │
└──────────────────────────────────────────────────────────────────────────────────────────────┘

17.7 Screen — Approval Detail: Ops/Data Health (confidence panel wired to Data Integrity)

Formerly

  • Feed freshness and job status were outside approvals.

Why changed like this

Approvals must clearly state when:

  • SBOM rescans are failing,
  • feeds are stale,
  • integrations are degraded, because the approval is otherwise not defensible.

This tab summarizes and links to Ops → Data Integrity (single source of truth).

Ops/Data tab graph (Mermaid)

flowchart TD
  D[Ops/Data tab] --> FEED[Feeds freshness snapshot]
  D --> JOBS[Nightly jobs snapshot]
  D --> INT[Integration connectivity snapshot]
  D --> DLQ[DLQ status snapshot]
  D --> DI[Open Data Integrity (filtered)]

ASCII mock — Ops/Data tab

┌───────────────────────────────────────────────────────────────────────────────┐
│ Ops/Data Health                                                               │
│ Formerly: Ops Feeds + System Jobs + Integrations (manual context switching)    │
├───────────────────────────────────────────────────────────────────────────────┤
│ Feeds                                                                          │
│  OSV: OK (20m)   NVD: WARN (3h stale; threshold 2h)   KEV: OK (3h)             │
│ Nightly jobs                                                                     │
│  sbom-nightly-rescan: FAIL (registry auth timeout) → 12 images stale > 24h      │
│  reachability-runtime-ingest: WARN (agent degraded) → runtime coverage down     │
│ Integrations                                                                     │
│  Harbor: WARN (token expiry)  Jenkins: DEGRADED  Vault: OK  Consul: OK          │
│ DLQ                                                                              │
│  runtime-ingest bucket: 1,230 items                                              │
│                                                                                  │
│ Actions: [Open Data Integrity] [Open Integrations] [Open Scheduler Runs] [Open DLQ]│
└───────────────────────────────────────────────────────────────────────────────┘

17.8 Screen — Approval Detail: Evidence (Decision Packet)

Formerly

  • Evidence existed in Evidence area; approvals didn’t present a consolidated “decision packet”.

Why changed like this

Approvals should create an exportable, auditable “decision packet” that includes:

  • bundle manifest digest,
  • gate trace,
  • data snapshot (feeds freshness + job status),
  • approver rationale,
  • signatures / transparency log receipts (if configured).

Evidence tab graph (Mermaid)

flowchart TD
  E[Evidence tab] --> PKT[Decision Packet items]
  E --> SIGN[Signature status + key]
  E --> TLOG[Transparency log receipts]
  E --> EXPORT[Export (PDF/JSON bundle)]
  E --> CHAIN[Proof chain (if sealed)]

ASCII mock — Evidence tab

┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Evidence (Decision Packet)                                                                     │
│ Formerly: Evidence existed separately; approvals didn’t present a unified packet                │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Decision packet                                                                                │
│  ✓ policy-decision.dsse (digest sha256:dd77...)                                                 │
│  ✓ gate-trace.json                                                                              │
│  ✓ data-snapshot.json (feeds + jobs + integrations)                                             │
│  ○ proof-chain.json (sealed on promotion completion)                                            │
│ Signatures: policy-k1 (valid)  | Transparency log: rekor receipt present                        │
│ Actions: [Export Packet] [Open Export Center] [Open Proof Chain]                                │
└──────────────────────────────────────────────────────────────────────────────────────────────┘

17.9 Screen — Approval Detail: Replay/Verify (contextual)

Formerly

  • Evidence → Replay/Verify existed as standalone (“Verdict Replay”).

Why changed like this

Approver should be able to replay the exact gate evaluation in-place:

  • prefilled verdict id,
  • bundle manifest digest,
  • policy baseline,
  • dataset snapshot / version lock (if used).

Replay/Verify tab graph (Mermaid)

flowchart TD
  RV[Replay/Verify tab] --> REQ[Request replay (prefilled)]
  RV --> LIST[Replay requests list]
  RV --> MET[Determinism metrics]
  RV --> LINK[Link to canonical Evidence → Replay/Verify]

ASCII mock — Replay/Verify tab

┌───────────────────────────────────────────────────────────────────────────────┐
│ Replay/Verify                                                                  │
│ Formerly: Evidence → Replay/Verify (standalone)                                 │
├───────────────────────────────────────────────────────────────────────────────┤
│ Prefilled replay request                                                       │
│  Verdict ID: verdict-123                                                       │
│  Bundle manifest: sha256:beef...                                               │
│  Baseline: Prod-EU-West                                                        │
│  Data snapshot: OSV 20m | NVD 3h | rescan FAIL                                 │
│ [Request Replay]                                                               │
│ Recent replays: rr-001 COMPLETED (match) | rr-002 RUNNING                       │
│ Link: [Open canonical Replay/Verify]                                           │
└───────────────────────────────────────────────────────────────────────────────┘

17.10 Screen — Approval Detail: History (decision lifecycle)

Formerly

  • Partial “age” fields existed, but not a full lifecycle ledger tied to evidence.

Why changed like this

Auditors and incident responders need:

  • who requested,
  • who approved/rejected,
  • when gates changed (due to new scans/feeds),
  • when exceptions were requested/applied,
  • and links to the evidence packet versions.

History tab graph (Mermaid)

flowchart TD
  H[History tab] --> EVT[Event timeline]
  H --> COM[Comments/Rationales]
  H --> PKT[Evidence packet versions]
  H --> LINK[Links to related release/promotion run]

ASCII mock — History tab

┌───────────────────────────────────────────────────────────────────────────────┐
│ History                                                                       │
│ Formerly: limited timestamps in approvals list                                 │
├───────────────────────────────────────────────────────────────────────────────┤
│  Feb 18 08:30  Gate eval: BLOCK (CVE-2026-1234 reachable; SBOM pending)        │
│  Feb 18 08:31  Data health changed: NVD stale 3h (WARN)                        │
│  Feb 18 08:32  Exception requested by alice.johnson                            │
│  Feb 18 08:40  Evidence packet exported (v2)                                    │
│ Links: [Open Evidence Packet] [Open Promotion] [Open Exception]                │
└───────────────────────────────────────────────────────────────────────────────┘

Net effect (what you asked for, achieved here)

  • SBOM findings + critical reachable per environment are first visible in the approval queue and detail.
  • SBOM status is treated as part of “environment readiness” and “decision readiness,” not an afterthought.
  • Nightly jobs + feed freshness + integration connectivity are shown in the approval context, but remain owned by Ops → Data Integrity (no duplication).
  • Hybrid reachability is second-class: summary badges + dedicated tab + links to ingest health.

If you want the next pack: Pack 18 will update the Environment Detail screen to standardize “Deploy status + SBOM status + CritR + B/I/R + data confidence” as a single consistent header across envs (and wire it to bundles/promotions/approvals).