As a kid, I often traveled by train in India. I always wondered what would happen if I pulled the chain under the sign that read, “To Stop Train, Pull Chain.” My parents warned me that it would cost them a fortune to pay the fine and that I’d be taken away by the police. Even though it scared me as a child, I was still tempted by the thrill of pulling that chain.
Fast forward 25 years, and I find myself pushing my clients to pull a similar, metaphorical chain. The chain in this case exists in their fast-tracked continuous integration/continuous delivery (CI/CD) pipeline where the procedural train moves at lightning speed.
Before digging into why pulling the proverbial CI/CD pipeline chain is important, let’s first examine some key software security activities. We’ll explore activities that take place in-line with the pipeline, in addition to those performed out-of-band.
What’s the difference between in-line and out-of-band activities, you may ask? Activities that can be completely automated and run in a CI/CD pipeline without any human intervention are categorized as in-line activities. Examples include SAST, DAST, and open source management.
Most in-line activities can also be performed out-of-band. However, out-of-band activities can’t be performed inline. As an example, there is currently no way to automate architecture risk analysis or manual code review.
The primary goal when breaking the build in the CI/CD DevOps life cycle is to treat security issues with the same level of importance as quality and business requirements. If quality or security tests fail, the continuous integration server breaks the build.
When the build breaks, the CI/CD pipeline also breaks. Based on the reason for the broken build, appropriate activities such as architecture risk analysis (ARA), threat modeling, or a manual code review are triggered.
This eBook provides actionable insight into: