Tools are the easy part
Every product security programme runs on tooling, but the tools themselves are rarely what separates good programmes from poor ones. Most categories have several capable options, and teams that buy every scanner often end up with thousands of unread findings. The skill is in choosing a small set of tools that fit how your engineers work, tuning them so their output is trusted, and routing findings to the people who can fix them.
This guide explains each major category: what it finds, where it falls short, and common examples. It finishes with data on which tools employers actually ask for in product security job listings. For the wider context of how tooling fits into the discipline, see what product security is.
The main categories at a glance
| Category | When it runs | What it finds | Main limitation |
|---|---|---|---|
| SAST | On source code, before it runs | Insecure code patterns and data flows | False positives; misses logic and design flaws |
| SCA | On dependency manifests and builds | Known-vulnerable open-source packages | Flags vulnerabilities that may not be reachable |
| DAST | Against a running application | Exploitable behaviour from the outside | Limited coverage; slow; hard to authenticate |
| IAST / RASP | Inside the running application | Vulnerabilities observed at runtime | Needs instrumentation; language-specific |
| Secrets detection | On code, history and logs | Committed credentials and keys | Only as good as its detectors and history coverage |
| IaC and cloud security | On templates and live cloud accounts | Misconfigurations and risky exposure | Context needed to prioritise |
| Container scanning | On images and registries | Vulnerable OS packages and base images | Noise from unused packages |
| Threat modelling | At design time | Design flaws and missing controls | Depends entirely on the people involved |
| Fuzzing | On parsers, libraries and APIs | Crashes and memory-safety bugs | Needs harnesses and compute time |
| Bug bounty | Continuously, by external researchers | Real-world exploitable issues | Costs and triage load; unpredictable coverage |
Static application security testing (SAST)
SAST tools analyse source code without running it, looking for patterns and data flows that lead to vulnerabilities: user input reaching a SQL query, a file path or a shell command, for example. Because they run on code, they fit naturally into pull requests and give developers feedback before anything ships.
The trade-off is noise. SAST tools cannot fully understand runtime context, so they report issues that are not exploitable, and they miss problems that are not visible in code patterns, such as broken authorisation logic or design flaws. The most effective teams start with a small set of high-confidence rules, add custom rules for their own frameworks and past incidents, and expand from there.
Common tools include Semgrep, CodeQL (part of GitHub Advanced Security), Checkmarx, Veracode, SonarQube, Snyk Code and OpenText Fortify. Semgrep and CodeQL are popular with product security teams because writing custom rules is straightforward.
Software composition analysis (SCA)
Most modern applications are mostly open-source code. SCA tools inventory the dependencies a project uses, including transitive ones, and match them against databases of known vulnerabilities. They are often the first security tool a team adopts, because the results are concrete and upgrades are usually the fix.
The main problem is volume. A single popular library can generate dozens of alerts that may not matter, because the vulnerable function is never called. Newer tools add reachability analysis to show whether vulnerable code is actually used, and some also look for malicious packages, which traditional vulnerability databases do not cover.
Common tools include Snyk, GitHub Dependabot, Mend, Black Duck, OWASP Dependency-Check, Socket and Endor Labs.
Dynamic application security testing (DAST)
DAST tools test a running application from the outside, sending crafted requests and observing the responses, much like an attacker would. Because they test real behaviour, their findings are usually exploitable. But they only see what they can reach, struggle with complex authentication and single-page applications, and are slower to run.
Burp Suite, from PortSwigger, is the standard manual testing tool for web application security and appears in more product security job listings than any other testing tool. ZAP is a widely used open-source alternative. Automated DAST tools such as Invicti and StackHawk are designed to run in CI pipelines against staging environments.
Interactive testing (IAST) and runtime protection (RASP) tools, such as Contrast Security, instrument the application itself to observe vulnerabilities as code runs. They can be very accurate, but they require agents in each supported language.
Secrets detection
Leaked credentials are one of the most common causes of real breaches, and they are easy to commit by accident. Secrets detection tools scan code, commit history, logs and sometimes chat and ticketing systems for API keys, tokens and passwords. The most valuable deployments block secrets before they are pushed, and connect to providers so a leaked key can be revoked automatically.
Common tools include GitHub secret scanning and push protection, GitGuardian, Gitleaks and TruffleHog.
Infrastructure, cloud and container security
Much of a modern product's attack surface sits in its cloud configuration rather than its code: an overly permissive IAM role, a public storage bucket, or an internal service exposed to the internet. Infrastructure-as-code scanners such as Checkov and Trivy check Terraform, CloudFormation and Kubernetes manifests before deployment. Cloud security platforms, often called CNAPP, such as Wiz, Prisma Cloud and Orca, scan live cloud accounts and connect misconfigurations, vulnerabilities and identities into attack paths.
Container scanners such as Trivy, Grype and Snyk Container check images for vulnerable operating-system packages. Using minimal or distroless base images is often more effective than scanning alone, because it removes most of the packages that generate findings.
Cloud skills show up strongly in hiring. In late September 2026, Kubernetes was mentioned in 198 of the 1,303 security roles on ProductSecurityJobs.com and Terraform in 168, far more than any individual security product.
Threat modelling tools
Threat modelling is the one category where the tool matters least. A whiteboard, a clear diagram and the right people in the room will find more design flaws than any software. Tools help most with consistency and scale: recording models, reusing threat libraries, and tracking mitigations.
Options range from free tools such as OWASP Threat Dragon, the Microsoft Threat Modeling Tool and pytm (threat models as code) to commercial platforms such as IriusRisk. Frameworks matter more than tools. STRIDE is the most common prompt list; PASTA and LINDDUN, which focuses on privacy, are also used.
Fuzzing
Fuzzers generate large volumes of unexpected input to find crashes, hangs and memory-safety bugs, especially in parsers, file-format handlers, network protocols and native code. Coverage-guided fuzzers such as libFuzzer and AFL++ are the standard for C and C++; Jazzer brings the same approach to Java and other JVM languages, and Go has fuzzing built into its standard toolchain. Google's OSS-Fuzz runs continuous fuzzing for many critical open-source projects.
Fuzzing is most common in product security teams at browser, operating system, hardware, networking and security vendors, where memory-safety bugs carry the highest risk.
Software supply-chain security
Supply-chain attacks target the build and distribution of software rather than the software itself: compromised dependencies, tampered build systems or malicious updates. This area has grown quickly, driven by high-profile incidents and new regulatory expectations.
Key building blocks include software bills of materials (SBOMs), generated by tools such as Syft or built into many SCA products; artefact signing with Sigstore and cosign; and build provenance frameworks such as SLSA. Hardened base images and dependency firewalls, from vendors such as Chainguard and Socket, reduce what enters the build in the first place.
Bug bounty and vulnerability disclosure
No amount of internal testing finds everything. A vulnerability disclosure policy gives external researchers a safe way to report issues, and a bug bounty programme pays them for valid findings. Platforms such as HackerOne, Bugcrowd and Intigriti handle researcher management, triage support and payments. Product security teams usually own these programmes and the fixes that come out of them.
Pulling it together: ASPM
Once a team runs several scanners, the hard problem becomes deduplicating and prioritising their combined output. Application security posture management (ASPM) platforms aggregate findings from many tools, map them to code owners and services, and apply risk context. Examples include Apiiro, ArmorCode and Cycode. Many teams build a lighter version of this themselves, using a data store, ownership metadata and ticketing integration.
Which tools do employers ask for?
We counted how often specific tools appeared in the 1,303 live security roles on ProductSecurityJobs.com in late September 2026. Infrastructure skills dominate, and among dedicated security tools, hands-on testing and cloud security lead.
| Tool or technology | Live roles mentioning it |
|---|---|
| Kubernetes | 198 |
| Terraform | 168 |
| Docker | 79 |
| Burp Suite | 25 |
| Wiz | 22 |
| Snyk | 10 |
| Checkmarx | 10 |
| SonarQube | 10 |
| Veracode | 8 |
| Prisma Cloud | 8 |
| Semgrep | 7 |
| GitHub Advanced Security / CodeQL | 5 |
What this means for your career
Employers rarely hire for experience with a specific scanner, because most tools can be learned in days. They hire for the judgement behind them: knowing what a tool can and cannot find, telling a real finding from noise, writing custom rules, and getting fixes shipped. The data backs this up. Cloud and infrastructure skills appear in far more listings than any single security product.
If you are building your skills, learn one tool well in each of three areas: a manual testing tool such as Burp Suite, a static analysis tool you can write rules for such as Semgrep or CodeQL, and the security features of one major cloud provider. Then browse all current product security jobs, read the interview questions guide, or see how to get into product security.
Frequently asked questions
- What is the difference between SAST and DAST?
- SAST analyses source code without running it and finds insecure patterns early, but produces more false positives. DAST tests a running application from the outside and finds exploitable behaviour, but only covers what it can reach. Most teams use both.
- What is SCA in application security?
- Software composition analysis inventories the open-source dependencies an application uses and flags those with known vulnerabilities or licensing problems. Tools include Snyk, Dependabot, Mend and Black Duck.
- What tools do product security engineers use?
- Common tools include Burp Suite for manual testing, Semgrep or CodeQL for static analysis, Snyk or Dependabot for dependency scanning, secrets scanners such as GitGuardian or Gitleaks, cloud security platforms such as Wiz, threat modelling frameworks such as STRIDE, and bug bounty platforms such as HackerOne.
- Which security tools should I learn for a product security job?
- Learn Burp Suite for testing, one static analysis tool you can write custom rules for, and one cloud provider's security features. Kubernetes and Terraform appear in more product security job listings than any individual security product.