Vulnerability management tools for a small team: reading the scanner output, scoring it, and fixing in order

Vulnerability management tools are the scanners and trackers that find known weaknesses in what you run, score them, and hold the list until each one is fixed or accepted. For one web app I’d use three things, not a platform: a dependency scanner in CI, a web scanner at staging, and a tracker with a due date per finding.

What vulnerability management tools are, and which a small team needs

Vulnerability management tools do four jobs: discover what you run, scan it, score the findings, and track each one to closure. Enterprise platforms are built to do all four across many hosts. In my working rule, one web app needs a dependency scanner in CI, a web scanner against staging, and a tracker, and all three can be free.

Dependencies and scanning are two of the controls in web app security, and the two where a tool does most of the work. Vulnerability management software from vendors such as Tenable, Qualys and Rapid7 is aimed, in my reading, at organizations that first have to find their servers, laptops and cloud accounts. One web app on a managed host has no fleet. The first job shrinks to a list you can write on one page, and the other three fit in tools you already have or can switch on today.

This is the small-team mapping I use, one row per job. It is a vulnerability management tools comparison by job, not by vendor: I make no vulnerability management tool comparison by features, and I do not rank anything.

For the scan row, the dependency scanner can be the code host’s alerts or the npm audit command run in CI, and choosing a web scanner, with what each one proves, is covered in a website security check. The platform advisor matters more than it looks: Supabase’s dashboard Security Advisor flags tables with RLS disabled in public schemas, RLS enabled with no policies, policies written as USING (true), and SECURITY DEFINER functions callable without authentication. Those are the same three tools a small team uses for vulnerability assessment, and any cyber security assessment tool you add later should map onto one of the four jobs. An IT scanner in this sense is a security scanner, not the network scanner that discovers the devices and IP addresses on a local network.

If you want open source scanning tools and open source vulnerability management tools, four are worth knowing by what their own pages say they are. ZAP, known as OWASP ZAP until it left OWASP in 2023, describes itself as a web app scanner, “Free and open source”. OpenVAS is the scanner inside Greenbone’s Community Edition, “a full-featured scan engine that executes Vulnerability Tests (VTs) against target systems”, released under open-source licenses. DefectDojo is the nearest thing to an open source vulnerability management platform: its repository describes a tool that “orchestrates end-to-end security testing, vulnerability tracking, deduplication, remediation, and reporting”, carries an OWASP Flagship badge, is licensed BSD 3-Clause, and sits beside a Pro edition. Dependabot alerts are available for organization-owned and user-owned repositories on GitHub, with no plan purchase needed.

A paid platform starts to earn its cost, in my reading, in three cases: you run many hosts yourself, a compliance scope names an approved scanning vendor, or the open findings no longer fit in a spreadsheet anyone reads. Until one of those is true, I would not shop for the best vulnerability management tools or the top vulnerability management tools; the money buys dashboards for a short list of findings.

What vulnerability management is: the lifecycle in five steps

Vulnerability management is a loop of five steps: discover what you run, scan it, prioritize the findings, fix or mitigate them, then verify by rescanning and record the result. Sources count the steps differently. The step that is easiest to skip is the rescan that proves the fix.

1. 01 Discover. List every repository, host, domain and third-party service that is yours to fix.
2. 02 Assess. Scan each item: dependencies, the running web app, and the ports a stranger can reach.
3. 03 Prioritize. Order the findings by whether they are reachable, being exploited, likely to be exploited, and how severe they are.
4. 04 Remediate or mitigate. Upgrade, patch or remove the flaw, or lower the risk with an expiry date while the flaw stays.
5. 05 Verify and report. Rescan or check the deployed version, record the date, and start the loop again.

That is the vulnerability management lifecycle as I run it for one app, and the vulnerability life cycle other sources describe has four to six steps depending on where they split assessment from prioritization. NIST SP 800-40 Rev. 4, NIST’s guide to enterprise patch management, frames its half of the loop in five verbs: “identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades throughout an organization.” The order is the answer to the question of which step comes first: you cannot prioritize what you have not found, and you cannot verify what you have not fixed. The fix-order section below tells a public case where the verify step was missing.

