Success of a CI/CD (Continuous Integration and Continuous Delivery) process in an enterprise environment relies heavily on teams supporting the development process. A particularly important supporting team is application security.
Throughout my interactions, I have realized there are common misconceptions about adopting CI/CD, and the resulting changes to the supporting processes, resulting in confusion across teams. It’s important to remember that most of the folks on supporting teams are not developers and have no formal experience with CI/CD.
Since I find that I frequently end up elaborating on these to get everybody on the same page about the process, I thought it would be useful to others if I wrote about them here. Below you’ll find an explanation of the three most common misconceptions about CI/CD and how to correct them.
Misconception #1: “In this kind of process, there is no regular planning meeting or project start.”
This is probably the single biggest myth of CI/CD. CI/CD, specifically in an enterprise environment, needs a significant amount of planning for each feature/epic that is being worked on. These planning sessions should result in a clear write-up of each feature in the form of user stories and acceptance criteria. This is where supporting teams, like the security team, need to be involved first. In fact, unlike waterfall, where it is easy to involve the security team in later stages, without early involvement in CI/CD, the process is doomed to fail. The key difference is that planning happens frequently and in a more rapid form with significant allowance for course corrections.
CI/CD is not chaos! There is planning involved.
Misconception #2: “I was told they use CI/CD. I know what it means!”
CI/CD is not the name of a process. It does NOT mean the same thing everywhere. Continuous Integration is completely separate from Continuous Delivery.
CI focuses on supporting rapid and automated feedback on the correctness of your application every time there is a change to the code. Code branches are merged in and tested frequently without the need to wait for a full completion of the feature.
CD builds upon CI concepts by providing fast, automated feedback on the production readiness of the application every time there is a change in code, infrastructure, or configuration.
There are also significant differences concerning the processes, cycles, frequency of releases, and so on. To support CI/CD, you first need to ask detailed questions about each of their approaches.
Misconception #3: “They follow CI/CD, so they must have daily releases.”
CI/CD doesn’t necessarily mean that every “green” build is deployed to production. It just means that the builds are always deployment ready. In fact, there are various techniques used to only control releases of new features when they are ready, such as feature flags.
Feature flags disable the features of an application that have been coded, but are not ready for mass consumption as determined by product management.
Ehsan Foroughi is the Vice President of SD Elements at Security Compass.
About Security Compass
Security Compass, a leading provider of cybersecurity solutions, enables organizations to shift left and build secure applications by design, integrated directly with existing DevSecOps tools and workflows. Its flagship product, SD Elements, allows organizations to balance the need to accelerate software time-to-market while managing risk by automating significant portions of proactive manual processes for security and compliance. SD Elements is the world’s first Balanced Development Automation platform. Security Compass is the trusted solution provider to leading financial and technology organizations, the U.S. Department of Defense, government agencies, and renowned global brands across multiple industries. The company is headquartered in Toronto, with offices in the U.S. and India. For more information, please visit https://www.securitycompass.com/