Using open source, eyes wide shut
After flying an F-14 against the bogeys, a brief stunt as a vampire, and just before the first “Mission Impossible“, Tom Cruise took part in Stanley Kubrick’s farewell masterpiece “Eyes Wide Shut“. To summarize, the plot is about married life, unfulfilled R-rated dreams and Kubrick’s perpetual dislike of the capitalist West.
The orgies depicted in “Eyes Wide Shut” are akin to the present R-rated open-source environment. But it wasn’t always like that.
Back in the 1960s, the original PG-13 concept of open-source development was about unrestricted academic collaboration, potentially funded by universities, the government, big corporations, or all of them combined. Then the corporations reminded everyone about their license agreements and forced everyone to pay up.
Along came Linus Torvalds and his co-conspirators. Developers of the world united to give their best for the public benefit, while teaming with other amazing individuals and earning very tangible Karma points in the process. The floodgate of innovation was unleashed, and the money-printing machines of Oracle, IBM etc. were seriously threatened. Stanley Kubrick would be proud!
Nowadays, companies and governments use open-source code because it allows them to build their solutions using highly functional and reasonably well-validated code entirely for free. Neither CapEx, nor OpEx. Smells like… victory!
Unfortunately, good open-source intentions lead to security landmines, both malicious and accidental, and the quicksand of potential licensing liabilities. To make it worse, you are actually dealing with a dreaded cascade of open-source dependencies, each with its potential host of security and licensing problems.
Open-source licensing mistakes can grow into a major legal headache, requiring significant changes in an already-built system. Imagine being forced to replace React with Vue on a galloping horse or publish the hard-earned IP.
Security vulnerabilities are being continuously discovered and then usually patched. Failure to apply these patches expeditiously may be really bad for your reputation, users and/or wallet. At the same time, open-source development never sleeps, with major releases often coming out every six months. After each such release, the previous one loses community attention, and security patches are no longer produced for it. Backward compatibility suffers too, by the way. In that race something’s got to give.
In Kubrick’s movie, Tom Cruise kept trying to figure out what was happening to him with his eyes wide shut – unsuccessfully so, and to a certain detriment to his mental health. Nicole Kidman was much more pragmatic and suggested to be grateful for the experience and …enjoy life.
As it applies to open source, I kind of agree with Nicole, and would like to mention a few ways to try to dream safely:
- Follow a method of doing upgrades on the odd/even basis – skip “odd” releases and upgrade to “even” releases in order to stretch the support cycle. This should definitely create some breathing space for the team.
- Start using enterprise versions of the open-source software. For example, MariaDB Enterprise instead of Community; and CloudBees instead of Jenkins. The “enterprise” versions offer backward compatibility and extended support of previous versions, plus a lot of complementary features. This means you can delay your upgrades and associated expense for a couple of years without exposing yourself to security risks.
- The value proposition of integrity tools like Snyk, BlackDuck, Mend and Threatrix comes from their ability to track and expose dependencies, allowing them to alert the user to the dangers. From this list, I am heavily biased towards Threatrix because they track both licensing and vulnerabilities, connect directly to the pipeline, and are very fairly priced.
- Generally, establish a Risk Management Framework process you can trust yourself with.
A few useful links: