Not only did the IT business appear substantially different 20 years ago, but so did product security. Open-source software was not widely used, and the majority of vendors maintained complete control and privacy over their product code.
Today, almost every software vendor contributes to and includes open-source software into their product or managed service (herein referred to as “services”), but how does this affect the security of these offerings? What, in particular, is Red Hat doing to demonstrate that our offerings are produced securely and provide reliable solutions? Red Hat, like other software suppliers, continues to watch and engage in the development of solutions that satisfy evolving market requirements, customer demand, and ongoing cybersecurity regulations imposed by governments worldwide.
Red Hat considers three dimensions of cybersecurity to determine an offering’s overall security posture, but this article will focus mostly on the first.
The concept of safe software development as a means of standardizing security measures has been around for many years and is the foundation of a secure development lifecycle (SDL). The National Institute of Standards and Technology (NIST) published their secure software development framework (SSDF), which is now a government-recommended SDL, in response to the popularity of these activities.
“The discipline required to generate robust, resilient software-based solutions demands everyone to improve their software use and production processes (regardless of whether it is #opensource or proprietary development,” a fellow recently wrote.
At Red Hat, two important processes are an incident response from found vulnerabilities and secure code development. Both of these procedures make use of data that is usually available in or linked with a software bill of materials (SBOM). Independent of SBOM requirements, Red Hat is focused on collecting and managing software code as well as detecting vulnerability data to satisfy both of these procedures.
Most Product Security Incident Response Teams (PSIRTs) that serve our internal stakeholders and external customers continue to discuss this. Our understanding of the structure of a providing, together with software development methods, speaks to the security of that offering and provides a starting point for security attestation.
Maintaining a manifest of components used in all Red Hat offerings, as well as a systematic process for reviewing those components before they are issued, is critical to our purpose. These manifests, coupled with data acquired during our secure development lifecycle, will aid in understanding an SBOM so that the customer is aware of the risks associated with delivering an offering.
The NIST SSDF framework is used by Red Hat as the main reference for security in software development techniques. Internally, we are trying to match these practices with additional industry needs and to create standards for monitoring the level of maturity with which those practices are met.
Our Product Security team consults with and helps develop the maturity of these practices in collaboration with each product team. As one of many firms that develop and sell software and services, we believe that the NIST SSDF tackles security from the perspective of a producer, whereas the NIST Cybersecurity Framework (CSF) focuses on software/services consumers. Red Hat is in a unique position as both a software consumer and creator, but we feel that our adoption of SSDF significantly supports our customers’ demands.
One of today’s top concerns for all software developers, publishers, and users is the code or components utilized to build a solution. At Red Hat, we see this as an opportunity to leverage our “default to open” mantra by leading the open-source community in the creation of a registry of all open-source software components utilized in our portfolio of solutions. A software bill of materials (SBOM) is a collection of data relating to those components, but our ability to collect this data is important in providing an SBOM file. We feel that this data not only assists us in improving the security of our offerings but also gives better insight into their security.
At its core, a component registry is a catalog of all components, including their version, source, and relationship to built offers. The registry provides, in essence, real data that leads to SSDF certification and SBOM output for all products at any time. The completeness and quality of the data provided by a registry are important to its success.
The Red Hat Product Security team has traditionally relied on reliable manifest data to help our incident response engineers with vulnerability investigation, but more effort was needed to consolidate that data and ensure consistency. This work grew into a larger initiative to create a component registry with detailed component data, which would be backed by our entire portfolio.
More data is always useful, but what can a component registry provide Red Hat and our customers? It provides us with a more full and higher-level perspective of the component origin, allowing us to form more accurate conclusions regarding the supply chain’s security. A component registry is also required for an offering registry to certify the maturity of software development security practices for all offerings. Finally, having complete and accurate component data enables automation and vulnerability management enhancements.
When we think of vulnerability management, we frequently think of flaws, weaknesses, or the most recent CVE (Common Vulnerabilities and Exposures) that we’ve read about. However, vulnerability management must encompass more than just identifying vulnerabilities; you must also take action to address the vulnerability itself.
The registry will enable us to associate a CVE with component versions, resulting in an exact list of all goods affected. If we can do it for one CVE, we can certainly do it for all known CVEs. We can better evaluate an offering’s total security posture or readiness if we combine known vulnerabilities with the state of each security practice mentioned in the NIST SSDF. This then allows our customers to make decisions while keeping requirements like authentication, boundary protection, and logging in mind.
We believe that the development of a component registry, collaboration with SSDF, and the ability to combine these data sets to give product attestation of security compliance will help in meeting the needs of various security standards. Simultaneously, the ability to publish that data transparently and openly would assist address customer expectations for extra security data in the software they use for improved software supply chain security.
Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.
For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com