Files
git.stella-ops.org/docs/modules/ui/v2-rewire/pack-07.md
2026-02-18 23:03:07 +02:00

39 KiB
Raw Blame History

Pack 7 — Security (menu + every screen graph + ASCII mocks; keep the main IA intact)

Security stays a root menu. This pack reorganizes Security pages to be release/bundle aware, surfaces SBOM findings + hybrid reachability (build / image-Dover / runtime) as second-class, and adds clear links to Nightly Ops Report + Integrations health when data is stale.


1) Security menu graph (Mermaid)

flowchart TD
  SEC[Security] --> SEC_OV[Overview]
  SEC --> SEC_FIND[Findings]
  SEC --> SEC_VULN[Vulnerabilities]
  SEC --> SEC_VEX[VEX Hub]
  SEC --> SEC_EXC[Exceptions]
  SEC --> SEC_COV[Coverage & Analytics]
  SEC --> SEC_GRAPH[SBOM Graph (Beta)]

  SEC_FIND --> SEC_FIND_DETAIL[Finding Detail]
  SEC_VULN --> SEC_VULN_DETAIL[Vulnerability Detail (CVE)]
  SEC_VEX --> SEC_VEX_DETAIL[VEX Statement Detail]
  SEC_EXC --> SEC_EXC_DETAIL[Exception Detail / Request]

Reachability (Build / Image-Dover / Runtime) is not a root product menu; it is embedded as a first-visible widget in Security Overview and a first-class facet/column in Findings/Vulnerabilities (i.e., second-class across the product, not buried).


2) Security → Overview

Previously

  • Formerly: Security → Overview (/security/overview), showing severity counters, VEX coverage, active exceptions, etc.
  • Missing: explicit “where reachable criticals exist” and hybrid reachability coverage.

Now (Redesign)

  • Now: Security → Overview (same route), but it becomes the security posture cockpit for release decisions:

    • “Critical reachable issues” surfaced by Region → Environment
    • SBOM freshness + Reachability coverage (build/image/runtime)
    • CVE dataset freshness (OSV/NVD) and explicit link to Nightly Ops Report
    • “Top affected bundles/releases” to drive hotfix decisions

Why changed

StellaOps is about release/hotpatch governance + auditable decisions. Security Overview must answer in 10 seconds:

  • “Are we safe to promote?”
  • “If not, which envs/regions are blocked and why?”
  • “Is the data trustworthy (feeds, scans, reachability) or are we blind?”

Screen graph (Mermaid)

flowchart TD
  A[Security Overview] --> B[Security Findings (filtered)]
  A --> C[Vulnerabilities (filtered)]
  A --> D[VEX Hub]
  A --> E[Exceptions]
  A --> F[Coverage & Analytics]
  A --> G[Operations: Nightly Ops Report]
  A --> H[Integrations: Security Data Sources]
  A --> I[Release Control: Bundle Organizer / Hotfix]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ SECURITY ▸ OVERVIEW                                                         [Run Scan]         │
│ Formerly: Security ▸ Overview                                                                    │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Scope: Region ▾ (All)   Environment ▾ (All)   Time ▾ (Last 7d)                                  │
│ Data Health: CVE Feeds  OSV: OK  | NVD: DOWN  → [Open Nightly Ops Report] [Open Integrations]   │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ POSTURE (hybrid reachability aware)                                                             │
│ Critical (Reachable):  3 envs  | High (Reachable): 6 envs  | Medium: 12 envs                    │
│ Reachability sources coverage: Build 92% | Image/Dover 96% | Runtime 61%                         │
│ SBOM freshness: Images scanned <24h: 88%  | Runtime inventory <24h: 54%                          │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ WHERE THE RISK IS (Region → Env)                                                                │
│ - eu-west ▸ prod-eu        Critical reachable: 5   (Top: log4j, openssl)   [View Findings]      │
│ - us-east ▸ staging-us     Critical reachable: 2   (Top: curl)              [View Findings]      │
│ - us-east ▸ prod-us        High reachable: 7       (Top: glibc)             [View Findings]      │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ VEX COVERAGE                                    EXCEPTIONS                                      │
│ Findings w/ VEX: 14  | Awaiting VEX: 6          Active: 2   Pending: 1   Expiring<14d: 1        │
│ [Open VEX Hub]                                   [Open Exceptions]                               │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ RELEASE IMPACT                                                                                  │
│ Hotfix candidates (bundles/releases):                                                           │
│ - Bundle: api-gateway@v2.1.0  (prod-eu)  Critical reachable: 3  [Open Bundle]                   │
│ - Bundle: user-service@v3.0.0-rc1        High reachable: 4      [Open Bundle]                   │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

