# Overview (/en/docs/platform/features/technologies)



Technologies lists every JavaScript library your visitors' browsers load on a website. Each library carries its version, whether that version is still current, and the [Common Vulnerabilities and Exposures (CVE)](https://www.cve.org/) entries that affect it. It is a client-side software bill of materials (SBOM): the list of libraries and versions that actually execute in your visitors' browsers, built from what real browsers report rather than from the packages in your build.

The page lives under each website as **Technologies**. Every website role can read it.

<Callout type="info">
  Technologies is included in the Scale and Enterprise plans. On other plans the sidebar entry is disabled. Compare plans on the [pricing page](/pricing) or under **Settings** > **Billing**.
</Callout>

## What it answers [#what-it-answers]

Open the page when you need one of these answers:

* Which libraries run on this site, and which version of each.
* Which of them ship a known vulnerability, and how severe it is.
* Which are outdated, dormant, or no longer maintained.
* Which script files carry each library, and from which URL.
* When a library appeared, changed status, or gained a new advisory.

The [Get started](/en/docs/platform/features/technologies/get-started) page takes you from an empty page to a reviewed inventory with alerts.

## Where the data comes from [#where-the-data-comes-from]

Browsers report a hash of every script they execute when your Content Security Policy (CSP) carries [`'report-sha256'`](/en/docs/web-security/policies/content-security-policy/values/report-sha-keyword). For each reported script, the CentralCSP engine identifies the technology, its version, its lifecycle status, and the known CVEs that affect it.

The inventory is what browsers loaded, so it includes third-party tags, CDN copies, and scripts injected by a tag manager that [a source-tree scan never lists](/en/blog/detect-vulnerable-javascript-libraries). Two things follow from that, and one limit:

* A library appears a short while after its script is first reported. There is no crawler to schedule, no agent to install, and no repository to connect.
* CentralCSP re-checks known technologies regularly, so a newly published advisory or a status change shows up on its own.
* Only scripts loaded from a URL are analyzed. Inline scripts are not part of the inventory.

The same [`csp-hash`](/en/docs/web-security/reporting-api/reports/csp-hash) reports feed the [CSP hashes](/en/docs/platform/monitoring/script-hash) page and the PCI DSS (Payment Card Industry Data Security Standard) [script inventory](/en/docs/platform/features/script-inventory). Technologies adds the library, version, and vulnerability layer on top.

{/* SCREENSHOT
  file: ../../../../img/technologies/technologies-list.webp
  alt: The Technologies page with the four summary cards and the inventory table, the most severe library first
  route: /<workspaceId>/websites/<websiteId>/technologies
  state: A site with a dozen technologies, at least one Critical and one Outdated row, no filter applied
  shows: The summary strip, the filters, and one row per library version
  care: Use demo data, no real customer hostnames
  */}

## What a row holds [#what-a-row-holds]

The inventory has one row per library version, so two versions of the same library are two rows. Each row has these columns:

| Column              | Meaning                                                                                  |
| ------------------- | ---------------------------------------------------------------------------------------- |
| **Technology**      | The name and icon of the library                                                         |
| **Version**         | The version the engine identified, or `Unknown` when only the library was recognized     |
| **Status**          | Where that version sits in the lifecycle of the library                                  |
| **Vulnerabilities** | How many advisories affect this version, with the highest severity among them, or `None` |
| **Scripts**         | How many distinct script files on the site carry this version                            |
| **First seen**      | When a script carrying this version was first reported                                   |
| **Last seen**       | When one was last reported                                                               |

The status values are described in [Version statuses](#version-statuses).

The four summary cards summarize the table: technologies detected, technologies with at least one known vulnerability, technologies that are outdated or deprecated, and the number of distinct scripts matched to a library.

Selecting a row opens the technology drawer with its advisories, its scripts, and its history. Refer to [Review a technology](/en/docs/platform/features/technologies/review).

## Version statuses [#version-statuses]

Every row carries one lifecycle status. The status describes the version you run, not the library as a whole. Each status means the following:

| Status         | Meaning                                                 | What to do                                                   |
| -------------- | ------------------------------------------------------- | ------------------------------------------------------------ |
| **Up to date** | The version is the current release                      | Nothing                                                      |
| **Outdated**   | A newer release exists                                  | Plan the upgrade, sooner if the row is also vulnerable       |
| **Dormant**    | The library has not published a release for a long time | Check whether it is still maintained before you depend on it |
| **Deprecated** | The library is no longer maintained                     | Replace it                                                   |
| **Unknown**    | The library was recognized, the version was not         | Check the script yourself                                    |

A deprecated library gets no fix for its next advisory, which is why the answer is replacement rather than an upgrade. An unknown version cannot be matched against advisories, because vulnerability matching needs a version to compare.

The **Outdated or deprecated** card counts the two statuses that call for action. Dormant is a warning sign rather than a finding, and Unknown means the analysis could not go further.

## Severity [#severity]

Each advisory carries a severity band: **Low**, **Medium**, **High**, or **Critical**. The severity of a technology is the highest among the advisories that affect its version, and the table sorts by it, so the row that matters most is the first one.

An advisory with no severity assigned still counts as a vulnerability. It shows as `No severity` in the drawer and does not raise the severity of the row.

## How long a technology stays listed [#how-long-a-technology-stays-listed]

A technology stays in the inventory as long as browsers keep reporting a script that carries it. When no script carrying a version has been reported for seven days, the version leaves the inventory. Its history stays, so a library that returns after a deployment rollback is listed as detected again with its earlier entries still attached.

## The daily analysis cap [#the-daily-analysis-cap]

Each website can send a limited number of new, never-seen scripts for analysis per day. A site that serves thousands of distinct script files in one day, for example a build that gives every user a unique bundle URL, hits that cap. The page then shows **Inventory paused for today**. Libraries already recognized keep being tracked. Scripts over the cap are analyzed the next day.

If the banner appears every day, the script URLs of the site change on every request. Stabilize the URLs, or accept that the inventory covers the stable subset.

## Use it from the API and MCP [#use-it-from-the-api-and-mcp]

Everything on the page is available on the REST API under the `technologies` resource of the website: the list with the same filters, the summary counters, the CSV export, one technology with its advisories and scripts, and its history. Refer to the [API reference](/en/docs/api-mcp/api).

The [Model Context Protocol (MCP) server](/en/docs/api-mcp/mcp) exposes the list as the read-only `list_technologies` tool, so an AI client can answer "which libraries on this site have a critical CVE" from the same data.

## Next steps [#next-steps]

* [Get started](/en/docs/platform/features/technologies/get-started)
* [Review a technology](/en/docs/platform/features/technologies/review)
* [Alert rules](/en/docs/platform/features/alerting/rules)
* [CSP hash report reference](/en/docs/web-security/reporting-api/reports/csp-hash)