Continuous vulnerability management is the same loop run on a schedule and on every change, not once before a launch. Cyber security vulnerability management in a large company adds asset owners, change boards and reporting lines, but the loop does not change.

Risk-based vulnerability management (RBVM) orders the list by the risk to your system: is the flaw reachable, is it being exploited, and what does the affected code guard. Base severity alone is only one input. The fix-order section below is RBVM at the scale of two people. Exposure management, a newer vendor term, widens the same idea from known software flaws to misconfigurations, identities and the paths an attacker could chain between them. For one app, the difference is mostly vocabulary.

Why it matters for a small app: the vulnerability window

The vulnerability window is the time between a flaw becoming public and your fix being deployed. Scanning shortens the first half, because you find out. The tracker shortens the second half, because someone owns the fix and a date sits next to it.

In my June and July 2026 audits, 9 of the 26 apps I audited ran a framework version with a publicly known, reachable RCE or auth bypass, and the fix was often a one-line version bump; 8 of those 9 were among the 21 third-party apps and 1 was an app of my own. Across the third-party apps in the same audits, the Dependencies and Supply Chain pillar averages 34.5 out of 100, scored on 20 of the 21 (N/A pillars excluded, not zeroed), and ranks 2 of 12 pillars by weakness. Those apps are a selected set, not a random sample, so the numbers describe that set, not a rate for AI-built apps in general.

The benefits of vulnerability scanning come down to three things. You learn about a flaw before an attacker’s scanner tells you. A customer’s security questionnaire gets an answer with a date on it. And the list stops growing silently between releases.

These are the vulnerability management best practices I hold a small team to, each expanded further down:

• Scan on a schedule and on every change.
• Scan logged in, so the scanner reaches the pages users reach.
• Score with more than CVSS: add KEV, EPSS and reachability.
• Fix by a written rule, not by the color of the finding.
• Verify each fix by rescanning or checking the deployed version.
• Write exceptions down with an owner and an expiry date.

A scanner cannot see broken access control between two users or a business rule that is wrong. Those need a person reading the code and the app, which is what a web application security audit is for.

How it works: the scans, and how often to run them

A vulnerability scan is an automated check of a system against a database of known flaws and misconfigurations, reported with an id and a severity. There are three kinds a small app meets: a dependency scan, a web application scan, and an external network scan.

That is my plain vulnerability scan definition. NIST’s glossary entry for vulnerability scanning gives the vulnerability scanning definition in fewer words: “A technique used to identify hosts/host attributes and associated vulnerabilities.” Either way, the idea is narrow: a tool compares what it can see with what it knows. It is not web application penetration testing, where a person tries to get in and chains findings together; how the two differ is covered in pen test vs vulnerability assessment. A vulnerability assessment is the scan plus a person’s triage and fix plan; the report section below shows its parts.

Web scanner and application scanner: what a web application scan covers

A web scanner crawls a running app and probes its pages and parameters for known flaw classes. A passive scan only reads traffic and an active scan sends test requests, so active scans belong on staging. In ZAP, the baseline scan performs no attacks; the full scan’s spider has no time limit by default, and a full active scan follows.

Web app scanners test the app while it runs, from the outside, which makes them a dynamic test (DAST). Tools that read the source instead are static code analysis tools, and the trade-off between the two is in SAST vs DAST. An application scanner, in the security sense, is the same thing as a web scanner; the phone apps that scan documents or QR codes share the name and nothing else.

The difference between active scan and full scan is a question about ZAP’s packaged scans. The baseline scan “runs the ZAP spider against the specified target for (by default) 1 minute and then waits for the passive scanning to complete”, and it “doesn’t perform any actual ‘attacks’”. The full scan “runs the ZAP spider against the specified target (by default with no time limit) followed by an optional modern spider scan and then a full active scan”, which means it “does perform actual ‘attacks’ and can potentially run for a long period of time.” The active scan is the attacking part; the full scan is the spider plus that active scan plus the report. ZAP’s full scan documentation has the details.

When you scan web app routes this way, what web application scans find well, in my reading, is missing security headers, outdated server software, reflected injection and files that should not be public. What they cannot find is a user reading another user’s data, because the scanner does not know whose data is whose. Tool choice and what each tool proves stay with the website security check linked above.

