What a CI/CD pipeline looks like with continuous security
How to insert security into your continuous integration and delivery process
May 7, 2020 | By: Armando Franco
Implementing continuous security and security as code is an ongoing journey. The risk and security landscape is ever changing, making it critical that you remain agile when it comes to adjusting policies and production processes to maintain—and improve—your organization’s productivity. Part of the modernization evolution is ensuring you incorporate everything at the forefront—i.e., developing with security and testing in mind. It’s challenging and takes a lot of strategic planning but can be the difference between a waterfall organization stuck in the past and a modern company with a multifunctional approach owning change.
So how do we implement continuous security and security as code in the production pipeline? The process follows a similar procedure as implementing infrastructure as code. While your continuous integration / continuous delivery (CI/CD) pipeline is meant to help you deploy faster releases, it doesn’t necessarily mean it’s made to keep your applications secure.
Incorporating security as code makes it possible to implement production like cybersecurity at lower environments and allows it to be tested in an automated fashion so potential security threats can be identified and corrected earlier in the development process. Besides reducing risk, the benefits are avoiding delays at the end of production, achieving better quality control of your code, and helping to keep your development and operations teams accountable.
The stages of CI/CD and where security fits in
Stage 1: Source code management and testing
The first phase, continuous integration, consists of source code management, when committed code is being checked into the feature branch and is tested with static analysis for security violations. During this phase, the opportunity is to integrate security analysis or a threat module to assess the code and run deeper tests to ensure the code is sound and verified. It’s also to ensure secrets are not being stored in source code. While often left out, you should test for third-party vulnerabilities and licensing issues, as well.
Stage 2: Continuous build and testing
Next, during the build stage, is where developers package and push artifacts to a code registry/repository to scan for vulnerabilities. This is also your chance to ensure your application has the latest patch level before deploying into production.
Stage 3: Continuous delivery and testing
The application is deployed to test servers, perhaps to a QA environment, where you’ll be able to perform continuous testing and dynamic scanning to find any new or missed vulnerabilities. But this is also an opportunity to take things further. You should continue testing by creating automated security attacks for penetration testing or API testing, ensuring your application—and even your infrastructure—cannot be hacked. Policies of whether the code should be accessed from external ports should be documented in pieces of code, as well.
Stage 4: Continuous deployment and testing
Finally, the tested application is deployed and released. At this time, any lingering bugs should have already been addressed and resolved.
Stage 5: Continuous monitoring and testing
Oftentimes, CI/CD pipelines “end” after deployment, but the very last step you need to incorporate is setting up a graceful failure or automatic error recovery, so if something within your application does fail, productivity doesn’t go down. It can be treated as a normal run-down failure and roll back to the previous version without impacting users.
You should also plan to hold a postmortem to discuss what went well, what failed and adjust accordingly or document to apply to your next deployment cycle.
Secure your pipeline with continuous security or risk it all
There are many security risks hidden within the automation and speed of this delivery process if continuous security is not incorporated—either security becomes a bottleneck in your process or is excluded altogether to prevent workflow interruptions. Injecting it into the delivery process helps visibility for all teams involved, as well as enhances what your CI/CD pipeline was meant to do in the first place—help you achieve faster, more efficient and higher quality application delivery, which ultimately translates to business value. In order to shift left, you need to reevaluate your CI/CD pipeline and implement security early in the software development life cycle.
Armando Franco is a cloud and DevOps architect for TEKsystems Global Services. He is an expert in DevOps practices to implement next-generation cloud computing solutions to build lasting organizational value.