So, you’re a programmer and you’ve finally completed that new code, and it’s ready to be deployed. Congratulations!

You’ve done a lot to get to this point. You’ve gone through the initial design and analyzed your code for possible performance and security issues. Maybe you’ve even followed paired programming techniques to identify where logical errors might occur and allowed for the flexibility that downstream maintenance teams may require, and those code reviews were positive. You’ve been sure to include static code analysis testing and even dynamic application scanning to make sure there were no vulnerabilities that raise to the severity level that would keep you from releasing this new feature. Finally, the QA team has given its seal of approval and the code is set for the next release.

Quick question though: was there potentially one glaring vulnerability in your code—that you are about to release into the wide world of the internet—that you didn’t know was there?

If you answered, “my open-source software,” you’re probably right. Nearly all software today includes open-source software. That is, software written by someone else then released into the software engineering community to be used (and, sometimes, abused) by other members of the programming community as a shortcut to write software. In short, if you write software for a living or for a hobby, you’re probably using open-source software. Note that open source isn’t just in the purview of software developers, it’s used by operations teams and non-technical users as well.

So why is that a problem? Sonatype, a company that makes security software and writes annual reports on the state of software engineering security, says that in its 2021 report that developers were expected todownload more than 78 billion net packages. JavaScript developers requested more than one trillion packages in 2020 and the volume for 2021 was estimated to approach 1.5 trillion, a 50% year-over-year increase¹. To well-funded attackers, corrupting a software supply chain by targeting open-source software enables them to maximize the potential attack space with minimal work. True, ransomware and malware (usually delivered by email) are probably still the most common methods of attack, but now hackers have learned how to corrupt software that is part of the open-source community, and that gives them “back doors” into your code, your servers and your clients’ data.

This type of attack, called a software supply chain attack, has been used to bring down servers, expose data and introduce back doors into some of the most sensitive systems—think defense department networks and financial systems—and healthcare software is high on bad actors’ target lists. In late 2020, SolarWinds’ Orion software was the largest cyberattack recorded and discovered in the United States. This software supply chain attack compromised the security of as many as 250 governmental bodies, including the US Energy Department².

Addressing software supply chain attacks is not easy. Consider these three dynamics of open-source software:

1. You don’t know what’s really in it
2. You don’t know what it depends on, or rather, what it “brings along” to your servers to be functional
3. You don’t (really) know where it came from

So, what can you do to minimize the risk of a software supply chain attack? First, get some visibility into what goes into your software products by creating a Software Bill of Materials (SBoM). An SBoM is a list of all of the software libraries that went into your code or scripts, much like a list of ingredients on a food label. Many consider it to be the “first tier of demonstration” that you consider software supply chain attacks as a relevant and an ongoing possibility. In fact, security-aware prospects and clients are starting to ask for SBoMs to be provided as part of their normal software delivery process, and the US government has made them a future requirement as part of its cybersecurity program. It’s a good idea to start creating SBoMs now so that you’ll have them when they’re needed. SBoMs can be created by your open-source security scanning platform as part of your normal software delivery pipeline.

SBoMs are only one part of protecting your software supply chain and they’re a good first step. There are other best practices, but software engineering—from design to deployment to maintenance—is a complex process, and risk management strategies to address known and unknown vulnerabilities rely on more than testing and firefighting when the alarm is sounded. As Altera bolsters its cybersecurity practices, we will provide more thoughts on how we can all work together to help make these issues less threatening so that our healthcare ecosystem’s foundation is as strong as it needs to be.

¹ Sonatype State of the Software Supply Chain 2021, https://www.sonatype.com/hubfs/Q3%202021-State%20of%20the%20Software%20Supply%20Chain-Report/SSSC-Report-2021_0913_PM_2.pdf?hsLang=en-us

² Lessons learned: How to prevent the next SolarWinds attack”, https://www.itp.net/security/solarwinds-how-to-prevent-the-next-attack#:~:text=In%20late%202020%2C%20SolarWinds%2C%20the%20largest%20cyber-attack%20recorded,that%20the%20Russian%20government%20was%20behind%20the%20attack.