How is Red Hat addressing the demand to develop offerings more securely?

The IT industry not only looked very different 20 years ago, product security looked very different as well. Open source software wasn’t mainstream and the majority of vendors had full control and secrecy over their product code.

Today, however, almost every software vendor contributes to and incorporates open source software within their product or managed service (herein called “offerings”), but does this impact the security of these offerings? In particular, what is Red Hat doing to demonstrate that our offerings are developed in a secure manner and provide trustworthy solutions?  Red Hat, like other software vendors, continues to monitor and participate in developing solutions which meet emerging market requirements, customer demand and ongoing cybersecurity requirements issued by governments around the world.

There are three aspects to cybersecurity which Red Hat examines to evaluate the overall security posture of an offering, but this blog will focus primarily on the first.

1. How securely is the offering built?

2. How secure is the infrastructure of the software supply chain?

3. Securing how the software will be used (security features and functions).

The idea of secure software development as a means to standardize security practices is the basis of a secure development lifecycle (SDL), and has been around for many years. The prevalence of these practices led the National Institute of Standards and Technology (NIST) to publish their secure software development framework (SSDF), which is now a government-recommended SDL.

A colleague recently wrote, “The discipline needed to produce robust, resilient software-based solutions requires everyone to improve their software use and production processes (independent of its #opensource or proprietary development).”

Two key processes at Red Hat are incident response from discovered vulnerabilities and secure development of the code. Both of these processes leverage the type of data commonly found within or associated with a software bill of materials (SBOM). Independent of SBOM requirements, Red Hat is focused on the collection and management of software code and identifying vulnerability data which will satisfy both of these processes.

This continues to be a subject of discussion within most Product Security Incident Response Teams (PSIRTs) serving our internal stakeholders and external customers. Our ability to understand the composition of an offering, together with software development practices, speaks to the security of that offering and offers the starting point for attestation of security.

Maintaining a manifest of components used in all offerings in Red Hat with a formal process to review those components before they are released in an offering is essential to our mission. These manifests, along with data collected during our secure development lifecycle, will help provide information to understand an SBOM so the customer knows the risks in deploying an offering.

Our evolution and maturity of security in software development

Red Hat utilizes the NIST SSDF framework as a key reference for security in software development practices. We are working internally to align these practices with additional industry requirements and define standards measuring the degree of maturity with which that practice is met.

Our Product Security team works closely with each offering team to consult with and help improve the maturity of these practices. As one of many organizations that builds and offers software and services, we believe that the NIST SSDF approaches security from the perspective of a producer, whereas the NIST Cybersecurity Framework (CSF) focuses on the perspective of consumers of software/services. Red Hat is in a unique position as both a consumer and producer of software, but we believe our adoption of SSDF strongly supports the needs of our customers.

What is a software bill of materials?

The code or components used when building an offering is one of today’s top concerns for all software developers, publishers and users. At Red Hat, we look at this concern as an opportunity to leverage our “default to open” mantra by leading the open source community in building a registry of all open source software components used in our portfolio of offerings. A software bill of materials (SBOM) is a collection of data related to those components, however, our ability to collect this data is key to the ability to provide an SBOM file. We believe that this data not only helps us improve the security of our offerings but also provides greater transparency into the security of those offerings.

A component registry is, at its heart, a catalog of all components, including their version, origin and relationship with built offerings. The registry offers, in essence, live data which leads to SSDF attestation and SBOM output that can be generated for all products at any point in time. The key to a successful registry is in the completeness and accuracy of the data that it provides.  

What do we hope to achieve with a component registry?

Red Hat’s Product Security team has always relied on accurate manifest data to assist our incident response engineers with vulnerability analysis, but work was needed to aggregate that data and improve consistency. That work evolved into a broad initiative to build a component registry with comprehensive component data, and which will be supported by our entire portfolio.

Additional data is always nice, but what does a component registry provide Red Hat and our customers? It gives us a more complete and higher-level view of the component origin, making it possible to draw better conclusions about the security of the supply chain. A component registry is also foundational to an offering registry and the ability to attest to the maturity of software development security practices for all offerings. Finally, having comprehensive and accurate component data allows for automation and improvements to vulnerability management.  

A comprehensive registry equals world-class vulnerability management  

When we talk about vulnerability management, we often think about flaws, weaknesses, or maybe just the latest CVE (Common Vulnerabilities and Exposures) we’ve read about. However, vulnerability management must include more than vulnerability identification — you have to actually take action to manage the vulnerability itself.

The registry will allow us to equate a CVE with component versions and then generate an accurate list of all products affected. If we can do that for one CVE, then we can do that for all known CVEs. If we can couple the known vulnerabilities with the status of each security practice mentioned in the NIST SSDF, then we are able to better understand an offering’s overall security posture or readiness. This then empowers our customers to make decisions while considering requirements such as authentication, boundary protection, or logging. 

We believe the buildout of a component registry, alignment with SSDF and the ability to merge these data sets together to provide product attestation of security compliance will help meet the demands of various security regulations. At the same time, the ability to disclose that data in a transparent and open manner will also help meet customer demands for additional security data in the software they are using for enhanced software supply chain security.

Learn more

• Red Hat Product Security Overview

• Red Hat Product Security Center

• Red Hat blog channel: Security