Today, the Software Bill of Materials (SBOM) has become a fundamental tool for managing security, compliance, and risk in the software supply chain, especially in a context where the reuse of open source components is widespread on a large scale. In this article, we explain how our approach can automate the collection and management of this information, improving visibility and resilience.
Per anni la sicurezza del software è stata affrontata come un problema prevalentemente tecnico, fatto di patch, firewall e controlli perimetrali. Oggi questa visione non è più sufficiente. Le applicazioni che utilizziamo e sviluppiamo non sono più monoliti costruiti interamente in casa, ma ecosistemi complessi, composti da librerie open source, componenti commerciali, servizi cloud, framework e moduli sviluppati da terze parti.
In questo contesto, la domanda non è più semplicemente “il mio software è sicuro?”, ma piuttosto: “di cosa è fatto il mio software e cosa comporta in termini di rischio, responsabilità e compliance?”
È qui che entra in gioco la Software Bill of Materials (SBOM): la distinta base del software, ovvero un inventario strutturato e interrogabile dei componenti che lo compongono. Quello che fino a poco tempo fa era un tema per addetti ai lavori sta rapidamente diventando una necessità trasversale, che riguarda tutte le organizzazioni, non solo chi sviluppa software.
Quando pensiamo a un’applicazione, tendiamo ancora a immaginarla come un prodotto relativamente compatto, sviluppato e controllato da un singolo team. In realtà, il software moderno è sempre più simile a una supply chain, paragonabile a quella di un prodotto industriale.
Accanto al codice proprietario sviluppato internamente, un’applicazione include oggi una quantità crescente di componenti esterni: librerie open source, framework, runtime, SDK di terze parti, plugin e moduli forniti da vendor, componenti commerciali acquistati e integrati (COTS), oltre a servizi cloud, API e pacchetti provenienti da marketplace. Il risultato è a assemblato di elementi con origini diverse, ciascuno con il proprio ciclo di vita, le proprie vulnerabilità e i propri vincoli di licenza.
Questa complessità è amplificata dal modo in cui il software viene prodotto. È normale che più team contribuiscano alla stessa applicazione — interni, fornitori, consulenti — e che gli stessi componenti vengano riutilizzati in più progetti. Le dipendenze cambiano frequentemente: nuove versioni, nuove librerie, nuove immagini container entrano in produzione con grande rapidità.
The advantage is clear: development is faster and innovation capacity increases. The downside is equally clear: the risk surface increases. Each dependency represents a potential source of vulnerability and compatibility issues. And every update, if not managed with the right visibility, can introduce new risks. Treating software as a supply chain is therefore not a theoretical exercise, but a necessary acknowledgment to truly understand its complexity and responsibilities.
One of the strengths of open source is reuse: components shared by thousands of projects accelerate development and foster innovation. At the same time, this model creates a risk multiplier effect. When a vulnerability emerges in a widely used component, the impact is not limited to a single product, but extends to entire software ecosystems.
In questi casi, il problema non è tanto l’esistenza della vulnerabilità in sé — le vulnerabilità sono inevitabili — quanto la capacità di capire rapidamente se e dove quella vulnerabilità impatta la propria organizzazione. Significa sapere se un componente è utilizzato, in quale versione, se è presente direttamente o come dipendenza indiretta, dove è stato distribuito e chi lo ha introdotto lungo la catena di sviluppo o fornitura.
Eventi come Apache Struts nel 2017, Log4Shell nel 2021 o la vulnerabilità di cURL nel 2023 hanno mostrato con chiarezza questo meccanismo. In tutti questi casi, la differenza tra chi ha reagito in modo rapido ed efficace e chi ha faticato per settimane è stata spesso una sola: la visibilità sulla composizione del software.
Organizations that knew exactly what they had in production were able to quickly identify points of exposure and take action. Those without this visibility found themselves searching “in the dark,” with significant impacts on time, cost, and operational risk. It is in this context that SBOM becomes a real operational accelerator. Having a structured inventory of software components does not eliminate vulnerabilities, but it drastically reduces the time and uncertainty required to identify them, assess their impact, and manage them in a targeted manner.
Il tema della SBOM viene spesso introdotto partendo dalla sicurezza: vulnerabilità, CVE, patching. Ma fermarsi a questo livello è riduttivo. Esiste un secondo piano, altrettanto rilevante, che riguarda licenze, obblighi legali e responsabilità lungo la supply chain software.
Un caso emblematico in questo senso è quello di Vizio, frequentemente citato nel mondo open source e copyleft. La vicenda è interessante perché sposta il focus da “stiamo usando software open source?” a una domanda molto più scomoda : “possiamo dimostrare di rispettarne davvero le condizioni?”
Vizio è stata coinvolta in una causa legata all’utilizzo di componenti software rilasciati sotto licenza GPL all’interno dei propri smart TV. Il punto centrale non era semplicemente l’uso di software open source — pratica del tutto legittima — ma il modo in cui tale software veniva distribuito. Secondo le contestazioni, il codice sorgente rilasciato non era sufficiente a consentire un utilizzo reale: mancavano parti fondamentali, istruzioni di build, informazioni sulle modifiche effettuate e una chiara tracciabilità dei componenti inclusi.
Il caso è diventato rilevante perché ha chiarito un principio fondamentale: non basta dichiarare la conformità a una licenza open source, bisogna essere in grado di provarla in modo concreto e verificabile. Nei contesti embedded e nei prodotti commerciali che incorporano OSS — come Linux embedded, driver modificati o librerie copyleft — una gestione superficiale della composizione software porta rapidamente a situazioni critiche. Il risultato è spesso un rilascio del sorgente solo formalmente corretto, ma privo delle informazioni necessarie a garantirne una reale fruibilità, con conseguenti rischi legali e reputazionali per l’organizzazione.
The bottom line is that the software supply chain generates obligations, not only technical but also contractual and legal. Each component introduced brings with it conditions of use, distribution constraints, and responsibilities that must be governed over time. Without an SBOM — or without an equivalent process of traceability and control — these obligations become difficult, if not entirely unmanageable.
In questo senso, la SBOM non è soltanto uno strumento di sicurezza, ma un meccanismo di accountability: consente di sapere cosa si sta distribuendo, da dove proviene, quali licenze lo regolano e quali responsabilità ne derivano. Ed è proprio questa capacità di dimostrare consapevolezza e controllo che sta rendendo la gestione delle SBOM sempre più centrale, anche al di fuori dei contesti puramente tecnici.
Negli ultimi anni, il tema della composizione del software è uscito dall’ambito puramente tecnico per entrare a pieno titolo nel perimetro normativo.
Le istituzioni hanno preso atto di una realtà ormai evidente: la sicurezza e l’affidabilità del software dipendono dalla sua supply chain. E governare questa supply chain richiede visibilità.
In questo contesto si inseriscono iniziative come la National Cybersecurity Strategy negli Stati Uniti e, soprattutto, il Cyber Resilience Act (CRA) in Europa. Il CRA introduce obblighi chiari per chi immette sul mercato prodotti con elementi digitali, in particolare software e dispositivi che lo incorporano. Tra questi obblighi rientrano la gestione delle vulnerabilità, la sicurezza lungo il ciclo di vita e la capacità di dimostrare controllo sui componenti utilizzati.
Although the CRA does not explicitly mention SBOM as the only possible tool, the principle is clear: it is not possible to comply with these requirements without knowing what the software is made of. In practice, SBOM becomes the most effective—and often the only truly scalable—means of demonstrating compliance.
Il punto però non riguarda solo i produttori di software. Altre normative ampliano ulteriormente il perimetro.
La Direttiva NIS2 sposta l’attenzione sulle organizzazioni che utilizzano software per erogare servizi essenziali o critici. Qui il focus non è tanto sul come è stato scritto il software, quanto sulla capacità dell’organizzazione di gestire il rischio cyber e quello legato alla supply chain. Questo include la valutazione dei fornitori, la gestione delle vulnerabilità e la dimostrazione di adeguate misure di controllo. Anche in questo caso, pur senza un obbligo esplicito, la SBOM diventa uno strumento chiave per esercitare e dimostrare la dovuta diligenza.
Per il settore finanziario, il quadro è ulteriormente rafforzato dal Digital Operational Resilience Act (DORA). DORA richiede alle organizzazioni finanziarie una profonda comprensione delle proprie dipendenze ICT e la capacità di rispondere rapidamente a incidenti e vulnerabilità che coinvolgono fornitori e tecnologie critiche. Senza una visibilità chiara sulla composizione del software utilizzato, soddisfare questi requisiti diventa estremamente complesso.
The result is a paradigm shift: the SBOM issue arose as a response to a security need, but has been made structural by regulation. The CRA acts upstream, imposing responsibilities on those who produce and distribute software; NIS2 and DORA act downstream, pushing organizations to demand transparency and control from their suppliers
In this scenario, SBOM is no longer an accessory document, but an enabling element for dialogue with regulators, customers, and partners. It not only serves to “improve security,” but also to demonstrate that the software is managed in an informed and responsible manner, in compliance with current and future regulatory expectations.
Truly effective SBOM management cannot be reduced to a static file or a one-off document: it requires an operational program capable of providing continuous visibility into the composition of the software.
This means having a complete and standardized inventory of all components—open source, commercial, and third-party—with versions, unique identifiers, and reliable metadata, but also understanding the relationships between these elements, including direct and transitive dependencies, hierarchies, and correlations. To be interoperable and sustainable over time, SBOMs must be managed in industry-standard formats such as SPDX, which is particularly effective for licensing and compliance aspects, and CycloneDX, which is more security and supply chain oriented.
However, the list of components alone is not enough: a useful SBOM must be enriched with operational information, such as known vulnerabilities, exploitability status, disclosure, and lifecycle data (EOL and EOS), as well as structured reports such as VDR and VEX.
From a practical standpoint, the process begins with the integration of SBOMs provided by vendors. However, market maturity on this issue is still uneven: SBOMs can be made available in very different ways—via manufacturer websites, “Readme” files included in distribution kits, content extracted directly from devices, device pointers (MUD), files provided to customers in readable format, or centralized repositories and trusted third parties. This heterogeneity makes integration complex and introduces significant standardization difficulties, especially when data does not follow consistent formats, levels of detail, or quality criteria.
To make the process sustainable over time, it is therefore necessary to activate structured collection channels and define clear rules on accepted formats, update frequency, delivery and signature methods, as well as minimum quality criteria, such as completeness of information, availability of build instructions, and traceability of origin. Where SBOMs are unavailable or incomplete—as in the case of internally developed software, SaaS solutions, or third-party components—it becomes inevitable to create them internally, adopting tools and processes capable of generating consistent, standardized, and maintainable SBOMs.
In this scenario, it is important to clarify that the CMDB is not the right place to manage SBOMs: designed to represent assets and operational relationships, it is often already overloaded with data and does not offer the granularity, continuous updating, and query capabilities required in the event of security incidents.
At WEGG, we address the issue of SBOMs with a deliberately cross-cutting approach, which starts with Software Asset Management (SAM) but extends beyond its traditional boundaries. SAM is the natural starting point for us because it is already the place where information on costs, contracts, and compliance converges; at the same time, it is the context in which the need to go beyond simple visibility of installed and used software emerges most clearly.
La SBOM diventa così l’elemento di collegamento tra SAM, sicurezza e compliance, rendendo la composizione del software un dato condiviso e realmente utilizzabile. In questa logica utilizziamo Flexera One IT Visibility come piattaforma di riferimento: non come uno strumento SBOM isolato, ma come parte di un ecosistema integrato.
We chose this solution because of its advanced open source Software Composition Analysis (SCA) technology—an area often not covered by traditional SAM tools—the comprehensive and continuously updated data in Technopedia, Flexera's database, and support throughout the entire SBOM lifecycle, from ingestion to normalization to continuous monitoring. Our role is to configure customer processes to make SBOM management an operational and scalable process, integrated into SAM, ITAM, CMDB, and security workflows.
La correlazione tra i componenti presenti nelle SBOM, la standardizzazione dei formati e l’integrazione con le informazioni sulle vulnerabilità permettono di collegare in modo naturale la gestione delle SBOM ai processi di vulnerability management, consentendo analisi di impatto rapide e mirate quando emergono nuove CVE. Allo stesso tempo, l’integrazione nei processi SAM contribuisce a garantire il rispetto dei requisiti di compliance normativa.
In this way, SBOM management is not treated as an isolated task, but as an integral part of overall software governance, starting with SAM and in dialogue with all the functions involved.
Insights
OUR OFFICES
OUR OFFICES
PADUA
Via Arnaldo Fusinato 42, 35137
MILAN
Viale Enrico Forlanini 23, 20134
ROME
Viale Giorgio Ribotta 11, 00144
Copyright © 2025 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Azienda Certificata ISO 9001:2015 – ITA / ISO 9001:2015 – EN
