Software developers vs. software security: Why can’t we all get along?
I was a software developer for over 20 years before I switched to the application/software security field. Being a part of several software engineering teams in my early career, and later becoming a security analyst, has put me in a unique position to understand these two worlds. Although I continue to enjoy the security assessment work, there is one thing I can’t help but notice. Over the years, I have sensed a tension between engineering teams (software developers) and software security experts. I’ve even noticed developer bashing in some corners of the security world. It doesn’t feel as if developers and software security experts are always playing on the same team.
Good security analysts know “the right thing to do”—which security controls to implement—and “how to do it right”—additionally, how to implement these controls in a correct/secure manner. That is well and good. However, the real agents of change are the software developers and engineering teams.
And therein lies the problem.
What’s the cause of the developer/security divide?
Although software security people own the security problem, the software developers are the actual agents of change. To complicate matters more, the security teams and software engineering teams are incentivized differently. Engineering teams are incentivized on the lines of code checked-in, number of features implemented, number of bug fixes, improvements in user interface and so on. On the other hand, security people are incentivized on making the software secure.
With seemingly contradictory incentives, it is easy to see why the software engineering teams and the software security teams are frequently at odds. But to get security right, they need to play on the same team.
Can this be done? If so, how do we effect this change?
What security can learn from economists
As it turns out, our field is not the only one that faces this problem. Economists have been studying a similar issue for years. It’s called the Principal-Agent Problem or Agency Problem. For many companies, the interests of the principals (e.g. shareholder or the owners of the company) are not always aligned with those of the agents (the management of the company). This frequently pits them against once another, or, in other words, puts them on opposing teams.
After studying this problem, economists devised a set of solutions aimed at aligning the incentives of the principals and agents (e.g., Incentive Stock Options). Most, if not all of these solutions align the incentives of the principals and agents. The result is getting the shareholders and the management to play on the same team. Voila!
Security and development together at last?
If you look at this model from our angle, software security teams are principals and software engineering teams are agents. To get everyone playing on the same team, all we need to do is align their interests and create complimentary (rather than opposing) incentives.
Of course, that’s easier said than done. In fact, there are major disciplines like organizational development that are trying to tackle such issues. But BSIMM (yes, Synopsys’ own Building Security In Maturity Model) is subtly and cleverly changing minds and organizational thinking. How? BSIMM has this ability to place a “mirror” up to an organization which reflects their current state of security in comparison to the rest of the industry. This “peer-view’ comparison affects change without expressly calling for it. For example, if your peers are ahead of you when it comes to security, chances are, you’ll want to make changes to catch up. In order to catch up to your competitors in a cost-effective, timely way, you’ll have encouraged your software security team and development team to work together. To do that, it’s essential to align their incentives. And we’ve come full circle. Very clever indeed.
