March 2, 20210 mins read
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. Although we believe that Open Source code is more secure for the aforementioned reasons, it still falls victim to vulnerabilities. Second, no matter how good your Proprietary Code is it still can be exploited by attackers. 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. This means organizations must arm themselves with the tools needed to scan theirOpen 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.