After a Vulnerability Scan Report: Triage, Disputing False Positives, and Retesting

Vulnerability scanning and security testing are carried out by qualified third parties. This article covers the work that begins once a report reaches the development side: which findings are real problems, which to fix first, which are false positives that call for a dispute, and what evidence to leave behind so a retest can confirm each fix one by one. NIST SP 800-115 (Scarfone et al., 2008) is a reference for technical security testing and assessment, covering technical tests that find weaknesses in systems and networks. How such tests are performed and judged is the expertise of the testing party. The difference between a vulnerability scan and a penetration test has its own article, so it is not repeated here.

False Positives Are Certain to Appear, and Cannot Be Skipped

Automated scanning judges by signatures, version strings, and response content, and knows little about how a particular system is configured or how its business logic works. The same request can look like an attack to a scanner and be an ordinary form submission inside the system. False positives in a report are hard to avoid entirely.

That does not make false positives safe to skip. Sadowski et al., 2018 summarize what Google learned building static analysis tools: false positives make users distrust the analysis, and for checks run during code review the criterion is an effective false-positive rate below 10%. Johnson et al., 2013 interviewed developers and found that the way false positives and warnings are presented is one of the main reasons developers do not use static analysis tools. Both studies concern static analysis tools rather than vulnerability scan reports, but the way false positives wear down trust carries over: when a report mixes in unresolved false positives, the credibility of the remaining findings is discounted as well.

So each false positive is handled individually: confirm it is one, write down the reason, and assemble it into a dispute instead of passing over it. The POLISH Engineering Team's work on a Ministry of Education project included working alongside the scans the competent authority required, fixing medium- and high-risk findings, and handling false-positive disputes.

Separating Real Problems from False Positives

For every finding, the development side has to answer three questions: does this problem actually exist on this system, what does exploiting it require, and how will the fix be shown to work. Classification means finding those three answers for each finding. The classification result and the content of any dispute are confirmed by the system owner before work moves on.

1. Reproduce: replay the request the report describes in a test environment and compare the response with the report.
2. Match: check that the version, path, and header the report names belong to this system, and not to a front-end proxy, an old service, or another host.
3. Preconditions: confirm whether exploiting the finding requires a login, a specific permission, or access from the internal network only.
4. Verdict: label each finding as a real problem, a false positive, or undetermined, and write down the reason; for undetermined ones, go back to the party that issued the report and ask for more information.

Order Fixes by Exploitability, Not by Score

The severity score on a report is where ordering starts, not where it ends. Two findings rated medium can differ a great deal in how hard each is to exploit when one sits on a public login page and the other on an admin interface reachable only from the internal network. OWASP Top 10, 2025 is a list of the most serious web application security risks compiled by expert consensus, and the 2025 edition is the current one. Which risk category a finding falls under can be checked against that list first, followed by the actual conditions on this system.

Once the order is set, each finding ends up on one of three paths: fix immediately, schedule for the next round, or file a dispute.

A Fix Is Not an Installed Package

When a batch of security fixes adds header protections and a global input-sanitizing package on the same day, the sanitizing and related settings tend to be switched off soon after: global sanitizing rewrites what users submit and collides with ordinary content such as rich text.

This pattern shows that a fix has to address the cause of the problem rather than add a component that looks protective. The POLISH Engineering Team leans toward output encoding, a content security policy, and explicit allowlists: content is encoded for its position at the moment it enters the page, a policy limits which sources the browser may execute, and acceptable input is defined by allowlist rather than rewritten wholesale afterward.

Password Rules Land Clause by Clause, and the Easily Missed Path Is the Other Login

On a checklist, each password clause is easy enough to implement: length, character rules, rotation period, and no reuse of the account name or earlier passwords. When password rules roll out in batches, what slips through is not the clause itself but another login path: ordinary login receives the initial-password check first, and if third-party login does not get the same check, the rules are only half in place.

• Registration and password change
• Initial-password and rotation checks at ordinary login
• Third-party login
• The password reset flow
• Rules on both the admin interface and the API
• The rule description text on the front end

The approach is a checklist that maps every rule to every login path instead of changing only the registration page. The back end's check is authoritative, and the front end's hints are updated to match, so both sides describe the same rules.

Turning Off the Back End Does Not Mean the Front End Has Stopped Depending on It

A CAPTCHA answer must never travel from the server back to the browser. If a report shows that a response carries the CAPTCHA value, the fix has to finish on both ends at once: the back end stops sending it and the front end stops reading it. Switching off only the back end while the front end still reads the field leaves the problem half fixed.

Confirming a clean fix means looking from both ends. On the back end, check that the response no longer contains the field. On the front end, check that the code no longer reads it and that screens and flows still work once the field is gone. Only when both ends are confirmed can the finding be marked fixed.

Settle the Scope Boundary Before Work Begins

A report may cover systems with years of older code. This round fixes the findings the report lists and classification has confirmed. Other existing problems in the old system are recorded on a list rather than rebuilt on the side, but newly written code must not add any new risk. This rule belongs in a document before work begins, confirmed by the system owner and the development team together: which findings this round covers, which existing problems are only recorded and left unchanged, and what rules new code follows. Without it, scope drifts outward during the repair and every change has to be argued again. At a minimum, newly written code holds to the following:

• Database queries are always parameterized
• Access to personal data includes the owner in the query condition, for example matching both the record ID and the user ID
• Callbacks from external systems are always signature-verified
• Secrets stay out of version control, and logs and status messages never print the original value; only a hash is compared or a length is shown

What Evidence a Retest Needs

For outsourced public-sector projects, the law makes selecting and supervising the contractor the agency's responsibility. Article 10 of the Cyber Security Management Act, 2025 requires government agencies and designated non-government agencies, when outsourcing the building or operation of information systems or services, to select suitable vendors, require each vendor to maintain effective security management, supervise the vendor, and set out rights, obligations, and liability for breach in a written contract. Article 7 of the Enforcement Rules of the Cyber Security Management Act, 2026 provides that selecting and supervising a contractor should consider staffing, subcontracting, security testing of customized systems, incident reporting, and data handling when a contract ends, and that the contractor must be audited periodically or when an incident comes to light.

For the contractor, this means each repair decision may later need to be explained. Maintenance evidence for public-sector projects is covered in its own article; for a vulnerability scan report, every finding needs evidence that lines up with it before the retest.

The retest is performed by a qualified third party. The development side's job is to make sure every finding has evidence to match. Fixes can be checked against OWASP ASVS, 2025, a list of application security verification requirements that developers use as a reference while building, coding, and testing web applications and services. When every fix is checked against the same list, no two fixes are judged by different standards.

When This Approach Does Not Fit

• No scan or test report exists yet. This article starts after the report arrives; scanning and testing must first be done by a qualified third party.
• The goal is to overhaul the whole old system at once. The approach here keeps the report's findings separate from existing problems, and it is not a rewrite plan.
• The only demand is that the score on the report drop to some level, without addressing real risk. Ordering follows exploitability, not score.

What to Prepare Before Contacting POLISH

• The full report, including each finding's identifier, severity, and the affected address or component
• The scope and environment of the scan, meaning whether it targeted production or a test site
• A summary of the system's technical architecture and who currently maintains it
• The parts of the old system known to be left alone for now, and any contract or agency requirements on repair scope
• The reply deadline, and who will run the retest and when

With those in hand, contact the POLISH Engineering Team and describe where the report came from and how far the handling has progressed. Repair and dispute work taken on by the development team falls under system maintenance and repair; scanning and retesting remain with a qualified third party.