Security
Headlines
HeadlinesLatestCVEs

Headline

Ask An OpenShift Admin episode 117: Security considerations while designing a CI/CD Pipeline

When designing your CI/CD pipelines, security should not be an afterthought for application development. A comprehensive security approach—from code development to implementation—needs to start at Day 0.

According to the State of Software Supply Chain report, there has been a 742% average annual rise in software supply chain attacks over the past three years. A Cost of a Data Breach report found that 20% of data breaches are due to a compromised software supply chain. Possibly as a result, almost 1 in 3 respondents of the State of Kubernetes Security report experienced revenue

Red Hat Blog
#vulnerability#red_hat#kubernetes

When designing your CI/CD pipelines, security should not be an afterthought for application development. A comprehensive security approach—from code development to implementation—needs to start at Day 0.

According to the State of Software Supply Chain report, there has been a 742% average annual rise in software supply chain attacks over the past three years. A Cost of a Data Breach report found that 20% of data breaches are due to a compromised software supply chain. Possibly as a result, almost 1 in 3 respondents of the State of Kubernetes Security report experienced revenue or customer loss due to a security incident.

A CI/CD pipeline helps take your code and application from build to production and deployment, with testing involved in every step. Multiple tasks need to happen and security needs to be considered in each phase. Risks may be introduced within the code itself, during the application’s building and packaging process, or even during deployment.

Security can be strengthened at multiple stages of your pipelines. You can incorporate vulnerability scanning in the codebase itself or in its dependencies, scan container images, utilize a trusted image registry such as Quay.io or Clair, and perform penetration testing in testing environments, among other things. While these practices have existed for a long time, the increasing security concerns surrounding the entire supply chain have led to the emergence of new tools and practices.

What is a Trusted Software Supply Chain?

A trusted software supply chain adds key elements to a DevSecOps approach that allow you to make sure that you “trust” the components being deployed and that you can trace them back to a trusted source. For example, it allows you to deploy signed container images, generate Software Bills of Material (SBOM) for precise understanding of production components, and provide continuous runtime monitoring for applications deployed in production environments.

Tekton Chains, which will be generally available with Red Hat OpenShift 4.14, is installed with the Red Hat OpenShift Pipelines operator by default. It adds several capabilities that help implement a trusted software supply chain, such as:

  • Signing container images and taskRuns using Cosign, and storing the signatures in a secure container registry such as Quay.io.
  • Providing attestation provenance in different formats such as in-toto
  • Storing the artifacts metadata in a transparency log such as Rekor

To learn more, don’t miss the last episode of the Security Series on “Ask an OpenShift Admin” featuring Jaafar Chraibi, Andrew, and Jonny. Tune in to discover valuable insights on CI/CD pipeline security and see multicluster DevSecOps in action with this solution pattern.

At Red Hat, we offer Red Hat Advanced Cluster Security for Kubernetes as a way to evaluate and improve security throughout the application lifecycle. Try Red Hat Advanced Cluster Security today!

Jehlum is in the Red Hat OpenShift Product Marketing team and is very passionate about learning about how customers are adopting OpenShift and helping them do more with OpenShift!

Read full bio

Red Hat Blog: Latest News

A smarter way to manage malware with Red Hat Insights