How the known flaws in components check works

Most websites are built from ready-made parts: script libraries such as jQuery or Bootstrap, and frameworks such as Drupal or Laravel. When a flaw is found in one of them, it is published as a security advisory with the versions it affects and the release that fixes it. This check compares the versions your site shows with those advisories.

What it reads

• The result of the technology check: which libraries and frameworks your site shows, and their versions.
• The open OSV vulnerability database (osv.dev), which collects advisories from GitHub and other sources. For each component with a full version number, we send OSV the component name and version only. Your site's address is never sent.

It makes no requests to your site.

What it reports

• A component version with a published advisory, with the advisory numbers (usually CVE numbers) and the release that fixes them. The finding's severity follows the advisory's own rating (critical, high, moderate or low); when a version has several advisories, the worst one counts. It is Potential, not Confirmed: a site can carry a patched copy under the old version number, and many advisories only apply when the component is used in a particular way.
• Components seen without a version, listed together as Unknown, so you know which parts could not be compared.

If OSV cannot be reached during the scan, the report says so under Unknowns instead of passing silently.

What it cannot see

• Components that leave no public sign, and versions the site hides.
• Server software such as PHP, nginx or Apache. OSV does not track them by version number, so they are covered by the vulnerability wave check for major flaws.
• Whether the flawed function is actually used on your site.

What to do with the result

Ask your developer to update the component to the fixed release or newer, and to test the site afterwards. If they believe your copy is not affected, ask them to say why in writing, so the next report makes sense to you.