External and internal vulnerability scans, authenticated or not

An external vulnerability scan runs from the internet and shows what a stranger sees; an internal one runs inside the network. Either can run unauthenticated or authenticated, and only the authenticated scan logs in and reaches the real surface of a web app. An app on managed hosting has no internal network to scan.

An external vulnerability scanner answers the stranger’s question, and external vulnerability scanning is the one kind every app needs. An internal vulnerability scan answers what a machine inside the network could reach. For an app on Vercel and Supabase, the honest internal equivalent, in my reading, is the dependency scan plus the platform’s advisor.

Internal scanning matters once you run your own servers. Then the internal vulnerability scanning tools are the same kind of network vulnerabilities scanner used from inside: OpenVAS, the scanner in Greenbone’s Community Edition docs, is internal vulnerability scanning software you can install on a machine in that network. On a VPS you run, point it at your own address from outside and confirm that only the ports you meant to open answer, which for a web app I’d expect to be 80 and 443. Network vulnerability tests of this kind are not the home Wi-Fi network security test that shares the name.

Authenticated scanning logs in and tests what a user can reach, which is where an app’s real surface is. An unauthenticated scan of a login-walled app mostly tests the login page. Proving that the scanner stayed logged in for the whole run is its own problem, worked through in vibe coding security scanners compared.

If you take card payments and are in scope for PCI DSS, its v4.0.1 self-assessment questionnaire D for merchants names both kinds: requirement 11.3.1 asks for internal vulnerability scans “At least once every three months”, 11.3.1.2 asks for internal scans “performed via authenticated scanning”, and 11.3.2 asks for external scans “At least once every three months” and “By a PCI SSC Approved Scanning Vendor (ASV)”. Whatever you scan, scan only systems you own or have written permission to test.

How often should systems be scanned

Scan on change and on a schedule, in my working rule: dependencies on every pull request and daily, the web app weekly or monthly against staging, external ports monthly. NIST’s RA-5 leaves the frequency to the organization, and PCI DSS asks for at least once every three months from merchants in scope.

This is the scan frequency I hold one app to, and it is my working rule, not a standard. What the frameworks say is narrower. NIST vulnerability scanning guidance sits in NIST SP 800-53 Rev. 5, control RA-5, which asks organizations to “Monitor and scan for vulnerabilities in the system and hosted applications” at an “organization-defined frequency and/or randomly in accordance with organization-defined process” and “when new vulnerabilities potentially affecting the system are identified and reported”.

Asked whether systems should be scanned monthly, I give a floor, not a target: monthly is my working floor for the web and external scans, and the change trigger matters more than the calendar, because a new login flow shipped on the second of the month should not wait four weeks for its first scan. No framework above says monthly.

The vulnerability scan process, one line each: scope, schedule, run authenticated, triage, fix, rescan, record. Schedule scan jobs in CI so nobody has to remember them; the pipeline side is covered in CI/CD best practices. What runs on each change and how suppressions get an owner and a reason are part of the scanner article linked above, and those are the vulnerability scanning best practices I would copy rather than rewrite.

How to read the output: CVE, CWE, CVSS, EPSS and KEV in one finding

A scanner finding has five fields worth reading: the CVE id names the flaw, the CWE names its class, the CVSS score rates severity, the EPSS score estimates the chance of exploitation, and the KEV flag says it has already been exploited in the wild. The fixed version tells you the work.

Here is one finding, constructed for this page as an example. The fields are real, read from NVD, FIRST and CISA on 2026-09-26, for a Next.js app on a 15.5 release inside NVD’s affected range.

EXAMPLE FINDING (constructed for illustration; values read 2026-09-26)
id:         CVE-2025-55182
component:  next 15.5.x, inside NVD's range "From (including) 15.5.0 Up to (excluding) 15.5.7"
summary:    pre-authentication remote code execution in React Server Components
weakness:   CWE-502 Deserialization of Untrusted Data   (source: NIST)
cvss:       10 CRITICAL   CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H   (source: CNA Facebook, Inc.)
            NIST: NVD base score N/A, "NVD assessment not yet provided"
