With modern software development, it's counterproductive to blame developers for your software security woes. Here are five reasons why.
When there's a failure in software security, it can be convenient to blame developers for the damage it causes to an organization. However, that path can not only be counterproductive — but also unwarranted.
Modern application development is a complex process that involves third-party code and components. Software engineering is only a part of that process. And any number of elements in it can influence software security — either directly or indirectly, said Jasmine Noel, a senior product marketing manager at ReversingLabs.
"Sure, a percentage of them will always be [from the development team] — so you always have to keep testing for vulnerabilities — but there's a growing percentage of things beyond vulnerabilities. You could develop the most secure software in the world — zero vulnerabilities — but you can still get attacked."
—Jasmine Noel
With the changing nature of threats shifting from legacy vulnerabilities to the software supply chain, it's time to stop thinking that all application security problems stem from code that's badly written, Noel said.
Here are five key reasons to stop blaming devs for your software security woes.
1. The development process is an emerging attack vector
In the past, software development techniques and systems, such as containers and continuous integration/continuous delivery (CI/CD) environments — and the developers working in them — did not have to consider trust too much. Now they do. "We're in a new phase of attack. They're attacking the development process," Noel said.
"They're attacking the trust we have in how we build software. So we need to rethink the threat models for our applications. Security people and development people need to get together to do that, but that get-together shouldn't start off with, 'You're doing something wrong or 'You made this error while coding.'"
—Jasmine Noel
Hackers breaking into the development environment are making changes directly to infrastructure or automation being used to package and sign software, she added. The recent NVD Analysis 2022 report showed that software supply chain attacks are surging, with attacks on popular repositories npm and PyPI up 289% since 2018. That happens after the developers are involved in creating the actual software. "A developer can't be blamed for that kind of attack."
2. Decisions outside a developer's control can affect security
Johannes Ullrich, dean of research at the SANS Technology Institute, explained that by the time developers get to work on a project, a lot of decisions have already been made. "If those decisions aren't made properly, then developers will have a hard time implementing things securely," he said.
"Blaming a software fail on any individual or group, like software developers, always increases the risk that you're missing the bigger picture. Software is a system. It's not just lines of code. It starts with the design of the software, with grading specifications, all the way to testing. Developers play a critical role, but they're not the only individuals participating in creating software."
—Johannes Ullrich
Casey Bisson, head of product and developer relations at the cybersecurity services company BluBracket, said software developers are always struggling with the classic "pick two" scenario among features, quality, and budget.
"When we look at the problem that way, we realize that security failures are either a failure to include security in the planning and requirements given to developers, or in the budget priorities that developers are working within, including both time and resources."
—Casey Bisson
3. Time constraints imposed on developers can contribute to security failures
If a developer is asked to add functionality to an application and not given the time and resources to do it properly, then security problems that arise from that feature aren't the fault of the developer's alone, Ullrich said. "They're a software development management problem or software lifecycle problem, where the system was just never designed properly," he said.
"Some time constraints you can offset with best practices and having good guidelines on how to develop secure code. In those cases, you may be able to speed up development, if developers have the proper tools."
—Johannes Ullrich
However, Ullrich noted there are issues around business logic — such as who is supposed to have access to a feature or how people are authenticated — that can be difficult for developers to understand and for which they need more time to do so. "Rushing that often leads to mistakes," he said.
Caroline Wong, chief strategy officer at Cobalt Labs, a penetration testing company, said that time constraints often meant that there was not enough time to focus on priorities — and not enough time to focus on items which are not a priority.
"Is it a priority for the organization to find and fix security vulnerabilities? That depends on a variety of factors, including culture and risk tolerance."
—Caroline Wong
4. Legacy software baggage can undermine an application's security
A lot of fails arise from "technical debt," or choices in an application made in the past for the sake of expediency that were flawed, said Ed Moyle, a member of the ISACA Emerging Trends Working Group and systems and software security director at Drake Software, a developer of tax preparation software.
Technical debt often includes places that impact, and in most cases weaken, security — but in places that may not be obvious, Moyle said.
"A management culture that engenders and fosters technical debt is absolutely contributing to security fails though they may not realize it. This is why they need experts who can help them understand why a culture of technical debt not only makes future development harder, but also undermines security as well."
—Ed Moyle
5. Management leadership failures can lead to security failures
An organization's leadership and management should be setting priorities for development teams, Wong explained.
"If finding and fixing security vulnerabilities is a priority, then attention will be paid to those activities, and they will be focused on. If not, these activities will be neglected and the result will be insecure software."
—Caroline Wong
Management is not going to know the architecture of an application as well as the developers who work on it every day, so they shouldn't be expected to mandate in detail how developers should be writing code, said Moyle. "What they can do, however, is communicate goals by having engineering principles or other guidance signed off by management about how to approach specific development tasks."
Stop the counterproductive blame game
As outlined in these five points, it's counterproductive to blame developers. Software security should be a shared responsibility, Noel said.
"Not all things that go wrong with software can be laid at the feet of a developer. I'm not saying developers are without responsibility, but starting at a point where they're always at fault is not going to get you where you need to be."
—Jasmine Noel
All Stories
Software Supply Chain Security
Dev & DevSecOps
CI/CD Security
Container Security