VulnBeacon
Request access

Know what affects your software. Decide what to fix and ship.

VulnBeacon is a software supply-chain security and vulnerability intelligence platform for the product-security and engineering teams responsible for the software their organisation builds and receives from suppliers. It connects the inventory your tools already produce to the security decisions your team has to make. Start with an SBOM, a supported lockfile or scanner output.

Request access Explore capabilities

Use the web workspace, connect your pipeline, or ask your AI assistant.

  1. You

    Create the SBOM of the project I am working on and check it with VulnBeacon. Can I ship it?

  2. Assistant

    This SBOM passes the release policy configured for Checkout service. Worth doing next: upgrade Django 5.2.13 to 5.2.17, which clears 15 findings.

    • UpgradeDjango 5.2.13 → 5.2.17clears 15
    • Upgradeurllib3 2.2.1 → 2.8.0clears 9
    • Upgradesqlparse 0.5.3 → 0.6.0clears 6
  3. How the assistant answered4 calls, 6.0 s

    1. cyclonedx-py requirements requirements.txt --of JSON -o sbom.cdx.json

      Generated sbom.cdx.json with cyclonedx-py from requirements.txt: 26 components.

      2.1 s

    2. upload_sbom product_id: 1, sbom: sbom.cdx.json, branch: main

      Uploaded as generation 1: 26 components, the scan queued.

      144 ms

    3. product_gate product_id: 1

      Passed: assessed, no rule broken.

      280 ms

    4. product_remediation product_id: 1

      8 components to act on. Django 5.2.13 to 5.2.17 clears 15 findings.

      131 ms

Gate passed

Recorded on an example project, a Django checkout service of 26 components: the assistant made its SBOM, uploaded it and read the verdict. Every line is the product's answer.

What you can do with it

Already use a scanner? Your scanner produces the inventory. VulnBeacon connects it to updated intelligence, identifies affected products, prioritises the work, tracks remediation, and produces the evidence behind your release decision.

Explore a sample product assessment: one fictional product from its inventory to its report, with the files to open.

One incident, start to finish

  1. A vulnerability is announced
  2. Find the affected products
  3. Choose the fix
  4. Track the work
  5. Re-check the release
  6. Share the evidence

When something new lands, know what it touches

A vulnerability makes the news, or a package turns out to be malicious. Ask one question of everything you ship, and get the answer from your own inventories.

An incident, across every product

Give VulnBeacon a CVE or any of its aliases, a package name or a purl. It answers which of your products ship it, which component at which version, whether the record is on the KEV catalogue and whether a fix exists. A record’s page lists your affected products too, and the API and the assistant give the same answer.

Your software stays the same. Its known risks do not.

When the record changes, the inventories you already uploaded are matched again, and again every night. A new finding appears without a new build, its deadline counted from the day it was first seen.

  1. You

    CVE-2026-67320 is in the news. Which of our products ship it?

  2. Assistant

    3 of your 11 products ship CVE-2026-67320: Patient Portal (axios 1.16.0, fixed in 1.18.0), Atlas Storefront (axios 1.16.0, fixed in 1.18.0) and Platform Worker Image (axios 0.32.0, fixed in 0.33.0). A fixed version exists for 3 of them.

    • Patient Portalhighaxios 1.16.0fix available
    • Atlas Storefronthighaxios 1.16.0fix available
    • Platform Worker Imagehighaxios 0.32.0fix available
  3. How the assistant answered1 call, 97 ms

    1. incident_impact cve_id: CVE-2026-67320

      3 of 11 products affected, 3 with a fix available.

      97 ms

Recorded on example products: one question, asked of all of them, answered from their inventories.

Where the risk sits across your products

The Products page ranks everything you ship, worst first: its grade, its open findings, anything exploited or malicious, its release gate and what moved this week. It prints as a report for the people who were not in the room.

