Opensource: The devil is in the backdooring

While there have been some notable deficiencies in using opensource software in recent years, Ilia Kolochenko, Chief Architect of ImmuniWeb is not in a hurry to bin off the utopia of code altogether. Johanna Hamilton AMBCS reports.

Betamax or VHS? Android or iOS? Enterprise software or opensource? Deciding the good over the bad is an ongoing battle and each really depends on preference.

I have an iPhone and will probably stay with it, but I also know many security professionals who for many good reasons are android only – they can probably argue for hours advocating or criticising both choices – but really it’s something that needs to be considered on a case by case basis.

Opensource is an ever green subject. It’ is not good and it is not bad, opensource is to be considered through the prism of your practical needs. Sometimes opensource is the best way to go if you’re building systems – but in an enterprise environment, where you have to comply with different regulations and diverging laws, for example, in the financial industry, I would be cautious about using opensource.

Is opensource risky and why?

While there are well-known cybersecurity, privacy and compliance risks, one should also bear in mind legal risks, such as unknowingly infringing someone's intellectual property rights, when there is no central management of opensource within your organisation. Otherwise, I would not say that opensource is riskier than proprietary enterprise software.

Could developers unwittingly be infringing code copyright?

An opensource software licence may state that you must always disclose the source code of your own software built on top of it. You may be even permitted to freely commercialise your software or provide a premium support for it, but you may be required to always keep it opensource in parallel.

Thus, opensource is accompanied with legal risks in terms of intellectual property infringement that may lead to multi-million dollar lawsuits and concomitant legal ramifications. Therefore, it’s a good idea to implement a process to verify who and how opensource is used within your organisation, paying special attention to licensing.

Likewise, pay attention to privacy: some opensource projects may silently send data of your users, or other statistics, to third-party systems thereby violating various privacy and data protection laws. Careless usage of untrusted opensource may cost you your reputation and deplete your budget with an eight-digit fine.

Another set of legal risks stems from widespread disclaimers of warranties and no contractual liability of opensource developers. The opensource is usually provided ‘as is’ without any warranty of any kind, though some projects may have a paid support and even some SLAs related to code quality for their paying customers. But generally, if something goes wrong, you will probably have no legal recourse.

Worse, you will likely also be liable to your own customers who suffered collateral damage, such as downtime of your systems with their data, because of the opensource failure. So, legally speaking, opensource may be problematic.

Of note, enterprise vendors also commonly try to contractually disclaim all imaginable liabilities, but there, at least, you have a chance to properly frame your contract. It’s always a good idea to ask your lawyers to scrutinise your software and SaaS contracts.

So, what is the best thing about opensource?

Opensource can provide a lot of flexibility, simplify and accelerate your SDLC. Oftentimes, you may swiftly build and improve your own products without being curbed by third-party obligations or requirements to interact with external vendors.

Contrariwise, large enterprise vendors like Oracle, may even prescribe a contractual right to come into your offices and inspect your systems for potential violation of license agreement. This is not to mention how long it will take if you need to customise their product.

Opensource or paid-for software?

Choosing opensource over enterprise proprietary solutions is really to be decided on a case by case basis, considering a wide spectrum of business and technical aspects.

Both opensource and proprietary software may have countless critical vulnerabilities, some of them being dormant during years, eventually leading to disastrous domino-effect data breaches among the end-users. How you, or your vendor, test the software – also plays a crucial role. Patch testing and management is likewise essential, while there is no binary division: both opensource and proprietary projects may serve a laudable example to everyone else in the industry.

You should, first of all, trust the vendor and make sure that its approach to software development and support are compatible with your risk appetite, cybersecurity strategy, processes and procedures. Incorporating mandatory security testing into your policies or your vendor’s contractual duties, encompassing specific standards and methodologies of testing for every new release, may significantly reduce your risks regardless whether the software is opensource or not.

What checks can be done to make sure it’s fit for purpose?

Opensource is publicly accessible and so, in theory, anyone can audit it. Many advocates of opensource emphasise that the latter is open and public, hence anyone can inspect the code to make sure that there are no vulnerabilities or backdoors. And while, technically speaking, that’s true, the reality is that very few cybersecurity experts will ever comprehensively check the code, because financial and other incentives are weak.

We do have some emerging bug bounty programs, sponsored by governments or companies like Google, paying for vulnerabilities in opensource projects, but pay-outs are comparatively modest.

Likewise, money is not something that will strongly incentivise knowledgeable cybersecurity experts to rush to auditing. It may be a motivator for beginners, who also strive to have an impressive CV, so they might proudly say, ‘I found a critical remote code execution vulnerability in one of the most popular pieces of opensource software.’

But, in reality, when you’re dealing with tens of millions of lines of code, no one is going to look at all of them. Let alone endless flow of updates and new versions that frequently contain even more vulnerabilities. So, being accessible to everyone does not mean being proof-tested or secure.

Does there need to be an alternative to opensource?

The enterprise proprietary software is a sound alternative to opensource that creates an equilibrium on the software market. It is, however, important to carefully select your software stack, taking into consideration your budget, business needs and security requirements.

Analysis of applicable data protection and privacy legislation will absolve you from innumerable troubles in the future. Frequently, different corporate systems may require a completely different set of software, oftentimes, mixing both opensource and proprietary solutions. Thus, software diversity may be the best way to go.

Will AI find the ‘bad’ code?

I'd say yes, but it will also miss something. For instance, if a skilled attacker stealthily inserts a purposely vulnerable code into an opensource project, automated scanning, with AI or without, will quite unlikely spot this. It may take many hours of manual scrutiny by security experts to ferret out the vulnerability hiding amid a complex update.

It is not impossible to hypothesise that we have several major opensource projects that contain exploitable security vulnerabilities since years, silently introduced by advanced threat actors to exploit them in sophisticated supply chain attacks.

AI may accelerate detection of vulnerabilities, spot supplementary weaknesses and flaws in the code, as well as provide other enhancements compared to traditional scanning software, but as of today, it still cannot replace a qualified human expert.

Do you think The Software Bill Of Materials will stop people picking up the wrong type of opensource?

It may definitely help, but it will unlikely be a panacea. For instance, we may have a specific policy whitelisting opensource projects and versions that your developers are authorised to use.

But this will not completely mitigate the risks: we saw numerous popular and regularly audited opensource projects falling victim to cybercriminals, who aptly injected malware into the code without being detected for a while. Some of such findings remained undetected for weeks or even months before being discovered.

We should also consider collateral risks, which are not necessarily directly related to opensource. For example, one of the non-technical threats is software package or libraries name squatting. This is when attackers choose repository names that are very close to the legitimate name to fool software developers into installing backdoored versions instead of the legitimate ones.

An innocent typo by a software engineer may ruin all your technical efforts. Integrity checks and other preventive security controls can undoubtedly help, but few developers use them by default. A multi-layered security defence, or what we also call defence-in-depth, would probably be the best answer to the growing quantity and sophistication of cyber-attacks.

Is security getting better off the back of opensource fears?

I remain pretty optimistic about the future. I think, the catastrophic cyber-attacks that we witnessed in 2021 and 2022 will serve us a valuable lesson. More organisations are currently implementing multi-layered cyber-defence, making it a continuous process, incorporated at all levels of the organisation.

Boards start caring about cybersecurity, making it an integral part of their corporate growth strategy. Opensource security is, of course, an inalienable part of cyber resilience: many enterprises are finally starting to taking it seriously. Read Full Article