epss:       0.99802   percentile 0.99957   (FIRST, scored 2026-09-26)
kev:        yes   date added 2025-12-05   federal due date 2025-12-12
fix:        move to 15.5.7 or later on the 15.5 line (the end of NVD's affected range)

Read it top to bottom and each line answers one question. The id is the name you search for. The weakness says what kind of mistake it is. The CVSS line says how bad it would be, and who said so: here the score came from the numbering authority, and NVD had not added its own. The EPSS line says how likely exploitation is in the next month. The KEV line says it has already happened. The fix line is the work. If you wanted an example of a CVE, this is one, and each field has its own section below.

CVE vs CVSS, and what NIST’s NVD adds

A CVE is an id for one publicly known vulnerability; CVSS is the system that scores its severity from 0 to 10. The first is a name and the second is a measurement. NIST’s NVD is the database that attaches scores, weakness classes and affected products to CVE records.

The CVE Program’s stated mission is “to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities”, with “one CVE Record for each vulnerability in the catalog”, assigned and published by organizations that have partnered with the program. The CVE website, cve.org, holds those records; the CVE Program’s overview explains who assigns them. Vulnerability codes, in a questionnaire, usually means these ids. The program does not score severity: its own overview lists “The CVE Program is responsible for assigning vulnerability severity scores” as a myth.

The Common Vulnerability Scoring System (CVSS) comes from FIRST and “is currently at version 4.0”. Version 4.0 has four metric groups, “Base, Threat, Environmental, and Supplemental”, and the base score “assumes the reasonable worst-case impact across different deployed environments”. FIRST’s CVSS page links the specification, and FIRST’s own user guide says base scores “are designed to measure the severity of a vulnerability and should not be used alone to assess risk.” That sentence is the reason this page does not sort by CVSS alone.

NIST NVD adds detail to each CVE record. NVD enrichment adds “impact metrics (Common Vulnerability Scoring System - CVSS), vulnerability types (Common Weakness Enumeration - CWE), and applicability statements (Common Platform Enumeration - CPE)” to published CVEs, and NVD “does not actively perform vulnerability testing”. How often the NVD is updated is not stated as a single cadence on NVD’s pages. NIST’s notice of April 15, 2026 says it will prioritize three groups for enrichment from that date: CVEs in CISA’s KEV catalog, with a goal of enrichment “within one business day of receipt”; CVEs for software used within the federal government; and CVEs for critical software as defined by Executive Order 14028. CVEs outside those criteria are to be categorized as “Lowest Priority - not scheduled for immediate enrichment.” NIST also says it developed “a significant backlog of unenriched CVEs” starting in early 2024 that it has “been unable to clear”, and that it will “no longer routinely provide a separate severity score” for CVEs whose numbering authority already scored them. That fits the example above: a CNA score, and no NVD score yet.

A CVE exploit line in a finding means exploit code or exploitation is known to exist, which moves the finding up the fix order. This page stops at what that flag means for priority; it does not point at exploit sources.

What is CWE: the weakness behind the vulnerability

CWE stands for Common Weakness Enumeration, MITRE’s catalog of weakness types. A CVE is one instance of a flaw in one product; a CWE is the class of mistake behind it, so a single CWE covers many CVEs and tells you what kind of fix is needed.

The CWE site calls Common Weakness Enumeration “a community-developed list of common software and hardware weaknesses”, where a weakness is “a condition in a software, firmware, hardware, or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities.” In practice the id names the class. The finding above carries CWE-502, Deserialization of Untrusted Data, and that id tells you to look for every other place your code turns untrusted input back into objects.

That is why a small team should read the CWE line: it says whether the same mistake could sit elsewhere in your own code, and it maps to OWASP categories, which the CWE site lists among its external mappings. The review against those categories is covered in how to test OWASP Top 10 vulnerabilities, and the weakness classes AI coding tools tend to ship are already mapped in a table on the CWE classes behind AI-generated security holes. As for who owns CWE: the site says it “is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE).” MITRE’s CWE site has the full list and search.

Low, medium, high, critical: what the severity levels mean

