Come Friendly SBOMs | FreeBSD Foundation

Journal > Browser Based Edition > Improving Software Quality > Come Friendly SBOMs

Come Friendly SBOMs

Leveraging software bill of materials for your benefit and protection

Alice Sowerby

I was going to give this piece the title How I learned to stop worrying and love the SBOM but I discovered that this American witticism has already been used extensively for the topic. Instead, I decided to pivot to an altogether more British alternative based on the much-loved poem, Slough, by Sir John Betjeman which has the first line "Come friendly bombs and fall on Slough!". It was published in 1937 to lament the industrialisation of a British town near London after World War I.

The poem invites bombs to destroy the town as it had, in Betjeman’s view, become ruined and beyond rescue. I hope to draw a more hopeful parallel by inviting friendly SBOMs (Software Bill of Materials) to drop on code. Not to destroy it – there is much to love and save about the great legacy of code we work with (and starting again may be impossible) – but to support it, to improve it, and to make it safer for the world to use.

We’ll start by looking at the context that SBOMs fit into – both regulatory and cultural. I’ll discuss how we got here, why security matters more and more, how SBOMs help, and then I’ll share a deep dive into what FreeBSD is doing about it.

The entry point to our story is a software security regulation that has been brought in by the European Union. It’s called the Cyber Resilience Act (CRA). Although it may not sound very exciting, its implications are significant for software vendors and will reshape dynamics across the software industry, including open source.

The CRA specifies that anyone placing "products with digital elements" on the EU market is responsible for the security of those products. In practice, this means manufacturers must design products securely, maintain evidence that they have done so, and provide that evidence to European market surveillance authorities on request. They also have to provide the product to the consumer in the most secure state possible and, if there is any actively exploited vulnerability or security incident relating to the product, they have to meet stringent reporting and remediation timelines.

Compliance with the reporting requirements is mandatory from 11 September 2026, and compliance with the "secure by design" and "secure by default" requirements is mandatory from 11 December 2027.

The fines for non-compliance are pretty eye-watering. The highest tier of fines, which applies to non-compliance with core requirements, is €15 million or 2.5% of total worldwide annual turnover, whichever is higher.

Let’s look at why this is important now, and why this is of any interest to the humble open source developer.

The good news is that open source projects finally have regulatory backing that requires downstream manufacturers to build and maintain software responsibly. The regulation mandates the use of SBOMs and requires manufacturers to perform due diligence on the security of every component in their codebase, whether developed in-house or sourced from a third party.

The European Union Agency for Cybersecurity (ENISA) is also developing guidance on what constitutes "secure by design" and "secure by default", while market surveillance authorities are responsible for assessing manufacturers’ compliance.

If you are getting a sinking feeling about how this will shake down onto us, the little guys, there is reason for hope. Thanks to some fantastic teamwork in the open source community over the last few years, the European Commission (EC) has become much more aware and educated about the nature of open source software development and its role in the software industry. Various individuals and organisations from the open source community have been engaging with the EC as the CRA has been developed. The CRA now includes specific exemptions and protections for open source software. There are even some opportunities to develop a source of income for open source projects. Specifically, there is a proposal for a "voluntary security attestations" framework. If implemented as currently envisaged (the details are still being developed), it could create a framework that enables open source projects to charge manufacturers for security attestations.

Open source projects and their developers are not subject to the CRA, and though open source foundations may be subject to some reporting obligations, they are not liable for fines for non-compliance.

The regulatory burden and associated penalties – the big sticks – are aimed primarily at commercial manufacturers.

Perhaps the most important outcome of all this work has been that the EC now has institutional knowledge of the value of open source and has become invested in safeguarding its role in European technological innovation and sovereignty. As the EC continues to refine its guidance on the...