Best Security Testing Tools 2025: SAST, DAST, SCA & More

Security testing tools had a dramatic 2025, and the drama came from the software supply chain. In August, malicious versions of the Nx build system stole credentials and abused locally installed AI coding CLIs to hunt for secrets. In September, an attacker phished a maintainer and published malicious versions of chalk, debug and other packages with billions of weekly downloads between them. Days later, the self-replicating “Shai-Hulud” worm spread through hundreds of npm packages, prompting a CISA alert. We covered these incidents in detail in npm supply chain attacks: security testing for QA teams.

At the same time, AI arrived in security tools, from Burp Suite’s AI features to AI-assisted triage and fixes in static analysis tools, and AI systems themselves became something to security-test. This guide covers the security testing tools we think engineering and QA teams should know in 2025, up to the end of September, organised by category.

How we evaluated

Security tools are judged on more than detection rates. For each tool we asked:

• Signal-to-noise. How many findings are real and actionable? A tool that produces hundreds of low-value alerts trains people to ignore it.
• Developer workflow. Do findings appear where developers work, in pull requests and IDEs, with clear explanations and fixes?
• Coverage. Which languages, frameworks, package ecosystems and deployment targets does it understand?
• Gating and policy. Can it block merges for new, severe issues while tracking the existing backlog separately?
• Deployment and data. Can it run inside your environment, and what does it send to a vendor?
• Cost at scale. Licensing by developer, application or scan can change the economics dramatically as you grow.

Security testing in the QA workflow

Security is often treated as a separate discipline with separate tools and separate people. In practice, many of the most damaging vulnerabilities are functional bugs in access control and business logic, exactly the area where QA engineers are strongest.

Broken access control has topped the OWASP Top 10 since 2021. Testing it doesn’t require a security scanner. It requires test accounts with different roles, a list of resources and actions, and tests that check each role can do only what it should. A matrix of roles against endpoints, generated from your OpenAPI definition, turns this into a parameterised test suite you can run on every change.

Business-logic abuse covers things like applying a discount code twice, buying a negative quantity, skipping a payment step by calling the confirmation endpoint directly, or changing a price in a client-side request. Scanners rarely find these. Exploratory testers with a security mindset do.

Input handling benefits from property-based and fuzz testing: generate unexpected strings, sizes, encodings and types, and check the application fails safely. Schema-driven API fuzzers make this cheap.

Security regression tests are the most underrated control. Every vulnerability fixed should leave behind a test that proves it stays fixed, written in your normal test framework and run in CI like any other test.

Treat these as part of the regular test plan, not as an annual penetration test. Penetration testers are most valuable when they’re not spending their time finding issues a well-designed test suite would have caught.

The categories

Category	What it tests	When it runs	Example tools
SAST	Your source code for vulnerable patterns	Every commit / PR	Semgrep, SonarQube, Checkmarx, Veracode, Snyk Code
SCA	Third-party dependencies for known vulnerabilities and licences	Every PR, plus continuous monitoring	Snyk, Dependency-Check, Black Duck, Trivy
Secrets scanning	Credentials committed to code	Pre-commit and every PR	Trivy, platform-native scanners
Container / IaC scanning	Images and infrastructure configs	Build and PR	Trivy, Snyk
DAST	The running application from outside	Staging, nightly or per release	ZAP, Burp Suite, Invicti, Acunetix, StackHawk
Attack surface / external scanning	What’s exposed on the internet	Continuous	Detectify, Probely, Nuclei, nmap
Exploitation and specialist tools	Specific vulnerability classes	Targeted testing	sqlmap, nikto, Burp Suite
AI and LLM security	Prompt injection, data leaks, unsafe tool use	PR and pre-release	promptfoo, mcp-scan

No single category is enough. SAST misses configuration and runtime issues. DAST misses code paths it can’t reach. SCA only knows about known vulnerabilities, and, as 2025 showed, it doesn’t catch a malicious package published an hour ago.

Static analysis (SAST)

Semgrep

Semgrep is our default recommendation for teams that want fast, customisable static analysis. Rules look like the code they match, so developers can write their own:

rules:
  - id: no-raw-sql-concat
    languages: [javascript, typescript]
    severity: ERROR
    message: "Possible SQL injection: build queries with parameters, not string concatenation."
    pattern-either:
      - pattern: $DB.query("..." + $X)
      - pattern: $DB.query(`...${$X}...`)

semgrep scan --config p/owasp-top-ten --config ./rules --error

Pros: fast, easy custom rules, good CI integration, a large open rule registry. Cons: the deepest cross-file and cross-function analysis is in the commercial product, and generic rulesets can be noisy until tuned.

SonarQube

SonarQube combines code quality and security analysis, with quality gates that fail builds on new issues. It’s especially popular in organisations that want one dashboard for maintainability, coverage and security across many repositories. Pros: quality gates focused on new code, broad language support, self-hosted or cloud. Cons: security depth varies by edition, and teams often need to tune rules.

