Add Trust Scoring to Your CI Pipeline in 5 Minutes

Most supply chain attacks are not zero-days. They are predictable failures: a package with a single maintainer, stagnant activity, and 50 million weekly downloads changes hands. npm audit shows zero issues — because there is no CVE yet.

proof-of-commitment scores dependencies on behavioral signals: maintainer count, download trends, maintenance activity, historical incidents. Two ways to add it to CI. Pick one.

Option 1: GitHub Action (Recommended)

Add a new workflow file to your repo:

# .github/workflows/supply-chain-audit.yml
name: Supply Chain Audit

on:
  pull_request:
    paths:
      - 'package.json'
      - 'package-lock.json'
      - 'bun.lock'
      - 'requirements.txt'
      - 'pyproject.toml'
  push:
    branches: [main]
  workflow_dispatch: {}

jobs:
  audit:
    name: Dependency Audit
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write   # needed for PR comments
    steps:
      - uses: actions/checkout@v4

      - name: Commit Supply Chain Audit
        uses: piiiico/proof-of-commitment@main
        with:
          fail-on-critical: false   # set true to block merges on CRITICAL packages
          max-packages: '20'
          comment-on-pr: true       # posts results as a PR comment

That is the minimal config. Auto-detects packages from your lock file, posts a comment on every PR touching dependencies.

Inputs

Input	Default	What it does
`packages`	auto	Comma-separated package names. Skip this — auto-detection reads your lock file.
`ecosystem`	`auto`	`npm` or `pypi`. Auto-detected from your package files.
`fail-on-critical`	`true`	Exit non-zero if any CRITICAL packages found. Set `false` to audit-only without blocking.
`max-packages`	`20`	How many packages to audit from the lock file. Focus on your top dependencies.
`comment-on-pr`	`true`	Post results as a PR comment, auto-updated on re-runs.

Example Output

The action posts a comment to every dependency PR:

## Commit Supply Chain Audit

| Package | Score | Risk | Weekly Downloads | Maintainers |
|---------|-------|------|-----------------|-------------|
| axios   |  42   | CRITICAL | 101M | 2 |
| lodash  |  71   | MODERATE | 54M  | 4 |
| chalk   |  58   | HIGH     | 413M | 1 |
| zod     |  89   | LOW      | 18M  | 2 |
| react   |  94   | LOW      | 70M  | 8 |

⚠️ 1 CRITICAL package found. Review before merging.

Scores reflect behavioral commitment signals — maintainer bus factor, download trend, maintenance activity, incident history. Not CVE databases.
→ Full methodology: getcommit.dev/thesis

The comment updates automatically on each push. No separate workflow run required.

Outputs

Use these in downstream steps:

      - name: Commit Supply Chain Audit
        id: audit
        uses: piiiico/proof-of-commitment@main

      - name: Post to Slack if critical
        if: steps.audit.outputs.has-critical == 'true'
        run: echo "Found CRITICAL packages — check audit summary"

Output	Value
`has-critical`	`true` if any CRITICAL packages found
`critical-count`	Number of CRITICAL packages
`audit-summary`	Full results as a markdown table

Option 2: CLI in Any CI

Works in GitHub Actions, GitLab CI, CircleCI, Buildkite — anywhere with Node.js.

GitHub Actions (manual step):

      - name: Audit dependencies
        run: npx proof-of-commitment --file package.json

GitLab CI:

supply-chain-audit:
  stage: test
  script:
    - npx proof-of-commitment --file package.json
  only:
    changes:
      - package.json
      - package-lock.json

CircleCI:

jobs:
  supply-chain-audit:
    docker:
      - image: cimg/node:lts
    steps:
      - checkout
      - run:
          name: Audit dependencies
          command: npx proof-of-commitment --file package.json

Any shell script:

npx proof-of-commitment --file package.json
npx proof-of-commitment --file requirements.txt   # Python projects

The CLI exits non-zero if CRITICAL packages are found, so it integrates naturally with any CI that checks exit codes.

Bonus: Add a Badge to Your README

Show live trust scores directly in your README. Badges pull from the same scoring API:

![Commit Trust Score](https://poc-backend.amdal-dev.workers.dev/badge/npm/your-package-name)

Replace your-package-name with any npm package. The badge updates live.

For PyPI packages: https://poc-backend.amdal-dev.workers.dev/badge/pypi/your-package

More badge options — shields.io compatible, custom thresholds — at /badges.

What the Scores Mean

Scores run 0–100. Four risk tiers:

Score	Tier	Interpretation
80–100	LOW	Strong behavioral signals across all dimensions
60–79	MODERATE	Some risk signals — review before major version bumps
40–59	HIGH	Multiple risk signals — consider alternatives or pin the version
0–39	CRITICAL	Severe structural risk — solo maintainer, high downloads, weak activity

Signals include: maintainer count, download volume vs. maintainer ratio, maintenance activity over 90 days, historical incident flags, and download trend anomalies.

These are structural signals, not CVE lookups. A package can score CRITICAL with zero known vulnerabilities — that is exactly the point. Full methodology →

Source

Running into issues? Found a package that should score differently? pico@amdal.dev

推荐订阅源

DEV Community