A holistic strategy for the selection of open-source packages

Published in

syngenta-digitalblog

10 min readJul 16, 2024

Choosing the right open-source package is like finding the perfect puzzle piece; it ensures quality, security, and functionality fit seamlessly into your project. By comparing options, you ensure compatibility and meet your project’s unique needs.

Introductions

Selecting open-source packages in the JavaScript ecosystem can be challenging due to the overwhelming number of options, variability in quality, and concerns about maintenance, security, and compatibility. A common approach to selecting and using these packages ensures consistency and reliability by standardizing evaluation criteria.

This approach helps mitigate security risks, maintain high quality, and streamline the decision-making process. Additionally, it promotes maintainability, reduces technical debt, and aligns team efforts, leading to more efficient and effective development. Overall, a standardized method is essential for leveraging the benefits of open-source software while managing its inherent risks.

By evaluating factors such as community support, documentation, and license compliance, you can make informed decisions that enhance reliability and performance. This holistic approach minimizes risks and maximizes the benefits of using open-source software.

Why do we need to use an open-source packages ?

Please find below some points where these open-source packages can be useful.

Cost Efficiency - Open-source packages are free, reducing development costs significantly.
Community Support and Collaboration- Large, active communities provide support, resources, and collective expertise.
Flexibility and Customization- Access to source code allows for modifications to meet specific needs.
Rapid Innovation- Contributions from diverse developers lead to frequent updates and new features.
Transparency and Security- Open source allows for extensive peer review, enhancing security and reliability.
Avoiding Vendor Lock-In- Freedom to switch providers or modify software without restrictive licenses.

Then what is the risk if it has more advantages?

The JavaScript ecosystem is vast and rapidly evolving, with thousands of open-source packages available on platforms like npm. This abundance can make it challenging to identify the best package for your specific needs. I believe that if something is free, it will come with some hidden cost, or else the way we use it could lead to an anti-pattern or an overload on the project.

Security Vulnerabilities- Open-source packages can have undiscovered or unpatched vulnerabilities that expose applications to security risks.
Maintenance and support- Some open-source projects may become inactive, leading to a lack of updates and support over time.
Quality Variability- The quality of open-source packages can vary significantly, potentially affecting the performance and reliability of the software.
Compatibility Issues- Dependencies on other packages can lead to version conflicts and integration challenges.
Legal Risks- Licensing issues can arise, particularly with copyleft licenses that require sharing modifications under the same terms.
Community Reliance- Assuming community support and updates can be risky if the community is inactive or unresponsive.
Hidden Costs- While the software itself may be free, there can be hidden costs associated with integrating, maintaining, and securing open-source packages

Why do we really need a common approach or strategy when selecting or using an open-source package?

To understand this, we need to go through some past use cases where we found some security issues that impacted the business, security, and quality. In the past, we have encountered numerous instances, but we would like to specifically highlight four instances where we encountered security issues.

Event-Stream Incident- The event-stream package, widely used in Node.js projects, was compromised when a malicious actor took over its maintenance. The attacker injected malicious code targeting the copay-dash wallet to steal Bitcoin. This breach went unnoticed for a while, highlighting the risk of supply chain attacks in open-source ecosystems. The issue was resolved by identifying the malicious code, deprecating the compromised version, and advising users to update to a safe version
React-Scripts and Node-Forge- A critical prototype pollution vulnerability was discovered in the node-forge package, which affected react-scripts due to its dependency on webpack-dev-server. This vulnerability could allow attackers to manipulate object prototypes, leading to potential security breaches. The resolution involved running npm audit fix to automatically update dependencies to secure versions, demonstrating the importance of regular dependency audits and updates in maintaining security
Lodash Prototype Pollution- Lodash, a popular utility library in JavaScript, faced multiple prototype pollution vulnerabilities over the years. These vulnerabilities allowed attackers to modify the properties of object prototypes, potentially leading to arbitrary code execution. The maintainers responded by releasing patches, and users were advised to update to the latest versions. This incident underscores the importance of using well-maintained libraries and staying vigilant about applying security updates
Left-Pad Removal- The unexpected removal of the left-pad package from npm in 2016 caused widespread disruption, as many projects depended on it. This incident did not involve a security vulnerability but highlighted the fragility of relying on open-source packages maintained by individual contributors. The issue was resolved by npm restoring the package, and it prompted the community to reconsider dependency management practices and the resilience of their software stacks

These examples illustrate the various security and reliability challenges associated with using open-source packages. Regular audits, prompt updates, and mindful dependency management are essential practices for mitigating these risks in software development.

A Common approach or strategy — DVS

If we notice the above incidents, we can say that it is not a one-time activity; it is an ongoing process, necessitating a common approach, continuous intervention, or audit for the open-source code base we used.

When we attempted to comprehend the specific steps involved in creating a framework to mitigate security incidents or prevent risks associated with using open-source pages, we discovered that we could construct a process that would assist us in the development and maintenance of any project that utilized open-source packages.

