Open source software is a type of software that is released under a free and open source license. This means that anyone can access, use, and improve the codebase of an open source project. This freedom comes with a few caveats: first, open source projects are often more difficult to maintain than closed-source projects; second, there is less control over who makes changes to an open source project; and lastly, open source projects can be more vulnerable to attack. Despite these challenges, secure open source programs are important for two reasons: first, because they provide a way for users to access and use the codebase of an open source project without having to worry about potential security risks; and second, because they help protect against attacks on closed-source projects. Open Source Security in Practice One way that open source projects can protect themselves from attack is by using security features built into the codebase. For example, many GNU/Linux distributions include security features such as kernel vulnerabilities and memory corruption vulnerabilities. These vulnerabilities allow attackers to execute arbitrary code or cause data to be lost or corrupted in the event of an attack. Another way that open source projects can protect themselves from attack is by using security measures designed specifically for their platform. For example, many GNU/Linux distributions include features that help prevent attackers from gaining access to system files or data (such as passwords or encryption keys) without having been authenticated first. This helps protect against attacks that would otherwise be able to access sensitive information on the system.
Supply Chain Attacks
Until very recently, if you were involved in cybersecurity and found yourself trying to explain supply chain attacks to someone you probably used the Stuxnet attack as an example. Now, you have any number of examples to choose from.
Everyone has heard of the Solarwinds and Codecov attacks because they were headline-grabbing, sophisticated attacks with a wide reach. But these two examples are a drop in the ocean of attacks of this type.
Supply chain attacks poison the buffet. Anyone who eats from the buffet consumes the poison. The host of the buffet isn’t the target. The targets are everyone who is invited to the feast. If the attackers can compromise a software toolkit or library that is used in many other applications and systems, they have managed to compromise all the users of those other products.
Open-source and closed-source products are both at risk. There have even been cases where laptops were produced with hard drive images cloned from a compromised golden image, baking malware right into the hardware.
But because open-source projects give everyone access to the source code and the ability to submit contributions to the project, they are an ideal attack vector for cybercriminals. And targeting open-source becomes ever more attractive as the use of open-source components continues to snowball. Almost all non-trivial development projects use open-source assets. The digital infrastructure of the modern world relies on open-source.
According to a report by Sonatype the use of open-source is still accelerating. That’s great for open-source. What isn’t so great is the concomitant increase in supply chain attacks using open-source as its attack vector. There has been a 650% increase in supply chain attacks year on year, including dependency confusion, typosquatting, and code injection.
We’ve previously described steps you can take in-house to try to limit your exposure to supply chain attacks, using utilities such as preflight. We’ve also reported on programs that are being implemented at an industry level, such as the Linux Foundation’s sigstore initiative which is being jointly developed by Google, Red Hat, and Purdue University, IN.
The Secure Open Source program is a new initiative run by the Linux Foundation with a $1 million sponsorship from the Google Open Source Security Team.
Secure Open Source Rewards
The pilot program is focused on enhancing the security of critical open-source projects. The definition of critical is the U.S. government’s definition, which was drafted to supplement Executive Order 14028. Their definition ranks software as critical if one or more of its software components has any one of the following attributes:
It is designed to run with elevated privilege or manage privileges It has direct or privileged access to networking or computing resources It is designed to control access to data or operational technology It performs a function critical to trust It operates outside of normal trust boundaries with privileged access
Another important factor is the potential impact of the issue on consumers of the software. Who will be affected, in what numbers, and how? If the software in question is incorporated into other open-source projects its impact will be higher than if it is a standalone application. And the more popular a given component is, the more attractive it is for a supply chain attack.
That’s why these criteria will also be considered:
How many and what types of users will be affected by the security improvements? Will the improvements have a significant impact on infrastructure and user security? If the project were compromised, how serious or wide-reaching would the implications be? Is the project included in the Harvard 2 Census Study of most-used packages, or does it have an OpenSSF Critically Score of 0. 6 or more?
In broad strokes, a software project can apply for funds to allow them to rectify a security issue. The application is reviewed and topics such as how critical the project is, what the remediation or improvements are, and who will do the work are considered. The evaluating board members will be Linux Foundation and Google Open Source Security Team personnel.
To be viewed favorably, a proposal should include improvements from this list:
Supply chain hardening, including CI/CD pipelines and distribution infrastructure in line with the Supply-chain Levels for Software Artifacts (SLSA) framework. Adopting software artifact signing and verification techniques, such as the sigstore tools. Project improvements that result in a higher OpenSSF Scorecard result. Scorecard detects and lists the dependencies with open-source projects. Using OpenSSF Allstar to harden GitHub repositories. Earning a CII Best Practice Badge by adopting industry best working practices.
The rewards are banded and dispensed according to the complexity and merits of the security improvements and the potential impact of a successful attack on the wider community.
$10,000 or more: Complicated, high-impact, and lasting improvements that almost certainly prevent major vulnerabilities in the affected code or supporting infrastructure $5,000-$10,000: Moderately complex improvements that offer compelling security benefits $1,000-$5,000: Submissions of modest complexity and impact $505: Small improvements that nevertheless have merit from a security standpoint
Reporting mechanisms must be agreed upon and adhered to. These will monitor the progress on the fixes, and verify they are actually taking place. This isn’t just free money.
Why This Matters
The Sonatype report reads “…we expect that attackers will continue to target upstream software supply chain assets as a preferred path to exploiting downstream victims at scale.”
Because of the widespread use of open-source in the development of open and proprietary products, that scale is huge. Open-source has permeated the technological fabric of our modern world to an astonishing degree. In fact, that technological fabric now utterly depends on open-source.
Initiatives like sigstore and Allstar have been designed to provide help to the entire open-source movement. Other tools such as preflight are deployed at the consumer level. This new initiative complements both approaches and attacks the problem at its very root.
If you improve the code and the development infrastructure and remove the vulnerabilities there will be fewer possible exploits. That will drive down the number of compromises.
The Secure Open Source Awards isn’t a bug bounty. It’s about providing resources to tackle problems. Addressing issues in the code, hardening the CI/CD pipelines and source code repositories, and using a software artifact signing and verification scheme will transform the position open-source finds itself in.
