Anonymous, the famous hacker group, struck a big target in 2015: after gaining access to a web site supporting ISIS (both the site’s source and host), they were able to covertly transition key messaging of the group from statements of aggression to more peaceful messages.
Aside from the political implications of this attack, this story highlights a serious cyber security threat that many companies face: web sites, mobile applications, and basically every piece of code that is exposed to the world in any way—especially ones that use cloud backend services—must be secured against all possible hacking techniques, at all times. As more and more companies adopt DevOps tools and principals, security is becoming an increasingly massive problem.
The Security Piece of the DevOps Puzzle
DevOps has expanded: its principles now address the whole ecosystem of the application—from code coverage through functional and performance testing, all the way to production deployment and release. Rugged DevOps, or DevSecOps, involves key practices to help solve one of the biggest concerns for many software vendors: producing more secure software and supporting faster fixes for security problems as they are discovered.
In order to continuously maintain stable and secure software, security testing must be part of the continuous integration, delivery, and deployment pipelines. One of the ways to do this is to run security tests automatically as part of these pipelines. DevOps, who were likely not previously aware of this type of validation, now need to understand and execute these tests in their environments.
One of the ways to implement security as part of DevOps is to treat it as a feature. Just think about it: almost every application has a user story or a requirement for cloud deployment or installation packaging. Security review and validation can be included and developed as part of the release.
Another option is to think like a developer; understanding the unique challenges of securing the code earlier in the development process requires security professionals to actually know what will be developed. With this level of visibility, they have the ability to plan the validation, help with accommodating the code review, and make the required adjustments to the development process.
How It Affects the Day-to-Day Process
When you consider what security validation requires—and the peace-of-mind it offers by doing it at the outset rather than later—it will make it easier to take the required steps to implement this task inside the development process.
If you verify your application continuously, you can ensure that it is secure to upload every build that passes the release criteria. This change in process saves time at the end of the release (during which the security review is typically done). Furthermore, it addresses the need for code changes very late in the release.
To verify security as part of daily testing requires a clear description of the security requirements. It’s important to articulate expectations and goals, such as which security best practices or compliance standards to follow, before considering how to verify an application’s security status.
Finally, security testing, just like any application testing activities, requires standards, review, and status visibility. There are several tools that gather information about the application’s security and display it in a clear, understandable view. Choosing the right tool, that provides the right level of visibility, is crucial.
Security is one of the most important aspects of any application. Hackers have a wide selection of methods and tools to choose from when trying to breach the software’s access points. Organizations can’t afford for a breach to happen or a hole to be found before increasing the magnitude of an application’s security. Implementing security as part of the dev process is essential to reduce the application’s vulnerability to zero.