Why Trust Scores Should Be Part of Your Dependency Workflow Today

Most supply chain attacks don’t start with zero-day exploits. Instead, they target packages with critical weaknesses such as a single overworked maintainer, stagnant development, or millions of weekly downloads—issues npm audit won’t catch because no CVE exists yet.

To close this gap, the open-source tool proof-of-commitment introduces behavioral trust scoring. Instead of relying on vulnerability databases, it evaluates packages based on signals like maintainer count, download trends, maintenance activity, and historical incidents. Within five minutes, you can integrate these scores into your CI pipeline and block risky dependencies before they enter production.

Take Control with a GitHub Action

Adding trust scoring to your GitHub repository is straightforward. Create a new workflow file in .github/workflows/supply-chain-audit.yml with the following configuration:

# .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
    steps:
      - uses: actions/checkout@v4
      - name: Commit Supply Chain Audit
        uses: piiiico/proof-of-commitment@main
        with:
          fail-on-critical: false
          max-packages: '20'
          comment-on-pr: true

This setup automatically detects packages from your lock file and posts a detailed risk assessment as a pull request comment on every dependency change. The fail-on-critical option can be toggled to true to block merges if critical packages are detected.

Configure for Your Project

The GitHub Action accepts several inputs to tailor the audit to your needs:

• packages (auto): Comma-separated package names. Leave blank to auto-detect from your lock file.
• ecosystem (auto): npm or pypi. Automatically detected from your package files.
• fail-on-critical (true): Exit with an error code if any critical packages are found.
• max-packages (20): Limit the number of packages audited from your lock file.
• comment-on-pr (true): Publish results as a PR comment that updates on re-runs.

When triggered, the action generates a markdown table in the PR comment, showing each package’s trust score, risk tier, weekly downloads, and maintainer count. For example:

| Package | Score | Risk | Weekly Downloads | Maintainers | |---------|-------|------|-----------------|-------------| | axios | 42 | CRITICAL | 101M | 2 | | lodash | 71 | MODERATE | 54M | 4 | | chalk | 58 | HIGH | 413M | 1 |

If any packages are flagged as critical, the action adds a warning to halt further review until addressed.

Use the CLI Across Any CI System

For teams using GitLab CI, CircleCI, or other platforms, the same tool works via CLI. Install it globally or run it directly using npx:

npx proof-of-commitment --file package.json

This command accepts the same inputs as the GitHub Action and exits with a non-zero status if critical packages are detected, making it compatible with any CI pipeline that respects exit codes.

Example integrations:

• 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

Display Real-Time Trust Scores in Your Documentation

To highlight the health of your dependencies publicly, add a dynamic badge to your project README. The badge pulls live scores from the proof-of-commitment API:

!Commit Trust Score

Replace your-package-name with your npm or PyPI package name. The badge updates automatically and supports custom thresholds via Shields.io.

Decoding the Risk Tiers

Trust scores range from 0 to 100, grouped into four risk categories:

• 80–100 (LOW): Strong signals across all dimensions, such as multiple maintainers and consistent activity.
• 60–79 (MODERATE): Some risk signals present—suitable for review before major version updates.
• 40–59 (HIGH): Multiple warning signs. Consider pinning versions or evaluating alternatives.
• 0–39 (CRITICAL): Severe structural risks, like a single maintainer supporting millions of downloads with little activity.

These scores reflect behavioral patterns, not traditional CVE databases. A package can score critically even with zero known vulnerabilities—a key insight for proactive supply chain defense.

As dependency ecosystems grow, integrating behavioral trust scoring into CI pipelines isn’t just smart—it’s essential. Whether through GitHub Actions, CLI tools, or public badges, teams can now assess risk in real time and prevent supply chain failures before they happen.

The future of secure software delivery depends on moving beyond reactive vulnerability scans to proactive trust evaluation. Start small, integrate quickly, and build a stronger foundation for every release.