Why scanning isn't enough

Developers today can choose from millions of free open source components, enabling them to build applications faster than ever before. But with great power comes great responsibility. While drinking from the open source firehose is great during the initial development phase, before deploying any code to production, a responsible developer will need to know the open source packages they’ve selected aren’t going to cause pain later. When making choices for which components to bring in, it is smart to ask questions like these:

• Is there an active community keeping the project maintained? 
• Is it secure?
• Is it licensed in a way that complies with our policies? 
• And how accurate and complete is that license information, anyway?

Enterprise organizations, especially those distributing software or in highly regulated industries, often—for good reason—care deeply about ensuring the safety and security of the code that they deploy. While the benefits of open source are undeniable, there are certain risks that must be considered when pulling code off the Internet.

Yet only 9% of organizations have an official policy in place for bringing open source components into their apps.

The need to ensure open source components were secure and properly licensed led to the rise of a set of tools that scan code for problems and vulnerabilities. Many large organizations today have licenses for at least one or more software composition analysis tools, “scanners,” that alert them to security or licensing issues with their open source components.  

For the most part these tools cover one function: they identify the issues. 

But when it comes to fixing the issues identified by the scanners, that is another story. Between false positives and “alert fatigue,” conflicting information about vulnerabilities, no easy way to resolve many issues (because by definition it’s not code you wrote in the first place), and yet another web UI for devs to check before deploying code, scanners can slow down releases and cause developers headaches. 

Think about scanners through the metaphor of a trip to the doctor. Imagine that you are at the doctor’s office for your annual checkup. At the end of the appointment, your doctor hands you a report that lists out everything wrong with you. She turns to you and says, “Well, Bob, you’re not looking too good. You have high cholesterol, your kidneys are shutting down, and your big toe...looks like you're going to lose it. Now...go get yourself better!”  

Where do you even start?

Similarly, say you get handed a list of problematic open source packages from your favorite scanning tool—what do you do with it?  

1. You can try to address some things yourselves, if you happen to have the particular expertise (i.e. Go, JavaScript, etc.). You probably already spend 35% of your time managing code issues anyway, so this might feel normal. And if you’re not in a position to get those changes merged into the upstream community repository, prepare to maintain your own branch of every package you do this for—for the rest of time.
2. You can bug the package maintainers on the public GitHub repo—maybe they’ll even respond? Just remember that 74% of open source maintainers have difficulty finding time to work on their projects, and in most cases they aren’t being compensated for their work, so your urgency isn’t their urgency.   
3. You can hire an outside consultant to come in and fix things for you—expensive, not particularly scalable, and this approach may leave you with a new fork you are now on the hook to maintain.

Or you can do what most organizations do—rank issues by severity level, address the “most important” things first, and ignore the rest. 

At the end of the day, getting a diagnosis of your problems simply is not enough. 

You still need the right treatment plan—including preventative maintenance—so these sorts of issues come up less in the future. 

The best way to ensure the health of your open source supply chain and pass your scans is to proactively start addressing security, licensing, and maintenance concerns earlier in the process. That’s why many forward-thinking organizations are avoiding these sorts of developer headaches by shifting left and ensuring open source components are secure, properly licensed, and well maintained earlier into the development process. 

Thinking back to our doctor’s office metaphor, if our goal is to be healthy, when I go to the doctor, I want them to give me a clean bill of health and send me on my way. Even though the doctor may have medication to help me with my high blood pressure and bad cholesterol, I can never expect to be healthy unless I change my ways, exercising and consuming less junk!  

The same can be said when building applications with open source components. When it comes time to write production-ready code, developers should start with known-good open source from the beginning—stable components with strong communities that won’t fall into disrepair.

Scanning by itself simply isn’t enough. While an important and necessary precaution, scans still leave the burden of the “staying healthy” work on the developers. Knowing about vulnerabilities is good, especially when there is an available fix or a reliable project maintainer committed to getting you one, but this is more often the exception than the rule.  

Keep scanning your code, but make sure you have tools and services—like the Tidelift Subscription—that help ensure your open source components are healthy before you even get to the scanner. You’ll have happier developers, and you’ll get better, more reliable applications even faster.