The art and science of secure open source software development

For many, writing a computer program isn’t that hard—it simply requires a certain amount of structural and logical thinking and a clear understanding of the syntax of the language you are using.

Developing software with a greater security posture adds an extra layer of complexity to this process, however, something which not all developers understand or are able to achieve. Open source can help. Open source developers, security researchers and auditors can see your code, spot potential flaws and perhaps even help you make fixes.

This doesn’t mean that the developers are free to write insecure software assuming people will correct the flaws or errors for free—it actually means that they now have a greater responsibility to create high-quality code that is free of known vulnerabilities.

Red Hat is in a unique position with respect to software security and open source development. Many of our offerings depend on upstream open source projects. While Red Hat is directly involved in a lot of important projects—either through upstream developers who are Red Hat employees, or through other forms of direct and indirect contributions—there are some projects which are wholly independent.

This presents a unique challenge, but is also an opportunity to test whether consuming enterprise open source software through a vendor like Red Hat helps minimize risk and achieve compliance with applicable U.S. government standards concerning IT security best practices.

What do we do for our customers?

Secure Software Development processes are important during software development. Design and code validation can help post development as well, before the code is compiled and shipped to customers. Red Hat runs a plethora of processes before actually shipping software to our customers, including:

• Code scanning: This process involves scanning source code before it is compiled to better detect security flaws and weaknesses. This helps us identify and fix issues in early stages. This process can detect issues in the way code is written but cannot detect design or logic mistakes. Early detection is important for Red Hat, as it helps to protect not only our customers but also the open source community as a whole, as the security patches are sent upstream so everyone can benefit from the fix.

• Threat modeling: This process helps identify potential threats, design issues and other higher-level things not covered by code scanning or code audits. This helps us determine which software security controls an application needs in order to set effective countermeasures against potential threats. This also helps us resolve problems early on, cost-effectively improving the security posture of any application.

• Software bill of materials (SBOM): Open source products are usually composed of many smaller projects, so knowing exactly what you are shipping is an essential step in understanding the security posture of those products. This also helps Red Hat Product Security in effective vulnerability management.

6 tips for open source developers

If you are an open source software developer or project lead, there are several things you can do to help develop software that is more secure.

1. Learn everything you can

Learning about security and how to develop code securely is a good starting point. There are several resources which are available online, most of which are free (in the true open source spirit), including:

• Secure Software Development Fundamentals Courses from OpenSSF is an excellent starting point.

• Red Hat Developers’ You’ve Got Microservices… Let’s Secure Them! talks about securing microservices and includes links to other secure coding guides.

• The Fedora project defensive coding guide is a good starting point if you want to learn language specific quirks, etc.

• Also try looking at the CVE database of previously found security flaws. These often contain links to references and can be an important way to learn how these vulnerabilities were caused in the first place.

2. Get your code peer reviewed

• If you are a team of developers then great, you already have teammates who can peer review your code before you commit.

• If you are a sole developer, no problem! Asking for help on public forums or mailing lists should be fine. Just get another set of eyes on your code—it always helps!

3. Use free security tools

• There are plenty of free security analysis tools available on the internet. These range from free source code scanners to threat modeling tools and even binary analysis tools which you could use.

• Even those which provide basic functionality for free can help provide important insights into your project.

4. Have a process to respond to vulnerabilities

• Secure software development is not only about detecting flaws early, but is also about responding to issues that are detected after code has been shipped to customers and users.

• Have a place to report security issues—probably an email address—and make sure this is properly advertised on the project page. Some reporters only like to send encrypted emails, so think about how you want to handle this.

• Respond to reporters in a timely fashion. Any issues fixed should also be converted to security advisories and prominently displayed on the project page so that customers and users know if their version of software is vulnerable or not.

5. Network and keep yourself updated

• Doesn’t this apply for everything? As a developer you keep yourself updated with the latest technologies or even the newest languages, so spend a few extra cycles to stay up to date on the latest attacks and the newest tools available. In the end it should all be worth it!

6. Understand your weakest links

We all know the proverb: A chain is only as strong as its weakest link. This is also true for secure software development. As a developer, you use all methods you can to make your code as secure as possible, but there are other factors at play. Here are some things to keep in mind.

• How secure is your build toolchain? If you are distributing pre-built binaries along with your code, how secure are your compilers, linkers and other build toolchain components? Are you using the correct flags while building?

• Where is your source code hosted? If it is a cloud-based git repository, who else has access to the code, and how secure are your credentials?

• Do you sign your source-code tarballs? Do you use any modern tools like sigstore to ensure transparency?

Conclusion

Thinking about securely developing your code is a process, and it takes time to train developers and reviewers to have the right mindset for this process. In the end, however, a diligent process helps both the consumers of the code as well the developers. If you’re a developer, there is plenty of help available and it is only a question of learning the right methods and tools to get on the right path.

Learn more

• Red Hat Security blog

• Red Hat Product Security Center

• Red Hat Product Security Overview