Checkmarx and Veracode

Checkmarx and Veracode are enterprise application security platforms that combine SAST with SCA, DAST and governance features. They suit regulated organisations that need policy management, audit reporting and coverage across large portfolios. Checkmarx also took over stewardship support for ZAP in 2024, announcing in September 2024 that the core ZAP team had joined the company while ZAP stays open source.

Snyk

Snyk covers SCA, SAST (Snyk Code), containers and IaC in one developer-oriented platform, with fix pull requests for vulnerable dependencies. In June 2025 Snyk announced it was acquiring Invariant Labs, the team behind the mcp-scan tool for MCP servers, signalling that AI agent security is becoming part of mainstream application security.

Software composition analysis and supply chain

SCA tools compare your dependencies against vulnerability databases. OWASP Dependency-Check is the established open-source option:

dependency-check.sh --project storefront --scan . --format HTML --format JSON --failOnCVSS 7

Black Duck is the enterprise choice for licence compliance and large-scale SCA. Trivy (open source, from Aqua Security) scans file systems, containers and IaC for vulnerabilities, secrets and misconfigurations in a single binary:

trivy fs --scanners vuln,secret,misconfig --severity HIGH,CRITICAL --exit-code 1 .
trivy image --severity HIGH,CRITICAL --exit-code 1 registry.example.com/storefront:${GIT_SHA}

What the 2025 supply-chain attacks changed

Classic SCA answers “does this dependency have a known vulnerability?”. The 2025 attacks were malicious releases, live for hours before being detected. Defending against them takes controls that aren’t scanners:

• Lockfiles and clean installs. Use npm ci (or the equivalent) in CI, so builds use exactly the reviewed versions.
• Release-age policies. pnpm 10.16 added minimumReleaseAge, which refuses versions newer than a set age, so most malicious releases are pulled before you could install them.
• Lifecycle scripts off by default. Many attacks run in postinstall. Disable install scripts where possible and allow-list the packages that need them.
• Provenance and signatures. npm audit signatures verifies registry signatures and provenance attestations.
• Pinned CI actions. Pin third-party GitHub Actions to a full commit SHA, not a tag.
• Least-privilege tokens. Short-lived, narrowly scoped tokens limit what a compromised dependency can steal.

# pnpm-workspace.yaml
minimumReleaseAge: 1440   # minutes: refuse versions published in the last 24 hours

Dynamic testing (DAST)

ZAP

ZAP is the most widely used open-source DAST tool. The baseline scan is a safe, passive starting point for CI:

docker run --rm -v "$PWD:/zap/wrk" ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py -t https://staging.example.com -r zap-report.html -c zap-rules.conf

The full scan and API scan (driven by an OpenAPI definition) go further, with active attacks, and belong in isolated test environments. Pros: free, scriptable, an active community, CI-friendly packaged scans. Cons: authenticated scanning of modern single-page apps takes configuration effort, and active scans need careful scoping.

Burp Suite

Burp Suite is the standard tool for manual web security testing, and Burp Suite Professional is in most penetration testers’ toolkits. In March 2025 PortSwigger introduced Burp AI, AI features inside Burp Suite Professional to help testers explore issues and reduce false positives. Burp Suite DAST (formerly Burp Suite Enterprise Edition) automates scanning at scale. Pros: unmatched for manual testing, extensible, a strong research community. Cons: the professional features are commercial, and getting value requires security skills.

Commercial DAST

Invicti and Acunetix offer automated DAST with proof-based scanning to reduce false positives. Detectify and Probely focus on continuous external scanning with payloads informed by security researchers. StackHawk targets developer-first DAST in CI pipelines. Choose based on how many applications you need to cover, how you authenticate, and whether you need API scanning.

Attack surface and specialist tools

• nmap discovers hosts and open ports. Regular scans of your own ranges catch unexpected services.
• Nuclei runs community-maintained templates for known vulnerabilities and misconfigurations: nuclei -u https://staging.example.com -severity high,critical.
• nikto checks web servers for dangerous files and outdated software.
• sqlmap automates detection and exploitation of SQL injection. Use it only on systems you’re authorised to test.

Use these tools only against systems you own or have written permission to test.

Security testing for AI features and agents

AI features add a new class of vulnerability: prompt injection, sensitive information disclosure, excessive agency and insecure tool use, as described in the OWASP Top 10 for LLM Applications. We covered LLM testing in detail in MCP and the OWASP LLM Top 10.

• promptfoo includes red-teaming features that generate adversarial prompts for jailbreaks, prompt injection and data leakage, and can run them in CI.
• mcp-scan checks MCP server configurations for tool poisoning and similar issues: uvx mcp-scan@latest.
• Agent permissions need testing, not just reviewing: confirm agents can’t call tools, read data or reach networks they shouldn’t.