3) Security → Findings

Previously

  • Formerly: Security → Findings (/security/findings) Table included: CVE, package, severity, CVSS, reachable, VEX, release impact, delta, environments, first seen.

Now (Redesign)

  • Now: Security → Findings stays, but becomes hybrid reachability first-visible:

    • Replace single “Reachable” with:

      • Hybrid Reachable (computed)
      • Build Reachable / Image(Dover) Reachable / Runtime Reachable
    • Add Region + Environment filters (region-first model)

    • Add Bundle / Release filters (release governance model)

    • Add Dataset provenance (which CVE snapshot + SBOM snapshot the decision used)

Why changed

Reachability is part of “what is exploitable for us” and must not be buried. Also, findings must route to Release Bundles and evidence.


Screen graph (Mermaid)

flowchart TD
  A[Security Findings] --> B[Finding Detail]
  A --> C[Vulnerability Detail (CVE)]
  A --> D[VEX Hub (filtered by CVE)]
  A --> E[Exceptions (filtered)]
  A --> F[Release Control: Bundle Organizer (filtered)]
  A --> G[Operations: Nightly Ops Report (data health)]
  A --> H[Evidence & Audit: Proof Chain (for decision)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ SECURITY ▸ FINDINGS                                                          [Export CSV]      │
│ Formerly: Security ▸ Findings                                                                     │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filters: Severity ▾  Hybrid Reachable ▾  Reach Source ▾(Any/Build/Image/Runtime)  VEX ▾         │
│         Region ▾  Environment ▾  Bundle/Release ▾  Time ▾                                       │
│ Banner: NVD feed stale → reachability/score may be incomplete  [Open Nightly Ops Report]        │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ CVE        Package     Sev  CVSS  Hybrid  Build  Image  Runtime  VEX     Bundle Impact   First │
│-------------------------------------------------------------------------------------------------│
│ CVE-XXXX   openssl     CRIT 9.8   YES     NO     YES    YES      Await   api-gateway@2.1.0  2d │
│ CVE-YYYY   log4j       CRIT 10.0  YES     YES    YES    NO       NotAff  user-svc@3.0.0    1d │
│ CVE-ZZZZ   curl        HIGH 8.1   NO      NO     NO     NO       -       none            7d  │
│ Actions per row: [View Finding] [View CVE] [Request Exception] [Open Bundle]                  │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

4) Security → Finding Detail (new explicit drill-down)

Previously

  • Formerly: implicit (row in Findings table, no dedicated “decision page”).

Now

  • Now: Security → Findings → Finding Detail

Why changed

A finding needs an auditable explanation page:

  • What data was used (SBOM snapshot, CVE dataset version)
  • Reachability per source (build/image/runtime)
  • Impacted bundles/releases and environments
  • Associated VEX and exceptions
  • Deep links to Proof Chain / Evidence Bundle

Screen graph (Mermaid)

