Conversation
poutine (https://github.com/boostsecurityio/poutine) is a CI pipeline scanner: it looks for supply-chain weaknesses in the workflows themselves (untrusted checkout execution, injection from external contributor input, secrets exposure, self-hosted runners on PRs, unpinnable components, known-vulnerable build components). It complements zizmor rather than duplicating it. - scripts/poutine-scan.sh runs the pinned poutine image against the repo read-only with no network access, emits a pretty report plus SARIF, and gates on POUTINE_FAIL_LEVEL (default: warning). - .github/workflows/poutine.yml runs it on workflow changes, weekly for rule/advisory drift, and on demand; SARIF goes to code scanning on push, and to the job summary on pull requests (forks cannot upload). - .poutine.yml suppresses nothing today; note-level findings are reported without blocking merges. Current state of the repo: zero warning/error findings. The seven note-level 'action from unverified creator' findings are all already commit-SHA pinned.
|
Warning Review limit reachedNext included review available in 26 minutes. View limit detailsLimit details: You’ve used all 2 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughChangesPipeline supply-chain analysis
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Feature Sequence Diagram(s)sequenceDiagram
participant GitHubActions
participant Poutine
participant GitHubCodeScanning
participant WorkflowArtifacts
GitHubActions->>Poutine: Run text and SARIF scans
Poutine->>GitHubActions: Return findings and reports
GitHubActions->>GitHubCodeScanning: Upload SARIF outside pull requests
GitHubActions->>WorkflowArtifacts: Store text and SARIF reports
Suggested reviewers: Merge Risk: ⚪ Minimal · up to The new scanner preserves advisory note findings while blocking warning and error findings as intended. No actionable merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Replaces scripts/poutine-scan.sh with boostsecurityio/poutine-action, per upstream's recommended integration. - Pinned to main@badd750a rather than the latest tag (v1.1.4): that tag still ships poutine 1.1.4, while this commit ships 1.1.6, the same image digest the previous script pinned. - The action always exits 0, so a small gate step reads the SARIF and fails the job on warning/error findings only; note-level findings are still reported without blocking merges. - The action runs twice (pretty + sarif) because it emits one format per invocation: pretty goes to the job summary, SARIF to code scanning. No change in results: still zero warning/error findings.
Carries over the three points raised on coop#721: - Pin the scanner binary, not just the action: the pinned action commit builds FROM poutine:1.1.6@sha256:722a8e09..., so the version cannot drift under a fixed action SHA (this is why it is pinned to main@badd750a and not @main as upstream's README suggests). - Upload SARIF only on push, annotate on pull requests: PR runs now emit inline file/line annotations from the SARIF instead of relying on the job summary alone. - No standing suppressions to maintain: .poutine.yml is gone. Its only content was disableVersionCheck, now set via the POUTINE_DISABLE_VERSION_CHECK env var on the scan steps, so there is no config file that could quietly grow exceptions. Also adds the CHANGELOG entry under 'CI & infrastructure'.
Context & Requests for Reviewers
Adds poutine (BoostSecurity) as a CI supply-chain scanner for our GitHub Actions pipelines, wired into CI and gated so it stays green in steady state.
Poutine is complementary to the
zizmorjob we already run rather than duplicating it.zizmor analyzes workflow files in this repo: template injection,
credential persistence, cache poisoning, unpinned actions. Broad rule
coverage, fast, auto-fix, and it runs as a blocking PR gate.
poutine analyzes those files reach. It resolves
workflows and actions transitively, so it flags an unpinned
action pulled in through a dependency (e.g. the Shai-Hulud)
attack, which is invisible to a tool that only reads our own YAML.
poutine is only advisory and does not block merges. Findings land in the code scanning tab.
This + zizmor should address CI scanning in #213
What's here
boostsecurityio/poutine-action— upstream's official action does the scanning.main@badd750a, not the latest tag. The newest tag (v1.1.4, Apr 2026) still builds frompoutine:1.1.4;main@badd750abuilds frompoutine:1.1.6@sha256:722a8e09…. Pinning tag refs vs hashes is literally what these tools warn you about....github/workflows/poutine.yml— Runs on a weekly cron (new poutine rules/advisories can flag workflows nobody has touched) andworkflow_dispatch.Current baseline
0 findings at
warningorerror.7 note-level
github_action_from_unverified_creator_usedfindings:dorny/paths-filter(×3),dorny/test-reporter(×2),zizmorcore/zizmor-action,MatteoGabriele/agentscan-actionAll already commit-SHA pinned.
Tests
warning/errorfindings; the gate'sjqfilter returns 0.(Optional) Rollout Plan
None: CI-only change.
Checklist
Only check items that apply to this PR; leave the rest unchecked.
If you changed anything user-facing (i.e. user interface or APIs):
Did you update related docs?
If the change is notable (refer to Keep a Changelog conventions):
Did you update CHANGELOG.md?
If you changed
server/models/**/{ContentTypeModel,ActionModel,RuleModel,PolicyModel}.ts:Did you update the corresponding history tables and their triggers?
If you changed
db/src/scripts/**and usedCREATE TABLE,ADD COLUMN, orALTER COLUMN:Are as many columns marked
NOT NULLas possible?If you added a new signal in
server/services/signalsService/signals/**:Did you classify every error case as a permanent error or a normal error?
zizmorgot aCHANGELOG.mdentry under "CI & infrastructure" when it was added (#721); happy to do the same here with the PR link if you want it recorded.Summary by CodeRabbit
New Features
Documentation