The Nx incident showed a new risk: malware that uses your own AI coding tools against you. Treat AI CLIs on developer machines and CI runners as privileged software.

A layered security testing pipeline

name: security
on: [pull_request]
permissions:
  contents: read
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
      - run: npm ci --ignore-scripts
      - run: npm audit signatures
      - name: SAST
        run: semgrep scan --config p/owasp-top-ten --error
      - name: SCA, secrets and IaC
        run: trivy fs --scanners vuln,secret,misconfig --severity HIGH,CRITICAL --exit-code 1 .

Add a nightly job that deploys to an isolated environment and runs a ZAP baseline or API scan, and a weekly external scan of your public attack surface.

Stage	Tooling	Blocks merge?
Pre-commit	Secrets scanning	Yes (locally)
Pull request	SAST, SCA, IaC, secrets, signatures	Yes, for new high/critical findings
Nightly	DAST baseline / API scan	Creates tickets
Weekly	External attack-surface scan	Creates tickets
Before release	Targeted manual testing for risky changes	Yes, for critical findings
AI features	Red-team evals, MCP scanning	Yes, for regressions

Rolling out security testing without drowning

The order in which you introduce tools matters as much as the tools you choose. A sequence that works for most teams:

1. Week one: secrets and dependencies. Secrets scanning and SCA have the highest signal and the clearest fixes. Rotate any leaked credentials immediately and upgrade the dependencies with known exploited vulnerabilities.
2. Weeks two to four: SAST on new code. Turn on a focused ruleset, such as the OWASP Top 10 rules, and gate only on findings introduced in the pull request. Let developers flag false positives and tune the rules weekly.
3. Month two: DAST baseline. Run a passive scan nightly against staging and review the results together. Add authentication once the baseline is stable.
4. Month three: supply-chain hardening and AI features. Pin actions, enable release-age policies and add red-team evals for any LLM-backed features.
5. Ongoing: measure. Track mean time to fix by severity, the number of new findings per release and the share of findings that turn out to be false positives. These numbers tell you whether the program is working better than any count of scans.

Each step should be owned by a named person, with an agreed response time for each severity. A finding without an owner is a finding nobody fixes.

Choosing your security testing tools

If you…	Start with
Have no security testing yet	Semgrep + Trivy in CI, ZAP baseline nightly
Want one developer platform	Snyk
Want code quality and security in one gate	SonarQube
Are a regulated enterprise	Checkmarx, Veracode or Black Duck, plus DAST
Need manual web testing	Burp Suite Professional
Need continuous external scanning	Detectify, Probely or Nuclei
Ship LLM features	promptfoo red teaming, mcp-scan

Pros and cons of open-source-first security testing

Pros: low cost, transparent rules, easy CI integration, and no data leaving your environment. Cons: you own tuning, triage and reporting; deeper analysis and governance features are usually commercial; and integrating many tools takes effort.

Common mistakes

1. Turning on everything at once. Thousands of findings on day one get ignored. Gate on new high and critical issues first, then pay down the backlog.
2. Treating scanner output as the truth. Triage matters: false positives erode trust, and false negatives are invisible.
3. Scanning only the main branch. Findings are cheapest in the pull request that introduced them.
4. Unauthenticated DAST only. Most of an application lives behind the login. Configure authenticated scans.
5. Ignoring the pipeline itself. CI runners, actions and tokens are part of the attack surface, as 2025 showed.

What this means for your team

QA has a role in security testing. QA engineers already understand flows, test data and environments. That’s exactly what authenticated DAST, abuse-case tests and permission tests need. Security teams set policy; QA can help make it testable.

Layer your tools. SAST, SCA, secrets and IaC scanning in every PR; DAST nightly; external scanning continuously; manual testing for risky changes.

Harden the supply chain. Lockfiles, npm ci, release-age policies, disabled install scripts, signature checks and SHA-pinned actions are cheap and effective.

Gate on new findings. Block merges for new high and critical issues, and track the backlog separately.

Test your AI features and agents. Prompt injection and excessive agency are real vulnerabilities. Add red-team evals to CI.

Write security abuse cases as tests. “A user can’t see another user’s order” is a functional test that’s also a security test. Write it with your normal test tools.

test('users cannot read other users\' orders', async ({ request }) => {
  const res = await request.get('/api/orders/ord-belonging-to-bob', {
    headers: { Authorization: `Bearer ${process.env.ALICE_TOKEN}` },
  });
  expect([403, 404]).toContain(res.status());
});

The best security testing tools of 2025 work as a system: fast checks on every change, deeper scans on a schedule, and humans focused on the risky parts. For the API side of the same story, see Best API testing tools 2025.

Further reading on CheckOps

• npm supply chain attacks: security testing for QA teams
• MCP and the OWASP LLM Top 10
• LLM testing and evals in the vibe-coding era