A software bill of materials is an indispensable mechanism for securing a software supply chain, as we found out in our previous article. So much so that governments explicitly demand the SBOM adoption via legislative acts that sprouted across the globe over the past few years in answer to growing cybersecurity threats.
This article provides an overview of the U.S. and EU regulatory landscape concerning SBOM adoption for cybersecurity fortification. It doesn’t give legal advice and only provides a general overview of the topic.
Table of Contents
U.S. Legislation
Executive Order 14028 on Improving the Nation’s Cybersecurity
One of the most well-known U.S. legislative documents concerning cybersecurity — Executive Order on Improving the Nation’s Cybersecurity — was released in May 2021 in response to the alarming increase of cyberattacks on software supply chains. The most devastating and far-reaching was the SolarWinds attack that affected over 18,000 customers and hundreds of organizations worldwide, including the U.S. federal agencies.
The Executive Order describes various measures to secure software systems utilized by federal agencies. Therefore, it relates to informational or operational technology service providers contracted by U.S. governmental bodies.
One of the cybersecurity goals set forth is to increase the transparency of software supply chains. This will raise awareness of present vulnerabilities and help IT teams react promptly to their appearance. For this purpose, service providers must
- Secure software development environments by applying multi-factor authentication (MFA), encrypting data, documenting and minimizing dependencies, etc.;
- Employ tools or processes to maintain trusted source code supply chains;
- Implement automated tools to scan for and remediate known vulnerabilities;
- Maintain precise and up-to-date data on software components’ origin;
- Provide a software bill of materials for each product;
- Follow the secure software development practices;
- Ensure and attest to the origin of utilized open-source software to the extent practicable.
As you can see, many of these measures are focused on the obligation to collect and maintain the data on known vulnerabilities and the origin and integrity of software components used in the development process and included in finished products.
Although the document concerns only vendors working with the U.S. government, the practices described above are helpful for all ISVs because they help to continuously monitor the security of software during development and after deployment, implement patches on time, steer clear of libraries of unknown or unverified origins, and thus minimize the risks of cyberattacks.
DHS Software Supply Chain Risk Management Act
The DHS Software Supply Chain Risk Management Act of 2021 obliges contractors to the Department of Homeland Security to provide a software bill of materials with their IT products or services. In addition, they must provide the certificate that each item in the SBOM is free of known vulnerabilities, a list of all vulnerabilities present in the technology, and a plan to mitigate or reserve them.
FDA medical device cybersecurity requirements
The U.S. Food and Drug Administration (FDA) raised concerns about the insufficient security of medical devices in response to the increased number of cyberattacks on healthcare institutions. The agency was pushing for legal cybersecurity requirements for medical device manufacturers, including the provision of an SBOM.
As a result, the Consolidated Appropriations Act of 2023, signed on December 29, 2022, includes Section 3305, which gives the FDA the authority to regulate the cybersecurity of medical devices. The Act amends the Federal Food, Drug, and Cosmetic Act that now has a 524B section, “Ensuring Cybersecurity of Devices,” which forces the applicants submitting an application to the FDA for a medical device containing software that connects to the internet to
- Submit a plan for monitoring and addressing postmarket cybersecurity vulnerabilities;
- Design and maintain processes for ensuring medical device cybersecurity, including timely postmarket integration of patches for known vulnerabilities;
- Provide a software bill of materials that includes data on commercial, open-source, and off-the-shelf software components;
- Comply with other requirements the FDA may put forward.
These cybersecurity requirements are applicable to applications submitted starting March 29, 2023. However, if the device was previously authorized, but the manufacturer introduced changes that require a new premarket review, then the requirements apply to the new submission.
The FDA will cooperate with organizations that do not have outlined plans for the remediation of discovered vulnerabilities to help them improve their cybersecurity documentations. But starting October 1, 2023, the FDA will not accept submissions from companies without a remediation plan.
BellSoft will provide a software bill of materials with Liberica JDK to help companies developing Java applications comply with the regulations. Contact us to learn more about the service.
European Union cybersecurity requirements
Although some European countries such as Finland and Germany have already introduced specific cybersecurity requirements on the legislative level, the main document applicable to all Member States is the Cyber Resilience Act (CRA) proposed by the European Commission.
The EU Cyber Resilience Act (CRA)
The EU Cyber Resilience Act, proposed on September 15, 2022, is the first EU-wide legislation addressing cybersecurity requirements for software and hardware manufacturers and developers with digital elements connecting to the internet. In contrast to the U.S. Executive Order, the CRA extends to all vendors who place their products on the EU market.
The European Commission sees two main reasons for a growing number of cyberattacks: the spread of vulnerabilities coupled with the lack of timely updates and insufficient access to the information by users, preventing them from choosing more secure products.
Consequently, two key goals of the CRA are:
- Establish the conditions for the development of products with fewer vulnerabilities and ensure that vendors make security a priority throughout the whole product life cycle;
- Raise awareness among users about the importance of cybersecurity, helping them to select and use sufficiently secure products with digital elements.
To achieve these goals, the European Commission sets forth essential requirements for manufacturers of digital products, who should among other things
- Ensure that their products are delivered without known vulnerabilities;
- Notify the European Union Agency for Cybersecurity (ENISA) about known exploited vulnerabilities and any cybersecurity incidents affecting the security of their products;
- Notify the maintainers of software components, including open source ones, on discovered vulnerabilities;
- Implement vulnerability disclosure policies to facilitate vulnerability reporting;
- Identify and document the components of a digital product, including by drawing a software bill of materials.
The CRA stresses the importance of an SBOM in the following statement (Article 37):
“A software bill of materials can provide those who manufacture, purchase, and operate software with information that enhances their understanding of the supply chain, which has multiple benefits, most notably it helps manufacturers and users to track known newly emerged vulnerabilities and risks. It is of particular importance for manufacturers to ensure that their products do not contain vulnerable components developed by third parties.”
The document includes additional requirements to the SBOM generation. Firstly, it should cover, at the very least, the top-level dependencies of the product in a commonly used and machine-readable format (Section Two, Annex I). Secondly, the European Commission may specify the format and SBOM elements, as well as the additional information, format, and procedures pertaining to notifications on vulnerabilities and incidents (Section 63).
The non-compliance with the CRA requirements is subject to fines up to 15 000 000 EUR (Article 53).
Although the CRA has not been passed yet and is therefore subject to amendments, two things are clear:
- Manufacturers are obliged to gather information about software components they use in development, including data on vulnerabilities, and
- As soon as the CRA gets adopted, it will significantly impact all software vendors working on the EU market.
Recommendations
The rapid increase of legislations and initiatives promoting vulnerability identification and tracking shows the worldwide tendency towards greater transparency of software supply chains. And although drawing up an SBOM is not yet legally binding on all software vendors, the situation will likely change.
What should you do if you are already among vendors obliged to follow the regulations?
- The first step is to draw up a plan on managing the vulnerabilities and exploits,
- The second step is to develop and implement the process of vulnerability management based on the plan,
- Finally, generate an SBOM in one of the recognized formats.
BellSoft can assist you at the planning stage if you want to migrate to reliable and secure JDK and Linux distributions with clear licensing conditions and LTS support from one vendor, delivered as part of Alpaquita Cloud Native Platform.
Alpaquita Cloud Native Platform will become a part of your processes as a comprehensive solution for Java applications, developed in line with the Secure Development Lifecycle (SDL) practices and receiving regular security patches guaranteeing that both Linux and Java are free of known vulnerabilities. We provide our own supply channels for builds, binaries, and metadata, as well as a software bill of materials, helping you to keep your Java infrastructure secure and comply with the regulations. Contact us to learn more about the services.
