Orca Cve Blast Radius

Orca CVE Blast-Radius Skill

Answers the question: "This CVE just dropped — which of our assets are actually at risk, ranked by real exposure?"

Static CVSS doesn't tell you which workloads matter. This skill takes a CVE-ID, finds every affected asset across all accounts, and ranks them by runtime exposure context — internet-facing, attack-path participation, crown jewel status, and existing related alerts.

Usage

/orca-cve-blast-radius CVE-2021-44228
/orca-cve-blast-radius CVE-2024-1234
/orca-cve-blast-radius CVE-2024-3094 prod

Or natural language:

• "blast radius of CVE-2024-1234"
• "where are we affected by Log4Shell?"
• "which assets have CVE-2021-44228?"
• "show me CVE-2024-3094 across all accounts"

Processing Logic

Step 1: Parse the CVE-ID

Extract a single CVE-ID in CVE-YYYY-NNNNN form. If the user provided a name (e.g. "Log4Shell", "xz backdoor", "Spring4Shell"), map to the canonical CVE-ID first using a discovery_search query like "<name> CVE". If the mapping is ambiguous, list candidates and ask the user to pick.

Optional scope arg: prod, staging, account <id>. Default: all accounts.

Step 2: Find every affected asset (parallel)

Run all three queries in parallel:

Query 1: Asset hits by CVE-ID

discovery_search:
  search_phrase: "assets with <CVE-ID>"
  limit: 50

Query 2: Critical exposure hits

discovery_search:
  search_phrase: "internet facing assets with <CVE-ID>"
  limit: 50

Query 3: Active alert hits (catches assets where Orca raised the CVE as an alert)

discovery_search:
  search_phrase: "open alerts for <CVE-ID>"
  limit: 50

De-duplicate by asset_id / group_unique_id after the three queries return. The intersection (assets in all three sets) is the highest priority.

Step 3: Enrich top affected assets (parallel)

Take the top 10 affected assets (prioritized by: internet-facing first → then by alert count → then by asset name). Per asset, in parallel:

get_asset_by_id:
  asset_id: <UUID>

get_asset_related_alerts_summary:
  asset_id: <UUID>

get_asset_related_attack_paths_summary:
  asset_id: <UUID>

get_asset_crown_jewel_info:
  group_unique_id: <group_unique_id>

This yields the runtime context: exposure, attack-path participation, crown jewel, and existing alerts.

Step 4: Rank by real exposure

Score each affected asset on a 0-100 scale:

Ranking tiers (after scoring):

• CRITICAL (≥ 60): internet-facing + attack path + (crown jewel OR other critical alerts). Patch now.
• HIGH (40–59): internet-facing OR attack-path participant. Patch this sprint.
• MEDIUM (20–39): vulnerable but not exposed externally. Patch in normal cycle.
• LOW (< 20): vulnerable but isolated. Patch on next dependency bump.

Step 5: Map attack paths through the CVE

For CRITICAL-tier assets, traverse attack paths starting from the CVE-vulnerable asset:

get_asset_related_attack_paths:
  asset_id: <UUID>

Show the kill chain: CVE → exploit → pivot → crown jewel.

Proactive Remediation Behavior

CRITICAL: Never leave the user with just data. After the report:

1. Suggest action — "Patch <asset> first because it's internet-facing + participates in 2 attack paths."
2. Offer remediation format — "I can generate the patch manifest. Choose format: terraform | helm | ansible | cli | dockerfile-patch | k8s-patch | instructions."
3. For CRITICAL-tier assets, auto-suggest opening an incident ticket and snoozing other noise.

When user picks a format:

• Generate the upgrade or mitigation config
• Write to cve-fix-<cve-id>-<asset>.<ext>
• Include the verification command
• Suggest the next asset to patch

Output Format

Layer 1: Blast Radius Dashboard

═══════════════════════════════════════════════════════════════════
CVE BLAST RADIUS — <CVE-ID>
<CVE name if known, e.g. Log4Shell> | <CVSS score> | <fix available?>
<date> | <scope>
═══════════════════════════════════════════════════════════════════

VERDICT: <one-liner — "12 affected, 3 critical, patch within 24h">

┌─────────────────────────────────────────────────────────────────┐
│  TOTAL AFFECTED        <N> assets                               │
│  CRITICAL TIER         <N> (internet-facing + reachable target) │
│  HIGH TIER             <N> (exposed OR attack-path participant) │
│  MEDIUM TIER           <N> (vulnerable, internal-only)          │
│  LOW TIER              <N> (isolated)                           │
│  CROWN JEWELS AFFECTED <N>                                      │
│  ATTACK PATHS THROUGH  <N>                                      │
│  ACCOUNTS AFFECTED     <N>                                      │
└─────────────────────────────────────────────────────────────────┘

CRITICAL TIER (patch within 24h):
  [1] <asset> (<type>) in <account> — score <X>
      Internet-facing: YES | Attack paths: <N> | Crown jewel: YES/NO
      Other criticals: <N> | Env: prod
      Exploit path: <CVE> → <pivot> → <target>

  [2] <asset> — score <X>
      ...

