ci(security): bump sonarqube-scan-action to v8.2.0 (Node 24)

[scottschreckengaust]

Bumps SonarSource/sonarqube-scan-action from v6.0.0 to v8.2.0 to stop targeting the deprecated Node.js 20 runtime.

Related

• GitHub Actions deprecation notice: Deprecation of Node 20 on GitHub Actions runners
• Warning observed on the sonarqube job:

  Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24: SonarSource/sonarqube-scan-action@fd88b7d… (v6.0.0)

Changes

• .github/workflows/security-scanners.yml: sonarqube-scan-action fd88b7d… (v6.0.0, using: node20) → 713881670b6b3676cda39549040e2d88c70d582e (v8.2.0, using: node24). SHA-pinned per repo convention.
• .github/workflows/dependency-review.yml: add an allow-dependencies-licenses entry for sonarqube-scan-action (see License note below), and remove the stale commented-out distlib example now that a real entry documents the usage.

Notes / research

• v8.2.0 fixes the warning: its action.yml declares runs: using: node24 (v6.0.0 declared node20).
• Drop-in bump: our usage passes only with: args and env: SONAR_HOST_URL/SONAR_TOKEN, which are unchanged across v6→v8. v7/v8 additions (e.g. scannerBinariesAuthHeader, SONARCLOUD_URL deprecation) don't affect this workflow.
• sonarqube-quality-gate-action intentionally left at v1.2.0: it's a using: composite (bash) action with no Node runtime, so it's unaffected by the Node 20 deprecation — and v1.2.0 is already its latest release.

License / dependency review

Bumping the pinned SHA caused the dependency-review job to re-evaluate the action and block on its LGPL-3.0 license (the org's shared amazon-ospo config allows only permissive licenses).

• The license did not change. sonarqube-scan-action has been LGPL-3.0 since its first commit in 2021 — LICENSE.txt is byte-identical at v6.0.0 and v8.2.0 (same blob). The SHA change simply triggered a fresh review that the pre-existing v6.0.0 pin had never been subjected to.
• Resolution: added allow-dependencies-licenses: "pkg:githubactions/SonarSource/sonarqube-scan-action@713881670b6b3676cda39549040e2d88c70d582e" to dependency-review.yml. Rationale: this is a CI-only action we invoke in the pipeline — not code we distribute or link into the published (Apache-2.0) plugins — so its copyleft terms do not reach our output.
• Version-pinned by SHA on purpose: that is the PURL version dependency-review emits for a SHA-pinned action, and it means any future version bump re-triggers the license review rather than silently inheriting this exception.
• This is a policy waiver of the org-wide permissive-only list; flagging it explicitly for maintainer / OSPO sign-off.

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

Generated with Claude Code

[theagenticguy]

Approve

Verified every load-bearing claim against ground truth (not the PR body):

SHA ↔ version mapping (exact):

• fd88b7d7ccbaefd23d8f36f73b59db7a3d246602 = v6.0.0
• 713881670b6b3676cda39549040e2d88c70d582e = v8.2.0

Node runtime fix confirmed: action.yml runs.using is node20 at v6.0.0 and node24 at v8.2.0. This resolves the deprecation warning.

Drop-in compatibility confirmed: v8.2.0 declares no required inputs (args, projectBaseDir, scannerVersion, scannerBinariesUrl, skipSignatureVerification, scannerBinariesAuthHeader all required: false). The workflow passes only with: args + the two SONAR_* env vars, so the interface is unchanged.

License exception is sound:

• sonarqube-scan-action is LGPL-3.0 (verified via GitHub license API). The copyleft applies to distributed/linked derivative works; a CI-only action invoked in the pipeline is a build tool, not linked into the published Apache-2.0 plugins, so the terms don't reach the output. Justified.
• The allow-dependencies-licenses entry is pinned to the exact SHA PURL, so a future version bump re-triggers the license review instead of silently inheriting the exception. Good fail-safe design.
• Empirical proof it's correct: the dependency-review check is green on the final commit — a mismatched PURL would leave the LGPL-3.0 block firing and fail the job.

Sibling sweep (per our review method): sonarqube-scan-action was the only Node 20 action in security-scanners.yml. Every other uses: is Node 24-era (checkout@v7, upload-artifact@v7, setup-python@v6, codeql-action@v4), and quality-gate-action@v1.2.0 is using: composite (no Node runtime). The deprecation warning won't survive elsewhere. The distlib comment removal is clean scaffolding cleanup.

All 24 checks pass, including dependency-review, sonarqube, semgrep, codeql, checkov, bandit, grype.

Non-blocking nit: the PR body's Changes and Notes sections describe only the security-scanners.yml bump — they don't mention the dependency-review.yml LGPL-3.0 allow-list, which is a license-policy decision worth surfacing in the description for future auditors (the rationale is well-captured in commit 09396a1, just not in the PR summary). Worth a one-line addition, but doesn't block the merge.

[scottschreckengaust]

@theagenticguy thanks for the approve and the thorough ground-truth verification. On your non-blocking nit — the PR body only covered the security-scanners.yml bump and not the dependency-review.yml LGPL-3.0 allow-list — I've updated the description to cover it:

• Changes now lists the dependency-review.yml edit (the allow-dependencies-licenses entry + the stale distlib comment removal).
• Added a License / dependency review section surfacing the LGPL-3.0 decision for future auditors: that the license didn't change (LGPL-3.0 since 2021; byte-identical LICENSE.txt across v6→v8, the SHA bump just triggered a fresh review), the CI-only-invocation rationale, and that the allow-list is SHA-pinned so a future bump re-triggers the review.

So the rationale now lives in the PR summary as well as commit 09396a1.