Aqua Blog

The Gaps in Open Source Governance That Threaten the Software Supply Chain

The Gaps in Open Source Governance That Threaten the Software Supply Chain

The widespread issue of unmaintained and deprecated npm packages recently discovered by Aqua researchers affects more than a fifth of open source packages. Presenting yet another silent example of hidden threats to the software supply chain, it demonstrates how poor operational and structural integrity of dependencies can be just as risky as code vulnerabilities, while masking their existence from developers.

In order to maintain application integrity, organizations must be proactive in understanding the provenance of every piece of code and instill practices to ensure that poorly maintained and risky code isn’t introduced into their applications.

In this blog, we describe how Aqua’s Software Supply Chain Security (SSCS) module enables developers to choose packages based on their security health, providing a way for security operations leaders to effectively maintain healthy applications by prioritizing the update of components when they become deprecated.

Understanding the Risks

Trust in open source software is built on the transparency and reliability of its maintainers, making it a vital factor in dependency management. It’s not just about the code — it’s about the people who craft and curate it, their approach to updates, and their vigilance against potential threats. This human aspect is an often overlooked but essential component of any robust security strategy in open source ecosystems.

As organizations strive to prevent attacks by minimizing the attack surface with vulnerability management, leaders already recognize that accurately assessing risk can’t be done based on CVE score alone. Understanding the risks associated with open-source dependencies should extend beyond the analysis of known CVEs, to include a comprehensive assessment of the package maintainers and their practices. It’s crucial to examine the maintenance practices of these individuals or teams, their open source projects, and their commitment to security best practices.

The real-world implications of neglecting those risks can be profound.  We can recall the notorious incident when the maintainer of a popular package was compromised, and the package was swapped with a malicious version. Similarly, the widespread campaigns that created malicious mimic packages and trusted maintainers going rogue provide more evidence of the danger security teams must defend against.

More recently, the infamous “everything” package incident showcased the potential for policy manipulation to cause widespread disruption. These risks not only highlight the fragility of dependency management systems but also stress the imperative for comprehensive solutions to safeguard against such risks, ensuring a secure and reliable open source ecosystem.

Determining Open Source Health

The Aqua platform delivers an analysis of open source components during development that evaluates the overall OSS project health, including when dependency changes were introduced. To scale and simplify enterprise open source risk management, Aqua maintains an intelligent asset inventory that monitors for license status and behavioral changes so teams can adopt a proactive risk based approach to remediation work.

Users can evaluate their open source dependencies through a comprehensive lens, across three categories: security, quality, and licensing.

  1. Security: Assess the security aspects of open source dependencies and the way you consume it is paramount to identify risks that could compromise your project, such as abnormal release of 3rd party package that is automatically pulled without pined the version
  2. Quality: Examine metrics of the open source package including maintainability, documentation, tracking back the author and the source code, in order to gauge the reliability and ease of use of a package.
  3. Licensing: Understand and follow the licensing terms in order to ensure they do not change throughout the SDLC, preventing potential violations and ensuring compliance with licensing obligations.

Dependencies

We can also take a deeper look at one of the dependencies to understand the different rankings, shown below:

dependencies to understand the different rankings

When we conducted SCA (software composition analysis) of the package above, we discovered:

  • The package was tagged as deprecated, which means it is unmaintained code that might have vulnerabilities and security flaws that are not addressed.
  • Unpinned dependencies in the package create further risks, as they can lead to the automatic integration of unverified updates that might contain malicious versions.
  • The notification of inactivity suggests potential neglect, while a sudden resurgence in activity could indicate unauthorized access or changes by a malicious actor.

These indicators collectively highlight the layered complexities and the necessity for a proactive approach to managing open source dependencies.

Security analysis, while necessary, may not be sufficient, as there are other aspects to assess such as license compliance and overall quality of the software. These elements are equally vital to ensure the integrity and legal soundness of a project:

 license compliance

This package has a license that has recently changed, which might introduce compatibility issues with the licensing policies of its dependent projects. Additionally, the absence of a repository link obscures the package’s development history, raising serious concerns about the quality and security of the software. It underscores the importance of a thorough and multifaceted approach to dependency management to maintain a secure and legally compliant software environment.

After understanding the various issues of a given package, you can easily review where this specific dependency lives across your code repositories, listed as Instances below

dependency across code repositories,

You can then define custom enforcement policies tailored to their specific requirements. Whether it’s restricting outdated packages, preventing the use of dependencies with known vulnerabilities, or enforcing licensing compliance, Aqua provides granular control over the inclusion of OSS packages in your codebase.

These policies can be used to generate alerts to developers, but also in stricter environments Aqua can prevent the use of code that violates these policies by stopping pull requests (PRs), image builds, or other CI/CD steps.

custom enforcement policies

Conclusion

The risks in poorly governed developer environments and software supply chain go well beyond those that can be found by scanning code, such as vulnerabilities and exposed secrets. Open source dependencies mean that risks can be inherited from badly maintained, deprecated, or compromised code that lies one or several steps up the supply chain.

With contextual insights into the quality and provenance of open source packages, enforceable CI/CD security, customizable policies, and real-time intervention, Aqua’s SSCS offers security teams a holistic approach to maintaining secure coding practices, both by informing developers of risks as they are uncovered, as well as enforcing preventive policies where needed.

Mor Weinberger
Mor is a Staff Software Engineer at Aqua Security. With vast experience in analyzing cloud native security and supply chain threats. Mor regularly uncovers emerging threats such as unsecured environments and cryptomining campaigns. Mor was part of the Argon Security team acquired by Aqua in 2021. Today, he focuses on developing innovative CNAPP projects
Naor Talmor
Naor Talmor is a Security Product Manager at Aqua. He leads the Supply Chain Security vector, blending technical depth from engineering, management roles, and customers understanding. A key player since the early days at Argon Security, acquired by Aqua in 2021, he thrive on turning creative ideas into reality.