The Products page: every product ranked worst first, with severity and grade distributions above, and for each product its grade, open findings, KEV or malicious flag, release gate result and movement this week.
Products: every product worst first, with what is blocked and what moved this week.

Your watch list

Name the products and packages you care about. A new record that names them, a fixed version, a listing on the KEV catalogue: each one reaches you at the cadence you choose, in the application, by e-mail or through your integrations. The record itself is updated as your administrator schedules it.

The Watch list: the names watched, the records matching them, those on the KEV catalogue, and what changed for them, newest first.
The watch list: the names you follow, and what changed for them.
The Alerts screen: new findings, record changes and policy events, each with its product, severity and time.
Alerts: what changed for your products, in one place.

One upload, the release decision end to end

Upload a CycloneDX or SPDX SBOM, a supported lockfile, a component CSV or what Syft, Trivy or Grype produced, or let the pipeline send it. Everything below is computed from that one file and the record, and every figure opens to the facts behind it. When a document declares cryptographic assets, services or AI models, those are inspected too. The products on these screens are demonstration products on our own instance; the record and its figures are real.

A grade, with its reasons

Each product gets a letter from A to F. It weighs what the findings are, not how many there are: a finding already exploited in the wild and a malicious package in the inventory pull the grade down hardest. The letter opens to the list of what moved it, and every finding carries its SLA deadline and its fixed version.

The Findings stage of a product blocked at the release gate: the SLA ageing strip, then each finding with its severity, record, EPSS, component, fixed version and status, the malicious packages first.
The findings of a blocked product, the malicious packages first.

From a list of findings to work you can follow

A long list of findings tells nobody what to do on Monday. The plan turns it into upgrades, ranks them by what each one clears, and follows them across your next builds.

A prioritised plan

Findings are grouped by the upgrade that closes them, and the upgrades are ranked by how much each one clears, so the first line is the place to start. Where no fixed version exists yet, the plan says so instead of leaving a blank. A malicious package is marked for removal, since there is nothing to upgrade to.

See the effect before you commit

Tick the upgrades you are considering and the plan projects the grade they would leave, and which rules of the release gate they would clear.

Tickets and campaigns

File an upgrade as a ticket in Jira or ServiceNow with its findings attached, or group several into a campaign. Each new SBOM generation shows which of a campaign’s upgrades actually landed, so nobody has to ask.

Projected grade on three selected upgrades: from D at 48.7 today to C at 24.6 after them, clearing 30 findings.
Tick the upgrades you plan: the grade they would leave and the findings they clear.
A remediation campaign of three upgrades with one landed: progress reads 1 of 3, the status open.
A campaign on an example product: one upgrade landed in the newest SBOM, two still to come.

Ask for the first move

The assistant reads the same verdict and the same plan, so anyone on the team can ask why a release is blocked and what to do first.

  1. You

    Why is the release gate blocking Platform Worker Image, and what should we fix first?

  2. Assistant

    The release gate blocks Platform Worker Image. Rules broken: malicious packages (eslint-plugin-restart-vega-soap@1.0.0, py-infopullhydra@1.0.0). First remove eslint-plugin-restart-vega-soap@1.0.0 and py-infopullhydra@1.0.0: no upgrade clears a malicious package. Then upgrade openssl 3.0.19-1~deb12u2 to 3.0.20-1~deb12u2, which clears 9 findings. Check the release again once that is done.

    • Removeeslint-plugin-restart-vega-soap@1.0.0
    • Removepy-infopullhydra@1.0.0
    • Upgradeopenssl 3.0.19-1~deb12u2 → 3.0.20-1~deb12u2clears 9
  3. How the assistant answered3 calls, 1.4 s

    1. list_products

      11 products.

      131 ms

    2. product_gate product_id: 10

      Blocked: max_malicious.

      1.2 s

    3. product_remediation product_id: 10

      6 components to act on. openssl 3.0.19-1~deb12u2 to 3.0.20-1~deb12u2 clears 9 findings.

      125 ms

Gate blocked

