Securing open source development: A supply chain perspective

Product security is the foundation of our software delivery at Red Hat. Developing open source is extraordinary, and we strive for the best standards since our code is open. While this is a broad subject, my focus is secure development, specifically from the supply chain perspective. 

Security as a culture

As an engineer on the Supply Chain team, the more I dive into software development, the more I have come to understand that security is a culture. It requires collective involvement from everyone in the organization. 

When you create code, you play a role in contributing to your organization's culture.

Securing your code from the beginning means hardening your technology before starting a single line of code. One way to test secure architecture and code is through threat modeling—a core activity that should be implemented in the early design stages that builds trusted platforms with significant value. It’s a fundamental practice that helps to identify flaws before your code becomes a reality. 

This is a simple yet powerful example that expands the concept of security beyond the code. Creating this mindset enables security at the core of your development process, which helps to identify and map weaknesses, clarifies the roadmap and points in the direction of what needs to be fortified. Being immersed in security as a culture can help you express your code in a way that reflects your corporate ideals. 

Secure development best practices

I compare secure development with martial arts. Why? Because, like some martial arts, secure development requires “study, learning, practice, and constant devotion and patience to a master.” Adopting best practices in secure development is fundamental and must become part of your lifecycle. Following this holistic idea, we have the SSDF(Secure Software Development Framework), a set of security-focused and evolving software development practices. Adopting these practices ensures you keep your skills sharp and honed.

The Concise Guide for Developing More Secure Software from the OpenSSF is another list to reference these practices. This guide is part of the Best Practices for Open Source Developers project. It covers an extensive security checklist: ensuring privileges, choosing protected memory languages, improving package management and dependencies, improving code review rules, adding signatures and other insights that may help you build and distribute more secure open source software. This initiative includes earning badges as part of the OpenSSF Best Practices Badge Program. The OpenSSF also has the OpenSSF Secure Software Development Fundamentals, a set of courses designed to jump-start your knowledge in secure development.

Creating a well-defined vulnerability management process enables feedback collection and gap identification, which helps the secure development lifecycle to evolve.

A supply chain perspective

A software supply chain attack can happen when there is a compromise in artifacts, materials or processes used to create software. Supply chain security relies on securing software components and dependencies early in the software development lifecycle, as well as the attestation and validation of each of those processes, to create trusted products and packages that businesses and customers can rely on.

There is an ongoing and growing effort to create best practices and tools to aid the industry in improving risk mitigation against attacks. Some keys to securing software development in the supply chain are recurring themes throughout the best practice recommendations from the CNCF Software Supply Chain Best Practices. As tooling and guides evolve, the supply chain's best practices continue mentioning automation to simplify the process and avoid human errors. We see efforts such as the Supply chain Levels for Software Artifacts (SLSA) on the horizon.

SLSA is a security framework that can help automate your development pipeline to improve the supply chain security maturity, helping your source code have higher integrity and tampering avoidance. SLSA currently has four levels of compliance that can be achieved, with level four being the highest. When implementing the SLSA framework for your project and generating the automated provenance, you will be exposed to more tools, such as sigstore cosign. Sigstore exposes your sources to a signing process that helps in attestation and verification in an automated form.

These guidelines and tools are part of the starting point for securing development from the supply chain perspective.

Conclusion

Secure development is a constantly evolving practice, and it’s better applied as part of the organization's culture. Security best practices can take the development lifecycle to another level, and exploring this will inevitably challenge developers, designers, and architects. 

Like a constantly improving martial art, supply chain security brings to the security floor the quest for achieving even more integrity and trustworthy results in software development and delivery. Empowered by the open source communities, new guidelines and tools are appearing to help improve supply chains across the industry. 

While seeking excellence in this area, organizations, developers, and communities can count on open source projects, tools, and guidelines to quickly evolve and achieve a constantly improving secure software development lifecycle.

Learn more

• Curated, tested and supported: How enterprise vendors mitigate open source supply chain risk
• What is software supply chain security?
• Supply chain security in cloud-native environments: What is it, why it matters
• Understanding open source software supply chain risks