Security testing is the practice of evaluating a system — source code, a running application, or the infrastructure behind it — to find the weaknesses an attacker could exploit, and to confirm that its design and configuration protect the availability, confidentiality and integrity of data.
What makes it worth doing is the gap between what a scanner flags and what actually breaks a system: in Fluid Attacks' tool benchmark, a pentester found 743 of the 1,201 vulnerabilities present in the target application that no automated tool in the study detected. Those 743 issues carried 86.8% of that application's total risk exposure.
This page covers what these assessments are, what they aim for, the types and techniques that exist, the tools involved, and how to run a program that measurably reduces risk.
What is security testing?
Security testing evaluates whether a system behaves safely under conditions its designers did not plan for. A functional test asks whether a feature works. A security assessment asks what happens when someone deliberately misuses it: sending malformed input, skipping a step in a workflow, replaying a token, or chaining two harmless behaviors into one dangerous outcome.
The object under evaluation — the target of evaluation, or ToE — can be source code, a deployed application, an API, a mobile binary, a network, or a cloud environment. The output is a set of vulnerabilities, each with a severity, a location, and enough evidence for a developer to reproduce and fix it.
Security testing is not a single activity. It spans automated scanning, which is fast and broad, and manual work by ethical hackers, which is slower and deeper. Most programs need both, for reasons the numbers in this page make concrete.
Main goals of security testing
A good assessment serves four goals at once:
Find exploitable weaknesses before an attacker does: not every defect is a risk, and not every risk deserves the same attention. The point is to surface the ones an adversary could realistically abuse.
Measure risk exposure, not just vulnerability count: ten low-severity issues do not equal one critical one. Fluid Attacks uses CVSSF, a metric derived from CVSS (CVSSF = 4 ^ (CVSS − 4)), so that one critical vulnerability counts as 4,096 units while ten minor ones add up to 0.2.
Give development teams something they can act on: a finding without a reproducible path and a remediation route is noise.
Support compliance without making it the objective: standards such as PCI DSS, HIPAA and ISO 27001 require security testing, but passing an audit and being hard to attack are different achievements.
Why is security testing important?
Because exploitation is now the most common way in. According to Verizon's 2026 Data Breach Investigations Report, "nearly a third (31%) of all breaches start with vulnerability exploitation" — the first time in 19 years that it has overtaken stolen credentials as the leading entry point.
The cost side is equally well documented. IBM's annual research on the financial impact of breaches puts the average breach in the millions of dollars, before counting regulatory penalties, customer churn, and the engineering time diverted into incident response. A vulnerability found during development costs a fraction of the same vulnerability found by an attacker.
There is also a compounding effect. Systems change constantly, and every change can introduce a weakness that was not there last month. A single annual assessment produces a snapshot that is stale within weeks. Performing security testing continuously keeps the picture current as the code evolves.
Case study: Costly lessons in the power of security testing
In 2023, Microsoft's AI research team accidentally exposed 38TB of internal data — including private keys, passwords and internal messages — through an overly permissive Azure SAS token published alongside a public GitHub repository.
The misconfiguration behind that leak was not an exotic zero-day. It was a permissions mistake that a review of the cloud configuration would have caught, and it sat in the open for nearly three years before researchers reported it.
Marriott International, a leading hospitality chain, unfortunately became the target of two major data breaches in 2014 and 2020, exposing the personal information of millions of guests.
Case study: Marriott International data breaches.
That is the shape of most real incidents: not a novel exploit, but an ordinary mistake that nobody looked for.
Security testing at Fluid Attacks
What we assess, and under what rules
Fluid Attacks assesses only systems it has been explicitly authorized to assess, within a scope agreed with the client before any work starts. Every technique described further down this page — from static analysis to manual exploitation — runs inside that agreement. Ethical hacking without authorization is not security testing; it is an attack.
The work is delivered as one all-in-one solution with two plans. The Essential plan runs the automated side: our own SAST, AI SAST, DAST, SCA, secret scanning and CSPM engines. The Advanced plan adds our pentesters, who hold 63 offensive security certifications across web, mobile, cloud, red teaming and exploit development, and who run manual penetration testing, secure code review and reverse engineering against the same target.
What our own numbers show
The reason we insist on combining both is that we measured the difference on a single application.
In our tool benchmark, we ran 36 third-party SAST, DAST and SCA tools — several of them in the Gartner Magic Quadrant — plus our own scanner and one of our pentesters against the same target: 1,201 known vulnerabilities across 105 CWE categories, worth 461,500 CVSSF units, with 73.2% of them behind authentication.
Evaluator | True positives | False positives | Precision | Recall | Recall (CVSSF) |
Fluid Attacks pentester (manual) | 1,076 | 0 | 100% | 89.6% | 98.9% |
Fluid Attacks scanner (automated) | 273 | 3 | 99% | 22.7% | 8.8% |
Best third-party tool in the study | 260 | 102 | 72% | 21.6% | 4.0% |
Average of the other 34 tools | — | — | — | 1.7% | — |
Two findings stand out. First, 17 of the 36 third-party tools failed to identify even ten vulnerabilities out of the 1,201 present. Second, 743 vulnerabilities — 61.9% of the total, and 86.8% of the risk exposure — were detected exclusively by the pentester.
The pattern held up years later against fresh data. Our State of Attacks 2026 report, covering assessments from January 1 to December 31, 2025, found that our tools detected 55.8% of total risk exposure while manual security testing detected, on average, five times more risk exposure per finding. Pentesters accounted for 90% of the risk exposure coming from critical-severity vulnerabilities.
Where that expertise comes from
Benchmarks measure a team on one application. Competitions measure it against everyone else. In the 2025 Hack The Box Business CTF — the Global Cyber Skills Benchmark, a four-day competition spanning web hacking, cryptography, reversing, cloud and full network compromise — our hacking team finished #1 in Latin America and #9 worldwide, completing 59 of 66 challenges with 14 players against the roughly 30 that each top-five team fielded.
That result is the end of a progression, not a one-off. Simon Correa, Head of Research at Fluid Attacks, documented it in his write-up of how the team reached the top 10:
"In 2021, the competition's first edition, we placed #80 worldwide. In 2024, we climbed 45 spots to #35. And in 2025, we jumped another 26 positions to finish #9 worldwide."
Simon Correa, Head of Research, Fluid Attacks, January 2026.
The same people run the assessments described on this page.
From finding to fix
Finding issues is only half the job. In the 2025 dataset, the overall remediation rate reached 62.2% by year end — 21.2 percentage points higher than in 2024 — and critical-severity issues had the best cumulative rate at 63.8%. Systems using our CI Gate, which breaks the build when a policy threshold is crossed, reached a 72% remediation rate against 58% for those without it, and closed issues 27% faster.
The phases described later on this page are not theoretical for us. Each finding is reported on our platform with its evidence and its CVSSF value, mapped against our own catalog of 384 software weaknesses, 182 security requirements and 1,937 remediation guides. When a team believes it has fixed something, it requests a reattack and one of our pentesters verifies it against the live system.
▶️ Watch: Michael Rivera, Chief Data & AI Officer at Fluid Attacks, walks through the full 2025 dataset — remediation rates, the manual-versus-automated split, and the CI Gate effect — in our State of Attacks 2026 webinar (36 minutes, in Spanish).
Key principles of security testing
Five principles separate an assessment that reduces risk from one that produces a document:
Confidentiality, integrity and availability: every finding should be traceable to which of these three properties it threatens.
Authentication and authorization: the majority of serious findings live behind a login. In our benchmark, 73.2% of the vulnerabilities in the target required authentication to reach — which is why unauthenticated scans systematically underreport.
Non-repudiation: actions must be attributable, and logs must survive an attacker who wants them gone.
Least privilege: test whether a compromised low-privilege account can reach data it has no business reaching.
Defense in depth: a single control failing should not end the story.
Types of security testing
The type is defined by what you are testing, not how.
Web application security testing
Web systems are the most exposed surface most organizations have. Assessments here combine web scanners with manual work against the categories in the OWASP Top 10: broken access control, injection, cryptographic failures, and the rest. Business logic flaws — a checkout that accepts a negative quantity, a password reset that leaks whether an account exists — are almost invisible to scanners and routine for a pentester. See how we secure your web applications.
Mobile application security testing
Mobile apps testing inspects the compiled app, its local storage, its certificate handling and the APIs it talks to. Hardcoded keys, unencrypted local databases and disabled certificate pinning are the recurring findings. Because the binary ships to the attacker's own device, manual review matters more here than almost anywhere else. See how we secure your mobile apps.
Network security testing
Network assessments map exposed hosts and services, check segmentation, and look for outdated services and weak protocols. The question is not only what is reachable from the internet, but what an attacker can reach after landing on a single internal host.
API testing
APIs concentrate business logic with very little UI to constrain it. Broken object-level authorization — changing an ID in a request and getting someone else's data — remains the most common serious finding. Rate limiting, schema validation and token handling round out the checklist. See how we secure your APIs.
Cloud infrastructure security testing
Cloud assessments review identity policies, storage permissions, network rules and secrets management against the provider's shared responsibility model. The Microsoft case above is the canonical example of what goes wrong here.
Other terms related to security testing
These terms get used interchangeably. They are not the same thing.
Cybersecurity risk assessment
A risk assessment is a management exercise: it identifies assets, estimates the likelihood and impact of threats against them, and sets priorities. It informs where to test. It does not find vulnerabilities.
Security auditing
An audit checks conformity against a standard or policy. It answers "do we comply?" — a technical assessment answers "can this be broken?" Both matter, and passing one does not imply passing the other.
Security posture assessment
A posture assessment looks at the whole organization: tooling, processes, people, and the gaps between them. It is broader and shallower than a technical evaluation of a single system.
Vulnerability scanning
Scanning for vulnerabilities is automated detection of known issues against signatures and rules. It is a component of a vulnerability assessment, and a component of full security testing — not a substitute for either. The benchmark table above is the clearest statement of what it does and does not cover.
Ethical hacking
Ethical hacking is the authorized simulation of real attacks. An ethical hacker works with the same mindset and much of the same toolkit as an adversary, under a contract that defines scope and rules of engagement. Pentesting, red teaming and social engineering all sit inside it — and the distinctions between them are ones we have done before in this blog.
Security testing techniques
The technique is defined by how you test.
SAST: static analysis reads source code, bytecode or binaries without running them. It catches insecure patterns early and integrates cleanly into a pipeline, at the cost of false positives and no visibility into runtime behavior. Picking a SAST tool is mostly a question of language coverage and noise.
DAST: dynamic analysis attacks the running application from the outside. It sees what the deployed system actually does, including configuration and integration problems, but it only reaches what it can crawl.
SCA: software composition analysis inventories third-party dependencies and flags known vulnerable versions. Good SCA tools also tell you whether the vulnerable code is actually reachable from your application.
CSPM: cloud security posture management continuously checks cloud configuration against secure baselines.
MPT: manual penetration testing is a human attacking the system with a goal. It is where business logic flaws, chained exploits and authorization gaps come from, and where the risk exposure that tools miss gets found.
SCR: secure code review is a human reading the code, usually guided by tool output, to judge what the tool could not.
RE: software reverse engineering takes apart compiled artifacts to understand behavior the source does not reveal — essential for mobile apps and third-party binaries.
Security testing tools
Tools do the breadth. Fluid Attacks' scanners cover SAST, SCA and DAST, and are recommended under the App Defense Alliance's Cloud Application Security Assessment for static scanning and recommended by CASA for dynamic scanning. On the OWASP Benchmark, our static engine scored 100% in true positives and 0% in false positives.
If you are evaluating open source options, maintenance status is the signal that matters most — and how to benchmark them properly deserves its own process. A few examples, with their standing in the OpenSSF Best Practices program:
SpotBugs still hasn't earned a passing badge, and a 2021 study measured how much of what it reports is actionable.
OWASP Zed Attack Proxy is the most widely used open source web application vulnerability scanner, and the equivalent badge listings are worth checking before adopting any of these. For mobile, the OWASP MASTG project has compiled them here.
None of this replaces judgment. The benchmark above measured 36 of these tools against one application; 34 of them averaged 1.7% recall.
The impact of false positives and false negatives in security testing
A false positive is an alert with nothing behind it. A false negative is a real vulnerability that nobody reported. Both are expensive, in different ways.
False positives consume the one resource that is hardest to get back: developer trust. A team that spends a sprint chasing phantom findings starts ignoring legitimate warnings in the future. In the benchmark, the best third-party tool produced 102 false positives against 260 true ones — a 72% precision rate — while six other tools averaged around 130 false positives each. Our pentester produced zero.
False negatives are worse and quieter. Nobody notices them until an attacker does. This is where the 8.8% CVSSF recall of even the best automated engine becomes the number to remember: a clean scan report is not the same as a secure application.
How to do security testing
Whatever the scope, the sequence is the same:
Define scope and rules of engagement. Which systems, which environments, which techniques are allowed, who to contact if something breaks. Get it in writing.
Map the attack surface. Enumerate endpoints, services, dependencies and entry points. You cannot test what you have not found.
Run automated analysis. SAST and SCA in the pipeline on every commit, DAST and CSPM against deployed environments on a schedule. This is the cheap, broad layer.
Add manual work where it pays. Authenticated flows, business logic, authorization boundaries, anything handling money or personal data. This is the layer that finds critical issues.
Prioritize by risk, not by count. Use a severity metric that reflects real impact, and fix the top of the list first.
Fix and verify. A finding is not closed until someone has confirmed the fix against the live system.
Repeat as the system changes. Ideally on every commit, not once a year.
Embedding security testing into a DevSecOps methodology is what turns it from a project into a practice, and which techniques to use at each stage is the decision that determines whether it works.
NIST's Secure Software Development Framework (SP 800-218, version 1.1, published February 2022) formalizes the same idea: reviewing human-readable code and testing executable code are separate, both required practices — not alternatives.
Conclusions
Security testing is how an organization finds out what an attacker would find out, on its own terms and its own schedule. The evidence is consistent on what that requires. Verizon's 2026 DBIR puts vulnerability exploitation at 31% of breaches, ahead of stolen credentials for the first time in 19 years. Our own benchmark found 61.9% of an application's vulnerabilities — and 86.8% of its risk exposure — only through manual work. Our 2025 data found pentesters responsible for 90% of the risk exposure from critical vulnerabilities.
Automation is not optional: nothing else gives you coverage on every commit. But a program built on scanning alone is measuring the part of the problem that is easy to measure. Combine both, run them continuously, and verify the fixes.
FAQs
What is the difference between security testing and a security audit?
Security testing looks for exploitable vulnerabilities in a system. An audit checks whether the organization complies with a standard or policy — its processes, documentation and controls. An organization can pass an audit and still be trivially exploitable.
How often should security testing be done?
Continuously, integrated into the CI/CD pipeline, rather than once a year before an audit. Systems change on every commit, and a point-in-time assessment goes stale within weeks. In our 2025 data, teams using our CI Gate reached a 72% remediation rate against 58% for teams without it.
Is automated security testing enough on its own?
No. In Fluid Attacks' benchmark of 36 third-party tools against an application with 1,201 known vulnerabilities, the best automated engine reached 22.7% recall and covered 8.8% of the risk exposure, while a pentester reached 89.6% recall and 98.9% of the risk exposure. Automation gives you breadth; human testers find the critical issues.
Does Fluid Attacks use automated tools, manual testing, or both?
Both, on the same target. Our Essential plan runs our AI SAST, SAST, SCA, DAST, secret scanning and CSPM engines. Our Advanced plan adds pentesters performing manual penetration testing, secure code review and reverse engineering, and lets teams request reattacks to verify that a fix actually worked.
Which type of security testing finds the most critical vulnerabilities?
Manual testing. In our State of Attacks 2026 report, covering all assessments run in 2025, pentesters accounted for 90% of the risk exposure coming from critical-severity vulnerabilities, and manual work detected on average five times more risk exposure per finding than our automated tools.
What does security testing cost?
It depends on scope — one application versus a full estate — on which techniques are included, and on whether it is a one-off engagement or a continuous program. Continuous programs cost more per year and find far more, because they test the system as it changes rather than once.
See what your scanner misses
In our benchmark, the best scanner found 22.7% of vulnerabilities and our pentesters found 89.6%. Test with both. Start free trial · Launch interactive demo.
