Automating Security in CI/CD Pipelines with Policy-as-Code

Introduction

Integrating security into product development as part of the DevSecOps philosophy brings significant long-term benefits. However, often developers omit to include security into the development processes that support application production.

DevSecOps revolves around the continuous integration and continuous deployment (CI/CD) pipeline to automate the generation and release of product artifacts as part of the overall development process pipeline. This increases production efficiency and minimizes time to market, critical factors in an agile development environment.

The quality and dependability of these artifacts directly depend on the pipeline's integrity. Therefore, the pipeline must be secure if the product is to be secure.

Why Security Matters

An attacker able to compromise the CI/CD pipeline can easily create processes that insert malware into the deployed applications. As a result, consumers of the applications see a product provided by a trusted source. It's common for organizations to focus security controls on downloaded applications from unknown or untrusted sources such as the internet. The ability of an attacker to bypass these controls by piggybacking malware into trusted code makes this an attractive target.

Attackers have used this strategy quite a few times in recent years, most notably the SolarWinds attack, where a software update from a trusted supplier containing malware could infect many of their customers, including US Government departments and prominent commercial organizations.

The CI/CD pipeline can also function as a data leak, a point in the code processing lifecycle where an attacker can gain unauthorized access to proprietary or confidential source code outside its secured repositories and potentially unprotected.

Securing the Pipeline

1- Security Threats

Security needs application at each stage of the CI/CD pipeline; the robustness of the overall pipeline is only as good as the robustness of the weakest stage. Attackers can exploit code-centric processes such as configuration management, build, and test to introduce malware. An advanced persistent threat looking to infiltrate the pipeline to launch an attack down the supply chain will have the time and patience to undertake surveillance and probing to find the exploitable weak points.

Typical vulnerabilities seen in the CI/CD pipeline include:

• Insecure source code repositories can allow an attacker access to exfiltrate or modify code by exploiting access control weaknesses or compromised authentication credentials.
• Third-party source code, including open-source libraries, can include malware when imported into the build process.
• Insecure build processes can allow an attacker to exfiltrate code or inject malware into the built application source code or generated executable.
• Insecure test processes can allow an attacker to exfiltrate code or hide the presence of vulnerabilities or malware in source code.
• Insecure deployment processes can allow an attacker to inject malware into the deployed executable code.

2- Security Controls

Robust infrastructure controls can detect attacks launched on development tools and services that provide the first line of defense. Additional controls to protect source code within repositories and along the CI/CD pipeline include:

• Access controls can prevent unauthorized access to source code.
• Encryption techniques can prevent compromise to the confidentiality of source code.
• Hashing techniques can prevent unauthorized modification of source code.
• Static analysis tools help detect the presence of additional instructions added to the source code. Standard dynamic testing tools often fail to identify such maliciously added code.
• Testing processes that require demonstrable coverage against common vulnerabilities can detect exploitable code weaknesses.
• Source code scanning using pattern matching can detect the insertion of known malware.

3- Security Risks

The first step in securing a CI/CD pipeline is identifying and understanding the credible threats and matching existing security controls against each threat.

The application of controls should reduce the risk that any threat may compromise the pipeline. If a control doesn't reduce the risk, it's ineffective and requires replacement. Each threat should retain a residual risk level after considering controls. Management action is then necessary to assess the residual risk of each threat and decide if the residual risk is acceptable. If it is, then the businesses need to take no further action. Otherwise, the process will require additional controls if the residual risk is too high.

It's essential to bear in mind that risks change over time:

• First, existing threats increase in capability, increasing the pre-control risk.
• Second, previously unknown threats emerge, generating new risks.
• Third, existing controls become less effective, increasing residual risks.
• Fourth, new controls become available that are more effective at reducing risk.
• Finally, business practices and processes change, affecting how threats can materialize.

The key takeaway is that a business must periodically repeat the process of identifying and understanding the credible threats, especially after any notable change to the business processes or infrastructure.

4- Security Best Practices

While CI/CD pipeline security will vary from business to business, the following generic best practices provide guidance on the issues to consider.

