In March 2023, the U.S. White House unveiled their National Cybersecurity Strategy, which aims to shift liability for cybersecurity onto software products and services. Software companies are going to shoulder more liability for the security of their products (and customers) than ever before, and your organization’s risk register needs to reflect this.
On July 26, 2023, the Securities and Exchange Commission (SEC) adopted final rules regarding cybersecurity disclosure that should be of interest to every public company.This move underscores the increasing importance of cybersecurity in corporate governance and risk management.
In recent years, hackers have caused considerable damage by finding vulnerabilities in open-source libraries that developers rely on. This gives them access to not only the core libraries but also the software that people have built on top of the exploited open source code.
Whereas supply chain security has been around for a long time, software supply chain security is a relatively new discipline. But although the threat of a software supply chain attack is new, it’s still incredibly dangerous. For example, the 2020 SolarWinds breach exposed organizations such as Microsoft, Intel, and even the U.S. Department of State.
And software supply chain attacks like these are only becoming more frequent.
(Source: Usenix)
Because of this mounting threat (and the resulting increase of government regulation), board risk and audit committees need to ensure that software supply chain security is included in their risk registers.
External factors pushing software supply chain security into risk registers
While the rising threat of third-party vulnerabilities should be reason enough to consider this discipline in your risk assessments, several other factors are pushing boards to increase their attention to software supply chain risks, namely: government regulation and thought leadership in the tech space.
Governments are making software supply chain security a priority
In May 2021, U.S. President Biden issued an executive order calling for enhanced software supply chain security, including specific callouts for companies selling into critical sectors to provide purchasers with software bills of materials (SBOMs) and participate in a “vulnerability disclosure program” (Sec. 4.e.vii–viii).
And the aforementioned 2023 National Cybersecurity Strategy aims to “rebalance the responsibility to defend cyberspace by shifting the burden for cybersecurity […] onto the organizations that are most capable and best-positioned to reduce risks.”
This shift isn’t limited to the U.S., either. In 2022, the Canadian House of Commons introduced Bill C-26, which also introduces new responsibilities for software vendors.
Tech companies and consultants are introducing best practices and frameworks
Non-regulating entities are recommending better software supply chain security practices, too. Days after the White House published Biden’s 2021 executive order, the Cloud Native Computing Foundation released a 45-page paper detailing software supply chain best practices.
In an accompanying press release, CNCF Security TAG co-chair Emily Fox stated that “it is critical that organizations and open source communities seriously consider not only what their software does but the mechanisms by which it comes to be. […] Now is the time to thoughtfully consider a better, more secure end-to-end architecture responsible for our innovations.”
Two months later, Google introduce their SLSA framework, which “formalizes criteria around software supply chain integrity, to help the industry and open-source ecosystem secure the software development lifecycle.”
Beyond this, consulting firms such as EY and KPMG have begun bringing up these and other frameworks for their advisory clients, and we expect them to do so even more in the wake of Biden’s 2023 National Cybersecurity Strategy. In fact, if you use a consulting firm for risk assessment and they haven’t brought up software supply chain security yet, now’s a good time to put it on their radar.
How to make sure your risk register addresses software supply chain security
With both threats and regulations on the rise, you can’t let this area go unchecked in your organization. Here’s how you can make sure your risk register accounts for the security of your software supply chain.
-
Check your current risk register. If it isn’t already represented, put this on the agenda for the next time your risk and/or audit committee(s) evaluate the document.
-
If it is on the register, make sure software supply chain risks are nested in the most sensible category for your organization. For most organizations, software supply chain security most logically falls under operational risks and can be treated as another cybersecurity activity. But for organizations with very mature supply chain management practices, it may make sense to group this under general supply chain security risks.
-
Require your software vendors to provide SBOMs. A software bill of material lists all the components and subcomponents your vendors use in the applications they sell you—which makes it easier to keep tabs on vulnerabilities you might be exposed to. You can begin by taking inventory of your current software vendors and requesting SBOMs from them. Then, build SBOM requests into your purchasing processes for future vendor relationships.
-
Ensure your organization is using a capable software composition analysis (SCA) tool. An SCA will scan your applications for any known third-party vulnerabilities—and a good SCA will give your developers guidance on prioritizing and fixing them. (For details on the most important criteria to consider in this type of solution, see our SCA buyer’s guide.)
-
Have a plan for handling unfixed vulnerabilities. Today, most companies have known vulnerabilities in their codebases—and yours probably does, too. These vulnerabilities may persist because open-source authors haven’t created patches for them yet—or because development teams simply don’t have the time or resources to fix them. No matter how a vulnerability stays in your system, you need a plan for addressing them and minimizing your risk exposure.
MergeBase’s Dynamic Application Surveillance and Hardening is especially effective for that last step. This feature scans your live application for vulnerabilities, and when a vulnerability is detected, MergeBase simply blocks people from taking the actions necessary to exploit the vulnerability.
Software supply chain security belongs on your risk register
Your organization needs to protect your code, your customers, and end users from the risks posed by third-party vulnerabilities in your software. You also need to be prepared for shifts in regulations and liability law. Soon every software company will need to improve their risk maturity—it’s smart to start improving yours now.
Making sure your software supply chain is represented on the risk register is a good start.
If you want an effective tool for protecting your applications from third-party vulnerabilities, MergeBase can help. Book a demo to see how our SCA tool can help you secure your software supply chain and keep your runtime applications safe from known vulnerabilities.
How mature is your DevSecOps? Take our complimentary DevSecOps Maturity Assessment to gain valuable insights into your current approaches, identify areas needing improvement, and emphasize the importance of advancing your DevSecOps maturity.
