452 scanner findings and six criticals: which ones can actually hurt you?
For CTOs and security leads who receive scanner reports and have to decide what to fix first.
A source-only scan of a group of JavaScript and TypeScript applications produced 452 findings. We checked, critical by critical, whether the vulnerable code was actually used.
- SaaS
- JavaScript and TypeScript web applications
- Money
- Compliance
- Reputation
- Clients
What was at risk
Engineering weeks spent on the label
One ticket per advisory would have been 166 tickets, closed by about a dozen version bumps. Time goes to the scanner's severity, not to the risk.
A list you cannot defend
Context: customer security questionnaires and ISO 27001 or SOC 2 audits ask how vulnerabilities are triaged. A flat list of 452 cannot answer that. A reachability decision per critical can.
A credential in the history
A personal access token was committed in a tracked configuration file and sat in six commits of history. It needed rotating.
A fix that did not reach the build
Two lockfiles disagreed, and the one CI installs from was the vulnerable one. The upgrade on paper was not the upgrade in the build.
Standards and rules in play
- Triage rule: is the vulnerable code used?Severity on a scanner list describes the advisory in general. Each critical was checked against the client's source: is the vulnerable feature in use?
- Evidence labelsWhat could not be verified is said so: the build-time shell-quoting library was downgraded from critical to medium and labelled unverified.
Context: ISO 27001 and SOC 2 both expect a vulnerability-management process.
How we tested it
- Test level
- Static review of the source code and dependency manifests of a group of repositories.
- Test types
- Security testing, white-box.
- Test basis
- The output of four scanners (dependency, secrets over full history, static analysis and a fourth) and the client's own source.
- How we workedStatic analysisWhere it showed upFour scanners produced 452 findings: 6 critical, 183 high, 191 medium, 27 low and 41 with no rating.
- How we workedCode reviewWhere it showed upReachability: for each critical we searched the source for the vulnerable feature: zero occurrences of a route-matching helper across 1,516 TypeScript files, OAuth plugins not enabled, raw-SQL helpers absent from all three repositories. Each negative came with a search that passed a negative control.
Terms as in the ISTQB CTFL 4.0.1 syllabus and glossary.
What we found, and what it costs
- FindingRuled outTwo of the four distinct critical advisories are not reachable in the client's codeWhat it costs youNo work spent on code that cannot be attacked, and the reason is written down.
- FindingOpenA request-validation framework flaw, counted three times, could not be ruled outWhat it costs youIt is a direct dependency with validation always on, so it became a ticket to upgrade, not an assumption.
- FindingFoundA committed access token in six commits of history, liveness not testedWhat it costs youA credential in history needs rotating whether or not it still works.
- FindingFoundThe lockfile CI installs from is the vulnerable oneWhat it costs youA fix applied to the wrong lockfile fixes nothing in the build.
Of 32 secrets hits, 29 were false positives, each disproved individually.
What changed
452 findings became 11 tickets, ordered by reachability and grouped by the package to upgrade. 373 dependency findings collapsed to 166 advisories across 38 packages.
Want a scan turned into a list you can act on?
We check reachability, say what we could not rule out and group findings by the work they need. The first month is a trial.
