Developers have no time for your complex security processes. Making application security simple means focusing on essentials and cutting through the noise.
It’s sounding more and more like the ghost of Henry David Thoreau had a hand in planning this year’s RSA Conference in San Francisco.
Perhaps the 19th-century poet, essayist, and philosopher’s most famous line is “Our life is frittered away by detail … simplify, simplify.”
And the message of multiple RSA sessions and keynotes could be paraphrased as “Application developers’ lives are frittered away on details. Simplify! Simplify!”
Make application security simple
The details that have developers frittering away their time usually involve having to stop what they’re doing, open something they were doing a week ago, and fix a bunch of bugs or defects the security team just sent them. They, understandably, resent it—and the security team.
So the message from many RSA podiums was: Stop doing security that way.
Christopher J. Romeo, CEO of Security Journey, in a talk titled Ten Things I Wish Every Developer Knew About Security, discussed what he wished security people knew about developers. For developers, process complexity is an enemy, and simplicity is a friend that helps them view security teams as collaborators.
He and others repeated what has been a regular theme at security conferences—that developers care about security and agree it is important, “but time is scarce. They feel like they’re not given enough time to do it.”
Make it simple: Practice developer empathy
To start, Romeo recommended that security teams work to “practice developer empathy.”
And then, to simplify. “We need to simplify methodology, language, and framework choices and provide adequate security guidance,” Romeo said, adding that this is one way to eliminate what developers perceive as an “oppositional style” and that security teams are an obstacle.
Indeed, Romeo even went so far as to declare that the “Sec” in DevSecOps should be “silent.” That, he said, would also simplify the development process.
“You cannot have a true DevOps without security being integrated, which is where it needs to be. It’s all about building security in,” he said. “Don’t make it a separate thing.”
“Building security in” throughout the software development life cycle (SDLC) rather than trying to patch it on at the end, when pen testing just before deployment can uncover hundreds of bugs and vulnerabilities, has been the focus of the Synopsys Building Security In Maturity Model (BSIMM) for the past decade.
The collection of data about the software security initiatives of dozens of companies (now up to 122), primarily in eight industry verticals, has shown that building security in—finding and fixing vulnerabilities throughout development—delivers better software faster and cheaper. And yes, when done right, with the right testing tools integrated into the process, it is also simpler for developers.
Make it simple: Prioritize
There was a similar message from Jennifer Czaplewski, director of product security at Target, even if the setting—a $75 billion retailer—was much different from Romeo’s.
In a talk titled When Application Security “The Wrong Way” Is “The Right Thing” for Your Organization, she said she and her team began four years ago to create a PowerPoint dashboard detailing whether the company’s products were secure.
It didn’t work. The product teams wouldn’t read it because it was so dense.
“So we thought simplicity would be good way to go,” she said. That led to the creation of what they called a Product Intelligence dashboard that yielded a single “security product intelligence” score.
“It was similar to a credit score,” she said, noting that it immediately caught the attention of product teams, which were allowed to get into the data weeds as much as they wanted.
“We spent a ton of time on data integrity,” Czaplewski said. “We let them run the numbers themselves. And now developers trust it.”
Another security “myth” that needs to be simplified, she said, is the one that contends it is mandatory to “scan ALL things.”
“It’s too much information,” she said. “We were unable to prioritize.”
In Target’s case, she said her team created a “security ninja” program, which then worked to guide product teams in best practices, including maintaining an app inventory—yet another element of security hygiene, given that you can’t protect what you don’t know you have.
But the bottom-line goal, she said, is to “make the secure way the easy way” for developers.
“If you simplify, less is usually more,” she said.
*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Taylor Armerding. Read the original post at: https://www.synopsys.com/blogs/software-security/application-security-simple-developers/