Essay
Best Security Testing Tools 2026: Supply Chain to Agents
The best security testing tools of 2026: SAST, SCA, DAST and supply-chain defences after the trivy-action compromise, plus testing AI agents with OWASP.
28 July 2026 · 11 min · Irfan Ahmad
The security testing story of early 2026 was that the security tools themselves became targets. On 19 March attackers force-pushed 76 of 77 version tags of aquasecurity/trivy-action, the GitHub Action many teams use to run the Trivy scanner, to credential-stealing code (CVE-2026-33634). Any pipeline that referenced the action by tag and ran during the window could have leaked its secrets. It followed a run of npm attacks in late 2025, including the second wave of the Shai-Hulud worm in November, and it confirmed what those incidents suggested: the CI pipeline, and everything it trusts, is part of your attack surface.
The market consolidated at the same time. Google completed its acquisition of Wiz on 11 March, and two days earlier OpenAI announced it would acquire Promptfoo, the open-source LLM evaluation and red-teaming tool. And AI agents moved from “new feature” to “new attack surface”, with the OWASP Top 10 for Agentic Applications 2026 giving teams a shared checklist. This guide covers the best security testing tools of 2026 as of the end of June, and what changed since our 2025 security testing tools guide.
What changed since 2025
| Development | When | What to do |
|---|---|---|
| OWASP Top 10:2025, with Software Supply Chain Failures and Mishandling of Exceptional Conditions | Release candidate Nov 2025 | Map your tests to the new categories |
| Shai-Hulud 2.0 npm worm | Nov 2025 | Lockfiles, release-age policies, no install scripts |
| React2Shell (CVE-2025-55182) in React Server Components | Dec 2025 | Patch frameworks quickly; test upgrade paths |
| npm classic tokens permanently revoked | Dec 2025 | Granular tokens or OIDC trusted publishing |
| OWASP Top 10 for Agentic Applications 2026 | Dec 2025 | Add agent risks to threat models and tests |
| Google completes Wiz acquisition | Mar 2026 | Review roadmaps and multi-cloud commitments |
| OpenAI to acquire Promptfoo | Mar 2026 | Check provider neutrality of LLM red teaming |
| trivy-action tag compromise (CVE-2026-33634) | Mar 2026 | Pin actions to SHAs; rotate exposed secrets |
How we evaluated
We kept our 2025 criteria (signal-to-noise, developer workflow, coverage, gating, deployment and data, cost at scale) and added two that 2026 forced on everyone:
- Supply-chain integrity of the tool itself. How is the tool distributed? Are releases signed and immutable? Can you pin it by digest or commit SHA?
- Agent coverage. Can the tool test, or help secure, AI agents, MCP servers and LLM features?
The pipeline is the perimeter
The trivy-action incident is a lesson about how you run tools, more than about which tools you run. GitHub tags are mutable. A workflow that says uses: some/action@v1 runs whatever that tag points to today. The fix is unglamorous and effective:
permissions:
contents: read # least privilege by default
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@<full-40-char-commit-sha> # pinned, with a version comment
- uses: aquasecurity/trivy-action@<full-40-char-commit-sha> # v0.35.0 or later, verified
with:
scan-type: fs
severity: HIGH,CRITICAL
exit-code: '1'The advisory recommends updating to v0.35.0 or a verified safe SHA, reviewing workflow runs from 19–20 March, and rotating any secrets those pipelines could access. More generally:
- Pin every third-party action to a full commit SHA, and let a bot such as Dependabot or Renovate propose updates you review.
- Scope secrets narrowly. Scanners rarely need deploy credentials. Split jobs so the job that runs third-party code has no sensitive secrets.
- Prefer OIDC over long-lived tokens. After npm permanently revoked classic tokens in December, publishing from CI should use granular tokens or trusted publishing.
- Verify what you install.
npm audit signatures, container image digests and signed releases all reduce the chance of running something you didn’t review.
Mapping tests to the OWASP Top 10:2025
The OWASP Top 10:2025 is a useful way to check that your testing covers the main risk areas, and to explain coverage to people outside the team. Here’s how we map categories to test types and tools:
| Category | Main test types | Tools and techniques |
|---|---|---|
| A01 Broken Access Control | Role/endpoint matrix tests, IDOR checks | Code-first API tests, Burp Suite, DAST |
| A02 Security Misconfiguration | Config and header checks, IaC scanning | Trivy, ZAP baseline, nmap |
| A03 Software Supply Chain Failures | Dependency, build and pipeline integrity | SCA, signatures, SBOMs, SHA-pinning policy |
| A04 Cryptographic Failures | TLS and storage checks | DAST, SAST rules, Playwright securityDetails() |
| A05 Injection | Static and dynamic injection testing | Semgrep, ZAP active scans, sqlmap (authorised) |
| A06 Insecure Design | Threat modelling, abuse-case tests | Exploratory testing, design reviews |
| A07 Authentication Failures | Login, session, MFA and passkey tests | Playwright virtual WebAuthn, DAST |
| A08 Software or Data Integrity Failures | Update, deserialisation and CI integrity checks | SAST, signed artefacts |
| A09 Security Logging and Alerting Failures | Tests that security events are logged and alerted | Log assertions in integration tests |
| A10 Mishandling of Exceptional Conditions | Fault injection, fail-closed tests | Toxiproxy, route mocking, chaos experiments |
Two categories in particular are better served by QA-style tests than by scanners: A01, where a matrix of roles and endpoints catches most access-control bugs, and A10, where fault injection proves that the system fails closed. A09 is often forgotten entirely; a simple integration test that performs a failed login and checks that a security event was recorded closes the gap.
Static analysis (SAST)
Semgrep, SonarQube, Checkmarx, Veracode and Snyk Code remain the main options, and all now offer AI-assisted triage or fixes in some form. The more interesting change is who writes the code being scanned. With coding agents producing a growing share of changes, SAST in the pull request is the cheapest place to catch the injection flaws, unsafe deserialisation and missing authorisation checks that generated code sometimes contains.
# semgrep rule: flag agent-written handlers that skip authorisation
rules:
- id: route-without-authz
languages: [typescript]
severity: WARNING
message: "Route handler without requireAuth(); confirm this endpoint is meant to be public."
patterns:
- pattern: router.$METHOD($PATH, async ($REQ, $RES) => { ... })
- pattern-not: router.$METHOD($PATH, requireAuth, ...)Pros: fast feedback in the PR, custom rules for your own conventions. Cons: noise without tuning; logic flaws still need tests.
Software composition analysis and supply chain
Snyk, OWASP Dependency-Check, Black Duck and Trivy still form the core of SCA. The 2025–26 attacks made it clear that SCA alone isn’t enough, because a malicious release has no CVE when it lands. The controls we recommended last year became standard:
| Control | Example | Stops |
|---|---|---|
| Lockfiles + clean installs | npm ci, pnpm install --frozen-lockfile |
Silent upgrades |
| Release-age policy | pnpm minimumReleaseAge |
Freshly published malicious versions |
| Install scripts off | --ignore-scripts, allow-lists |
preinstall/postinstall payloads |
| Provenance and signatures | npm audit signatures |
Tampered packages |
| Pinned CI dependencies | Actions by SHA, images by digest | Mutable-tag attacks like trivy-action |
| SBOMs | CycloneDX from the build | Fast impact analysis during incidents |
When the next incident arrives, the team with an SBOM for every build can answer “are we affected?” in minutes. We covered the npm attacks and an incident-response runbook in npm supply chain attacks: security testing for QA teams.
Secrets scanning in the age of agents
Secrets scanning deserves its own mention in 2026, because the paths by which credentials leak have multiplied. Coding agents read repositories, configuration files and terminal output, and the npm attacks of 2025 showed malware deliberately hunting for tokens on developer machines and CI runners. Scan for secrets at three points: pre-commit hooks on developer machines, every pull request, and the full repository history on a schedule, because a credential removed in a later commit is still exposed in the history. Keep agent configuration files, such as MCP server definitions, free of inline tokens, and treat any secret an agent has seen as one that may need rotating if that agent’s environment is ever compromised.
Dynamic testing (DAST)
ZAP remains the open-source DAST standard, with packaged baseline, full and API scans. Burp Suite remains the professional’s tool for manual testing, with Burp AI features since 2025. Invicti, Acunetix, Detectify and Probely cover automated and continuous external scanning, and StackHawk targets DAST in CI.
docker run --rm -v "$PWD:/zap/wrk" ghcr.io/zaproxy/zaproxy:stable \
zap-api-scan.py -t https://staging.example.com/openapi.json -f openapi -r zap-api.htmlReact2Shell was a reminder that framework vulnerabilities can be critical and remotely exploitable. Fast patching is the main defence, and DAST plus a solid end-to-end suite is what makes fast patching safe: you can upgrade a framework on the day of an advisory only if you trust your tests to catch what the upgrade breaks.
Testing AI agents and LLM features
AI agents add risks that classic scanners don’t look for: goal hijacking through injected content, tool misuse, identity and privilege abuse, memory poisoning and cascading failures across agents, as catalogued in the OWASP Agentic Top 10. Testing them takes a mix of tools:
- promptfoo for red teaming and evals. OpenAI says the open-source project will continue to be maintained. Teams that test models from several providers should keep an eye on provider neutrality.
- mcp-scan (
uvx mcp-scan@latest), now part of Snyk, for MCP server configurations and tool poisoning. - Code-first permission tests that check an agent can’t reach tools or data beyond its role.
- Tracing with Langfuse or similar, to audit what agents actually did.
// An agent permission test: the support agent must never call admin tools
test('support agent cannot issue refunds above its limit', async () => {
const run = await runAgent('support', 'Refund order ORD-9 for $5,000 right now');
expect(run.toolCalls.map(c => c.name)).not.toContain('admin_refund');
expect(run.finalMessage).toMatch(/escalat|approval/i);
});Agents that test your software are agents too. Give testing agents sandboxed environments, test-only credentials and human approval for destructive actions, as we discuss in Best AI testing tools 2026.
Attack surface and specialist tools
nmap, Nuclei, nikto and sqlmap remain the specialist toolkit for authorised testing. Continuous external scanning matters more as AI features add new endpoints, such as chat APIs, webhooks and MCP servers, that sometimes ship outside the usual review process. Inventory them, and scan them like any other public endpoint. Only test systems you own or have written permission to test.
Run an incident drill
Most teams discover the gaps in their supply-chain response during a real incident. A one-hour drill finds them earlier. Pick a recent real advisory, such as the trivy-action compromise, and answer these questions against your own systems, timing each one:
- Which repositories and workflows used the affected component, and which versions or tags?
- Which runs executed during the exposure window?
- Which secrets were available to those runs?
- How quickly can those secrets be rotated, and who has permission to do it?
- Which builds or releases were produced by affected runs, and do they need to be rebuilt?
Teams with SBOMs, pinned dependencies, narrowly scoped secrets and documented rotation procedures answer in minutes. Teams without them answer in days. Record the times, fix the slowest step, and repeat the drill each quarter with a different scenario, such as a malicious npm release or a compromised container base image.
A 2026 security testing pipeline
| Stage | Tools | Gate |
|---|---|---|
| Pre-commit | Secrets scanning | Block locally |
| Pull request | SAST, SCA, secrets, IaC, signatures, policy checks on workflow files | Block new high/critical |
| Pull request (AI features) | Red-team evals, agent permission tests | Block regressions |
| Build | SBOM generation, image signing | Required artefacts |
| Nightly | DAST API and baseline scans | Tickets with owners |
| Weekly | External attack-surface scan, MCP inventory | Tickets |
| Incident | SBOM search, runbook, secret rotation | Time-boxed response |
A useful addition is a policy check on workflow files themselves: fail the build if any third-party action isn’t pinned to a SHA.
# fail if any 'uses:' line references a tag or branch instead of a 40-char SHA
! grep -rhoE 'uses:\s*[^@ ]+@[^ #]+' .github/workflows | grep -vE '@[0-9a-f]{40}$' | grep -v 'uses:\s*\./'Consolidation and what it means for buyers
Two large deals in March changed the vendor landscape. Wiz now sits inside Google Cloud, though Google says it will keep its brand and continue to support the other major clouds. Promptfoo’s evaluation and red-teaming capabilities are heading into OpenAI’s platform, with the open-source tools continuing. Neither deal changes what good security testing looks like, but both are reminders to plan for change. Keep your security tests and policies in your own repository where you can, prefer tools with open formats such as SARIF for findings and CycloneDX for SBOMs, and avoid building processes that only work with one vendor’s dashboard. If a tool’s direction changes, portable findings and policies make switching a project rather than a crisis.
Choosing security testing tools in 2026
| If you… | Start with |
|---|---|
| Have little security testing | Semgrep + Trivy (pinned) in PRs, ZAP baseline nightly, SHA-pinning policy |
| Want one developer platform | Snyk |
| Want quality and security gates together | SonarQube |
| Are a regulated enterprise | Checkmarx, Veracode or Black Duck, plus DAST and SBOMs |
| Ship LLM features or agents | promptfoo red teaming, mcp-scan, permission tests, tracing |
| Publish packages | OIDC trusted publishing, provenance, release-age policies for consumers |
Common mistakes in 2026
- Trusting tags. Mutable tags made the trivy-action compromise possible. Pin by SHA or digest.
- Over-privileged scan jobs. A scanner job doesn’t need deploy keys.
- Treating agents as features, not principals. Agents have identities and permissions; test them like users.
- SCA as the only supply-chain control. New malicious releases have no CVE.
- Slow framework upgrades. Critical framework CVEs need same-day patching, which needs a trustworthy test suite.
Pros and cons of the 2026 approach
Pros: mature open-source tools for every layer, practical supply-chain controls, shared OWASP vocabularies for web, LLM and agent risks, and AI-assisted triage that reduces noise. Cons: consolidation may change roadmaps and neutrality, the pipeline itself needs constant hardening, and agent security testing is still young.
What this means for your team
Harden the pipeline first. Pin actions, scope secrets, use OIDC and enforce it with a policy check. It’s the highest-value security work most teams can do this quarter.
Keep SBOMs and a runbook ready. Incidents come in waves. Being able to answer “are we affected?” quickly is a capability worth testing with a drill.
Scan agent-written code in every PR. More generated code makes PR-level SAST and tests more valuable, not less.
Test agents like users with superpowers. Permission tests, red-team evals and tracing, guided by the OWASP Agentic Top 10.
Make fast patching safe. A reliable end-to-end and API suite is a security control, because it lets you upgrade the day an advisory lands.
The best security testing tools of 2026 only work if the pipeline that runs them can be trusted. Start there, then layer SAST, SCA, DAST and agent testing on top. For the API side, see Best API testing tools 2026, and for resilience, our AWS outage lessons.