flowchart TD
  A[Finding Detail] --> B[Vulnerability Detail (CVE)]
  A --> C[VEX Statement Detail]
  A --> D[Exception Detail / Request]
  A --> E[Release Control: Bundle Organizer (affected bundles)]
  A --> F[Evidence & Audit: Proof Chains]
  A --> G[Evidence & Audit: Replay/Verify]
  A --> H[Operations: Nightly Ops Report (if stale inputs)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ SECURITY ▸ FINDING DETAIL: CVE-XXXX in openssl                                                  │
│ Formerly: Security ▸ Findings (row drilldown)                                                   │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Severity: CRITICAL  CVSS: 9.8   EPSS: (if available)   KEV: (if available)                      │
│ Data provenance: SBOM snapshot: 2026-02-18T02:00Z | CVE dataset: OSV-2026.02.18.01 | NVD: stale │
│                                                                                                 │
│ REACHABILITY (HYBRID)                                                                           │
│ Hybrid Reachable: YES  (because Image/Dover=YES OR Runtime=YES)                                  │
│ ┌───────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ Source     Coverage   Result     Evidence link                                               │  │
│ │ Build      92%        NO         [build reach report]                                         │  │
│ │ Image/Dover96%        YES        [image reach report]                                         │  │
│ │ Runtime    61%        YES        [runtime reach report]                                       │  │
│ └───────────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                                 │
│ AFFECTED (Region → Env)                                                                         │
│ - eu-west ▸ prod-eu    reachable=YES  first seen=2d  bundle: api-gateway@2.1.0  [Open Bundle]   │
│ - us-east ▸ staging-us reachable=YES  first seen=1d  bundle: api-gateway@2.1.0  [Open Bundle]   │
│                                                                                                 │
│ CONTROLS                                                                                        │
│ VEX: Awaiting VEX  → [Open VEX Hub]     Exceptions: none  → [Request Exception]                 │
│ Evidence: [Open Proof Chain] [Replay/Verify] [Export Evidence Bundle snapshot]                  │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

5) Security → Vulnerabilities (CVE Catalog)

Previously

  • Formerly: Security → Vulnerabilities (/security/vulnerabilities) but it was a placeholder (“pending data integration”).

Now

  • Now: Security → Vulnerabilities becomes the CVE catalog view:

    • CVE metadata + source freshness (OSV/NVD/vendor)
    • “In our estate” counts: findings total + reachable total
    • Drill-down to CVE detail

Why changed

You need both:

  • Findings = concrete occurrences in your envs/bundles
  • Vulnerabilities = global CVE view with intelligence + provenance

Screen graph (Mermaid)

flowchart TD
  A[Vulnerabilities (Catalog)] --> B[Vulnerability Detail (CVE)]
  A --> C[Security Findings (filtered by CVE)]
  A --> D[Integrations: Security Data Sources]
  A --> E[Operations: Nightly Ops Report (feed failures)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ SECURITY ▸ VULNERABILITIES (CVE CATALOG)                                                        │
│ Formerly: Security ▸ Vulnerabilities (pending integration)                                       │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filters: Severity ▾  In-Our-Estate ▾(Any/Yes)  Reachable ▾(Any/Yes)  Source ▾(OSV/NVD/Vendor)    │
│ Data freshness: OSV OK | NVD DOWN  → [Open Integrations] [Open Nightly Ops Report]               │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ CVE        Sev   CVSS  Sources   In our estate  Reachable  Top bundles impacted                 │
│-------------------------------------------------------------------------------------------------│
│ CVE-XXXX   CRIT  9.8   OSV,NVD*  12 findings    7          api-gateway@2.1.0, web@2.0.0         │
│ CVE-YYYY   HIGH  8.1   OSV       3 findings     0          none                                 │
│ Actions: [View CVE] [View Findings]                                                             │
│ *NVD stale indicator                                                                             │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

6) Vulnerability Detail (CVE) — new

Previously

  • Formerly: none (catalog didnt exist).

Now

  • Now: Security → Vulnerabilities → Vulnerability Detail

Why changed

You need a single place to explain the vulnerability and tie it to:

  • findings + reachability + bundles
  • VEX statements
  • evidence snapshot (dataset versions)

Screen graph (Mermaid)

