Secure your CI/CD pipeline with Trusted Delivery
CI/CD pipelines are integral to modern software development teams. Find out the security risks associated with CI/CD pipelines and how trusted delivery can help you mitigate them.
A continuous integrations/continuous delivery (CI/CD) pipeline is the cornerstone of the software development process. A typical CI/CD pipeline has access to proprietary code, credentials, secrets, and databases and uses a multitude of tools - such as Jenkins, Travis, and CircleCI - provided by multiple vendors. To a hacker, this pipeline amounts to a treasure trove of data and artifacts that can be maliciously exploited.
In the infamous SolarWinds attack, attackers injected malware into the build software pipeline. A pipeline that delivered ‘signed and trusted’ software to over 18,000 customers worldwide, including high-profile companies and government organizations.
The pervasiveness and the impact of the SolarWinds attack demonstrate how vulnerable CI/CD pipelines can be and the importance of securing CI/CD pipelines, for large and small companies alike.
In this blog, we will outline some of the security risks associated with the CI/CD pipelines and how Trusted Delivery using policy as code can help mitigate those risks and prevent catastrophic breaches from taking place.
CI/CD Security Threats
There are numerous security threats in a CI/CD environment, some of which include:
- Insecure third-party code, including open-source libraries, can include malware when imported into the build.
- Unauthorized access to source code or any of the CI/CD tools can give way to malicious code injection into an application.
- Poor management of secrets and confidential information (such as hardcoding passwords into IaC) can be used by hackers to execute a breach.
- Insecure or misconfigured system configuration settings can be leveraged by an attacker to gain unauthorized access to the system.
- The pipeline's lack of flow control mechanisms (no external verification or validation) can allow an adversary to push malicious code to production.
- Poor identity and access management due to overly permissive or stale identities could serve as a segway into the production environment.
The rise in the amount and magnitude of incidents focusing on flaws in the CI/CD pipeline makes it imperative that we create an environment of trust where developers can securely maintain their agility.
Introducing Trusted Application Delivery
Trusted delivery describes the practice of embedding security guardrails into the CI/CD workflows in code format. These security guardrails, also called security as code or policy as code can be company-mandated policies and/or industry best practices. By integrating security into the software pipeline, you can detect and fix security vulnerabilities early in the software lifecycle. With trusted delivery, you can also monitor and test your runtime environment to identify and respond to threats that may arise in production.
Using policy as code, you can enact and enforce three types of policies:
- Security policies ensure that security best practices, such as the MITRE ATT&CK, are implemented and can prevent any misconfigurations from taking place.
- Resilience policies, when enforced, make your system fault-tolerant and highly available, which in turn means better business continuity.
- Coding standard policies can be company-mandated rules and checks, helping organizations apply governance standards across the whole organization.
By embedding security and policy checks in the software development pipeline, developers can find and fix security flaws and defects early on. After all, software defects are easier to fix, consume less time, and are cheaper to fix if caught early on. According to IBM Systems Sciences Institute, it can cost 100x more to fix a software defect in production compared to in the design phase.
Trusted delivery provides that element of trust, where every piece of code and artifact is rigorously checked against numerous checks and controls before making it into production.
LIVE WEBINAR: Security Across Hybrid Cloud with GitOps and Policy as Code
Sign up today to learn how to shift from manual to automated cluster provisioning with policy and security checks in place
Register NowSecuring CI/CD Pipelines with Trusted Delivery and GitOps
GitOps is an operational framework for developing, delivering, testing, and deploying cloud-native applications. Using Git as the single source of truth, GitOps relies heavily on automation and uses directors (such as Weave GitOps) to deploy changes to the cluster.
Before we jump into how you can achieve the trust factor and secure the pipelines, let’s take a look at a typical GitOps workflow.
A developer (Dev) pushes codes to Git; that code is then picked up by the Continuous Integration (CI) system. The CI tool then runs some tests on the code and uses it to build container images which are then pushed to the image repository before being deployed to a Kubernetes cluster.
In the Kubernetes cluster, Weave GitOps runs the reconciliation operator (built on FluxCD) and continuously monitors the actual state to ensure it matches the desired state as declared in Git.
Ideally, you can embed security checks or ‘developer guardrails at these points in the GitOps pipeline.
1. Git Repository- IaC Scanning
Misconfigurations within the infrastructure as code (IaC) files are the most common in the misconfigurations categories. Scanning IaC templates against codified policies before commit time helps developers catch and fix misconfigurations early on.
2. CI Stage - Misconfigurations Detections
At this stage, the developer will receive build-time feedback. Another set of checks is run in the CI system, with detected violations flagged and blocked.
3. Kubernetes Clusters - Deploy Time Feedback
Developers will receive feedback at the deployment stage if the deployment artifact violates any of the specified policies. This will help mitigate some of the potential security, such as over-privileged containers or insecure networking configurations.
4. Configuration Repository - Runtime feedback
After code is deployed to production, we continuously scan the runtime production against the codified policies to detect any violating system configurations.
Trusted Delivery with Weave GitOps
Weave GitOps, a full-stack GitOps platform, simplifies the management and deployment of Kubernetes clusters and applications at scale in any environment.
With Weave GitOps, you can create, enforce, and manage policies that you want to enforce in your pipeline. Policies are built on standard Open Policy Agent (OPA) rego, stored and managed in Git. Using Git to manage the active policies, you can create approval and review workflows, see version history, and get a complete audit trail of who changed what and when.
Weave GitOps enables swift and easy trust delivery through the Weave Policy Library, a catalog of 100+ OPA-based policies that DevOps and Platform teams can embed into their pipelines. The library includes operational and DevOps best practices and industry standards such as CIS Benchmarks, NIST, PCI DSS, GDPR, and MITRE ATT&CK.
Check out our Weave GitOps Enterprise page to learn more about how you can secure your CI/CD pipeline with Trusted Delivery or Request a Demo with one of our experts.
Whitepaper: Trusted Delivery with GitOps and Policy as Code
Download our latest whitepaper and learn how automated security and compliance checks, in the form of policy as code, make automated continuous deployments safe and secure.
