Open source software is a powerful tool in the hands of developers. Acting as a force multiplier, it allows them to build faster by incorporating software that was written by others in the development community. What’s not to love?
For as much as developers love and depend on open source to avoid pulling their hair out under tight deadlines, they might forget to mention that it also comes with some considerable risks. Like all software, there will always be flaws that the less than honest hackers out there may try to exploit. However unlike the proprietary code that your team writing in house, a vulnerability in a popular open source component can leave many, many organizations exposed. All a hacker has to do is try the same exploit across a range of targets, hoping to hit one that has failed to implement the proper fix.
There are also license considerations to take into account. While most developers in the open source community are just happy to contribute and let you use their code with no strings attached, others may have demands that are not inline with your company’s policy. The classic example of this is a general use license — think GPL — that requires the users to make all of their code available as open source as well. This can be a real turn off for companies that have poured millions into R&D for their proprietary software, and would have a few choice words if they saw their intellectual property slipping away due to carelessness. This is not to mention the headache of trying to carry out due diligence for an M&A where the buyer wants to know what exactly she is buying by acquiring your company.
Taking these concerns into account, developers should not be scared to turn to open source as the pros far outweigh the cons. What it means though is that they need control over what they allow into their build, and of course visibility over the lifespan of the component.
Initially, the first solutions to market utilized scanning as a way to identify specific bits of code that matched up with known open source components. While it met the need for some legal teams, giving the lawyers the warm and fuzzy feeling that every line of code was being examined, it was not without its flaws.
Going through the process of scanning all of the code, searching out snippets, and launching investigations was time consuming, and very expensive. Here are five ways that this method can affect your efficiency.
1. Way, way too many false positives
The original sin of open source scanning tools, false positives are a time suck and send your team off on wild goose chases. Whereas scanning through the code searching for snippets may give the sense that it is more thorough, it can quickly produce an overwhelming number of false positives that appear to match an open source component. Your developers will then have to track down and manually determine not to be relevant, essentially wiping clean the advantages of automation.
So what if the team has to deal with a couple of false positives along the way? How many could there be?
Ask your developers for some of their horror stories and they’ll probably tell you about products that they encountered with 50,000 plus false positives.
2. Open Source Scanning brings your Agile SDLC Process to a Grinding Halt
The days of building and releasing a new version of your product every six months (or longer) are long gone. Most vendors now work on a continuous integration (CI) model that makes their software development lifecycle faster and far more dynamic. With this agile model, developers need to be able to move quickly, correcting bugs and vulnerabilities as they build.
Unfortunately, open source code scanning stops this process in its tracks. Often taking weeks to run its course, code scanning requires a long period of review to go over alerts (remember those?), many of which were never relevant in the first place.
As CI and DevOps become the industry standard, your customers have sped up their expectations for delivery of new and shiny updates. Try not to disappoint them by slowing your developers down.
3. Broken eggs – Good luck fixing your mistakes from scratch
Owning up to mistakes is never easy. Making last minute changes in your product release process is even harder and unforgiving. If you wait until the last minute before your update is set to go out into the world, then be prepared for some rude surprises.
Chances are that your developers probably used some open source components that fell outside of your company’s policy. Perhaps they had the wrong license or there was simply an unacceptable number of serious vulnerabilities that could come back and bite you later.
Whatever the reason, your planned schedule is now a distant memory as your developers will have to forego game night with their crew to stay and switch out the component. Now it gets worse. Not only are they probably pretty cranky, but they will have to find a secure piece of software that meets all of your standards, and pray that the rest of your product wasn’t dependant on that piece of bad code.
In any event, expect a lot of groaning from your team at having to repeat a lot of work over an easily preventable mistake.
Oh, and if you have been super lazy, holding off on getting visibility over your licenses and vulnerabilities until that M&A offer came in, then you are doubly screwed. Not only are you going to have to go into panic mode as your team scrambles to document every bit of code that ever went into your product, but any timelines set for the deal have just gone out the window.
Now go and tell your CEO to scuttle the deal while you take care of busy work from five years ago.
4. No Time to Waste for Critical Security Flaws
Speed is key when it comes to dealing with security vulnerabilities. Word spreads fast when an exploit is exposed and you’d better believe that hackers will be picking off the stragglers who were too slow to patch. While proprietary software can also be vulnerable, open source is far more so as they are widely used and cybercriminals will try to attack them at scale.
Since scanners are run intermittently (possibly months), chances are that you are missing critical vulnerabilities in between check ups. An even more dire situation is one where your company is running an on premises scanner that, unlike a SaaS-based product, has the added inconvenience of needing to receive updates from the mothership in order to learn about new vulnerabilities that it needs to be on the lookout for. This is hardly an enviable situation.
Your security solutions needs to keep pace with your development, providing continuous checks for flaws that could be exploited by the bad guys. Don’t lose valuable time waiting for your scanner to play catch up. The longer you wait, the more risk you are exposing your clients to.
5. Is the Juice Worth the Squeeze? — Determining Your ROI
Far from the plug and play solution that you’d hope it to be, open source scanning products take a fair amount of expensive time and talent to properly set up for your organization. Deploying your scanner means bringing in a specialist as a part of an expensive professional services package who will attempt to find that balance between uncovering all the open source components in your while not setting off a million false positives. These expenses of course go up significantly if you are working on premises and need some special customizations.
The costs continue to add up even after installation as the responsibility shifts to your own team. The task of sifting through the false positives can turn into a blackhole for your highly paid developers, whose efforts should be spent on more profitable endeavors. Furthermore, the delays in your production that we mentioned above due to the start-stop nature of the scanners means a drop in your team’s output, and less satisfaction from your customers.
Unfortunately, the costs for running a scanner solution can be prohibitive for many organizations that are unable to eat the high priced bill of lost time and human hours required to maintain it.
The Next Generation
If the reasons stated above are not enough to give you pause about deploying scanning for managing your open source code, then how about the fact that there is a better alternative out there?
Software Composition Analysis (SCA) is the latest generation of tools, providing answers to questions of security and licenses. Offering a much faster and cost effective solution that easily blends into a CI environment, it is constantly updating and checking for new vulnerabilities that could leave your company exposed.