The DevOps approach gives infosec groups and testers an opportunity to integrate security earlier in the software development and deployment process, as long as they're willing to accommodate the cultural changes that come with the territory. It's a critical part of software quality, according to the World Quality Report, and test automation.
Collaborative development
DevOps is an approach to software development that emphasizes collaboration between an organization's operations, development, testing, and support teams. The focus is on reducing time to market and improving agility through rapid development and rollouts.
Flickr is widely regarded as one of the first companies to have adopted the DevOps model, but many companies routinely push out double-digit software updates into production every day. Not all the deploys are major new features or security updates. Instead, they're often just incremental changes to code in response to configuration issues, user feedback, changing business needs, and a variety of other factors. The changes are built, tested, and pushed out to production as soon as they become available.
It's a process that involves automated testing of small pieces of software at the unit level and at the integration level, in a staging environment that's as close as possible to the production environment.
Shifting security to the left
At first glance, DevOps involves a culture of continuous software delivery and updates. For security organizations, this complicates the work of doing code analysis and other security routines on software, before it's deployed in production.
In reality, the DevOps delivery approach gives organizations an opportunity to reduce overall security risks in software, says Alan Shimel, an information security professional and editor-in-chief of DevOps.com, an organization that hosted a session on the intersection of security and DevOps at the recent RSA Conference in San Francisco.
"DevOps is a great opportunity to get security right," Shimel says. It offers security groups a real chance to introduce security earlier in the development cycle so they can address issues earlier.
"When we look at software development process we read it left to right like a book. It starts with planning, coding, testing, releasing, and then deployment and monitoring," Shimel said. Security typically makes an entrance toward the end of this process near the deployment phase and is typically bolted onto the code rather than an integral part of it from the outset.
With DevOps, everything can get shifted left. The concept of shift left simply means moving security tasks farther left in the development timeline, Shimel said. Injecting code analysis tools and automated penetrating tests earlier in the development process makes it possible for organizations to identity and eliminate security issues at every step of the development process. By the time the software gets to the staging and deployment stage, all the things that need to be tested would have been tested.
Automation can be a good friend
The staging environment in a DevOps model is usually a mirror image of the production environment where automated tests are run on the code to ensure it's error free. If the software passes these tests, it simply can get pushed out into production without any further security vetting.
More than the tools and actual processes, the biggest challenge with DevOps for security groups is cultural in nature, Shimel said. "My advice is not to be so quirky. Don't be so afraid of change, and at least give new ideas the benefit because you may be surprised."
To integrate security into the development cycle, the security group needs to be able to work with a cross functional team. It means having a seat at the table with planning, development, and operational teams.
According to Shimel, the high degree of automation in DevOps is often its most radical aspect as well for security practitioners. "But the fact is that if you set the parameters right and the controls right, by automating you will actually have better security," Shimel notes. "You have less human error, less drift," because everything is configured to specifications that have already been proven secure.
Changing cadence
Joshua Corman, chief technology officer of application security vendor Sonatype Inc,. said DevOps could be intimidating to security professionals who are used to a completely different rhythm and cadence. Typical security organizations, for example, might need four to five days to do a complete static and dynamic code analysis—maybe even longer for a full penetration test on code that needs to be deployed.
DevOps is the antithesis of that model. "These guys are reckless, going at 100 miles per hour." Worse, a lot of the automation and orchestration tools used in DevOps are still very nascent, at least from a security standpoint, he said.
The best tactic for infosec groups is to approach DevOps like the developers do. "The only way that security is going to scale is when you make the easy thing the safe thing," for developers to do, Corman said. Every developer wants to be on time and on budget, and the security group's role should be to try to enable that in a secure manner.
For instance, there's always a certain amount of unplanned and unscheduled work inherent in any software development project because of defective software components. Security groups can help address this issue by identifying and helping developers use safer components, Corman says. Numerous tools are available that help security groups identify vulnerabilities in popular software components and ensure a cleaner, safer supply chain for developers, he said.
Bridging the communication gap
Equally vital is the need for security practitioners to be able to bridge the communication gap that exists between the security function and the rest of the organization. Security is often viewed pejoratively because people don't understand it.
To succeed in a world that's moving to DevOps, security groups need to be able to explain their concerns in language and terms that are relevant to the operational and development teams, Corman says. For example, instead of talking about a breach or a vulnerability, it's better to talk about a security risk in terms of project delays and unplanned, unscheduled work. When speaking to operations teams, it's better to talk about availability and mean response time, rather than a security breach.
"Use the priorities that they care about and the words that they use. If you understand what they care about, you can help them be successful," Corman says.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
