Organizations carrying out digital transformation initiatives put significant emphasis on speed and efficiency – and with good reason. They want to get things done fast: create prototypes in days, deliver new versions in weeks and conduct revisions constantly, quickly, with the push of a button. They also want everything done correctly: completing and documenting all code fixes, moving the build along prescribed tracks, and monitoring the work of everyone involved in the process.
For the most part, organizations have succeeded. By creating DevOps cultures, implementing Continuous Delivery processes and migrating to new, more flexible development platforms, they have slashed deployment times and raised the bar on quality.
But how securely are new apps moving through these new, fast and efficient pipelines? In 90 percent of our engagements, we see a lack of alignment between security and DevOps. Security is on digital transformation agendas, but it is not taking the priority position it should in today’s DevOps processes.
What is happening? Why is it happening? What kind of impact can a lack of attention to security in DevOps create? And what can be done to push security higher on priority lists?
How Security Should Work
To understand what is not being done on the security side, it is instructive to look at how a fully functioning security model works in an agile pipeline. Looking at a well-constructed pipeline, you will see security checkpoints at each of the major steps: version control, repository, scheduling and deployment. You will see a vast array of security modules governing issues such as identity and access management, encryption, vulnerability management, logging and monitoring, infrastructure protection and automated security testing.
For example, when a developer pushes an app past version control, the CI server will contain a stack of tools that perform security infrastructure tests, security unit testing, static applications security testing (SAST) and third-party validation testing. Moving past the deploy server, cloud environments will have tools that perform image scanning to make sure the images have not changed since they went through the automated deployment. They will also have dynamic application security testing (DAST) detecting conditions that indicate a security vulnerability.
In a true security-equipped pipeline, developers are specifically trained in secure coding, so they are expert at the challenges and solutions. Also, threat modeling is done at the design stage to determine if there are potential security issues in the application design itself. Finally, the organization determines, early in the process, who has access to what from an identity and access management perspective.
Where Organizations Fall Short
Here are the areas where organizations fall short. There are a number of reasons, but they all come down to cultural issues.
When we walk into an organization, it is as if there is a wall between the Security and DevOps sides of the house or in more traditional environments a wall between Development Infrastructure and Security. Security specialists rarely come from a development perspective but Security leaders know they need to be involved. Development is less than welcoming because they’re afraid that adding more security checkpoints will cause delays as it has in the past. While DevOps focuses on building collaboration and empathy between Development and Operational silos, it also should be a natural inclination for DevOps to include Security in their thinking. But they are not because of old cultural thinking.
At this point development is shooting itself in the foot because security flaws will show up eventually, and it will cost more time and money to fix down the line. If security is not built in early, it takes a lot more work to undo the problem and make app security compliant, than it would have to implement security upfront.
The Three Steps to Aligning Security and DevOps:
- Standardize on a Pipeline
- Do Not Rejigger the Organization – Re-Allocate Tasks
- Add New Tools
Standardize on a delivery pipeline toolset and bring security in to automate all the different security pieces within it. Identify specific automated places where security can do its check. Once one facet finishes, it moves on to the next portion of the deployment. Often, we see that organizations do not standardize their deployment pipeline and therefore are putting security into the position of maintaining the integrity of many different types of pipelines. Security should become a service provider and treat development as a client. Its mission should be to create a more secure pipeline to help the DevOps team move faster. Development needs to be a source of consistency and security needs to be valued as a point of quality.
You do not need to replace or reassign people to implement a greater focus on security. Repurposing people’s existing tasks is all you need to do. For example, people who are normally doing just the penetration test of an application might take on additional roles for static app security testing or dynamic applications security testing. When an app is finally released in a waterfall scenario, it gets pen tested. By that time, potentially thousands of lines of code have been written. In a more agile system, those security personnel get the opportunity to shift left in the development lifecycle. Put mechanisms into place to make lighter controls to ensure problems will not exist when code gets released into production. It is like using anti-aircraft guns instead of cannons. Rather than having one big cannon trying to hit a target, you take more shots at securing the app earlier by using more organizational artillery.
A lot of organizations do not take on app security. They hope developers write code safely and do pen testing; this is not application security . There are more tools to leverage now, such as SAST, DAST, IAST and RASP and third-party versioning tools and pre-IDE code checkers. These tools have matured as the space has become bigger. Larger organizations are using them, but they should be employed more widely to help DevOps avoid unnecessary delays in the workflow.
Everybody wants pipelines to move quickly and efficiently, sometimes this happens at the cost of security but it doesn’t have to. Implementing security measures earlier in the process does impose more controls, but these controls are mostly automated. Therefore, security checks increase but are earlier in the pipeline and process making resolution clearer and quicker. Organizations need to open up to the benefits they can achieve by shifting security functions left along the pipeline. These moves can save organizations time and trouble in the long run, helping them achieve their original business goals.