Blog

Securing Open-Source Components with Spyderbat

  • All Posts
  • 1 month ago
  • 3 min read
  • 27 views
  • 0 comments

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. 

Approaching the problem from the other end, Spyderbat’s cloud native runtime security platform allows development teams to monitor and intervene in live deployments, rather than trying to defend against all possibilities ahead of time. Using eBPF to enable runtime visibility in and across complex microservice architectures across cloud and container workloads, Spyderbat delivers comprehensive, visual monitoring throughout the entirety of your environment, both in real-time and historically. With access to a complete record of behaviors in previous deployments, organizations can codify expected runtime behaviors and execution sequences to identify suspicious deviations as they occur.

By fingerprinting workload runtime behavior throughout the software development lifecycle, Spyderbat enables developers, platform engineers and/or site reliability engineers the opportunity to capture deviations from expected workload behavior. This enables early recognition of unanticipated or even undesired behaviors from open source components even if days or weeks after installation. 

To learn more and schedule a live demo, visit Spyderbat today.

Write a comment

guest
0 Comments
Inline Feedbacks
View all comments

Solutions

Use cases