Continuous Integration (CI) and Continuous Delivery (CD), or CI/CD, are part of the Agile and DevOps approach to software development. The most prominent aspect of Agile development—and its most important rule—is that it requires software development to be responsive to change through an iterative process.

But software development projects often require large chunks of code, which take time to write. Bugs can go unidentified, and with different work being done by different teams, conflicts can slip by undetected until late in the process. This is not Agile.

CI and CD offer a solution to these common issues, allowing code changes to be made more frequently and more reliably. Security is part of this reliability, but it can often be overlooked in the CI and CD process.

What is CI/CD, and why implement it?

Continuous Integration is a methodology for software development that requires developers to integrate (check in) code to a shared repository on a frequent schedule. Code is usually checked in at least daily, but the right frequency really depends on how often code changes are made.

Each check-in is verified by an automated build. Errors are detected and immediately addressed.

Continuous Delivery builds upon Continuous Integration by using automated solutions to quickly deploy software applications. Multiple environments are typically used in the development process, such as testing and production, and CD ensures there is an automated mechanism to push code changes to all environments quickly. CD also automates needed service calls to web servers or databases, and restarts databases as needed when code updates are made.

Fortunately, you don’t have to build your own CI system. There are tools available that provide one, out of the box:

  • Jenkins is an extensible automated server that can be used as a basic CI server. It is a Java-based program with packages for Windows, Mac OS X, and other Unix-like operating systems. Jenkins includes error checks and built-in help, and it comes as a simple configuration through a web interface.
  • TeamCity is a Java-based CI server from JetBrains. It allows you to build, check, and run automated tests prior to committing source code changes. Progress reporting identifies issues during development.

The benefits of CI and CD include:

  • Agility—The Agile approach to software development usually breaks work down into one or two-week sprints, so the application is built incrementally. If developers wait until the end of each sprint to integrate their work, it takes longer to locate and address errors. With CI, frequent integrations identify errors immediately. They are addressed at the time of identification, resulting in fewer problems at the end of development.
  • Faster deployment—CI/CD is a faster way to build software. Frequent check-ins and testing of code prevent your team from having to rewrite large amounts of code if errors or conflicts go undetected for too long.
  • Better quality—Developers spend less time fixing errors when CI/CD is employed. They have more time to focus on higher value-added tasks, such as usability testing.

For a more in-depth look at the CI/CD process, including best practices, we recommend downloading this white paper.

Why security cannot be forgotten and how to build it in

Remember that the purpose of CI and CD is to produce reliable software. By definition, this means it must be trusted. It must be secure.

Security needs to be addressed from the very beginning as part of a DevSecOps approach, and should remain a high priority throughout the application lifecycle. Instead of the security team approving each software release, they should be approving the overall CI/CD process to make sure it is secure. Security should also be able to monitor and run security checks on the process at any time.

Let’s look at each step in the process to see how security can be built in:

Security of the CI/CD pipeline itself

As long as your team followed best practices for DevSecOps when setting up your CI/CD pipeline, this should not be an area of major concern. But it is worth noting here as it should not be overlooked.

Logins to the system should be tracked, pushing changes should require authentication, and builds should be stored on a secure server.

Integrated Development Environment (IDE) Pulls

Before the developer even commits code, static analysis tools should be used to check the code for vulnerabilities and coding errors. These tools are easy to set up, and save time in the long run by identifying issues during development.

This minimizes the amount of code review that is needed later in the process. Examples include Veracode plugins for Eclipse, Visual Studio, and SpotBugs.

The CI Build

Static Application Security Testing (SAST) tools can be used to make sure the code is free of vulnerabilities. SAST tools examine the application from the inside, looking at the source code, byte code, or application binaries for security vulnerabilities.

As part of the build process, any third-party code must also be scanned for security. It is not safe to assume that third-party code has been adequately tested. Many third-party components also have zero-day disclosed vulnerabilities, or are dependent upon other third-party components with vulnerabilities. Even if what you’re using is fine, it might be dependent upon code that isn’t. SAST and other tools must be used to make sure you aren’t introducing insecure code to your application.

Further, these tools can and should be integrated into your CI environment. Examples include OWASP Dependency-Check for third-party component checks and Checkmarx for SAST tools.

Application deployment into the development and test environment

Once the code has been verified, it is deployed to a development environment. At this point, you need to check the running version of the application for vulnerabilities.

This can be done with penetration testing tools such as OWASP ZAP and Dynamic Application Security Testing (DAST) tools. DAST tools approach the application from the outside, mimicking a “robot attacker” to find vulnerabilities.

Any tools used in this process should run quickly, as the purpose of CI/CD is rapid release. Overnight testing can be used to run lengthier code scans to allow for a more in-depth security check.

Once fully deployed into production, security testing should continue. New threats and vulnerabilities are constantly emerging, so you cannot assume your code is secure. For more details on SAST tools, DAST tools, and other application security testing tools, consult our blog.

How to manage security effectively in your CI/CD pipeline

Using a variety of application security testing tools at all stages of the CI/CD pipeline is the only way to make sure your application is always production-ready. But it can be difficult to manage the results coming in from all of these tools.

The easiest way to do this is to use an application vulnerability manager. This type of DevOps tool is not another testing tool. Rather, it combines the results and unleashes the true power and potential of your testing tools.

An application vulnerability manager:

  • De-duplicates results, delivering one report with a single set of results rather than multiple reports in mixed formats.
  • Assists with remediation management by identifying the specific lines of code where vulnerabilities exist.
  • Performs compliance checks, validating your code against such regulations as HIPAA, the Defense Information Systems Agency Security Technical Implementation Guides (DISA-STIG), and the Payment Card Industry Data Security Standard (PCI DSS).
  • Provides Hybrid Analysis . Hybrid Analysis combines the results of SAST and DAST tools, identifying which potential vulnerabilities are actually exploitable, so you can fix the most important issues first.
  • Allows for workflow integration. A tool that integrates with the environment in which developers are already working makes it simple to keep security a part of the process. Look for a tool that provides plugins for such popular environments as Eclipse for IDE, Jenkins, Visual Studio, Intellij, Burp Suite, and OWASP ZAP.

CI/CD is an important step in the Agile and DevOps approach to software development. But security cannot be sacrificed in favor of speed. Rather, security must be integrated into each step of the process. Rapid and secure releases are the product of a truly successful CI/CD process, one that produces software that is valuable to end users and protects those users and your company from vulnerabilities.