Address critical Github-Security-Advisories, Add audit CI Check#3376
Address critical Github-Security-Advisories, Add audit CI Check#3376ckeshava wants to merge 3 commits into
Conversation
…y Github Security Advisory
… Security Advisory
WalkthroughA new ChangesSecurity Audit CI and Dependency Overrides
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested reviewers
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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/nodejs.yml:
- Around line 92-94: The workflow contains multiple actions/checkout steps that
do not explicitly disable credential persistence, which creates a security risk.
Add persist-credentials: false as a parameter to each of the four
actions/checkout step occurrences in the workflow to prevent git credentials
from being persisted to disk, since none of the subsequent steps perform
authenticated git operations. This follows the principle of least privilege and
mitigates token exposure risk from artifacts.
- Around line 91-98: Replace the mutable version tags on the `actions/checkout`
and `actions/setup-node` actions with full commit SHAs, adding the original
version tag as a comment for maintainability (format:
`actions/name@<full-commit-sha> # <version-tag>`). Additionally, add
`package-manager-cache: false` to the `actions/setup-node` step configuration to
disable automatic package-manager caching and mitigate cache-poisoning exposure.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 64f36104-3469-4b0f-a349-dba0075a97d5
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (2)
.github/workflows/nodejs.ymlpackage.json
| - uses: actions/checkout@v4 | ||
| with: | ||
| ref: ${{ env.GIT_REF }} | ||
| fetch-depth: 0 | ||
| - name: Use Node.js ${{ matrix.node-version }} | ||
| uses: actions/setup-node@v4 | ||
| with: | ||
| node-version: ${{ matrix.node-version }} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/nodejs.yml | sed -n '80,110p'Repository: XRPLF/xrpl.js
Length of output: 1145
🌐 Web query:
GitHub Actions security best practices pinning commit SHA vs tags 2025
💡 Result:
As of June 2026, pinning GitHub Actions to a full-length commit SHA is the recommended security industry standard to prevent supply chain attacks [1][2][3]. Key Security Principles 1. Immutability: Git tags (e.g., @v4) are mutable references that can be deleted, moved, or recreated by a repository owner to point to a different commit [4][5]. If an action's repository is compromised, an attacker can retarget existing tags to point to malicious code [2][6]. Pinning to a full-length commit SHA provides an immutable reference that guarantees your workflow runs exactly the code you reviewed [4][6][7]. 2. Enforcement: Organizations can now enforce SHA pinning at the enterprise, organization, or repository level [1][2][3]. When enabled, any workflow referencing an action by a mutable tag or branch will fail [1][4]. 3. Recommended Practice: Use full-length commit SHAs for all third-party actions [2][8]. To maintain readability and ease of updates, include the version tag as a comment in your YAML file [2][6]: - uses: actions/checkout@3df4ab1 # v4.0.0 Automation and Maintenance Because pinned SHAs require manual updates to receive fixes, automation is essential for both security and maintenance [2][5]: - Use tools like Renovate or Dependabot to automatically generate pull requests when a new version tag is released, keeping your pinned SHAs up to date [1][2][5]. - When configuring automated tools, ensure they are set to pull updates for review rather than automatically merging, as an attacker could still publish a new, malicious version tag that your automation might otherwise adopt [6][5]. - Tools such as zizmor or CodeQL can be used to audit your workflows and flag any actions that are not currently pinned to a commit SHA [2][8]. While pinning to a tag is more convenient, it should only be considered for internal or highly trusted sources where you accept the risk of mutable references [3][9]. In all other cases, particularly with third-party dependencies, SHA pinning is the primary defense against tag-retargeting attacks [2][6][5].
Citations:
- 1: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 2: https://architecture.lullabot.com/adr/20260505-pin-github-actions-to-hash/
- 3: https://docs.github.com/en/actions/reference/security/secure-use
- 4: https://www.romainlespinasse.dev/posts/github-actions-commit-sha-pinning/
- 5: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability/
- 6: https://safeguard.sh/resources/blog/github-actions-pinning-sha-vs-tag
- 7: https://docs.github.com/en/actions/how-tos/create-and-publish-actions/manage-custom-actions
- 8: https://codeql.github.com/codeql-query-help/actions/actions-unpinned-tag/
- 9: https://github.com/github/docs/blob/962a1c8dccb8c0f66548b324e5b921b5e4fbc3d6/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md
🌐 Web query:
actions/setup-node package-manager-cache false security recommendation
💡 Result:
For the actions/setup-node GitHub Action, the security recommendation is to set package-manager-cache: false in workflows with elevated privileges or that access sensitive information [1][2][3]. This recommendation exists to mitigate the risk of cache poisoning [4][5]. When automatic dependency caching is enabled, an attacker who can influence the workflow could potentially inject malicious content into the build cache [5]. If this poisoned cache is subsequently used in a privileged context—such as a release workflow—it may lead to compromised build artifacts or the exposure of sensitive credentials (including OIDC tokens) to attacker-controlled code [4]. Key points regarding this recommendation: 1. Scope of Risk: The risk is most significant in privileged workflows where the cache might be read or written by processes with access to secrets or the ability to publish packages [4][6]. 2. Default Behavior: Automatic caching for npm is enabled by default if the package.json file includes a packageManager field set to npm (or devEngines.packageManager), unless an explicit cache input is provided [1][7][3]. 3. Implementation: You can explicitly disable this behavior by setting package-manager-cache: false in your workflow YAML configuration [1][8]. 4. Official Guidance: The official actions/setup-node documentation explicitly advises disabling automatic caching in sensitive or elevated contexts when caching is not strictly required for secure operation [1][2][3]. Additionally, it is noted that disabling caching is a standard practice when running workflows without a lockfile [8].
Citations:
- 1: https://github.com/actions/setup-node
- 2: https://github.com/actions/setup-node/blob/v6/README.md
- 3: https://github.com/actions/setup-node/tree/refs/heads/main
- 4: docs: Update caching recommendations to mitigate cache poisoning risks actions/setup-node#1567
- 5: Fix cache poisoning vulnerabilities by disabling package-manager-cache in setup-node github/gh-aw#5214
- 6: Don't cache automatically in privileged workflows actions/setup-node#1358
- 7: https://github.com/actions/setup-node/blob/main/README.md
- 8: https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md
Pin GitHub Actions by commit SHA and disable automatic package-manager caching.
Lines 91 and 96 use mutable tags (@v4), which weakens supply-chain integrity by allowing tag-retargeting attacks if the action repository is compromised. Also, set package-manager-cache: false on actions/setup-node to mitigate cache-poisoning exposure in the audit workflow.
For SHA pinning, use the full commit hash with the version tag as a comment for maintainability (e.g., actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # v4.0.0). Update these pinned SHAs regularly using automation tools like Dependabot or Renovate.
Suggested hardening patch
- - uses: actions/checkout@v4
+ - uses: actions/checkout@<COMMIT_SHA> # v4
with:
ref: ${{ env.GIT_REF }}
fetch-depth: 0
- name: Use Node.js ${{ matrix.node-version }}
- uses: actions/setup-node@v4
+ uses: actions/setup-node@<COMMIT_SHA> # v4
with:
node-version: ${{ matrix.node-version }}
+ package-manager-cache: false🧰 Tools
🪛 zizmor (1.25.2)
[warning] 91-94: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 91-91: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 96-96: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 96-96: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default
(cache-poisoning)
🤖 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/nodejs.yml around lines 91 - 98, Replace the mutable
version tags on the `actions/checkout` and `actions/setup-node` actions with
full commit SHAs, adding the original version tag as a comment for
maintainability (format: `actions/name@<full-commit-sha> # <version-tag>`).
Additionally, add `package-manager-cache: false` to the `actions/setup-node`
step configuration to disable automatic package-manager caching and mitigate
cache-poisoning exposure.
Source: Linters/SAST tools
| with: | ||
| ref: ${{ env.GIT_REF }} | ||
| fetch-depth: 0 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/nodejs.yml | sed -n '85,100p'Repository: XRPLF/xrpl.js
Length of output: 558
🌐 Web query:
GitHub Actions checkout action persist-credentials security best practices
💡 Result:
In GitHub Actions, the persist-credentials input for the actions/checkout action controls whether the action configures the GITHUB_TOKEN or SSH key into the local Git configuration (.git/config) [1][2]. It defaults to true [1][3]. Security Best Practices: 1. Always set persist-credentials: false unless your workflow specifically requires running authenticated git commands (e.g., git push, git commit) [3][4]. 2. Explicitly include this configuration in every actions/checkout step, as omitting the line leaves it enabled by default [3]. 3. Be aware of the "ArtiPACKED" vulnerability: If persist-credentials is true and you subsequently upload the workspace (or the .git directory) as a workflow artifact, the sensitive credentials stored in .git/config may be leaked into that artifact, becoming accessible to anyone with access to the workflow's artifacts [5][6][2]. If your workflow needs to perform authenticated Git operations: - Use the GITHUB_TOKEN with the minimal required permissions (e.g., set permissions: contents: write only where necessary) [7][3]. - If you must persist credentials for other tools, ensure artifact upload steps are strictly scoped to exclude the .git/ directory [8][4]. While recent versions of actions/checkout (such as v6) have improved security by storing credentials in a separate file under $RUNNER_TEMP rather than directly in .git/config, setting persist-credentials: false remains the recommended best practice to adhere to the principle of least privilege and eliminate the risk of accidental credential exposure [1][9].
Citations:
- 1: https://github.com/actions/checkout/?tab=readme-ov-file
- 2: https://sisaku-security.github.io/lint/docs/rules/artipacked/
- 3: https://actsense.dev/vulnerabilities/unsafe_checkout/
- 4: https://actsense.dev/vulnerabilities/artifact_exposure_risk/
- 5: https://yossarian.net/til/post/actions-checkout-can-leak-github-credentials/
- 6: GHSA-3959-6v5q-45q2
- 7: Remove
persist-credentialsor change the default tofalseactions/checkout#485 - 8: [Code Quality] Fix artipacked security issue - Prevent credential persistence in workflow artifacts github/gh-aw#14438
- 9: [security] Escalate concerning default
persist-credentials=trueplease actions/checkout#2312
🏁 Script executed:
cat .github/workflows/nodejs.yml | tail -n +90Repository: XRPLF/xrpl.js
Length of output: 5427
Add persist-credentials: false to all actions/checkout steps.
The workflow contains multiple actions/checkout steps (lines 91-94, 126-129, 170-173, 219-222) that do not explicitly disable credential persistence. Since none of the subsequent steps perform authenticated git operations, credentials should not be persisted to follow the principle of least privilege and mitigate the risk of token exposure through artifacts (ArtiPACKED vulnerability).
Suggested hardening patch
- uses: actions/checkout@v4
with:
ref: ${{ env.GIT_REF }}
fetch-depth: 0
+ persist-credentials: falseApply this change to all four checkout steps in the workflow.
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 91-94: 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/nodejs.yml around lines 92 - 94, The workflow contains
multiple actions/checkout steps that do not explicitly disable credential
persistence, which creates a security risk. Add persist-credentials: false as a
parameter to each of the four actions/checkout step occurrences in the workflow
to prevent git credentials from being persisted to disk, since none of the
subsequent steps perform authenticated git operations. This follows the
principle of least privilege and mitigates token exposure risk from artifacts.
Source: Linters/SAST tools
1 participant
High Level Overview of Change
npm audit fixcommand.Type of Change
Did you update HISTORY.md?
Test Plan
Existing tests pass, no functional change in the APIs / methods of the SDK.