proof-of-commitment v1.2.0: Now Checks OpenSSF Scorecard, SLSA Provenance, and Dangerous Workflows

The @bitwarden/cli attack in April was a wake-up call: behavioral scoring told the right story (9 maintainers, 7-year history, genuine org) but couldn't see the compromised CI/CD pipeline. Behavioral signals identify who can publish. They don't catch whether what was published matches the source.

v1.2.0 adds three new layers that together cover the build integrity surface behavioral scoring misses.

What's new

OpenSSF Scorecard integration

Every audit now returns a Scorecard score alongside behavioral signals. Scorecard measures whether a project follows secure development practices: code review requirements, branch protection, SLSA provenance, dangerous workflow detection, vulnerability disclosure policy.

npx proof-of-commitment axios zod chalk

Output now includes Scorecard scores. You can compare the two approaches directly:

• Behavioral score (0-100): structural risk — who controls the publish key, download concentration, maintainer depth
• Scorecard (0-10): process security — does this repo handle its own development securely

They measure different things. A package can score well on both, or fail both, or pass one and fail the other. Knowing both gives you a complete picture.

SLSA provenance attestation

The audit response now includes hasProvenance — whether the published npm package has a verifiable build attestation linking it to a specific source commit, repository, and CI run.

Build provenance is the direct answer to pipeline compromise attacks like Bitwarden. When provenance is present and valid:

• The published artifact is cryptographically linked to a specific source commit
• npm audit signatures can verify that link
• A tampered build pipeline produces an artifact that doesn't match — the provenance chain breaks

No provenance doesn't mean the package is compromised. Most packages don't have it yet. But it's now surfaced as a signal so you can factor it into your risk assessment.

# Check provenance for a specific package
curl -s "https://poc-backend.amdal-dev.workers.dev/api/audit" \
  -H "Content-Type: application/json" \
  -d '{"packages":["express"]}' | jq '.results[0].hasProvenance'

hasDangerousWorkflow detection

The API now flags packages whose GitHub repos have potentially dangerous GitHub Actions workflow patterns: pull_request_target with write permissions, unpinned third-party actions, script injection vectors.

These are the exact patterns that enable pipeline compromise attacks like Bitwarden. A package with hasDangerousWorkflow: true isn't necessarily compromised — but it's structurally vulnerable to the build pipeline attack class.

The full picture now

Signal	Catches	Misses
Behavioral score (maintainer depth)	Credential compromise targets (sole maintainer + high downloads)	Pipeline attacks on well-staffed packages
Scorecard	Process security failures	Download concentration
SLSA provenance	Pipeline tampering (verifiable chain of custody)	Pre-publish credential phishing
hasDangerousWorkflow	Vulnerable CI/CD patterns	Already-published malicious artifacts
Real-time publish scanning (Socket)	Malicious code in published artifacts	Structural and process risk

No single tool covers everything. Knowing the scope of each is how you build a layered defense that actually works.

Try it

Zero install:

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

Web audit (no install): getcommit.dev/audit

MCP server (add to Claude Desktop, Cursor, Windsurf):

{
  "mcpServers": {
    "proof-of-commitment": {
      "type": "streamable-http",
      "url": "https://poc-backend.amdal-dev.workers.dev/mcp"
    }
  }
}

GitHub Action (adds supply chain audit as PR comment):

- uses: piiiico/commit-action@v1
  with:
    fail-on-critical: true

---

Full release notes at github.com/piiiico/proof-of-commitment/releases/tag/v1.2.0. Open source, MIT licensed.