As part of FOSSA's security offering, we also provide insight into your software supply chain resiliency through what we call "supply chain risk" signals. While supply chain risk issues do not necessarily mean that there is a vulnerability, they do offer insight into potential exposure or the likelihood of unknown vulnerabilities, reliability of the underlying dependency, to even the confidence you can have about the reproducibility of a build that relies on a particular dependency.

Abandonware

Abandonware refers to packages that have not seen any maintainer activity (i.e. publishing) for long period of time, in the case of FOSSA we set this window to 2 years.

Why is Abandonware a Useful Supply Chain Risk Signal?

While a package being abandoned does not necessarily mean that there is a known vulnerability, it does pose a risk if a known vulnerability is published because a patch is unlikely to be published. The same can be said for bugs within the package - they're unlikely to ever be resolved.

Example

nomnom on npm has not seen a publish since 2014. Having this dependency used within your company is a clear risk, should there be a vulnerability or bug that affects your use case, as it is unlikely it will ever be addressed.

Supported Ecosystems/Languages

npm/nodejs
python/pypi
Maven/Java

Empty Package

Empty packages are those that have no runnable code. For instance

Why is Empty Package a Useful Supply Chain Risk Signal?

Empty packages can indicate:

faulty publication
name squatting
risk of being unpublished

An empty package can only be a liability, as it cannot provide any functionality. We highly recommend removing empty packages from your dependency graph entirely and ensure that what it is replaced with has the code that was intended.

Supported Ecosystems/Languages

npm/nodejs
python/pypi
Maven/Java

What Is Considered an Empty Package?

Empty packages are determined by the absence of any of the following file types on a per ecosystem basis:

NPM / Javascript

A javascript package is considered empty if there are none of the following filetypes

.js
.jsx
.ts
.tsx
.ejs

Pypi / Python

A python package is considered empty if there are none of the following filetypes

.py
.pyc
.pyd
.dll

Maven / Java

A java package is considered empty if there are no .class files within the jar

Example

On npm, ms version 3.0.0-canary.0 is an empty package, containing only package.json readme.md and license.md. This was clearly a mistake in publication, as their source code exists for this tag and there was a fix to their build script that caused the published package to be empty. In this case, this being an empty package is only clearly detectable when downloading from npm, as the source code itself always existed and is visible. This is why it is important to have supply chain risk signals reported from FOSSA.

Native Code Detection

Packages that embed compiled executable files.

Why is Native Code Detection a Useful Supply Chain Risk Signal?

While not always a security risk, binaries can obfuscate intent and functionality. This allows an author to potentially sneak in malicious code that can't be easily detected without a disassembler and research. Aside from the security risk, binaries often target specific environments, which means functionality may break depending on where and how your code is deployed.

Supported Ecosystems/Languages

npm/nodejs
python/pypi

What is Considered Native Code?

We're constantly expanding the binaries that we detect. An example of files that we detect includes, but is not limited to:

.exe
.dmg
.deb
.rpm

When FOSSA alerts you to an issue with native code detection, we will list out the files that we've identified as native code so that you can investigate the trustworthiness of the file, package, and publisher.