Software usually consists of proprietary code and integrated libraries. If a security vulnerability is discovered in one of these libraries, manufacturers must identify which of their deployed applications are affected. To do this, they need reliable component information and a process that covers everything from technical testing to informing customers.
An SBOM provides the basis for this work. This article explains how this forms the basis for an ongoing vulnerability management process and what information helps when deciding on updates, protective measures and reporting.
An overview of abbreviations
| Abbreviation | Advertised | Meaning in the article |
|---|---|---|
| SBOM | Software Bill of Materials | Machine-readable overview of the software components and their dependencies |
| CVE | Common Vulnerabilities and Exposures | An identifier used to uniquely reference a published vulnerability |
| CVSS | Common Vulnerability Scoring System | A method for assessing the characteristics and technical severity of a vulnerability |
| VEX | Vulnerability Exploitability eXchange | Machine-readable statement indicating whether a specific product version is affected by a vulnerability |
| KEV catalogue | Known Exploited Vulnerabilities Catalog | CISA’s catalogue of known vulnerabilities |
| CISA | Cybersecurity and Infrastructure Security Agency | US Cybersecurity and Infrastructure Security Agency |
| CRA | Cyber Resilience Act | EU Regulation setting out cybersecurity requirements for products containing digital elements |
Work on software security does not end with its release. A library that appeared unremarkable at the time of release may contain a known security vulnerability months later. What matters then is how quickly the vendor can determine which versions that have been distributed are affected and what its customers need to do.
A Software Bill of Materials (SBOM) provides the information basis for this. It documents the components of an application. Its practical value becomes apparent when a new alert is received: the search begins with a known software inventory, rather than with the question of which libraries have been incorporated into the project at some point.
To ensure a reliable response, component information, technical assessment and customer support must work together.
The warning must correspond to the software as supplied
A vulnerability report usually specifies a component and the affected versions. A CVE identifier allows the published vulnerability to be uniquely referenced. An initial comparison with your own SBOMs reveals which product versions require further investigation.
The SBOMs from previous releases are just as important as the current file. An update to the development project does not remove a vulnerable library from an application that has already been deployed. Anyone who only looks at the latest build may correctly assess the current status but still overlook the affected customers.
That is why the SBOM is associated with the relevant release. The product version, build configuration and list of components must remain accessible together. The delivery and installation information then indicates which customers have received this version or are still using it. The SBOM itself does not perform this mapping.
If version details are missing, this initially creates a research task. An automatic comparison can only work with the information available to it.
The library is included. Is the application affected?
A match in a vulnerability scan is a reason to investigate. It does not, in itself, prove that the security vulnerability can be exploited in your own application.
A library, for example, may contain a vulnerable server module, whilst your own product uses only other parts of it. The crucial factor, then, is whether the affected code is actually present in the delivered build and under what conditions it can be accessed.
This test forms part of the development process or falls within the remit of the department responsible for product safety. The security advisory sets out the attack conditions; the code, build documentation and tests demonstrate whether these conditions are met in our own product.
The justification for ‘not affected’ must also be sound. ‘We don’t normally use it’ is hardly sufficient. A feature may be activated by the customer or accessed via another part of the programme. A documented analysis, on the other hand, makes it clear why a specific product version does not require a fix.
VEX is designed to facilitate the sharing of such assessments. It enables manufacturers to provide machine-readable information on the impact on specific product versions.. CycloneDX describes how VEX supports this communication. The statement remains tied to the status of its product and the reasoning behind it.
The assessment must enable a decision to be made
If the application is affected, a decision must be made regarding the urgency of the matter and the necessary remedial action. The severity of an attack depends, amongst other things, on which data or functions are at risk, what permissions are required, and whether the vulnerable function is publicly accessible.
A CVSS score provides information on the technical severity. However, a baseline score in particular does not yet take the specific operational context into account. The basis for the assessment is explained FIRST. References to known exploits, such as those in CISA’s KEV catalogue, are another important component.
The assessment should therefore result in a specific action plan: who will provide the fix, what is the deadline, and how will users be protected in the meantime?
Sometimes a library can be updated straight away. In other cases, the change requires further development and testing. In such cases, a temporary measure may help, such as restricting access or disabling a vulnerable function. Customers must be able to understand how to apply this measure and what restrictions it entails.
At the same time, a review of potential reporting obligations is underway. For products covered by the CRA, manufacturers have been required since 11 September 2026 to report actively exploited vulnerabilities and serious security incidents that affect product safety. An initial report must be submitted within 24 hours, and a more detailed report within 72 hours of becoming aware of the issue.The European Commission sets out the requirements and deadlines.
A published CVE alone does not trigger an automatic notification. However, once the conditions are met, the notification cannot wait until the update is ready.
Fictitious example: A warning, a clear response
The following company, library and security vulnerability are purely fictional.
Beispiel GmbH markets a Delphi application for the maintenance of industrial plant. A security warning concerns the file import library: specially crafted files could enable the execution of programme code.
Comparison with the archived SBOMs narrows down the scope of the investigation. Version 3.1 contains a version of the library that is not affected. Version 3.2 contains the vulnerable version. The investigation also confirms that the vulnerable function is accessible when opening an import file.
The decision has therefore been made: version 3.2 requires a fix. Until it is available, the company advises affected customers to disable file import. The development team will update the library, verify the security fix and test the standard import functions. It will then release version 3.2.1 with a new SBOM.
In the case described, there is no evidence of active exploitation or of a serious security incident. Consequently, no CRA report is required. The company documents this assessment alongside the fix and informs customers of the update.
The SBOM has narrowed down the affected software versions here. The technical investigation made this decision possible. The agreed procedure has ensured that the remedy is also reaching customers.
An update needs clear information
A corrected version is only helpful if users can tell whether they need it and how to install it.
The customer information should therefore specify the affected versions, explain the available fix and, where appropriate, describe any temporary protective measures. Following publication, it must also remain clear what has been tested and released.
Even a case that does not result in an update needs to be closed: the product version investigated, the outcome and the reasoning. This information is helpful in the event of any queries and prevents the same warning from being investigated from scratch time and time again. If the product or the findings regarding the vulnerability change, the assessment is revisited.
How Maenken Systems supports the process
The Msys SBOM Generator creates CycloneDX SBOMs for Delphi projects. When this project setting is enabled, the overview is generated automatically upon successful compilation. Additional component information can be incorporated via custom or virtual SBOMs and external modules. Command-line tools are available for automated build processes.
This enables manufacturers to archive the component overview together with the relevant release and keep it available for future analysis.
Maenken Systems is developing the SBOM Monitor for ongoing monitoring. The system is designed to carry out regular comparisons with vulnerability data and send notifications regarding relevant matches. These are intended to support the technical processing of new reports.
Conclusion
An SBOM saves valuable investigation time when a new security alert is issued. It is then crucial that the investigation leads to a well-founded decision and that the necessary measures are implemented. By linking the component overview, development and customer information, it is possible to explain more quickly which software is affected and what remedies are available.
Sources and further information
Sources and further information
- FIRST: CVSS User Guide: Fundamentals of Technical Severity Assessment.
- CISA: Catalogue of Known Exploited Vulnerabilities: Information on vulnerabilities known to have been exploited.
- CycloneDX: VEX: Machine-readable statements regarding the impact on specific products.
- EU-Kommission: CRA reporting requirements: Reportable events, deadlines and reporting channels.
As at October 2026. The procedures described are practical recommendations. Legal reporting obligations must be assessed on the basis of the specific incident and the applicable regulations.