Recorded on the example product Platform Worker Image: the gate's verdict and the plan's first lines.

The same rules, before a change merges

A pull request that adds a dependency is the cheapest moment to refuse it. The pull-request check reads the candidate SBOM against the product without changing it, and answers with the rule it tripped on.

What the gate judges on every change

Malicious packages
None allowed by default. A package the feeds or its registry name as malicious fails the check.
Look-alike names
A name one or two letters away from a package everyone uses.
Abandoned or deprecated
No release in two years, or deprecated by its maintainers.
Young versions
A version published fewer days ago than the number you set.
Lost provenance
A version without the registry attestation its predecessors carried.
Changed publisher
A version published by another account than the version before it.
New install script
A version that added a script run at install time.
Exploited findings
Records exploited in the wild, or tied to ransomware campaigns.
Licence restrictions
Licences that restrict commercial use, distribution or modification, as you list them.

Each rule is a switch in your policy, and the same rules decide the release gate.

  1. You

    Our pull request on Payments API adds eslint-plugin-restart-vega-soap 1.0.0. Will it pass the release gate?

  2. Assistant

    No. The pull request would block the release gate of Payments API. Rules broken: malicious packages (eslint-plugin-restart-vega-soap@1.0.0). New in this pull request: CVE-2026-4800, MAL-2025-19862, CVE-2025-13465.

  3. How the assistant answered1 call, 5.1 s

    1. check_sbom product_id: 1, sbom: CycloneDX 1.6, 2 components, branch: add-eslint-plugin-restart-vega-soap

      Blocked: max_malicious (eslint-plugin-restart-vega-soap@1.0.0). 4 new findings.

      5.1 s

Gate blocked

Recorded against the example product Payments API: a candidate SBOM carrying the dependency the pull request adds, checked without changing the product.

The ready-made jobs for GitHub Actions, GitLab CI, Jenkins, Bitbucket Pipelines and Azure Pipelines run the check on each pull request and upload each release build's SBOM. A blocked verdict, or a scan that did not finish in time, fails the job.

The Package trust group of the release gate in Policy: seven rules on the packages a release may carry, each with its switch and the level that turns it on.
The Package trust group of the release gate in Policy: the first four of its seven rules, each a switch.

Hold what suppliers deliver to your own requirements

The software you buy ends up in what you ship. Ask each supplier for an SBOM, and judge it the way you judge your own.

A key for each delivery

A Supplier key uploads for one product and reads back only the result of its own delivery, never a finding. The supplier needs no account, and the delivery is matched like any other generation of the product.

A scorecard for each supplier

Each supplier’s scorecard averages completeness, identifiers, format, licences, supplier data, timeliness and signatures across the latest SBOMs of the products they deliver.

An acceptance profile

Choose the profile a supplier’s SBOMs are judged against, such as the Cyber Resilience Act minimum. The answer is per product, so you can see which delivery falls short and why.

The Suppliers scorecard of one example supplier: its grade, its seven quality dimensions, its acceptance profile, and each product accepted or not accepted with the reason.
A supplier’s scorecard, on invented suppliers and our demonstration products: one delivery accepted, one refused, and why.

Eight frameworks, one set of facts

The scan that grades a product also answers the controls of the frameworks it targets.

  • EU Cyber Resilience Act
  • NIS2
  • SOC 2
  • ISO/IEC 27001
  • PCI DSS v4.0.1
  • NIST SSDF
  • BSI TR-03183
  • EU AI Act

The four answers a control can give

Satisfied
The facts meet the control.
Needs attention
Something to look at before the review.
Gap
The facts fail the control.
Awaiting attestation
A person confirms it, with a note or a link.

Readiness is the share of applicable controls that are satisfied, a control that needs attention counting as a half. It is a figure for review, never a certification, and the report says so in plain words. It is measured every night, so a regression reaches your alerts before it reaches the audit.

