使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/orcasecurity/orca-skills --skill orca-cve-blast-radius開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
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 prodOr 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: 50Query 2: Critical exposure hits
discovery_search:
search_phrase: "internet facing assets with <CVE-ID>"
limit: 50Query 3: Active alert hits (catches assets where Orca raised the CVE as an alert)
discovery_search:
search_phrase: "open alerts for <CVE-ID>"
limit: 50De-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:
| Signal | Points |
|---|---|
| Internet-facing | +30 |
| Participates in ≥1 attack path | +25 |
| Crown jewel | +20 |
| ≥1 other CRITICAL alert | +15 |
| Prod environment tag | +10 |
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:
- Suggest action — "Patch
<asset>first because it's internet-facing + participates in 2 attack paths." - Offer remediation format — "I can generate the patch manifest. Choose format: terraform | helm | ansible | cli | dockerfile-patch | k8s-patch | instructions."
- 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 flaggedInvalid 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
| Tool | Purpose | Parameter |
|---|---|---|
discovery_search | Find assets affected by a CVE | search_phrase (NL), limit |
get_asset_by_id | Asset metadata + env tag | asset_id (UUID) |
get_asset_related_alerts_summary | Existing alerts (incl. the CVE alert itself) | asset_id (UUID) |
get_asset_related_attack_paths_summary | Attack-path participation count | asset_id (UUID) |
get_asset_crown_jewel_info | Crown jewel status | group_unique_id |
Secondary Tools
| Tool | Purpose | When |
|---|---|---|
get_asset_related_attack_paths | Full kill-chain detail | "attack-paths" drill-down |
get_attack_path | Single attack-path expansion | When drilling into one chain |
get_alert | Full detail on the CVE alert | When user wants alert text/IoC |
get_alerts_with_similar_alert_type | Other CVE alerts of same type | Pattern-matching across assets |
Parameter Notes
- The three
discovery_searchqueries (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_searchis capped at 50 results — surfaceapp_urlwhen truncated and recommend account-level scoping.get_asset_related_attack_paths_summaryreturns counts only; useget_asset_related_attack_pathsfor full kill-chain.- CVE name → CVE-ID mapping (e.g. "Log4Shell" → CVE-2021-44228) is not built into the MCP; a
discovery_searchfor"<name> CVE"is the usable workaround.
Implementation Notes
- The three-query fan-out in Step 2 is non-negotiable — each surfaces different assets. De-duplicate after, not before.
- 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.
- Cap enrichment to top 10 assets — full per-asset enrichment is 4 tool calls × N assets. With many affected assets, this balloons fast.
- 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.
- Link to other skills: suggest
/orca-impact-analysisfor 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. - 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.
