And What You Can Do About It
Engineers and technical leaders don’t want to build insecure applications, platforms, and environments. Yet, in helping companies with their application security and DevSecOps, we usually find significant security backlogs. Let’s take it as a given that building secure applications requires expertise and investment and pose the question: Why is it, even in innovative companies, that development teams tend to ignore information security issues?
Here are our top reasons based on recent experience and, just for fun, we identify the culprits involved in each:
1) Intentional assumption of security risk.
Let’s face it, beyond the very basics, information security is one of many issues on the back burner for most new companies. Until management is more certain that there are customers interested in what they are building, securing whatever that is can feel like an unnecessary or premature use of precious resources. This works at the individual level as well, for example, an engineer working on a proof of concept.
Venture-funded companies are on the clock and burning cash and PE-funded companies are often executing against a strategy including specific financial objectives. Given the criticality of development velocity paired with scarcity of resources in most business situations, it’s easy to understand how people rationalize risk acceptance and, with the best of intentions, resolve to fix security issues later on.
Even at the individual developer level, management makes the acceptance of security risk permissible. When management measures security and sets expectations, the engineer knows her code will be judged, in part, on its use of security best practices.
2) Unintentional assumption of security risk.
Application security issues can remain out-of-sight and out-of-mind until Sales, Customers, or the FBI come calling. Code is created to implement a feature or functionality and, although that code can be demoed, tested, and evaluated by others, in most environments only the authors understand the details of how it does what it does. In making these decisions, even in alignment with stated security practices and understood security architectures, unintentional security risk can be introduced.
Management is in control of investment in security-enhancing training and tools, etc., but engineers write, document, and integrate the code itself. From our experience, the performance, elegance, and even quality and reliability of code are considered by many engineers before its security. Individual engineering and architecture choices are where the rubber meets the road.
3) Maturity of security and engineering processes and procedures.
While the engineering teams we have worked with have the brain power and the leadership necessary to figure out security, we often find that their resources, processes, meetings, and development hours are not focused on security topics. The extent to which security issues are addressed in development shops is often a function of the maturity of both security and core engineering processes and procedures.
In some cases, we see inconsistent attention to documented security processes, procedures, and standards. We also see cutting-edge security tools installed but not used. Leadership might
prioritize security when a customer or sales issue arises, but then fail to allocate meaningful and dedicated resources over time. Worse, we’ve seen organizations where investments have been made in information security programs (people, process, and technology) but they remain organizationally and operationally siloed off from engineering, under-resourced, or lacking the authority to drive meaningful changes.
There are tons of blame to go around here but, come-on, “the buck stops here” at some point.
4) Paper security and compliance programs.
We mentioned sales and customers forcing engineering to focus on security issues. “Hey ABC Bank wants to see a third-party pen test conducted in the last three months, can I have that this afternoon?” We’ve blogged before about the security theater surrounding many vendor risk management programs and the amount of paper generated during the never-ending performance.
It’s amazing how long companies can go without causing developers to address real security issues. Organizations use the super-tidy and well-documented security and compliance programs that you can purchase out of the box via one of the twenty well-funded GRC-lite SaaS tools on the market today. Some companies go all the way to surging through the creation of evidence for a SOC-2 audit in order to win that big deal, and then let it lapse.
Culprit: CONSULTANTS AND VENDORS
It’s tempting to blame management again, but consultants and vendors make hundreds of millions of dollars a year driving this form of security theater to new heights -- what’s an engineer to do but keep his head down and execute?
In part 2 of “Why Do Software Engineers Ignore Security Issues, And What Can You Do About It,” we’ll explore some practical steps that you can do to overcome the natural security malaise often surrounding SDLC and DevOps.