It’s a tale as old as time: developers want to ship an app but are lambasted with security requests, and security teams want to secure an app but are brought in too late to do their job without knocking some heads in the process. The ensuing result is usually insecure code and frustrated teams.
The time is ripe for rethinking how developers and security teams work together. It’s no longer kosher to have two integral teams at odds with each other in a time when all eyes are on speed and safety. Collaboration is key, and to get to a place where seamless collaboration happens, it’s important to understand and overcome the challenges faced on both sides.
Let’s start with the obvious: Who owns application security? Developers will tell you they’ve gone to great pains to ensure every line of code is as secure as they need it to be. Security teams will tell you they haven’t gone far enough. This clash of opinions stems from a mutual misunderstanding of the other’s function. We commonly refer to this as the DevSec Disconnect. Giving problems a catchy name is great and all, but with teams operating in such a way, how do we go about bridging the gap? We’ll touch a bit on this later, but communication and collaboration built into the development process is key.
Zooming into the misunderstanding on both sides, we can see exactly how it is such a source of frustration. No one team can have full oversight if developers lack the time and technology to close security gaps; while security teams are notoriously understaffed and tend to lack the full development cycle view.
Human error is still the biggest threat to application security, and 90% of cyberattacks are aimed at software. Faced with this status quo, you would think that teams would share knowledge and talk to each other. But that’s not necessarily happening across the board. DevSecOps technologies have yet to reach proper market adoption levels and organisational inertia is one of the main obstacles to DecSecOps implementation.
A lack of visibility also challenges the role of analytics and measurement. Security tools generate reports and tasks to get software up to scratch, but with a cohesion gap, how does anyone make sense of the data, and who is accountable for it?
Culturally, some ingrained attitudes and behaviours challenge the success of any DevSecOps efforts. Security teams think developers don’t care about security, developers think security people are naysayers and give inconsistent advice. Each party has their manager to please, their own set of metrics that they’re measured against, and a priority list as long as their arms already.
Both teams operate at different levels, follow different processes and crucially, use different tools. Developers can’t get around the security tool complexity, and security teams have no control over the CI pipeline to best implement findings.
We also see different meanings and weighting of security risks between developers and security teams. What’s an absolute necessity to one might be seen as a nice-to-have to the other. This leads to a mismatch in the prioritisation of risks and disagreements about where to focus efforts.
There is a silver lining and a caution. GitHub’s 2021 Global DevSecOps Survey found some good news and some not so good news.
The Developer/Security relationship has come on leaps and bounds, but there’s still a long way to go.
Shifting security left has been at the forefront of every software company’s plans for the last few years. There is an industry-wide appreciation for the need to get security involved at all levels of the SDLC, with no exceptions.
But goodwill only gets DevSecOps so far. According to a 2019 DORA report, only 31% of the top organisations doing DevSecOps properly have been able to automate security within their environment, and 70% of organisations lack adequate working knowledge of DevSecOps practices. Without investing time to instil organisational-level understanding and best practices, and money into the tools to make light work of it, DevSecOps maturity levels will stagnate.
Imagine a world where high-performing teams spot vulnerabilities early and eliminate false positives. A universe in which developers become security-aware, and security teams reduce real risks early in the life cycle. When collaboration starts, development and security teams begin to confidently ship safe software faster.
DevSecOps automation and orchestration platforms like Uleska can help to improve collaboration between developer and security teams by streamlining testing and correlating results. They can fundamentally change the way development and security teams work and improve the organisation’s DevSecOps maturity.
To learn more about the challenges facing DevSecOps today, check out our in-depth guide, and to discover more about overcoming these collaboration challenges by automating DevSecOps, let’s talk about Uleska.
You may unsubscribe at any time using the unsubscribe link in the newsletter.