The EU’s growing focus on SBOMs, highlighted in ENISA’s SBOM Landscape Analysis – Towards an Implementation Guide, is a key step toward greater transparency and resilience in software supply chains. SBOMs are rapidly becoming a central building block for cybersecurity governance under the Cyber Resilience Act (CRA) and related frameworks.
From Bitsea’s perspective, this direction is both necessary and overdue. SBOMs provide a shared factual basis for what a product contains, its dependencies, and potential security or compliance risks. Implemented well, they speed up vulnerability assessments, improve incident response, and clarify communication across technical, legal, and organizational teams. They also give regulators and customers a clear view of an organization’s control over its software.
Bitsea has also shared feedback with ENISA on practical considerations needed to make SBOM guidance effective in real-world use.
Moving from Conceptual SBOMs to Practically Usable Ones
One key observation is that SBOMs often describe software at a very high level, focusing primarily on complete components or packages. In practice, however, modern software development frequently involves partial reuse, individual files, directories, or code fragments extracted from larger projects. This form of reuse has direct implications for licensing, copyright attribution, and security exposure. A practically usable SBOM should reflect partial components and fine-grained reuse, instead of assuming that software is always used as complete, versioned packages.
Closely related is the widespread informal reuse of code snippets, including those copied from public forums or knowledge-sharing platforms. Such snippets may be subject to copyright, carry licensing obligations, or embed known vulnerabilities. While this type of reuse is rarely intentional non-compliance, it represents a real and recurring risk. Bitsea emphasizes that SBOM guidance should acknowledge this reality and encourage organizations to include it in their software inventory and compliance processes.
Beyond Source Code: Accounting for Non-Code Artifacts
Another important consideration is that software products rarely consist of source code alone. Documentation, configuration files, images, fonts, media assets, and other non-code artifacts are routinely shipped as part of software distributions. These elements carry their own licensing and IP constraints, creating legal and operational risks. Bitsea recommends expanding SBOMs beyond source code to include such artifacts. A common example is including an open-licensed font in an application, firmware, or documentation. Widely used fonts under the SIL Open Font License (OFL) allow embedding, modification, and redistribution, while requiring copyright notice preservation and restricting reserved font names.
AI-Generated Code and Emerging Provenance Risks
ENISA’s report acknowledges AI-generated code as a limitation and challenge, but Bitsea believes this topic needs stronger emphasis. In practice, AI-assisted development is already a significant factor in many codebases. AI-generated outputs may closely resemble existing open source components, sometimes without clear attribution or identifiable licensing context. This raises novel questions around provenance, compliance, and risk allocation. At a minimum, SBOM guidance should raise awareness of these risks and recommend measures for identifying and managing AI-assisted or AI-generated code within SBOM-driven workflows.
SBOMs and License Compliance: Foundation, Not a Shortcut
Organizations must understand SBOMs as foundational data structures, not as a replacement for established compliance obligations. While an SBOM lists components and licenses, most open-source licenses still require human-readable notices, attribution, and access to corresponding source code (CCS). SBOMs are most effective when they serve as the authoritative inventory for generating compliant notices automatically or semi-automatically.
Beyond Security: SBOMs Must Also Address Licensing Obligations
ENISA’s report rightly acknowledges the purpose of an SBOM also includes license compliance. However, the CRA emphasizes the role of SBOMs primarily in the context of vulnerability tracking, risk mitigation, and security updates, showing only one dimension of SBOM utility. IIn practice, a complete and accurate SBOM captures the legal metadata for each component, most critically the license or licenses under which an organization uses it.
This broader interpretation reflects established industry practice, as defined by standards such as SPDX, CycloneDX, and OpenChain ISO/IEC 5230, and enables organizations to meet additional legal and contractual obligations, including:
- License attribution and notice compliance
- Copyleft license obligations, including source code disclosure triggers
- Commercial and IP due diligence in vendor, customer, and M&A contexts
In short, license compliance and vulnerability management are two sides of the same SBOM coin.
From a compliance and operational perspective, organizations preparing SBOMs for CRA or security obligations must treat license data as essential, not optional. Failing to track licenses can expose them to legal liability, especially in complex supply chains or regulated industries.
ENISA also notes that in regulated contexts—such as export-controlled, classified, or safety-critical systems—full SBOM disclosure may be legally or operationally impossible. This limitation does not reduce SBOMs’ value; instead, it underscores the need for controlled, audience-specific SBOM practices that balance transparency with regulatory constraints.
Way forward
None of these considerations undermine the value of SBOMs. On the contrary, they highlight why SBOMs must be treated as living documents, capable of evolving alongside real-time development practices. ENISA’s effort to provide implementation guidance is a critical step toward harmonising expectations across Europe, particularly for organisations operating with limited resources.
Bitsea welcomes this initiative and has provided feedback. SBOMs are not an end, but a critical foundation for effective software supply-chain governance under the CRA and beyond. When granular and integrated into workflows, SBOMs turn software from an opaque risk into a transparent, manageable, and governed asset.
At Bitsea, we focus on this intersection: analyzing SBOMs and dependency data, auditing open-source and build artifacts, and helping organizations turn regulatory requirements into sustainable engineering and compliance practices.
Next Post