akanealw/Charon
1
0
Fork 0
Code Issues Pull Requests Actions 16 Packages Projects Releases Wiki Activity

fix: harden frontend-builder with npm upgrade to mitigate bundled CVEs

Browse Source
This commit is contained in:
GitHub Actions
2026-03-16 12:26:55 +00:00
parent 5e5eae7422
commit 79800871fa
4 changed files with 337 additions and 515 deletions
Download Patch File Download Diff File Expand all files Collapse all files

472
docs/plans/current_spec.md
View File

@@ -1,301 +1,309 @@
# Fix Plan: Slack Sub-Test Failures in Handler-Level Provider Create Tests
# Fix Plan: 6 HIGH CVEs in node:24.14.0-alpine frontend-builder Stage
**Status:** Active
**Created:** 2026-03-15
**Branch:** `feature/beta-release`
**Scope:** Two failing `go test` sub-tests in the handlers package
**Created:** 2026-03-16
**Branch:** `fix/node-alpine-cve-remediation`
**Scope:** `Dockerfile` — `frontend-builder` stage only
**Previous Plan:** Backed up to `docs/plans/current_spec.md.bak`
---
## 1. Failing Tests
## 1. Introduction
| Test | File | Sub-test | Expected | Actual |
|------|------|----------|----------|--------|
| `TestBlocker3_CreateProviderRejectsNonDiscordWithSecurityEvents` | `notification_provider_blocker3_test.go` | `slack` | `201 Created` | `500 Internal Server Error` |
| `TestDiscordOnly_CreateRejectsNonDiscord` | `notification_provider_discord_only_test.go` | `slack` | `201 Created` | `500 Internal Server Error` |
The `frontend-builder` stage in the multi-stage `Dockerfile` is pinned to:
```dockerfile
# renovate: datasource=docker depName=node
FROM --platform=$BUILDPLATFORM node:24.14.0-alpine@sha256:7fddd9ddeae8196abf4a3ef2de34e11f7b1a722119f91f28ddf1e99dcafdf114 AS frontend-builder
```
Docker Scout (via Docker Hub) and Grype/Trivy scans report **6 HIGH-severity CVEs** in this image. Although the `frontend-builder` stage is build-time only and does not appear in the final runtime image, these CVEs are still relevant for **supply chain security**: CI scans, SBOM attestations, and SLSA provenance all inspect intermediate build stages. Failing to address them causes CI gates to fail and weakens the supply chain posture.
---
## 2. Root Cause Analysis
## 2. Research Findings
### 2.1 Execution Path
### 2.1 Current Image
Both tests are table-driven. For the `slack` row, the request payload is built as:
| Field | Value |
|---|---|
| Tag | `node:24.14.0-alpine` |
| Multi-arch index digest (used in FROM) | `sha256:7fddd9ddeae8196abf4a3ef2de34e11f7b1a722119f91f28ddf1e99dcafdf114` |
| amd64 platform-specific manifest digest | `sha256:e9445c64ace1a9b5cdc60fc98dd82d1e5142985d902f41c2407e8fffe49d46a3` |
| arm64/v8 platform-specific manifest digest | `sha256:0e0d39e04fdf3dc5f450a07922573bac666d28920df2df3f3b1540b0aba7ab98` |
| Base Alpine version | Alpine 3.23 |
| Compressed size (amd64) | 53.63 MB |
| Last pushed on Docker Hub | 2026-02-26 (19 days before research date) |
```go
payload := map[string]interface{}{
"name": "Test Provider",
"type": "slack",
"url": "https://example.com/webhook",
"enabled": true,
// ... (no "token" field)
}
### 2.2 Docker Hub Floating Tag Alignment
`docker manifest inspect node:24-alpine` confirmed on 2026-03-16:
- amd64: `sha256:e9445c64ace1a9b5cdc60fc98dd82d1e5142985d902f41c2407e8fffe49d46a3`
- arm64/v8: `sha256:0e0d39e04fdf3dc5f450a07922573bac666d28920df2df3f3b1540b0aba7ab98`
- s390x: `sha256:965b4135b1067dca4b1aff58675c9b9a1f028d57e30c2e0d39bcd9863605ad62`
The Docker Hub layers page for the amd64 manifest confirms **INDEX DIGEST: `sha256:7fddd9ddeae8196abf4a3ef2de34e11f7b1a722119f91f28ddf1e99dcafdf114`** — exactly matching the digest pinned in the Dockerfile.
**`node:24-alpine`, `node:24-alpine3.23`, and `node:24.14.0-alpine` all resolve to the identical multi-arch index digest.** There is no newer `node:24.x.y-alpine` image on Docker Hub as of 2026-03-16.
### 2.3 CVE Summary
Docker Scout scan of `node:24-alpine` amd64 manifest `sha256:e9445c64ace1...`:
| CVE ID | CVSS | Severity | Package manager | Package | Version |
|---|---|---|---|---|---|
| CVE-2026-26996 | 8.7 | **HIGH** | npm | minimatch | 10.1.2 |
| CVE-2026-29786 | 8.2 | **HIGH** | npm | tar | 7.5.7 |
| CVE-2026-31802 | 8.2 | **HIGH** | npm | tar | 7.5.7 |
| CVE-2026-27904 | 7.5 | **HIGH** | npm | minimatch | 10.1.2 |
| CVE-2026-27903 | 7.5 | **HIGH** | npm | minimatch | 10.1.2 |
| CVE-2026-26960 | 7.1 | **HIGH** | npm | tar | 7.5.7 |
| CVE-2025-60876 | 6.5 | MEDIUM | apk | alpine/busybox | 1.37.0-r30 |
| CVE-2026-22184 | 4.6 | MEDIUM | apk | alpine/zlib | 1.3.1-r2 |
| CVE-2026-27171 | 2.9 | LOW | apk | alpine/zlib | 1.3.1-r2 |
**Total: 0 Critical, 6 High, 2 Medium, 1 Low**
**Docker Scout fixability as of 2026-03-16: 0 Fixable** (no patched versions yet available in Alpine apk repositories or npm registry)
### 2.4 CVE Location Analysis
All **6 HIGH** CVEs are in **npm's own internally-bundled packages**, not in the frontend project's `node_modules`. These packages live inside the image at:
```
/usr/local/lib/node_modules/npm/node_modules/minimatch/ ← CVE-2026-26996, CVE-2026-27904, CVE-2026-27903
/usr/local/lib/node_modules/npm/node_modules/tar/ ← CVE-2026-29786, CVE-2026-31802, CVE-2026-26960
```
The handler `Create()` in `notification_provider_handler.go` passes the bound request to `service.CreateProvider()`.
`minimatch` is used by the npm CLI for glob pattern matching. `tar` is used by npm for `.tgz` tarball extraction during `npm install`/`npm ci`. These are NOT declared in `frontend/package.json`; they are shipped inside the npm CLI binary itself.
### 2.2 Service Enforcement
The **2 MEDIUM + 1 LOW** CVEs are in Alpine OS packages managed by apk:
- `busybox@1.37.0-r30`: CVE-2025-60876
- `zlib@1.3.1-r2`: CVE-2026-22184, CVE-2026-27171
`CreateProvider()` in `notification_service.go` (line ~793) has a mandatory token guard for Slack:
### 2.5 `apk upgrade` Effectiveness
```go
if provider.Type == "slack" {
token := strings.TrimSpace(provider.Token)
if token == "" {
return fmt.Errorf("slack webhook URL is required") // ← triggered
}
if err := s.validateSlackURL(token); err != nil {
return err
}
}
`apk upgrade --no-cache` operates exclusively on Alpine apk-managed packages. It has no effect on files under `/usr/local/lib/node_modules/`.
| CVE set | Fixed by `apk upgrade`? |
|---|---|
| 6 HIGH (npm/minimatch, npm/tar) | **No** — these are npm-managed, not apk-managed |
| 2 MEDIUM + 1 LOW (apk/busybox, apk/zlib) | **Yes, once Alpine maintainers publish patches** — currently 0 fixable per Docker Scout, but the `apk upgrade` step will apply patches automatically when they land |
### 2.6 Renovate Automation
The Dockerfile already carries the correct Renovate comment on the line immediately before the FROM:
```dockerfile
# renovate: datasource=docker depName=node
FROM --platform=$BUILDPLATFORM node:24.14.0-alpine@sha256:7fddd9... AS frontend-builder
```
Because the test payload omits `"token"`, `provider.Token` is empty, and `CreateProvider` returns the error `"slack webhook URL is required"`.
When the Node.js project publishes `node:24.15.0-alpine` (or later) to Docker Hub, Renovate will automatically propose a PR updating the version tag (`24.14.0` → next) and the `@sha256:` digest to the new multi-arch index. That Renovate PR is the **definitive fix path** because the new release will ship npm bundling patched `minimatch` and `tar`.
### 2.3 Handler Error Classifier Gap
### 2.7 Risk Assessment
The handler passes the error to `isProviderValidationError()` (line ~280):
```go
func isProviderValidationError(err error) bool {
errMsg := err.Error()
return strings.Contains(errMsg, "invalid custom template") ||
strings.Contains(errMsg, "rendered template") ||
strings.Contains(errMsg, "failed to parse template") ||
strings.Contains(errMsg, "failed to render template") ||
strings.Contains(errMsg, "invalid Discord webhook URL") ||
strings.Contains(errMsg, "invalid Slack webhook URL")
}
```
The string `"slack webhook URL is required"` matches none of these patterns. The handler falls through to the default 500 branch:
```go
respondSanitizedProviderError(c, http.StatusInternalServerError, "PROVIDER_CREATE_FAILED", "internal", "Failed to create provider")
```
### 2.4 Summary
The production code is correct. Slack providers must have a webhook URL (stored in `token`) at creation time. The Slack webhook URL is architecturally separate from `url` — it is a credential/secret and is stored in `token`, not `url`. The tests are wrong because they supply a `slack` provider type with no `token` field, which the service correctly rejects. The 500 response is a side-effect of `isProviderValidationError` not classifying `"slack webhook URL is required"` as a 400-class validation error, but that is a separate concern; the fix belongs in the tests.
| Risk factor | Assessment |
|---|---|
| Appears in final runtime image | **No** — only the compiled `dist/` output is `COPY`-ed to the final stage |
| Exploitable at runtime | **No** — `npm`, `minimatch`, and `tar` are not present in the final image |
| Exploitable during build | Theoretical (supply chain attack on the build worker) |
| CI scan failures | **Yes** — Grype/Trivy flag build stages; this is the main driver for the fix |
| SBOM/SLSA impact | **Yes** — SBOM includes build-stage packages; HIGH CVEs degrade attestation quality |
---
## 3. Files Involved
## 3. Technical Specification
### Production (no changes needed)
### 3.1 FROM Line — No Change (No Newer Image Available)
| File | Function | Role |
|------|----------|------|
| `backend/internal/api/handlers/notification_provider_handler.go` | `Create()` | Binds request, calls service, returns HTTP response |
| `backend/internal/api/handlers/notification_provider_handler.go` | `isProviderValidationError()` | Classifies service errors for 400 vs 500 routing |
| `backend/internal/services/notification_service.go` | `CreateProvider()` | Enforces Slack token requirement at line ~793 |
| `backend/internal/services/notification_service.go` | `validateSlackWebhookURL()` | Validates `https://hooks.slack.com/services/T.../B.../xxx` regex |
| `backend/internal/services/notification_service.go` | `WithSlackURLValidator()` | Service option to override URL validator in tests |
Since `node:24-alpine` and `node:24.14.0-alpine` resolve to the **same** multi-arch index digest (`sha256:7fddd9...`), there is no newer pinned image to upgrade to. **The FROM line does not change.** Renovate handles future image bumps autonomously.
### Tests (require fixes)
### 3.2 Changes to `frontend-builder` Stage
| File | Test | Change |
|------|------|--------|
| `backend/internal/api/handlers/notification_provider_discord_only_test.go` | `TestDiscordOnly_CreateRejectsNonDiscord` | Add `token` to struct + payload; use `WithSlackURLValidator` |
| `backend/internal/api/handlers/notification_provider_blocker3_test.go` | `TestBlocker3_CreateProviderRejectsNonDiscordWithSecurityEvents` | Add `token` to struct + payload; use `WithSlackURLValidator` |
**Single file changed:** `Dockerfile`
---
**Locations:** Two changes in `Dockerfile`.
## 4. Minimal Fix
**Change A — Top-level ARG (Pinned Toolchain Versions block):**
No production code changes are required. All changes are confined to the two test files.
Add after the existing `ARG XNET_VERSION` line in the `# ---- Pinned Toolchain Versions ----` section:
### 4.1 Established Pattern
The `services` package already uses `WithSlackURLValidator` in 7 tests to bypass the real URL format check in unit tests (`notification_service_test.go` lines 1456, 1482, 1507, 3304, 3334, 3370, 3397 and `notification_service_json_test.go` line 196). The handler tests adopt the same pattern.
### 4.2 Fix for `notification_provider_discord_only_test.go`
**Change 1 — service constructor** (line ~27):
```go
// Before
service := services.NewNotificationService(db, nil)
// After
service := services.NewNotificationService(db, nil,
services.WithSlackURLValidator(func(string) error { return nil }),
)
```diff
# renovate: datasource=go depName=golang.org/x/net
ARG XNET_VERSION=0.51.0
+
+# renovate: datasource=npm depName=npm
+ARG NPM_VERSION=11.11.1
```
**Change 2 — test struct** (line ~33):
**Change B — `frontend-builder` stage (before `RUN npm ci`):**
```go
// Before
testCases := []struct {
name string
providerType string
wantStatus int
wantCode string
}{
{"webhook", "webhook", http.StatusCreated, ""},
{"gotify", "gotify", http.StatusCreated, ""},
{"slack", "slack", http.StatusCreated, ""},
{"telegram", "telegram", http.StatusCreated, ""},
{"generic", "generic", http.StatusBadRequest, "UNSUPPORTED_PROVIDER_TYPE"},
{"email", "email", http.StatusCreated, ""},
}
```diff
# Vite 8: Rolldown native bindings auto-resolved per platform via optionalDependencies
// After
testCases := []struct {
name string
providerType string
token string
wantStatus int
wantCode string
}{
{"webhook", "webhook", "", http.StatusCreated, ""},
{"gotify", "gotify", "", http.StatusCreated, ""},
{"slack", "slack", "https://hooks.slack.com/services/T1234567890/B1234567890/XXXXXXXXXXXXXXXXXXXX", http.StatusCreated, ""},
{"telegram", "telegram", "", http.StatusCreated, ""},
{"generic", "generic", "", http.StatusBadRequest, "UNSUPPORTED_PROVIDER_TYPE"},
{"email", "email", "", http.StatusCreated, ""},
}
+# Upgrade npm to replace its bundled minimatch/tar with patched versions
+# Addresses: CVE-2026-26996, CVE-2026-27903, CVE-2026-27904 (npm/minimatch)
+# CVE-2026-26960, CVE-2026-29786, CVE-2026-31802 (npm/tar)
+# Run apk upgrade for Alpine package CVEs (busybox, zlib) once patches land
+# hadolint ignore=DL3017
+RUN apk upgrade --no-cache && \
+ npm install -g npm@${NPM_VERSION} --no-fund --no-audit && \
+ npm cache clean --force
+
RUN npm ci
```
**Change 3 — payload map** (line ~48):
### 3.3 Step-by-Step Rationale
```go
// Before
payload := map[string]interface{}{
"name": "Test Provider",
"type": tc.providerType,
"url": "https://example.com/webhook",
"enabled": true,
"notify_proxy_hosts": true,
}
| Added command | Rationale |
|---|---|
| `apk upgrade --no-cache` | Applies any Alpine repo patches for busybox (CVE-2025-60876) and zlib (CVE-2026-22184, CVE-2026-27171) without changing the base image pin. Currently 0 fixable per Docker Scout, but will take effect automatically once Alpine maintainers ship packages. |
| `npm install -g npm@${NPM_VERSION} --no-fund --no-audit` | Replaces `/usr/local/lib/node_modules/npm/` (and its bundled `minimatch` + `tar`) with the pinned npm release from the npm registry. `NPM_VERSION` is declared as `11.11.1` in the top-level Pinned Toolchain Versions ARG block and tracked by Renovate's npm datasource manager. `--no-fund` and `--no-audit` suppress log noise during build. If a patched npm has been published since the node image was created, this eliminates the 6 HIGH CVEs. |
| `npm cache clean --force` | Clears npm's cache after the global upgrade to prevent stale entries interfering with the subsequent `npm ci`. |
// After
payload := map[string]interface{}{
"name": "Test Provider",
"type": tc.providerType,
"url": "https://example.com/webhook",
"token": tc.token,
"enabled": true,
"notify_proxy_hosts": true,
}
```
### 3.4 Caveats
### 4.3 Fix for `notification_provider_blocker3_test.go`
**"0 Fixable" status:** Docker Scout reports zero fixable CVEs across all 9 at research time (2026-03-16), meaning patched npm packages are not yet in the registry. The `npm install -g npm@${NPM_VERSION}` step is **defensive** — it will self-apply patches as soon as the npm team publishes a release bundling fixed dependencies. When that release is published, Renovate will propose a bump to `NPM_VERSION` which is all that is needed.
**Change 1 — service constructor** (line ~32):
**Definitive fix:** A new `node:24.x.y-alpine` image from the Node.js release team (bundling a fixed npm version) is the complete resolution. Renovate auto-detects and proposes this update.
```go
// Before
service := services.NewNotificationService(db, nil)
**`npm ci` behavior:** `npm ci` installs project dependencies from `frontend/package-lock.json` and is unaffected by upgrading the global npm executable. The frontend project's own `node_modules` are separate from npm's internal bundled packages.
// After
service := services.NewNotificationService(db, nil,
services.WithSlackURLValidator(func(string) error { return nil }),
)
```
**npm pinning:** `npm@latest` has been replaced with a top-level `ARG NPM_VERSION=11.11.1` tracked by a Renovate npm datasource comment. The ARG is declared in the Pinned Toolchain Versions block alongside `GO_VERSION`, `XNET_VERSION`, etc. Renovate auto-proposes version bumps when a newer npm release is published. The implemented pattern:
**Change 2 — test struct** (line ~35):
```go
// Before
testCases := []struct {
name string
providerType string
wantStatus int
}{
{"webhook", "webhook", http.StatusCreated},
{"gotify", "gotify", http.StatusCreated},
{"slack", "slack", http.StatusCreated},
{"email", "email", http.StatusCreated},
}
// After
testCases := []struct {
name string
providerType string
token string
wantStatus int
}{
{"webhook", "webhook", "", http.StatusCreated},
{"gotify", "gotify", "", http.StatusCreated},
{"slack", "slack", "https://hooks.slack.com/services/T1234567890/B1234567890/XXXXXXXXXXXXXXXXXXXX", http.StatusCreated},
{"email", "email", "", http.StatusCreated},
}
```
**Change 3 — payload map** (line ~50):
```go
// Before
payload := map[string]interface{}{
"name": "Test Provider",
"type": tc.providerType,
"url": "https://example.com/webhook",
"enabled": true,
"notify_security_waf_blocks": true,
}
// After
payload := map[string]interface{}{
"name": "Test Provider",
"type": tc.providerType,
"url": "https://example.com/webhook",
"token": tc.token,
"enabled": true,
"notify_security_waf_blocks": true,
}
```dockerfile
# renovate: datasource=npm depName=npm
ARG NPM_VERSION=11.11.1
# hadolint ignore=DL3017
RUN apk upgrade --no-cache && \
npm install -g npm@${NPM_VERSION} --no-fund --no-audit && \
npm cache clean --force
```
---
## 5. What Is Not Changing
## 4. Implementation Plan
- **`notification_provider_handler.go`** — `Create()` and `isProviderValidationError()` are correct as written.
- **`notification_service.go`** — The Slack token requirement in `CreateProvider()` is correct behavior; Slack webhook URLs are secrets and belong in `token`, not `url`.
- **No new tests** — Existing test coverage is sufficient. The tests just need correct input data that reflects the real API contract.
### Phase 1: Playwright Tests
No new Playwright tests are required. The change is entirely in the Docker build process, not in application behavior. The E2E suite exercises the running application and does not validate build-stage CVEs.
### Phase 2: Dockerfile Change
1. Open `Dockerfile`.
2. In the `# ---- Pinned Toolchain Versions ----` section (approximately line 27), locate `ARG XNET_VERSION` and insert the `NPM_VERSION` ARG immediately after it, as specified in §3.2 Change A.
3. Locate the `# ---- Frontend Builder ----` comment block (approximately line 88).
4. Find the line `# Vite 8: Rolldown native bindings auto-resolved per platform via optionalDependencies`.
5. After that line, insert the new RUN block exactly as specified in §3.2 Change B.
6. Leave all other lines in the `frontend-builder` stage unchanged.
### Phase 3: Build Verification
```bash
# Build frontend-builder stage only (fast, ~2 min)
docker build --target frontend-builder -t charon-frontend-builder-test .
# Confirm npm was upgraded (version should be newer than shipped with node:24.14.0-alpine)
docker run --rm charon-frontend-builder-test npm --version
# Grype scan of the built stage
grype charon-frontend-builder-test --fail-on high
# Trivy scan
trivy image --severity HIGH,CRITICAL --exit-code 1 charon-frontend-builder-test
```
If patched npm packages are in the registry, Grype and Trivy will report 0 HIGH CVEs for npm packages. If patches are not yet published, both scanners will still report the 6 HIGH CVEs (the `npm@${NPM_VERSION}` step installs `11.11.1`; once the npm team ships a patched release, Renovate bumps `NPM_VERSION` to pick it up).
### Phase 4: Full Image Build
```bash
docker buildx build --platform linux/amd64,linux/arm64 -t charon:test .
```
Confirm the final runtime image does not inherit the build-stage CVEs:
```bash
docker scout cves charon:test
```
### Phase 5: Monitor Renovate
No action required. Renovate monitors `node` on Docker Hub via the existing `# renovate: datasource=docker depName=node` comment. When `node:24.15.0-alpine` lands, Renovate opens a PR.
---
## 6. Commit Slicing Strategy
## 5. Commit Slicing Strategy
A single commit and single PR is appropriate. The entire change is two test files, three small hunks each (service constructor, struct definition, payload map). There are no production code changes and no risk of merge conflicts.
**Decision: Single PR.**
The entire change is one file (`Dockerfile`), one stage, three lines added. There are no application code changes, no schema changes, no test changes. A single commit and single PR is appropriate.
### PR-1 — `fix: upgrade npm and apk in frontend-builder to mitigate CVEs`
| Field | Value |
|---|---|
| Branch | `fix/node-alpine-cve-remediation` |
| Files changed | `Dockerfile` (1 file, ~4 lines added) |
| Dependencies | None |
| Rollback | `git revert HEAD` on the merge commit |
**Suggested commit message:**
```
test: supply slack webhook token in handler create sub-tests
fix: upgrade npm and apk in frontend-builder to mitigate node CVEs
The slack sub-tests in TestDiscordOnly_CreateRejectsNonDiscord and
TestBlocker3_CreateProviderRejectsNonDiscordWithSecurityEvents were
omitting the required token field from their request payloads.
CreateProvider enforces that Slack providers must have a non-empty
token (the webhook URL) at creation time. Without it the service
returns "slack webhook URL is required", which the handler does not
classify as a 400 validation error, so it falls through to 500.
The node:24.14.0-alpine image used in the frontend-builder stage
carries 6 HIGH-severity CVEs in npm's internally-bundled packages:
Add a token field to each test struct, populate it for the slack
case with a valid-format Slack webhook URL, and use
WithSlackURLValidator to bypass the real format check in unit tests —
matching the pattern used in all existing service-level Slack tests.
minimatch@10.1.2: CVE-2026-26996 (8.7), CVE-2026-27904 (7.5),
CVE-2026-27903 (7.5)
tar@7.5.7: CVE-2026-29786 (8.2), CVE-2026-31802 (8.2),
CVE-2026-26960 (7.1)
Plus 2 medium and 1 low Alpine CVEs in busybox and zlib.
No newer node:24.x-alpine image exists on Docker Hub as of 2026-03-16.
node:24-alpine resolves to the same multi-arch index digest as the
pinned 24.14.0-alpine tag. Renovate will auto-update the FROM line
when node:24.15.0-alpine is published.
Add a pre-npm-ci RUN step in frontend-builder to:
- Run `apk upgrade --no-cache` to pick up Alpine package patches for
busybox/zlib as soon as they land in the Alpine repos
- Run `npm install -g npm@${NPM_VERSION}` (pinned to `11.11.1`,
Renovate-tracked via npm datasource) to replace npm's bundled
minimatch and tar with patched versions once npm publishes a fix;
Renovate auto-proposes NPM_VERSION bumps when newer releases land
The frontend-builder stage does not appear in the final runtime image
so runtime risk is zero; this change targets supply chain security.
```
**Validation gate:** Docker build exits 0; Grype/Trivy scans of the `frontend-builder` target report 0 HIGH CVEs for npm packages (contingent on npm publishing patched releases).
---
## 7. Verification
## 6. Acceptance Criteria
After applying the fix, run the two previously failing sub-tests:
| # | Criterion | How to verify |
|---|---|---|
| 1 | Docker build succeeds for `linux/amd64` and `linux/arm64` | `docker buildx build --platform linux/amd64,linux/arm64 --target frontend-builder .` exits 0 |
| 2 | No new CVEs introduced | Grype scan of the new build shows no CVEs not already present in the baseline |
| 3 | `apk upgrade` runs without error | Build log shows apk output without error exit |
| 4 | npm version is upgraded | `docker run --rm charon-frontend-builder-test npm --version` shows a version newer than what shipped with node:24.14.0-alpine |
| 5 | `npm ci` still succeeds | Build log shows successful `npm ci` after the upgrade step |
| 6 | Final runtime image is unaffected | `docker scout cves charon:latest` shows no increase in CVE count vs pre-change baseline |
| 7 | Renovate comment preserved | `# renovate: datasource=docker depName=node` remains on the line immediately before the `FROM` |
| 8 | Diagnostic shows 0 HIGH npm CVEs | Grype/Trivy scan of `frontend-builder` target exits 0 with `--fail-on high` once npm publishes patched minimatch/tar |
```bash
cd /projects/Charon/backend
go test ./internal/api/handlers/... \
-run "TestBlocker3_CreateProviderRejectsNonDiscordWithSecurityEvents/slack|TestDiscordOnly_CreateRejectsNonDiscord/slack" \
-v
```
---
Both sub-tests must exit `PASS`. Then run the full handlers suite to confirm no regressions:
## 7. Open Questions / Future Work
```bash
go test ./internal/api/handlers/... -count=1
```
1. **When will `node:24.15.0-alpine` be released?** Node.js 24.x follows a roughly bi-weekly release cadence. Monitor https://github.com/nodejs/node/releases. Renovate handles the FROM update automatically once the image is on Docker Hub.
2. ~~**Pin npm version?**~~ Resolved. `npm@latest` has been replaced with a pinned `ARG NPM_VERSION=11.11.1` in the Pinned Toolchain Versions block, tracked by Renovate's npm datasource manager. No follow-up PR is required.
3. **Should `node:24-alpine3.22` be evaluated?** Switching Alpine base versions to 3.22 would produce a different CVE profile but is inconsistent with the final runtime stage already using `alpine:3.23.3`. Not recommended.