Skip to main content

Wiz vs SecurityV0: Story Coherence & Positioning Delivery Analysis

Date: 2026-04-03
Author: Delta (sv0-delta)
Context: Follows Sergey's feedback on the March 29 Wiz UX analysis. This is NOT a feature comparison. It analyzes whether pages tell coherent stories that deliver on product positioning.

1. Executive Summary​

The one big insight: Wiz's pages feel modern because every page follows a single reading pattern — what's wrong → why it matters → what to do → evidence — and every page points back to one organizing principle (the Security Graph). SecurityV0 has the same quality of underlying data but presents it as stacked sections of equal visual weight, forcing the analyst to mentally reconstruct the story that the page should tell. Our pages currently say "here is everything we know" instead of "here is what you need to decide."

The fix is not adding components. It's restructuring reading order so that every page delivers on "See what your agents do" the way Wiz delivers on "the Security Graph is the product."

2. How Wiz Delivers on Its Positioning Through Page Structure​

The Organizing Principle: Every Page Points to the Graph​

Wiz's positioning is "the Security Graph is the product." This isn't just marketing — it's a structural UX commitment:

  • Dashboard: KPIs are derived from graph analysis (toxic combinations, not raw CVE counts). The numbers themselves are proof the graph works.
  • Findings list: Issues are pre-filtered by the graph (171 raw findings → 17 actionable issues). The list IS the graph's output.
  • Finding detail: The attack path visualization (a graph subview) is the centerpiece. It answers "why does this matter?" visually.
  • Remediation: Guidance targets the graph node that breaks the attack path. "Fix this one thing" is a graph-derived insight.

Every page reinforces: you don't need to think about this because the graph already did.

Reading Order Per Page Type​

Dashboard (3s / 15s / 60s):

  • 3s: Single number (Security Score 81%) + direction (↑ or ↓). Executive knows if things are getting better or worse.
  • 15s: Severity breakdown + MTTR trend + top issues. Manager knows where to focus the team.
  • 60s: Compliance heatmap + project-level risk. Leader can answer "are we compliant?" per framework.

Findings list (3s / 15s / 60s):

  • 3s: Pre-filtered to OPEN + CRITICAL. Count of actionable issues visible. Analyst knows the size of today's work.
  • 15s: Severity distribution + issue types. Analyst can mentally group the work ("4 IAM issues, 2 exposure issues").
  • 60s: Individual rows with inline descriptions, due dates, ticket status. Analyst can start triaging without clicking into any detail page.

Finding detail (3s / 15s / 60s):

  • 3s: Title + severity + status in header. "Publicly exposed VM with critical vulnerability" — analyst knows what category of problem this is.
  • 15s: Attack path graph. Analyst sees WHY it matters — the chain from internet exposure to sensitive data.
  • 60s: Remediation guidance (copy-paste CLI/Terraform). Analyst can act.

Remediation (0 additional clicks from detail):

  • Remediation is the last section on the finding detail page, not a separate destination. The page tells a complete story: problem → context → fix.

The Key Structural Pattern​

Wiz pages use a funnel architecture: each level narrows scope and increases detail. Dashboard → list → detail → action. At no point does the user encounter a page that just dumps all available data.

3. How SecurityV0 Currently Delivers (or Fails to Deliver) on "See What Your Agents Do"​

The Organizing Principle Problem​

SecurityV0's positioning is "See what your agents do." The organizing principle should be: the access path is the unit of truth — every page should point back to a specific workload doing a specific thing via a specific identity to a specific destination.

Currently, our pages partially deliver this but break coherence in several ways:

Overview Page: Tells a "what exists" story, not a "what changed" story​

The Overview page shows:

  1. Drift activity banner (good — change-oriented)
  2. Business metrics cards (Sensitive Domains, Departed Owners, LLM Egress)
  3. "New since last visit" banner
  4. Top Risks (top 3 paths by finding count)
  5. Top Risk Clusters (card grid)
  6. Scan Metrics (executions, active paths)

Problem: The page reads as a collection of cards, not a narrative. There's no single "how are we doing?" answer. The drift banner is first (good) but it's a count, not a story. An executive at 3 seconds sees "Drift Activity: 5 scope changes, 2 ownership changes" — but doesn't know if that's bad or normal, whether it's more or less than last week, or what to do about it.

Contrast with Wiz: At 3 seconds, Wiz gives you a single number with a trend arrow. At 15 seconds, you know what's driving the number. Our Overview gives you six different things to look at with no hierarchy between them.

