Code quality policies are used to enforce restrictions on project dependencies. Currently, code quality policies can:

Utilize stale package prevention to ensure your dependencies are kept up to date.
Whitelist packages for automatic approval.
Blacklist packages for automatic flagging.

Creating a Quality Policy

To create a new code quality policy, navigate to the quality tab of the policy configuration menu and click create policy.

From there, you can configure a title and description for your new policy accordingly.

Stale Package Prevention

Outdated packages carry increased security risk and prevent your team from utilizing newer features. To enforce up-to-date packages, you can enable rules to flag packages by semantic version, ordered versions, or both. Package matching either rule will be flagged as issues.

Blocked Packages

As a function of FOSSA's package management feature, a user can "Block" a package enabling two key workflows:

Global reporting of blocked package usage across the organization
CI/CD failure via fossa test preventing blocked packages from entering your production environments

A user can block a package by navigating to the packages tab and searching or filter to your desired package

From there a user can either "Block All Versions" via the Block package button

Or select specific package versions to block

Finally a user will select the desired Quality policy to attach the blocked package rule to, and Block package

Risk Intelligence Rules

As part of FOSSA's quality offering, we also provide insight into your software supply chain risk through what we call "risk intelligence" rules.

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.