# Review a technology (/en/docs/platform/features/technologies/review)



The Technologies page is a table with filters, and a drawer per row. This page covers each part, from narrowing the list to deciding what to do with a finding.

## Filter the inventory [#filter-the-inventory]

The toolbar holds a search box and three filters:

| Control                                  | What it does                                                                         |
| ---------------------------------------- | ------------------------------------------------------------------------------------ |
| **Search**                               | Matches part of a library name                                                       |
| **Filter by status**                     | Keeps one or more statuses: Up to date, Outdated, Dormant, Deprecated, Unknown       |
| **Minimum severity**                     | Keeps technologies whose highest severity is at least Low, Medium, High, or Critical |
| **Vulnerable only** / **Not vulnerable** | Keeps only technologies with, or only technologies without, a known vulnerability    |

The filters combine, and the URL carries them, so a filtered view can be shared as a link. The table orders rows most severe first, then vulnerable before clean, then by name. Two views cover most of the work:

* **Vulnerable only** with **Minimum severity** at High is the patch list.
* **Filter by status** at Outdated and Deprecated is the upgrade backlog.

With the list narrowed, select a row to open it.

## Open a technology [#open-a-technology]

Select a row to open the drawer, the panel that holds everything known about that library version. The header shows the library, the version, and the status label. Four sections follow: **Overview**, **Vulnerabilities**, **Scripts**, and **History**.

<!-- SCREENSHOT
file: ../../../../img/technologies/technology-drawer.webp
alt: The technology drawer open on the Vulnerabilities section, showing two advisories with their CVE IDs, severity, and affected range
route: /<workspaceId>/websites/<websiteId>/technologies
state: A vulnerable, outdated library selected, Vulnerabilities section active
shows: What an advisory entry looks like
care: Use demo data
-->

**Overview** repeats the row plus the website of the library, so you can jump to its release notes.

## Read an advisory [#read-an-advisory]

Each entry in **Vulnerabilities** is one advisory affecting the version you run. Read it in this order:

1. Check the severity label, or `No severity` when the source assigned none.
2. Note the Common Vulnerabilities and Exposures (CVE) IDs. An advisory with no CVE shows `No CVE assigned`, and it is still a published vulnerability.
3. Read the one-line summary of what the flaw allows.
4. Check **Affected versions**, a range such as `From 1.2.0 below 3.5.0`, with any excluded versions listed. The first version at or after the range is the one to upgrade to.
5. Follow **Weakness**, the [Common Weakness Enumeration (CWE)](https://cwe.mitre.org/) class, linked to its definition.
6. Open **Read more** for the pages of the advisory itself.

An empty list reads `No known vulnerabilities`. It means no advisory in the vulnerability sources CentralCSP tracks covers this version, not that the version has been audited.

## Find which script carries it [#find-which-script-carries-it]

**Scripts** lists every script file on the website that carries this version, most recently seen first, with its URL, its hash as browsers reported it, its size, and first and last seen.

The URL is the answer to "where does this come from", and each case has a different owner:

* Your own origin means your bundle or a vendored copy.
* A CDN host means a script tag pointing at it.
* A tag manager or vendor host means a third party ships the library to your visitors.

The fix goes to that owner. The hash is the same value shown on the [CSP hashes](/en/docs/platform/monitoring/script-hash) page, where CSP stands for Content Security Policy, and in the PCI DSS (Payment Card Industry Data Security Standard) [script inventory](/en/docs/platform/features/script-inventory), so you can cross-reference the script there.

When browsers no longer load a version, the list reads `No script carries this version anymore` and the row leaves the inventory after seven days.

## Follow the history [#follow-the-history]

**History** is a timeline of what changed for this version on this website, newest first:

| Entry                 | Meaning                                                                        |
| --------------------- | ------------------------------------------------------------------------------ |
| **Detected**          | A script carrying this version was first reported                              |
| **New vulnerability** | A source published an advisory for this version, with the CVE IDs and severity |
| **Status changed**    | The lifecycle status moved, for example from Up to date to Outdated            |
| **Removed**           | No script carried this version anymore                                         |

The history outlives the row, so a library that comes back after a rollback keeps its earlier entries.

Use it to answer "when did this become a problem". A **New vulnerability** entry dated after **Detected** means the advisory appeared after the library was already in production, which is the case the [New vulnerability alert rule](/en/docs/platform/features/alerting/rules#tune-a-technology-rule) exists for.

## Act on a finding [#act-on-a-finding]

The page records what runs. It does not change your site. What to do depends on the row:

* **Vulnerable and Outdated**: Upgrade past the affected range. The range in the advisory tells you the first safe version.
* **Vulnerable and Up to date**: No fix has shipped yet. Check whether the vulnerable code path applies to how you use the library, and watch the history for a status change.
* **Deprecated**: Replace the library. Its next advisory will not get a fix.
* **Unknown version**: Open the script URL and check the version yourself. Vulnerability matching needs a version to compare against.
* **A third-party script**: Contact the vendor, or remove the tag until they update it.

For a worked example of a library that arrives through several of these routes at once, refer to [Which jQuery versions are vulnerable](/en/blog/vulnerable-jquery-version).

If the script also runs on a payment page, record the decision as described in [Justifying scripts](/en/docs/platform/features/pci-dss/justifying-scripts), which is where your assessor reads it.

## Export the inventory to CSV [#export-the-inventory-to-csv]

To download the current view as CSV, select **Export** in the toolbar. The export honors the filters and has no row limit. The file is named after the website and the day, and it has these columns:

* Library name and version
* Status
* Whether it is vulnerable
* Number of advisories
* Highest severity
* Number of scripts
* First seen and last seen
* URL of the most recently seen script

A filtered export is the useful one: **Vulnerable only** gives the patch list to hand to the team that owns the site. The same export, and the list behind it, are available on the [REST API](/en/docs/api-mcp/api) for anything scheduled.

## Next steps [#next-steps]

* [Get started](/en/docs/platform/features/technologies/get-started) for the initial review order and the two alert rules
* [Rules](/en/docs/platform/features/alerting/rules) to be notified of the next advisory
* [CSP hashes](/en/docs/platform/monitoring/script-hash) for the raw hash reports
* [Technologies overview](/en/docs/platform/features/technologies) for the statuses and the daily cap