A vulnerability assessment is the systematic evaluation of a system — source code, running applications, cloud configurations, dependencies, infrastructure — to identify security weaknesses, classify them by the risk they carry and report them so they can be fixed. It covers automated scanning and manual testing, and it ends in a prioritized list of findings, not a raw inventory.
In the systems Fluid Attacks assessed during 2025, automated scanners accounted for 55.8% of the detected risk exposure. The other 44.2% came from manual techniques — and so did 87% of the critical-severity findings.
This page covers what a vulnerability assessment is and is not, how it differs from vulnerability scanning and penetration testing, the types that exist, the steps a complete vulnerability assessment follows, what its report has to contain to be usable, and what our own testing data says about what each method actually finds.
What is vulnerability assessment?
Vulnerability assessment is the process of examining an information system to find, classify and report its security weaknesses. A complete vulnerability assessment reports each finding with its category, its exact location, the evidence that supports it and a severity rating, so remediation can be prioritized instead of guessed at.
Automated tools and human testers both perform vulnerability assessment work. Signature-based scanners compare what they see against a database of known issues, such as the entries in the Common Vulnerabilities and Exposures (CVE) list, which means their reach is bounded by that database. Modern analysis is less bounded than that — our own AI SAST generates candidate findings in open-source repositories that our analysts then validate, work that has produced 12 published advisories so far — but the general point holds: a tool finds what it was built to recognize.
What a vulnerability assessment is not: a penetration test, a compliance certificate, or a one-time project. It is the detection and reporting layer that the rest of vulnerability management depends on, and the quality of everything downstream is capped by it.
Why is vulnerability assessment important?
Vulnerability assessment is the only part of your security program that tells you what an attacker would actually find. Everything after it — prioritization, remediation, compliance evidence — is built on what the vulnerability assessment reports, and it inherits that report's blind spots.
Risk exposure, not vulnerability counts
A long list of findings is not a measure of risk. Ten low-severity issues do not add up to one critical one, which is why we score findings with CVSSF, a risk-exposure metric derived from CVSS rather than a flat count. The gap is wide in practice: in our 2025 data, vulnerabilities reported by automated tools averaged 15.5 CVSSF units, while those reported by our pentesters averaged 93.2 — six times as much. A vulnerability assessment that only reports how many issues exist tells you very little about how exposed you are.
What late detection costs
Fixing a weakness before release is cheaper than fixing it in production, and far cheaper than responding to its exploitation. Among the systems we assessed in 2025, those using our CI Gate — which breaks the build when a policy-breaking vulnerability is present — reached a 72.2% remediation rate by year's end, against 58% for systems without it, and their teams closed findings at a median of 22 days versus 30.
Where compliance comes in
Several standards expect weaknesses to be identified regularly and corrected, and expect you to show the work. Our catalog maps security requirements directly to PCI DSS, HIPAA, ISO 27001, GDPR and dozens of other standards and frameworks, so a finding can be traced to the requirement it breaks. Compliance is a by-product of vulnerability assessment done well, not a reason to do it.
Assessment, scanning and penetration testing are not the same
Vulnerability assessment, vulnerability scanning and penetration testing get used interchangeably, including by vendors. They are not equivalent, and the difference decides what you will and will not find.
Practice | What it is | Performed by | Finds | Confirms exploitability? |
Vulnerability assessment | The overall process of finding, classifying and reporting weaknesses | Tools, humans, or both | Depends on the methods it includes | Only if it includes manual testing |
Vulnerability scanning | One method inside an assessment: automated detection against known patterns | Automated scanners | Known issue classes, at scale and speed | No |
Penetration testing | A methodology, not a target: simulating an attacker to reach a goal | Ethical hackers | Complex logic flaws, chained attacks, zero-days | Yes, with evidence of impact |
Scanning is a method; vulnerability assessment is the process that may contain it. Penetration testing is a second method that can sit inside the same process. The two complement each other: scanners give breadth and speed, pentesters give depth and proof, and manual review also corrects what the scanner got wrong, cutting false positives out of the final vulnerability assessment report.
Vulnerability assessment at Fluid Attacks
We run vulnerability assessment the way an attacker would approach your software, continuously, combining AI, our own scanners and our pentesters. What follows is how that works and what our own numbers say about it — including where those numbers stop being evidence.
▶️ Video: we show how our AI-native scanners, our deterministic scanners and our certified pentesters work on the same system, which is what a complete vulnerability assessment looks like in practice.
What we assess, and under what rules
Every vulnerability assessment starts with scope, agreed before testing and written down: which web apps, mobile apps, APIs and microservices, cloud infrastructure, containers and infrastructure as code are in, what is off limits, and what evidence we may collect. Exploitation is performed to prove impact, never to cause it: our testers confirm that a weakness is reachable and exploitable, and stop there.
What it looks like in practice
Surface | Technique | Evidence you get |
Source code | File, line and data flow, with compliant-code examples | |
Running applications | Request, response and a reproducible proof of concept | |
Dependencies | SCA with reachability analysis | Affected component, version and whether the vulnerable code is reachable |
Cloud and containers | Misconfigured resource or exposed credential, with its location | |
Binaries and closed components | Logic recovered from the binary and the weakness it exposes |
Automated scanning and manual testing in our data
Between January 1 and December 31, 2025, we recorded 1,119,396 vulnerabilities across the systems we assessed, carrying 27,440,146 CVSSF units of risk exposure. Splitting that by detection method:
Method | Share of risk exposure | Critical-severity findings | Average CVSSF per finding |
Automated (SAST, AI SAST, SCA, DAST, CSPM) | 55.8% | 13% | 15.5 |
Manual (PTaaS, secure code review, reverse engineering) | 44.2% | 87% | 93.2 |
Source: Fluid Attacks, State of Attacks 2026, covering all systems assessed in 2025. Pentester figures come from Advanced plan systems only; tool figures include both Advanced and Essential plans.
The pattern is consistent: tools carry the volume, humans carry the severity. That is the single most useful thing to know when you are deciding how to staff a vulnerability assessment.
What the benchmark does not prove
In our benchmark of AppSec tools and pentesting, run against a universe of 1,201 vulnerabilities spread over 105 CWE categories, a pentester reported 1,076 of them: 89.6% recall at 100% precision. Of that universe, 743 vulnerabilities — 61.9% — were detected by the pentester and by nobody else, out of 36 third-party SAST, DAST and/or SCA tools.
Three limits on that result, because a number without its caveats is not evidence:
The highest-recall automated tool in it is our own scanner, at 22.7%, against the pentester's 89.6%.
The dataset is curated, not a product. 1,201 is the size of a labeled set of known vulnerabilities, not a production application. A recall figure measured against test cases with an answer key does not transfer unchanged to real software, where nobody knows the total.
The recall is computed on the portion the pentester reviewed. The benchmark's own footnote says the pentester's false negatives are counted as 73 rather than 125, because he did not re-review sections the scanner had already covered. Change that denominator and 89.6% moves.
The automated tool with the highest recall in that benchmark is our own scanner, at 22.7%. We publish that number precisely because it is low. Scanners are not close to replacing people, and we would rather say so than round it up.
The same caution applies to the 2025 comparison above: the pentester average of 93.2 CVSSF comes from Advanced plan systems, while the 15.5 tool average spans both plans. The bases are not identical, and the six-fold gap should be read with that in mind.
Reassess every fix
A fix can fail, or introduce a new weakness. On our platform you request a reattack, and the same finding is tested again against the patched code before it is closed. A vulnerability assessment that never verifies its own remediations is reporting intentions, not state.
Types of vulnerability assessment
Vulnerability assessments are usually classified by what is being evaluated, and most teams run more than one type.
Type | Target | Typical analysis |
Host | Servers, workstations and other devices on a network | Configuration review, patch level, exposed services |
Network | An entire wired or wireless network and its reachable resources | Discovery, port and service identification, segmentation checks |
Database | Databases and big data environments | Access control, encryption, injection paths, exposed data |
Application | Web and mobile apps, APIs and microservices | Static analysis of the code, dynamic analysis of the running app |
Cloud and IaC | Cloud accounts, containers and infrastructure definitions | Posture management, image scanning, template review |
Pentesting does not belong in this list of vulnerability assessment types. It is a methodology, defined by how the testing is done, not by which system is under evaluation — which is why it compares against vulnerability scanning rather than against network or application vulnerability assessment.
How a vulnerability assessment works
NIST's SP 800-115 (2008), the technical guide to information security testing and assessment, groups the work into review techniques, target identification and analysis — network discovery, port and service identification, vulnerability scanning — and target vulnerability validation. The sequence below follows that shape.
Scope and asset inventory
You cannot assess what you have not listed. This step fixes which systems, repositories, accounts and third-party components are in scope, and what each one is worth to the business. Most vulnerability assessments that miss something miss it here, not during detection.
Detection
Scanners and analysts work over the agreed scope of the vulnerability assessment. Breadth comes from automation running on every commit and every deployment; depth comes from testers working through business logic that no signature describes.
Validation
A vulnerability assessment that skips validation ships its own errors to developers, so reported findings are confirmed first. This is where false positives are removed and where a suspected issue becomes a documented one, with evidence attached.
Prioritization
Severity alone is a poor queue. CVSS describes potential impact; EPSS estimates the probability of exploitation; CISA's Known Exploited Vulnerabilities catalog — 1,734 entries as of October 2026 — records what is already being exploited in the wild, and CISA recommends using it as an input to vulnerability management prioritization.
Our own priority score works that way. It starts from a CVSS-derived base and adjusts it with your organization's prioritization policies: the transitivity of the affected dependency, the phase of use of the vulnerable component, whether the issue appears in CISA's KEV list, its EPSS value, and the estimated time to fix. The result is a percentile against every vulnerability identified so far, which is a more useful thing to sort by than a score out of ten.
Remediation and verification
Findings are assigned, fixed through code changes, configuration changes or patches, and then retested. The vulnerability assessment is not finished when the report is delivered; it is finished when the fix is confirmed.
Each pass feeds the next: verified fixes close findings, and new commits reopen the loop.
Inside a vulnerability assessment report
A vulnerability assessment report is actionable when a developer can open a finding and know what is wrong, where it is, why it matters, what to do about it and how long it should take. Anything less and the report becomes a ticket-generation exercise. This is the part buyers evaluate least and suffer most, so it is worth being concrete about the fields.
The finding: What, where and the evidence for it
Every finding starts with a weakness category — a standardized class, not free text — and the specific instance of it found in your system. One category can appear many times; each instance needs its own location.
In a vulnerability assessment, location means the file path or the environment URL, plus the exact line of code, port number or input field affected. For code, our platform also records the hash of the commit that introduced the issue, the email of its author and the number of days between that commit and the report. That last figure is the one teams underestimate: it is a direct measure of how long the weakness sat in the repository before anyone saw it.
The description belongs to the weakness, not to the instance. Our public vulnerability database publishes it openly, and each entry carries the same five fields: what the weakness is, its impact, the threat actor it assumes, the recommendation to fix it and an expected remediation time in minutes. Entry 079, Non-upgradable dependencies, is a plain example: the impact is "loss of maintainability because dependencies are not maintained", the threat is an "authenticated attacker from the Internet", the recommendation is to declare every dependency through a dependency manager, and the expected remediation time is 120 minutes. Each entry also links to the security requirement it breaks, which is how a finding becomes compliance evidence instead of a separate exercise.
Weakness 079 in our open database. Every entry carries the same five fields and links to the security requirement it breaks, so anyone can check what a vulnerability assessment of ours is built on.
Severity, and what the score does not say
Severity in a vulnerability assessment should be a score and its vector. The score alone is an opinion; the vector is the reasoning. Our platform shows the CVSS v4.0 vector string, the calculated score with its qualitative rating, and a breakdown of every metric that produced it, so a reader can disagree with a specific metric rather than with the number.
The qualitative bands are worth stating plainly, because teams argue about them more than they should: low is 0.1 to 3.9, medium 4.0 to 6.9, high 7.0 to 8.9, and critical 9.0 to 10.0. A report that gives you only the band has thrown away the part you could have checked.
The Severity tab on our platform: the calculated score, its qualitative rating and the vector that produced it, metric by metric. A vulnerability assessment that reports only the rating hides the reasoning.
Field | What it answers | Why it matters |
Weakness and description | What class of issue this is | Groups instances and connects them to a known fix |
Location and specific line, port or input | Where exactly it is | A finding without this is a rumor |
Evidence | How we know it is real | Lets the developer reproduce it instead of trusting you |
CVSS score and vector | How bad it could be, and on what reasoning | Makes the severity auditable |
Priority | What to fix first | Adds exploitation and context data to severity |
Expected remediation time | What it should cost to fix | Turns a backlog into something you can plan |
Treatment and assignee | Who owns it and under what decision | Stops findings from sitting unowned |
Reattack record | Whether the fix worked | Closes the loop with proof instead of a status change |
Associated requirement | Which standard this breaks | Converts findings into compliance evidence |
Treatment: who owns it, and until when
A finding with no owner does not get fixed. A vulnerability assessment report should carry the treatment applied to each vulnerability, the person assigned to it, the date that decision was made and, when the treatment is temporary, the date it expires. An accepted risk with no expiry is not a decision; it is a finding that was quietly dropped.
The same applies to false positives. Our platform treats a false positive as a requested, recorded treatment rather than a silent deletion, which means the disagreement stays visible and reviewable. If your vulnerability assessment report lets findings disappear without a trace, you have no way to audit the judgment calls made on your behalf.
Verification: the reattack record
The last field is the one that separates a vulnerability assessment from a claim. Each finding should show the outcome of its most recent reattack, the date it was requested, who requested it, how many reattack cycles it has been through and the efficiency of those cycles — the share that confirmed an actual fix.
Cycles and efficiency are the diagnostic nobody asks for and everybody needs. A vulnerability that has been through four reattacks with low efficiency is not a remediation problem; it is a sign that the team is patching a symptom and the underlying weakness is still there.
Vulnerability assessment as part of vulnerability management
Vulnerability assessment detects and reports; vulnerability management decides what gets fixed first, assigns it, tracks it and verifies it. A risk-based approach to that second half is what keeps limited engineering time pointed at the findings that matter.
Both halves have to run continuously, which is why vulnerability assessment is a process and not a project. Systems change on every merge, and new weaknesses appear in dependencies you did not touch — our catalog tracks more than 340,000 vulnerabilities across 15 open-source ecosystems. Point-in-time testing describes a system that no longer exists by the time the report is read, which is why vulnerability assessment belongs inside the CI/CD pipeline, as DevSecOps prescribes, rather than beside it.
Conclusions
Treat vulnerability assessment as a measurement problem, not a reporting exercise. The method you choose sets a ceiling on what you can possibly find: in our 2025 data, automation produced most of the volume while 87% of the critical findings came from people, and in our benchmark the best automated tool recalled 22.7% of a known vulnerability set against a pentester's 89.6%. Pick one method and you have not reduced risk, you have narrowed your view of it.
Then judge the vulnerability assessment by its fields, not its page count. A finding that carries its location, its evidence, its vector, its priority, its owner and its reattack history is one a developer can act on this week. A severity band and a paragraph is not.
The practical consequence of treating vulnerability assessment this way is a short list. Inventory what you own, run both methods over it continuously, validate before you escalate, prioritize with exploitation data rather than severity alone, and retest every fix.
Frequently asked questions
Is vulnerability assessment the same as vulnerability scanning?
No. Vulnerability scanning is one method inside a vulnerability assessment. A vulnerability assessment is the whole process of finding, classifying and reporting weaknesses, and it can combine automated scanning with manual testing. Describing an assessment as "running a scanner" leaves out the part that finds the complex issues.
How often should a vulnerability assessment be done?
Continuously, not on a schedule. Code changes on every merge and new vulnerabilities appear in dependencies you never edited, so an annual or quarterly vulnerability assessment reports on a system that has already changed. In our 2025 data, systems with a CI gate in place reached a 72.2% remediation rate against 58% for those without one.
Can automated scanners replace pentesters?
Not currently. Among the systems Fluid Attacks assessed in 2025, 87% of the critical-severity findings were identified through manual review, and vulnerabilities found by pentesters averaged 93.2 CVSSF units against 15.5 for those found by tools. Scanners deliver speed and coverage; people find the logic flaws and chained attacks that no signature describes.
What should a vulnerability assessment report include?
At minimum: the weakness, its exact location, the evidence, a CVSS score with its vector, a priority, an expected remediation time, an owner and a verification record. A report that gives a severity band without the vector, or a finding without a reproducible location, cannot be acted on or audited.
Does a vulnerability assessment help with PCI DSS or ISO 27001 compliance?
Yes, when the findings are mapped to requirements. Standards such as PCI DSS, HIPAA, ISO 27001 and GDPR expect weaknesses to be identified and corrected. A finding that can be traced to the specific requirement it breaks turns a vulnerability assessment report into compliance evidence instead of a separate exercise.
Does Fluid Attacks perform vulnerability assessments?
Yes. We combine AI and our own scanners — SAST, AI SAST, SCA, DAST, MAST, CSPM, Secret Scanning — with Pentesting as a Service, Secure Code Review and Reverse Engineering. Every finding lands on our platform with its evidence, its severity, its remediation guidance and a reattack button to verify the fix.
Assess what an attacker would actually reach
Our scanners and pentesters run vulnerability assessment on your systems as they change, so the findings you prioritize reflect what is exploitable today rather than what a scan found last quarter. Start free trial · Contact us
Get started with Fluid Attacks' RBVM solution right now
