How to strengthen security in your CI/CD pipeline

SnykSec - Jul 13 '23 - - Dev Community

DevSecOps refers to the integration of security practices into DevOps process. With modern development cycles, you can't afford to leave security until the end. It should be baked in at every stage.

Continuous integration, continuous delivery (CI/CD) security is a big part of the DevSecOps picture. It's critical that you secure your pipelines and that the automated systems used to implement CI/CD are not vulnerable to attack.

In this article, you'll learn about security risks that can threaten your CI/CD pipeline. You'll also learn how to build pipelines that are hardened against attack and how to test them to verify their security.

Why you need to secure your CI/CD pipeline

When thinking about security, web applications and public-facing services are usually the focus. Seemingly niche concerns, such as your pipeline, are easy to leave out of the security picture, but that's a mistake as the consequences of inadequate CI/CD security can be severe.

A compromised pipeline can grant hackers access to your systems. That can include access to your code, valuable data, and client secrets. Once one part of your pipeline is compromised, everything on your pipeline is vulnerable.

There's also the risk of malicious code injection, a subtle but highly serious form of attack. A hostile actor with access to your pipeline can insert their own code, which can then be integrated into your final build without your knowledge. Your deployed application is then compromised, giving attackers free rein to steal data from you and your users.

In addition, a compromised build chain can leak secrets. Passwords or credentials used to grant authorization to your tools can be stolen and used to access other parts of your system. A hacker can do a lot of damage with stolen credentials, so it's essential you keep them safe.

Moreover, beware of using outdated components, as these can be the most vulnerable to attack. New attack vectors are discovered all the time, and software is updated and patched to remove them, but older software remains unprotected.

Updating your software to the latest versions has many benefits aside from security, and keeping your toolchain up-to-date should be a core part of your security strategy.

Building a secure CI/CD pipeline

Fortunately, there's a lot you can do to defend yourself from attack. Let’s run through some of the measures you can take.

Implement role-based access control

Role-based access control (RBAC) lets you limit access to different parts of your system. With it, you can grant access to people based on their roles. That makes it easier to develop a secure set of rules with different levels of access that can be quickly implemented.

Managing access on a per-user basis sounds secure, but in practice, it leads to problems, such as old accounts being overlooked and privileges being granted for too long. With RBAC, you have a fixed set of rules in place that can be granted or withdrawn together.

Scan for vulnerabilities

Automated tools are an essential part of scanning for vulnerabilities. Thankfully, there are many different security scanning systems available to help you find issues quickly and efficiently. They can detect coding errors or configuration problems that leave your system open to attack.

You can also call in outside help by having a third-party perform a security audit to spot things you may have missed. Someone who isn't as close to the project as you can find blind spots you might not have considered.

Use a secrets manager

Secrets managers are tools that store and manage access to sensitive data such as credentials or keys. By limiting who, where, and how such data is made available the chances that it will be leaked are greatly reduced. Additionally, a good secrets management tool will encrypt the data both at rest and in transit, minimizing the impact if it is leaked.

Many CI platforms have their own integrated secrets/credentials management system and some can even integrate with popular external secrets management systems.

Manage network exposure

Unrestricted network access can leave your CI/CD systems vulnerable to attack from external actors (ingress) as well as allowing for easy exfiltration of data (egress). Managing network exposure by means of shutting down access your pipeline doesn’t need keeps you safer.

For instance, you should open a minimum of ports and close them when they're not needed. In addition, make sure you switch off remote features you don't need. Docker sockets, APIs, and any means by which your systems communicate with the outside world all need to be heavily guarded.

Limit trust boundaries

Another way to mitigate risk is to limit trust boundaries as much as possible. Any communication between outside systems or users needs to be secured. Make sure you limit what's allowed to only what you need and, preferably, grant access only for a specific period.

Making sure all the different parts of your chain leak the least amount of information also makes you harder to hack. Text output, such as error messages, could make it into a public-facing part of your system and can then be used to build a detailed picture of your infrastructure that can assist hackers in targeting their attacks.

To prevent this, in some cases, you can call commands with minimal output, meaning any logs or output messages that might get leaked provide as little information about your system as possible.

For example, the wget command in Bash outputs all kinds of information. That can be suppressed with the q flag, like this:

