OPAIRS SBOM Scanner: Continuous Vulnerability and Supply-Chain Monitoring for the Cyber Resilience Act

Most of the software running in manufacturing is made of building blocks that were not written in-house: libraries, base images, runtimes. A typical Docker container ships hundreds of such packages. When a vulnerability becomes known in one of them, the first question is: are we affected, and where? Without a bill of materials, a manual search starts at exactly the moment when time is shortest.

The EU Cyber Resilience Act turns this good practice into an obligation. OPAIRS has therefore built its own SBOM scanner, which runs in production on our servers and is freely available as open source. It creates a software bill of materials for every running container, tracks vulnerabilities over time and sends an email when a vulnerability is actively exploited or a package has been reported as malicious. It runs entirely on the operator's premises, without a cloud account and without an external service provider.

What the Cyber Resilience Act Requires Now

The Cyber Resilience Act (Regulation (EU) 2024/2847) has been in force since December 2024 and applies in stages. It concerns manufacturers of products with digital elements placed on the EU market – including machine and plant builders whose controllers, HMIs or software modules connect to a network. The regulation text is available on EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj

• Since 11 September 2026 the reporting obligations of Article 14 apply: actively exploited vulnerabilities and severe incidents must be reported – an early warning within 24 hours, a notification within 72 hours and a final report no later than 14 days after a corrective measure is available. This also covers products already on the market.
• Reports go through ENISA's Single Reporting Platform, which went live the same day: https://www.enisa.europa.eu/cra-srp/
• From 11 December 2027 all essential requirements apply. According to Annex I, Part II, these include identifying and documenting the components of a product, among other things with a software bill of materials (SBOM) in a commonly used, machine-readable format, and handling vulnerabilities throughout the support period.
• On 27 July 2026 the European Commission published guidance on applying the regulation, with 67 practical examples and particular attention to small and medium-sized enterprises: https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation

In practice, the 24-hour clock starts as soon as the manufacturer becomes aware of an actively exploited vulnerability. If you only then begin to work out which products and versions contain the affected library, you lose exactly the hours you need for the report. An up-to-date bill of materials and continuous monitoring are therefore a precondition for meeting the obligations at all. This article is a technical overview, not legal advice; whether and how a product falls under the CRA must be assessed case by case.

A Service That Keeps Watching

The scanner runs as a single container next to the other services and works in small increments instead of one large nightly run. It builds on two established open-source tools from Anchore – Syft for the bill of materials and Grype for matching against vulnerability databases – and adds everything needed for continuous operation:

• CycloneDX bills of materials for all running Docker containers, Kubernetes pods and any configured directories. As long as an image does not change, the stored bill of materials is reused.
• Tracking over time: every finding has a "first seen", "last seen" and "resolved" date. You see what is new, what was fixed and what is still open.
• Scoring with CVSS, FIRST's exploit prediction score EPSS and the version in which the vulnerability is fixed.
• A daily email report with figures, changes, the largest open risks and the operating state of the scanner itself.
• A REST API for pulling findings into your own tools, dashboards or automations.

A failed scan counts as an error, not as "no findings". It is retried with increasing back-off and listed in the daily report. Syft and Grype run at low CPU priority, and disk usage is bounded: reports have a retention period, bills of materials are archived compressed, and scratch files are removed after every run.

Alerts Only When It Matters

A scanner that sends a hundred emails a day is ignored after a week. Alerting is therefore rule-based and deliberately sparse. Two cases have top priority: a finding is listed in the US agency CISA's catalogue of Known Exploited Vulnerabilities (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), or a package in use has been reported as malicious. These are exactly the situations in which the CRA reporting deadlines may become relevant. In addition there are warnings for critical findings and for high findings with an exploit probability of at least 50 percent.

Each finding is announced only once – again only if it escalates, for example when a known vulnerability is later added to the KEV catalogue, or if it reappears after being fixed. The first scan of a system is treated as a baseline: legacy findings go into the daily report rather than the inbox, while actively exploited vulnerabilities and malware still alert immediately. The same vulnerability across several images appears on one line, and every email names the image, package, version, target version and a concrete action.

Supply-Chain Attacks: When a Package Is Malicious on Purpose

A classic vulnerability scanner finds known bugs. It does not find a package that was deliberately published with malicious code. How real this risk is became clear in 2026 with the attack on the Python package LiteLLM: in March, two manipulated versions were published on PyPI after attackers obtained the maintainer's credentials through a compromised CI pipeline – of all things, via a security scanner used there. The project has documented the timeline: https://github.com/BerriAI/litellm/issues/24518

Every six hours, the OPAIRS scanner therefore checks all packages from the stored bills of materials against the malware advisories in the OSV database (https://osv.dev), which are fed by the OpenSSF Malicious Packages project. This runs independently of the actual scan: if a package is reported as malicious weeks after an image was built, the scanner still fires. The limits are clear: only the ecosystems OSV covers (npm, PyPI, Cargo, RubyGems, Go, Maven, NuGet), only packages that appear in the bill of materials, and only what has already been reported. It is a tripwire, not proof of safety.

A Small Language Model That Only Writes

Optionally, a small language model writes a short note for each alert on what the finding means and what to do, and summarises the daily report. It runs via llama.cpp on the CPU, uses no GPU and needs around two gigabytes of memory; we use IBM Granite 4.0 Micro in a 4-bit quantisation, the repository defaults to Qwen2.5-1.5B. The model decides nothing: severity, priority and alerting are fixed rules, and its texts are labelled as an AI assessment without guarantee. Because CVE descriptions come from third parties, they are treated as untrusted, sanitised, truncated and passed explicitly as data, not instructions. If the model is slow or switched off, the emails go out without notes.

Lessons From Our Own Operation

Since 25 October 2026 the scanner has been monitoring our platform server with around 50 images, including language model servers, databases and our own services. The first alert for an actively exploited vulnerability concerned the scanner itself: an outdated version of the Starlette web framework had been in the KEV catalogue since early September. It was updated the same day – a good example of why a tool should also check itself.

It was also instructive to see where the tools hit their limits. For images with embedded model files, such as vLLM and Open WebUI, matching with Grype grew to around 25 gigabytes of memory until the process was killed. The cause is an open bug in Grype when reading model components without a package identifier (https://github.com/anchore/grype/issues/3767). The scanner therefore removes these components from a copy of the bill of materials before Grype reads it; they cannot match a package vulnerability anyway, and the archived original stays complete. After that, a vLLM image was scanned in 18 seconds and 49 of 50 targets were covered. For the last one, a particularly large speech recognition image, bill-of-materials generation itself shows the same pattern; a further countermeasure that skips model files altogether is being tested there. Further lessons: alerts for actively exploited vulnerabilities are now bundled at ten-minute intervals, and the same vulnerability across several images appears only once in the report.

What the Scanner Does Not Do

The scanner is no proof of security and no push-button CRA conformity. It finds known vulnerabilities and reported malicious packages, not unknown bugs in your own code. It does not check the server's operating system or software that is only loaded at runtime. It does not file reports to the ENISA platform; deciding whether a vulnerability is actually exploitable in your product and must be reported remains a human decision. The CRA additionally requires risk assessment, a support period, an update process and technical documentation. What the scanner provides is the data foundation for all of this: an up-to-date bill of materials, a traceable history of every finding and an alert at the moment the clock starts ticking.

Independent of External Service Providers

SBOM and vulnerability management is usually offered today as a cloud platform. That requires the complete list of software in use to leave the building – precisely the information an attacker would most like to have when preparing an attack. The OPAIRS scanner instead runs at the operator's site: on an existing Linux server, started with Docker Compose in a few minutes, with no account, licence key or subscription. Outbound connections go only to the public data sources (vulnerability database, KEV catalogue, OSV), and offline mode switches even those off, for instance for plants without internet access. Emails go through your own mail server. This lets smaller manufacturers and machine builders set up continuous monitoring without being tied to a vendor – and lets integrators offer their customers something that runs on site and stays there.

Acknowledgements

The actual analysis is done by other people's tools and data: Syft and Grype from Anchore, CISA's KEV catalogue, OSV and the OpenSSF Malicious Packages project, FIRST's EPSS scores, llama.cpp and IBM Granite as the local model. The OPAIRS scanner develops none of these; it combines them into a service that runs permanently and with limited effort in-house. The licences and terms of use of the data sources and model weights should be checked before deployment.

Part of the OPAIRS Platform

On the OPAIRS platform the scanner is another local specialist service alongside language models, the SQL agent and the forecasting service. Through its API, findings can be pulled into automations or queried by an agent in chat – for example, which images are affected by a particular vulnerability. It complements the governance building blocks we described for the EU AI Act: https://opairs-systems.com/en/insights/eu-ai-act-industrie-orientierung

Open Source on GitHub

The scanner is open source under the MIT licence on GitHub: https://github.com/OPAIRS/sbom-scanner. The repository contains the code, tests, a Docker Compose example, a full description of all settings and endpoints, and the contribution guidelines. Every change runs through automated tests and a Docker build with start-up and health checks. Anyone who wants to review the scanner, use it in their own operation or develop it further can do so without depending on OPAIRS.

Get Involved: Tests, Feedback, Contributions

The scanner is meant to help manufacturers, machine builders and operators tackle the obligations of the Cyber Resilience Act with their own means. To do that well, it needs feedback from other environments: different image landscapes, Kubernetes clusters, plants without internet access, requirements from audits. Cases where the scanner misses something, reports too much or hits its limits are especially valuable. Issues and pull requests are welcome in the repository.

For joint pilot projects, integration into existing processes or questions about deployment: office@opairs-systems.com