SolarWinds Orion Security Breach: A Shift In The Software Supply Chain Paradigm
The recent SolarWinds breach highlights a new paradigm in the Software Supply Chain. When compared simply to the code itself without any additional tools, Proprietary Code is no more secure than Open Source. By contrast, many would argue that Open Source Code is more secure due to a faster fix/patch/update cycle and the pervasive access to source code (Clarke, Dorwin, and Nash, n.d.). For most in software development, this is nothing new; however, there are many companies who are still staunchly anti-Open Source – believing that Proprietary Code is more secure. Despite the opposing views in this debate, one fact remains: 96% of applications use Open Source Code, and 80% of the code in the Software Supply Chain is from Open Source.
Ironically, the recent SolarWinds Orion breach may help shed light on this exact shift in the Software Supply Chain paradigm. While the responsible actors are still unknown, details on how the attack occurred have emerged. First, hackers were able to weave malicious code into a SolarWinds Orion update in early 2020 (Paul, 2020). With the infected code onboard the SolarWinds Orion update, many users then executed this update on their devices giving hackers backdoor access to troves of data. The deeply embedded nature of SolarWinds Orion, which often receives VIP network access to avoid conflicts with other malware detection solutions, simply adds to the gravity of the attack. End state: A once-trusted cybersecurity solution without any Open Source code was brought to its knees by unknown actors causing widespread unauthorized access to vast amounts of our Federal Government’s most sensitive data.
Two lessons emerge from this example.
#1: Open Source Code is Vulnerable
Although we believe that Open Source code is more secure for the aforementioned reasons, it still falls victim to vulnerabilities. Developers who rely to any extent on open source libraries should have this in mind, and should implement the use of Open Source Security tools into their product lifecycle.
#2: Proprietary Code is, too
No code is impenetrable, and it is not solely up to an organization’s security professionals to take responsibility for security; rather, bolstering the Software Supply Chain should start with the developer.
How Do You Fix This?
Organizations must arm themselves with the tools needed to scan their Open Source Code (SCA), Proprietary Code (SAST), Containers, and Infrastructure as Code (IaC). Doing so will only enable organizations to identify, prioritize, fix, and monitor vulnerabilities. Furthermore, the key is to implement this process early in the SDLC. This is a defining solution characteristic that should be an independent product requirement of any good SCA, SAST, Container, and/or IaC Scanning solution: It must be purpose-built for the Developer. Why? Because early fixes—when the code is still in the developers’ hands – are less costly, less time-consuming, and less detrimental to mission speed/success.
Keep the capabilities. Lose the vulnerabilities. Contact us to implement end-to-end code security, to let your teams code worry-free.
Originally published by Snyk.