The enterprise challenge in generating secure code is well known: as software becomes a competitive advantage and customers expect regular updates, the need to release new features and content frequently often trumps the need to release secure code. Although that's a true conflict, it's not the full story. Psychology can play almost as big a role, with security teams often perceived by developers as the "they'll always say 'no'" people.
The best approach to negate both problems is to create a security champion from within the developer ranks. That person—often a developer—can bridge the gap between development and security. That accomplishes both making developers more comfortable accepting security advice as well as helping product management internalize how essential security is. Also, having someone from the development team serving as a security champion will accelerate the process of delivering secure code, which means those capabilities get to the customers faster.
And it is that speed, that never-ending need to deliver to a constantly shrinking window for time-to-market, that fuels both sides of this problem. "Companies must keep up with that pace of technology change and remain competitive," said Sonali Shah, the VP for product management and marketing at Veracode, in a recent webcast.
Shah argued that as development methodologies advance and improve, so, too, must security tactics. "Software development has evolved from the waterfall method, where releases occur only once or twice a year, to agile, where releases may occur monthly, to continuous integration and delivery, where code may be shipped multiple times per day. In addition to these changes in how software is developed, enterprises are also shifting to the cloud and moving from monolithic architectures to microservices," she said. "The problem occurs when the way software is developed and deployed changes, but security tools and processes do not.”
But security departments or groups are far too often seen as obstructionists. "First, security is seen as a blocker. Security cannot be a gatekeeper or development teams will simply go around them," Shah said. "Secondly, security occurs mainly in the test phase, once development is complete. Security findings are then sent back over the wall for the developer to fix, sometimes long after he or she has even written the code. This can result in costly delays and no one wants to be the developer whose insecure code held up a release. Or, even worse, to be the developer whose insecure code was released and resulted in a breach. The unplanned and unscheduled work caused by security findings cause developers to be in conflict with security teams."
At the same time, developers face pressure from product managers and their sales teams to release the next hot new feature and, in many cases, security has not been defined as a key functional requirement from the start. "Security can often be overlooked or worked around because, after all, continuous innovation and improved features can be the key to delighting customers and staying competitive," Shah said. "This is when companies are forced to make the tradeoff between releasing code quickly and releasing secure code."
Another element of the secure app problem is the fact that there are simply far fewer people with meaningful cybersecurity credentials than there are jobs that need those skills and that experience. By next year, the global shortage of cybersecurity professionals will top 2 million. Some 53 percent of organizations experience delays as long as six months trying to find qualified security candidates. About 77 percent of women said that no high school teacher or guidance counselor mentioned cybersecurity as a career. For men, that figure drops to 67 percent. And 84 percent of organization executives say that half or fewer of their applicants for open security jobs are qualified. The result of all of this has been that software is not nearly as secure it can and should be. "Security has to be included in the definition of done for any new software release,'" Shah said.
Shah's position is that the role of security champion—a member of the development team who agrees to receive security training and then to act as the "voice of security" for the product—can fix many of these problems. The security champion is trained in basic security concepts, threat modeling, secure code review training, and security controls, and works with developers on improving the security of code at every stage of development. When the security problem is beyond his or her training, the champion would escalate the problem to the security team. Critically, the champion also represents the needs of development to the security team, such as selecting the tools and training needed and working out release timelines. The champion would also represent Security in product planning by building security into the earliest product requirements.
The element that gives the security champion such effectiveness with fellow development team members is that the security champion is truly one of them. The security champion "sits with the development team every day. Because the security champions are developers, they're often better able to communicate and to work with the developers," Shah said. "Developers think 'Security just blocks my way and they talk in jargon that I don't understand.' By having someone in the development team teach developers about security and help them work through their security issues, you're much more likely to be successful."
A similar dynamic makes the security champion an equally effective advocate for developer concerns when the security champion meets with Security. "This way, development has a seat at the table when security decisions are made that impact them. And Security has a seat at the table when decisions are made about development practices and definition of done requirements," Shah said. Shah also stressed that the security champion doesn't necessarily have to be a coder. "The security champion can be a QA engineer. They could be a UX designer," she said. "It's simply somebody in the development organization with the right security training and the ability to influence and motivate his or her peers. It doesn't have to necessarily be a developer."
One thing that the security champion must be, though, is a volunteer. Security champions must decide on their own that this is the right role for them. How to persuade them to step up? It's not that hard. Most developers are smart and curious and eager to learn new skills. Also, given the increasing cybersecurity professional shortage, many developers understand that these new skills give them a career boost and make them more attractive to employers.
For management, a critical component of a security champion's role is that the security responsibilities are on top of existing development tasks. For the security champion to succeed, some things will have to come off of their to-do list. "When you add it on to someone's job without freeing up some bandwidth, that's really when they tend to fail," Shah said. "It's because they are not being given the time to do their jobs."
This security champion approach quickly delivers benefits to the company as well as the development team and the Security team. For the company, security holes are identified and fixed much sooner, which means faster time-to-market with much higher quality secure code. For developers, "you're finding and fixing security issues early, thereby enabling good code to be released on time," Shah said. "They don't need to wait days for someone from the Security team to help them secure their code."
Beyond general help with security issues, Shah points out some not-so-obvious benefits for the Security group. "The security team gets to now focus their previous resources on the hardest problems to solve," she said. "You've given (Security) more interesting work to do, which helps with their retention. And they have greater job satisfaction because they're not constantly fighting with the development team."
Listen to Sonali Shah’s session on The Secret of the Security Champion.