The printable report carries a running header, a table of contents when it is long, and an appendix with the framework's own text for every control it cites.

Evidence you can hand over

A VEX documents why a vulnerability does or does not affect your product, and it is written from the facts VulnBeacon holds. The vulnerability disclosure report, the SARIF, the evidence pack and the printable reports are dated and carry the product’s name. To show a customer one report, share a read-only link with an expiry date and, if you want, a password.

Two controls of the EU Cyber Resilience Act opened: each with its citation, its status, the evidence behind it and what to do.
A control opened on its evidence: its citation, its status and the facts behind them.
The printable compliance report of a product: its readiness and each control with its status and evidence.
The printable report you can hand over or share.

Vulnerability intelligence: one record, from 86 sources

Behind every grade is one record per vulnerability. The CVE list, the NVD, GitHub's advisories, OSV, the CISA KEV catalogue, EPSS, the vendors' own advisories, national CERTs and the malicious-package feeds are merged into it, so you read one record instead of reconciling five.

245,222

malicious packages in the record, 1,108 of them published in the last 30 days

Packages published to do harm

Attackers no longer wait for a flaw; they publish the package. A scanner that looks only for CVE identifiers never sees them.

1,760

records on the CISA catalogue of known exploited vulnerabilities, 32 of them added in the last 30 days

Exploitation before the score

A score says how bad a flaw could be; exploitation says it is happening. 32,423 records carry evidence of exploitation in the wild or a weaponised exploit.

  • EU Cyber Resilience Act
  • NIS2
  • PCI DSS v4.0.1

ask for the proof, not the intent

Regulation that asks for proof

An SBOM, a vulnerability handling process, the evidence that it ran, and a reasoned answer for each vulnerability that does not affect you. A spreadsheet assembled the week before the audit does not hold up.

Names one letter away from the real one

The malicious packages hide behind names one letter away from the real ones, install scripts that fetch a binary, and versions pushed by an account nobody knows. The record holds them beside the vulnerabilities, with the registry's own verdict when it has one, so the inventory of a product is judged on both at once.

Sorted by what is happening, not by a score

Sorted by CVSS alone, the exploited records sit among thousands that nobody attacks. VulnBeacon reads the KEV catalogue, the exploitation evidence and the EPSS probability into every record, and the findings of a product come out exploited first.

The proof the regulation asks for

The EU Cyber Resilience Act, NIS2 and PCI DSS v4.0.1 ask for the proof, not the intent. The reasoned answer for a vulnerability that does not affect you is what a VEX is, and VulnBeacon writes it from the facts it holds.

The Threat intel screen: records on the KEV catalogue, records past the CISA due date, records exploited in the window, and how far the window's records went from publication to exploitation.
Threat intel in the application: what is exploited now, and how far each window's records got.

The record, this month

New CVE recordsPublished in the last 30 days 15,679
MAL Malicious packagesPublished in the last 30 days 1,108
KEV Known exploitedAdded to the CISA catalogue in the last 30 days 32
SourcesMerged into one record per vulnerability 86
The whole record, in figures
CVE records395,743
Advisories2.7 million
Malicious packages245,222

Each record shows when it was last modified.

The record bulletin of a critical vulnerability on the CISA KEV catalogue, as the application shows it: exploited in the wild, the CVSS vector, the EPSS probability, the risk score, the remediation and the weaknesses.
A real record, read from the application: exploited in the wild, the vector, the probability, the remediation, the weaknesses.

Ask the record directly

