Shared success in building a safer open source community


“Prevent” was conceived to help users understand the risks of new dependencies so they can make informed decisions about the packages and components they consume.

We’ve seen strong community involvement in the prevention of vulnerabilities, particularly in the Security Scorecards project. Scorecards evaluates a project’s adherence to security best practice and assigns scores that developers can consult before consuming a dependency. Users can choose to avoid projects that, for example, don’t use branch protection settings or employ dangerous workflows (which make projects vulnerable to malicious commits), and gravitate to projects that follow strong security practices like signing their releases and using fuzzing. Thanks to contributions from Cisco, Datto and several other open source contributors, there are now regular Scorecard scans of 1 million projects, and Scorecards has developed from a command line tool into an automated GitHub Actions that runs after any change to GitHub project. More organizations are adopting Scorecards, and the Scorecard GitHub Action has been installed on over 1000 projects, with continued growth. With increased adoption, overall security will improve across entire ecosystems.

Additionally, Sigstore is helping prevent attacks by creating new tools for signing, verifying and protecting software. Recently, Kubernetes announced that it is using sigstore to sign its releases, showing that artifact signing at a large scale is now within reach. As adoption expands, we can expect stronger links between published source code and the binaries that run it.

Community collaborators like Citi, Chainguard, DataDog, VMWare and others have actively contributed to the OpenSSF’s SLSA framework. This project is based on Google’s internal Binary Authorization for Borg (BAB), which for more than a decade has been mitigating the risk of source and production attacks at Google. SLSA lays out an actionable path for organizations to increase their overall software supply-chain security by providing step-by-step guidelines and practical goals for protecting source and build system integrity. The SLSA framework addresses a limitation of Software Bills of Materials (SBOMs), which on their own do not provide sufficient information about integrity and provenance. An SBOM created using SLSA provenance and metadata is more complete and addresses both source code and build threat vectors. Using SLSA may also help users implement Secure Software Development Framework (SSDF) requirements.

Continued improvements to the OSS-Fuzz service for open source developers have helped get over 2300 vulnerabilities fixed across 500+ projects in the past year. Google has also been heavily investing in expanding the scope of fuzzing through adding support for new languages such as Java and Swift and developing bug detectors to find issues like Log4shell.

Through the Linux Kernel Self-Protection Project, Google has been providing a steady stream of changes to overhaul internal kernel APIs so that the compiler can detect and stop buffer overflows in fragile areas that have seen repeated vulnerabilities. For everyone in the ecosystem staying current on Linux kernel versions, this removes a large class of flaws that could lead to security exploits.

Looking ahead, this area’s rapid growth highlights the community’s concern about integrity in software supply chains. Users are searching for solutions that they can trust across ecosystems, such as provenance metadata that connects deployed software to its original source code. Additionally, we expect increased scrutiny of development processes to ensure that software is built in the most secure way possible.

The next goals for open source software security should involve broad adoption of best practices and scalability. Increasing the use of these tools will multiply the positive effects as more projects become secured, but adoption needs to happen in a scalable way across ecosystems (e.g., via the OpenSSF Securing Package Repositories Working Group focused on improving security in centralized package managers). Education will be a driving force to speed the shift from project-by-project adoption to broadscale ecosystem conversion: greater awareness will bring greater momentum for change.

Source link

Leave a Reply

Your email address will not be published.