flowchart TD
  A[Vulnerability Detail (CVE)] --> B[Security Findings (filtered)]
  A --> C[Finding Detail]
  A --> D[VEX Statement Detail]
  A --> E[Exceptions (filtered)]
  A --> F[Release Control: Bundle Organizer]
  A --> G[Evidence & Audit: Proof Chains (dataset attestation)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ SECURITY ▸ CVE DETAIL: CVE-XXXX                                                                 │
│ Formerly: (new)                                                                                │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Severity: CRITICAL  CVSS: 9.8                                                                   │
│ Sources: OSV (fresh) | NVD (stale) | Vendor advisory (optional)                                 │
│ Affected: openssl < 3.0.2 (example)  Fixed: 3.0.2+ (example)                                     │
│ Dataset evidence: OSV snapshot 2026.02.18.01  [Export dataset attestation]                       │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ IN OUR ESTATE                                                                                   │
│ Findings: 12  | Hybrid reachable: 7                                                             │
│ Reachability breakdown: Build 2 | Image/Dover 6 | Runtime 5                                      │
│ Top impacted bundles: api-gateway@2.1.0, web-frontend@2.0.0                                      │
│ [View Findings] [Open Bundle Organizer filtered]                                                 │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ CONTROLS                                                                                        │
│ VEX statements: 1 Not-Affected, 1 Under-Investigation  → [Open VEX Hub filtered]                │
│ Exceptions: 2 active (prod-eu) → [Open Exceptions filtered]                                     │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

7) Security → VEX Hub

Previously

  • Formerly: Security → VEX Hub (/security/vex) but showing error and limited utility.

Now

  • Now: Security → VEX Hub becomes the exploitability statement center:

    • Search statements by CVE/component/bundle
    • Show statement validity (issuer, signature, scope, expiry)
    • Directly explain policy effect (“blocks/unblocks approvals”)

Why changed

VEX is essential to reduce noise and to make decisions auditable. It must be adjacent to findings.


Screen graph (Mermaid)

flowchart TD
  A[VEX Hub] --> B[VEX Statement Detail]
  A --> C[Security Findings (filtered by CVE/component)]
  A --> D[Integrations: VEX Sources]
  A --> E[Evidence & Audit: Trust & Signing]
  A --> F[Release Control: Governance & Policy (how VEX affects gates)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ SECURITY ▸ VEX HUB                                                           [ + Search Statements ]│
│ Formerly: Security ▸ VEX Hub                                                                    │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Banner: VEX source error → [Retry]  (if feeds/integration failing)                              │
│ Coverage: Findings with VEX: 14 | Awaiting VEX: 6                                               │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Statement ID   Issuer        Scope (bundle/env)         Status         Validity    Actions      │
│-------------------------------------------------------------------------------------------------│
│ vex-001        VendorA       api-gateway@2.1.0          NOT_AFFECTED   signed      [View]        │
│ vex-002        InternalSec   prod-eu / web@2.0.0        INVESTIGATING  signed      [View]        │
│ vex-003        VendorB       openssl component-wide     AFFECTED       signed      [View]        │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

8) VEX Statement Detail — new

Previously

  • Formerly: implicit.

Now

  • Now: Security → VEX Hub → Statement Detail

Why changed

You need a decision artifact that auditors can read:

  • statement content + signature chain
  • scope (which bundle/env/component)
  • policy effect

Screen graph (Mermaid)

flowchart TD
  A[VEX Statement Detail] --> B[Trust & Signing (issuer, cert)]
  A --> C[Security Findings (affected)]
  A --> D[Vulnerability Detail (CVE)]
  A --> E[Evidence & Audit: Proof Chain]
  A --> F[Release Control: Governance & Policy]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ SECURITY ▸ VEX STATEMENT DETAIL: vex-001                                                         │