We have divided the process into three sections, which we refer to as the Discovery, Validation, and Solution (DVS) process. Each step holds equal significance in the decision-making process.

Discovery — This step involves researching and identifying potential open-source packages that might meet your project’s needs.
Validation — This step involves verifying the quality, security, and suitability of the shortlisted packages.
Solution — This step involves implementing and testing the selected package to ensure it integrates well and meets project requirements.

Let us try to understand each step and the tools we can use while considering or working on that step.

Discovery

The first step is to determine the type of problem statement we are attempting to solve and whether using an external open-source package is necessary. Also, we need to find out how many options are available and which we can select. Technically, we can call this step research and evaluation.

Popularity and Maintenance

Check the package’s download statistics, GitHub stars, forks, and the frequency of commits. Ensure it is actively maintained and widely used.
If you have multiple options and need to compare them side by side, then I think https://npmtrends.com/ is the best tool we can use to get these statistics.
Stackshare: A community-driven platform that allows developers to discover and compare different tools, frameworks, and services, including JavaScript libraries and frameworks
Bundlephobia: A tool that analyzes the size of npm packages and their dependencies, helping developers make informed decisions about package selection.

Documentation and Community

Review the quality of the documentation, including the Readme file, API documentation, and examples. Assess the size and activity level of the community for support and contributions.

Compatibility and Dependencies

Ensure the package is compatible with your project’s environment and other dependencies. Evaluate the package’s dependencies to avoid potential conflicts or bloat.
Dependencies generally fall into two main categories: dependencies and devDependencies.
What is the devDependencies?
These are packages required only during the development and testing phases. They are not necessary for the application to run in production.
Installation Command: Installed using npm install <package> --save-devor yarn add <package> --dev
What is dependencies?
These are the packages required for the application to run. They are essential for the code that runs in production.
Installation Command: Installed using npm install <package> --saveor yarn add <package>
Now, let’s examine the impact of these factors on our application.
Production Build Size: Keeping unnecessary packages out of the production build reduces its size, leading to faster deployment times and lower hosting costs.
Security: Fewer packages in production means a smaller attack surface, reducing the risk of vulnerability.
Performance: By including only the necessary packages in production, you ensure that your application runs efficiently without the overhead of development tools.

Validation

When selecting open-source packages, security and quality audits or validations are essential.
These processes are essential for identifying and mitigating potential security vulnerabilities that could expose applications to exploitation or data breaches.
For instance, audits can uncover issues like prototype pollution in Lodash or malicious code injections, as seen in the event-stream incident.
By conducting thorough audits, developers can ensure that selected packages meet stringent quality standards, minimizing the risk of bugs, crashes, or unreliable performance.
Furthermore, audits help verify compliance with licensing requirements, safeguarding against legal implications stemming from non-compliant software usage.
Choosing well-audited packages also supports long-term stability by ensuring active maintenance and timely updates, which are crucial for adapting to evolving security threats and maintaining compatibility with modern technologies.
Ultimately, investing in security and quality audits upfront enhances development efficiency by pre-emptively addressing potential issues and reducing the need for extensive troubleshooting and rework later in the software lifecycle.

Security Vulnerabilities

Use tools like npm audit or yarn audit to check for known vulnerabilities. Review the package’s history of addressing security issues.

Code Quality and Testing

Examine the codebase for coding standards, readability, and the presence of tests. Check if the package includes comprehensive unit tests and continuous integration practices.

Solution

These phases allow developers to evaluate functionality, assess compatibility, measure performance, uncover security issues, validate documentation, and gauge user support. This thorough evaluation ensures that the chosen package meets project requirements effectively and integrates seamlessly into existing systems, minimizing risks, and optimizing long-term success.
Use package-lock files to lock dependencies to specific versions, minimizing the risk of inadvertently introducing vulnerabilities through updates.

Initial Testing

Create a small test project or a sandbox environment to experiment with the package. Evaluate its functionality, performance, and ease of integration.

Performance and Scalability

Assess the package’s impact on your project’s performance and scalability. Ensure it meets your project’s requirements without introducing bottlenecks.

Feedback and Decision

Gather feedback from your team or stakeholders based on the trial and evaluation. Make an informed decision considering all factors, including long-term maintenance and support.

How do we manage Decision Records for open-source package selections?

After going through the DVS(Discovery, Validation, Solution) process and selecting a specific package, you can gather all the necessary inputs and supplement them with relevant documentation.

Let me clarify: if you are choosing a package from a range of options based on specific criteria and fulfilling your needs,

However, future developments are unpredictable, and certain organizations may have their own procedures for utilizing open-source packages, necessitating the provision of specific information to facilitate decision-making. I think for this scenario, you can use an architect decision record document template.

You can find comprehensive documentation, sample templates, and examples in this GitHub repository(architecture-decision-record).

How can we determine whether a project is not using a npm dependency?

Depcheck is a tool for analyzing the dependencies in a project to see: how each dependency is used, which dependencies are useless, and which dependencies are missing from package.json.

Example — Please refer to the npx depcheckresult of the snapshot for one of the projects provided below.