Why developers need security

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, to 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 a Backend Team Leader, the saying that everything is personal rings truer today than ever. I have understood the importance of instilling an overarching approach 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.

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

While it may seem far-fetched, this approach between developers can also do wonders for inter-departmental relationships, even the most significant and complicated relationship between developers and security professionals.

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

AppSec teams should prioritize, and not “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 first hurdle may be that the organization uses data and tools that are less than optimal for their AppSec program, and the processes are often misaligned with the frequency and number of development demands. As a result, many AppSec programs fail to identify critical assets and properly protect them leaving the organization exposed to data loss, financial penalties, and downtime (while developers take the heat). Teams that invest in shift-left approaches are not immune to this.

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

Automate, and take 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 write secure code. How do we do this in a constructive way? Easy, take the human out of the loop. Create a system that removes human interaction from the code review. No feelings are hurt and no conflict ensues if a security concern is identified in the code, the security professional should create a task, assign the corresponding developer, and you’re done. No verbal feedback and no walking over to the developers’ room to tell them all the things you don’t like about their code.

Establishing a clear communication process once a vulnerability is found and the scanners are done scanning is imperative. While 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.

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, developers shouldn’t entirely ignore security concerns and must remain vigilant that the code passes through the important security touchpoints.

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

And to end with some due 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 professionals 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….