│ Formerly: VEX Hub (statement row)                                                                │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Issuer: VendorA   Signature: VALID   Rekor entry: present  [View in Trust & Signing]            │
│ Scope: Bundle api-gateway@2.1.0  | Regions: eu-west, us-east | Envs: prod, staging               │
│ CVEs: CVE-XXXX, CVE-AAAA                                                                          │
│ Status: NOT_AFFECTED  Reason: component not reachable in shipped configuration (example)         │
│ Policy Effect: allows approvals to proceed for scoped bundles (per governance rules)             │
│ Evidence: [Open Proof Chain] [Export to Evidence Bundle]                                         │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

9) Security → Exceptions

Previously

  • Formerly: Security → Exceptions (/security/exceptions)

Now

  • Now: Security → Exceptions remains, but:

    • exceptions are tied to Finding/CVE + Region/Env + Bundle/Release
    • includes expiry + mitigation as first-visible fields
    • links to Release Control → Exception Workflow (configuration lives there now)

Why changed

Exceptions are part of release governance and must be traceable to what was accepted, where, and until when.


Screen graph (Mermaid)

flowchart TD
  A[Security Exceptions] --> B[Exception Detail / Request]
  A --> C[Security Findings (filtered)]
  A --> D[Release Control: Governance & Policy (exception workflow)]
  A --> E[Evidence & Audit: Evidence Bundle (for exception record)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ SECURITY ▸ EXCEPTIONS                                                        [ + Request Exception ]│
│ Formerly: Security ▸ Exceptions                                                                   │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filters: Status ▾  Region ▾  Environment ▾  Bundle/Release ▾  Expiring soon ▾                    │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Exception ID  Finding/CVE   Scope (region/env)      Bundle        Reason        Expires  Status │
│-------------------------------------------------------------------------------------------------│
│ exc-101       CVE-XXXX      eu-west/prod-eu          api@2.1.0     mitigation…   14d     ACTIVE  │
│ exc-102       CVE-YYYY      us-east/staging-us       user@3.0.0    rollback…     2d      PENDING │
│ Actions: [View] [Extend] [Revoke] [Export evidence]                                            │
│ Workflow config: Release Control ▸ Governance & Policy ▸ Exception Workflow [Open]              │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

10) Exception Detail / Request — new explicit page

Previously

  • Formerly: implied; request button existed but no structured “audit-grade” view.

Now

  • Now: Security → Exceptions → Detail/Request

Why changed

This is the artifact auditors will ask for:

  • what risk accepted, scope, mitigation, approvals, expiry
  • evidence attachments / signatures

Screen graph (Mermaid)

flowchart TD
  A[Exception Detail] --> B[Finding Detail]
  A --> C[Vulnerability Detail (CVE)]
  A --> D[Evidence & Audit: Proof Chain]
  A --> E[Evidence & Audit: Export Center]
  A --> F[Release Control: Governance & Policy (workflow)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ SECURITY ▸ EXCEPTION DETAIL: exc-101                                                            │
│ Formerly: Security ▸ Exceptions (row)                                                           │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Finding: CVE-XXXX in openssl   Severity: CRITICAL   Hybrid reachable: YES                       │
│ Scope: eu-west ▸ prod-eu  | Bundle: api-gateway@2.1.0                                            │
│ Reason: customer outage risk if patched immediately (example)                                    │
│ Mitigation: WAF rule + restricted egress + monitoring                                             │
│ Expires: 2026-03-04  Approvers: security-lead, release-manager                                     │
│ Evidence: [Attach] [Open Proof Chain] [Export to Evidence Bundle]                                │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

11) Security → Coverage & Analytics (SBOM Lake moved)

Previously

  • Formerly: Analytics → SBOM Lake (/analytics/sbom-lake)

Now

  • Now: Security → Coverage & Analytics (and cross-linked from Evidence & Audit because it measures attestation coverage)

Why changed

SBOM Lake is not “generic analytics.” It directly answers:

  • “Do we have enough SBOM + reachability + VEX + policy-decision attestations to trust promotions?”
  • “Which regions/envs are blind or stale?” That is security posture and must live under Security.

