Why developers dislike security—and what you can do about it

This post was written by Chris Romeo during his tenure at Security Journey. This article originally appeared on TechBeacon.com on May 18, 2021. You can access it here.

Developers dislike security but won’t always admit it. They dislike the security function because it doesn’t understand development and often tries to force a process and tool set on them.

The tension between devs and the security teams regarding the security of new features and bug fixes is called “the DevSec disconnect.” If you imagine a developer who is about to push a feature, you can almost read his thoughts: “Security is getting in the way and slowing us down. They have arbitrary requirements and can’t make up their minds. We need to push this feature to production.”

On the flip side, security says, “The developers are lazy and are not applying the guidance we provide via the process and the pipeline. Their code is insecure; our tools blow up when we scan the code. They can’t push this feature to production.” The DevSec disconnect is real, and it stems from a lack of understanding between the parties.

Empathy is the foundation of the answer to closing the DevSec disconnect. Empathy is psychological identification with another person or vicariously experiencing that person’s feelings, thoughts, or attitudes. When security professionals feel empathy for developers, they are able to understand the struggle necessary to implement security while still pushing features and bug fixes into production. With empathy, security teams truly experience developers’ frustrations, which leads to better working relationships.

Here are 10 frustrations that developers have with security, with a resolution and actions that security can take to counter each.

1. “Security doesn’t understand what I do.”

If you take your car for service, do you tell the mechanic how to fix it? It is frustrating for developers to be instructed by those that do not know how to do what they do. But coding skills are one of the 5 core skills every cybersecurity pro should possess. A security person who doesn’t invest the time to learn how to read and write code is saying, “I’m important enough to govern this process, but not concerned enough to understand the work you do.” That is consulting without expertise.

Resolution: Become a developer and learn how to code.

Action items:

1. Learn the primary base language your developers use. Your code review skills significantly increase when you build a foundational knowledge of at least one object-oriented language.
2. Understand and be able to explain the build pipeline from a developer perspective.
3. Explore any frameworks in use and understand how they work and add value.
4. Write and commit a small amount of code alongside the devs. Use the process that you have spelled out for security; you might be surprised by the amount of friction you encounter using that process.

2. “Nobody ever showed me how to do security.”

Your developers’ knowledge and experience with security may be lacking. Security expects developers to react and do the right thing, but they have no idea what the right thing is and nobody has taken the time to spell it out. If a security person tells a developer, “Stop coding SQL injections!” the developer is likely to think to herself, “What’s a SQL injection?” Developers are frustrated when you do not take the time to teach them the foundational pieces of security.

Resolution: Build a security coaching practice and education program.

Action items:

1. Define and document how to coach for security.
2. Empower your security team members and champions to perform coaching.
3. Roll out an education program that touches every adjacent product person.

3. “I don’t know why we put so much effort and time into security.”

Developers are compensated in most organizations for producing features and fixing bugs. The security team is always (rightfully) preaching the need and value of building secure things. But security fails when it doesn’t explain the value proposition and the return on investment that comes from shifting left, or moving security to the earliest stages of development.

Resolution: Start with the why and the security ROI.

Action items:

1. Launch a campaign to promote the three R’s: reputation, retention, and requirements. If the company's reputation for security is poor, it loses customers (retention). Customers levy specific security requirementsbased on regulations or their internal security culture.
2. Analyze the data and give developers objective metrics for security ROI. They can be motivated to change by metrics such as the percentage of flaws that require rework. That's because they want to build new things, not fix problems with something they made weeks or months ago.

4. “The security process is difficult or undefined.”

Without clear guidance and a framework, developers are unsure what the process looks like or what the requirements are for them and new-feature development.

Developers crave predictability of the surrounding process. Without that, they won't know how much time they will need to set aside for the security process when marching toward a Friday deadline.

Resolution: Use the secure development lifecycle (SDL) as guardrails.

Action items:

1. Lean into the SDL, and if you don’t have one, get one quick.
2. Give developers the freedom to be creative by sharing the SDL with them.
3. Define and communicate clear developer expectations regarding the SDL and other security processes.