• Keep all tools, applications, and services fully maintained and updated with security patches applied as soon as possible.
• Conduct security audits for all third-party supplied elements that feed into the CI/CD pipeline.
• Implement robust protection mechanisms for all data at rest and in transit across the entire CI/CD pipeline to prevent unauthorized access or modification.
• Implement robust access controls for all tools, applications, and services that use multi-factor authentication techniques to minimize credential compromise.
• Apply the need-to-know principle for source code and maintain comprehensive access logs to support an incident investigation.
• Implement image scanning for known vulnerabilities as an integrated pipeline process.
• Implement intelligent threat monitoring that uses pattern matching techniques for known threats and behavioral monitoring techniques for novel threats.
• Use infrastructure as code (IaC) to create a known safe environment for each development and test lifecycle iteration.
• Ensure satisfactory completion of all required security checks before deployment.
• Continuous monitor deployed applications to detect and remediate previously undetected compromise of the CI/CD pipeline.

Figure 1: Security in the CD/CI Pipeline

Automating Security

There are various options for implementing security across the CI/CD pipeline. However, the fundamental purpose of implementing a CI/CD pipeline is to realize the business benefits of automated process flows. Developers will quickly bypass or remove security controls that impede the pipeline flows. To be effective, integration and automation of security controls into the CI/CD pipeline processes are essential.

Automation allows the implementation of security best practices without adversely impacting the speed and quality of the development products. In addition, it will enable uninterrupted security and compliance processes within the continuous development workflow.

Securing Kubernetes

1- Best Practices

Kubernetes offers developers unique opportunities to implement good security practices into development processes. If you're a Kubernetes user, look at our top Kubernetes security best practices.

Application manifests define the configuration parameters for application deployment. Standard controls for containers and containerized applications are available from the US National Institute on Standards and Technology (NIST). Typical issues include unnecessary escalation of privileges that an attacker can exploit. Scanning the application manifest for compliance against these controls will eliminate known deployment vulnerabilities before deployment.

2- Configuration

For organizations utilizing Kubernetes for container orchestration, this brings advantages in simplifying cloud-native infrastructure. For example, a simple Kubernetes command can implement service delivery, replication, load balancing, and auto-scaling. However, to be secure, it requires a robust configuration. Therefore, we've provided valuable guides to prevent Kubernetes network policy misconfigurations with Policy as Code, as well as the six common Kubernetes configuration mistakes to avoid.

Where open-source repositories or other third-party sources supply container images, then developers should use scanning processes to search for security violations along the CI/CD pipeline using image scanning tools to detect known vulnerabilities.

3- Architectures 

Securing cloud-native architecture can still be a challenge for organizations. One of the security reinforcement approaches is running compliance checks against CIS benchmarks for Kubernetes as part of the pipeline processes. You can read more in our guide for enforcing cloud-native security with CIS Benchmarks for K8s using Policy-as-Code.

Benefits of Policy-as-Code

1- Establishing Compliance

Policy-as-code enables organizations to define and manage security policy using the same processes and techniques as application software, allowing security policy to integrate seamlessly into the development processes. As a result, managing security becomes part of the development tasks.

This integration prevents siloed workflows where development and security work in isolation. Developers may see a requirement for additional controls to manage threats as a pain point in achieving deployment deadlines. In addition, it ensures compatibility with the CI/CD pipeline and makes security as flexible and scalable as its protected applications.

Policy-as-code also supports automated audit processes, enabling continuous compliance monitoring and deviation reporting, even in non-persistent development environments.

2- Maintaining Compliance

It's important to note that implementing policy-as-code is not a one-time activity. Following the initial achievement of compliance, a continuous compliance monitoring process will be necessary to maintain compliance. Every iteration of the CI/CD pipeline process can trigger a policy violation.

Magalix provides a solution that detects and prevents such violations before deployment, making management more straightforward for organizations. You can find more information in our Product In-Depth Guide: Security Best Practices at Build and Deployment.

Conclusion

Policy-as-code brings significant benefits to security and compliance of the CI/CD pipeline, workflow management, access control, and threat detection. It can achieve this will an efficient, scalable solution that fits the CI/CD workflow philosophy, acting as a security enabler rather than a process flow inhibitor.

Magalix empowers organizations to integrate security-as-code into all CI/CD pipeline stages. This service allows businesses to enforce their security policy and reduce risks across infrastructure and embedded in workflows. Additionally, it will enable infrastructure monitoring that quickly detects and responds to security issues.