Bullying software developers into embedding security procedures in their workflows is a mistake, a developer-turned-hacker said in a presentation at the OWASP Global AppSec conference in San Francisco last week.
"Security is something that devs are forced to do, and we kind of treat them like dogs," said Dr. Katie Paxton-Fear, a staff security advocate at Semgrep and course advisor at the Manchester (UK) Metropolitan University. "We're fostering resentment, not good security practices."
All too often, she related, security personnel adopt a high-minded attitude to software developers, telling them what to do (and not do) while failing to appreciate the complexities and pressure of the developers' jobs.
Needless to say, this does not create a positive attitude. It often spurs developers to simply bypass the imposed security checks in the development environment that are slowing down their work.
"Developers just route around security," said Paxton-Fear. "When I was a dev, I thought that security was for other people, not for me."
We are (not always) the champions
To mitigate the resentment, many organizations designate specific individuals on development teams as "security champions" who can check their colleagues' work and encourage better security practices. But Paxton-Fear says this is often a thankless job.
"You alienate your colleagues and slow down their productivity for no reward," she said.
Not only are many security champions not compensated in any way for their efforts, Paxton-Fear said, but they are often expected to match the outputs of their colleagues even as they spend time learning and evangelizing best security practices.
"Security champions will close fewer tickets than their colleagues because they have to spend time focusing on security," she pointed out.
The better way to get developers to embrace security practices is to nudge, cajole and charm them, Paxton-Fear said.
"Make the secure path the default," she said.
Opt-out beats opt-in
She drew an analogy to a UK government program that in 2012 began enrolling workers into making paycheck contributions to private pension schemes by default, after the contributions had previously been an opt-in choice. The private-pension enrollment rate went from 55% to 90% in a few years, Paxton-Fear said.
In this way, she said, the implementation of security procedures in software development would be "invisible and easy" rather than obvious and difficult.
Similarly, she said, practicing good security in the development environment should be what Paxton-Fear called EAST, or "Easy, Attractive, Social, and Timely."
"Cut the hassle of doing the right thing," she added. "Make it rewarding. Show them that people like them already do it."
Developers can be prompted as they are deciding between two paths, offered feedback as code is being written, shown easy-to-access examples of best practices, and presented with two-minute explainers instead of hour-long sessions.
Software developers should also be given ownership of security and treated as intelligent people who can offer input, Paxton-Fear said.
"Bring devs into vendor conversations," she urged. "Ask them how to improve security. Listen to what they want changed. Respect their autonomy."
Guardians of the development galaxy
As for the put-upon security champions, Paxton-Fear said, make them security "guardians" who genuinely are interested in security, reward them for their efforts with extra perks or pay, and designate part of their workload as "protected time" to be spent focusing on security.
"Recruit the curious, not the 'voluntold,'" she said. "Don't just look at a list of teams and tell individuals they've got to do it. Make it truly voluntary and make it a bit exclusive."
Asked by an audience member about how to know which developers to bring into security discussions, Paxton-Fear was blunt.
"Get the most opinionated person, the one who isn't afraid to be an asshole," she replied. "You want to make them feel like security is happening with them, not to them."