5. “Security people change their minds all the time.”

Developers can have this perception if they see security telling two teams different things. From security's perspective, those different answers are entirely appropriate and accurate. But for the developers, the issue is trust.

Developers lose faith when advice isn't consistent, and a developer who loses confidence in security will stop bringing things to security’s attention.

Resolution: Fully explain answers and suggest getting a second opinion.

Action items:

1. When interacting with developers, never assume that you have been understood; perspectives can be too different. Question the level of understanding until satisfied that it is sufficient. Ask developers whether they agree with your conclusion, and discuss in more depth if they do not.
2. Ensure that your team is doling out the same guidance.
3. Provide a mechanism for developers to get a second opinion.

6. “I can’t please everyone.”

Developers are under pressure every day to fix bugs and deliver features. When their manager has not bought into the corporate requirements for security, they are pulled in two directions. To comply with what security has decreed, they must go against the immediate orders of their manager.

Resolution: Raise awareness about security resource needs.

Action items:

1. Gather buy-in for security resource allocation at all levels: front-line managers, directors, and executives.
2. Provide estimates for how much time the average security activity takes for completion.
3. Launch a campaign to make everyone aware of the need to communicate about security resources.

7. “Security is a silo and acts as a gatekeeper.”

DevOps promotes open communication among everyone on the team; siloed security operations are alien to developers, because they block flow and hamper communication, requiring more status meetings to stay in sync. Security also wants to make all the decisions. Gatekeepers are frustrating because their need to control the process slows down everything to a crawl.

Resolution: Partnership, not gatekeeping.

Action items:

1. Just let go. Build an automated process and rely upon it for success.
2. Perform a proper assessment of gatekeeping. Ask your developer audience if your process has any hint of gatekeeping.
3. Partner with your developers.

8. “Security gives us busy work.”

Developers need to see value in the activities that security asks them to perform.

When security requires a risk assessment for every new feature but never reviews the risk assessments, developers will be frustrated that you are wasting everyone’s time. If you are doing anything manually (except for threat modeling), you are wasting some time. It is frustrating for anyone to do busy work of any type.

Resolution: Optimize the process, and no busy work.

Action items:

1. Review all the artifacts from your process and collect feedback from developers and security about which ones maximize value.
2. Cancel any artifacts that are not useful in the improvement of security and privacy.

9. “The sky is always falling—we never celebrate success.”

By its very nature, security is always chasing the next vuln, problem, or bug, taking no time to celebrate or even pat anyone on the back. It is frustrating for developers to work in an environment where things seem to get worse every day.

Resolution: Celebrate security wins.

Action items:

1. Get a feel for the climate. Is the sky always falling for your developers, and is security the cause of this perception?
2. Celebrate security wins at different levels. E-mail and team chats can do a lot and cost almost zero. Other ideas are all-hands events and naming a security win of the month.

10. “Security tools are loud, obnoxious, and inaccurate.”

In security, we love our tools. We think they have nearly all the answers. But developers are frustrated when security tools generate thousands of entries and false positives.

Resolution: Tune the tools.

Action items:

1. Assess the current frustration level with your security tool suites among your developers.
2. Practice the least possible configuration mode with any new tools or tools with a terrible reputation.
3. Don’t be afraid to yank a tool out of the pipeline if it needs revamping.

Security culture and empathy are key

Don't try to solve all of these frustrations at once. Review the list, consider which of the items are most applicable to your organization, and then start making programmatic adjustments to improve your security culture.

Spend time getting to know your developers by practicing empathy. Walk a mile in your developers' shoes, and make the changes you need. You’ll have a company where developers and security work together, and when that happens, security culture starts to change.

Chris Romeo will be presenting on this topic at RSA Conference 2021.

Keep learning

• Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
• Understand the app sec tools landscape with TechBeacon's Guide to
• Application Security Tools 2021.
• Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
• Understand the five reasons why API security needs access management.
• Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
• Build a modern app sec foundation with TechBeacon's Guide.