Open Source Developers Are Security’s New Front Line
We are in a pandemic. It changes everything. As a society, we have an increased level of anxiety. And we have an increased reliance on the devices and software that allows us to stay connected, get food, find distractions, and work from home. Quite suddenly, tens of millions of software developers are addressing unexpected traffic spikes from unplanned, potentially insecure, distributed locations.
“The world is now in an unprecedented experiment where most of the development force is no longer working in secure networks, safe in corporate security and restricted by their cut-off networks. In this new world, the role of open source software is going to just increase, and has become its critical infrastructure,” said Ilkka Turunen, global director of pre-sales at open source security provider Sonatype.
The New Stack both attended Turunen’s talk this March at QCon London and followed up with him this week. This article weaves together highlights from both.
Is Open Source Software’s Greatest Risk or Strongest Ally?
We know what happens over the next few months will dramatically change the world. But, if not done with careful consideration, it’ll negatively affect software security as we know it. Turunen’s talk was entitled “Open Source Developers are Security’s New Front Line” and is a sentiment that’s even more true today.
“In this world, these devolved security tools that enable developers to self-service, this quality is paramount. We must make sure we don’t let these standards lapse, as in the confusion of the current situation we will be paying a long price if that is the case,” Turunen said.
Instead of writing all your code from scratch, you can now leverage the feedback of everyone who has built something before you. Whether open source or proprietary, he says 85 percent of any codebase is now sourced by external suppliers.
With this in mind, everyone is responsible for considering their software supply chain. This includes open source projects, component repositories, software development teams and public-facing applications.
He argues that open source enables you to get value in front of your customers faster. In its fifth annual State of the Software Supply Chain report, Sonatype learned that 47 percent of open source users were deploying multiple times per week.
But, is faster also better for our adversaries?
Turunen observes that “Most engineering happens on the spot and for the use case I need it for. But if this is an unmanaged process, it brings risks.”
When talking about observability, we are looking to learn more about the unknown unknowns, but this level of sophistication can only come after you take care of the knowns. Frankly, many developers are googling solutions and downloading vulnerable open source software.
He cited that 313,000 Java components are downloaded annually by the average organization. He says that leads to a lot of re-downloading without introducing things like artifacts management. Among that, 27,704 Java downloads — or 8.8 percent — had known vulnerabilities. In JavaScript, each developer downloads an average of 60,660 packages — more than half have known vulnerabilities.
“Open source doesn’t age like fine wine. It ages like milk.” — Ilkka Turunen, Sonatype
It’s clear that open source enterprise software can be an attractive target to malicious actors. It’s even more appealing in a cryptocurrency world that has targets in the server, the visitors and the build infrastructure. More than two years ago, the open source Jenkins automation server was discovered to be the target of one of the biggest mining operations ever. So far, more than $3.4 million has been mined because so many teams still haven’t applied the patch.
For Turunen, DevSecOps is about automating faster than the evil can attack. And automating all the updates and security that you can.
Learning from Open Source Security
Open source becomes a good place to learn lessons, as code is being delivered faster and projects are observed completely out in the open.
Turunen addressed three common assumptions about open source software.
Assumption #1: If you release faster you are probably putting in more security patches.
The key metrics for this are:
- Time to remediate
- Time to update
- Do you have stale dependencies
They realized that the meantime to remediate a security vulnerability is 326 days. But popular open source projects are staying more secure because they are staying up to date. Although, if the developers using that tech are applying those patches, that’s a whole other story.
What Sonatype has found is that active projects that maintain their dependencies also maintain their security. These projects have five times more downloads and 79 percent more developers. They also have about 12 percent more foundation funding.
The first assumption pretty much holds up.
Assumption #2: Projects with Fewer Dependencies Are Safer.
Simply put, larger teams will always have more dependencies and they will always deploy them faster.
In the end, the Sonatype team negated this assumption because they found that larger development teams — which inherently have more dependencies — have a 50 percent faster mean time to update (MTTU) and release 2.5 times more frequently. Therefore, components with more dependencies actually have better MTTU.
Assumption #3: More Popular Projects Will Be Better about Staying up to Date.
Turunen says that exemplary projects have a direct correlation of releasing more often and maintaining popularity.
“There are also a large cohort of projects that are just popular but since they don’t release very often, they fall behind in terms of quality — that’s the group that introduces the most risk,” he said.
This assumption was rejected because there are plenty of popular components with poor MTTU.
What to Learn from the Open Source All-Stars
If dependencies are natural part of accelerated software development, then there must be a process for adding them. Only half of organizations Sonatype surveyed actually do.
We know there are certain patterns uncovered among elite DevOps performers. Turunen mentions the following common traits among DevSecOps exemplars:
- They are ten times more like to perform daily updates to all of their dependencies
- Most of these projects are using the latest or the latest-N version for all their OS components dependencies
- They have a process to add a new dependency
- They have a process to proactively remove problematic or unused dependencies
- They are 12 times more likely to have automated tools to track, management and/or ensure policy compliance of dependencies
Since these updates become routine, they are also 3 times less likely to consider it a pain to do.
On the other hand, when Sonatype examined the much larger non-exemplary group, they found that 21 percent of components were vulnerable in unmanaged supply chains. But by adding an open source security manager, they were able to reduce that by half.
“We’re not there to write the code to make sure it’s secure. We’re there to write code to offer something to our users,” he said.
Which is why he thinks automation is key to successful and safe open source-backed orgs.
The Power of a Software Bill of Materials (SBOM)
“In my opinion, FOSS [free open source software] Is the main driver of the software economy — without it we could not have gained the productivity levels we are at now in the world. With it, it’s become critical infrastructure and we have to be mindful of using it in a responsible way.” Turunen said.
So how do software teams do that especially when they are working outside of normal time tables and office spaces?
Turunen offered key activities each team needs to be aware of:
- Always compile a list of what open source software is used in building and deploying your software and monitor it — a Software Bill of Materials (SBOM)
- Introduce standards on what open source you use
- Only choose the best suppliers
He says developer-friendly tools are necessary to make the right decisions with the right kind of visibility, and that most of the above can be achieved through automation.
Especially now, there has to be a trust in automation and a trust in your developers.
“What was previously a gatekeeping operation by corporate security has to become a quality test built into the software manufacturing process. The good news is the same tips worked in other industries in the past — and we have plenty of experience that shows this approach works,” Turunen said.
Right now, many companies are focused on keeping the businesses open, but security can’t be overlooked.
“With plenty of services built with open source and most organizations focusing on just keeping their lights on, we must not lose sight of being ready to defend what is arguably one of the easier campaigns to execute by adversaries. Organizations can go a long way even by beginning to introduce SBOM generation as a part of their release processes,” Turunen said.
Sonatype is a sponsor of The New Stack.
Feature image by ddzphoto from Pixabay.