Low, medium, high and critical are labels for CVSS score ranges, four bands above zero as NVD publishes them. They describe the flaw in the abstract, not the risk to your app: a critical in code you never call matters less than a medium on your login route.

Those vulnerability severity levels come from NVD’s CVSS severity ratings, which also keep the older CVSS v2.0 scale with only Low, Medium and High, so a v2 score never reads as critical. Scanner vendors add criticality levels of their own, such as a numbered scale or an Info or Urgent label. Map each one to the CVSS rating it came from and move on. The level of vulnerability in disaster planning and social science is a different field that uses the same words.

EPSS score, the KEV list and CISA Vulnrichment

An EPSS score is a daily estimate, from 0 to 1, of the probability that a CVE will be exploited in the next 30 days. KEV is CISA’s list of CVEs known to have been exploited in the wild. CVSS says how bad, EPSS says how likely, KEV says it has happened: use all three.

In FIRST’s words, the Exploit Prediction Scoring System “is a data-driven machine-learning model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days”, and FIRST EPSS publishes “a 0–1 probability (with ranking percentiles) every day for every CVE”. The score is the probability; the percentile is where that probability sits among all scored CVEs. FIRST’s own example: a probability of 0.10 “rests at about the 88th percentile”. FIRST also says EPSS is “Not a “severity” score and not a complete risk score”, and that it “does not know what is in your environment, whether an attacker could reach it”. FIRST’s EPSS page has the daily data and the guidance on combining it with CVSS and KEV.

CISA’s Known Exploited Vulnerabilities catalog is the confirmed half. A CVE goes in when three things hold: it has a CVE ID, “There is reliable evidence that the vulnerability has been actively exploited in the wild”, and “There is a clear remediation action for the vulnerability, such as a vendor-provided update.” Each entry has a due date, which binds US federal civilian agencies under Binding Operational Directive 26-04; CISA says other organizations, though not bound, can strengthen their posture by prioritizing the same list. KEV vs CVE, then: every KEV entry is a CVE, and a CVE can become a KEV entry only once there is reliable evidence of exploitation.

CISA Vulnrichment is useful while NVD enrichment lags. CISA’s Vulnrichment repository is “the public repository of CISA’s enrichment of public CVE records”, which adds SSVC decision points to new and recent CVEs, and “some higher-risk CVEs will also receive enrichment of CWE and/or CVSS data points, where possible.” For one CVE in one app, whether the vulnerable code is reachable is a separate worksheet, the kind used for how to detect the Log4j vulnerability.

How to fix in order: the remediation process, the tracker and the policy

My fix order has five tiers: reachable and on the KEV list first, then internet-facing flaws with a high EPSS score or a public exploit, then high and critical findings on code you use, then the rest with routine updates. Unreachable findings are the fifth tier: each is closed in writing, with a reason and a review date.

This vulnerability remediation process is my working rule for a team of two, top to bottom. The due dates are the team’s own policy, not an industry number: NIST’s RA-5 itself leaves remediation to “organization-defined response times” and an organizational assessment of risk.

1. 01 Anything in KEV that is reachable in your app: now.
2. 02 Anything reachable from the internet without login that has a high EPSS score or a public exploit: this week.
3. 03 High and critical findings on code paths you actually use: this month.
4. 04 Everything else: with the next routine dependency update.
5. 05 Not reachable or not applicable: closed with a written reason and a review date.

The fourth tier is where an update bot earns its place; how one works is a separate question: what Renovate bot is. How confirmed a finding should be before it enters this order, a pattern match or a reproduced request, is the evidence ladder in the scanner comparison linked in the external and internal scans section above.

Remediation removes the flaw: upgrade, patch, or delete the dependency. Vulnerability mitigation lowers the risk while the flaw stays: turn the feature off, add a WAF rule, flip a config flag. To mitigate vulnerabilities is a stopgap, so every mitigation gets an expiry date in the tracker. Mitigating vulnerabilities is still a fine answer for the week a patch does not exist yet. Accepting a risk is a decision with a name and a date on it, not an absence of action.

The vulnerability remediation tracker has eight columns, and the last one is the one that proves the fix. The first row below is the example finding from above; the second is a placeholder for the kind of finding a baseline web scan reports.