Screen graph (Mermaid)

flowchart TD
  A[Coverage & Analytics] --> B[Security Findings (filtered)]
  A --> C[VEX Hub (filtered)]
  A --> D[Operations: Nightly Ops Report]
  A --> E[Integrations: Security Data Sources]
  A --> F[Evidence & Audit: Proof Chains]
  A --> G[Administration: Usage & Limits]

ASCII mock (expanded SBOM + reachability coverage)

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ SECURITY ▸ COVERAGE & ANALYTICS                                                                 │
│ Formerly: Analytics ▸ SBOM Lake                                                                 │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filters: Region ▾  Environment ▾  Min Severity ▾  Time Window ▾                                  │
│ Banner: Analytics API auth error (if any) → [Open System] [Open Integrations]                    │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ ATTESTATION COVERAGE (last 30d)                                                                  │
│ SBOM: 88%  | VEX: 62% | Policy Decision: 91% | Human Approval: 74%                               │
│ Complete Chains: 71% (SBOM+Reachability+Policy+Evidence)                                         │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ HYBRID REACHABILITY COVERAGE                                                                     │
│ Build reach coverage: 92%  (fresh <24h: 90%)                                                     │
│ Image/Dover coverage: 96% (fresh <24h: 88%)                                                      │
│ Runtime coverage: 61%     (fresh <24h: 54%)                                                      │
│ → gaps reduce confidence in “reachable” classification                                           │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ APPROVAL VELOCITY / BLOCKERS                                                                     │
│ - Top blocker: NVD feed stale (dataset) → [Nightly Ops Report]                                   │
│ - Top blocker: runtime reach ingest degraded (eu-central agent) → [Worker Fleet]                 │
│ Exports: [Export CSV] [Export coverage attestation snapshot]                                     │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

12) Security → SBOM Graph (Beta)

Previously

  • Formerly: Security → SBOM Graph (/security/sbom) but the build says “not yet available.”

Now

  • Now: Security → SBOM Graph (Beta) remains, but positioned explicitly as:

    • a visualization tool for dependency relationships and component impact
    • driven by Bundles/Releases, with region/env lens
    • links back to Findings and to Bundle Organizer

Why changed

Even if not implemented yet, the IA must reserve the place so it doesnt get shoved into random “analytics” later. Its a security tool.


Screen graph (Mermaid)

flowchart TD
  A[SBOM Graph (Beta)] --> B[Security Findings (component/CVE filtered)]
  A --> C[Release Control: Bundle Organizer]
  A --> D[Vulnerability Detail (CVE)]
  A --> E[Coverage & Analytics]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ SECURITY ▸ SBOM GRAPH (BETA)                                                                    │
│ Formerly: Security ▸ SBOM Graph (not available)                                                 │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Scope: Bundle/Release ▾  Region ▾  Environment ▾                                                │
│ (Graph canvas)                                                                                  │
│ - Nodes: components/packages/images/services                                                    │
│ - Edges: dependency relationships                                                                │
│                                                                                                 │
│ Side panel: Selected node → vulnerabilities + reachability + affected bundles                    │
│ Actions: [View Findings] [View CVE] [Open Bundle Organizer]                                     │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

Preservation mapping (prove the reorg stays intact)

  • Security → Overview stays Security root
  • Security → Findings stays Security root, but now hybrid reachability is first-visible
  • Security → Vulnerabilities becomes real (was placeholder)
  • Security → VEX Hub stays under Security root
  • Security → Exceptions stays under Security root, with workflow config linked to Release Control
  • Analytics → SBOM Lake is moved to Security → Coverage & Analytics (and cross-linked from Evidence & Audit)
  • Security → SBOM Graph stays, labeled Beta

If you want, Pack 8 can cover Release Control screens in the same format (Mermaid + ASCII + Formerly/Why) including the missing Release Bundle Organizer you called out (microservice digest→version, env vars from Vault/Consul, per-repo changelog, bundle composition, promotion paths).