CI/CD pipeline and security
What is CI/CD pipeline?
The practice of CI/CD resides at the heart of DevOps. It involves two concepts - continuous integration (CI) and continuous deployment (CD). Continuous Integration (CI) means creating and testing the software in an automated way. Static and dynamic testing tools could be used to drive this process in an agile way and speed up the entire release cycle. On the other hand, Continuous Deployment (CD) refers to an automated way of delivering the software. Therefore, the CI/CD pipeline automates your entire software delivery process through small iterations, thus reducing chances of human error.
Continuous Delivery and Deployment is an approach that combines the above discussed techniques to develop applications and deploy them in the most effective and ideal manner. This allows companies to remain competitive by introducing new code, acquiring quick feedback, and reducing the innovation cycle.
DevSecOps builds on these ideals and focuses on implementing security into this pipeline at the early stages (shift security left), to protect it and deliver secure software, without losing velocity. This will ultimately translate into good value for the business. It could be aggravating to discover security vulnerabilities in the finished product at the end of SDLC since it would lead to multiple costly iterations. Therefore, the earlier you detect vulnerabilities, the more quickly you can fix them.
Figure 1: A CI/CD Pipeline
The looming threat landscape
Different components like code repositories, image repositories, build servers, containers, other third party testing tools, etc make up a CI/CD pipeline. Hidden risks in the pipeline might act as a vector for major cyberattacks and hinder the speed of your software delivery process. There might be unencrypted connections between different CI/CD components or the developer might be using a vulnerable version of a certain component. There could be vulnerable open source code, configurations, code commits, Docker/container images etc. If you do not scan for these risks, your application will remain vulnerable and open a backdoor for malicious attackers. Given the wide range of different digital threats and the evolving threat landscape, security can no longer be just an afterthought.
Figure 2: The risks related to the CI/CD pipeline
To achieve an ideal security posture, it is important to incorporate certain security tools into the different stages of your existing CI/CD pipeline. In this blog post, we have covered the techniques to add security to the CI/CD pipeline.
How to add security to the CI/CD pipeline?
Figure 3: Common tools used in the CI/CD pipeline
When developers start creating code for their applications, they may include sensitive information such as access credentials, API tokens, SSH keys that are then commit-ed into their private (Gitlab) or public repositories (GitHub) for version control purposes. Pre-commit hooks tools, as Talisman, are an efficient way to scan both files names and content in order to catch secrets and ensure sensitive information does not leave the developers’ workstations. Talisman can be directly hooked into the repository and can be used as a first security component in a CI/CD pipeline.
In addition to using a pre-commit hooks tool, it is necessary to manage all secrets in a vault such as HashiCorp Vault allowing an access segregation between security and development. Secrets management admins (or Vault admins) usually do not have access to the code created by developers, and developers do not have access to secrets. Secrets management solutions like Vault make it easy to manage the secrets lifecycle, from creation to revocation, going through secure storage and audit changes.
Throughout the SDLC, developers rely on 3rd party frameworks and libraries, leveraging ready-to-use functions and features. Then comes the challenge of monitoring outdated or/and vulnerability components and ensuring those aren’t used or updated. Software composition analysis (SCA) tools such as Dependency-Check allow performing checks to identify the used libraries that are affected by a CVE. As a complement to SCA, a static analysis can be useful to weed out low-hanging fruits like SQL injections and Cross-Site Scripting in a white-box security approach, even before any deployment is made. Once an application is deployed, DAST tools such as ZAP will help picking out deployment specific issues, in a grey-box or black box security approach.
While dealing with SAST & DAST reported vulnerabilities may take time, applications could still be deployed in staging and production with an efficient DevSecOps runtime protection, to speed up the go-to-market - those reported vulnerabilities could be virtually patched while being corrected in the source code. Classical WAFs, handled by production teams, protect only the application’s run phase. To overcome this shortcoming of traditional WAFs, a newer, unified and end-to-end approach to application security is required. Using a cloud native solution in a staging environment can help developers describe their application context, and perform functional and security tests to ensure the application is working as expected and vulnerabilities are correctly hidden. The same solution could then be deployed into a production environment in the run phase, leveraging the same security policy, and providing in depth monitoring and logging of the accesses, attacks and additional security recommendations to be implemented. R&S®Trusted Application Factory is such a cloud native application protection solution that could be deployed from a CI tool as a freemium solution to accelerate applications’ go-lives, in the most secure way possible.
Whether that application is deployed as a standalone container or in a Kubernetes infrastructure, it will be leveraging a base image pulled from a container hub that may be backdoored or may contain malware that will be used for DoS or cryptomining. Trivy is an opensource vulnerability scanner identifying vulnerabilities or missing security patches in app containers and integrates with most CI solutions.
Last but not least, ensuring compliance standards for specific industries (Finance or Health for instance), or geographic regulatory guidelines are met, can be another challenge for developers. Inspec is a great opensource tool relying on a defined set of rules that will help developers turn compliance, security and other policy requirements into automated tests.
Centralizing all the results from the security tools used in the CI/CD pipeline is key. ArcherySec is an open source vulnerability management solution helping DevSecOps teams gain visibility over their security posture, by identifying and classifying reported vulnerabilities and taking necessary actions to mitigate them.