Over the past 10 years, as more organizations have made the transition to DevOps, there has been a cultural shift in which security and development teams agree quality is a priority. Yet, even with a shared quality focus, Development, Security and Operation teams still find themselves at odds on the road to continuous delivery of secure software.
Some people claim developers don’t care about security. The reality is they want to write great code that’s secure code, but often they don’t have access to tools that fit with the way they work.
There’s also tension between different sets of expectations and performance metrics for different teams. Developers are graded on their ability to deliver features and functionality to market as quickly as possible, while security engineers focus on prevention and detection. Operations teams, meanwhile, focus on reliability, uptime and stability.
Development managers feel pressure from senior management to avoid project delays. At the same time, security managers aren’t rewarded for reducing risk and may be asked to turn a blind eye and give the application a temporary pass so the project can move forward.
Prioritizing delivery to customers over security creates real dangers for the business. Veracode has found that 63 percent of internally developed applications are out of compliance with the Open Web Application Security Project (OWASP)’s Top 10 standards when initially assessed for security. And, attackers increasingly target the application layer, with web application attacks now the most frequent pattern in confirmed breaches, according to the 2016 Verizon Data Breach Investigations Report.
Empowerment = Security
Regardless of where your team is in the DevOps journey, you’re likely aware that detecting and fixing quality issues as early in the software development life cycle (SDLC) as possible increases efficiency and reduces costs. According to the Puppet 2016 State of DevOps Report, “high-performing development teams spend 50 percet less time remediating security issues” when they address security throughout the SDLC, instead of “retrofitting security at the end.”
While you want to find and fix bugs early in the SDLC, early detection of coding flaws has the unintended consequence of distorting an application’s risk posture. Development is once again in the hot seat, despite trying to do the right thing and testing new versions of an application early in the life cycle.
There is a middle path that can allow development to deliver more secure code at DevOps speed, but it requires automating security into the SDLC and into a continuous integration or continuous deployment (CI/CD) pipeline. Integrating security into the pipeline ensures that security testing happens with every release, and avoids the problem of bolting on application security late in the process.
This method has the ability to scale easily as more applications are developed. The release engineer adds a step in the CI/CD build workflow for an application security scan from the master branch. The assessment can take place in parallel to the CI/CD workflow process and any security issues can be loaded automatically into the defect tracking system that development teams already are utilizing for functional testing. Security issues are prioritized and resourced just as any quality issue.
The best way to catch software defects quickly is to analyze code as close to the time that it was written as possible. Security assessment, such as functional testing, “follows the code” through the application life cycle. During the development phase, developers analyze code in the IDE and develop unit tests that will find issues relative to their individual code changes. At this phase, developers receive immediate feedback while coding a feature, allowing developers to remediate basic issues when they are least expensive to fix.
During the build and integration phases, when a development or feature branch is merged into the master branch, compilation and integration tests are executed automatically by the CI/CD workflow. Issues detected at this stage are visible to the larger development team. No developer wants to be the one who “breaks the build” or has a basic defect that should have been detected during development phase. The integration testing is critical because functional and security tests are able to detect issues resulting when data and control flows between components. Coverage of the application expands and developers still have the time to fix before code goes moves to the next phase.
Enter Infrastructure as Code
“Infrastructure as code” (IAC)—the concept of managing, provisioning and configuration of development, QA, pre-production and production environments in a repeatable automated methodology—provides consistency that previously was challenging when each system was provisioned and configured independently. Product teams using virtual machines (VMs) or containers are able to advantage of this model more easily.
Even for those product teams that cannot take advantage of IAC, teams can still automate the deployment and configuration of the application. This becomes particularly important during systems/pre-production testing, where finding issues takes longer to remediate and the complexity increases as the application integrates with other systems. At this point in the life cycle, system and pre-production tests are automated when possible, and QA engineers and user acceptance testers may run end-to-end tests. Running security assessments at this stage is just as important as functional tests. True, fixing issues at this stage will be more costly to fix than during the development phase. But by this point the developers have been incorporating quality throughout the process and the number of high-priority issues will be significantly reduced.
Empowering developers to find and fix quality issues earlier in the life cycle provides them with the knowledge and skill set to more efficiently fix defects where it is less expensive and disruptive to their coding.
About the Author / Janet Worthington
Janet Worthington is senior product manager at Veracode,  working on solutions to help developers and development teams smoothly incorporate security into the application development life cycle. Janet joined Veracode in 2012 as senior program manager, delivering Veracode’s secure development solutions to Fortune 100 companies. Prior to joining Veracode, she led software quality assurance test teams at a number of startup technology companies. Janet has over 19 years of experience in software product development and services. Connect with her on LinkedIn and Twitter.