Why Developers Need Security (...and Vice Versa!)

They say that everything is personal. Well, so is code development. Since childhood, I was surrounded by developers– my father was a developer, my uncle was a developer, and that was all I knew growing up. When people asked me what I wanted to do when I got older, the only answer was, well, become a developer. Code development was very different back then– we learned coding from a large, thick book. No open resources and no Youtube. I look back on those days with a smile. 

As the Backend Team Leader at Enso Security, the saying that everything is personal rings more true today than ever. I have understood the importance of instilling a process of transparency and open communication with my team and between the teammates themselves. This is how good code gets developed– code review, clear design and good communication. 

How, then, can we translate this process to one of the most significant professional relationships in an organization, between the developers and the security teams? My answer is simple– apply the same management approach described above to security.

Below is a review of the steps I believe are beneficial for keeping the peace between your developers and security teams, and allowing your organization to perform in the true meaning of the word agile - from the developer’s perspective, of course. 

Tell your AppSec team to prioritize, and not to “bother” developers with every.single.concern in their code. 

AppSec can be a losing battle (with no disrespect to my AppSec sisters and brothers). Developers will always produce more, and faster, than AppSec teams can handle. Therefore, it is crucial that security focuses only where it matters. AppSec teams must learn to prioritize and communicate those priorities to developers. 

The problem is that sometimes the data and tools used in AppSec are unfit, and the processes are often misaligned with the speed of development demands. As a result, many AppSec programs fail to properly identify critical assets and properly protect them - leaving the organization exposed to data loss, financial penalties, and downtime (and sometimes blaming developers on the way). Teams that invest in shift-left approaches are not immune to this. 

This is where Application Security Posture Management, or ASPM, is beneficial. An ASPM solution like Enso’s helps organizations by first mapping all web application assets across the entire development pipeline to create a comprehensive and unified inventory of all applications developed by the organization. On top of that, the platform analyzes the data and provides qualitative and real-time insights to allow AppSec teams to communicate data-driven decisions to developers, and therefore manage risk in an efficient, transparent and informed way.

For the sake of agility, and the developers’ sanity, we must prioritize vulnerabilities and fix what really matters. 

‍‍

Automate, and take the human interaction (and emotion) out of it. ‍

As developers, we have a responsibility to both the organization and our fellow developers and security colleagues to help each other write secure code. How do we do this in a constructive way? Easy, take the emotion out of it. Create an automated system that removes human interaction from the code review.  No feelings hurt and no conflict– if there is an identified security concern in the code, open up a task, assign the corresponding developer, and that’s it. No verbal feedback and no walking over to the developers’ room to tell them all the things you don’t like about their code. 

Automating the communication process once a vulnerability is found and the scanners are done scanning is imperative.  While all of the tools in an organization’s security tool arsenal (SAST, DAST and all the fun acronyms) are supposed to cover this process, there can always be gaps. We must turn this communication process into a systematic, robotic discipline, and in this case, pivot away from the personal. ‍

‍

Think security…. just a little ‍

My next statement is a bit of a ‘hot take’ for developers, but bear with me - the truth is, we can all think a little security. As part of the code review process, we should  be conscious of possible security concerns, especially when they may quickly turn into overarching organizational concerns - for example, in identity and access management features. As a baseline, we can adopt frameworks and coding practices that will make our software resilient to many attacks.  But when it comes to designing or implementing security sensitive functions, it requires the attention of security experts - the same way we need a professional product team to address business-specific requirements. 

Just to clarify - developers should not be expected to be security experts. Security teams must ensure that they are purchasing developer-friendly tools that integrate with rather than inhibit the developer workflow. That being said, we shouldn’t entirely ignore security concerns, and must remain vigilant that our code passes through the important security touchpoints.

Our main concern and responsibility as developers is agility and a fast development flow. Security must ensure that this workflow continues unobstructed. 

And to end with a little credit for my security colleagues and their difficult job: AppSec teams are charged with making sure software is safe. As the industry's productivity multiplies, AppSec experiences shortages in resources to cover the basics. The AppSec community developed useful methodologies and tools — but outnumbered 100 to 1 by developers, AppSec simply cannot cover it all.

To bridge this gap, developers and security must learn to prioritize and automate - together. And as developers, it won’t hurt to think just a little about security….

‍

About the author

Ariel Shadkhan is a Backend Team Leader at Enso Security, the first Application Security Posture Management (ASPM) tool used daily by AppSec teams to enforce, manage and scale a robust AppSec program, all without interfering with development.