Walking In The Application Developer's Shoes
Security professionals try to go to where the app developers live
Kelly Jackson Higgins, Editor-in-Chief, Dark Reading
March 10, 2011
5 Min Read
No one expects application vulnerabilities to be altogether eradicated. But even with all of the secure coding initiatives and tools out there -- OWASP, Microsoft's open Secure Development Lifecycle (SDL) tools and guidance, BSIMM, Rugged, and plenty of application security scanning tools and services and research -- applications are still being written with security flaws. So the stubborn gap between the security and development worlds remains.
That has led some security pros to try a different tack to work with developers: Rather than preaching to the choir in security or trying to attract developers to security conferences, a few have begun stepping into the developer's world -- or at least meeting them where they live.
"I think to speak with developers is really difficult from a security standpoint," says Chenxi Wang, vice president and principal analyst at Forrester Research. "The application security community has been preaching to itself for a number of years."
Wang says application development today is all about features and getting them to market quickly. "Today it's all about how fast you can push out code. Given that mentality, it's difficult to tell them to slow down [for security]. Some don't even do quality testing, let alone security [testing]," she says.
Jeremiah Grossman, co-founder and CTO of WhiteHat Security, during the past year has been taking his app security message directly to developers, small developer groups, and various start-ups. Grossman says the case that developers should come to security just isn't "compelling."
Developers typically don't have any real incentive to prioritize security, he notes. "From their personal perspective, if they want to learn a new technique, it helps their careers and they get promoted. But security is not necessarily that way: Do they get promoted if they write secure code? Not so much. Do they get fired if they write insecure code? Not so much," Grossman says. "There's no carrot and no stick. Where's the real incentive? The developers are not coming to us because we have nothing to offer [them in light of that.]
"I wasn't having the impact I would like in preaching to the choir ... So I started visiting with developer groups in different start-ups and found that when I started doing Web hacking demos, they were all over it. The alternative is to go to them, and they appreciate that."
Grossman has no illusions: He says he's just an outsider at these developer sites bringing some information to them about Web application vulnerabilities and attacks to help them in their jobs. Still, he's taking this new role to heart and has cut the number of security conferences he attends by about 50 percent since 2008, attending about one security conference every two months. "I might meet one developer at all of the [multiple] security conferences. Or I can meet 100 developers at 40 different companies ... and make a greater impact that way," he says.
Grossman meets a combination of both developers who haven't yet been exposed to the perils of cross-site scripting (XSS), cross-site request forgery (CSRF), or other common Web application vulnerabilities their apps might harbor, as well as developers who already have been schooled about avoiding such flaws.
"Others I have visited say, 'Yes, we've heard about CSRF and cross-site scripting ... and we do care,'" Grossman says. They just aren't given the time or resources to focus on it by their organizations -- they're often pulled to develop a new feature first, he says.
"And some don't care ... they just build," Grossman says.
Grossman says he's not trying to bridge the gap between the two worlds, per se: "Security is security, and development is development," he says.
One trend he has noticed is some large organizations take it upon themselves to educate their developers in-house. "We're seeing more organizations hosting conferences for themselves: eBay has one, Amazon has one, and Microsoft does. Their security teams bridge their own gap internally and invite their developers internally. That way, developers can go to a conference only for them and about them, and they can talk frankly with one another," he says.
Some larger companies' security teams are now starting to compile a set of metrics of where different business units need to improve their security. Grossman says he has seen this strategy at a handful of large companies, where they publish an internal report that lets business units see how they compare security-wise against other units. For those that have the most secure systems and websites, it's kudos and reinforcement that they are on the right track. "For others, it's a wall of shame," he says.
But despite the frustrations with application security flaws, there has been some progress with companies cleaning up their code: Grossman points to WhiteHat's latest stats on remediation rates, which have been increasing about 5 percent per year over the past three years. "Back in 2007, remediation was at 30 to 35 percent. Now it's at 53 percent," he says.
Marisa Fagan, security project manager at Errata Security, is taking it a step further and becoming a developer as well. She says she's hoping to lead developers by example: "I've begun working on projects that lead developers by example to see security for what it is -- ruggedness -- and not an arsenal of pain. This means growing my development skills and practicing what I preach. Hopefully this way I can get to better know the development community and effect change from the inside," she blogged today.
Fagan says security has to become a priority. "That's a mindset shift that is hard to do" for the development community, she says. "But we have seen developers picking up stuff on their own, and fixing problems from the perspective of quality. They add SSL to development because that's what the customer expects," for example, she says.
Like Grossman, Fagan feels that solving the application security problem can't just be solved from the confines of the security community. "We need to let developers help themselves," she says.
Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.
About the Author(s)
Kelly Jackson Higgins is the Editor-in-Chief of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise Magazine, Virginia Business magazine, and other major media properties. Jackson Higgins was recently selected as one of the Top 10 Cybersecurity Journalists in the US, and named as one of Folio's 2019 Top Women in Media. She began her career as a sports writer in the Washington, DC metropolitan area, and earned her BA at William & Mary. Follow her on Twitter @kjhiggins.
You May Also Like
Your Everywhere Security guide: Four steps to stop cyberattacksFeb 27, 2024
Your Everywhere Security Guide: 4 Steps to Stop CyberattacksFeb 27, 2024
API Security: Protecting Your Application's Attack SurfaceFeb 29, 2024
API Security: Protecting Your Application's Attack SurfaceFeb 29, 2024
Securing the Software Development Life Cycle from Start to FinishMar 06, 2024