My vulnerability management policy is one page: the scope; the scan cadence; the fix-order rule with its timelines; who owns triage; how exceptions are approved and when they expire; how fixes are verified; and where the record lives. A customer’s questionnaire asking whether you have a vulnerability management process is asking for that page and a tracker that matches it.

A public case shows what the last column is for. The FTC alleges that Equifax failed to patch its network after being alerted in March 2017 to a critical security vulnerability affecting its ACIS database. According to the FTC’s release, Equifax’s security team “ordered that each of the company’s vulnerable systems be patched within 48 hours after receiving the alert”, but Equifax “did not follow up to ensure the order was carried out by the responsible employees.” The release says Equifax “did not discover that its ACIS database was unpatched until July 2017, when its security team detected suspicious traffic on its network.” The FTC’s release on the Equifax settlement has the rest of the allegations.

The lesson I take from it, which is my reading and not the FTC’s words: an order to patch within 48 hours is a due date, not a fix. The verified-on column gets filled only by evidence that the fix is in, either a rescan that reports the finding resolved or the deployed version checked on each system, and that is the follow-up the release says was missing. A rescan counts only if the scanner tests for that flaw, so when it does not, the version check is the evidence. The release does not say whether Equifax scanned, and I do not claim a tracker would have prevented anything; it would have shown whether the order was carried out.

SANS vulnerability management material includes a maturity model with five levels, from Level 1, Initial, through Managed, Defined and Quantitatively Managed to Level 5, Optimizing, across five focus areas: prepare, identify, analyze, communicate and treat. A small team’s aim, in my reading, is the level where scans run on a schedule and fixes are tracked and verified, not the top of the model. Ranking threats at the design stage, before any scanner runs, is a different exercise: threat modeling.

The vulnerability report: what a scan report and an assessment report contain

A vulnerability assessment report has seven parts: scope and dates, method and tool versions, a summary by severity and status, the findings with evidence and owners, exceptions with reasons, verification after fixes, and the next scan date. A raw scan export is not an assessment report.

Three documents get mixed up. A vulnerability scan report is the raw tool output: every alert, every severity, no judgment. A vulnerability assessment report is the scan plus triage, scoring and a fix plan, written by a person. A VAPT report adds penetration testing on top, and its format is covered in the penetration test report format. A security vulnerability report sent to you by an outside researcher is a fourth thing again, and handling those starts with a security.txt file example.

I use the outline as the vulnerability report template and as a vulnerability assessment template and checklist: copy the table and fill it in. The vulnerability assessment methodology in one line: scope, scan authenticated, confirm each finding against the running app to remove false positives, score, plan, fix, rescan. VAPT tools are the scanners above plus a tester’s intercepting proxy.

In my reading, many downloadable sample reports are infrastructure audits of servers and networks, while a web app’s report is mostly dependencies, headers and configuration; that is what a cyber vulnerability assessment of one SaaS looks like. In my working rule, vulnerability management reporting over time is the same outline repeated per scan, with the open count by tier on the first page so the trend is visible. A vulnerability assessment for a small business can be this small; the example below walks through one.

Can you provide an example of a vulnerability assessment?

A vulnerability assessment example for one small SaaS: three free tools run in an afternoon find a dependency advisory with a fixed version, a missing header from the baseline scan, and a forgotten server with an open port. Each finding gets a reachability call, a tier and a due date from my rule, and the result is a two-page report.

This example of vulnerability assessment is my illustration, not results from a real app. The findings are placeholders of the kinds each tool reports, taken through the six steps of the afternoon below.

Dependabot alerts include “Details about the vulnerability and its severity” and “Information about a fixed version (when available)”. A missing header is the kind of finding I’d expect from the baseline scan’s passive pass. Vulnerability assessment examples from larger companies, in my reading, add more hosts and more tools, not more steps. A security assessment example for a whole company adds policies and people; this one stays with the app.

How to check your own app: one afternoon

A first pass takes six steps: list what you run, turn on dependency alerts, run a baseline web scan against staging, check open ports from outside, put every finding in the tracker under the fix-order rule, then fix the top tier and rescan.

