Steve, the application security lead, sits down with Julio, a senior developer. Steve explains an initiative to move security into the early phases of the SDLC. Julio understands the value proposition: it’s easier to fix defects early on. Steve then goes on to explain the new processes he’ll be instituting and Julio looks concerned:
“I conceptually get why you want to add these processes, but quite frankly it’s a wasted effort with our group. We’ve got some very senior and capable engineers who have undergone extensive training. I don’t mean to say we’re perfect, but anything we miss just gets caught with static analysis anyway. “
Steve’s not sure what to say. Surely Julio knows that the application had a few high risk vulnerabilities caught in an audit report earlier this year. Sensing Steve’s concern, Julio continues:
“The real problem, if you ask me, is people. If you hire smart, competent developers you don’t get security issues. As you know, recently management made a decision to outsource some key development. These outsourced developers, well they’re good at doing *exactly* what you ask of them but nothing more. They don’t get that security requirements are implicit. These guys created a hidden form field manipulation security defect. Come on, tampering hidden form fields? Really? I remember reading about that in 2001. If you ask me, all the processes and tools in the world won’t protect you from incompetence. We need to stick with smart engineers.”
Steve is unsure what to do. In his mind, the issue here isn’t competence — it’s about rigor. He isn’t sure how to get Julio on his side.
This is the first in a series of cultural challenges we often see for deploying full secure SDLC projects. The “incompetent developer problem” stems from a popular view that security defects primarily arise from incompetent developers. Few people would argue with Julio that strong engineers are generally less likely to make egregious mistakes than less experience counterparts. However, focusing exclusively on developer skill ignores the difficulty of effectively training developers on the entirety of relevant common software weaknesses, keeping up with emerging threats, and remembering that cognitive load and lack of awareness of in context are all contributing factors.
Is Julio right? How should Steve approach this kind of conversation? Let us know your thoughts. We’ll present our approach in a future post.