wget -q https://google.com
Enter fullscreen mode Exit fullscreen mode

Hackers often work along your toolchain, gaining knowledge about your system as you go, so minimizing output minimizes their opportunity to do so. You can apply similar flags to other commands.

How to automate CI/CD pipeline security

Thankfully, several of these issues can be handled using a security product, such as Snyk, that runs as part of your build pipeline, helping you quickly detect and respond to issues.

For example, running a vulnerability scanner on your pipeline can detect issues arising from outdated components. Snyk can both find and detect these kinds of issues. To find problems from the terminal, just type the following:

snyk test
Enter fullscreen mode Exit fullscreen mode

You can also integrate your source code management, such as GitHub, with Snyk tol automatically add PR Checks to detect new vulnerabilities introduced in dependencies, containers, or infrastructure as code policies:


You can find out more about integrating Snyk with PR checks in Snyk’s support docs.

How to integrate security testing into a CI/CD pipeline

Security tests can be included in your pipeline, and there are several things tests can look for, so be sure to cover all of them.

RBAC

As mentioned, RBAC is a great way to secure different parts of your system. Regular tests can ensure it stays secure. Automated checks can verify that users only access resources that correspond to their role. For instance, a test with an anonymous user should not be able to access resources you want to restrict to authorized users. For example, this kind of test could fail if you update software and its settings change, meaning previously implemented settings changes are no longer applied.

APIs

API tests are another thing that can be automated. Again, for security purposes, you want a mix of tests that succeed with the proper credentials and fail if they don't have them.

Successfully accessing a resource without the proper credentials is a security failure. Automated API tests are a way to check this regularly and quickly. You can also check that your APIs return the expected result and respond adequately to malformed requests designed to compromise your security.

Secrets

Secrets tests let you check if your secrets are exposed at any point. Pipelines have to manage passwords and tokens, and the tools in your chain need the right privileges to perform their roles.

Beware of leaking your secrets in the tests, as these can be accessed. Synk can spot hard-coded secrets in your code or scripts, allowing you to fix the problem.

How to secure a Jenkins CI/CD pipeline with Snyk

To get started with Snyk, you need to sign up and install its client locally — installation instructions are available here. For example, if you have npm, you can use the following code:

npm install snyk -g
Enter fullscreen mode Exit fullscreen mode

Snyk also integrates with major cloud providers as well as many other CI/CD tools, and there are many Snyk plugins that facilitate this. For example, to use it with Jenkins, go to the Jenkins dashboard, and then to Manage Plugins. Then find Snyk Security under the Available tab. Make sure you don't forget to register the plugin and connect it to your account.

Once you've integrated Snyk, you can add it as a stage on your pipeline with the snykSecurity entry:

//build stage omitted 

stage('Test') {
      steps {
            echo 'Testing with Snyk'
            snykSecurity(
                  snykInstallation: '',
 snykTokenId: '',
 // other parameters here
 )
 }
}

//deploy stage omitted
Enter fullscreen mode Exit fullscreen mode

The following are other additional commands you can use to control how Snyk behaves:

  • failOnIssues and failOnError: These commands allow you to stop your script on either of these conditions, preventing any problems Snyk detects being pushed into deployments. That's an especially good idea if your CI/CD automates the deployment of anything that goes live.
  • severity: This lets you specify the level of issue Snyk will investigate. You could potentially ignore less serious issues, allowing builds to continue if only minor issues are detected. You could even run a separate build step with a different behavior based on issue severity.

When you run your builds, you can see if there are problems via the Snyk console, and you can check the logs in detail to find out what you need to fix.

That's how to set up Snyk with Jenkins, but there are many other possibilities, including integrating Snyk with GitHub or cloud providers such as Amazon Web Services (AWS) and Azure.

Conclusion

Your CI/CD pipeline is a critical but easily overlooked part of your security picture. There are many ways hackers can exploit it, so it's essential that you take steps to mitigate every attack vector.

You need to be defensive and try to stay one step ahead of those looking to compromise your systems. Security updates, automated testing, and role management are just a few of the ways to harden your system and keep the bad guys out.

Snyk is a great tool to have in your arsenal, offering you control of your pipeline. Check out their website and get started defending your CI/CD security. Snyk makes staying safe easy.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .