build(deps): clear all Dependabot advisories + harden CI security#1331
Conversation
Clears all 9 open Dependabot advisories. All are transitive and unreachable, but the pins remove the vulnerable copies from the trees entirely. Root (pnpm-lock.yaml): bump the obsidian-calendar-ui>svelte override 3.59.2 -> ^5.56.3 so it dedupes onto the already-bundled, already-patched svelte 5.56.3 instead of pinning the EOL 3.x that accumulated every new Svelte advisory (CVE-2024-45047 + CVE-2026-27121/27122/27125/27901/42573/42599). The subtree is never bundled (dataview's dist imports no calendar-ui; treeShaking on), verified by a production build: 0 svelte/internal refs in main.js. Docs (docs/pnpm-lock.yaml): add joi ^17.13.4 (CVE-2026-48038) and uuid ^11.1.1 (CVE-2026-41907) overrides; both are Docusaurus build/dev-time transitives. Verified: pnpm audit clean (root + docs), build + 1856 tests pass, docs build OK.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughThis PR extracts dependency review to its own workflow, runs Svelte checks in CI, expands CodeQL to include Actions, switches the release job to use a GitHub App token, and updates pnpm overrides and several dependency versions. ChangesCI Workflows and Dependency Management
Sequence DiagramsequenceDiagram
participant PR as Pull Request
participant CI as Dependency Review Workflow
participant Harden as step-security/harden-runner
participant Checkout as actions/checkout
participant DepAction as actions/dependency-review-action
PR->>CI: open/update PR to master
CI->>Harden: run runner hardening
CI->>Checkout: checkout code (persist-credentials:false)
CI->>DepAction: run dependency review (runtime & dev)
DepAction->>CI: result (pass/fail)
alt new moderate+ advisories
DepAction->>PR: post comment and fail
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
|
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. |
Deploying quickadd with
|
| Latest commit: |
82bf126
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://f361117e.quickadd.pages.dev |
| Branch Preview URL: | https://chhoumann-github-dependency.quickadd.pages.dev |
- dependency-review: move to its own workflow that runs on ALL PRs (the root CI path-ignores docs/**, so docs lockfile bumps were unreviewed); raise the gate from fail-on-severity:high to moderate and add fail-on-scopes:runtime,development. - codeql: add the 'actions' language so workflow files get scanned too.
b2ffc62 to
fdde72d
Compare
Folds the open non-security Dependabot PRs into this branch so there's a single dependency PR with one coherent lockfile: - svelte-dnd-action 0.9.69 -> 0.9.70 (prod, bundled) [#1324] - obsidian 1.13.0 -> 1.13.1 (dev types) [#1323] - @types/node 25.9.2 -> 25.9.3 (dev types) [#1323] - eslint -> 10.5.0 (within existing "eslint":"10" range, lockfile) [#1323] Verified: pnpm install --frozen-lockfile consistent, audit clean, build OK, svelte-check 0 errors, 1856 tests pass (incl. drag-reorder suites).
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@package.json`:
- Line 26: Update the devDependency entry for `@types/node` in package.json to use
a caret prefixed semver (change "25.9.3" to "^25.9.3") so it matches the other
devDependencies and allows semver-compatible patch updates; edit the
"`@types/node`" value accordingly.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 2c178502-ded4-49eb-9d54-a682bcb1909a
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (1)
package.json
Prereq for enforced branch protection on master: - release.yml: mint a short-lived token from the QuickAdd Release Bot GitHub App (actions/create-github-app-token, SHA-pinned) and use it for checkout + the semantic-release step. The release push is then attributed to the App, which is an allowed bypass actor on the master ruleset; GITHUB_TOKEN's github-actions[bot] push cannot be a bypass actor and would be blocked. - ci.yml: drop docs/** + **/*.md paths-ignore so Test + Build + Lint run on every PR and can be required without deadlocking docs-only PRs.
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/release.yml:
- Around line 45-58: Move the "Generate release-bot token" (step id: app-token)
and the checkout that uses its token (the actions/checkout with token: ${{
steps.app-token.outputs.token }}) so they run only immediately before the
Release step: remove the app-token minting and the checkout-with-token from the
pre-build stages (before pnpm install/build/test), keep a normal checkout
earlier without the app-token, then add a new step sequence right before the
Release job that (1) generates the release-bot token via the existing
create-github-app-token invocation (id: app-token) and (2) performs a checkout
or configures git to use ${{ steps.app-token.outputs.token }} and exports that
token to GITHUB_TOKEN for the semantic-release step; this ensures the
bypass-capable App token is minted and persisted into git credentials only after
install/build/test succeed.
- Around line 47-50: The GitHub App installation token creation is granting the
App's full installation scopes by default; update the
actions/create-github-app-token step to pass explicit permission-* inputs
limiting scopes to only what actions/checkout and semantic-release require (for
example add permission-contents: write, permission-metadata: read,
permission-actions: read — adjust to your repo’s actual needs), so replace the
current invocation with one that includes those permission-* inputs to apply
least-privilege.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1eb8f7c0-f7d6-4e42-9d60-346d7a57ce72
📒 Files selected for processing (2)
.github/workflows/ci.yml.github/workflows/release.yml
| - name: Generate release-bot token | ||
| id: app-token | ||
| uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0 | ||
| with: | ||
| app-id: ${{ secrets.RELEASE_APP_ID }} | ||
| private-key: ${{ secrets.RELEASE_APP_PRIVATE_KEY }} | ||
|
|
||
| - name: Checkout | ||
| uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3 | ||
| with: | ||
| # semantic-release needs full history + tags and the persisted | ||
| # semantic-release needs full history + tags and the persisted App | ||
| # credential to push the release commit. Do not change these. | ||
| fetch-depth: 0 | ||
| token: ${{ secrets.GITHUB_TOKEN }} | ||
| token: ${{ steps.app-token.outputs.token }} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show the workflow file with line numbers (bounded to keep output small)
nl -ba .github/workflows/release.yml | sed -n '1,200p'Repository: chhoumann/quickadd
Length of output: 105
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Print workflow file with line numbers (no nl available)
awk '{printf "%6d\t%s\n", NR, $0}' .github/workflows/release.yml | sed -n '1,220p'Repository: chhoumann/quickadd
Length of output: 9464
Delay minting the bypass-capable GitHub App token until right before the Release step
Generate release-bot token mints the App token before pnpm install/build/test, and Checkout immediately persists it into git credentials via token: ${{ steps.app-token.outputs.token }}. This exposes a branch-protection-bypass credential to lifecycle/build/test code that can execute arbitrary scripts. Mint the token only after install/build/test pass, then set the git credential/remote and GITHUB_TOKEN for semantic-release immediately before the Release step.
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 52-58: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 47-47: dangerous use of GitHub App tokens (github-app): app token inherits blanket installation permissions
(github-app)
🤖 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/release.yml around lines 45 - 58, Move the "Generate
release-bot token" (step id: app-token) and the checkout that uses its token
(the actions/checkout with token: ${{ steps.app-token.outputs.token }}) so they
run only immediately before the Release step: remove the app-token minting and
the checkout-with-token from the pre-build stages (before pnpm
install/build/test), keep a normal checkout earlier without the app-token, then
add a new step sequence right before the Release job that (1) generates the
release-bot token via the existing create-github-app-token invocation (id:
app-token) and (2) performs a checkout or configures git to use ${{
steps.app-token.outputs.token }} and exports that token to GITHUB_TOKEN for the
semantic-release step; this ensures the bypass-capable App token is minted and
persisted into git credentials only after install/build/test succeed.
Source: Linters/SAST tools
| uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0 | ||
| with: | ||
| app-id: ${{ secrets.RELEASE_APP_ID }} | ||
| private-key: ${{ secrets.RELEASE_APP_PRIVATE_KEY }} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/release.yml"
echo "== File =="
ls -la "$FILE"
echo
echo "== Lines 1-120 =="
nl -ba "$FILE" | sed -n '1,140p'
echo
echo "== Search for app-token outputs usage =="
rg -n "app-token|create-github-app-token|steps\.app-token\.outputs|app_token|github-app-token" "$FILE" || true
echo
echo "== Search for GITHUB_TOKEN permissions usage =="
rg -n "permissions:|GITHUB_TOKEN|token:" "$FILE" || trueRepository: chhoumann/quickadd
Length of output: 232
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/release.yml"
echo "== File =="
ls -la "$FILE"
echo
echo "== Lines 1-200 =="
nl -ba "$FILE" | sed -n '1,220p'
echo
echo "== Search for app-token outputs usage =="
rg -n "app-token|create-github-app-token|steps\.app-token\.outputs|app_token|github-app-token" "$FILE" || true
echo
echo "== Search for GITHUB_TOKEN and job permissions blocks =="
rg -n "permissions:|GITHUB_TOKEN|token:" "$FILE" || trueRepository: chhoumann/quickadd
Length of output: 232
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/release.yml"
echo "== File =="
ls -la "$FILE"
echo
echo "== Lines 1-220 =="
awk '{printf "%5d\t%s\n", NR, $0}' "$FILE" | sed -n '1,220p'
echo
echo "== Matching create-github-app-token usage (context) =="
rg -n "actions/create-github-app-token" "$FILE" -C 5 || true
echo
echo "== app-token step output usage (context) =="
rg -n "app-token|steps\.app-token|permission-|permission-contents|permission-issues|permission-pull-requests" "$FILE" -C 2 || true
echo
echo "== Any token: assignments used for checkout/semantic-release (context) =="
rg -n "token:\s*\${{\s*steps\.(app-token|app_token)|token:\s*\${{\s*secrets|checkout|semantic-release|actions/checkout" "$FILE" -C 3 || true
echo
echo "== Job permissions blocks (context) =="
rg -n "^\\s*permissions\\s*:" "$FILE" -C 3 || trueRepository: chhoumann/quickadd
Length of output: 12118
🌐 Web query:
actions/create-github-app-token v3.2.0 permission-contents permission-issues input names
💡 Result:
In the actions/create-github-app-token action, permissions are configured by prefixing the relevant GitHub API permission name with permission- (e.g., permission-contents or permission-issues) [1][2]. The inputs for permission-contents and permission-issues function as follows: - permission-contents: Sets the level of permission granted to the access token for repository contents, including commits, branches, downloads, releases, and merges [2]. It can be set to either read or write [3][2]. - permission-issues: Sets the level of permission granted to the access token for issues, including related comments, assignees, labels, and milestones [2]. It can be set to either read or write [3][2]. By default, if no permission-* inputs are provided, the generated token inherits all permissions currently granted to the GitHub App installation [1][4]. It is recommended to explicitly list only the permissions required for your specific use case to follow security best practices [1][2]. The action validates these inputs against the allowed permissions schema [5][2].
Citations:
- 1: https://github.com/actions/create-github-app-token?tab=readme-ov-file
- 2: actions/create-github-app-token@0e0aa99
- 3: https://github.com/actions/create-github-app-token/blob/df432cee/action.yml
- 4: https://github.com/actions/create-github-app-token/blob/34c66235f6ccc38eb01b7aed860890bdf40db33c/README.md
- 5: https://deepwiki.com/actions/create-github-app-token/4.2-permission-system
🌐 Web query:
actions/create-github-app-token supported permission-* keys pull-requests releases
💡 Result:
The actions/create-github-app-token action supports all available GitHub App permission scopes by using inputs prefixed with permission- [1][2][3]. To specify a permission, you replace the underscores in the GitHub API permission name with dashes and prefix it with permission- (e.g., the pull_requests permission becomes permission-pull-requests and issues becomes permission-issues) [1][2]. Most permissions accept read or write as valid values, though specific permissions may have restricted options (e.g., workflows generally supports only write) [4][2][3]. Key points regarding these permissions include: - Default Behavior: If no permission-* inputs are provided, the generated token inherits all permissions currently granted to the GitHub App installation [1][2][3]. - Validation: Selected permissions must be granted to the GitHub App installation; requesting a permission the installation does not possess will result in an error [1][3]. - Mapping: The action internally maps the action input (e.g., permission-pull-requests) to the corresponding GitHub API scope (e.g., pull_requests) [2]. - Best Practice: It is recommended to explicitly list only the permissions required for your specific use case to follow the principle of least privilege [1]. For a complete list of all supported permission keys, you can refer to the action's official action.yml file, which defines these inputs dynamically [4][1][2].
Citations:
- 1: https://github.com/actions/create-github-app-token?tab=readme-ov-file
- 2: https://deepwiki.com/actions/create-github-app-token/4.2-permission-system
- 3: https://deepwiki.com/actions/create-github-app-token/4.1-action-inputs
- 4: https://github.com/actions/create-github-app-token/blob/df432cee/action.yml
Constrain the GitHub App token permissions (least privilege)
actions/create-github-app-token mints an installation token with the GitHub App’s granted permissions; if you omit permission-* inputs, it inherits the App installation’s full scope, and the job-level permissions: block doesn’t reduce that scope. This App token is used for actions/checkout and for semantic-release (via GITHUB_TOKEN), so request only the scopes you need.
Suggested change
- name: Generate release-bot token
id: app-token
uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
with:
app-id: ${{ secrets.RELEASE_APP_ID }}
private-key: ${{ secrets.RELEASE_APP_PRIVATE_KEY }}
+ permission-contents: write
+ permission-issues: write
+ permission-pull-requests: write📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0 | |
| with: | |
| app-id: ${{ secrets.RELEASE_APP_ID }} | |
| private-key: ${{ secrets.RELEASE_APP_PRIVATE_KEY }} | |
| uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0 | |
| with: | |
| app-id: ${{ secrets.RELEASE_APP_ID }} | |
| private-key: ${{ secrets.RELEASE_APP_PRIVATE_KEY }} | |
| permission-contents: write | |
| permission-issues: write | |
| permission-pull-requests: write |
🧰 Tools
🪛 zizmor (1.25.2)
[error] 47-47: dangerous use of GitHub App tokens (github-app): app token inherits blanket installation permissions
(github-app)
🤖 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/release.yml around lines 47 - 50, The GitHub App
installation token creation is granting the App's full installation scopes by
default; update the actions/create-github-app-token step to pass explicit
permission-* inputs limiting scopes to only what actions/checkout and
semantic-release require (for example add permission-contents: write,
permission-metadata: read, permission-actions: read — adjust to your repo’s
actual needs), so replace the current invocation with one that includes those
permission-* inputs to apply least-privilege.
Source: Linters/SAST tools
Allow semver-compatible @types/node patch/minor updates (25.9.3 -> ^25.9.3), consistent with the caret-ranged devDependencies. Verified: frozen-lockfile consistent, tsc build + svelte-check clean.
Summary
Clears all 9 open Dependabot advisories, consolidates the three open Dependabot dependency PRs into one lockfile, and closes a couple of CI/supply-chain gaps. No user-facing behavior changes ship — every advisory was already unreachable, and the edits only update dependency versions/copies. Title is
build(deps):so semantic-release does not cut a release.Supersedes / consolidates: #1322 (svelte security bump), #1323 (dev-deps group), #1324 (svelte-dnd-action) — all closed in favour of this single PR.
Advisories cleared (all medium, all real-risk: none)
obsidian-calendar-ui>svelteoverride; never bundled; shippedsvelte@5.56.3already patchedwebpack-dev-server>sockjs, dev-server only; usesv4(), unaffected branchRoot cause (svelte cluster)
quickadd → obsidian-dataview → obsidian-calendar-ui → svelte. The override"obsidian-calendar-ui>svelte": "^3.59.2"pinned the EOL 3.x, which satisfies every new Svelte advisory's open-lower-bound range. The fix bumps it to^5.56.3so it dedupes onto the already-bundled, already-patched svelte 5.56.3 (only≥5.55.7clears the 2026 set;4.2.19would clear only #41).Changes
Security / advisory fixes
package.json:obsidian-calendar-ui>svelteoverride^3.59.2→^5.56.3docs/package.json: addjoi ^17.13.4,uuid ^11.1.1overridesRoutine dependency bumps (folded from #1323/#1324)
svelte-dnd-action0.9.69 → 0.9.70 (prod, bundled)obsidian1.13.0 → 1.13.1,@types/node25.9.2 → 25.9.3,eslint→ 10.5.0 (dev)CI / supply-chain hardening
docs/**, so docs lockfile bumps were unreviewed); gate raisedhigh → moderate+fail-on-scopes: runtime, developmentactionslanguage (workflow files)Repo settings (applied out-of-band, not in this diff)
CLAUDE_CODE_OAUTH_TOKEN,FACTORY_API_KEY(onlyDISCORD_WEBHOOKremains)Verification (run locally on this branch)
pnpm install --frozen-lockfileconsistent (CI-safe)pnpm why svelte→ 1 version (5.56.3);pnpm audit→ no known vulnerabilities (root + docs)pnpm run buildOK,main.jsbundle has 0svelte/internalrefs (svelte 3 confirmed absent)pnpm run check→ 0 errors;pnpm run test→ 1856 passed / 31 skipped (incl. drag-reorder suites against svelte-dnd-action 0.9.70)docusaurus build→ successNotes / known follow-ups
masterruleset currently enforces onlydeletion/non_fast_forward; making the new check (and CodeQL) required conflicts with the release job's directgithub-actions[bot]push and needs a token-strategy decision (release-via-PR, or a GitHub App/PAT bypass actor) first.getAPIfromobsidian-dataview(src/utils/DataviewIntegration.ts); dropping the runtime dep and resolving Dataview through Obsidian's plugin API would remove the svelte-3 subtree entirely instead of overriding it.joi@17.13.4is the correct 17.x fix; the GHSA's "upgrade to ≥18.2.1" free-text is misleading (two patched lines).uuid8→11 only affectssockjsunderdocusaurus start(dev server);docusaurus buildis unaffected.docs/— a docs override/lockfile change is security-reviewed but not build-tested until release.🤖 Generated with Claude Code
Summary by CodeRabbit