The Dept. of Know Live!: Ellen Körbes on how security should approach the developer experience
It’s no secret that the relationship between security and development is often fraught with friction. Developers face pressure to ship code quickly, and it can be frustrating when a security requirement stops a project in its tracks. And like Omar discussed in the third installment of The Dept. of Know Live!, security teams often implement new programs without considering how it will impact the development process.
Last week, I joined the series to explore the ins and outs of the relationship between security and development. Kelly Shortridge, Bea Hughes, and I chatted about how security falls short of developer expectations, and what doing security with developers in mind really looks like.
Watch the conversation here, and catch up on my top takeaways below.
1. Be curious about developer priorities
Security teams should approach their relationship with development with a healthy dose of curiosity. If you’re finding that developers are violating certain policies, it’s important to consider why that is happening. If it’s a pattern, it’s probably because there’s something that’s interfering with their workflows. Security teams need to think about the developers they’re trying to have an impact on and make an effort to understand what their priorities are. Give developers something that aligns with those priorities instead of expecting them to change their workflows and priorities to match security’s.
2. Think of every context switch as expensive
One metric that security teams should carefully consider when implementing new security requirements is the amount of context switching that developers will have to undergo. Developers today are responsible for such a high amount of code, and that amount is only going to continue growing. Because of this, it’s critical that distractions are eliminated. Remember that every context switch is expensive, and the ideal number of context switches is zero. We should reduce the number of instances in which a developer needs to turn their attention away from their code to a security requirement, or from their development environment to a security tool. Don’t make developers switch contexts unless it’s really important, and treat every context switch with extreme respect.
3. Be open to the idea of security that “goes away”
Reducing the amount of context switching developers need to go through means being open to the idea of letting infrastructure fade into the background. A development environment is a live thing, so we need security tools that are integrated in some way, and that monitor code as it’s being written or development environments as they’re changing. Automate wherever it’s possible. Ultimately, developers want security to go away, and I understand how hard that is for security practitioners to hear. The gut reaction will be to think, “so my job doesn’t matter?” But it’s important to remember that becoming almost invisible actually requires deep empathy and understanding for what the human on the other side is trying to achieve. It’s similar to the idea that when your body is healthy, you don’t pay attention to it — you just go on living your life.
To sum it up
Security and development teams might have some competing interests, but the first step to eliminating friction is to remember that both teams are ultimately on the same side in wanting success for their organization. For security teams, curiosity, empathy, and a willingness to prioritize the developer experience will go a long way in reaching shared goals and removing the stigma of security as “the department of no.”
Watch our full conversation on demand, and tune in later this week on March 31 at noon PDT when Daniel Miessler, Founder of Unsupervised Learning and Head of Vulnerability Management and AppSec at a large financial services company, joins The Dept. of Know Live! to chat about why we can’t ignore asset management’s role in security.