The same record answers an assistant. These two sessions were recorded against it: a week’s critical vulnerabilities, and the latest remote code execution records.

  1. You

    Which critical vulnerabilities were published this week?

  2. Assistant

    273 critical records were published since 23 October. The newest: CVE-2026-76024 (Chrome, critical, fix available), CVE-2023-22793 (Management Pack for Microsoft System Center, CVSS 9.3, fix available), CVE-2026-61707 (CoPilot, CVSS 9.0, fix available), CVE-2026-61645 (docat, CVSS 9.1, fix available) and CVE-2026-103093 (ServiceNow AI Platform, CVSS 9.4). None of them is on the KEV catalogue yet.

    • CVE-2026-76024criticalChromefix available
    • CVE-2023-22793criticalCVSS 9.3Management Pack for Microsoft System Centerfix available
    • CVE-2026-61707criticalCVSS 9.0CoPilotfix available
    • CVE-2026-61645criticalCVSS 9.1docatfix available
    • CVE-2026-103093criticalCVSS 9.4ServiceNow AI Platform
  3. How the assistant answered1 call, 112 ms

    1. search_corpus severity: critical, since: 2026-10-23, per_page: 5

      273 records; the 5 newest:

      112 ms

Recorded against the record: the critical records of the last seven days, newest first, the five newest listed.

An assistant that answers from your products and the record

VulnBeacon ships an MCP server, so an assistant such as Claude, Cursor or VS Code can ask in your words. It calls the same API the application uses, with your key, and answers from the same facts. It is one way in: the web application and your CI jobs reach the same capabilities. The sessions on this page were recorded that way, on example products.

What it can ask

  • A product's decisionThe grade and its reasons, the gate verdict, the findings, a prioritised plan, the trend, the advisory to publish, the whole portfolio. product_risk, product_gate, product_findings, product_remediation, product_trend, product_advisory, portfolio_summary, list_products
  • An SBOMUpload a build's SBOM, check a pull request's candidate without touching the product, compare two generations. upload_sbom, check_sbom, sbom_diff
  • The recordA vulnerability by any of its identifiers, the packages it affects, a package by its purl with its malicious status, a search over the whole record, the impact of an incident on your products. cve_lookup, cve_packages, package_lookup, search_corpus, incident_impact
  • ComplianceReadiness per framework and the report with every control's answer. compliance_summary, compliance_report
  • Your watchThe watch lists, what changed for them, the alerts feed. list_watchlists, watchlist_changes, alerts_feed
  • The rules and the keyThe policy in force for the account, and what the key in use may do. effective_policy, key_info

Local or hosted

Locally, uvx vulnbeacon-mcp runs the server on your machine for Claude Code, Claude Desktop, Cursor or VS Code. Hosted, the same tools answer at https://mcp.vulnbeacon.com/mcp, with your key sent in each request.

The key decides what it can do

A Reporting key reads every product of your account and changes nothing. A Product CI key also uploads an SBOM and runs the pull-request check, for the products it names. No key changes a policy or a decision; those change in the application only.

The MCP section of Settings: the server's address, and a configuration snippet for each assistant with the key left for you to paste.
The MCP settings: one snippet per assistant, your key left for you to paste.

Where the team already is

Alerts go to the channel that will be read, and the pipeline does the uploading.

  • SlackChat
  • TeamsChat
  • PagerDutyOn-call
  • JiraTickets
  • ServiceNowITSM
  • SplunkSIEM
  • ElasticSIEM
  • SentinelSIEM
  • GitHubSCM
  • GitLabSCM
  • E-mail alertsBuilt-in

Routing rules decide which alert kind, which severity and whether a KEV listing reaches each integration. A ticket reaches Jira or ServiceNow with the finding attached. An integration that keeps failing pauses itself and tells you, and only allowed hosts are ever contacted.

Settings, Integrations: the catalogue of providers, each with its mark and what it is for.
Settings, Integrations: each provider with its routing rules.

How it works, and what happens to your data

Your scanner keeps listing what is in the build. VulnBeacon adds what happens next: what that list now means, who has to act, and what you can show for it.

Beside the tools you already run

Syft, Trivy, Grype and your SBOM tools produce the inventory, as CycloneDX, SPDX, a supported lockfile or the scanner’s own output. VulnBeacon reads it against a record kept up to date from 86 sources, and reads it again when the record changes, with no new scan. Your scanner tells you what it found today. VulnBeacon follows each product from there: which ones a new flaw reaches, what to fix first, whether the fix landed, and whether the release meets your policy.

