Skip to main content
Use Minimus supply chain protection to govern package installations and enforce stronger security standards. Public repositories such as npm and pip are frequent targets for malicious package uploads and Minimus supply chain policies can help mitigate the risks with minimal setup.
Supply Chain Policy

​
Create a Minimus supply chain policy

Policies are activated via an environment variable added to a Dockerfile or during runtime with any Minimus images. It’s standard practice to set up stricter policies for production and relax controls for dev environments. You can select a policy from the provided templates or create one from scratch.
1

Provide general details

Provide a name and description to identify the purpose of the policy and help your teammates understand its intended purpose.
2

Set the action

Decide if the policy should block suspicious packages or alert on them:
  • If you select block, the policy will prevent installation of packages that trigger the policy guardrails and will fail builds.   
  • If you select alert, the policy will generate security alerts in the Minimus Audit Log. 
3

Configure thresholds

Set the policy’s risk thresholds and trust requirements. A violation of any of these rules will activate the policy.
  • Cooling-off period - Protects against package versions that haven’t been out long enough to be vetted by the community. It sets a minimum number of days since the version’s release. 
  • Popularity - Protects against package versions that haven’t yet been vetted by the community. It sets a minimum number of pulls over the previous 7 days.
  • Typosquatting risk - Toggle this setting on to enable it. It protects against packages with suspicious names, misspellings, or look-alikes of popular packages.
  • Suspicious version release - Toggle this setting on to enable it. It protects against package versions present on a registry that lack a corresponding tag, release, or entry in the project’s GitHub repository.
4

Manage allow & block lists

Add packages to the allowlist or blocklist to bypass the policy. 
5

Save your policy

The policy will be added the list with its name and environment variable.

​
Activate Minimus supply chain policy for npm

Once the policy is ready add the environment variable to your Dockerfile or runtime command to activate the policy and protect your supply chain. Currently the policy protects npm and should be activated for Minimus images that include npm. These may be Node-based images or private images that include npm. Format of the environment variable: -e NPM_CONFIG_REGISTRY="https://<policy-ID>-${IMAGE_NAME}.supplychain.mini.dev Example of a Minimus supply chain policy activated in a Docker run command:
Run command example
docker run -e NPM_CONFIG_REGISTRY="https://157-5-${IMAGE_NAME}.supplychain.mini.dev" \
<Minimus-image>
Example of a Minimus supply chain policy activated via a Dockerfile:
Dockerfile example with Minimus supply chain policy
FROM reg.mini.dev/node

ENV NPM_CONFIG_REGISTRY="https://153-8-${IMAGE_NAME}.supplychain.mini.dev"

COPY package.json ./

RUN npm install
You can add the environment variable to any of your Minimus Node environments. For example, if you want to try out the quick start example for the Minimus Node image with the supply chain policy, adjust the run command to include the policy environment variable -e NPM_CONFIG_REGISTRY: 
docker run -e NPM_CONFIG_REGISTRY="https://153-8-${IMAGE_NAME}.supplychain.mini.dev" \
    -p 3000:3000 -d --name minimus-node \
    -v $(pwd)/hello-minimus-node.js:/home/hello_world/hello-minimus-node.js \
    reg.mini.dev/node:latest \
    /home/hello_world/hello-minimus-node.js
You can exec into your running containers to test package installs manually. The following command assumes your container name is minimus-node: 
docker exec -it minimus-node bash

​
Test your supply chain policy

For testing purposes, we will runreg.mini.dev/node:latest-dev with a Minimus supply chain policy set to alert and open a shell:
Test supply chain policy with node:latest-dev
docker run -e NPM_CONFIG_REGISTRY="https://153-8-${IMAGE_NAME}.supplychain.mini.dev" \
reg.mini.dev/node:latest-dev /bin/sh
# Replace `153-8` with your policy ID
1

Confirm the registry is active

Inside the running container, verify npm is pointed at your policy:
npm config get registry
2

Test a trusted package

Install a well-known, high-download package — it should pass without issue:
npm install lodash
3

Trigger the cooling-off period guardrail

Test the cooling-off period guardrail by finding and installing a recently published package version: First, check when recent versions of a package were published. (This command works best when the policy is in alert mode. In block mode, the policy will only fetch packages that aren’t blocked):
npm view <package> time --json | tail -5
Install a version published within your cooling-off window so it triggers the policy:
npm install <package>@<recent-version>
  • If your policy is set to block, the install will return an error and an alert is generated in the Minimus Audit Log.
  • If your policy is set to alert, the install will succeed and an alert is generated in the Minimus Audit Log.
4

Trigger a typosquatting guardrail

Try installing a package with a suspicious name to test the typosquatting guardrail:
npm install expres
  • If your policy is set to block, the install will return a 403 error and an alert is generated in the Minimus Audit Log.
  • If your policy is set to alert, the install will succeed and an alert is generated in the Minimus Audit Log.
5

Check the Audit Log

Open the Audit Log in Minimus to review policy activity from your test run, including any blocked installs or alerts (direct link). 

​
Summary

You can test each guardrail individually using these tips:
GuardrailHow to trigger it
Cooling-off periodInstall a package version published within the last N days
PopularityInstall an obscure package with very few weekly pulls
TyposquattingTry a common misspelling like expres. Keep in mind that detection is heuristic and depends on the policy’s algorithm so it may not trigger
Suspicious versionInstall a version that exists on npm but lacks a corresponding GitHub release tag
Last modified on June 14, 2026