Findings List: Data-rich but decision-poor​

Current reading order:

  1. Title + count
  2. Summary strip (severity pills + type counts)
  3. Preset filter buttons
  4. Filter dropdowns
  5. Table rows

Problem: The summary strip and presets are good additions (from the March sprint). But the table itself still treats all findings as equal-weight rows. The line-clamp-2 truncation on descriptions means the most important text is cut off. There's no ownership column, no remediation status, no "is anyone working on this?" signal.

An analyst scanning the findings list can answer "how many criticals exist?" (3 seconds) but cannot answer "which criticals does nobody own?" or "which criticals already have tracked actions?" without clicking into each one.

Finding Detail: Sections of equal weight​

Current reading order (top to bottom):

  1. Header (type, severity, evidence badge, status)
  2. Explanation
  3. Access Path (inline visualization — good, added in #241)
  4. Recommended Actions
  5. Scope Drift Detail (if applicable)
  6. Evidence Completeness
  7. Evidence Pack (9 sections)
  8. Metadata

Problem: This is Sergey's core critique. The page is a vertical stack of equally-weighted sections. Sections 1-4 are decision-critical. Sections 5-8 are verification/audit content. But visually, they all look the same — white cards with gray headers, equal spacing, equal prominence.

The evidence pack (9 subsections!) dominates the page by sheer volume, even though most analysts only need it for edge cases. The page reads as "here is everything we know" rather than "here is what happened, why it matters, and what to do."

Authority Path Detail: The strongest page, but still too long​

This is actually our best page for story coherence. The reading order roughly follows decision flow:

  1. PathHeader (what path, confidence, narrative description)
  2. Path diagram (visual)
  3. Risk Conditions Strip (what's wrong)
  4. Remediation Guidance (what to do)
  5. Tracked Actions (what's being done)
  6. Standing Authority (what else is at risk)
  7. Ownership / Metadata / Identity Binding (who's responsible)

Problem: It's too long. The bottom grid (ownership, automation metadata, identity binding, authority state, linkage proof) has 5-6 cards that an analyst rarely needs on first visit. The page should separate "decision content" (sections 1-5) from "reference content" (sections 6-7) more aggressively.

Scope Drift: A label, not a story​

Sergey's strongest critique. When scope drift appears as a finding tile in the Risk Conditions strip, it shows:

  • Label: "Scope drift"
  • Severity badge
  • Status badge
  • On expand: a ScopeDriftDeltaCard with before/after role counts, new roles, baseline date

The ScopeDriftDeltaCard is actually good — it shows before→after, net-new roles, cause, and sensitive domain impact. But it's buried inside an expandable tile. The one-liner in collapsed state (scopeDriftOneLiner) shows "3→5 roles, 2 sensitive domains" which is a step in the right direction but still reads as a data point, not a change event with urgency.

The same drift finding on the Finding Detail page shows a ScopeDriftDetail component, but it's section 5 of 8 — below the explanation and recommended actions, above evidence completeness. A user who lands on a scope drift finding has to scroll past the generic explanation to find the actual delta.

4. The 3-5 Structural Changes That Would Make Our Pages Tell a Coherent Story​

Change 1: Restructure Finding Detail into Decision Flow (highest impact)​

Replace the current equal-weight vertical stack with three explicit zones:

Zone A — Decision (always visible, above fold):

  • Header: type + severity + evidence trust + owner + status
  • Risk summary: 1-2 sentence plain language ("This workload gained 3 new roles since baseline, now reaching patient data via sql_admin_reader. The owner departed 14 days ago.")
  • Primary action: safest first step + who should do it + track button

Zone B — Context (visible on scroll):

  • Access path visualization (inline, already exists)
  • Blast radius summary: what else this affects
  • For scope drift: before/after delta as the LEAD content, not a subsection

Zone C — Evidence (collapsed or tabbed):

  • Evidence pack (9 sections)
  • Evidence completeness
  • Metadata
  • Raw JSON

Implementation: This doesn't require new data. It requires moving existing components and adding visual separation (a divider, a "Show evidence details" accordion, or tabs).

Change 2: Make Scope Drift a Change Event, Not a Condition Label​

Every scope drift finding should lead with the delta:

BEFORE: 2 roles → finance-db, hr-db
AFTER:  5 roles → finance-db, hr-db, patient-db, billing-api, admin-console
DELTA:  +3 roles, +2 sensitive domains (patient, billing)
CAUSE:  New role assignment: sql_admin_reader (2026-03-28)
IMPACT: Workload can now reach patient data without owner review
OWNER:  IAM team (departed: former-owner@example.com)
ACTION: Remove sql_admin_reader or re-baseline with justification

This should be the FIRST thing visible on a scope drift finding detail, not section 5. On the findings list, the description column for scope drift findings should show the delta one-liner prominently, not a generic explanation.

Change 3: Add Grouped Action Views Above Atomic Findings​

Per Sergey's corrected stance: keep atomic findings, add derived action groups.

On the Findings List page, add an optional "Action Groups" view above or alongside the table:

  • Fix groups: "Remove sql_admin_reader → resolves 8 findings across 4 paths"
  • Team routing: "IAM team: 12 actions | Platform owners: 5 actions | Data governance: 3 actions"
  • Theme groups: "Scope expansion (14) | Orphaned ownership (8) | LLM egress (3)"

This is the "two-layer model" Sergey described: truth layer (exact findings) + action layer (grouped remediation). The findings table remains the source of truth; the action groups are a derived view above it.

Change 4: Overview Should Answer "How Are We Doing?" in 3 Seconds​

Replace the current card soup with a clear headline:

3 critical paths unreviewed | 2 owners departed this week | 1 new scope expansion into patient data

This is a deterministic posture sentence, not a probabilistic score. It tells the executive exactly what needs attention in plain language.

Below it, keep the business metrics cards but add trend sparklines (the TrendIndicator component already exists but shows "—" placeholder because the API doesn't have prior-period data yet). The trend data gap is the biggest blocker to making the Overview tell a trajectory story.

Change 5: Remediation as Story Conclusion on Every Page​

Currently, remediation appears as:

  • "Recommended Actions" section on Finding Detail (section 4 of 8)
  • "Top Risk Reducers" section on Authority Path Detail (section 4 of ~10)
  • Not visible at all on the Findings List

Remediation should be the natural conclusion of the reading flow on every page:

  • Findings list: Add a "Next action" column or indicator (even just "Tracked ✓" / "Untracked")
  • Finding detail: Move recommended actions into Zone A (decision zone), right after the risk summary
  • Authority path detail: Already good placement; just ensure it's above the fold

The pattern is: problem statement → context → action. Never: problem statement → context → evidence → metadata → action.

5. What to Explicitly NOT Do​

1. Don't Add a Composite Security Score​

Wiz's Security Score (81%) works because their inputs are probabilistic — exposure likelihood, blast radius estimates, threat intelligence correlation. Our inputs are deterministic facts. A composite score would:

  • Mask the specific access paths that matter
  • Invite gaming ("score went up but 2 critical paths are still unreviewed")
  • Undermine the "what is proven vs inferred" trust model

Instead: Use deterministic posture sentences ("3 critical paths, 0 reviewed this week").

2. Don't Make the Graph the Organizing Principle​

Wiz built their entire product on the graph — it's their data model, analysis engine, and visualization layer simultaneously. Our organizing principle is the access path — a specific workload executing via a specific identity to a specific destination. The graph is a supporting exploration tool.

Making the graph central would:

  • Dilute the focused NHI governance value proposition
  • Require a fundamentally different data architecture
  • Move us toward Wiz's territory where we can't win

Instead: Keep the access path as the atomic unit. Show path diagrams inline where relevant (already doing this with #241).

3. Don't Add AI Verdicts or Auto-Remediation​

Wiz uses LLM-powered investigation (Green Agent) to produce Remediate/Ignore verdicts. This makes sense when you have thousands of probabilistic alerts that need triage.

Our findings are already deterministic conclusions. Adding AI verdicts would:

  • Create a second, less trustworthy layer on top of proven facts
  • Undermine the "accountable human review" moat
  • Confuse the "proven vs inferred" distinction

Instead: Make deterministic evidence and confidence more visible (EvidenceTrustBadge already exists; promote it).

4. Don't Build a Workflow Automation Engine​

Wiz Workflows is a drag-and-drop automation builder. Building this would be:

  • Massive scope creep (months of engineering)
  • Off-wedge (our value is review quality, not automation orchestration)
  • Premature (we don't have enough users to know what workflows they need)

Instead: Focus on making the ticket creation flow excellent (pre-populated, one-click, with deep links back to SV0).

5. Don't Copy Probabilistic Contextual Severity​

Wiz re-scores severity using exposure analysis, blast radius, and runtime state. A CVSS 6.0 can become Critical if it's internet-facing with access to PII.

Our severity is already contextual through evaluator logic — a scope drift finding IS critical because the evaluator proved it expanded into sensitive data. Re-scoring on top of this would:

  • Add a confusing second severity layer
  • Require probabilistic inputs we don't have
  • Undermine trust in the evaluator's deterministic output

6. Recommended Reading Order Redesign for Each Major Page Type​

Overview Page (/)​

Current: Drift banner → Business metrics → New findings → Top risks → Clusters → Scan metrics

Recommended:

  1. Posture headline (3s): "3 critical paths unreviewed · 2 departed owners · 1 new scope expansion" — deterministic sentence, not a score
  2. What changed (15s): Drift activity with BEFORE/AFTER framing, not just counts. "Scope expanded: 2→5 roles on patient-data-pipeline (new this week)"
  3. Top risks needing action (30s): Top 3 paths with owner + action status. Show whether someone is working on it.
  4. Business metrics with trends (60s): Current cards + sparklines showing trajectory
  5. Scan metrics (reference): Demoted, as currently implemented

Findings List (/findings)​

Current: Title → Summary strip → Presets → Filters → Table

Recommended:

  1. Action groups (3s): "12 findings → 3 fix groups" or "IAM team: 8 | Platform: 4" — derived view
  2. Summary strip + presets (15s): As-is, working well
  3. Table with enhanced columns (60s):
    • Remove line-clamp-2 on descriptions (show 4-5 lines)
    • Add Owner column
    • Add Action Status column (Tracked/Untracked)
    • For scope drift rows: show delta one-liner in description, not generic explanation
    • Default sort: severity-descending (already implemented in #238)

Finding Detail (/findings/:id)​

Current: Header → Explanation → Path → Actions → Drift Detail → Evidence Completeness → Evidence Pack → Metadata

Recommended:

  1. Header (3s): Type + severity + evidence trust + owner + status (as-is, good)
  2. Risk summary (15s): NEW — plain language "what is proven and why it matters in business terms." For scope drift, lead with the delta.
  3. Primary action (30s): Recommended action + who should do it + track button. Moved up from section 4.
  4. Path context (60s): Inline path visualization + blast radius summary
  5. Evidence (on demand): Collapsed accordion or tab — Evidence pack, completeness, metadata

Authority Path Detail (/authority-paths/:id)​

Current: Header → Diagram → Risk Conditions → Remediation → Tracked Actions → Standing Authority → Ownership → Metadata → Binding → Authority State → Linkage

Recommended:

  1. Header + diagram (3s): As-is, strong. Path chain + confidence + narrative.
  2. Risk conditions (15s): As-is. Finding tiles with inline drift breakdowns.
  3. Remediation + tracked actions (30s): As-is. "Top Risk Reducers" + action tracking.
  4. Ownership (60s): Move up slightly — ownership is decision-critical for action routing.
  5. Reference (on demand): Collapse into accordion — Standing authority, identity binding, automation metadata, authority state, linkage proof.

Risk Cluster Detail (/clusters/:key)​

Current: Narrative → Metrics → Governance Checklist → Exposure Narrative → Compliance → Remediation Targets → Findings Timing → Paths Detail

Recommended:

  1. Headline (3s): Cluster title + severity + "affects N paths, M findings"
  2. What's wrong (15s): Narrative + governance checklist (which conditions are failing)
  3. What to do (30s): Remediation targets + team routing
  4. Paths affected (60s): Path list with inline status
  5. Evidence (on demand): Compliance mapping, timing grid, exposure narrative

Summary​

The gap between Wiz and SecurityV0 is not features or data quality. It's reading order. Wiz pages tell a story: problem → impact → action → evidence. Our pages present a catalog: here's the type, here's the severity, here's the explanation, here's the evidence pack, here's the metadata.

The fix is architectural (page structure) not additive (more components). Every page should answer four questions in order:

  1. What is proven? (not inferred)
  2. Why does it matter? (in business terms)
  3. What's the safest first action? (specific, not generic)
  4. Who should own it? (team or individual)

If our pages answer those four questions in that order, we deliver on "See what your agents do" the way Wiz delivers on "the Security Graph is the product" — through structure, not through features.

Next Action​

Status: research-complete — input to [[combined-ux-strategy]] Decision needed from: CTO (Ivan) See: [[combined-ux-strategy]] for synthesized recommendations and decision options

— Delta (sv0-delta)