← All posts

What a technology checker is for, from security ratings to PCI scans

CentralCSP Team ·

Last update:

A security rating drops, an Approved Scanning Vendor (ASV) scan fails, or a customer's security questionnaire asks which third-party components your site runs. Behind each of these sits the same question: which JavaScript libraries does this page load, which versions, and which of those versions have known vulnerabilities. A technology checker answers it from a URL, and the answer is the starting point for the fix, the evidence, or the reply.

This post covers what the Technology Checker returns, then the problems it helps with, one per section, and ends with where a one-off check stops being enough.

What a technology checker returns

Enter a page address and the checker lists the technologies that page uses, with a focus on JavaScript libraries and frameworks. For each one you get:

  • The version in use, or a dash when no version could be read.
  • The version status: up to date, outdated, dormant (no release for a long time), or end of life (the line no longer receives fixes).
  • The latest release in the same line, which is the smallest upgrade that helps.
  • The highest severity among the known vulnerabilities affecting that version.
  • Where it was detected on the page.
  • Each known vulnerability: its CVE id (linked to the National Vulnerability Database), severity, a summary, the version that fixes it, and the advisory links.

You can export the result as a CycloneDX 1.6 SBOM, a CSV, or a dated PDF. The check is free, needs no account, and results are not saved.

One honest limit before the use cases: a check reads one page, once. It is not a crawl of the whole site, and it sees the scripts that page loads at that moment. For a method comparison and the manual ways to check, see What technology is this website using, and is any of it outdated.

Clear outdated library findings in a security rating

External rating platforms scan your public sites and grade what they see, and an outdated JavaScript library is one of the things they flag.

  • BitSight checks JavaScript libraries in its Web Application Security risk vector, under the "Components with Known Vulnerabilities" assessment, and publishes the list of library vulnerabilities it currently checks. How fast you remediate critical vulnerabilities is graded separately, in the risk vector BitSight renamed from Patching Cadence to Critical Vulnerability Management in July 2026.
  • SecurityScorecard raises "Potential Vulnerability Detected" under its Application Security factor when it matches a product to a CVE but cannot pin the version. Once it reads a vulnerable version, the finding moves to its Patching Cadence factor, which expects a fix within 30 days of NVD publication for a critical CVE, 45 for high, 90 for medium, and 120 for low.
  • UpGuard lists published vulnerabilities in the software it identifies from HTTP headers and website content.

The workflow is the same whichever rating you watch:

  1. Run the page the finding names through the checker and find the library and version it flags.
  2. Read the "Detected in" list to see which file carries it: your own bundle, a plugin path, or a vendor's host. Each has a different owner.
  3. Upgrade to the fixed version shown, or remove the copy if nothing uses it.
  4. Check the page again to confirm the new version is the one served, then ask the rating platform to rescan.

Two caveats. Each platform uses its own detection and timing, so a clean check does not guarantee the finding clears on their side. And SecurityScorecard keeps Patching Cadence findings on the scorecard for a period after the last observation, by design: they record how fast you patched, not only whether you did. Fixing early is what shortens that window. For the Content Security Policy (CSP) findings on the same ratings, see how to fix SecurityScorecard CSP findings and how to fix BitSight CSP findings.

Pre-check a PCI ASV scan

PCI DSS requires a quarterly external vulnerability scan by an Approved Scanning Vendor for many merchants. Under the ASV Program Guide, any component with a vulnerability scored CVSS 4.0 or higher fails the scan unless you remediate it or the ASV accepts a dispute. The common jQuery advisories score 6.1 on NVD, so a page loading an old jQuery is a typical failure.

Running the checker on your payment and login pages a few days before the scan tells you which library versions are likely to be flagged, which copy carries each one, and what to upgrade to. It is a pre-check, not an ASV scan: only an ASV listed by the PCI Security Standards Council produces a passing scan report. The full fix, including when a dispute is legitimate, is in Fix an outdated jQuery or other JavaScript library that fails your PCI ASV scan.

Answer vendor security questionnaires

Customer security reviews often ask whether you keep an inventory of the third-party components your site runs and how you track vulnerabilities in them. PCI DSS v4 requirement 6.3.2 asks for the same kind of inventory, covering the third-party components in your bespoke and custom software. A dated export answers the question with evidence instead of a sentence:

  • The CycloneDX file goes to a reviewer or a tool that reads SBOMs.
  • The PDF goes to a reviewer who wants a document.
  • The CSV goes into your own tracker or the questionnaire's attachment.

It works the other way round too. When you assess a supplier, run their public pages through the checker before the call. An end-of-life framework on a vendor's login page is a concrete question to ask, and a better one than a yes/no checkbox.

Triage a pentest or scanner finding

A pentest report or a scanner says "vulnerable version of the library jQuery found" and names one URL. The checker tells you, for that page, which copies load and which advisories apply to each version, so the ticket goes to the right owner with the right target version.

For jQuery specifically, the version table and the fix sequence are in Which jQuery versions are vulnerable. For finding every copy across a whole site, see How to detect vulnerable JavaScript libraries on a live website.

Get a client-side SBOM in one click

Your build pipeline produces an SBOM of what is in the repository. It does not list the tag manager's payload, the chat widget, or the analytics snippet, because those never pass through the build. The checker's CycloneDX export lists what one page actually loads in the browser, including those scripts, with versions and known vulnerabilities. For a continuously updated client-side SBOM of every page, see Technologies in the documentation.

When a one-off check is not enough

Every use case above has the same weak point: the check is a snapshot of one page. Ratings and ASV scans run again, a plugin update can bring an old library back, and a new CVE can land on a version that was clean last week. That is where the timing of Patching Cadence findings hurts most.

CentralCSP covers that continuously. The browsers of your real visitors report the scripts they run, and the platform keeps an inventory of every library version across every page, with an alert when a new advisory affects one of them. The supply-chain page has the tour, and you can start free with CentralCSP on your own site.

FAQ

Is the Technology Checker an ASV scan?

No. An ASV scan is performed by an Approved Scanning Vendor listed by the PCI Security Standards Council, and only that scan counts for PCI DSS. The checker is a free pre-check that shows which library versions on a page carry known vulnerabilities, so you can fix them before the ASV scan runs.

Will fixing what the checker finds raise my security rating?

It removes the cause of an outdated-library finding, but no one outside the rating platform can promise a score. Each platform has its own detection, weighting, and timing, and some findings stay visible for a period after you fix them.

Can I check a website that is not mine?

Only check sites you own or are authorised to assess, such as a supplier under a review agreement. The checker reads the same public resources a browser downloads when it opens the page, and nothing else.

Does the checker scan the whole website?

No. Each check reads one page and the scripts it loads at that moment. Check the pages that matter (payment, login, sign-up), or use continuous monitoring for full coverage.

Sources