© 2026 Peter N. M. Hansteen
The European Union Cyber Resilience Act (CRA) and its various international analogs are entering fully into force during 2026 and 2027, with new legal requirements that some have found to be perilous or challenging to software developers and possibly for open source developers in particular.
Some have predicted this legislation will be the end of open source software and the end of the world as we know it. In the present article, we will show that this is far from the case.
As we have mentioned in several earlier articles and presentations which I will provide links to in a moment,
On December 12 2027, it's already too late. The day before, the European Union Cyber Resilience Act (CRA) will have fully entered into force.If you are interested in what this means in practical terms, for individual developers, for organizations that have taken on the free software steward role, and for other participants in the wider community or ecosystem of the IT industry, read on.On December 11 2027, the Cyber Resilience Act is fully in force in the European Union member states and associated countries and territories.
From that date onward, suppliers of any "product with digital elements" are required to present those products along with a full overview and insight into all components and dependencies that went into making that product.
If you are a manufacturer or supplier of any "product with digital elements" are required to present those products along with a full overview and insight into all components and dependencies that went into making that product.
Unless, of course, you are a supplier that is fine with being considered at best second rate, or even being ineligible for lucrative contracts. Selling product that has not qualified for the CE mark for its product category will simply not do.
The European timeline for phased implementation of the CRA is outlined here, among other places.
From EU CRA: It's Later Than You Think, Time to Engineer Up! (also here)
The European Union Cyber Resilience Act is part of an expanding body of legislation, which includes General Data Protection Regulation (GDPR), Regulation of the Digital Operational Resilience of the Financial Sector (DORA), and Directive on Network and Information Systems (NIS2), that regulates information technology and products with digital elements in the European Union, associated states and territories.
The underlying motivation is to ensure the safety, wellbeing and civil rights of inhabitants of the EU, associated states and territories. It is important to keep this in mind as the basic driver behind the regulation.
One the face of it, initiatives to ensure the safety of individuals and businesses should not be controversial. Development of new technologies lead to changes in society that neither technologists, their customers nor the politicians they elect had been able to anticipate.
We will mention some key incidents in a few moments, but taken together these incidents made it clear that there was a need to come up with well defined legislation and a firm but reasonable enforcement regime.
In the area of cyber security and digital resilience, for a long time the specification and standardization work was fairly well in sync between the European and US efforts for all the obvious reasons.
Early on, the USA was the first to enact formal legislation for the subject area in the form of the US Executive Order 14028 of May 12, 2021, Improving the Nation's Cybersecurity (2021), and the EU finally enacted their version of the legislation as the EU Cyber Resilience Act (CRA) in 2024. For both sets of legislation the plan was to have the specific parts enter into force gradually and in sync across the Atlantic.
However, it took the second Trump administration one year and nine days to rescind the US Executive Order 14028 of May 12, 2021, Improving the Nation's Cybersecurity leaving the specifications and emerging standards as optional only for projects and procurement under federal authorities of the United states.
The European Union, on the other hand, has not let up its efforts. This means that going forward, it is the European Union Cyber Resilience Act (CRA) that defines the parameters for those of us who develop products with digital elements (PDEs) intended for any international market that includes the European Union and associated states and territories.
Let's move on to what the practical consequences will be for various categories of people and organizations as the legislation enters into force.
We will take the boring parts first, move on to the scary things next, before we finally get to the fun parts.
Under the CRA, people and organizations that are involved in producing or marketing products with digital elements can be classified into several categories. For contexts where open source software plays a role, the roles that are of the most interest are,
Manufacturers: Businesses that put products on the market to be available in the EU, defined as
a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge (from CRA article 3 (13)
Crucially, the context here is that these activities are part of commercial activityCRA Article 3(22).
Open Source Stewards: Organizations that coordinate open source projects, typically foundations (not for profit corporations), defined as
a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products (from CRA article 3 (14) )
Open Source Developers and Maintainers: People who write and maintain open source software. While the CRA does not include a definition in this case, the relevant text is
for the purposes of this Regulation, the development of products with digital elements qualifying as free and open-source software by not-for-profit organisations should not be considered to be a commercial activity provided that the organisation is set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives. This Regulation does not apply to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility. (from CRA recital 18)
As we can see, there are three distinct categories, each with their specific roles and obligations.
If you are an individual open source developer, I hope by now you are reassured by the quote from CRA recital 18 that you are in fact not under any formal obligation to do anything in particular. You are free make any changes to your workflow you want as a developer, on a completely voluntary basis.
That said, the emerging legal requirements do offer opportunities that may be worth exploring. We will come back to those shortly.
Open Source Stewards, under any reasonable interpretation of CRA article 3 (14) will usually be a not for profit organization or foundation such as the FreeBSD Foundation, which operates with a purpose to support the activities of the project. Such organizations have some measure of responsibility to maintain sufficient infrastructure and organization to support such activites as bug and incident reporting and following up on any security relevant matters raised by manufacturers, the reporting authorities or the general public.
It is useful to look up CRA article 24 and recitals 17, 18 and 19 for more nuance.
As you would expect, the practical and financial responsibility for any product placed on the market lies with the manufacturer that produces and markets the product.
The manufacturer is responsible for ensuring that the product is suitable for its intended use, that it conforms with any requirements specified for its product category in the European Union, including any required specifications for its intended use. The CRA somewhat extends the requirements for product information to be made available on request, including a Software Bill of Materials (SBOM) that specifies components of the product and their dependencies.
Once a product is on the market, the manufacturer is responsible for the continued security of the product in operation, including reporting security relevant bugs and incidents to the designated authorty.
The exact parameters of the enforcement regime are still work in progress, but potential sanctions for non-compliant products and manufacturers include, depending on the severity of the matter, mandatory recall of marketed products and fines up to whatever is the greater of 15 million Euros or 2.5 per cent of the manufacturer's worldwide annual turnover for the preceding financial year (see CRA article 64).
So why was this legislation needed at all? And why does it come into force now?
Explaining why legislation of the Cyber Resilience Act mold was needed means that we will need to look at some history. There is a sequence of events that lead us to where we are, and that shaped how we see ourselves in the context of software security and software quality.
It is worth keeping in mind that during a longish stretch of recent times, software has been poorly understood by the public, generally disregarded as unimportant, or in the cases where it was at least considered not unimportant was considered to be trade secrets by the dominant players in the field, and consequently off limits to any real security or quality inspection.
One very visible consequence is that a large part of what labels itself as IT security or cybersecurity centers around selling tools scanning whatever data they can get their hands on for an ever-increasing set of malware signatures, or in the case of network traffic captures, signs of malicious activity such as probing for common misconfigurations or bugs that are known to be exploitable.
On the other hand, in the open source parts of the industry, where the source code for your system is available for study, it is possible and even encouraged to focus on code quality and code correctness.
With the source code within reach, outside reviews can and will happen if your code is interesting enough to be considered usable in environments that are different from your own.
With source in hand, some projects have even gone to the extra steps of not only improving code quality and correctness, but even creating mechanisms that would make even currently unknown bugs and misfeatures in the code harder to exploit. It is fair to say that the OpenBSD project has been particularly innovative in exploit mitigation and prevention.
The role that code quality plays in making products with digital elements robust and safe has not been lost on the people who have worked to formulate the CRA and the best practices that we are expected to adopt.
We will come back to the best practices, but first, a quick look at some recent history.
Software is a relatively recent phenomenon. For a long time, you could credibly say most of its existence, software was poorly understood by society and industry at large.
There was a time -- and I am old enough to remember that time -- when software was considered a minor, somewhat irritating but necessary, component in IT deliveries.
On the more extreme end of things, you would occasionally hear that software was not at all important, literally just a bit of typing.
All the while it was ever more clear to developers and practitioners that the software was what made all that expensive hardware useful. But software was all ephemereal to most and in almost all cases the source code was secret, and the customer was expected to just accept whatever came you way as-is.
That perception changed over time, and during recent decades it is no longer in doubt that the software industry is just that, an industry in its own right.
Still, in the pre-Internet age, keeping your source code hidden from the world as a trade secret was seen by large parts of the industry as the key to generating revenue and necessary and even sufficent for an acceptable level of security.
Then, as some of us still remember, the Internet happened.
Few people realized it at the time, but this was the time in history when two important things happened at roughly the same time.
For one, it became obvious to developers at least that the infrastructure we all have come to rely upon owes its strength and resilience to the fact that it consists mainly of software that was built on standards built on rough consensus and working code, code that was open source.
The other thing that happened, was that software products became exposed to the Internet, those products found themselves facing the full force of the entire world banging away at their keyboards.
Some of those keyboards were operated by people who intended to do bad things.
A significant subset of the devices that appeared on the Internet ran software that was clearly not designed for secure operation in a connected environment.
Eventually, bad things started happening.
Over the years, eventually enough episodes piled up that software security, sometimes discussed under other labels, started becoming an issue.
During the twenty-tens and -teens, we had several incidents where software bugs were tickled enough to lead to costly and embarrasing episodes.
Some of these episodes were grave enough that the powers that be (the kind wearing suits) discovered that software was indeed something they needed to care about.
At the time, there were commentators from both camps who seemed surprised to learn that open source and closed source software both demonstrably had exploitable bugs.
In the early days of the Internet age, and to some extent still, we have often been faced with claims that open source software could either never be as secure as proprietary software, or that open source software was inherently more secure than the closed source kind, because "given enough eyes, all bugs are shallow".
Both assertions fail because even without access to source code, it is possible to probe running software for vulnerabilities, and on the other hand the shallowness of bugs depends critically on the eyes looking being attached to people with sufficient competence in the field.
The public reactions to a couple of security incidents during recent years that generated a flurry of largely uninformed punditry, are worth revisiting for the lessons that can be learned.
Some incidents of note are,
The Solarwinds supply chain incident, also known as SUNBURST (2020) - One of the most widely publicized yet mostly quite poorly understood security incidents in recent years emerged when it was revealed that adversaries unknown had been able to compromise the build computers where the binaries for their widely used network management software was built for distribution.
The SANS institute has produced a fairly thorough writeup of the incident, which breaks down as follows:
The first stage of a multi-stage compromise kit was included in binary distribution packages, complete with authentic signatures from the build system, that were largely put directly into production environments by network admins everywhere. The malware then went on to explore the networks they landed in, and through a process that made heavy use of crafted DNS queries and other non-obvious techniques, the miscreants were able to compromise several high security government and enterprise networks.
Several open source component supply chain incidents (2020 onwards) - Soon after the SUNBURST incident several incidents occured where popular open source components that other systems pulled in as dependencies started malfunctioning or were suddenly unavailable, causing complete malfunctions or loss of functionality such as a web service suddenly refusing to interact with specific networks.
The sudden breakage in open source components caused quite a bit of uproar, and predictably the chattering subset of the consulting class set about churning out dire warnings about the risk of using open source of any kind.
Watching from the sidelines it struck many open source oriented professionals, myself included, that the combination of these incidents carry an important lesson. It is obvious in a modern environment we suck in upgrades automatically and frequently, and that no untested code should ever be deployed directly to production.
Blind trust versus the right to read (and educate yourself) and the right to repair - In the case of proprietary, binary-only software, you have no choice but to trust your supplier and that they will address any defects in a timely manner. The upshot is that with proprietary, binary-only you do not have access to two important features of open source software: The right to read and study the code, and the right to repair any defects you find, potentially saving yourself potential service shutdowns or workarounds while the secret parts of your system get fixed elsewhere.
The lesson to be learned is that you need to run quality assurance on your supply chain. You may choose to trust, but you still need to verify. That goes for open source and proprietary software both.
These episodes spurred several things, one being memes like
(XKCD #2347, please also read the explainer), which lead to the common belief that supply chain management and the subtopic dependency management is mainly a problem that concerns open source software.
As we will see, that assertion does not hold. Even with products that are made up of proprietary parts that their manufacturers want to treat as much as possible as trade secrets, we know that no project is an island.
Whether you let others see the code you wrote or not, the software does not exist in isolation.
The XKCD comic struck a chord with open source developers, who at the time were a lot more in tune with the world of software dependencies than most other people.
By the way, this slightly modernized version
is likely more in tune with the day to day experiences of developers and maintainers of products with digital elements (PDEs).
Or you may feel this is more appropriate:
With all this as the backdrop, now let us return to the base starting point of it all: our source code. We will see how this all fits together to make an ideal setting open source as proper engineering.
For individual developers, the question becomes something more along the lines of "Do you know what your code does?", or even "Do you know everything your code does?".
To put it bluntly, whether you answer to either of these is a clear yes or no determines whether you are just a coder or an engineer who codes.
The purpose of this session is to help you move towards becoming the latter. To start you upping your engineering game.
To set the stage for what real engineers (should) do and to keep focus on the importance of doing things right, the anecdote of the Canadian engineers' iron ring is a useful reference.
So let's ask the question,
Dear developer, do you know what your code does?
Your answer is likely to be along the lines of
Sure, I wrote it all. I know what it does.
Unless you vibe coded the thing, that is. But let's leave that particular set of circumstances for another time.
The answer I wrote it all. I know what it does is, however, unlikely to be totally accurate. Unless you are doing extremely low level stuff and your code speaks directly to the hardware, your code more likely than not also pulls in and utilizes dependencies such as system calls and library functions that provide the foundation of functionality that makes the code you wrote work.
Knowing your dependencies and what role they plain in making your code work is a significant part of delivering proper quality.
As I mentioned earlier, no project is an island.
Whether you let others see the code you wrote or not, the software does not exist in isolation.
Summing up so far,
So what we do is important. What do we do about that?
One way to handle the situation is to look at what other people who build important things do.
In other fields, the term Bill of Materials, or BOM for short, is a familiar term. The Bill of Materials is a document or set of documents that lists all component parts of a delivery.
This is the kind of document that becomes crucial in contexts where the procuring organization is geared toward accounting for everything and auditing when the supplier least expects it.
One such context could be when your organization has landed a contract to supply a backhoe, an armored personnel carrier or even a ship, and the contract requires you to specify component materials used, down to the nuts and bolts level.
For an example of the scale of things we are talking about, consider this ultra high level view of an item that was delivered to the UK Royal Navy, one aircraft carrier HMS Queen Elizabeth:
Your delivery would not be considered complete without the Bill of Materials or Manifest, even for a thing this size.
In practice, the BOM for the HMS QE and similar-sized projects would be a collection of BOMs with specifications for each of the multitude of component deliveries that make up the whole. Each supplier would be required to come up with a Bill of Materials for their delivery.
A much referenced anecdote has it that one aircraft carrier recently commisioned by the US Navy came with a BOM with more than a million entries, ranging from "(some number of) 1/4 inch bolts" to "1 Nuclear Reactor".
It is likely that the nuclear reactor came with its own Bill of Materials, possibly with somewhat restricted circulation.
For physical deliveries to organizations of some stature, a Bill of Materials has been a standard part of the process across industries as an important part of quality assurance and a fundamental part of maintenance processes.
Software, on the other hand, has traditionally not been subject to that kind of scrutiny.
In other fields of engineering, the process runs roughly like this:
You design your product, make detailed plans and descriptions of how to build the thing.
While planning and building, you keep track of all parts and components.
A Bill of Materials (BOM) for a pump that could well be a part of the HMS Queen Elizabeth could look like
Your plans and design documents will likely undergo changes during product development and assembly.
For each delivery, you create a Bill of Materials that is a required and essential part of the delivery.
The Bill of Materials (BOM) lists all component parts, to the detail level required for running maintenance.
The BOM typically also references and serves as reference for maintenance documentation.
As an aside, it is likely worth noting that the US Department of Defense's need for structured text markup in processing inventory information such as bills of materials was one of the more important drivers, albeit not the only one, behind the creation of SGML, the direct precursor to HTML and XML.
Again, for a long time, this kind of engineering practice was not seen as a requirement for software deliveries.
Handling dependencies in software is not a new thing. You probably poke around for dependencies yourself when you start looking into a new project.
You will start looking into the source code files in your project, any libraries or tools needed to build the thing would be nice-to-knows. Once you have the thing built, it becomes interesting to know what other things -- libraries, suites of utilities, services that are required to be running or other software frameworks of any kind -- that are required in order to have the thing run.
So basically, any item your code would need comes out as a dependency, and you will find that your code has both build time and run time dependencies.
Those terms will be quite familiar to users and the developers of the package manager systems for the various open source operating systems. The very same items you would recognize from a listing of package dependencies in a package management tool will turn up in our Software Bill of Materials too. Depending on the specific tool and options you use, the SBOM could contain additional information that may not be entirely relevant in a package manager context.
Under any circumstances, with package systems in place, and even vulnerability scanners available to scan for unsecure code at rest or while running, the free and open source software communities were in fact well positioned for the legal requirements when they hit. Even more, the lessons learned from package management came in quite useful in meeting and satisfying the updated requirements.
Every free operating system, and in fact most modern-ish programming languages come with a package system to install software and to track and handle the web of depenencies. You are supposed to use the corresponding package manager for the bulk of maintenance tasks.
So when the security relevant incidents hit, the open source world was fairly well stocked with code that did almost all the things that were needed for producing what became known as Software Bill of Materials, or SBOM for short.
So what would a Software Bill of Materials even look like?
Obviously nuts and bolts would not be involved, but items such as the source code files in your project, any libraries or tools needed to build the thing would be nice-to-knows. And once you have the thing built, it becomes interesting to know what other things -- libraries, suites of utilities, services that are required to be running or other software frameworks of any kind -- that are required in order to have the thing run.
The information is there in our code, and with development tools and code scanners a developer is well placed to poke around.
The next challenge it to take that information and present it in a way that conforms with the legal specification and is presented in a way that is usable for stakeholders that are not developers.
Thanks in large measure to the open source heritage of the specifications and tools, both of the commonly used SBOM specifications (SPDX and CycloneDX) consider information on licenses used in a file or project as tagging and tracking relevant items.
The tools we describe have some measure of support for tracking and reporting on licenses in use. This can be useful for flagging licenses that may be mutually incompatible or even incompatible with your organization's business goals.
In addition to adding another set of tools to the quality assurance suite, the name of the SBOM game is compliance with the legal requirements set out in the CRA and its analogues. The task here is not only to generate the information -- that's the relatively easy part -- but also to present the information in a way that is understandable and actionable to stakeholders who are not themselves software developers.
As I hinted at earlier, there are tools available for all of this. If you want to go on and explore for yourself, I would recommend going to the awesome-sbom site, which offers a curated collection of SBOM resources and tools hosted as a Github repo.
There are a large number of tools available, with varying feature sets. In addition to the free tools you find via that collection, several tool suites exist that are exclusively commercial or with free trial or reduced features set versions out with full features available only to paying customers.
The tool set I found the most accessible for my own poking around was the combination of syft for generating SBOMs and bomber for display and presentation.
Another popular and quite capable tool is cdxgen, which supports a significant number of langages and BOM formats.
The home pages for those tools and numerous others are linked from the awesome-sbom collection.
As you can see from that page, there are several SBOM formats around, with standardization and interoperability efforts in progress.
These efforts have however not reached the point where the competing and to some extent complementary SBOM spesifications (SPDX and CycloneDX) have object definition parity, but for large subsets of possible SBOMs, conversions are possible.
For the most part, more common tools support both specifications.
If you are a BSD developer or other free software developer, getting started on your CRA compliance journey could be as easy as installing a suitable SBOM generating tool and adding the generating step to your build pipeline.
Unfortunately, more often than not you will find that the best of breed SBOM tools come witout a man page, but tend instead to stick their documentation in web pages somewhere close to their source code repositories.
Your first move to start exploring SBOMs for your code could be as simple as changing to the project directory and running the command
$ cdxgen -t c .
that is, assuming your project is a C language one, and take a peek at the generated bom.json.
The output becomes somewhat more legible if you run it through a pretty printer such as jq.
Once you have studied the results, and possibly gained some new insight into your project, the logical next step is to include a similar command in your build workflow.
Several of my colleagues have noted that when you come to an existing project, just generating an SBOM, especially if the project does not include one alread, gets you more and deeper insight into what the code is about.
In almost all cases, it will also be useful to have your build and deploy setup feed the SBOM to an SBOM management tool such as DependencyTrack.
That tool is one of those rare pieces of free software that is also quite appeling to stakeholders who are not themselves developers.
The purpose of the CRA and related legislation is to make sure products that are put on the market are safe to use.
The Software Bill of Materials is a key tool, for quality assurance in development, and for any formal certification processes may be needed for some classes of products with digital elements.
As we mentioned earlier, unless your software only interacts directly with the hardware it runs on, even proprietary, trade secret protected products have dependencies. Those dependencies may be for open source and free software or even other proprietary products.
The CRA has language that makes it possible to keep the SBOM information under wraps and available only upon request from stakeholders with a need to know.
For developers, stewards and manufacturers with products that are all or mostly open source, the SBOM, by contrast, is a tool for transparency as well as quality assurance.
It should be fairly obvious that for transparency, open source based products have the clear advantage.
So far we have focused on the background and covered some of the tools that are available for developers who work on creating and maintaining the code.
However, for essentially any product will be relevant for CRA compliance, several parts of the organization with people who are not developers need to be involved, and they will need tools.
One one fairly popular SBOM management tool is DependencyTrack, created and maintained by The OWASP Foundation, available under the Apache 2.0 license. DependencyTrack comes with a web frontend that provides easy overview of uploaded SBOMs, including views such as dependency trees, CVE and known vulnerability listings, all with intuitive color coding schemes. It also interfaces well with various build processes, including common CI/CD systems.
Other tools with similar feature sets may be emerging, but I would recommend setting up a DependencyTrack instance for internal use for all teams who are starting to explore SBOMs and dependency tracking.
The state of CRA readiness in open source projects varies. A good chunk of the tools and education work has been done under the Linux Foundation umbrella, and the FreeBSD Foundation is sponsoring CRA readiness activities in their project. For other individual projects it is perhaps most appropriate to say that awareness and readiness is improving.
The traditional development workflow in the BSD projects tends to be that base system components that have their upstream outside the projects are periodically imported into the project source tree as a fork off the origin and integrated with any necessary local changes. In between largely manual code import and review during the development of a specific release, any code in the tree is treated as integral to the self-contained project.
Traditionally, and I think still for all the major BSDs, the principle that all the tools that are required for building, developing and maintaining the operating system itself should be part of the system and preferably in the default install sets.
If you are a part of the OpenBSD community, you will be familiar with the phrase
"/bin is full."
which to some extent applies to all the BSDs. This should be taken to mean that including more items in the base system is a decision that is not taken lightly.
For SBOM tools, this becomes an important barrier, since the majority of the tools available are written in and for the younger languages such as go, java, javascript, python and others, while the Unixlikes are mainly C with a smattering of other languages such as perl and, of course, shellscripts.
Several of the more popular and capable tools such as syft or cdxgen are able to generate SBOMs from C source, and could be set to generate SBOMs for entire operation systems, given sufficent memory resources. However, since the tools are not themselves C code (syft is 98.9% Go, while cdxgen is 95.7% Javascript) it is unlikely that any of these tools will be added to the base system in any BSD.
Perhaps at least partially for those reasons, as far as I am aware, NetBSD and OpenBSD have not announced any specific activity intended to reach CRA compliance.
Manufacturers who base their products on OpenBSD or NetBSD would have the option to generate SBOMs for the base system, or if they make local modifications, generate the data from their variant builds along with data for any third party or locally developed additions.
Among the three major BSD projects, apparently FreeBSD is the one with the more public stance on the legislation. In a blog post dated 25 February 2025, Getting ready for the Cyber Resilience Act, the FreeBSD Foundation outlines the initiatives it sponsors in order to make FreeBSD CRA ready.
Tooling for SBOM generation, NetBSD pkg-config, leveraging existing package management technology, is being prepared for inclusion in the default FreeBSD install. The full toolchain as well as a full SBOM for the system itself is slated to be included in FreeBSD 16, which is expected to be released roughly in time for the CRA enters fully into force.
If you have read this far, you have probably realized that European Union Cyber Resilience Act (CRA) and its various international analogs do not spell the end of free and open source software or the world as we know it.
Rather, the new legislation creates a legal framework that is, at least potentially, extremely beneficial to well engineered free and open source software.
The CRA is a sign that at least in the European Union, software engineering is now treated as a proper branch of engineering.
Software engineers are now considered proper engineers, and we are expected to engineer up and rise to the challenge. Free and open source software engineers are used to and welcome transparency, and the CRA does not place any further burdens on the engineers who offer their work openly and transparently to the world.
The key for BSD developers and other software engineers to make sure we have earned the trust that is afforded to us as proper engineers.
This is a lightly curated list of resources for further study:
Linux Foundation Training:
Automating Supply Chain Security: SBOMs and Signatures (LFEL1007) a short but information- and reference-filled introduction (free, requires registration, gives you a badge at the end)
Understanding the EU Cyber Resilience Act (CRA) (LFEL1001) Focused on the EU CRA, gives an overview with lots of useful references, nominally a 1 hour course worth taking
Cyber Resilience Act at the official European Union site (full text of the act is here
European Union Cyber Resilience Act (CRA) resources page at the Open Source Security Foundation (OpenSSF)
The Software Bill of Materials home page at NTIA is the mother ship of SBOM documentation
Browse OWASP CycloneDX for all things about the CycloneDX specification and related tools, also their CycloneDX tool center
Browse the System Package Data Exchange specification (SPDX) for all things SPDX (supported by the Linux Foundation), including copious linked reference material
awesome-sbom is a curated list of SBOM tools and resources (mainly for techies and engineers(
Awesome CRA Compliance is a curated list of CRA compliance resources (mainly for management and legal)
Brewing Transparency: How OWASP's TEA Is Revolutionizing Software Supply Chains is a summary of recent work on OWASP Transparency Exchange API (TEA)
SBOM buyer’s guide: 8 top software bill of materials tools to consider is a readable overview of (some) SBOM tools
Olle Johansson's FOSDEM presentations are among several good SBOM talks at that conference (search the site for more)
Peter N. M. Hansteen: Open Source in Enterprise Environments - Where Are We Now and What Is Our Way Forward? (2022, also here) has some insights on how open source software plays a crucial role in enterprise environments and elsewhere
Peter N. M. Hansteen: No Project Is an Island: Why You Need SBOMs and Dependency Management (also here)
Peter N. M. Hansteen: EU CRA: It's Later Than You Think, Time to Engineer Up! (also here)
Peter N. M. Hansteen: EU CRA: It's Later Than You Think, Time to Engineer Up! (slides)
Peter N. M. Hansteen: What has (can) the EU Cyber Resilience Act done (do) for you? (this article) (also here, slides)