At Red Hat Summit 2023, we addressed the market demand for tools and services that help secure the software supply chain by announcing two projects that will change the way developers and ops develop and deploy their applications to Red Hat OpenShift. These projects are the Red Hat Trusted Application Pipeline and Red Hat Developer Hub.
Meanwhile, with the help of customer feedback, these projects have matured into Red Hat products that are available for self-managed deployments and are part of a product family that addresses the software supply chain from end to end—Red Hat Trusted Software Supply Chain. Figure 1 shows this complete supply chain.
Which challenges do we address?
Red Hat has long been acknowledged as the provider of enterprise strength frameworks and platforms, notably Red Hat Enterprise Linux and OpenShift, the enterprise distribution of Kubernetes. Both are incredibly powerful product sets, but to get the most out of them, we have to understand and use them as experts would. Most developers and ops personnel don’t have the time, on top of their day-to-day jobs, to learn every aspect of the underlying technology. The likely result of this missing knowledge is the eventuality of various security issues.
The key issue with deploying applications nowadays is a combination of a lack of domain knowledge when it comes to using and exploiting all the power of Kubernetes, and an obliviousness to potential risks within the code itself, both the code written by the developer and, more importantly, risks within code that is sourced external to the organization, such as imported libraries.
Software is vulnerable
I come from a developer background, and developers are focused on delivery. We build our pieces of software, we use external libraries when we don’t want to reinvent the wheel, and we want to be creative. Our focus is always on our creativity. Is our code good enough? Have we written it to be efficient? We make assumptions about the libraries we import and use because we don’t have time to review every single line of code in them. We’re always busy writing and delivering the code we own—without wondering if we have written it securely.
This became all too evident with the Log4j Log4Shell vulnerability. Java developers had been using Log4j for years without knowing it had a critical vulnerability in it. We just assumed it was fine to use because it’s a library. The more cynical of us would say, “not our problem,” because we don’t have responsibility for that code. We make assumptions about the code of the libraries because they work.
Now that we live in the generation of the container, this problem has gotten a little bit worse. Not only do we now have the capability to import exploits through libraries and external software, we also have the ability to use base images for our containers that might contain hidden exploits.
This new concept of inherited flaws falls somewhere between the developer and the ops person. The developer has responsibility not to use any code with known exploits. The ops person has the responsibility not to deploy exploitable components—and additionally monitor deployments for abnormal behavior or new security risks (notably new exploits, CVEs) as they occur.
Kubernetes is complex
In addition, the nature of container orchestration platforms and Kubernetes in particular means that this kind of operation, building and deploying applications, can be painfully complicated. Throw in new technologies like Tekton for automating everything as pipelines, and suddenly, both developer and ops must be highly skilled in Kubernetes to deploy their applications. This should never be the case. Tools should assist and ease the operation in a problem space. Kubernetes is complex by design, but it can and should be simplified in such a way as to abstract deep knowledge to the point that a user can just get on with their jobs rather than having to become an expert.
Solutions: Red Hat Trusted Software Supply Chain
Red Hat has built products that address this problem space in a modular yet integrated manner from end to end, as shown in Figure 2 and described in the following sections.
Red Hat Trusted Application Pipeline
Specifically addressing the need to increase the security of the software supply chain, Red Hat Trusted Application Pipeline adds a lot of capabilities to your toolset, all configurable but with a Red Hat opinionated set of templates and configurations to start with, including:
- A developer portal with security-focused Software Templates, supporting developers to develop code with integrated checks to stay compliant with the organization's security practices.
- The ability to sign and verify code commits or arbitrary build artifacts in a “keyless” signing paradigm, to tamper-proof code while avoiding the need to issue and manage signing keys (issuance, rotation, invalidation, and revocation).
- The ability to automatically generate and store SBOMs (Software Bills of Materials) of your containers, from the container OS level to your application artifacts.
- The ability to achieve and verify build provenance and Supply-chain Levels for Software Artifacts (SLSA) compliance with an automated chain of trust that uses enterprise contracts integrated with cryptographic signing tools as approval gates to stop suspicious build activity from being promoted.
- Pipelines-as-code definitions and templates, incorporating best practices and build system attestation (required for SLSA compliance) to support continuous deployment, with built-in vulnerability scanning and policy checking directly from the CI/CD pipeline that report on the latest CVEs.
- User-friendly storage, management, correlation and cross-referencing of SBOM and Security Advisory (VEX: Vulnerability Exploitability eXchange) data, gathered from your own build processes or provided by vendors (such as Red Hat) that automatically index and analyze newly pushed images against vulnerability databases.
All of these capabilities (and many more) come with the ease of a single wizard-driven installer that makes it easy for the platform (or operations) team to adopt them.
Providing a security-aware application delivery pipeline that serves developers as much as operations teams has never been easier.
While Red Hat Trusted Application Pipeline has been designed with ease-of-use and a full end-to-end view in mind, these capabilities can also be added to your software supply chain individually.
Red Hat Trusted Application Pipeline provides the fully integrated installation and usage experience of the following Red Hat products, detailed below.
Red Hat Developer Hub
Red Hat Developer Hub is an enterprise-grade platform for building developer portals containing a supported and opinionated framework, based on the Backstage open source project. By implementing a unified and open platform designed to maximize developer skills, ease onboarding, and increase development productivity, focus can be centered on what really matters: writing great code. Red Hat Developer Hub also offers Software Templates to simplify the development process, which can reduce friction and frustration for development teams, thereby boosting their productivity and increasing an organization's competitive advantage.
Platform engineers can benefit by implementing a tailored platform with a complementary suite of verified and curated tools and components needed for operations teams to support developers—within a centralized, consistent location. Development teams can experience increased productivity, fewer development team obstacles, and simplified governance of technology choices with self-service and guardrails.
[ Download the e-book: Developer Portals: Prepare to Perform with Red Hat Developer Hub ]
Red Hat Trusted Artifact Signer
Red Hat Trusted Artifact Signer, Red Hat’s enterprise-ready and fully supported build of the open source Sigstore project has been designed to enhance software supply chain security through a variety of significant advantages.
Red Hat Trusted Artifact Signer provides a transparent and secure system for software developers to sign software artifacts, such as binaries and container images. While artifact signing and verification has been around for quite a while, this typically involves the need to issue and manage signing keys (issuance, rotation, invalidation, and revocation.)
Red Hat Trusted Artifact Signer aims to make cryptographic signing accessible for all developers, including those with limited security expertise. It simplifies the process of signing and verifying software artifacts by tying a signing event to the user’s identity instead of a “nameless” key, encouraging more widespread adoption of secure software development practices—and since it is compatible with all major tools (such as git/gitsign/cosign), signing a code commit is as easy as authenticating with the company OpenID Connect (OIDC) system.
git commit, login/authenticate—and that's it. It’s as easy as that.
As a developer, there is no need to find (and protect) your keys on your hard drive and try to remember your key’s password. It is all tied to the user identity.
Also, Red Hat Trusted Artifact Signer’s design includes measures to mitigate the impact of key compromise, such as short-lived keys and the use of transparency logs to detect malicious activity.
Due to its broad compatibility, integrating its signing and verification features into your existing supply chain is straightforward.
Additionally, it is compatible with Enterprise Contract, which allows to easily verify SLSA compliance (among other things), including the existence of a valid artifact signature, supported by a signing event in the tamper-proof transparency log.
The ec binary for use in the CLI or automated processes, such as a pipeline, is also part of the Red Hat Trusted Artifact Signer installation.
Red Hat Trusted Profile Analyzer
Red Hat Trusted Profile Analyzer provides the storage and management means for Software Bills of Materials (SBOMs), with cross-referencing capabilities between SBOMs and CVEs/Security Advisories that are continuously ingested from trusted sources (such as Red Hat).
SBOMs have become increasingly important to today's supply chain security for several reasons. Their significance stems from the growing complexity of software applications and the myriad of components that comprise them, including open-source and proprietary elements. Key reasons include:
- Visibility and transparency: SBOMs provide detailed inventories of all software components in an application, including libraries, packages, and modules. This visibility is essential for understanding the software's composition, which is the first step in securing the software supply chain.
- Vulnerability management: With a comprehensive SBOM, organizations can quickly identify which components may be affected by newly discovered vulnerabilities. This allows for prompt mitigation measures, such as patching or updating components, to protect against potential security breaches.
- Compliance and licensing: SBOMs help organizations ensure compliance with licensing requirements by detailing the open-source components used in software. This can prevent legal issues related to copyright infringement or non-compliance with open-source licenses.
- Risk management and security analysis: By analyzing the components listed in an SBOM, organizations can assess the security posture of their software, identify potential risks, and implement necessary controls. This is crucial in preventing supply chain attacks.
- Facilitate software assurance: SBOMs support the practice of software assurance, ensuring that software is free from vulnerabilities, functions as intended, and does not contain malicious code. This is particularly important in critical infrastructure and high-security environments.
- Regulatory compliance: Governments and industry regulators are increasingly recognizing the importance of SBOMs for cybersecurity. For example, the United States has issued executive orders mandating the creation of SBOMs for software used by the federal government, setting a precedent that will surely lead to broader adoption.
- Enhanced trust among stakeholders: Providing an SBOM to customers and partners demonstrates a commitment to security and transparency, enhancing trust in the software and the organization that developed it.
In conclusion, SBOMs play a critical role in modern supply chain security by providing the necessary transparency, facilitating effective vulnerability management, ensuring compliance, and enhancing risk management practices.
Having a database to collect and search all your SBOMs from your own and vendor products is great and useful, but the primary use case is driven by the question—are the products in my database affected by a vulnerability? And if yes, what is the impact, what are the details, what is the “blast radius?”
These are the key questions that Red Hat Trusted Profile Analyzer can answer.
Complementary Red Hat products
Beyond the capabilities of Red Hat Trusted Application Pipeline as a new Red Hat product, we believe that two of our established products complement the supply chain to form the Red Hat Trusted Software Supply Chain.
Red Hat Quay
In addition to being a fast and robust highly scalable container registry with fine-grained access control, in a security context Red Hat Quay adds continuous scanning of images for CVEs. In a secure and trusted software supply chain, all container images should continuously undergo security scans—regardless of where they come from, be it a pipeline build, a vendor, or some other source.
Even if they come from your trusted software supply chain and have been scanned and verified during the build process, new CVEs might occur between active pipeline runs (and their scans). Therefore, it is a good security practice to scan images “at rest.”
Red Hat Advanced Cluster Security for Kubernetes
Red Hat Advanced Cluster Security for Kubernetes is a Kubernetes-native security platform that equips you to build, deploy, and run cloud-native applications with more security. The solution helps protect containerized Kubernetes workloads in all major clouds and hybrid platforms, including Red Hat OpenShift, Amazon Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE).
It can be integrated in the build and deploy (CI/CD) stages of your software supply chain, but will also monitor running deployments for CVEs, policy violations of built-in or custom policies. It is highly configurable, from a simple warning about a fixable, medium impact CVE to stopping running deployments if suspicious behavior (such as a crypto mining process) is detected.
Both Red Hat Quay and Red Hat Advanced Cluster Security for Kubernetes are included with Red Hat OpenShift Platform Plus, a complete set of powerful, optimized tools to secure, protect, and manage your apps.
Summary
The Red Hat Trusted Software Supply Chain family of products comprise a composite solution that will make it far easier and more secure to create, deploy, and host applications in the container era. Together, they deliver a seamless developer experience that increases their productivity without additional cognitive load or heavy context switching.
These products take advantage of the concept of Software Templates, which are defined but configurable guided routes to end states, making it easier for developers and ops to achieve what they need in the quickest and most secure way possible. The combination of these products provides a powerful and essential solution to the day-to-day issues facing an organization adopting DevSecOps in a container-centric world.
Interested? Visit our Red Hat Trusted Software Supply Chain product family page to learn more.
