Veracode
Cloud-based application security platform combining SAST, DAST, SCA, and penetration testing. Enterprise-grade with detailed reporting.
Overview
Veracode is a cloud-based application security platform that combines static analysis (SAST), dynamic analysis (DAST), software composition analysis (SCA), and manual penetration testing in a single platform. Founded in 2006 and now part of Thoma Bravo, Veracode is one of the largest application security vendors, serving Fortune 500 companies and government agencies worldwide.
Veracode is particularly strong for enterprises that need a unified security platform with governance, reporting, and compliance features. It is often the mandated tool in regulated industries.
What it's used for
Veracode is the right choice when:
- Unified security platform needed: One vendor for SAST, DAST, SCA, and pen testing.
- Enterprise governance required: Policy management, audit trails, and compliance reporting.
- Regulated industry: Banking, healthcare, and government often mandate Veracode or similar.
- Third-party risk management: Assess the security of vendor-supplied applications.
Pros & Cons
Pros
- Comprehensive coverage: SAST, DAST, SCA, pen testing, container
- Strong compliance and governance features
- Detailed reporting for executive and audit audiences
- Professional services for remediation support
- Mature platform with 15+ years of development
Cons
- Very expensive — enterprise pricing only
- Scan times can be slow compared to newer tools
- Less developer-friendly than Snyk or SonarQube
- Configuration and tuning require expertise
- Can generate false positives — requires manual review
Platforms & Integrations
Veracode is a cloud-based SaaS platform. It supports all major languages and integrates with Jenkins, GitHub, GitLab, Azure DevOps, and more.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Enterprise | Custom | All modules, professional services, dedicated support |
NZ Context
Veracode is used by NZ's largest enterprises — primarily major banks and government agencies where strict security governance and audit trails are non-negotiable. NZ financial services organisations operating under PCI-DSS and RBNZ oversight are the most likely buyers; several large NZ insurers and Crown entities have also adopted it as part of broader security uplift programmes. For NZ professionals, Veracode experience is valuable but niche — job opportunities are concentrated in large enterprises and specialist security consultancies with the budget to sustain enterprise licensing.
Alternatives
When to choose Veracode
A quick decision guide for NZ teams evaluating application security testing options.
| Choose Veracode when… | Choose something else when… | Combine with… |
|---|---|---|
| Your organisation is in a regulated sector — banking, insurance, government — and audit trails are mandatory. | You are a startup or SME. Veracode's per-application pricing and onboarding overhead will consume budget that could fund three engineers. | Snyk in the IDE so developers get fast feedback on dependencies without waiting for a Veracode scan cycle. |
| You need to assess third-party or vendor-supplied binaries where you have no access to source code. | Developer experience and CI gate speed matter most. Veracode SAST upload-and-scan cycles can take 20–60 minutes; Semgrep or SonarQube runs in seconds in a pipeline. | OWASP ZAP or Burp Suite Pro for exploratory DAST during sprints — Veracode DAST is thorough but not designed for ad-hoc testing. |
| Procurement requires a single vendor to cover SAST, DAST, SCA, and pen testing under one contract and one dashboard for risk reporting. | Your team is shifting left and wants security built into pull-request reviews. Checkmarx KICS or Semgrep integrate more naturally at that stage. | Jira and ServiceNow for defect lifecycle — Veracode's integrations are solid here and let security findings flow into existing team boards without manual triage. |
| Your security team needs executive-ready compliance reports (PCI-DSS, SOC 2, ISO 27001) with minimal manual formatting. | Your stack is heavily open-source. Black Duck (Synopsys) has deeper SCA for OSS licence risk; Veracode SCA is strong but narrower in that specialisation. | Wiz or Prisma Cloud for cloud posture management — Veracode secures the application layer; a separate CSPM tool covers the infrastructure beneath it. |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
If…
I were the head of application security at Harbour Bank and needed to consolidate five different point-tools into a single compliance-reportable platform before an upcoming PCI-DSS audit.
I would…
Run a 90-day pilot on two high-risk applications using Veracode's eLearning and Professional Services onboarding. I would not try to scan the entire portfolio on day one. The false-positive rate in the first scan is always high — use that first cycle to tune policies and train developers to triage findings, not to report numbers upward. Ship the Jira integration early so developers see findings in their own boards rather than a security tool they never open.
If…
I were a senior QA engineer at TechServNZ supporting a government agency client who had just been handed a Veracode licence as part of a Crown security uplift programme.
I would…
Prioritise the SAST pipeline scan via the Veracode CLI in GitLab CI and ignore the web UI for day-to-day work. Most teams abandon Veracode because they treat it as a once-a-release gate instead of a pull-request signal. I would also immediately add Snyk alongside it in the IDE — Veracode scan latency makes it unsuitable as a developer's first line of feedback. Use Veracode for the final gate and compliance artefacts; use Snyk for the fast inner loop. This dual-tool approach will feel redundant but it is the only way to get both developer adoption and audit coverage.
If…
I were a test manager at HealthNZ six months into a Veracode rollout and the development teams were complaining that security findings were slowing releases without producing real fixes.
I would…
Stop scanning everything and switch to risk-based scoping. In Veracode Policy, tighten the severity thresholds so only Very High and High findings block a pipeline — Medium and below go to the backlog. Then run a triage sprint where the security engineer and a developer from each team sit together for one hour and close or mitigate the High findings on their application. Teams need to feel progress before they trust the tool. If triage sprints do not move the needle within a quarter, that is a signal to evaluate whether Checkmarx or SonarQube with a dedicated security plugin would produce lower friction for the same compliance outcome.
The bottom line: Veracode earns its price when it becomes the single source of truth for application risk across an enterprise — not when it is bolted onto a team's pipeline as an afterthought. If you cannot answer "who reviews these findings and by when?" before you buy the licence, the tool will sit unused within six months.
Interview questions
Questions you are likely to get if you list Veracode on your CV — with what interviewers are really testing for.
What is the difference between SAST and DAST, and how does Veracode implement both?
What they’re really testing: Whether you understand the fundamental security testing concepts or just know how to click buttons in a UI.
Strong answer covers: SAST analyses source/bytecode without running the app (upload-and-scan in Veracode); DAST probes a running application from outside; in Veracode, SAST is the core module while DAST (Veracode Dynamic Analysis) requires a deployed URL target. Mention that Veracode SAST accepts compiled binaries, so you don’t need source code access—a key advantage when assessing third-party software common in NZ government procurement.
When would you choose Veracode over Snyk or SonarQube for a development team?
What they’re really testing: Whether you understand tool trade-offs and can make a cost-justified recommendation rather than defaulting to the most expensive option.
Strong answer covers: Veracode wins when compliance reporting (PCI-DSS, ISO 27001, SOC 2) is mandatory and audit artefacts need to come from a single vendor; Snyk wins for developer-inner-loop speed and open-source dependency management; SonarQube wins for continuous code quality gates in CI. A strong answer acknowledges the dual-tool pattern: Snyk in the IDE for fast feedback, Veracode as the final compliance gate—a setup used in NZ banking environments.
You’re joining TeleNZ as a senior QA engineer and the team has a Veracode licence but developers say it slows releases and nobody trusts the findings. How would you turn that around?
What they’re really testing: Whether you can solve people and process problems, not just technical ones—Veracode rollouts fail more often due to culture than configuration.
Strong answer covers: Start with risk-based scoping—tighten policy so only Very High and High findings block the pipeline, Medium and below go to backlog. Run joint triage sessions (security engineer + developer per team) to close High findings and build trust. Add Snyk in the IDE so developers have fast inner-loop feedback and don’t blame Veracode for all friction. Set a 90-day metric: reduction in Mean Time to Remediate Highs as the success signal, not scan count.
Your Veracode pipeline scan passes locally but the same scan fails in GitLab CI with a policy violation you can’t reproduce. How do you debug it?
What they’re really testing: Whether you can methodically investigate environment-specific scan differences rather than blaming the tool or the pipeline.
Strong answer covers: Check that the artifact being uploaded in CI is the same build output (compiled bytecode or packaged binary) as the local scan—a different build profile can expose different code paths. Verify the Veracode API credentials and sandbox vs. policy scan context (sandbox scans use different policy rules). Pull the CI scan results XML via the Veracode Results API and diff the finding list against the local run to isolate which specific CWE is new. Check whether a third-party dependency was resolved differently in the CI build environment.
How would you structure a Veracode programme for an organisation that has 40+ applications across multiple development teams with different release cadences?
What they’re really testing: Whether you can think at an enterprise programme level, not just per-team tool configuration.
Strong answer covers: Tier applications by risk (customer-facing with PII vs. internal tooling) and apply different Veracode policies per tier. Use Veracode Pipeline Scan for fast CI gates and reserve Policy Scan for release gates—this respects different cadences without blocking fast-moving teams. Centralise policy management in Veracode so the security team owns the rules, not individual teams. Use the Veracode Analytics dashboards to give executive leadership a portfolio-level risk view without requiring them to log into 40 separate applications—critical for board reporting in NZ regulated sectors like banking or health.