Where adopted, the DevOps methodology has made big changes in how applications are developed. Adding security into this methodology, however, has not been at the forefront of the developer thought process. This can cause many gaps in deployed applications. DevOps needs to change security. Teams can easily gain added visibility with the introduction of security during this build time while adding a collaboration point.
But what are the required changes, and what will be the impacts to security architecture and operations? What needs to stay the same and what needs to change?
Security at Speed
Even with manual approval points built into the workflow, traditional security operating models are going to present a bottleneck. To be effective, security teams need to embrace and integrate with the DevOps model to deliver testing and controls as part of the pipeline.
This will require the adoption of some new tools, the shifting of operational practices – and some new skills. In a DevOps-driven business, it’s the only way to fulfill a team's mandate to protect the enterprise.
Shift Left
“Shifting security left” speaks to both definition and explanation. At the core, it means to insert security considerations earlier in the software delivery lifecycle. This makes sense because some security weaknesses are easier to detect – and much cheaper to remediate – during the construction phase of application development than after the software has been deployed.
What this can’t mean, however, is the wholesale transfer of responsibility for application and runtime security to a development team. Security and development teams need to collaborate to identify threats and controls earlier and to insert security testing into the software delivery workflow.
The good news is that, although the specific tools a dev team might need to automate security testing might not be in place, they are available.
Threat Analysis
Finally, developers are taking more responsibility for the runtime stack where their code will execute by using things like infrastructure-as-code to define an entire running application environment, or with Dockerfiles to define their application containers. In turn, security teams need to understand the possible threats within these evolving development environments and provide tools that development teams can integrate at the earliest stages of application coding. This will allow both teams to recognize insecure configurations so they can be fixed even before the first code commit.
Embracing DevSecOps
As DevOps-inspired software delivery becomes more and more prevalent, the other parts of IT – security in particular – will need to adapt to faster development cycles and new attack vectors within a highly automated software delivery pipeline. This in addition to implementing security best practices and keeping up with the constantly changing threats and compromise techniques. It’s safe to say the only risk that’s shrinking is the risk of having nothing to do.
To learn more about bridging the divide between security and DevOps teams, you can watch our Cloud Native Live virtual summit on-demand.
This post originally appeared on The New Stack.