DevSecOps work safely with open source despite open source components
From code to software packages and libraries to entire applications: open source is an important factor for the thriving developer market. But how can you really work safely with – and maybe even thanks to – generally accessible code.
Only since the use of open source, modern applications can be created, refined and maintained at a really high pace. The days when developers had to create new code to program everyday functions are long gone. Instead, you can use the insights of great thought leaders and focus on providing new features and functions of your own applications.
Open source is now used by application developers almost nationwide. According to Gartner, 96 percent of all applications contain open source packages. They form a massive, invisible foundation that lies under the applications and supports the native code of the developers.
Gartner’s open source analysis concludes that four-fifths of the source code of all applications is based on open source. This possibility of developing faster and not having to reinvent the wheel is an immense advantage. But with this opportunity comes a great responsibility.
In recent years, cybercriminals have increasingly attacked supply chains, particularly targeting open source packages. The attackers had joined existing projects and changed the code contained in them or created new variants of already existing packages. These gave the appearance of being the latest version, but in reality contained malicious code.
These types of attacks have recently proven to be relatively simple and at the same time highly effective. Many open source packages are updated almost daily and uploaded to repositories such as NPM, RubyGems and PyPI – usually with few or no security checks. These packages are then downloaded millions of times by developers, who also only perform a poor security check.
A good example of this is the Event Stream incident in 2018. A cybercriminal pretended to be an enthusiastic and capable new employee of event stream, a respected and useful low-level utility that went into maintenance mode in 2015. It didn’t take long for the attacker to gain the editing and access rights.
In the first instance, he added a new, initially harmless component to the package. However, he updated it the following month with a new version that contained malicious code. This very package was downloaded by millions of developers – however, it took over a month for someone to notice the malicious content.
The inserted code targeted the developers of a single company that provides a Bitcoin wallet application. He should intercept the data of the end users. But of course, it could also have included other, more general applications such as ransomware or other ways to steal data.
The consequence of this and many similar attacks is that developers can no longer take open source packages at face value. In the past, the 20 percent of internally developed application codes were subject to stronger security checks than open source code. It was assumed that open source packages are inherently more trustworthy.
Nowadays, we know that this was an unwise assumption and developers should thoroughly investigate open source packages before using them. The investigation should focus on four key issues:
1. Who uses it?
A package used by different developers is potentially more trustworthy than one with only a few users. A higher popularity also suggests that a package performs its tasks effectively. The more people actively deal with the package, the more likely it is that vulnerabilities or newly added malicious code will be discovered.
Repositories record the number of downloads, as well as ratings, splits, dependencies and other indicators of success. However, popularity alone – as the event stream incident also showed – is not yet the silver bullet.
2. Is it serviced regularly?
Some packages are popular, but they are not regularly maintained. Instead, they were eventually classified as “finished” or the developers involved lost interest. The alarm bells should be ringing here. If developers encounter problems with this package in a business-critical application, no one can help them. In addition, you can not be sure that the package is compatible with modern components or has developed vulnerabilities over time.
A package should have a regular update flow throughout its lifetime. Developers should check the list of open issues and pull requests. These do not always indicate a weak point in a very active project; but significant gaps in the course deserve a closer look.
3. Is it safe to use?
Popularity and regular maintenance give a certain basic security, but the potential risk contained in an application should also be evaluated. It is not always easy to determine whether a package contains security vulnerabilities or even malicious code.
Developers very often have to choose between different packages. Of course, you should choose the package that carries the least risk with the desired functionality. At the same time, you should use the least vulnerable version of this package, which does not necessarily have to be the latest. A well-maintained database contains information about exactly these vulnerabilities. Parts of the test can also be taken over by automation.
However, security alone does not protect against every risk. Each open source component comes with a license that describes how it may be used. Many well-known companies did not comply with licensing regulations and therefore had to accept fines and other sanctions. Developers should research the name and type of license under which the software was released and make sure that their own application or company policies do not contradict compliance.
4. How strong is the community behind the package?
For most open source packages, the responsibility for creating and maintaining the code lies with a small core team. But users also play an important role when it comes to optimizing a project. They help by expressing feature requests, reporting bugs and providing feedback on the roadmap.
The stronger the community, the more dynamic and secure a package is. In addition, it acquires new and improved functions and features over time. A strong, dedicated community is also likely to develop tools that will facilitate the use of the package, thus simplifying the life of developers. The number of contributors over the entire life cycle of the package is an important indicator of the trustworthiness of a project.
With a thorough and critical preliminary check of the points described above, it is possible to program in the selection of open source packages with the confidence that the basic application elements provide solid and, above all, secure support.
Of course, this represents a certain additional effort. However, functional web-based databases such as the Snyk Advisor can reduce this so that the required information is available as quickly as in a Google search. The peace of mind achieved in this way and the avoided security incidents make the research effort very worthwhile.
* Daniel Berman is Product Marketing Director at Snyk.
