How to work securely with open source

Four questions to ask before you use an open source library

The availability of open source code, applications, packages and libraries is undoubtedly one of the most important contributors to today's flourishing development ecosystem. It's an essential ingredient for the intense pace with which modern applications are created, polished and maintained. Gone are the days when developers had to create new code to deliver commonly required functionality. Now, instead, they can stand on the shoulders of giants, and concentrate on delivering the new features and functions of their specific applications.

The use of open source has become almost universal among application developers in recent years. In fact, according to Gartner, 96 per cent of all applications contain open source packages. And it makes up the massive unseen foundations that lie beneath applications, propping up the developers' native code: Gartner's analysis concludes that 80 per cent of application source code across the board is open source.

This power to create faster and avoid reinventing the wheel to accomplish anything is undoubtedly an immense benefit. But with that power comes considerable responsibility.

The last few years have seen a considerable increase in supply chain attacks by cybercriminals targeting popular open source packages: cybercriminals have joined existing projects and altered their code, or created new variations on existing packages that appear to be the latest version but actually contain malicious code.

It's proven a relatively easy and highly effective vector for attacks. Many open source packages are updated almost daily, and uploaded to repositories like npm, RubyGems and PyPi with few, if any, security checks. In turn, those packages might be downloaded millions of times by developers with a similar lack of scrutiny.

See also: Open source dev sabotages own library to target Russian and Belarusian users

The event-stream incident in 2018 provides a great example. A cybercriminal posed as an enthusiastic and able new contributor to event-stream, a well-regarded and useful low-level utility, which had entered maintenance mode in 2015. Before long, the bad actor was able to obtain editing and publishing rights. The attacker added a new, harmless component to the package, but then, the following month, updated that component with a new version containing malicious code.

The affected package was downloaded by millions of developers — but it took over a month before anyone noticed the malicious content. The added code was hyper-targeted at a single company, the developers of a bitcoin wallet application, and designed to capture end-user's details. But obviously, it might have contained other, more generally targeted payloads, like ransomware or other data-breach enablers.

The consequence of this, and many similar attacks, is that developers cannot take open source packages at face value any more. Historically, far more security scrutiny has been given to the 20 per cent of the application code that is developed in-house. Open source packages were assumed to be intrinsically more trustworthy. Now, that's an unwise assumption to make, and developers should be prepared to thoroughly research open source packages before using them.

This research process should focus on four key questions:

1. Who else is using it?
   There's some safety in numbers. A package that's widely used by many different developers has a greater chance of being trustworthy than one with a few users. It's also more likely to be effective at its job, and popularity also means that more people are actively looking at the package, so any vulnerabilities or the addition of malicious code is more likely to be spotted. Repositories will record the number of downloads, alongside star-ratings, forks, dependencies and other indicators of success. Popularity isn't a silver bullet, though - as evidenced by the event-stream case.
2. Is it well-maintained?
   Some packages are popular but not actively maintained. At some point, it was either judged to be ‘finished' or the core developers involved lost interest. This raises a couple of red flags. If you hit problems with the package in a business-critical application, who is there to help you? The answer may be nobody. Second, how can you be sure of its compatibility with more modern components or know whether vulnerabilities have developed over time? Again, the answer is that you probably can't. Look for a regular flow of commits over the package's lifetime; check the list of open issues and pull requests — this isn't always a red flag for a very active project, but significant gaps in progress deserve scrutiny.
3. Is it safe to use?
   Popularity and a regular program of maintenance can provide some reassurance, but a third consideration is whether a package introduces more risk into your application. It's not always straightforward to establish whether a package contains any vulnerabilities or even malicious code. Very often there are choices between different packages to be made and, of course, developers should seek the package that introduces the least risk to achieve the functionality required, and ensure they use the least vulnerable version of that package, which may not be the most recent. Use a well-maintained database to obtain information on these vulnerabilities, potentially seeking some automation of these checks.
   Then, risk doesn't end with security. Every open source component comes with a licence describing how it can be used. Many high-profile companies have fallen foul of licence compliance requirements and suffered from fines and other penalties as a result. Developers should research the name and type of the licence under which the software has been released, and of course ensure their own application, or their company policies, don't put them at risk of non-compliance.
4. How strong is the package's community?
   For most open source projects, a small core team is responsible for writing and maintaining the code. But the community of users also play a key role in terms of driving the project forward through feature requests, reporting bugs and providing feedback on the roadmap. A package with a strong community is more likely to be healthy and dynamic, introducing and improving functionality and performance over time. A strong, vibrant community is also likely to produce tools that make it easier to use the package, making your life easier as a consequence. Check the number of contributors and their number over time to gain confidence in the project's health.

With this degree of rigour in the selection of open source packages, it becomes much easier to code with real confidence that the foundational elements of an application will give solid, secure support. It does introduce some extra overhead, of course, but there are very functional web-based databases that can supply the necessary information as quickly as a Google Search.

Daniel Berman is product marketing director at Snyk