Regulations are forcing organizations to address software supply chain security

There’s a prevailing trend to force organizations into looking more closely at their Cybersecurity – Supply Chain Risk Management (C-SCRM). Key regulations both here in the U.S. and EU are beginning to require more certifications, reporting, and direct responsibility by both government and private entities as well as software manufacturers.  All of these are aimed at enhancing trust and resilience in supply chain security.

More regulations

First let’s look at why there’s more of a push to bolstering standards and adding more regulations relevant to C-SCRM. In today’s interconnected landscape, organizations rely on suppliers and vendors having real-time access to systems and physical devices. In the operational technology (OT) world this often means vendors having access to maintain and support systems such as power generation plants, water treatment, and automated manufacturing equipment. For many manufacturers or utility companies this may mean access from multiple vendors all with their own supply chains and risks.

These multiple vendors in a distributed supply chain present some significant risks based on today’s threat landscape. Recent compromises involving supply chain attacks include:

1.  Malware injections: Attackers insert malicious code into software during development or distribution.
2. Compromised updates: Legitimate software updates are tampered with to include malware.
3. Third-party vulnerabilities: Weak security practices of third-party vendors can expose the entire supply chain to risks.

These vulnerabilities are coupled with Island Hopping attacks where vulnerable third-party vendors that are compromised can be used as jumping off points into customer networks. Add to that the fact that multiple vendors accessing a network multiplies these risks. It’s clear that strengthening the cybersecurity practices along the supply chain is critical to minimizing the inherent risk in a multi-vendor environment.

Evolving risks, evolving standards

To that end, many of the standards that cover C-SCRM are evolving to keep pace with these increasing risks. It’s clear however that just providing guidelines and frameworks without incentive to implement doesn’t always work. Some new directives and standards are moving to more enforcement of certifications and shared responsibility for supply chain security to address the slow implementation of current cybersecurity practices.

Let’s look at two new standards introduced by the European Union (EU), the Cyber Resilience Act (CRA) and the National Information and Security Directive (NIS2).  

The CRA agreement, which received formal approval by the European Parliament in March 2024, covers cybersecurity from a product manufacturer perspective. Products with digital elements will be expected to provide conformance testing to the standard and in some cases for digital elements classified as important or class II, third-party verification will be required. Requirements include: 

• vulnerability management during the product lifecycle requires manufacturers to ensure regular testing for vulnerabilities and remediation is performed
• the capability for automatic security updates.  Software updates will need to be provided as security only patches with no feature updates to make updates more frequent and less impactful on customers.
• timely notification to CSIRTs and ENISA for adequate overview of vulnerabilities and assessments and disclosure to the European vulnerability database when appropriate,
• support of product for updates and documentation for a minimum of 10 years after release.

In addition, enforcement articles in CRA provide for surveillance authorities to request relevant software bill of materials (SBOMs) to determine software dependency assessments for categories of products.

This is just a sampling of some of the key requirements in the CRA agreement but highlights key legislation that begins to look at the software development life cycle (SDLC) and instilling good practices from an early stage on the development/manufacturing side.

NIS2, on the other hand, focuses on the end user or enterprise entity ensuring proper risk management techniques are enforced in the deployment of cyber technologies. The NIS2 directive builds on the original NIS directive. All EU member nations will have passed legislation enacting NIS2 directives into national law by Oct. 17. While the EU Cyber Security Act focuses on national entities, NIS2 also applies to private organizations. NIS2 has two major impacts for private organizations:

• Implementing a defined risk management strategy (Article 21)
• Reporting of significant cybersecurity incidents within 24 hours of discovery with requirements for follow up in 72 hours and 1 month with remediation and detailed final report.

Additionally, NIS2 includes personal responsibility for top management if gross negligence is found and larger administrative fines for non-compliance. Ensuring failure to implement proper procedures has fines and responsibilities attached that will assist in making sure the C-SCRM occupies a key place in an organization’s management strategy.

From the U.S. perspective, the CMMC framework, introduced by the U.S. Department of Defense (DoD), is targeted at enhancing the security posture of private corporations that form part of the Defense Industrial Base (DIB). It includes five maturity levels for organizations to achieve based on the contracts being bid on for government work. Each level has specific cybersecurity practices and processes that must be met. Without complying to the CMMC framework, organizations will not be allowed to participate in new contract opportunities going forward.

These regulations provide a good example of the need to address both sides of the cybersecurity software supply chain and apply financial and/or reporting requirements for enforcement. There are many other regulations that affect the C-SCRM process, but many existing regulations are guidelines and frameworks without reporting or enforcement requirements.   

What can manufacturers do?

From a manufacturer perspective, ensuring good practices and frameworks are put in place early in the SDLC is key. Developing software that is inherently secure and kept up to date with new vulnerabilities provides products that are less susceptible to known attacks. Making sure software products can be easily and automatically updated ensures that as new vulnerabilities emerge customers can keep pace with security updates. To that end, directives such as CRA are a good attempt at trying to drive better processes in the software manufacturing side of the supply chain.

In looking at the overall enterprise supply chain, regulations such as NIS2 and CMMC are forcing more ownership of C-SCRM practices.  By driving financial penalties in the case of NIS2 and access to financial opportunities or the lack of in the case of CMMC these regulations have a bit more teeth than previous attempts. 

Of course, the downside of additional regulations with reporting, certification, and financial penalties could be the stifling of innovation as smaller companies cope with the expense and requirements.  Some of this pushback was seen by the open-source community with CRA where some significant concessions were won for open-source software with exemptions from many of the CRA directives.  Whether these regulations begin to have an impact on C-SCRM going forward remains to be seen.

About the author

Bill Cantrell

Bill Cantrell is the CPO and COO of XONA Systems. XONA enables secure user access that's purpose-built for operational technology (OT) and other critical infrastructure systems.

SC
MR