The freely available nature of open source software and its high quality has antiquated the need for developers to create new code to deliver commonly required functionality
The days of creating software from scratch are over, as developers can concentrate on enhancing their specific applications; not reinventing them.
The popularity of open source among application developers is overwhelming, and still growing rapidly. According to OpenLogic’s 2022 State of Open Source Report, 77% of organisations were more reliant on open source software than they were 12 months ago. Their reliance on open source shows no signs of slowing, as the code’s presence in the unseen foundations of applications makes it an essential tool to support a developer’s native code.
This rapid adoption of open source by the software community has afforded immense time savings to developers who can now focus on adding value where it is needed most. But while the pace of innovation accelerates, security is often stuck in first gear. The increase in supply chain attacks targeting open-source packages is now exploiting this advancement without remorse.
The recent ‘peacenotwar’hacktivism incident is a great example of why the security of open source software should not be assumed. The exploit was the result of tampering with the nested dependencies of node-ipc by its designated maintainer to introduce ‘peacenotwar’. Using dependencies is a very normal part of the way open source applications and tools work, but one that can be exploited to bring vulnerabilities onto unsuspecting users’ machines.
Rather than assuming open source software is intrinsically secure, developers must be prepared to thoroughly research packages before using them.
The research process should include measurements and judgements around four metrics:
- The User Base:
Safety in numbers is an initial rule of thumb when judging the security of an open-source package. You would avoid eating in an empty restaurant, and the same goes for open source. A package with many users has a greater chance of being trustworthy than one without. The more eyes actively looking at the package, the more likely it becomes that vulnerabilities or malicious code will be spotted. Repositories record the number of downloads, alongside ratings from other users that can help guide your security evaluation. But note, high user volume does not always equal success and a valid research process goes beyond following the crowd.
- The Package’s Maintenance
A large user base also does not always mean that software is actively maintained. The more secure packages are the ones that not only have many watching eyes but users who participate in making sure its safety is kept up to date. It is not uncommon for the developers of a package to neglect maintenance once they’ve deemed a package as finished, turning it into a potential target for new vulnerabilities that its current state is not accounted for. The best way to understand the maintenance history of a package is to check the list of open issues. A lengthy list isn’t always a dealbreaker, but significant gaps in progress should raise questions.
- The Package’s Safety Record
Popularity and regular maintenance are certainly good early barometres of a secure open source package. However, the research process must dig deeper to ascertain the degree of risk its download carries. A well-maintained security database is a good source of information on a package’s vulnerabilities and any malicious code. Developers should also conduct background checks on the software’s release, being mindful of its name and the type of license it was released under. Multiple packages are often available to complete the required tasks, and comparing the degree of risk should be part of the package selection process.
- The Strength of the Package’s Community
A strong, healthy community is an asset for even the most polished and well-developed packages. Moreover, it is a great indicator of security and can validate that a large user base is actively invested in the project. Communities help to push the boundaries of the code they are built around, feeding back to its core developers, to ensure innovation continues. Developers interested in a package should check the number of contributors and commentators over time to gain confidence in the project’s credibility. Although again, not foolproof, a lively and devoted community is likely the byproduct of open source software that is secure and successful.
The security of open-source software can never be taken for granted, but developers can do their best to maximise their confidence in their selection. A thorough research process has become non-negotiable to mitigate the chances of introducing vulnerabilities and malicious code.
Supporting these research endeavours with the solution from Snyk, Snyk Advisor, should hopefully provide a great solution for many organisations. Through the application of these considerations, developers gain peace of mind that their final decision was an informed one.
About the Author
Daniel Berman is Product Marketing Director at Snyk. Snyk is the leader in developer security. We empower the world’s developers to build secure applications and equip security teams to meet the demands of the digital world. Our developer-first approach ensures organizations can secure all of the critical components of their applications from code to cloud, leading to increased developer productivity, revenue growth, customer satisfaction, cost savings and an overall improved security posture. Snyk is a Developer Security Platform that automatically integrates with a developer’s workflow and is purpose-built for security teams to collaborate with their development teams. Snyk is used by 1,200 customers worldwide today, including industry leaders such as Asurion, Google, Intuit, MongoDB, New Relic, Revolut and Salesforce.
Featured image: ©MH
