DEVOPSdigest

Open source isn't a strategy, it's a philosophy of collaboration. It's the fabric of millions of commercial projects in industries like FinTech, IT and AI. But there's something curious about open source — it makes up the majority of codebases, so surely the packages have hundreds of eyes keeping watch on their security posture? Unfortunately not — just look at Log4j and Equifax.

The free-for-all nature of open source makes the technical, operational and financial risks of data breaches and exploitation frighteningly high, posing unrelenting security headaches for developers and organizations.

Despite the negativity, the outlook is positive. The 2022 Linux Foundation report revealed that 77% of organizations believe the security of open source development will improve by the end of 2023. Automation like software composition analysis (SCA) tools(link is external) are at the forefront of the safe-OSS revolution, with the goal of keeping malicious packages out of your applications for good.

When Did Open Source Become the Wild West?

96% of codebases contain open source code (as per the 2023 OSSRA report), and vulnerabilities grew across every vertical last year. Open source isn't just for startups and have-a-go developers, as company-led projects are booming too. GiHub's 2023 Octoverse report showed that 30% of Fortune 100 companies have an in-house open source program office (OSPO) to facilitate OSS strategies and investment.

The cost efficiency, innovation, and collaborative nature of open source packages are altogether a good thing, but what happens when the standardization and planning of proprietary code go out of the window? Veracode found that a huge 70.5% of applications contain a security flaw in an open source library, and similar research by Sonatype discovered a 700% increase in cyber attacks launched against open source repositories over the last three years.

So, where did it all go wrong?

Developers are constantly under pressure to deliver amid time, money, and resource constraints, which is why the functionality and efficiency of OSS packages are so appealing. But velocity is a cruel taskmaster, and it's easier to take open source code from repositories without verifying it for known and unknown vulnerabilities than it is to check. The solution isn't to stop benefitting from open source; instead, it's to refine your usage by creating an approval process, investing in a SCA tool, and building a software bill of materials (SBOM) — which, incidentally, is where it all began.

In 2021, everything changed. The Biden administration announced its SBOM Executive Order, requiring all organizations to provide a list of software components in their products. The Order was designed to promote better visibility and security of the software supply chain. SCA tools enable security teams to automate open source governance and SBOM creation — and maintain high velocity.

Threats Lurk in Every Corner (and Package)

There's a reason why Log4J is still hanging around in the shadows. Open source is available to all, leaving a big hole where the centralized authority should be. With no one steering the ship, contributors lacking resources, funding, and expertise often neglect security best practices. 91% of codebases in 2023 contain outdated open source components or code that had no development activity in the last two years, according to a Synopsys report.

Contributors and organizations alike struggle to keep up with the unprecedented growth of package usage, often losing track of dependency trees and the OSS components in off-the-shelf and in-house products. The level of interdependency in the open source world is a significant part of the problem, causing a vulnerability chain reaction. When things go awry, patches are slow to arrive and even slower to implement consistently without the actionable threat intelligence of a SCA tool.

As well as insight into vulnerabilities, SCA tools identify a second major danger with OSS packages: compliance failures. 54% of codebases use open source with either no license, a customized license, or license conflicts, which puts your organization at risk of regulatory heat. Before choosing a SCA tool, you can check that it offers the flexibility to use preconfigured software composition analysis scanning or to implement your own security policies, so you know your codebase will be as compliant as it is secure.

There's good news on the horizon, as the 2023 OSSRA report found the number of applications with high-risk vulnerabilities is at its lowest level in four years (the SBOM Executive Order and SCA uptake get kudos for this). Is there light at the end of the tunnel?

Go to SCA: The New Savior of Open Source Software - Part 2