Why DevOps Needs to Change Security
Where adopted, the DevOps methodology has made big changes in how applications are developed. Adding security into this methodology, however, is not something that has been at the forefront of the developer thought process. This can cause many gaps in deployed applications. 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 and skillsets and the shifting of operational practices. In a DevOps driven business, it’s the only way to fulfill a team’s mandate to protect the enterprise.
“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.
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.
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.
For more insight from security thought leaders, Cloud Native Security Live, 2020 Virtual Summit is your opportunity to learn from the experience and expertise of developers, DevOps pros and IT leaders who all have so much at stake in container technologies and DevSecOps. Hosted by Prisma, from Palo Alto Networks, in partnership with The New Stack, you can still virtually attend this event held Feb. 11, 2020, for a full day of discussions about cloud native security — brought to you online wherever you may be.
Image from Pixabay.