Skip to main content

Cracking the DevSec disconnect

laptop keyboard lit by screen
(Image credit: Unsplash)

I’m a believer that a healthy amount of tension between teams is a good thing. It can foster new approaches, friendly competition and ultimately allow new ways of thinking to emerge. If we all thought the same, the world would be boring – and much less innovative. But over the last few months, a few headlines have caught my eye that have made me think we could be doing more to bridge the gap between developers and security teams. 

Though it’s been discussed for years, the apparent DevSec disconnect can be a recurring hurdle. For example, debates arose at RSAC on how to resolve the disconnect between security and development teams. To make some movement in the right direction, it is critical that the topic is openly discussed and that all work toward a better solution, but we do also need to start taking action. At the end of the day, both teams are working towards common goals: advancing technology and addressing security risks. In my experience, you can't have one without the other – they are both critical. 

Not enough communication 

What seems like a "simple" process of embedding security at the beginning of a project is quite the opposite. Developers are often wary of security mandates and requirements that slow them down. On the other hand, security teams are frustrated that developers do not follow protocol. The result is that both sides shut down communications, and bugs get out the door. 

ESG's Modern Application Development Security report found that nearly half of developers (48 percent) regularly push vulnerable code into production. It is often a "chicken with its head cut off" situation with developers racing to patch them. And of course, we know that addressing bugs in production is costly. Nearly 20 years ago, I worked to help build our organization’s first comprehensive software security program at GE, and back then it was en vogue to cite the NIST findings that it cost 60x more to fix a bug once it reached in production (or was it 100x?). Now, it feels tiresome to even bring up these stats. But it’s been a constant for a reason – that’s because it’s true. 

Working towards a common goal 

Rather than seeing security as a red tape measure, requirements need to be positioned as an essential part of the development process to avoid roadblocks in a project. While developers know this deep down, they are going at a million miles per hour trying to hit velocity targets and ship on time. Same for security teams, who are still drowning in a backlog of alerts. If security and developers can be in lockstep at the start of the project, speaking the same language, it will help them better understand threats and overcome them.

One way to achieve this is by ensuring that both security and developer teams have KPIs they both measure and view as a team. For example, one metric could be the amount of security defects found in a solution vs. the completion of secure code training. 

Speaking the same language 

As I mentioned earlier, speaking the same language and understanding the developer/security space is crucial. Both teams have an even playing field of knowing code. That's how they can get on the same page. Security teams can better instruct and advise developers in a language they understand by looking at the code, not just giving them a listicle of security requirements that might not apply. Going through a repository of code is never "fun", but time must be made when it comes to the security of the product. And developers must be open to dialogue if security issues are found. 

Let’s take the development process of building a car as an example. If there is a security flaw at the design conception stage that goes unnoticed throughout production, then the final product can be dangerous – so much so that there could be a potential loss of life. Therefore, from start to finish, car brands complete numerous tests and checks to confirm every part of development is safe and secure. This is to ensure nothing gets through the net. The same approach needs to be taken when it comes to DevSec.

Working collaboratively 

To establish a greater sense of collaboration and understanding with one another, I would encourage teams to host internal bug bounty competitions or security-focused Hackathons. This friendly competition will foster a sense of community, and both developers and security teams can try to identify the vulnerabilities of the project at hand. While big-name companies like Microsoft and Twitter ask outsiders to spot flaws, internal bug bounty programs are cost-effective. For example, think about creating a leader board of individuals who spot the most risks.

No one wants security to be an afterthought, but it often falls by the wayside in the race to innovate. We've seen time and time again that a lack of security early on can have detrimental impacts on the final product. The greatest innovation can hit a snag with a security flaw. To avoid this pitfall, better collaboration requires communication and fostering of healthy tension. Together, teams can build more secure products for all– a win-win.

Grady Summers, Executive Vice President of Product, SailPoint

Grady Summers serves as the Executive Vice President of Product at SailPoint.