ci: add an advisory UI audit for apps/v4 - #1899
Conversation
📝 WalkthroughWalkthroughAdds a GitHub Actions workflow that runs ChangesUI Audit Workflow
Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 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 |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ui-audit.yaml:
- Around line 23-24: Update the actions/checkout step in the UI audit workflow
to set persist-credentials to false, ensuring the checkout token is not retained
for subsequent steps.
- Line 24: Update the workflow steps using actions/checkout and
vinayakkulkarni/shadscan-vue to reference immutable, full-length commit SHAs
instead of mutable version tags, preserving the intended release versions with
trailing tag comments for clarity.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 44f28eb5-ef23-4752-9397-554306f7b3ca
📒 Files selected for processing (1)
.github/workflows/ui-audit.yaml
| - name: Checkout repository | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Disable persisted checkout credentials.
This workflow never performs authenticated Git operations after checkout, so add persist-credentials: false. actions/checkout otherwise persists the token for later steps, including the third-party scanner. (github.com)
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 23-27: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ui-audit.yaml around lines 23 - 24, Update the
actions/checkout step in the UI audit workflow to set persist-credentials to
false, ensuring the checkout token is not retained for subsequent steps.
Sources: MCP tools, Linters/SAST tools
|
|
||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "## workflow snippet"
sed -n '1,80p' .github/workflows/ui-audit.yaml 2>/dev/null || true
echo
echo "## action uses in workflow"
rg -n "^[[:space:]]*uses:[[:space:]]+" .github/workflows/ui-audit.yaml || trueRepository: unovue/shadcn-vue
Length of output: 1042
🌐 Web query:
GitHub docs full-length commit SHA action pinning
💡 Result:
Pinning GitHub Actions to a full-length (40-character) commit SHA is a security best practice that ensures an action remains immutable, protecting your workflows from malicious changes that could occur if an upstream tag or branch is compromised [1][2][3]. Key aspects of full-length commit SHA pinning: Immutability and Security: Unlike tags (e.g., @v4) or branches (e.g., @main), which are mutable pointers that can be updated or re-pointed by a repository maintainer (or an attacker who gains access to the repository), a full-length commit SHA refers to a specific, immutable Git object [1][2][4]. Pinning to a SHA mitigates risks such as supply-chain attacks where malicious code is injected into a previously trusted version [5][3]. GitHub Policy Enforcement: GitHub allows administrators to enforce SHA pinning at both the organization and repository levels [1][5]. When this policy is enabled, any workflow attempting to reference an action by a non-SHA identifier (like a tag or branch) will fail [5][6]. Note that this policy checks the entire dependency tree of the workflow, including any sub-actions called by the primary action [6]. Best Practices for Implementation: 1. Use 40-character SHAs: You must use the full-length commit SHA, not an abbreviated version [7][8]. 2. Maintain Human-Readability: While pinning to a SHA provides security, it sacrifices readability and makes manual version tracking difficult. A standard practice is to include the version tag as a trailing comment in the workflow file (e.g., uses: actions/checkout@a1b2c3d4... # v4.0.0) [2][3][4]. 3. Automate Updates: You do not need to manually update SHAs. Tools like Dependabot and Renovate support SHA pinning; they can parse the trailing version comment to detect new releases and automatically open pull requests that update the SHA and the comment simultaneously, allowing you to maintain both security and freshness [2][3][4]. Official Documentation: GitHub's official documentation identifies pinning to a full-length commit SHA as the only way to treat an action as an immutable release [1][7]. While older documentation may have recommended binding to major version tags for convenience [9], current security guidance strongly favors SHA pinning as the secure default [1][5].
Citations:
- 1: https://docs.github.com/en/actions/reference/security/secure-use
- 2: https://starsling.dev/best-practices/github-actions/pin-action-shas
- 3: https://tomodahinata.com/en/blog/dependabot-github-actions-sha-pinning-supply-chain-security-guide
- 4: https://nearform.com/insights/why-you-should-pin-your-github-actions-by-commit-hash/
- 5: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 6: https://www.romainlespinasse.dev/posts/github-actions-commit-sha-pinning/
- 7: https://docs.github.com/en/actions/how-tos/create-and-publish-actions/manage-custom-actions
- 8: https://docs.github.com/en/enterprise-cloud@latest/actions/how-tos/create-and-publish-actions/manage-custom-actions
- 9: https://github.com/actions/toolkit/blob/master/docs/action-versioning.md
Pin both actions to immutable commit SHAs.
actions/checkout@v4 and vinayakkulkarni/shadscan-vue@v0 are mutable references. Resolve the intended release commits and pin each step with a full-length SHA, e.g. using a trailing comment for the tag version.
Applies to lines 24 and 29.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ui-audit.yaml at line 24, Update the workflow steps using
actions/checkout and vinayakkulkarni/shadscan-vue to reference immutable,
full-length commit SHAs instead of mutable version tags, preserving the intended
release versions with trailing tag comments for clarity.
Source: MCP tools
Runs shadscan-vue against the docs app on pull requests that touch it and writes the score, category table, and failing rules to the job summary. The job is advisory: continue-on-error keeps it from blocking a pull request. The audit reads source files and never starts the app, so it needs no install step and adds no dependency to the repository. Refs unovue#1898
4a01a1c to
941294d
Compare
Follows up on #1898, and implements option 1 from that issue — advisory only, nothing gated.
What this adds
A single workflow,
.github/workflows/ui-audit.yaml, that runs shadscan-vue againstapps/v4on pull requests touching it and writes the score, category table, and every failing rule to the job summary.That is the whole change: 31 lines, one file, no dependency added to the repository.
Deliberately non-blocking
The job sets
continue-on-error: true, so it can never fail a contributor's pull request. It reports and stops there. If you later decide you want a floor,fail-under: 61would pin today's score and catch regressions — but I have left that out on purpose, since gating is your call and not mine to assume.Path filters mirror
test.yaml, so it only runs whenapps/v4changes.No install step
shadscan-vue reads source files and never starts the app, so the audit runs on a bare checkout. I verified this against a fresh clone of
devwith nonode_modulespresent: complete coverage, 204 files, 61/100 (D) — matching the number in #1898 exactly.Verified before proposing
I ran this workflow on a fork first rather than opening it here untested. Both runs completed successfully, and the first one exposed a rendering bug in my own action: rule messages name the offending element, so
Routable surface starts at <h2> with no <h1>was being rendered as a literal heading, breaking the summary apart. Fixed in shadscan-vue 0.3.1 by escaping messages before they reach the renderer, and@v0already points at it.One thing worth flagging: the run logs a Node 20 deprecation warning from
actions/checkout@v4. That is the version pinned across your workflows, so I matched it rather than bumping it here — it seemed wrong to change your standard action version inside an unrelated pull request.Easy to decline
If this is not something you want in CI, close it — no hard feelings, and #1898 stands on its own as a list of findings you can act on or ignore. I would rather you have the option than assume you want the tool.
Disclosure: I wrote shadscan-vue.
Summary by CodeRabbit