DevSecOps Will Ensure That Time-to-Market and Security Don’t Clash
According to a recent survey by Veracode, 52% of developers worry that application security will delay development and threaten deadlines. This is huge percentage, especially considering how crucial finding, fixing and preventing security vulnerabilities is to any development effort.
Any way you look at it, ensuring that quality code is also secure is complex. Traditionally, surfacing security vulnerabilities during design, development, deployment, upgrade, or maintenance were mitigated via:
- Design review – involves creating a threat model of the application, usually together with a spec or design document, even before the code is created.
- Tooling – using automated tools can lower human overhead, but you need to beware of false positives.
- Blackbox audit – involves security testing through another application
- Whitebox review – manual review of source code by a qualified engineer
Each of these techniques has its advantages, and each involves varying levels of time, effort, and cost – especially time. It’s exactly these types of before-the-fact or after-the-fact security reviews that developers fear – especially when time to market can make or break a project.
That’s Why They Invented DevSecOps
When it became clear that a streamlined yet secure build and ship process was a must have – AppSec and/or InfoSec teams began taking a hard look at how and when security enters the development process. The idea is to integrate security measures at numerous points in the DevOps workflow, but to do so in a way that is as transparent as possible to developers. This keeps DevOps teamwork, agility, and speed intact – while still ensuring application security throughout the entire lifecycle, from production to deployment.
We, at Aqua Security, recently published a survey analyzing the state of container security in the enterprise, 13% of responders reported that DevSecOps own container security in their organizations. This number grows to 28% when asked who should own the responsibility of container security moving forward, showing the expected growth of DevSecOps.
Transforming to a DevSecOps model isn’t simple, though. First off, it requires a change in the way your organization works and thinks. Namely, DevSecOps requires:
- Increased focus on customers – app security experts aren’t necessarily used to thinking about customers. Rather, they’re rightfully used to seeking vulnerabilities and mitigating threats. With the advent of DevSecOps, AppSec needs to adapt security programs and practices to client needs and business demands.
- Scaling toward innovation – In the context of DevSecOps, application security isn’t a gatekeeper. It’s an innovator – a partner that needs to keep pace with business demands and DevOps methods. To scale accordingly, application security may have to streamline processes and adopt automated tools to lower overhead.
- Creating objective criteria – To ensure the fast security decision-making that facilitates rapid time to market, application security needs to create objective security criteria, then adopt the tools to measure them.
- Working proactively – With the goal of identifying potential attack targets before they become actual targets, application security should proactively hunt, surface, test, and remediate. This not only ensures that the business impact of weaknesses discovered is minimal, it also helps inject security into core business processes.
- Continuously detect and respond – In the DevSecOps model, application security needs to constantly detect, compare, correlate, and respond to threats. Moreover, detection models need to channel information to internal teams for more effective trans-enterprise responses based on real-world business goals.
Different Approaches to DevSecOps
The best approach to implement DevSecOps into your organization depends on a mix of organizational culture, tools, and goals. Some of the primary avenues organizations are taking include:
- Creating a bilateral task force – Even as you’re working to facilitate better cultural and professional integration, you can still get down to actual work. A joint DevOps/AppSec task force can start addressing pressing matters right away, or tackle more basic DevSecOps issues like defining a joint set of measurements that facilitate continuous collaboration.
- Training DevOps in security – Understanding comes from both sides. To help DevOps team members better understand their new security colleagues, encourage them to learn more about security. From practices to jargon – there is no shortage of online resources or conferences that can promote DevSecOps coexistence.
- Add security to your DevOps mix – Security thinking is very different to DevOps thinking. To jump-start what will hopefully become a smooth-running team effort, add security staff to your DevOps team. By breaking down the internal cultural barriers, you can smooth and expedite the integration of these two teams into a cohesive DevSecOps group.
The Bottom Line
By adopting the DevSecOps model, those 52% of worried developers can rest easy. Finding, fixing and preventing security vulnerabilities - ensuring application security throughout the entire lifecycle, from production to deployment – is possible without degrading productivity or time to market.