This post was originally published here by gregg rodriguez.
This is Part 1 of a two-part post on ensuring your applications are secure by adding continuous security to your CI/CD pipeline.
Today, more enterprises are looking to public cloud, or Infrastructure-as-a-Service (IaaS), to enable the speed and agility they need in their Continuous Integration/Continuous Delivery (CI/CD) pipeline to stay competitive.
For many use cases, IaaS has been the fastest route to cloud infrastructure, and often more reliable and cost-effective than building your own on-premise solution. Additionally, adopting cloud infrastructure complements the implementation of CI/CD technologies and practices enabling continuous integration of code being written more frequently and reliably.
In the old days you would deploy to a live environment and only then get feedback. Security teams didn’t get access to the infrastructure or application for testing until after things were fully integrated. In newer cloud computing environments, developers can deploy code much faster, which means testing and evaluation should be an iterative process that happens in multiple phases as versions progress through the pipeline.
While scale and speed enabled by cloud infrastructure are friends of CI/CD, they can often be the enemy of security if not handled correctly. The challenge is that within cloud environments there are so many more things in more places that need to be monitored and protected. Additionally, the rate of change, both for code and infrastructure, is orders of magnitude higher, which adds more layers complexity to maintaining security.
Adding Continuous Security to Your CI/CD Pipeline
The adoption of cloud infrastructure requires a new approach to testing and validation in the CI/CD pipeline, creating a pressing need for agile teams to work differently in order to move faster. That has given birth to the new DevOps model, which exists primarily to safely accelerate application teams by improving the flow between development (release frequency-driven) and operations (uptime-driven) teams.
This new approach to continuous security makes the process more like a regularly scheduled internal audit that’s an integral part of the CI/CD pipeline.
In this new model, the security team is responsible for infrastructure operational security, while the DevOps team is responsible for workload security. But the two teams no longer work “siloed.” Instead, they are merged into one team where the engineers work across the entire application lifecycle, from dev and test to deployment and operations, developing a range of skills not limited to a single function. and ultimately continue evolving along with cloud computing in order to maintain continuous security.
Though, as enterprise IT becomes more decentralized due to cloud adoption, security is also becoming decentralized and can now fall on everyone across a DevOps organization. And as the speed and pace of deployments increases, with deadlines becoming daily – security and compliance can still be seen as a roadblock to be overcome.
So what’s the solution? In order to avoid the nasty surprises that come from only scanning for vulnerabilities in production, you should ensure that your builds are clean and secure before they are deployed. You can accomplish this by implementing security scanning across your CI/CD pipeline!
4 Key Things Your Security Solution Should Deliver
To ensure only clean, secure builds are going to production, you have to approach DevOps organizations with a solution that enables adding continuous security to your CI/CD pipeline by meeting the following requirements:
1) No interruption for clean builds. The build fails only when something is wrong, otherwise the CI/CD process continues without human intervention.
2) Minimal time tax on CI/CD process. CI/CD is what gives developers feedback on the quality of their work, and fast feedback is essential. For a rapidly iterating environment, a security assessment process that takes more than ten minutes to perform is a hard sell.
3) Uses existing messaging channels for alerts on build security quality issues. For some, that may mean an email is sent or a Jira issue is created. For others, a messaging solution like Slack is the ideal channel for these notifications.
4) Provides meaningful information to the developer through preferred channels, not just, “Hey, your build failed because ‘Computer says no…’ ” The more detailed the information, the faster the developer can likely diagnose the problem and get the build back on track.
Photo:AET Europe
