SAST, DAST & SBOM Analysis
Static source code analysis (15+ languages), dynamic web application testing (runtime vulnerability discovery), and Software Bill of Materials generation with CVE matching and license compliance.
Prerequisites
- Source code repository path, Git URL, or uploaded archive (.zip / .tar.gz)
- For DAST: running target URL accessible from the PhantomYerra machine
- For SBOM: package manager lock files or container images available
- Claude API key configured (Settings → AI Configuration)
- Application credentials available (for authenticated DAST testing)
- Sufficient disk space for codebase cloning and analysis artifacts
-
1
Select SAST / DAST / SBOM from Home Screen
Click the 🔍 SAST / DAST / SBOM card on the Home Screen. Choose which analyses to run:
Analysis Types: SAST (Static Application Security Testing) → Analyzes source code WITHOUT executing it → Finds vulnerabilities in code patterns, data flows, and configurations → Supports 15+ programming languages simultaneously → Produces findings with exact file path, line number, and fix suggestions DAST (Dynamic Application Security Testing) → Tests a RUNNING web application by sending real HTTP requests → Discovers runtime vulnerabilities: injection, auth bypass, misconfig → Includes authenticated crawling with session management → Produces findings with raw HTTP request/response evidence SBOM (Software Bill of Materials) → Generates a complete inventory of all software components → Matches every component version against CVE databases → Identifies license compliance issues (GPL, AGPL, restrictive) → Produces CycloneDX, SPDX 2.3, and VEX documents Combined (recommended) → Run all three for comprehensive coverage → Cross-correlates SAST findings with SBOM vulnerable components → Links DAST runtime findings to SAST source code locations -
2
Configure Source Input
Provide the source material for each analysis type you selected.
SAST Input Options: Git Repository URL → https://github.com/org/repo.git (cloned automatically) Local Directory → C:\Projects\my-app\ or /home/user/my-app/ Uploaded Archive → Drag-and-drop .zip or .tar.gz into the upload area Branch / Tag → Select specific branch (default: main/master) Monorepo Filter → Analyze specific subdirectories only (e.g. src/, api/) DAST Input Options: Target URL → https://staging.yourapp.com (must be authorized) Auth Configuration → Bearer Token / API Key / Session Cookie / Basic Auth / Form-based login (URL + username + password fields) Crawl Depth → 1–10 (default: 5, deeper = more coverage, slower) Excluded Paths → /logout, /admin/delete-*, /api/dangerous-endpoint OpenAPI / Swagger → Upload spec file for API-aware testing Rate Limit → Requests per second (default: 10, reduce for prod) SBOM Input Options: Lock Files → requirements.txt, package-lock.json, yarn.lock, go.sum, pom.xml, Cargo.lock, Gemfile.lock, composer.lock, packages.config, Pipfile.lock Container Images → Docker image name (local or registry: nginx:1.24) Binary Inspection → Upload compiled binary for dependency extraction VEX Document → Import existing VEX to exclude known-acceptable risks -
3
Language and Framework Auto-Detection
PhantomYerra scans the source tree and automatically selects the appropriate security analyzers for each detected language. The detection table below shows what runs for each language:
Language / Framework Primary Analyzer Secondary Analyzer ───────────────────────────────────────────────────────────────────────── Python Semgrep (Python ruleset) Bandit JavaScript / TypeScript Semgrep (JS/TS ruleset) ESLint-security, npm audit Java Semgrep (Java ruleset) SpotBugs + Find Security Bugs C / C++ cppcheck + Flawfinder Semgrep (C/C++ ruleset) Go gosec Semgrep (Go ruleset) Rust cargo-audit Semgrep (Rust ruleset) .NET / C# Semgrep (C# ruleset) Security Code Scan Ruby Brakeman Semgrep (Ruby ruleset) PHP Psalm (security) Semgrep (PHP ruleset) Swift SwiftLint (security rules) Semgrep (Swift ruleset) Kotlin detekt (security rules) Semgrep (Kotlin ruleset) Solidity Slither + Mythril Semgrep (Solidity ruleset) COBOL Semgrep (COBOL patterns) Custom COBOL security rules Terraform / HCL tfsec + Checkov Semgrep (Terraform ruleset) CloudFormation Checkov (CFN framework) cfn-lint security rules Kubernetes YAML kubelinter + kube-score Checkov (K8s framework) Helm Charts Checkov (Helm framework) kubelinter Dockerfile Hadolint Checkov (Dockerfile) Shell Scripts ShellCheck Semgrep (Bash ruleset) SQL Semgrep (SQL injection) Custom SQL security patterns -
4
Attack Categories Selection
Select which vulnerability categories to test for. All categories are enabled by default. Deselect categories to narrow the scope.
Vulnerability Categories: Injection Flaws → SQL injection, NoSQL injection, OS command injection, LDAP injection, XPath injection, template injection Cross-Site Scripting (XSS) → Reflected XSS, Stored XSS, DOM-based XSS Authentication Issues → Weak passwords, session fixation, MFA bypass, insecure password reset, credential stuffing Cryptographic Weaknesses → Weak algorithms (MD5, SHA1, DES), hardcoded keys, insufficient key length, insecure random generation Sensitive Data Exposure → PII in logs, API keys in source, credentials in config, unencrypted sensitive storage, verbose error messages Insecure Deserialization → Pickle, Java ObjectInputStream, JSON.parse with gadgets, YAML.load unsafe, .NET BinaryFormatter Server-Side Request Forgery→ URL parameter SSRF, DNS rebinding, blind SSRF via webhook/callback, cloud metadata access (169.254.169.254) Path Traversal → File read via ../, file write via ../, ZIP slip, symlink attacks, absolute path injection Race Conditions → TOCTOU, double-spend, concurrent request abuse, file lock bypass, database transaction races Hardcoded Secrets → API keys, passwords, tokens, private keys, database connection strings, AWS access keys in source code Unsafe Dependencies → Known CVEs in imported packages, outdated libraries, unmaintained dependencies, license violations -
5
AI Engine Orchestrates Analysis Pipelines
Claude orchestrates all three analysis pipelines in parallel, cross-correlating findings across SAST, DAST, and SBOM results.
SAST Pipeline: 1. Parse → Build AST (Abstract Syntax Tree) for each source file 2. Rule Match → Run language-specific security rules (2000+ rules) 3. Taint Analysis→ Trace data flow from source (user input) to sink (dangerous function): e.g. request.GET["id"] → cursor.execute() 4. AI Semantic → Claude reviews each finding's code context for business logic vulnerabilities that rules cannot catch 5. FP Filtering → AI removes false positives by analyzing control flow, sanitization functions, and framework protections 6. Severity Rate → Assign CVSS + exploitability + business impact score DAST Pipeline: 1. Crawl → Spider the target application, discover all endpoints 2. Endpoint Map → Build sitemap with parameters, forms, APIs, WebSockets 3. Active Test → Send payloads for each vulnerability category: SQLi probes, XSS vectors, SSRF callbacks, path traversal 4. Payload Inject→ Context-aware payload generation adapted to the target's tech stack, WAF, and response patterns 5. Response Parse→ Analyze HTTP responses for vulnerability indicators: error messages, reflected input, timing differences 6. Evidence Save → Capture full HTTP request/response for each finding SBOM Pipeline: 1. Dependency Tree → Parse all lock files, build full dependency graph (direct + transitive dependencies) 2. Version Match → Match each component name + version against NVD, OSV, GitHub Advisories, and vendor-specific databases 3. CVE Lookup → Pull CVSS scores, EPSS probabilities, exploit availability for every matched CVE 4. Reachability → Analyze whether vulnerable code paths in dependencies are actually called by your application 5. License Audit → Identify license type for each component: MIT, Apache-2.0, GPL-3.0, AGPL-3.0, LGPL, proprietary, unknown 6. VEX Generate → Create Vulnerability Exploitability eXchange document marking each CVE as: exploitable / not affected / fixed -
6
Review Findings
All findings from SAST, DAST, and SBOM are presented in a unified view with cross-correlation.
Finding Details: Code Location → Exact file path, line number, column (SAST) Data Flow → Visual trace from source to sink showing every step HTTP Evidence → Full request + response with highlighted vulnerability (DAST) Component Info → Package name, installed version, fixed version (SBOM) Severity → CVSS 3.1 score + PhantomYerra exploitability rating Fix Suggestion → AI-generated code fix with before/after diff Reachability → Whether the vulnerable path is actually exercised (SBOM) Related Findings → Cross-links: SAST finding ↔ SBOM vulnerable component DAST runtime finding ↔ SAST source code location Export Formats: SARIF → Standard format for IDE integration (VS Code, IntelliJ) CycloneDX JSON → SBOM in CycloneDX 1.5 format SPDX 2.3 JSON → SBOM in SPDX format for compliance VEX → Vulnerability Exploitability eXchange document CSV → Spreadsheet for Jira / ServiceNow import PDF Report → Professional report with executive summary HTML Report → Self-contained styled report for email delivery
What Claude Tests (SAST / DAST / SBOM)
- SAST: SQL/NoSQL/OS command injection patterns across 15+ languages with taint tracking
- SAST: XSS (reflected, stored, DOM) with framework-aware context analysis
- SAST: Insecure deserialization (Pickle, Java, .NET, YAML, JSON gadgets)
- SAST: Hardcoded secrets, API keys, passwords, private keys in source code
- SAST: Cryptographic misuse (weak algorithms, insufficient key length, insecure random)
- SAST: Path traversal, SSRF, race conditions, unsafe file operations
- DAST: OWASP Top 10 runtime testing with context-aware payload generation
- DAST: Authentication bypass, session management flaws, CORS misconfiguration
- DAST: API-specific testing (REST, GraphQL, gRPC) with OpenAPI spec awareness
- SBOM: Full dependency tree CVE matching (direct + transitive) with reachability analysis
- SBOM: License compliance audit (GPL, AGPL, proprietary license detection)
- SBOM: VEX document generation with exploitability assessment per component
Options Reference
| Option | Values | Default | Description |
|---|---|---|---|
| Analysis Type | SAST, DAST, SBOM, Combined | Combined | Which analysis pipelines to run |
| Source Input | Git URL, Local Path, Archive Upload | -- | How source code is provided for SAST/SBOM |
| Branch / Tag | Any Git ref | main | Which branch to analyze (Git repos only) |
| SAST Rulesets | OWASP, CWE-Top-25, Security-Audit, Secrets, Custom | OWASP + CWE-Top-25 | Which rule packs to apply |
| SAST Severity Filter | Critical, High, Medium, Low, Info | All enabled | Minimum severity to report |
| AI Triage | On / Off | On | Claude reviews findings and removes false positives |
| DAST Target URL | Any URL | -- | Target application for dynamic testing |
| DAST Auth Type | None, Bearer, API Key, Cookie, Form, Multi-Step | None | Authentication method for crawling behind login |
| DAST Crawl Depth | 1–10 | 5 | How deep to spider the application |
| DAST Rate Limit | 1–100 req/sec | 10 | Maximum requests per second (reduce for production) |
| DAST Excluded Paths | Comma-separated paths | -- | URLs to skip during crawling and testing |
| SBOM Format | CycloneDX, SPDX 2.3, Both | CycloneDX | Output format for bill of materials |
| SBOM Source | Lock files, Container image, Binary | Lock files | What to analyze for component inventory |
| License Policy | Permissive only, Allow weak copyleft, Allow all, Custom | Allow all | Which license types trigger compliance alerts |
| VEX Generation | On / Off | On | Generate Vulnerability Exploitability eXchange document |
| IaC Frameworks | Terraform, CloudFormation, K8s, Helm, Dockerfile, All | Auto-detect | Which IaC frameworks to scan |
| Report Format | PDF, HTML, SARIF, CSV, JSON | PDF + SARIF | Output report format(s) |
Common Scenarios
A development team wants to scan their application before deploying to production. Run Combined analysis: SAST on the Git branch being released, DAST against the staging environment, SBOM from lock files. Set severity filter to Critical + High only for the go/no-go decision. Export SARIF for developer IDE integration and PDF for the release approval board.
Legal team needs a license inventory for a product using 300+ open-source components. Run SBOM only with all lock files. Set license policy to Permissive only to flag any GPL/AGPL/copyleft components. Export CycloneDX JSON for the compliance database and PDF license report for legal review. Generate VEX document to track which CVEs are exploitable in your specific usage.
A COBOL/Java application with 20 years of history needs a security review before modernization. Run SAST with all rulesets enabled, including custom COBOL patterns. Enable AI Triage to filter the high false-positive rate common in legacy code. Run SBOM to identify outdated Java dependencies with known CVEs. Expect 100+ findings; use severity filtering and AI triage to prioritize the top 20.
Embed SAST and SBOM checks into your build pipeline. Use Automated AI mode via the PhantomYerra CLI:
phantomyerra sast --input ./src --format sarif --output results.sarif. Fail the build if any Critical findings are detected. Upload SBOM to your component registry on every release. Configure DAST to run nightly against the staging URL with authentication credentials from your secrets manager.
Common Issues
Verify the correct ruleset is selected for your language: use the Auto-detect option for automatic language and ruleset selection. Check that the source directory path points to actual source files (not compiled output, not node_modules). Enable verbose mode in Settings → SAST → Verbose Logging to see which rules are being applied. If scanning a monorepo, ensure the subdirectory filter includes the right paths. Try running with the security-audit ruleset which has broader coverage than OWASP alone.
The SBOM generator needs package manifest or lock files to enumerate dependencies: requirements.txt, package-lock.json, yarn.lock, go.sum, pom.xml, Cargo.lock, Gemfile.lock, composer.lock, etc. If you only have source code without lock files, run pip freeze, npm install, or the equivalent package manager command first to generate them. For binary-only analysis, use the Binary Inspection input mode which extracts embedded dependency information from compiled executables.
Use severity and confidence filters: select High Severity + High Confidence Only in the SAST configuration panel to reduce noise. Enable AI Triage (on by default in Automated and Semi-Automated modes) which analyzes code context, control flow, and sanitization functions to identify false positives. Create a .semgrepignore file to exclude test directories, generated code, and vendor libraries. For persistent false positives, add inline suppression comments: # nosemgrep: rule-id (document the reason for each suppression).
Modern SPAs (React, Angular, Vue) render content with JavaScript that traditional HTTP crawlers cannot see. Enable Browser-based Crawling in the DAST configuration which uses a headless browser to render pages before crawling. Alternatively, provide an OpenAPI/Swagger specification file which gives the crawler a complete endpoint map without needing to discover them through the UI. For GraphQL APIs, provide the schema introspection endpoint.
Reduce crawl depth from the default 5 to 2 or 3 for initial scans. Lower the rate limit if the target is responding slowly (set to 2–5 req/sec for production targets). Add excluded paths for large static content directories (/assets/, /images/, /docs/). Limit the vulnerability categories to the most critical (injection + XSS + auth) instead of testing all categories. For very large applications, split the scan into multiple runs targeting different URL path prefixes.
Components with "Unknown" license status require manual investigation. Check the component's source repository (GitHub, GitLab, npm registry) for a LICENSE file. Some packages declare their license only in package.json "license" field or in source file headers. If no license is found, treat the component as potentially proprietary and consult your legal team. You can manually override the license classification in PhantomYerra: SBOM → Components → [component] → Edit License.
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 →