Best Practices for Securing Open Source Code Quality

Open Source Best Practices for Higher Quality Code to Fundamentally Strengthen Your Project

November 09, 2022
By Aaron Linskens

9 minute read time

Sonatype has partnered with the Cloud Native Computing Foundation (CNCF) for Security Slam , an event to help improve the security of open source projects. To extend the value of this event, we created a series of blog posts on best practices for open source maintainers.

Here in the third and final post of our series, we focus on a few best practices for higher quality code to help fundamentally strengthen your project. A strong foundation on which to build and grow your project starts with a return to fundamental practices that keep contributors and maintainers on the same page.

Modern Threat Vectors: An Ongoing Story

Open source software, by its very nature, is built by the community, for the community.

However, open source projects that gain even a modest level of visibility deal increasingly with more and more attacks by bad actors.

Bad actors no longer wait for public disclosure of vulnerabilities. They forge their own paths to gain unauthorized access and extract data. While they continue to carve out more threat vectors, a few current popular methods include:

Recently, we see these tactics play out in a few notorious cases, such as a popular npm project, a PHP Git server hack, and a flood of dependency confusion PoCs on PyPI projects.

Opportunistic bad actors continually find new threat vectors and constantly renew tried-and-true tactics of attacking software projects. For open source projects, bad actors might bluntly attempt to inject malicious code into projects under the guise of a legitimate contribution.

Fortunately, in terms of open source software projects, we detail a few basic practices below that can help you prioritize code quality, shore up your security, and control your own narrative, as you try not to become a character in a bad actor's schemes.

Basic Practices to Put Your Project on a Path to Higher Quality Code

Code Reviews

As attention to upstream open source projects disseminates among bad actors, code reviews can help protect against the latest trends of malicious behavior. Furthermore, Sonatype's 8th Annual State of the Software Supply Chain Report revealed code review as the top factor that identifies a project's vulnerability.

Code review delivers multiple benefits:

By having your code reviewed, you demonstrate willingness to listen to feedback and make changes based on it. This in turn frames your project as a space for collaboration and makes users more likely to contribute.

The mere presence of a called-out code review process may also deter malicious contributors from attempting to outsmart your project in the first place. If you require code reviews before the merge of a pull request to the project, you can protect against any undue influence.

Overall, an established code review process can help find bugs, improve code quality, and build trust within the community.

Signed Releases

A signed software release provides evidence (a cryptographic signature) that a piece of code originated with a particular developer or organization, and guarantees the code has not been edited or corrupted since it was signed.

Signed releases can deter would-be attackers, since tampering can be easily detected. Additionally, signed releases can provide a measure of assurance to users that the software they install is the software released by the project maintainers, not an imposter.

There are a few ways to sign releases:

Signing releases helps assure your users that releases come from a canonical source, and gives a verifiable provenance to ensure your project is what it seems.

Change Control

No set of anointed best practices can ever completely prevent vulnerabilities or defects in your open source software project. But practices that encourage repeated interactions among developers help build trust and lay a foundation for a well-functioning development community. Visibility of your change control processes leads to better code quality.

If you use a common distributed version control system (VCS), such as Git, you typically have many change control features readily available, such as:

Additionally, unique version numbering helps your users stay out of dependency hell. Semantic Versioning (SemVer) and Calendar Versioning (CalVer) exist as common standards in this regard to help you safely move your project forward.

Release notes summarize changes of a given release and help your users decide if they should upgrade, given potential impacts. Rather than the raw output of a version control log, this should be a published detailed document that describes:

Release notes complement other key documents that help welcome new contributors to your project.

Elements to Help Strengthen Code Quality

OpenSSF Security Scorecard

The Open Source Software Foundation (OpenSSF) created a Security Scorecard tool that grades the security health of a project. The scoring process assesses a project's practices, such as code review, signed releases, and dependency update tools, and generates a quantitative output.

The resultant score gives you a measurement of your project's security posture and gives you an idea of the possible risks introduced by your dependencies.

You can run Security Scorecards manually via command line or automatically on code you own via GitHub Actions.

Security Scorecards assign a 0-10 score to a series of checks— heuristics commonly associated with software security. These checks include, but are not limited to:

If you want to further your development of best practices, in addition to Security Scorecards, check out OpenSSF's Best Practices Badge Program.

CLOMonitor

The CNCF created a tool called CLOMonitor which you can use to periodically check your open source project repository and gauge health and security posture. Essentially, it serves as a dashboard for viewing your project’s progress as you work to improve its security relative to the checks system.

Notably, CLOMonitor runs many security checks from OpenSSF's Security Scorecard.

In addition to Security Scorecard checks on code reviews, signed releases, and binary artifacts, CLOMonitor checks also include:

For qualified projects, clomonitor.io provides a comprehensive user interface with automatic scans to keep the website up to date.

If you want to review or modify the checks being made for a project, check out the CLOMonitor configuration file. This YAML file will specify:

For any use case not covered by clomonitor.io, you can take advantage of a local, Dockerized execution of the application.

You can also follow the docs to set up your development environment to build, test, and run CLOMonitor locally from source.

A Basic Foundation to Support Your Project

While bad actors continue to weaponize new threat vectors in open source software, you as the maintainer can stand your ground with a strong foundation of development basics.

By leveraging tools and staying vigilant with basic practices, such as code reviews, signed releases, and change control processes, you can ensure your code maintains high quality control.

While you might already have enough on your plate to deal with low-quality contributions, you can mount a good defense against malicious behavior and other bad-actor techniques by shoring up a few basic practices and leveraging some helpful tools.

Written by Aaron Linskens

Aaron is a technical writer at Sonatype. He works at a crossroads of technical writing, developer advocacy, and information design. He aims to get developers and non-technical collaborators to work better together in solving problems and building software.