False Dichotomies and Overemphasizing Open Source Security
Discussing the pendulum swing between OSS and proprietary code/software security concerns
If you’ve been paying attention to the broader conversation around software supply chain security, you know that there’s been an increased emphasis on securing Open Source Software (OSS).
In the U.S. we’ve seen an emphasis on securing OSS from sources such as the Cybersecurity Executive Order (EO), National Cyber Strategy and Implementation plan (NCS/NCSIP), OMB Memos 22-18/23-16 and the “Securing Open Source Software Act of 2022”. Likewise in the EU we’ve seen efforts around securing OSS in sources such as the Cyber Resilience Act, and across industry there’s been a tremendous focus on software supply chain security, including OSS.
This isn’t unfounded, given the massive growth of OSS adoption and notable incidents such as Log4j which rocked the entire ecosystem, impacting countless organizations and technology vendors who were using the widely popular OSS component.
Sources such as Synopsys in their 2023 Open Source Security and Risk Analysis Report have pointed out how “Open Source is Everywhere”, with 96% of codebases containing OSS and 76% of code in codebases being OSS.
So what?
This article is not an attempt on my part to downplay the risks of insecure OSS consumption or use either, given I have written extensively about the risks of OSS in my article “Top 10 OSS Risks”, where I discussed a report from Endor Labs discussing risks such as known vulnerabilities, package compromise, unmaintained and outdated software and more.
What the article is, is an attempt by me to bring some sanity to the over-emphasis we have seen in software supply chain security discussions when it comes to OSS versus proprietary code and commercial suppliers.
This is also partly tied to recent discussions and a podcast I had with Contrast Security founder and longtime AppSec leader, Jeff Williams - which should be published soon.
Jeff points out that in their 2021 “Application Security Observability Report” they made some interesting findings, including:
78% of active code in an application is your code, not OSS
The majority of vulnerabilities are in your code
Despite findings such as from Synopsys and Contrast showing that 70-80% of code is OSS, only 6% of the code belongs to an active library or class, with the remaining 74% coming from inactive libraries or inactive classes within active libraries
There was a 21% YoY increase in serious custom code vulnerabilities, with 39% of vulnerabilities being either High or Critical
Why does it matter?
The reason this point deserves calling out and emphasizing is that we are on a pathway to potentially over-focusing on the wrong problem(s), while also potentially further drowning our Development/Engineering peers in more toil and vulnerability noise that lacks actual context.
Organizations are increasingly utilizing SCA tooling and SBOM’s to get an understanding of their OSS usage and the associated vulnerability footprint.
This means that 70-80% of code that is OSS now will have vulnerability data associated with it, that security will throw over the fence via scan results onto their Development peers, only to make them chase down a bunch of information related to vulnerabilities that aren’t active or reachable in the application(s) and/or vulnerabilities that aren’t known to be exploited or likely to be in the next 30 days per sources such as EPSS.
I’ve discussed the problem with doing this extensively in my article “Security Throwing Toil over the Fence”
There I discussed the need to shift smart over “shifting left”, which includes using the appropriate tooling, scanning for specific vulnerabilities at appropriate points in the SDLC, having Developers focus on code that is actually invoked/reachable and further enriching vulnerability data with sources such as threat intelligence and exploitation information, from sources such as the CISA Known Exploited Vulnerability (KEV) catalog and the Exploit Prediction Scoring System (EPSS).
Jeff has also written about the concept of shifting smart in a pair of Forbes articles, which can be found here and here.
It Depends
As it turns out, despite the overemphasis on securing OSS, it isn’t apples to apples when discussing which is more secure, OSS or proprietary code and software, it is indeed a false dichotomy.
I’ve spoke about this before, and wrote about it in “Software Transparency”, my software supply chain security book with Wiley.
There are a variety of factors that go into determining whether something is “secure” or insecure, both for proprietary software and OSS.
OSS
As discussed by researcher Chinmayi Sharma in “A Tragedy of the Digital Commons”, in the OSS community, you have thriving projects with large communities and contributors, and you have projects with scarce resources and participation, with almost 25% of projects having only ONE developer contributing code and 94% of projects being maintained by 10 or fewer developers, leading to a high “bus factor” (e.g. someone gets hit by a bus and you’re screwed).
Furthermore, OSS code is generally provided “as-is”, as I discussed in the article “Supplier Misnomer”, pointing out that organizations adopting OSS code are still responsible for maintaining it, keeping it updated and addressing any vulnerabilities it brings to their products and downstream customers/consumers.
There is also the challenge of dependency management and the associated vulnerabilities with dependencies used in modern applications.
For example, Endor Labs State of Dependency Management Report found that organizations on average suffer from code bloat, or a significant share of dependencies that aren’t actually used or reachable in code, however, in those dependencies, 95% of vulnerabilities are found in the transitive dependencies.
Most developers don’t fully understand the depth of their dependency tree, nor do many security tools enable reachability analysis, to determine of the vulnerable dependency trees, what is actually reachable, and therefore, potentially exploitable.
Proprietary Software
On the flip side, proprietary software and products are not all uniformly secure either. For every major tech giant and software leader with robust DevSecOps practices and Developers versed in secure coding, you have many other bootstrapped startups with little to no security team and competing priorities with an emphasis on speed to market and product/revenue growth that take priority over security (this happens with the largest tech firms too).
Even in the case of commercial firms, there is no shortage of security incidents and data breaches that would take too long to ramble off here, and a CISA Known Exploited Vulnerability (KEV) catalog that regularly features software giants and firms who allegedly lead the industry in “security”, while churning out products and software that is regularly exploited by malicious actors, and not just through insecure OSS libraries.
In fact, this past week we’re watching one of the largest CSP’s experience a security incident that is impacting millions of applications and customers, all while the majority of customers don’t have good visibility into the incident due to not paying for the higher tier of service to get sufficient logging (a problem we hear leaders from CISA and other agencies calling to be addressed with Secure-by-Default offerings, without up-charging customers for basic security capabilities). Granted this situation was due more so to poor engineering practices and single points of security failures than insecure code, but you get the picture. In fact, that same vendor is now under an analysis by the U.S. Cyber Safety Review Board (CSRB) tied to a hack of Microsoft Exchange that involved Government emails.
We’ve also seen several notable hacks of major software vendors such as Okta in 2023 and Progress Software, the makers of MOVEit are now facing class action lawsuits tied to the incident impacting that product and that impacted an estimated 1,000 organizations and 60 MILLION individuals. This is leading to a continued trend for software vendors to faced increased liability for the products they make and aligns with language in the latest National Cyber Strategy (NCS) which calls for the burden to be pushed onto suppliers to produce secure products and software, rather than pushing the cost of insecurity downstream onto customers and consumers.
Some of these companies ironically are “leaders” in security, with tens of billions in security revenue while concurrently being leaders in known exploited vulnerabilities, acting as the fireman and the arsonist while laughing to the bank.
Conclusion
As we continue to see areas such as Application Security (AppSec) and Software Supply Chain Security evolve and mature, we need to keep a healthy balance between securing both proprietary and OSS.
We also need to ensure we’re driving down toil on our development and engineering peers by shifting smart rather than blindly shifting left, testing for the right vulnerabilities at the right points in the SDLC, and ensuring we’re enriching findings with context in terms of both reachability/invocation and either known exploitation or a sufficient probability of exploitation.
Failing to do the above will have us exhausting scarce resources both organizationally and industry wide, while also drawing resentment from our peers and further bolstering silos that we are so desperately looking to break down in the name of DevSecOps.
It’s important to not hyper-focus on OSS, as proprietary software vendors represent massive targets that can, and have, impact millions of customers and citizens around the world due to insecure products and software that gets breached. This is why efforts such as aligning with NIST’s Secure Software Development Framework (SSDF) and self-attesting (for now) to following secure development practices is an important part of the conversation.
The software supply chain attack surface includes both OSS and proprietary code and products.
The attackers are equal opportunists, and we need to keep that in mind.