1. 01 List what you run: repositories, hosts, domains and third-party services, on one page.
2. 02 Turn on the dependency alerts your code host offers and read the first page of results.
3. 03 Run a baseline web scan against staging, logged in if the tool allows it.
4. 04 From outside your network, check which ports answer on any server you run.
5. 05 Put every finding in the tracker and apply the fix-order rule.
6. 06 Fix the top tier, rescan, and write the date in the verified-on column.

For step 2 on GitHub, repository administrators and organization owners can enable Dependabot alerts, and the alerts appear on the repository’s Security and quality tab; GitHub’s page on Dependabot alerts has the details. For step 3, ZAP’s baseline scan is the safe first run because it performs no attacks. In my reading, many first-report findings close as not reachable or are fixed by a version bump.

Keep the evidence: the tool versions, the raw output, the tracker and the rescan. If you would rather not open a terminal, the first rung is browser-only: the code host’s security tab and the platform’s advisor, such as Supabase’s Security Advisor in the dashboard. In my reading, step 6 passes when the rescan no longer reports the fixed finding, or reports it as resolved; the wording varies by tool.

This afternoon does not find access control or logic flaws. Those need the audit described earlier and the OWASP review linked above.

Where the sprint fits

In the Production Hardening Sprint, deliverable 3.5, dependency remediation, audits dependencies, upgrades or removes known-vulnerable packages, and removes unused packages. The OWASP Top 10 review, deliverable 3.7, reviews the application against the OWASP Top 10 and records findings, fixes, and evidence by category. Deliverable 3.10 tests the five highest-risk externally reachable attack surfaces, remediates findings, and delivers the methods and evidence. The production readiness report, deliverable 13.1, delivers the result for every scope item, the work completed, and its verification evidence. Formal third-party certifications and independent audit opinions are separate from the sprint deliverables. Hosting, paid tools and API usage remain in the client’s accounts. The full list is in the security deliverables in the published scope.

Common questions about scanners and scores

What are the top 5 CVE vulnerabilities?

There is no standing top five. The useful list is CISA’s Known Exploited Vulnerabilities catalog, which CISA calls “the authoritative source of vulnerabilities that have been exploited in the wild”, and a CVE enters it only with reliable evidence of active exploitation in the wild and a clear remediation action. Filter it by the products in your own stack instead of reading someone’s ranking.

Which is better, OpenVAS or Nessus?

Both are vulnerability scanners you point at hosts on a network, and the answer depends on the license you can use. OpenVAS, in Greenbone’s Community Edition, is released under open-source licenses. Tenable’s free Nessus Essentials is a 30-day license that scans “up to 5 IPs” and is “Not intended for commercial use”; Nessus Professional is the commercial product. For one web app on managed hosting, neither is the first tool to reach for: dependency alerts and a web scanner come first.

What EPSS score is considered high?

FIRST gives no single cutoff and says “There is no universal “right” answer to what the cut off should be”. As a starting point, it says a team that acts on CVSS Critical would match that effort at about the 90th EPSS percentile, a probability of 0.04 or more. My own rule, and it is this page’s rule, not FIRST’s: a score in about the top tenth by percentile on a component reachable from the internet without login goes into this week’s tier.

What does CVE stand for?

CVE stands for Common Vulnerabilities and Exposures. Each CVE ID is a unique identifier for one publicly known vulnerability, assigned and published by organizations that have partnered with the CVE Program.

What are some common CWE examples?

Three from MITRE’s 2025 CWE Top 25: CWE-79, cross-site scripting, ranked first; CWE-89, SQL injection, ranked second; and CWE-862, missing authorization, ranked fourth. The weakness classes behind AI-generated security holes are in the table linked from the CWE section above.

What does CVSS 9.8 mean?

A CVSS base score of 9.8 is Critical, the band from 9.0 to 10.0 in CVSS v3.x and v4.0 as NVD publishes them. In FIRST’s own worked example, the Shellshock flaw in GNU Bash scores 9.8 under CVSS v3.1 because it is reachable over the network, with low complexity, no privileges and no user interaction, and has high impact on confidentiality, integrity and availability. It is a severity, not a risk: FIRST says base scores “should not be used alone to assess risk.”