Cohesion Between Development and Security Teams

For a technical manager, fostering an open culture of smooth communication between cybersecurity and programmers can be an uphill battle. Devs can feel frustrated by onerous security requirements, and security pros can get annoyed when devs repeatedly cut corners. So how can management break this cycle and bring harmony, so security and development work as a team instead of at each other’s throats?

No need to fret; we’ve used our extensive cybersecurity management experience to distill the best advice for managers who are stuck at the nexus between cybersecurity teams and developers. If you’ve felt this frustration, this article is for you.

We should start with the most obvious question: Why is it so hard for Cybersecurity Teams to communicate with developers and vice versa?

Let’s look at a simple code sample in Python that should be meaningful to both developers and security pros but in very different ways. Don’t let yourself get intimidated if you aren’t a coder; give it a brief look over, and you should get an idea of what’s going on, at least enough to understand what we’ll say about it later.

import SQL 
sql.connect(database='localhost') 
# Get name from command line input 
name = input() 
# Get the phone number of the name supplied by command line input 
phone_number = sql.query('SELECT phone FROM people WHERE name=$$', name) 

Not too scary, right? A security engineer will immediately fix their gaze on the double dollar sign near the end of the last line and understand this to be an instance of a ‘parameterized query.’ But to a developer, it might not be clear why we have to use the dollar signs instead of just formatting the name variable right into the string. Of course, this would lead to a SQL injection vulnerability, but this lack of clarity is precisely what causes endless bickering between teams.

In the code sample above, the disagreement would arise over philosophy. A software engineer thinks of code as something that expresses an idea and communicates meaning to other developers. On the other hand, security engineers think of code as something that communicates concrete actions to computers. Both of these views are correct, but which one takes priority is contingent on perspective. As a manager, you must be able to hold both of these perspectives simultaneously to balance the expressive needs of your developers with the pragmatic concerns of the security team.

Another common frustration that arises between devs and security teams is when security constantly asks for minor revisions and additions to handle obscure edge cases. These tiny defenses litter codebases and configurations. It’s easy to forget what they do and laborious to document. What is the solution?

Like with our code posted before, we’ve uncovered a problem where security devs make code harder to understand. The solution is for security to investigate and provide solutions that offer these security mechanisms built-in, by default, or implicitly. So now developers can enjoy security features without even knowing they’re using them. Using an ORM such as SQLAlchemy, for example, would make an application immune to SQLi while also making the code even more straightforward for developers. In other words, a win-win for both security and developers. Of course, guiding the security team to find solutions that solve the problem while making life easier for developers is the challenge you’ll have to face daily as a manager or team lead. But it’s almost always possible.

But what if you can’t manage all of this coordination by yourself? Is there a way you can build this relationship into the team itself? There absolutely is a role designed precisely for this purpose - The Security Developer!

Wait, hire a what exactly? A security developer is someone with a strong software engineer background who specializes in application security. Their job is to help convert the vulnerabilities reported by the security team into patches written by the development team (or, as is often the case, deployed by the DevOps team!). Thus, they spend most of their time documenting issues, creating proof of concepts, and writing simple example patches to help the dev team understand what’s going on so they can write an effective fix. To hire one, you can use an already existing candidate finder service like Hire a Sec Dev exist for the sole purpose of making the hunt for sec devs easy; interviewing and verifying qualifications is still an uphill battle. So let’s make a simplified list of the traits you should look for in a Security Developer.

• Experience in the specific tech stack used at your company (programming languages, frameworks, operating systems, etc.)
• Years of experience as a developer and any background in security (even as a passion hobby)
• Love documentation. The more they like documenting things, the better since this is what they’ll spend most of their time doing.

Interview questions should involve implementing patches for common security issues. You can present them with code in a language they profess to know already and ask - how would you make this vulnerable code better?

Then watch and see if they can do so without making the code a complicated mess. This is a security developer, after all. You’re bringing them in because they can make solutions that are easier for devs to digest.

Okay, so now you’ve hired a security developer to bridge the gap or decided that you or someone on your team can do the equivalent - now what?

How to explain Security issues to Developers?

For developers, security can feel like an oppressive black hole. The most critical step towards remediating this disparity is the one explained above, where you diligently use tools and apply solutions that are secure by default, thus requiring less work for developers instead of more. But what about situations where a vulnerability absolutely must be explained in detail to a developer without a security background?

In that case, you’ll save yourself a headache by applying the following report formula and using it diligently:

• Title - Type of vulnerability and application it affects
• Impact - Show how the bug could be used to exploit or harm systems
• Explanation - What is wrong with the code that causes this to happen
• Remediation - How could the code be changed so it wouldn’t be vulnerable in this way?

That’s all! Be clear, not curt, when applying this formula to reports directed at devs. Use as many examples as possible to show instead of tell. Sometimes, complicated concepts will need to be communicated. It’s okay to link to external docs or explanations or invite additional questions if anyone’s confused.

With these tactics, you’ll likely have gotten pretty far in easing communication between the two sides. Of course, your security developer should also be used to train your developers in security issues and implement aggressive regression tests, but these are things a good sec dev will likely recommend to you on their own.

We hope this has been helpful to you. While we’ve thoroughly recommended sec devs, don’t feel pressured to hire someone if you don’t have the means - there is nothing wrong with allocating someone from your current team to fulfill this role on an as-needed basis. Worst case scenario, you’ll have to implement these strategies yourself. After all, as managers, we often must wear far too many hats. It’s just part of the job.