ci: add poutine security scanning workflow

[Mehdi-Bl]

Summary

• add a dedicated GitHub Actions workflow at .github/workflows/poutine.yml
• run boostsecurityio/poutine-action on pull requests, pushes to main, manual dispatch, and weekly schedule
• upload SARIF results to GitHub code scanning and as a build artifact
• use least-privilege workflow permissions and pinned action SHAs

Validation

• npm run lint
• npm test -- --runInBand

Summary by CodeRabbit

Chores

• Added a new automated workflow that runs on pull requests, pushes to main, and on a weekly schedule
• Workflow executes security scans and uploads results to GitHub for review

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• In the "Implementation Instructions" section, consider adding a concrete cron expression (e.g. schedule: [{ cron: "0 5 * * 1" }]) alongside the "weekly schedule" guidance to avoid ambiguity when implementing the workflow.
• When mentioning .poutine.yml in the triage steps, it would help to explicitly state its expected location (e.g. repo root) and any key top-level fields so that future contributors are less likely to misconfigure the skip rules.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the "Implementation Instructions" section, consider adding a concrete cron expression (e.g. `schedule: [{ cron: "0 5 * * 1" }]`) alongside the "weekly schedule" guidance to avoid ambiguity when implementing the workflow.
- When mentioning `.poutine.yml` in the triage steps, it would help to explicitly state its expected location (e.g. repo root) and any key top-level fields so that future contributors are less likely to misconfigure the skip rules.

## Individual Comments

### Comment 1
<location> `docs/BACKLOG.md:65` </location>
<code_context>
+
+1. `.github/workflows/poutine.yml` runs successfully on PR and push to `main`.
+2. SARIF is uploaded successfully and visible in GitHub code scanning.
+3. Poutine workflow is green on `main`.
+4. Any `.poutine.yml` skip has explicit rationale and narrow scope.
+5. Existing checks remain green.
</code_context>

<issue_to_address>
**suggestion (typo):** Capitalize "poutine" consistently throughout the document.

The doc currently alternates between “Poutine” (e.g., title, checklist items) and “poutine” (e.g., “poutine scanning,” “poutine workflow”). Please choose one capitalization style and apply it consistently throughout.

Suggested implementation:

```
3. poutine workflow is green on `main`.

```

To fully implement the requested consistency, update the rest of `docs/BACKLOG.md` so that all non-filepath uses of the word are lowercase “poutine”. For example:
- Change headings like `## Poutine` or `## Poutine scanning` to `## poutine` / `## poutine scanning`.
- Change phrases like “Poutine scanning”, “Poutine job”, “Poutine run”, etc., to “poutine scanning”, “poutine job”, “poutine run”, etc.
Be careful **not** to modify file paths or config filenames such as `.github/workflows/poutine.yml` or `.poutine.yml`, which should remain as-is.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

suggestion (typo): Capitalize "poutine" consistently throughout the document.

The doc currently alternates between “Poutine” (e.g., title, checklist items) and “poutine” (e.g., “poutine scanning,” “poutine workflow”). Please choose one capitalization style and apply it consistently throughout.

Suggested implementation:

3. poutine workflow is green on `main`.

To fully implement the requested consistency, update the rest of docs/BACKLOG.md so that all non-filepath uses of the word are lowercase “poutine”. For example:

• Change headings like ## Poutine or ## Poutine scanning to ## poutine / ## poutine scanning.
• Change phrases like “Poutine scanning”, “Poutine job”, “Poutine run”, etc., to “poutine scanning”, “poutine job”, “poutine run”, etc.
  Be careful not to modify file paths or config filenames such as .github/workflows/poutine.yml or .poutine.yml, which should remain as-is.

[gemini-code-assist]

Code Review

This pull request adds a backlog document outlining the task to implement a poutine CI security scan. The document is very detailed and well-structured. I've added a couple of suggestions to improve the implementation instructions for clarity and efficiency. My main suggestions are to scope the CI triggers to relevant paths to save resources, and to make the instructions on pinning actions more explicit and consistent to enforce security best practices.

[gemini-code-assist]

For efficiency, consider scoping the pull_request and push triggers to paths under .github/workflows/. This will ensure the poutine scan only runs when workflow files are changed, saving CI resources on pull requests that don't modify workflows.

Suggested change

	- `pull_request` on `main`
	- `push` on `main`
	- `pull_request` on `main` (paths: `.github/workflows/**`)
	- `push` on `main` (paths: `.github/workflows/**`)

[gemini-code-assist]

This instruction is a bit vague. For clarity and to ensure security best practices are followed, it should be as explicit as the instruction for poutine-action on line 34. Please specify that github/codeql-action/upload-sarif should be pinned to an immutable commit SHA.

Suggested change

	- upload SARIF with pinned `github/codeql-action/upload-sarif`
	- upload SARIF with `github/codeql-action/upload-sarif` pinned to an immutable commit SHA

[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