Open-source software (OSS) has become a cornerstone of modern technology, offering a collaborative and transparent development and distribution approach. Once considered impractical for the enterprise, open-source software and code power nearly all global organizations today. While open-source software code can provide enterprise tools and capabilities, it presents unique cybersecurity challenges, such as software supply chain attacks.
Many organizations adopt open-source software and code repositories and integrate them into applications or infrastructure without realizing hidden security vulnerabilities and complexity. Deploying specific repositories and dependencies across multiple cloud environments can increase exposure and attack surface.
There are countless reasons organizations adopt OSS rather than closed-source, proprietary software. But the reality is that organizations adopt both, each requiring a unique approach to managing, administrating, and securing it.
This is a lengthy deep dive into open-source security and potential mitigation solutions, so we’re providing a table of contents to make it easier to navigate.
Table of contents
1. Open-source isn’t less secure than Closed-source
Open-source software isn’t inherently less secure than closed-source software. Each has vulnerabilities, potential exploits, and unique challenges.
Ten years ago, when I would speak to security teams and IT administrators, open-source software and platforms had a stigma to them. Many organizations weren’t comfortable deploying anything they didn’t pay for from a vendor with a logo they could trust. A vendor product made organizations feel comfortable and safe, and they knew if something broke, they had multiple people on speed dial who could help them.
Open-source? The perception was that it was the Wild West. You were on your own. Even if those shiny vendor products had open-source components under the hood, a familiar logo still stared at their faces when the lights went red.
Luckily, the IT industry has changed its stance and embraced open standards and code. Adopting open-source software shouldn’t be ostracized. Instead, it requires understanding the potential threats and vulnerabilities and how to mitigate these concerns before a security incident occurs.
2. How vulnerable are open-source codebases?
According to the Synopsys 2021 Open Source Security and Risk Analysis (OSSRA) report, 98% of audited codebases contained open-source. However, paralleling the popularity of open source is a growth in risk—specifically around open-source licensing, code quality, and especially open-source security. Eighty-four percent of the audited codebases examined in the OSSRA report were found to have at least one vulnerability, with an average of 158 vulnerabilities per codebase.
Manual open-source tracking is untenable; organizations can’t adequately track and manage the amount of OSS they use by spreadsheet anymore. Software composition analysis is an automated process that identifies security vulnerabilities, license compliance, and code quality issues that may arise from using OSS in applications and containers.
Open-source repositories create “invisible dependencies” within a codebase. On average, 595 open-source components are present per codebase. Codebases such as LowPDF have 100 dependencies, and if they are integrated into an application, I have now introduced 100 OSS component dependencies.
3. Managing open-source in containers and applications
Containers, Docker, and Kubernetes frameworks have exploded in prevalence across organizations’ IT infrastructure. Today, it is common for organizations to containerize workloads and deploy across multiple cloud service providers, such as AWS, Azure, and Google Cloud.
Look no further than the rise of GitHub, which has over 420 million projects, 284 million public repositories, 65 thousand generative AI projects, and 4.5 billion code contributions to all projects in 2023. OSS is everywhere, and that can become a challenge for resource-strapped IT teams to get a hold of.
Software Composition Analysis, SBOM, and Container Hardening
This explosive growth of containers, OSS, and containers has introduced concepts such as Software Composition Analysis (SCA), Container Hardening and Registries, and Software Bill of Materials (SBOMs). However, the utility and effectiveness of each vary. For example, SBOMs don’t provide any level of security, and despite a White House Executive Order calling for SBOM adoption, it hasn’t been an enforceable measure.
Solution providers such as Synopsys offer SCA tools for workloads and open-source vulnerability monitoring. These allow development teams to fix vulnerabilities during the development cycle with a single automated solution to manage the open source in our containers and standard deployed applications.
Other tools specialized in identifying open-source vulnerabilities, such as RedEye, an open-source analytic tool developed by CISA, and Google OSV-Scanner are attempts to arm red and blue teams.
Let cloud service providers manage your OSS
One approach organizations can take for cloud-native environments is allowing your cloud service provider, such as AWS or Google Cloud, to manage your open-source software deployments. Google Cloud offers Assured Open Source Software to provide hardened, verifiable integrity packages distributed by a secure Google-managed Artifact Registry.
By leveraging Google Cloud Assured Open Source Software, Google provides package assurance with verifiable SLSA-2 compliant builds, which indicates the package was securely built by vetted sources. SBOMs include vulnerability impact data in each package, including vulnerability and fuzzing testing with OSV data.
AWS actively supports open-source foundations and standard bodies and provides security frameworks and tools to its customers. AWS co-founded the Open Cybersecurity Schema Framework (OCSF) project to make it easier for security professionals to aggregate and correlate telemetry data from different sources. AWS provides Rust, Kubernetes, OpenJDK, Snapchange, Cedar, Bottlerocket, Kani Rust Verifier Project, and Firecracker, among 1,200 Amazon-led open-source projects on GitHub.
4. Final thoughts on OSS cybersecurity
When OSS is integrated into the software supply chain–and 98% of codebases contain open-source code–it complicates the cybersecurity risk and defensive posture organizations must maintain.
However, OSS has numerous tangible benefits. Customers and organizations need to understand the risks and their exposure. Supply chain attacks such as the Log4j vulnerability (CVE-2021-44228) highlighted the interconnected nature of OSS. Attackers can inject malicious code into popular libraries, impacting countless downstream applications.
The Log4j vulnerability impacted over 35,000 Java libraries, causing widespread fallout across the software industry. As of December 2022, a full year after the initial exploit, cybersecurity firm Tenable estimated that 72% of organizations were still vulnerable.
Dan Lorenc, CEO of software supply chain firm Chainguard, stated, “The unknown unknowns are the ones that are problematic here.”
For more resources on hardening your organizational IT infrastructure, consider reviewing the guidance on cybersecurity best practices offered by the National Security Agency, including OSS.
Discover more from Cybersecurity Careers Blog
Subscribe to get the latest posts sent to your email.