Getting Out of Open Source Debt

Open source tools have unleashed business speed and flexibility that was unimaginable only a few years ago. But unless you’re very careful, deploying open source components in large numbers also wracks up a lot of “technical debt” – and that can result in security risks, according to Kevin Behr, chief scientific officer for PraxisFlow and author of The Phoenix Project: A Novel About IT, DevOps and Helping Your Business Win.

Technical debt was best explained by Saša Zdjelar, ExxonMobile’s Software Security Group (SSG) Supervisor, as “the cost tomorrow of a shortcut from yesterday. Each time you make a sub-optimal technology decision, you’re incurring debt for future re-engineering and refactoring of the cost of that decision.” Technical debt can accumulate rapidly during software development for businesses where there is no finish line, and operations keep moving faster and more frenetically. “It’s not an easy problem to solve because there are so many potential landmines,” states Tim Prendergast, chief cloud officer at Palo Alto Networks.

Perhaps most critical to paying off your technical debt, Prendergast says, is “Having people who really understand open source components, how they fit together and how they’re used.” This includes public cloud migrations that frequently add to the accumulation of open source code and technical debt. Solving technical debt requires an organization to address deep open source issues, like understanding the limitations of open source tools, recognizing how gaps and vulnerabilities occur in them, how they create exposure to breaches and break-ins, and how each open source community addresses flaws embedded in its components.

The More Code You Have, The More Security Flaws You Have

As modern businesses move faster and become more complex, software, too, has increased in complexity. Add in public clouds used by rogue business and development groups and you have the makings of a security nightmare. “The more code you have, the more bugs you have. When you introduce DevOps and micro-services you’re creating a very complex architecture with inherent security risks,” observes Azzedine Benameur, senior researcher in the Cyber R&D Lab at Accenture.

A primary reason for accumulation of technical debt is the lack of a framework–including a governance structure–to manage open source components. In some cases, Prendergast says, legal, technical and practical issues can collide. “Too often, organizations have a fractured situation. Legal experts make decisions without any knowledge of licensing fees or security, while a security group doesn’t acknowledge legal issues or understand how developers work,” he explains.

DevOps presents particularly vexing challenges, author Behr says. The whole point of a DevOps initiative is to remove red tape and streamline processes. “But the situation can create a Frankenstein of technical debt. If you’re not careful you find yourself adopting an endless array of one-off solutions. Debt piles up as people make quick choices that aren’t part of an integrated and coordinated plan,” Behr explains.

Finding A More Secure Open Source Way

Like enterprise risk, “Technical debt is not something you ever completely eliminate,” says Prendergast. “The goal is to reduce technical debt and, along with it, risk exposure in the cybersecurity space.” This includes open source components used in public clouds. He identifies three primary ways to address the challenge.

  • Engage in open discussion. It’s important to ensure that the board and senior executives understand the concept of technical debt and how, particularly in a DevOps environment that relies on open source components, it can play out. “People need to identify risks and responsibilities. They need to understand how and why the organization uses open source as part of its business framework,” Prendergast explains. This includes discussions with partners, open source groups and peers at tech and open source conferences.
  • Develop a cohesive strategy and build a framework for managing open source components. A governance framework and clear policies are paramount. This includes criteria for how groups choose open source components, how they use and retire containers, and how security tools fit into the picture. Accenture’s Benameur says it’s important to automate security processes, including static and dynamic analysis. Yet, at the same time, it’s vital to avoid procedures and processes undermining the speed and efficiency of DevOps. Benameur says that DevSecOps is a logical solution. It focuses on a more systematic and organization-wide shift in values, attitudes and methods.
  • Determine how best to evaluate and consume technology, including open source components. The way organizations select, adopt and use software has changed radically. Clouds and platform-as-a-service (PaaS)–particularly AWS, Azure and Google Cloud–have transformed the way organizations develop code and software. “You have to understand your technology stack, licensing and governance models, APIs and how open source fits into these systems,” Prendergast explains. Metrics and scorecards are also critical, Behr says. “When an organization understands what works, what doesn’t work and how things work, they are in a position to create greater value.”

Prendergast suggests five core criteria for selecting open source solutions: your ability to operate, manage and support the component; whether you can extend it in the future; its security framework (including how long it takes for a group to patch vulnerabilities); potential licensing or legal issues; and its long-term viability.

Ultimately, says Behr, “It’s important for executives to understand the conditions and trade-offs that lead to technical debt. The end goal is the adoption of open source components that lead to fluidity, reliability, sustainability and value.”