SCA & Reachability Analysis

Prerequisites

Source code repository or lockfile access (Git clone URL or local path)
At least one supported lockfile present in the repository (see supported formats below)
Claude API key configured for AI-powered reachability analysis (Settings → AI Configuration)
Network access to NVD, OSV, and EPSS databases for vulnerability matching
Written authorization covering source code analysis of the target application

1

Select SCA & Reachability from Home Screen

Click the 📦 SCA & Reachability card on the Home screen. This opens the SCA configuration panel.

What makes PhantomYerra SCA different from traditional SCA tools: Traditional SCA tools report every CVE associated with every dependency version in your manifest. This produces hundreds of findings, the vast majority of which your application never actually calls. PhantomYerra builds a call graph from your application's HTTP entry points, CLI handlers, and event listeners, tracing function calls all the way down into dependency code. Only vulnerabilities where the vulnerable function is actually reachable from an entry point are flagged as actionable. The result: 70-90% noise reduction, with every remaining finding backed by a concrete call chain.
2

Configure Source Input

Provide the source code for analysis. PhantomYerra needs both the dependency manifest and the application source to build call graphs:

Input Methods: Git Repository Clone URL (HTTPS or SSH) + branch + optional commit hash Local Path Absolute path to project root on disk Lockfile Upload Upload lockfile directly (dependency-only mode, no reachability) Supported Lockfiles (auto-detected from repository): package-lock.json npm (JavaScript/TypeScript) yarn.lock Yarn (JavaScript/TypeScript) pnpm-lock.yaml pnpm (JavaScript/TypeScript) Pipfile.lock Pipenv (Python) requirements.txt pip (Python) — with pinned versions poetry.lock Poetry (Python) Gemfile.lock Bundler (Ruby) go.sum Go modules (Go) Cargo.lock Cargo (Rust) pom.xml Maven (Java) — resolved dependency tree build.gradle Gradle (Java/Kotlin) — resolved dependency tree packages.lock.json NuGet (.NET/C#) composer.lock Composer (PHP) Package.resolved Swift Package Manager (Swift) mix.lock Hex (Elixir)

If the project uses multiple lockfiles (e.g., a monorepo with both package-lock.json and requirements.txt), PhantomYerra analyzes all of them and merges the results.

Branch Selection: Choose the branch to analyze. Default is main or master. For PR reviews, select the feature branch to see new dependency risks introduced by that branch.
3

Configure Analysis Options

Analysis Depth: Dependencies Only Direct dependencies listed in manifest Dev + Production Both devDependencies and production dependencies Full Transitive All transitive dependencies (deepest analysis) Reachability Mode: Call Graph (default) Build full call graph from entry points to deps Most accurate — traces actual function calls Static Import-level analysis only (faster, less precise) Checks if vulnerable module is imported, not if the specific vulnerable function is called Behavioral Runtime-informed (requires test suite execution) Runs test suite, instruments calls, highest accuracy Language (auto-detected): JavaScript / TypeScript / Python / Java / Go / Ruby / Rust .NET (C#) / PHP / Swift / Elixir / Kotlin Framework Hints (optional, improves entry point detection): Express / Fastify / Next.js / Django / Flask / FastAPI Spring Boot / Gin / Rails / Laravel / ASP.NET Core Phoenix / Vapor / Actix-Web / Rocket

Framework hints help PhantomYerra identify entry points more accurately. For example, selecting "Express" tells the analyzer to look for app.get(), app.post(), and router.use() patterns as HTTP entry points. Without hints, PhantomYerra uses heuristic detection (works for most projects but may miss custom routing patterns).
4

Complete Mission Control Wizard

Step 1: Environment → Source repository confirmed Step 2: Mode → Automated AI (selected) Step 3: Surfaces → SCA & Reachability (auto-selected) Step 4: Source Input → Git URL or local path confirmed Step 5: Auth Token → Authorization for source code analysis Step 6: Options → Depth, reachability mode, language, framework Step 7: AI Interview → "What are the main entry points?" "Are there background workers or cron jobs?" "Any vendored/forked dependencies?" Step 8: Review → Confirm settings, launch analysis
5

AI SCA Pipeline (8-Phase)

Claude orchestrates the full SCA pipeline, building from dependency resolution through to prioritized findings:

Phase 1: Dependency Tree Resolution Parse all lockfiles, resolve full transitive dependency tree. For each dependency: name, version, license, direct vs transitive. Output: complete dependency graph with version pins. Phase 2: Version Extraction & SBOM Generation Generate CycloneDX SBOM (JSON) with all components. Extract exact versions, package URLs (purls), hashes. Cross-reference with known end-of-life / unmaintained packages. Phase 3: CVE Matching Match every dependency version against: NVD (National Vulnerability Database) — primary source OSV (Open Source Vulnerabilities) — language-specific advisories GitHub Advisory Database — GitHub Security Advisories Vendor advisories (npm, PyPI, RubyGems, crates.io) Output: raw CVE list with CVSS vectors and severity. Phase 4: EPSS Scoring Enrich each CVE with EPSS (Exploit Prediction Scoring System): EPSS score (0.0-1.0) = probability of exploitation in next 30 days EPSS percentile = how this CVE ranks against all CVEs CVEs with EPSS > 0.5 are flagged as "Actively Exploited" priority. Phase 5: Call Graph Construction Build call graph from all entry points: HTTP route handlers, CLI entry points, event listeners, background workers, scheduled tasks, WebSocket handlers. Trace every function call chain into dependency code. Resolve dynamic imports, conditional requires, lazy loading. Phase 6: Reachability Verdict For each CVE, determine if the vulnerable function is reachable: REACHABLE Entry point → call chain → vulnerable function POTENTIALLY_REACHABLE Call chain exists but passes through dynamic dispatch, reflection, or conditional logic UNREACHABLE Vulnerable function never called from any entry point in the application Phase 7: Exploit Availability Check For each REACHABLE CVE, check: Public PoC available? (GitHub, Exploit-DB, PacketStorm) Active exploitation in the wild? (CISA KEV, threat intel feeds) Metasploit module available? Patch available? (fixed version identified) Phase 8: Prioritized Report Generation Rank all findings by: Reachability → CVSS → EPSS → Exploit Avail. Generate noise reduction metrics (before/after reachability filter). Produce call chain evidence for every REACHABLE finding. Generate upgrade recommendations with breaking change warnings.
6

Review Dashboard

The SCA dashboard provides a complete view of your dependency security posture:

Summary Panel (top): Total CVEs Found Raw CVE count before filtering After Reachability Filter CVEs that are REACHABLE or POTENTIALLY_REACHABLE Noise Reduction % Percentage of CVEs eliminated by reachability analysis Example: 847 total → 94 reachable = 89% noise reduction Reachability Badges (per finding): [REACHABLE] Red badge — fix immediately, full call chain shown [POTENTIALLY_REACHABLE] Yellow badge — review required, partial call chain [UNREACHABLE] Gray badge — safe to deprioritize, reason shown Call Chain Viewer (click any REACHABLE finding): HTTP Entry: POST /api/users/update → UserController.update(req, res) src/controllers/user.ts:47 → UserService.updateProfile(userId, data) src/services/user.ts:123 → sanitize(data) src/utils/sanitize.ts:8 → lodash.merge(target, data) node_modules/lodash/merge.js:23 CVE-2021-23337 — Prototype Pollution — REACHABLE SBOM Export (bottom toolbar): CycloneDX JSON Machine-readable SBOM for compliance SPDX Alternative SBOM format CSV Spreadsheet-friendly export VEX Vulnerability Exploitability eXchange document

Click Reports → Generate → SCA Reachability Report for the full PDF with executive summary, reachability analysis results, call chain evidence, upgrade plan, and compliance documentation.

What Claude Analyzes (SCA Reachability)

Known vulnerabilities (CVE/GHSA) in all direct and transitive dependencies
Reachability of vulnerable functions from application entry points
Exploit availability and active exploitation status (CISA KEV, EPSS)
License compliance: GPL, AGPL, LGPL, MIT, Apache, BSD, proprietary conflicts
End-of-life and unmaintained packages (no security patches)
Typosquatting detection (dependency confusion, namespace hijacking)
Pinning and lockfile integrity (detect unpinned or floating versions)
Breaking change analysis for recommended upgrades

⏱ Typical duration: 5-30 minutes depending on repository size and dependency count. Call graph construction is the most time-intensive phase (scales with codebase LOC).

Prerequisites

Same as Automated AI mode
Select "Semi-Automated" in Wizard Step 2
Familiarity with dependency management for the target language

1

Configure Source and Approve Dependency Scan

Proposal: "Parse package-lock.json and resolve full transitive dependency tree" → [Approve] → 1,247 packages resolved (312 direct, 935 transitive) → 3 lockfile integrity warnings: lodash@4.17.20 — pinned but 4.17.21 available (security patch) axios@0.21.1 — pinned but 1.6.0 available (major version jump) tar@4.4.13 — pinned but 6.2.0 available (multiple CVEs fixed)
2

Review CVE Matches and Approve Reachability Analysis

Proposal: "Match all 1,247 packages against NVD + OSV + GitHub Advisory databases" → [Approve] → 847 CVEs found across 89 packages → Severity breakdown: 12 Critical, 47 High, 198 Medium, 590 Low Proposal: "Build call graph from 23 detected HTTP entry points and trace reachability to all 847 CVE-affected functions" → [Approve] → Reachability analysis complete: REACHABLE: 14 CVEs (entry point → vulnerable function path confirmed) POTENTIALLY_REACHABLE: 80 CVEs (partial call chain, needs review) UNREACHABLE: 753 CVEs (vulnerable function never called) Noise reduction: 89% Proposal: "Enrich 14 REACHABLE findings with EPSS scores and exploit availability" → [Approve] → 3 CVEs have public PoC exploits 2 CVEs are in CISA KEV (known exploited vulnerabilities) 1 CVE has active Metasploit module
3

Review Call Chains and Generate Report

Proposal: "Generate call chain evidence for all 14 REACHABLE findings and produce upgrade recommendations with breaking change analysis" → [Approve] → 14 findings with full call chains documented Upgrade plan generated: lodash 4.17.20 → 4.17.21 (patch, no breaking changes) axios 0.21.1 → 1.6.0 (major, 3 breaking changes listed) tar 4.4.13 → 6.2.0 (major, 5 breaking changes listed) → [Generate Report] → SCA Reachability Report (PDF)

⏱ Typical duration: 15-45 minutes with active approval at each phase.

Prerequisites

PhantomYerra SBOM generation tools configured (Settings → Tools)
PhantomYerra vulnerability matcher configured with NVD API key (optional, increases rate limit)
Source code accessible on local filesystem for call graph analysis
Python 3.12 runtime active for reachability engine

1

Generate SBOM (Software Bill of Materials)

Create a complete inventory of all software components using PhantomYerra's SBOM generator:

# PhantomYerra → Tools → SBOM Generator → select project directory # The SBOM generator produces output in multiple formats: # CycloneDX JSON (recommended — richest metadata) # PhantomYerra → Tools → SBOM Generator → Format: CycloneDX JSON # Output: sbom.cdx.json # SPDX (for compliance with NTIA minimum elements) # PhantomYerra → Tools → SBOM Generator → Format: SPDX # Output: sbom.spdx.json # Table (human-readable summary) # PhantomYerra → Tools → SBOM Generator → Format: Table # Output: console table showing: # NAME VERSION TYPE LICENSE # lodash 4.17.20 npm MIT # express 4.18.2 npm MIT # axios 0.21.1 npm MIT # jsonwebtoken 9.0.0 npm MIT # ... (all 1,247 packages) # For container images, scan the image directly: # PhantomYerra → Tools → SBOM Generator → Source: Docker Image # Image: myapp:latest # Scans both OS packages (apt/yum) AND application dependencies
2

Vulnerability Matching

Match every component in the SBOM against known vulnerability databases:

# PhantomYerra → Tools → Vulnerability Matcher → select SBOM file # The matcher checks against multiple databases: # NVD (National Vulnerability Database) — US government CVE source # OSV (Open Source Vulnerabilities) — language-ecosystem advisories # GitHub Advisory Database — GHSA identifiers # Vendor advisories (npm audit, pip-audit, bundle-audit equivalents) # Output: vulnerability list sorted by severity # CVE-2021-23337 lodash@4.17.20 HIGH Prototype Pollution (merge) # CVE-2021-3749 axios@0.21.1 HIGH ReDoS in trim function # CVE-2021-37701 tar@4.4.13 HIGH Arbitrary file overwrite # CVE-2021-37712 tar@4.4.13 HIGH Path traversal # ... (847 total CVEs) # Filter by severity: # PhantomYerra → Vulnerability Matcher → Severity: High + Critical only # Result: 59 findings (12 Critical + 47 High) # Export to SARIF for GitHub Code Scanning integration: # PhantomYerra → Vulnerability Matcher → Export: SARIF
3

Reachability Analysis

Build call graphs and determine which vulnerable functions your application actually calls:

# PhantomYerra → Tools → Reachability Analyzer → select project root # Step 1: The analyzer detects entry points automatically: # HTTP handlers (Express routes, Flask views, Spring controllers) # CLI entry points (main functions, command handlers) # Event listeners (WebSocket handlers, queue consumers) # Background workers (cron jobs, scheduled tasks) # Step 2: Call graph construction # Static analysis: follows import/require chains into node_modules/ # For each CVE: checks if the specific vulnerable FUNCTION is called # Not just "is the package imported" but "is merge() called" for lodash # Step 3: Reachability verdict for each CVE: # REACHABLE: # CVE-2021-23337 lodash.merge() called via: # POST /api/users/update → updateProfile() → sanitize() → merge() # # POTENTIALLY_REACHABLE: # CVE-2021-3749 axios used but trim() path depends on server response # # UNREACHABLE: # CVE-2020-8203 lodash.zipObjectDeep() — never imported or called # Reason: "Function zipObjectDeep not present in any import statement # or require() call in the application codebase" # View call chain for any finding: # PhantomYerra → Reachability Analyzer → click finding → "View Call Chain"
4

EPSS Enrichment

Add exploit probability scores to prioritize remediation effectively:

# PhantomYerra → Tools → EPSS Enrichment → select vulnerability list # EPSS (Exploit Prediction Scoring System) adds: # Score: 0.0 to 1.0 (probability of exploitation in next 30 days) # Percentile: rank against all CVEs in the EPSS database # # Example enriched output: # CVE-2021-23337 CVSS 7.2 EPSS 0.72 Percentile 95th REACHABLE # CVE-2021-37701 CVSS 8.1 EPSS 0.45 Percentile 88th REACHABLE # CVE-2021-3749 CVSS 7.5 EPSS 0.03 Percentile 42nd POTENTIALLY_REACHABLE # Priority matrix (used by PhantomYerra for final ranking): # REACHABLE + EPSS > 0.5 = P1 (fix within 24 hours) # REACHABLE + EPSS 0.1-0.5 = P2 (fix within 1 week) # REACHABLE + EPSS < 0.1 = P3 (fix within 1 sprint) # POTENTIALLY_REACHABLE = P4 (review and fix within 1 month) # UNREACHABLE = P5 (document for compliance, fix when convenient)
5

License Compliance Analysis

Identify license conflicts and compliance risks in your dependency tree:

# PhantomYerra → Tools → License Analyzer → select SBOM file # Checks for: # Copyleft conflicts: GPL/AGPL dependencies in proprietary software # License compatibility: MIT + Apache OK; GPL + proprietary NOT OK # Missing licenses: packages with no declared license (legal risk) # Multi-licensed packages: verify correct license selected # LGPL dynamic vs static linking: static = copyleft trigger # Example output: # CONFLICT: readline@8.1 (GPL-3.0) — used in proprietary application # WARNING: unknown-pkg@1.0.0 — no license file found # OK: lodash@4.17.20 (MIT) — compatible with proprietary use # INFO: openssl@3.0.0 (Apache-2.0) — compatible, attribution required # License policy enforcement: # Settings → SCA → License Policy → define allowed/denied licenses # Denied licenses trigger a FAIL verdict in CI/CD pipeline
6

VEX Document Generation

Create Vulnerability Exploitability eXchange statements for compliance and customer communication:

# PhantomYerra → Tools → VEX Generator → select analysis results # VEX (Vulnerability Exploitability eXchange) documents formally state: # - Which CVEs affect your product # - Which CVEs are NOT exploitable (with justification) # - Remediation status for exploitable CVEs # VEX status values: # not_affected Vulnerable code is not reachable (with call graph proof) # affected Vulnerable code is reachable, remediation in progress # fixed Patched in version X.Y.Z # under_investigation Reachability analysis inconclusive, reviewing # Example VEX statement: # { # "vulnerability": "CVE-2020-8203", # "product": "MyApp v2.1.0", # "status": "not_affected", # "justification": "vulnerable_code_not_in_execute_path", # "detail": "lodash.zipObjectDeep() is never called from any # application entry point. Call graph analysis confirms # no import path reaches the vulnerable function." # } # Export formats: CycloneDX VEX, CSAF, OpenVEX # Use for: customer security questionnaires, compliance audits, # supply chain transparency (Executive Order 14028)

⏱ Duration: 1-4 hours for a complete manual SCA + reachability analysis + VEX documentation.

Configuration Options

Option	Values	Default	Description
Analysis Depth	Dependencies Only / Dev+Prod / Full Transitive	Full Transitive	How deep into the dependency tree to analyze
Reachability Mode	Call Graph / Static / Behavioral	Call Graph	Method used to determine if vulnerable functions are reachable
Language	Auto / JS / Python / Java / Go / Ruby / Rust / .NET / PHP	Auto-detect	Programming language of the application being analyzed
Framework	Auto / Express / Django / Spring / Rails / etc.	Auto-detect	Web framework hint for better entry point detection
CVE Databases	NVD / OSV / GitHub / All	All	Which vulnerability databases to query for CVE matching
EPSS Enrichment	On / Off	On	Add exploit probability scores from FIRST EPSS database
License Check	On / Off	On	Check dependency licenses for compliance conflicts
License Policy	Permissive / Strict / Custom	Permissive	Which licenses to allow/deny in the dependency tree
SBOM Format	CycloneDX / SPDX / Both	CycloneDX	Output format for the Software Bill of Materials
VEX Output	On / Off	Off	Generate VEX document with reachability justifications
CI/CD Fail Threshold	REACHABLE only / All CVEs / Custom	REACHABLE only	Which findings cause CI/CD pipeline failure
Severity Threshold	Critical / High / Medium / Low / Info	High	Minimum severity to include in actionable findings
Ignore File	Path to .phantomyerra-ignore	None	File listing CVEs to suppress (accepted risk)
Report Format	PDF / HTML / JSON / SARIF	PDF	Output format for the SCA report

Reachability Verdicts Explained

Verdict	Meaning	Action Required	Call Chain Evidence
REACHABLE	The vulnerable function is directly called from an HTTP-reachable entry point with data that flows from user input	Fix immediately: upgrade dependency or apply workaround	Full call chain from entry point to vulnerable function with file:line references
POTENTIALLY_REACHABLE	The vulnerable function is called but the path passes through dynamic dispatch, reflection, or runtime-conditional logic	Developer review required: verify if user input can reach this path	Partial call chain with gap notation where static analysis could not resolve the target
UNREACHABLE	The vulnerable function is never called from any entry point in the application	Safe to deprioritize: document for compliance, fix in next sprint	Reason provided: "function not imported", "only called in test suite", "behind admin gate"

Common Scenarios

Goal: Reduce the overwhelming CVE list from npm audit to only exploitable findings.

Recommended Settings: Full Transitive depth, Call Graph reachability, Express framework hint, EPSS enrichment enabled.

Approach: Upload the repository with package-lock.json. PhantomYerra resolves the full dependency tree (typically 1000-3000 packages for a mid-size Express app). The call graph traces from Express route handlers into node_modules/. Expect 80-95% noise reduction — most CVEs in transitive dependencies affect functions your app never calls. Focus remediation on the 5-15% that are REACHABLE.

Expected Duration: 10-15 minutes.

Goal: Audit a Django application with requirements.txt and identify which outdated packages actually pose a risk.

Recommended Settings: Dev+Production depth (include test dependencies to verify they are not shipped), Call Graph reachability, Django framework hint.

Approach: PhantomYerra parses requirements.txt and resolves transitive dependencies via pip's resolver. For Django apps, entry points are detected from urls.py patterns, management commands, and Celery tasks. The analyzer traces through Django's middleware chain, view functions, serializers, and model methods into third-party libraries. Common finding: Pillow CVEs are often UNREACHABLE if the app does not process user-uploaded images.

Expected Duration: 8-12 minutes.

Goal: Analyze a Maven-based Spring Boot microservice and produce VEX documents for customer compliance questionnaires.

Recommended Settings: Full Transitive depth, Call Graph reachability, Spring Boot framework hint, VEX output enabled, CycloneDX SBOM format.

Approach: PhantomYerra resolves the Maven dependency tree from pom.xml (typically 200-500 JARs for a Spring Boot app). Bytecode-level call graph analysis traces from @RestController methods through @Service and @Repository layers into third-party JARs. Spring Boot's auto-configuration means many libraries are included but never activated — reachability analysis identifies these as UNREACHABLE. Generate VEX documents in CycloneDX format for SOC 2 and ISO 27001 audits.

Expected Duration: 15-25 minutes (bytecode analysis is more intensive than source-level).

Goal: Block PRs that introduce REACHABLE Critical/High CVEs while allowing UNREACHABLE CVEs to pass.

Recommended Settings: CI/CD Fail Threshold = REACHABLE only, Severity Threshold = High, SARIF output for GitHub Code Scanning integration.

Approach: Add PhantomYerra SCA to your CI pipeline. On every PR, PhantomYerra resolves dependencies from the lockfile, matches CVEs, and runs reachability analysis against the branch's source code. Only REACHABLE findings with High or Critical severity block the merge. UNREACHABLE and POTENTIALLY_REACHABLE findings are reported as annotations but do not block. SARIF output integrates with GitHub's Security tab, showing findings inline on the PR diff. Developers see exactly which function calls reach vulnerable code.

Expected Duration: 3-8 minutes per pipeline run.

Common Issues

The reachability analyzer could not detect any HTTP entry points, CLI handlers, or event listeners. This usually means the framework was not recognized. Go to Settings → SCA → Framework Hint and select the correct framework (Express, Django, Spring, etc.). For custom frameworks or non-web applications, manually specify entry point files in the analyzer configuration: "entry_points": ["src/main.ts", "src/cli.ts"]. For serverless functions (AWS Lambda, Azure Functions), select the "Serverless" framework hint.

This occurs when the lockfile is out of sync with the manifest (e.g., package.json was modified but package-lock.json was not regenerated). Run the package manager's install command to regenerate the lockfile: npm install, yarn install, pip freeze > requirements.txt, etc. For monorepos, ensure all workspace lockfiles are present. If the repository requires authentication for private registries, configure the registry credentials in Settings → SCA → Registry Auth.

POTENTIALLY_REACHABLE findings occur when the call chain passes through dynamic dispatch (e.g., obj[methodName]() in JavaScript, reflection in Java). Two approaches to reduce these: (1) Switch to Behavioral reachability mode, which runs your test suite and instruments actual function calls at runtime — this resolves dynamic dispatch definitively. (2) Add type annotations or JSDoc comments to your source code to help the static analyzer resolve dynamic calls. For Java projects, enabling -parameters compiler flag preserves method parameter names, improving call graph precision.

Different tools query different vulnerability databases and use different matching algorithms. PhantomYerra queries NVD + OSV + GitHub Advisories simultaneously, which may produce more or fewer matches than a single-source tool. Additionally, PhantomYerra de-duplicates CVEs that appear in multiple databases under different identifiers (CVE vs GHSA). To see the raw un-deduplicated count, enable Settings → SCA → Show All Advisory IDs. To match a specific tool's output, disable databases in Settings → SCA → CVE Databases until only NVD remains (for npm audit parity).

Call graph construction scales with codebase size. For very large codebases: (1) Switch to Static reachability mode (import-level only) for a faster but less precise result. (2) Limit analysis to specific directories using Settings → SCA → Source Paths (e.g., only src/ excluding test/ and vendor/). (3) Increase the analysis timeout in Settings → SCA → Call Graph Timeout from the default 300s to 900s. (4) For monorepos, analyze each workspace/package separately rather than the entire repository at once.

Full Disclosure

264 modules · 30+ surfaces · 14 vuln families · 120+ classes

The sections above describe what this surface tests. For the complete enumeration of every vulnerability class PhantomYerra covers across all surfaces — with scanner module names — see the Coverage Matrix.

View Full Coverage Matrix →

Prerequisites

Select SCA & Reachability from Home Screen

Configure Source Input

Configure Analysis Options

Complete Mission Control Wizard

AI SCA Pipeline (8-Phase)

Review Dashboard

What Claude Analyzes (SCA Reachability)

Prerequisites

Configure Source and Approve Dependency Scan

Review CVE Matches and Approve Reachability Analysis

Review Call Chains and Generate Report

Prerequisites

Generate SBOM (Software Bill of Materials)

Vulnerability Matching

Reachability Analysis

EPSS Enrichment

License Compliance Analysis

VEX Document Generation

Configuration Options

Reachability Verdicts Explained

Common Scenarios

Common Issues

Related Topics

264 modules · 30+ surfaces · 14 vuln families · 120+ classes