RECOMMENDED ACTION:
  Patch <top asset> first — <reason>.
  I can generate the patch right now.

  What format? terraform | helm | ansible | cli | dockerfile-patch |
  k8s-patch | instructions | pulumi

═══════════════════════════════════════════════════════════════════
Or drill down: critical | high | medium | low | attack-paths |
by-account | full
═══════════════════════════════════════════════════════════════════

Layer 2: Drill-Downs

"critical" — Critical-tier assets

───────────────────────────────────────────────────────────────────
CRITICAL TIER — Patch Within 24h
───────────────────────────────────────────────────────────────────

  [!] <asset> (<type>) in <account>
      Score: <X>/100
      Internet-facing: YES | Public IP: <ip>
      Attack paths: <N> kill chains through this asset
      Crown jewel: YES (data classification: <X>)
      Other critical alerts: <N>
      Related Orca alert: <alert-id> — <title>
      Fix: upgrade <package> to <safe-version>
      OR mitigation: <workaround if known>

  [!] <asset> — ...

───────────────────────────────────────────────────────────────────

"attack-paths" — Kill chains through the CVE

───────────────────────────────────────────────────────────────────
ATTACK PATHS — CVE as Entry Point
───────────────────────────────────────────────────────────────────

  [1] Score: <X.X>
      Entry: <vulnerable asset> (public IP: <ip>)
        → Exploit: <CVE-ID> (<exploit availability>)
        → Pivot: <internal asset>
        → Target: <crown jewel> (<why it matters>)
      Break chain: patch <package> on <entry asset>

  [2] Score: <X.X>
      Entry: <vulnerable asset>
        → ...

TOTAL PATHS THROUGH <CVE-ID>: <N>
Crown jewels reachable: <N>

───────────────────────────────────────────────────────────────────

"by-account" — Affected count by account

───────────────────────────────────────────────────────────────────
AFFECTED ASSETS BY ACCOUNT
───────────────────────────────────────────────────────────────────

  Account              Total   Critical   High   Medium   Low
  ──────────────────────────────────────────────────────────────
  <account-1>          <N>     <N>        <N>    <N>      <N>
  <account-2>          <N>     <N>        <N>    <N>      <N>
  ...

WORST ACCOUNT: <account> — <why>

───────────────────────────────────────────────────────────────────

"high" / "medium" / "low"

Same table-per-tier layout as "critical" with reduced enrichment.

"full"

Show all sections in order.

Edge Cases

CVE Not Found in Any Asset

✅ No assets affected by <CVE-ID> in the monitored environment.

Caveats:
  • Verify Orca scanner coverage with /orca-account-health
  • The CVE may be too new for Orca's vulnerability database — check the
    Orca UI → Vulnerabilities for the latest sync time
  • Some vulnerabilities only surface after a workload runs — recently
    deployed assets may not yet be flagged

Invalid or Unrecognized CVE-ID

⚠ <input> doesn't match a known CVE.

Did you mean one of these?
  • CVE-YYYY-XXXXX — <title>
  • CVE-YYYY-XXXXX — <title>

Or provide the canonical ID in CVE-YYYY-NNNNN form.

Massive Blast Radius (> 50 hits per query)

⚠ <CVE-ID> affects more than 50 assets — discovery_search is capped at 50.

Showing top 50 by exposure score. For the full inventory:
  Open the app_url in the discovery_search response, OR
  Re-run with a narrower scope: /orca-cve-blast-radius <CVE> account <id>

CVE Affects Multiple Packages

<CVE-ID> spans multiple packages: <name1>, <name2>.
Showing combined exposure. Drill into a single package with:
  /orca-supply-chain-exposure <package>

MCP Tools Used

Primary Tools

Secondary Tools

Parameter Notes

• The three discovery_search queries (asset-with-CVE, internet-facing-with-CVE, open-alerts-for-CVE) hit different indexes — running all three is what catches assets that one query alone misses.
• discovery_search is capped at 50 results — surface app_url when truncated and recommend account-level scoping.
• get_asset_related_attack_paths_summary returns counts only; use get_asset_related_attack_paths for full kill-chain.
• CVE name → CVE-ID mapping (e.g. "Log4Shell" → CVE-2021-44228) is not built into the MCP; a discovery_search for "<name> CVE" is the usable workaround.

Implementation Notes

1. The three-query fan-out in Step 2 is non-negotiable — each surfaces different assets. De-duplicate after, not before.
2. Real exposure beats CVSS. A CVSS 10.0 on an isolated dev box matters less than a CVSS 7.5 on an internet-facing crown jewel. The scoring rubric in Step 4 enforces this.
3. Cap enrichment to top 10 assets — full per-asset enrichment is 4 tool calls × N assets. With many affected assets, this balloons fast.
4. CRITICAL tier should always have an exploit path shown, even if it's a one-hop ("CVE → asset → exposed port"). The kill chain framing is what makes the urgency clear.
5. Link to other skills: suggest /orca-impact-analysis for fix consequences, /orca-alert-triage <alert-id> for the related Orca CVE alert, /orca-supply-chain-exposure <package> for the package-level view, /orca-asset-profile <asset> for full asset context.
6. The CVE may not be in Orca's DB yet for very fresh disclosures — surface the caveat in the "Not Found" edge case and don't claim a clean bill of health prematurely.