CIパイプラインに信頼スコアリングを5分で追加する

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:  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 GitHub Action: github.com/piiiico/proof-of-commitment CLI: npx proof-of-commitment API: https://poc-backend.amdal-dev.workers.dev Running into issues? Found a package that should score differently? [email protected] 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:  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 GitHub Action: github.com/piiiico/proof-of-commitment CLI: npx proof-of-commitment API: https://poc-backend.amdal-dev.workers.dev Running into issues? Found a package that should score differently? [email protected]