The last few years have seen a proliferation of cybersecurity regulations around the world. While earlier legislation in this space focused on data protection and network security (like the 1987 Computer Security Act that gave rise to NIST), recent trends have shifted toward securing the software development process itself.
This evolution began with the U.S. Executive Order 14028 for Improving the Nation's Cybersecurity. It was followed closely by the FDA’s ‘Ensuring Cybersecurity of Medical Devices’ (via the omnibus bill section 3305) amendment to the US Federal Food, Drug, and Cosmetics Act (section 524b). In Europe, the Radio Equipment Directive has been in place since 2014 and was updated with cybersecurity requirements shortly before the CRA was implemented.
At Finite State, we talk to many companies trying to navigate the increasingly complex regulatory landscape. While it’s essential to understand each regulation in detail, we've identified important commonalities across these frameworks that, once addressed, make cross-framework compliance that little bit easier.
Secure Software Development
The overarching intent of all regulations is to ensure software is developed securely through a Secure Software Development Life Cycle (SSDLC). This approach focuses on building in security upfront, including concepts like “secure by default” — say goodbye to admin/admin default accounts!
Security frameworks provide a catalog of security practices that the organization should be performing. Still, it is up to each organization to determine how to implement the controls to ensure those practices are being adhered to. The Secure Software Development Framework (NIST 800-218) and the ISA/IEC 62443 4-1 are two popular frameworks to achieve this.
Secure Software Supply Chain Security
While not explicitly required by all secure development frameworks, Software Bill of Materials (SBOMs) certainly make satisfying the requirements much easier.
For example, 62443-4-1 recommends maintaining an inventory of components from third-party suppliers and requires processes to identify and manage security risks from externally provided components (SM-9, SM-10). Having an SBOM makes it very easy to meet this requirement.
The use of SBOMs extends past just the 4-1 as it works to underpin other standards in the 62443 family. For example, both 3-3 (SR7.8) and 4-2 (CR 7.8) require “… the capability to report the current list of installed components and their associated properties” — a natural fit for SBOM implementation.
Similarly, in the ‘Produce Well-Secured Software’ section, NIST 800-153 (SSDF) encourages teams to ‘Reuse existing well-secured software when feasible instead of duplicating functionality (PW.4)’. Two tasks within this section clearly lend themselves to SBOMs.
- Task 4.1: “Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, open-source, and other third-party developers for use by the organization’s software.”
- Task 4.4: “Verify that acquired commercial, open-source, and all third-party software components comply with the requirements as defined by the organization throughout their life cycles.”
Ongoing Monitoring
Both the 62443-4-1 and NIST frameworks require teams to identify and manage risk associated with all third-party components throughout the whole lifecycle, which leads to the last area they have in common: ongoing monitoring for new risk.
While the goal is to build security in from the start, it’s not enough to say, “Well, it was secure when we shipped it, so now you're on your own.” Inventories need to be continuously monitored for emerging risks for their whole lifecycle— which in the world of IoT and OT can be years!
This is where SBOM management tools, like Finite State, come in, providing continuous monitoring for emerging vulnerabilities.
Incidentally, this same monitoring can play a crucial role in incident response when the emerging risk is particularly severe, like Zero-day announcements. Having a comprehensive inventory of all third-party software will enhance response times (and effectiveness) as it makes it easy to quickly understand which products are affected instead of wasting time on a discovery effort to track this down after the fact.
The Common Thread Between Regulations
Across regulations like the CRA, UN RED, EO 14028, and FDA requirements, we consistently see an emphasis on implementing a robust SSDLC with verifiable controls ensuring adherence to security practices. These frameworks cover a lot more than just Software Supply Chain Security. Still, in that context, we can see that the expectation is to identify and manage the risk associated with third-party components and provide ongoing monitoring throughout the product lifecycle — including the ability to respond to vulnerabilities. This can be challenging for security teams to achieve, which is where implementing the proper tooling is key.
At Finite State, we offer comprehensive solutions that help teams of all sizes address these requirements and regulatory challenges. Our platform generates and enriches SBOMs with vulnerability and threat intelligence from 200+ sources while continuously monitoring for emerging risks. Beyond the tooling, we provide services to help implement effective SSDLCs, offer consultation on regulatory implications for your business, and deliver penetration testing - to name just a few.
For more information on how Finite State can help you achieve cross-framework compliance, get in touch today.
