Software Supply Chain Security: addressing cybersecurity challenges in using open source software
By Lightbird’s Thuy-Linh
Most software today isn’t written from scratch — in fact, it is estimated that over 80% of code in any modern application is code written by others, whether it is code from open source projects and Github repositories, remote call-outs to third-party services, or libraries acquired from third-parties. While re-using third-party code makes absolute sense in terms efficiency, efficacy, speed and cost, these external software artifacts are potentially subject to vulnerabilities and hacks that can negatively impact one own’s software security. In fact, with the rise in popularity of open source components (the average software application in 2021 depended on more than 500 open source libraries and components, up 77% in two years), the exposure of software to vulnerabilities inherited from potentially unsecure third-party’s components is expected to rise too. And indeed, in the past few years, the number of attacks that took advantage of these software dependencies — so called software supply chain vulnerabilities — increased in average 740%+ YoY (!).
So, how can one address the security challenges of using third-party’s and especially open source software components?
In this article, you’ll read more about our research in the state of software supply chain security (SSCS), our opinion on the current status quo (incl. a list of players / tools in the field) and where we see market gaps and opportunities for new entrants.
Status quo and respective challenges
In the aftermath of recent massive software supply chain attacks (e.g., SolarWinds, Log4j), politics around the world, including the White House and the EU, were awaken to the criticality of SSCS and intensified efforts to better protect software from supply chain vulnerabilities. This global concern has by now also spread to the private sector with for instance a large industry group, including the likes of Google, Amazon, Ericsson, Intel, Microsoft and VMware, pledging $30 million to work with the Linux Foundation and Open Source Security Foundation to improve the security of open source software. In the same vein, many initiatives, frameworks and guides were subsequently developed, such as S2C2F (“Secure Supply Chain Consumption Framework”) or SLSA (“Supply Chain Levels for Software Artifacts”; pronounced “salsa” 💃). Software supply chain security issues also took the center stage at the Black Hat conference in 2022.
While the issue of SSCS gets strong public and private interest today, and despite the risks that software supply chain issues could expose an organization to (see the latest supply chain attack targeting 3CX users and more than 600,000 companies worldwide), 27% of medium to large companies still do not have any established security policy in place to deal with software governance and open source security. For small companies this number approaches more than 45%. Worse than that, latest surveys show a great discrepancy between what people think is happening within their organization vs. what is really happening: while 68% of respondents are confident that their applications are not using known vulnerable libraries, close to 70% of 55’000 enterprise applications revealed known vulnerabilities in the underlying open source software components.
In fact, the core challenge for companies is that software supply chain security is highly complex as it spans various and vast aspects of software development that an organisation cannot directly control. Months after the Log4j vulnerability was reported for instance, it was still responsible for security breaches: this attack taught us that it is not enough to only know where one’s own developers are using Log4j, organizations have to also know all of their software that uses Log4j. As such, organizations have to implement processes and tools that help them check components across their entire software development lifecycle, including in-house code, outsourced development, commercial software packages, open source deployments, interfaces and protocols, development tools, … and anything else that makes up or interacts with the final solution.
In addition to “scanning all individual components” thanks to SCA or SAST tools for instance, the understanding of the dependencies within a project is equally vital (e.g., how do the different parts of the code interact with each other? how would a vulnerability affect the rest of the software chain? who has access to what and when?). Along with choosing and managing hundreds of initial dependencies, developers are thus asked to track an average of 1,500 dependency changes per year per application while maintaining software quality at all times. This is commonly referred to as dealing with the “Dependency Hell”.
And so, while SCA and SAST tools are relatively in use (around 35% of all respondents to a recent survey by the Linux Foundation have such tools in place), they typically can only address a portion of all the aspects around software supply chain security:
To date, various tools and frameworks exist across the three pillars of SSCS as illustrated above to help companies use third-party’s code and open source components more securely. 👉 Look at the end of this article for our list of 25+ companies, incl. companies recently out of stealth such as Oligo or Ox Security, providing solutions in this space.
It is nonetheless important to highlight here that given the complexity and vastness of SSCS, it is almost impossible for anyone to be 100% protected or “clean” of vulnerabilities, and thus for any tool to provide a bullet-proof solution. In fact, an external dependency per se already contains risks and potential vulnerability exposure. Like other aspects in cybersecurity, it ultimately comes down to the extent of an organization’s risk appetite.
Market development and opportunities
As mentioned earlier, SCA and SAST are the most widespread tools currently in use against software supply chain security vulnerabilities. However, they can only cover parts of what would be needed — thereby creating opportunities for new entrants and innovative solutions. At Lightbird, we are excited about the following developments in the SSCS space:
- The provision of more comprehensive / aggregating tooling across various aspects of software supply chain security. 59% of all respondents in a recent survey by the Linux Foundation found that “adding intelligence to existing software security tools (e.g., SAST, SCA, SBOMs, IaC)” should be the top priority to improve SSCS. And while a few players — such as Sonatype (US, 2008) or Snyk (US, 2015) — have been developing and commercializing suite of tools to address various aspects of SSCS, new technologies and an increasing availability of data will enable the next generation of more encompassing solutions. Endor Labs (US, 2021), for instance, backed with $25M in seed funding from Lightspeed, started the commercialization of a product suite claiming to go further and deeper than any other tools in SSCS matters. Ox Security from Israel also emerged from stealth in late 2022 with $34M in funding to introduce a more comprehensive version of the Software Bill of Materials (SBOM), called PBOM or Pipeline Bill of Materials, which covers not only the code but also each of the procedures and processes that impacted the development of a specific application.
- Tools and frameworks to facilitate the adoption of best practices and endorsement of organizations that do so. Google has for instance launched its Assured Open Source Software service which gives enterprises and government users access to the same vetted open source packages that Google itself uses in its projects. According to the company, these packages are regularly scanned, analyzed and fuzz-tested for vulnerabilities and built with Google Cloud’s Cloud Build service with evidence of SLSA-compliance. Chainguard (US, 2021) also took this route with products that allow developers to only build with SLSA compliant containers with provenance and SBOM verified by digital signatures. Chainguard was founded by the team behind the SLSA framework itself and is funded by Sequoia.
- Automated analysis and remediation of security vulnerabilities for SMBs. Security by default from the start should be encouraged, yet not every developer needs to be a cybersecurity expert, nor do all companies have the resources to address the complexity level of supply chain security. Because supply chain vulnerabilities can however affect companies of all sizes with the same impact, we see an opportunity for new entrants to offer basic, developer-friendly (i.e. embedded in a developer’s workflow) yet performant security tools targeting the particular needs of SMBs. Aikido Security — one of the few European players in this space — based in Belgium is taking this route by addressing teams with less than 50 developers.
- The adoption of bottom up go-to-market approaches. At Lightbird, we back companies with strong distribution advantages that come from adopting innovative go-to-market strategies beyond traditional sales & marketing. It’s fair to say that cybersecurity has remained one of those industries where traditional sales motions have endured. And so, it is not surprising that SSCS companies often target security officers, CISOs and compliance teams in a top down approach. Yet, with Snyk leading the way, we are particularly excited to see more and more cybersecurity companies start adopting an innovative go-to-market approach, typically targeting developers and incentivizing developer communities around security to evangelize the product from the bottom-up.
We’ve put together a list of active companies in the SSCS space 👉here. Have we missed anyone? If you are building something to improve software supply chain security and enable more secure use of open source software, we’d love to exchange perspectives and hear from you! Feel free to reach out via LinkedIn or to hello@lightbird.vc.
Thanks to my colleagues at Lightbird for their feedback as always and a special thank you to Charles for the insightful input!
