feat(ci): live verification of v0.1.1 SARIF upload#1
Conversation
This branch demonstrates what SkilLock catches when an existing skill suddenly adds risky behavior. Diff vs main: + shell_commands: curl (require_approval lifts severity to high) + network_urls: https://internal.example.com/notify (host not in allowed_domains — high) Running 'skil-lock ci' on this branch exits 1 with a BLOCK verdict plus a copy-paste approval snippet pointing at .skil-lock-approvals.yaml. The drift is described in the SKILL.md frontmatter as a 'team notification webhook for visibility' — innocent-sounding language that real malicious skills also use. The capability surface in skills.lock is what catches it, not the prose.
- Bumps skills-lock/skil-lock-action@v0.1.0 → v0.1.1 (pin-binary too). - Adds sarif: true input so the SARIF v2.1.0 report is uploaded to GitHub Code Scanning. Findings will surface in the repo Security tab and as inline PR annotations. - Grants security-events: write at the workflow scope, required by github/codeql-action/upload-sarif@v4. This PR doubles as the live verification of the v0.1.1 SARIF feature described in skills-lock/skil-lock#9 and skills-lock/skil-lock-action#1. The drift commit on this branch (changelog-summary growing curl + a non-allowlisted POST) gives the SARIF report real findings to upload.
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
|
@/home/runner/work/_temp/skil-lock-pr-comment.md |
Live verification reportThe workflow ran end-to-end on this PR. Results: SARIF upload — works
PR comment — bug foundThe PR comment posted by the workflow contains the literal string Fix in flight at skills-lock/skil-lock-action#2 — pipes the body file through Next steps for this PR
CI gap follow-upThe PR-comment path was never exercised by CI before this PR — |
…nts (#2) `gh api -f body=@$BODY` was being interpreted as a string literal, not a curl-style file reference — gh CLI does not support `@file` in -f arguments. As a result, every live PR comment posted by the Action since v0.1.0 contained the verbatim text `@/home/runner/work/_temp/skil-lock-pr-comment.md` instead of the capability-delta markdown. The bug was latent because the only CI exercise of this step (`composite-smoke`) runs on `push`, so the `if: github.event_name == 'pull_request'` guard skipped it — the path was never executed until the live SARIF verification PR on `skills-lock/example-claude-code-skills#1` (2026-05-22). Fix: round-trip the file contents through `jq -Rs '{body: .}'` to produce a safe JSON payload, then pipe it to `gh api --input -`. `jq -Rs` handles arbitrary text (newlines, quotes, backticks, unicode) without shell-escaping pitfalls. `jq` is preinstalled on `ubuntu-latest` and `macos-latest` runners, which are the only platforms the composite supports. Verified against PR #1 of example-claude-code-skills on the fix branch after this commit lands.
v0.1.2 fixes the PR-comment body being posted as the literal '@/home/runner/work/_temp/skil-lock-pr-comment.md' string instead of the markdown body. See skills-lock/skil-lock-action#2. Pinning pin-binary to v0.1.1 (unchanged — the CLI didn't change in v0.1.2, only the Action's PR-comment posting step).
SkilLock - capability deltaComparing
Verdict: BLOCK: 2 of 2 entries at severity >= medium To approve, append to schema_version: "0.1"
approvals:
- skill: "changelog-summary"
delta:
added_shell_command: "curl"
reviewer: "you@example.com"
reviewed_at: "2026-05-25T06:33:42Z"
reason: "<why this delta is acceptable>"
- skill: "changelog-summary"
delta:
added_network_url: "https://internal.example.com/notify"
reviewer: "you@example.com"
reviewed_at: "2026-05-25T06:33:42Z"
reason: "<why this delta is acceptable>" |
v0.1.2 verified — PR comment now renders correctlyAfter bumping the workflow to Confirmed working:
The wedge is now end-to-end live. Closing this PR; the Action items finished for the maintainer
Demo-repo |
Refreshes the live demo PR's workflow to the v0.1.2 CLI so the bot comment that newcomers see on PR #1 uses the cleaned-up renderer output (no em-dashes).
Empty commit to force GitHub Actions to re-run on the demo PR head; the prior workflow-file-only push to this branch didn't fire the pull_request: synchronize event (documented Actions quirk for workflow-only edits to PR head branches). After this run completes, the bot comment on PR #1 will refresh with the cleaned-up renderer output (no em-dashes).
Resolves long-standing conflict that was suppressing the workflow re-run on this PR: - README.md: take main's modernized version (em-dash-free prose, blockquoted example PR comment with native table rendering, PATH note for go install). - .github/workflows/skil-lock.yml: take main's v0.1.2 pin-binary and v0.1.2 Action ref, but keep 'sarif: true' which only this demo branch sets (so Code Scanning upload still demonstrates). After this lands the workflow will re-run on PR #1 and the bot comment will refresh with the cleaned-up renderer output.
|
Closing: obsolete v0.1.1-era SARIF live-test branch. SARIF upload is verified working end-to-end through this repo's CI on v0.2.0 (skil-lock-action pinned to v0.2.0 SHA c7a3b9f). Superseded. |
Why
v0.1.1shipped SARIF v2.1.0 output for GitHub Code Scanning across both production repos. The Action exposes it assarif: true. We haven't yet exercised the SARIF upload path on a real PR — this is the live verification.What this PR does
skills-lock/skil-lock-action@v0.1.0 → v0.1.1.pin-binary: v0.1.0 → v0.1.1.sarif: trueso the report is uploaded to Code Scanning.security-events: write(required bygithub/codeql-action/upload-sarif@v4).The branch is based on
example/drift, which mutateschangelog-summary/SKILL.mdto addcurl+ a non-allowlisted POST URL — that drift gives the SARIF report real findings to upload.Expected outcome
SKL-SHELLforcurl,SKL-NETWORKfor the non-allowlisted URL).Not for merging
This PR is a smoke test of the SARIF upload path. Once Security-tab population is confirmed, it can be closed (or kept open for screenshots).