Want to see Spyderbat in action?
Today’s software development companies rely on hundreds to thousands of open-source components and dependencies – an average of 203 per repository – to write new applications. This trend is a remarkably recent development, with industry average open-source use rising by 259% in just the last six years. The logic driving this transformation is as simple as the maxim against reinventing the wheel. Modern applications share so many common functionalities that it rarely makes any economic sense for developers to custom code any function or feature freely available in published open-source archives.
Nevertheless, like any rapid adoption trend, developers’ use of open-source components often outpaces their understanding of the risks they introduce and their ability to secure applications against upstream vulnerabilities. In 2021, the National Vulnerability Database (NVD) published 20,175 new vulnerabilities – up from 18,341 in 2020 – and in Q1 of 2022, 8,051 vulnerabilities were recorded, marking a possible 25% increase over 2021. Recent security assessments have found high-risk vulnerabilities on the network perimeters of 84% of organizations. Although most of these could be resolved with a single update, the scale and depth of recent incidents based on open-source components of the software supply chain such as the Log4j vulnerability should remind companies to continuously monitor new and existing open-source components in their codebases.
Best Practices for Securing Open-Source Components
Although known vulnerabilities abound in current applications, the development industry has several established best practices for securing open-source components.
1. Automated Component Testing
Modern software engineering is highly modular. Component libraries and dependencies are accessed and written in regularly. As developers have no upstream control over what is passed into these components, organizations must institute automated, recurring testing for all open-source code.
2. Risk Tolerance Rules
All open-source code introduces some element of risk as it is written and maintained by third parties. Many organizations attempt to mitigate overall risk by enforcing risk tolerance policies equally at all stages of the software development lifecycle (SDLC).
3. Software Composition Analysis (SCA)
SCA refers to automated processes for identifying open-source components in a codebase. In large projects, SCA can save countless hours in the manual analysis of dependencies, libraries, and licenses.
4. Tracking Custom Changes to Open-Source Code
Open-source components are not necessarily used as is. When developers modify open-source code, they can significantly reduce the difficulty of subsequent testing and incident investigations by forking changes to enable automated scanning for modifications.
Monitoring Expected Deployment Behavior with Spyderbat
Standard industry practices for securing open-source components focus mostly on advanced prevention through automated scanning and testing prior to deployment. As developer reliance on open-source rises and the rate of new vulnerabilities accelerates, staying ahead of the curve becomes increasingly challenging and costly in time and resources.
To learn more, schedule your live demo today.
Want to see Spyderbat in action?