Three ways in, one set of answers

The web workspace holds everything, with nothing to install. Your pipeline uploads each SBOM and checks each pull request with a key that names its products. An AI assistant is optional: it reads through the same API with a key you choose, so an organisation that has not approved one still has the whole product.

Where it runs

Every offer is your own instance, operated by us. Enterprise can also run on your own machines.

A product’s Inventory stage: each component with its version, ecosystem, licence and health signals, and the SBOM’s quality score above.
What a scanner’s list becomes: each component with its licence, health and quality.

What you send, and where it goes

What you upload
SBOMs and dependency manifests, not source code. They can still reveal details of a project, so remove any personal information or secret the analysis does not need.
Hosting
Datacentres in the European Union. That does not keep every flow inside it: the services below can involve processing outside the European Economic Area.
In transit
Every connection passes through a network-protection provider, which processes what each request carries while it is in transit, documents included.
Package lookups
To judge dependency health and run the pull-request check, package identifiers go to public package-intelligence services and, for npm and PyPI, to their registries. Identifiers only, never a whole SBOM. A private package’s name can still reveal something: tell us if your lookups need restricting.
Integrations
An integration receives what you send it, and nothing reaches one you have not configured.
Assistants
If you connect one, its provider processes your prompts, the information retrieved and the answers under its own terms. We do not use your information to train AI models.
On your own machines
All of this describes the instance we operate. An Enterprise instance on your own machines is hosted under your control, on your network. Package lookups still go out unless you ask us to restrict them.

The privacy notice names each provider and has the full detail, and the terms of service what you may upload.

Offers

Every offer runs as your own instance, operated by us. Enterprise can also run on your own machines.

8
20
500

What each offer holds
Team €900 a month, billed annually, excl. VAT 10 products For a team shipping a handful of products. Request Team Business €2,400 a month, billed annually, excl. VAT 50 products For an organisation with a portfolio to keep clear. Request Business Enterprise from €5,000 a month, billed annually, excl. VAT 200 products For a large portfolio, or an instance on your own machines. Request Enterprise
Where it runs Your own instance, run by us Your own instance, run by us Your own instance, run by us or on your machines
Price a year, excl. VAT €10,800 €28,800 from €60,000
Support Not included Not included Included
SBOM generations kept, per product 10 25 50
Uploads and pull-request checks a month 10,000 50,000 200,000
Components in one SBOM 5,000 10,000 10,000
Components across all products 20,000 100,000 400,000
Alert integrations 10 20 50
Reporting keys 5 10 25
API requests a minute, per key 300 300 600
API requests a month, per key 100,000 100,000 500,000

How the limits read

One product
Whatever you track as one: an application, a service or an image. A new version is a new SBOM generation of the same product, not another product.
Reaching a limit
What you already have stays as it is. An upload or check past the month’s quota waits for the next month, a new product past the limit is refused, and an SBOM over a component limit is refused with both figures. A deleted product that was in use keeps its place for 30 days.
Users, onboarding, evaluation
Tell us what you need in your request, and a person answers.

In every offer

  • A grade with its reasons, and a prioritised remediation plan
  • The release gate and the pull-request check, on your rules
  • VEX, exports and the evidence pack
  • Readiness against every framework we cover
  • One record of vulnerabilities and malicious packages, kept from 86 sources
  • The assistant over MCP, hosted or on your machine
  • Alerts and tickets in the tools you already use
  • Supplier keys, for the SBOMs your suppliers deliver

Start with one product

Start with one product: bring its inventory and see its exposure, prioritised fixes, release-policy result and evidence. Explore a sample product assessment first, if you want something to read or share. Accounts are created for you once we have read your request. Tell us your name, your organisation and what you ship. Once your account exists, the first grade takes about a minute after your first upload.

Request access Sign in