Get started

This page takes you from nothing to an inventory of the libraries your visitors load, with the vulnerable ones reviewed and an alert waiting for the next advisory.

Before you begin

Make sure you have:

• A plan that includes Technologies. Compare plans on the pricing page.
• 'report-sha256' in your script-src. Without it browsers send no hash reports and the page stays empty. The CSP hashes page, where CSP stands for Content Security Policy, must already show data.
• Website role Manager to add alert rules. Reading the inventory needs no particular role.

1. Confirm hash reports arrive

For the website, go to Reports > CSP hashes. If the origins table has rows, browsers are reporting script hashes and you can move on.

If it is empty, add the keyword to the script directive of the policy you already send. It reports, it does not block, so it is safe in an enforced policy.

Content-Security-Policy: script-src 'self' 'report-sha256'; report-to default

For the full header set, refer to Connect your site.

2. Open Technologies

In the website sidebar, select Technologies. The first rows appear a short while after the first hash reports, as CentralCSP analyzes each newly reported script. The page fills at the pace real visitors load your pages, since there is no crawler.

The table sorts by severity, so vulnerable libraries are listed first. Each row is one library version, with its status, its vulnerability count, and how many script files carry it.

If the page shows Inventory paused for today, the site sent more new scripts than CentralCSP analyzes in a day. Nothing is lost. The rest is analyzed tomorrow. Refer to The daily analysis cap.

3. Review the vulnerable rows

Set the vulnerability filter to Vulnerable only. Work through the list in order.

For each row, select it to open the drawer, then review it in this order:

1. Read the Vulnerabilities list. Each advisory carries its Common Vulnerabilities and Exposures (CVE) IDs, severity, a one-line summary, the affected version range, and links to read more.
2. To see which URL loads the library, check the Scripts list. That tells you whether it is your bundle, a CDN copy, or a third-party tag.
3. Decide: upgrade to a version outside the affected range, remove the script, or accept the risk in writing if the vulnerable code path cannot be reached.

Then switch the status filter to Outdated and Deprecated and plan those upgrades. A deprecated library will not receive a fix for the next advisory.

Refer to Review a technology for each part of the drawer.

4. Add the two alert rules

Go to Alerts > Configuration > Add rule. In the event list, select the Technologies group. Add these two rules:

• New vulnerability: Fires when an advisory is published for a version already on the site, or when a vulnerable version is first detected. Leave Minimum severity at Medium unless Low-severity findings also need a notification.
• Outdated or deprecated version: Fires when a technology is detected with, or moves to, one of the statuses you select.

Point both at a channel the person who patches reads. The rule looks forward only, so it does not notify you about what is already in the inventory. You reviewed that in step 3.

Refer to Tune a technology rule for cooldown and channel choices.

What you have now

The inventory lists what your visitors' browsers load, the vulnerable rows have a decision, and the next advisory reaches a person without anyone checking the page.

The library set changes as you deploy and as vendors update their tags. A technology drops out seven days after browsers stop reporting its scripts. A new one shows up the same way the first ones did.

Next steps

• Review a technology
• Rules
• Script inventory for the PCI DSS (Payment Card Industry Data Security Standard) review of payment-page scripts