Veracode offers several scan types, each suited to a different point in your development workflow. Understanding which to use — and when — is key to building an effective application security program.
Scan Type Overview
| Scan Type | What It Scans | Best For | Policy Tracked? |
|---|---|---|---|
| Static Analysis (Upload & Scan) | Compiled application binaries | Comprehensive, official policy assessment | Yes |
| Pipeline Scan | Compiled binaries (fast, lightweight) | Developer feedback in CI/CD | No (can use policies; no grace periods) |
| Software Composition Analysis (SCA) | Open-source dependencies | Vulnerability and license risk in third-party libraries | Yes (upload scan); No (agent scan) |
| Dynamic Analysis (DAST) | Running web applications | Runtime vulnerabilities in deployed applications | Yes |
Static Analysis (Upload and Scan)
Upload and Scan is Veracode's comprehensive static analysis. You upload a packaged build artifact, and Veracode analyzes it for security vulnerabilities, measuring the results against your assigned security policy.
- Best for: official policy assessments, release gate decisions, compliance reporting.
- Results appear in the Veracode Platform and count toward policy compliance.
- Supports both SAST and SCA (upload scan) simultaneously.
- Docs: Veracode Upload and Scan
- Docs: Packaging Requirements
Pipeline Scan
Pipeline Scan is a fast, lightweight static analysis designed to fit in CI/CD pipelines. It runs quickly (up to 60 minutes maximum), returns results as a JSON file, and can fail your build if new findings above a configured severity are introduced.
- Best for: developer-facing security feedback on every pull request or commit.
- Results are not policy-tracked by default (no grace period support).
- Rate limit: 6 scans per 60 seconds per account. File size limit: 200 MB.
- Use a baseline file to avoid failing builds on pre-existing findings.
- Docs: Pipeline Scan
Software Composition Analysis (SCA)
SCA scans your open-source dependencies for known vulnerabilities and license risks. There are two SCA workflows:
SCA Upload Scan — Runs automatically alongside Upload and Scan. Results appear in the Platform and are policy-tracked. No additional setup required.
SCA Agent-Based Scan — Runs via the Veracode CLI or IDE plugins, scanning your source dependencies without compilation. Faster and more flexible; useful in pipelines and for languages where compilation isn't needed.
- Docs: SCA Agent-Based Scan
- Docs: SCA Upload Scan
Dynamic Analysis (DAST)
Dynamic Analysis tests your deployed web application by simulating real-world attack techniques against a running instance. It finds vulnerabilities that static analysis cannot, such as authentication flaws and injection vulnerabilities in deployed configurations.
- Best for: web applications you can deploy to a test or staging environment.
- Requires a deployed and accessible application to scan.
- Results are policy-tracked and appear in the Veracode Platform.
- Docs: Dynamic Analysis
- Docs: DAST Essentials
Recommended Scan Strategy by Persona
For Developers: Start with IDE plugin scans for instant feedback, then add Pipeline Scan to your pull request workflow.
For DevOps Engineers: Pipeline Scan on every build for developer feedback; Upload and Scan nightly for policy-tracked results.
For Security Leads: Upload and Scan on all business-critical applications for policy tracking, plus DAST for externally-facing web applications. Approve/reject mitigations (Mitigation Approver role required) and monitor policy compliance in Analytics.
How Each Scan Type Sees Your Code
Understanding what each scan type can and cannot find — and why — helps you set realistic expectations and make sense of your results.
Static Analysis (Upload and Scan / Pipeline Scan)
Veracode's static analysis engine analyzes your compiled binary, not your source code. It has the same view of your application as a compiler: it can see every code path, every function call, and every data flow — but it knows nothing about your runtime environment, configuration files, or live data. This means it will find deeply embedded coding flaws that only appear under certain conditions, but it will not find vulnerabilities that depend on how your application is deployed or configured. If a flaw only manifests at runtime (e.g., an insecure header set by your web server, not your code), static analysis will not catch it — that's what DAST is for.
Pipeline Scan
Pipeline Scan uses the same underlying static analysis engine as Upload and Scan but is optimized for speed and CI/CD integration. Because it is designed to run in under 60 minutes, it may not achieve the same depth of coverage as a full Upload and Scan on large applications. Think of Pipeline Scan as a fast first pass that catches new issues as they are introduced — and Upload and Scan as the thorough baseline assessment.
Software Composition Analysis (SCA)
SCA does not analyze your application code at all. It reads your dependency manifests (package.json, pom.xml, requirements.txt, etc.) to identify which open-source libraries you are using, then checks those libraries against vulnerability databases. It cannot find flaws you introduced yourself — it only sees vulnerabilities in third-party code you have included. If you are writing custom code that wraps a vulnerable library call in a safe way, SCA will still flag the library as vulnerable, because it cannot evaluate how you are using it.
Dynamic Analysis (DAST)
DAST has no knowledge of your code whatsoever. It probes your running application from the outside, simulating how a real attacker would interact with it — submitting inputs, following redirects, testing authentication flows, and observing responses. It can find vulnerabilities that only exist at runtime (misconfigured headers, exposed error messages, injection flaws in live endpoints) but it cannot find anything that is not reachable via an HTTP request to your deployed application. It requires a working, deployed instance to scan.
Reference Architectures
These two models show how Veracode scan types fit into complete application security programs. Use them as a starting point — adapt the model that most closely matches your team's profile.
Model A — Developer-First, Continuous Feedback
Best for: Teams with active developer participation in security, modern SCM-based workflows, and a focus on catching issues early.
| SDLC Stage | Veracode Activity |
|---|---|
| Code (local) | IDE plugin scan — SAST + SCA + Veracode Fix |
| Pull Request | Pipeline Scan via CI — fail on new High/Very High findings |
| Merge to main | Upload and Scan (nightly) — policy-tracked SAST + SCA results |
| Staging | DAST — weekly scan of deployed application |
| Production | Review Analytics dashboards — track policy trend over time |
Key outcomes: Developers get findings before code review; policy results stay clean; compliance reporting is automated.
Model B — Security-Led, Compliance-Focused
Best for: Teams where the security function owns scanning, applications are deployed to a stable environment, and audit reporting is a priority.
| SDLC Stage | Veracode Activity |
|---|---|
| Release candidate build | Upload and Scan — policy-tracked SAST + SCA |
| Staging environment | DAST — scan before each release to production |
| Annually or per compliance cycle | Manual Penetration Testing (MPT) — human-led assessment for highest-criticality applications |
| Ongoing | Analytics — policy compliance tracking, remediation trend reporting |
Key outcomes: Policy compliance is gated at release; MPT provides depth for critical applications; compliance reports are available on demand.
Sandboxes
Sandboxes let you run development scans of an application without affecting its policy status. Use sandboxes for work-in-progress branches, pre-release testing, or security research on your own codebase.
- Docs: Veracode Sandboxes
Useful Resources
Learning Paths
Go deeper with these step-by-step learning paths on Veracode Docs:
← Back to the Getting Started Guide | ← Back to the Onboarding Hub
.png){kind=logo}
