How Security Scanning Tools Handle Forked Packages in End-of-Life Projects

At HeroDevs, we specialize in extending the lifecycle of end-of-life open-source projects. Through HeroDevs security research, compatibility tests, and vulnerability patches we provide our customers with secure, maintained versions, ensuring they can safely continue using software that would otherwise be at risk. However, this work comes with a unique challenge: how do security scanning tools respond to our unique, non-public versions? Can they recognize that packages like @neverendingsupport/angularjs originate from discontinued projects, and can they distinguish between resolved vulnerabilities and ongoing risks?

In this article, we analyze how popular security tools—including Snyk Open Source, SonarCloud, Aikido, and Jit—handle forked packages. We will also explore different tool methodologies, such as Static Application Security Testing (SAST) and Software Composition Analysis (SCA), to better understand their capabilities and limitations when analyzing forked versions of packages.. HeroDevs packages are installed under npm aliases to ensure that users don't need to modify their source code. As part of our evaluation, we assess how security scanners react to this approach.  Specifically, we assess their ability to trace forks back to the original projects and assess security within the context of each project’s patching history.

Experiment Setup

To explore this, we created a JavaScript project titled "how-scanners-react-to-hd-packages". In the project, we included the latest Herodevs version of AngularJS as a dependency—one we’ve patched to address all known vulnerabilities—and observed how different scanners responded. Below is the package.json setup:

{
  "name": "how-scanners-react-to-hd-packages",
  "version": "1.0.0",
  "description": "A repository to track how security scanners react to herodevs forked packages",
  "scripts": {
    "start": "http-server .",
    "postinstall": "node snyk.js"
  },
  "license": "ISC",
  "dependencies": {
    "angular": "npm:@neverendingsupport/angularjs@1.8.3-trial"
  },
  "devDependencies": {
      "http-server": "^14.1.1"
  }
}

Identifying Fork Origins

A key aspect of analyzing forked packages is determining whether security tools can recognize the origin package. For example, can they detect @neverendingsupport/angularjs as a derivative of the original AngularJS project and account for the original project’s vulnerability history?

Snyk Open Source

In our test, Snyk Open Source displayed mixed results. It partially recognized the origin of the fork and correlated vulnerabilities from the source package. However, it identified @neverendingsupport/angularjs as "Angular 1.9.7"—a version that doesn’t exist in the official AngularJS release. This error occurred because Snyk does not currently support npm aliases, which led to incorrect reporting of vulnerabilities based on the latest public version of AngularJS.

Even when run in CI, Snyk struggled to correctly identify the package origin. Although Snyk offers a .snyk configuration file to suppress specific CVEs, it only checks for this file in the project’s root directory, not within individual packages. Therefore, users relying on Snyk with our Angular fork must manually configure the .snyk file to avoid false-positive reports.

SonarCloud

‍Running SonarCloud on our project returned no detected vulnerabilities. However, it’s unclear whether this result was due to an inability to interpret the forked package or an understanding that vulnerabilities had been addressed. Testing an earlier forked version (1.8.3), SonarCloud again reported no vulnerabilities, suggesting that it treats @neverendingsupport/angularjs as an entirely new package without linking it back to AngularJS. Even after running the scan in CI post-dependency installation, SonarCloud could not effectively analyze the package. Unlike Snyk, which is a SCA tool, SonarCloud performs SAST, and we expected that a SAST tool would still be able to detect vulnerabilities within the source code, even if it couldn't trace the package back to its original version.

Aikido Security

Aikido (SAST) behaved similarly to SonarCloud in this scenario, showing no vulnerabilities and seemingly not recognizing the fork’s origin.

Jit Security

Jit Security, which performs  both SCA and SAST analysis, followed a similar pattern as SonarCloud and Aikido. Although Jit provides integration support for private npm packages, it couldn’t interpret our setup as we use a private registry. This limitation led to the tool not being able to analyze the forked package effectively, similar to the behavior we observed with SonarCloud.

Limitations and Challenges in Private Registry Support

We observed that current security tools lack straightforward configuration options for private packages hosted in private registries. This limitation affects our ability to integrate forks effectively and results in inconsistent vulnerability reports. Often, scanners only check CVEs associated with a known package without performing deeper analysis of the code itself. As a result, they miss potential vulnerabilities or misclassify patched versions of our packages. This reliance on CVE-based checks without code analysis complicates the detection of vulnerabilities in our forks and patches. Improved configurability in security tools for private registries, along with a more thorough code analysis, would better support our use case, allowing for more accurate tracking and reporting.

What to do when your scanner doesn't recognize HD package

When a security scanner doesn't recognize a HeroDevs package, there are a few strategies you can employ to ensure your package is still accurately assessed:

1. Use Overrides
   Many security tools allow users to apply overrides for specific vulnerabilities or configurations. This is useful when the scanner misinterprets your package or doesn't recognize it properly. For example, Snyk allows you to add a .snyk file in your project’s root directory to suppress false positives. In addition, you can manually configure the tool to map your fork to the correct source package. Always check the documentation of your security tool for specific instructions on applying these overrides.
2. Letter of Attestation
   If you need a more formal solution, HeroDevs can issue a Letter of Attestation. This document serves as an official declaration that your dependency is secure and that you've addressed any known vulnerabilities. It’s particularly useful in regulated environments or when dealing with stakeholders who require additional assurance.
3. Reach Out to Your Scanning Partner
   It’s a good idea to contact your scanning provider directly. Let them know that the ability to recognize forked packages and correctly analyze them is critical for your workflows. Some tools may not have full support for private packages or npm aliases, and raising awareness can sometimes prompt improvements or offer you custom solutions to enhance tool compatibility.

Conclusion

Selecting a security tool for end-of-life forks requires weighing the benefits of historical vulnerability tracking against accurate, current-state analysis. For teams using HeroDevs packages, it’s essential to understand each tool’s strengths and limitations to achieve a realistic security overview. Improved private registry support and alias recognition would significantly enhance these tools’ effectiveness for projects like ours.