This post was originally written by Ericka Chickowski for Security Boulevard; access it here.
Application security (AppSec) struggles mightily with scale. Applications must be protected, dependencies tracked, and vulnerabilities prioritized — it can be dizzying to keep tabs on it all. And most overwhelming of all is the sheer gravity of the typical enterprise codebase.
The amount of code running the world today is staggering, and its growing by the day. Most frustrating for teams responsible for AppSec is that a lot of that code is actually not all that useful. AppSec veteran Bert Hubert brought the issue back into the spotlight in an IEEE Spectrum think-piece, “Why Bloat Is Still Software’s Biggest Vulnerability,” which hit a nerve across the AppSec and development communities.
“The world ships too much code, most of it by third parties, sometimes unintended, most of it uninspected. Because of this, there is a huge attack surface full of mediocre code. The way we build and ship software these days is mostly ridiculous leading to apps using millions of lines of code to open a garage door.”
—Bert Hubert
The problem of code bloat is at the root of many security problems today. First and foremost, as Hubert pointed out, inefficient code expands the attack surface. More critically, it makes it more difficult to know, understand, and test the code.
Michael Burch, director of AppSec for Security Journey, said there are more points of failure with bloated software, and this is often the result of old software meeting new code.
“This is because the person writing the new software often doesn’t have an appreciation of all the details of the original code that is being leveraged. The more complex a system the more difficult it will be to secure and the more possibility of failure exists.”
—Michael Burch
There are a lot of contributing factors that cause this issue to fester: technical debt, lack of awareness, a pragmatic sense of “If it ain’t broke, don’t fix it.” One of the greatest accelerators of bloat is the undisciplined use of modular software components. It’s all too easy to use a huge open-source library for only one small use case, adding 10 times more unnecessary code in the process.
Mick Perick, vice president of cybersecurity consulting for Nuspire, said that in the interest of efficiency, many applications are built using an amalgamation of different code sets.
“As modules are bolted together without concerted efforts to ensure minimization of content, it’s not outside the realm of possibility to find that Frankenstein’s monster’s arm came with a bit of body art or jewelry that adds to the overall whole.”
—Mick Perick
AppSec experts implicitly understand the downstream impacts of code bloat — but doing something about it is not so easy. That’s because code bloat is a problem of technical debt that can’t be tackled with a couple of tools and a few hours of work. It’s something that must be owned by the entire development organization and that will take long-term investment and effort to fix.
Here are seven key steps experts say development teams need to do to get started on building a program for better code efficiency for better AppSec.
Development teams could make a serious dent in code bloat if they were given the direction and time to do maintenance and refactoring work. An organization makes this a priority by scheduling regular sprints that task dev teams with looking at the codebase and identifying opportunities to refactor and trim code. “If teams took a sprint once a quarter to refactor portions of the codebase to address things like duplicate code — code reused in multiple places that could be consolidated — this would go a long way to reducing the application’s attack surface,” explained Burch.
Burch suggested documenting the work put into the sprints and the high-level outcomes seen from them.
“The best approach is to track the improvement efforts over time: ‘We had four sprints this year focused on refactoring and attack surface reduction. In those sprints, we identified X areas of improvement, consolidated X features, and removed X lines of excess code.”
—Michael Burch
In many ways, modularity is both the cause of and solution to code bloat in the modern software stack. A lot of the issues stem from teams pulling in packages and libraries for one or two use cases and adding a whole lot of irrelevant features, functions, and extraneous code in the process. But when code reuse and modularity are coordinated through a well-managed microservices architecture, the discipline can be tuned to improve code efficiency and reduce the attack surface of applications.
Joe Nicastro, field CTO at Legit Security, said moving to microservices architecture and reusing modules that perform sensitive functions across your application portfolio can help reduce the overall attack surface.
“This also allows for clear risk understanding, as these microservice can be deeply vetted and all risk can be understood before it’s deployed in multiple places throughout the organization.”
—Joe Nicastro
Policies around the use of components should stand as the bulwark of a secure, code-efficient microservices approach. These kinds of policies are frequently what AppSec advocates refer to as good guardrails — both for security and software performance.
Satyam Tyagi, vice president at ColorTokens, said that development teams should work on guidelines for adopting any new software component or library.
“These should be managed and enforced. Similarly, any integration should be considered from the point of view of security and maintainability, and a risk review should be done before moving forward.”
—Satyam Tyagi
Nicastro said another tip is to mind your language — your programming language, that is. By limiting the number of programming languages that developers code in, an organization can reduce bloat and the under-the-hood complexity (and attackability) of an organization’s application portfolio.
“Minimizing the number of languages your developers are authorized to use within an org can greatly reduce the number of open-source packages and, therefore, attack surface being brought in. Do you really need to code in every flavor of programming language and bring in multiple sets of packages that do the same thing in all languages?”
—Joe Nicastro
Trimming code bloat in existing applications and encouraging efficient coding can’t happen by accident. Organizations need to take a programmatic approach that ties all of the disparate practices described above into a cohesive strategy, said Itai Birenshtok, vice president of research and development at DoControl.
“It has to be a discipline that is built within the culture of the engineering teams. Multiple developer tools provide visibility into unused or rarely used code and give the ability to trim it selectively. The problem is more a lack of focus than a lack of visibility or tooling.”
—Itai Birenshtok
Many of the actions taken to cut bloat will be completely owned and executed by the dev team, but AppSec professionals can play a role in helping to consult and advise on the highest-priority areas to address. Burch said that If you have a robust security team, it should be involved with the development teams in tasks such as threat modeling and secure design planning.
“Their involvement should help identify improvement points in this effort and help guide teams to a smaller attack surface. For organizations that are more development-heavy and don’t have as much security support, this responsibility turns to the development management team to ensure this is a priority.”
—Michael Burch
One part of security’s function in managing code bloat should be to encourage disciplined management of security features. Security controls in the application should be tracked, consolidated when possible, and maintained on a regular basis, Burch said.
“A good example is something like authentication. When development teams start implementing multiple avenues for authentication into an application because it’s easier than working with the legacy approach, it can lead to a lack of support for one of those authentication security controls. These are prime targets for attackers to gain unauthorized access to a system.”
—Michael BurchLeadership’s support is essential
The ownership problem can’t be solved by security leadership alone, of course. Which is why all of these efforts will need to be backed up by the business. At the end of the day, the only way that any of these code-efficiency practices will take root is if they’re championed by business leadership, said John Bambenek, president at Bambenek Consulting.
“Software engineering leadership needs to own simplifying the codebase, but it will never work without business leadership buy-in, with improved software performance being the gateway drug to getting acceptance.”
—John Bambenek