Open source software (OSS) is essential to almost all technology in use today. It enables developers to create capable, robust systems with agility and efficiency. And when used properly it is an exceptionally valuable resource. But it does have some potential risks. So we’ve worked with Intechnica, our technology due diligence partner, on some best practice guidance to minimise these risks:
- Inventory: make sure your tech team keep and regularly update a running list of what OSS is being used, where it is from, when it/ the library is updated.
- Usage policy: ensure your developers know what they can/ cannot use and how to evaluate whether a component is acceptable from a risk perspective, including factors like expected vulnerabilities and incompatible licences.
- Continuous integration practices: how do you monitor your tech, and how quickly can OSS components be updated if a vulnerability is found (whether internally or externally e.g. by attackers)? Design and update systems with sufficient redundancies, prioritising vulnerabilities that would have the highest impact to your business if exposed.
- Component quality culture: foster a development culture that treats OSS projects with constructive skepticism. As a starting point, it may be helpful having an open forum discussion on the relevance of each risk with your engineering team, and what controls exist (see risks below).
As convenient as OSS is, having a balanced understanding of what you’re about to integrate is essential. It can present a unique set of challenges that proprietary software won’t have. Below are some of the key risks to help highlight why it’s so important to integrate best practices within your OSS usage.
1: Insecure components
Having source code open and available for independent examination gives malicious code nowhere to hide. However, it also gives potential malicious entities all the information they might need to find weaknesses and exploit code already in use. OSS code is only secure when it’s being properly and regularly examined and updated. It is rare for OSS projects to be exploited. But if they are it could affect any number of systems that use it.
2: Licence management
If you don’t respect OSS licence terms you are vulnerable to legal challenge and risk being unable to use/ exploit anything you’ve built with the OSS. Some licences require any modifications to the OSS code to be republished under the same licence (share-alike), whilst some others prohibit modification entirely. [Some even require you to buy the author a beer (Beerware).]
3: Version management and oversight
OSS and libraries are subject to frequent change. The communities using them often collaborate to build new features and fix bugs, exploits and vulnerabilities, and these are usually widely disclosed. But it’s important to avoid relying on OSS that has been abandoned by its community. Out-of-date, neglected code is a common point of entry for attackers.
4: Developer malpractices
Effective integration of OSS into a system isn’t simply copying/ pasting code – doing so makes tracking changes almost impossible and issues or vulnerabilities even harder to pinpoint. Properly integrating OSS, via package managers or otherwise, makes critical updates easy to integrate.
Get in touch if you want to discuss how to integrate best practice into your business and ensure your team are fully aware of the implications around using OSS. You may want to consider an OSS risk assement with Intechnica. They work with businesses to increase enterprise value and reduce risk through the use of technology. In addition to assessing OSS risk, they also help businesses maximise the value of their technology investments through their CTO as a Service, roadmap creation, data science services and tech due diligence. To discuss an Open Source Risk Assessment or any of the above contact: more@intechnica.co.uk
You may also want to check out our Open Source 101 blog.
