feat(workflows): add weekly dependency-provenance reusable workflow

[williaby]

Summary

Adds python-dependency-provenance.yml, a weekly, deterministic, keyless
dependency-provenance reusable workflow that makes Open-Source vulnerability
findings actionable by showing which DIRECT dependency introduces each insecure
TRANSITIVE package.

It uses no Anthropic API key and no hosted Snyk test quota. The
interpretation layer (deciding which fix to apply) runs locally on the
operator's subscription, separately from CI. This workflow is a reporter; the
gating OSV-Scanner job in python-sbom.yml still owns the merge gate.

What it does

1. detect-config - detects the ecosystem (Python uv.lock / requirements*.txt, frontend package.json); rejects Poetry on the Python path (uv-only by org policy).
2. provenance - runs OSV-Scanner (keyless) to list vulnerable packages, then traces each back to its introducing direct dependency with uv tree --invert --package <pkg> (Python, tags the introducing extra:/group:) and npm why <pkg> (frontend). Assembles a structured Markdown report and uploads it as an artifact.
3. post-issue - posts/updates a sticky GitHub issue anchored by <!-- dependency-provenance -->. Tolerant of zero-vuln runs (updates a "no actionable transitive vulns this week" body so a clean cycle is observable).
4. provenance-gate - aggregates results; fails only when the report pipeline errored, never on the presence of vulnerabilities.

The report table columns: vulnerability id (+ CVE alias), severity, vulnerable package, introducing direct dep, extra/group, suggested action (remove / upgrade / replace / gate), under a short "how to act" preamble.

Conventions mirrored

• Structure follows python-snyk.yml: detect-config state job, permissions: {} deny-all with per-job grants, SHA-pinned actions, step-security/harden-runner audit egress, workflow_call inputs, gate job.
• Token-optional: uses the default GITHUB_TOKEN; only post-issue needs issues: write.
• Report assembly and provenance tracing extracted into SHA-pinned scripts (scripts/dependency_provenance.py, scripts/dependency_provenance_trace.py), checked out at job.workflow_sha like check_licenses.py (injection-safe; all inputs via env).
• Scheduled caller dependency-provenance-weekly.yml mirrors sbom-nightly.yml (weekly cron 23 6 * * 1, off-peak non-:00).

Also included

• Docs page docs/workflows/python-dependency-provenance.md (mirrors python-snyk.md).
• USAGE_EXAMPLES.md entry + Available Workflows row.
• ADR-003 dated "Role boundary" note (Snyk owns SAST + IaC + AIBOM, OSS stays advisory; transitive-provenance handled here + local agent; points to ByronWilliamsCPA/.claude ADR-009).
• self-test.yml self-test job and .github/actionlint.yaml exception for job.workflow_*.

Validation

• actionlint clean, yamllint clean, ruff check + ruff format --check clean, full pre-commit clean (no em-dash, secret scans pass).
• Report assembler tested against sample OSV + provenance data: severity sort, CVE alias display, all four action categories, zero-vuln path, missing-file tolerance, and multi-ecosystem merge all verified locally.

Consumer calling convention

jobs:
  provenance:
    uses: ByronWilliamsCPA/.github/.github/workflows/python-dependency-provenance.yml@v1
    permissions:
      contents: read
      issues: write
    with:
      python-version: '3.12'
      open-issue: true

Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@williaby, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 5 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: a9c19a6f-4949-4877-9dfe-eba757f0b6d4

📥 Commits

Reviewing files that changed from the base of the PR and between 4b12bfe and 49721fa.

📒 Files selected for processing (9)

• .github/actionlint.yaml
• .github/workflows/dependency-provenance-weekly.yml
• .github/workflows/python-dependency-provenance.yml
• .github/workflows/self-test.yml
• USAGE_EXAMPLES.md
• docs/planning/adr/adr-003-snyk-ai-code-security.md
• docs/workflows/python-dependency-provenance.md
• scripts/dependency_provenance.py
• scripts/dependency_provenance_trace.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/dependency-provenance-workflow

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud