From 2ef3077b37e5a69beb666747d32d05b9a4405519 Mon Sep 17 00:00:00 2001 From: Justin Klein Date: Sun, 27 Sep 2026 11:28:00 +0000 Subject: [PATCH] valkey: name the two Trivy exceptions on the CI section Both are keyword matches on the ConfigMap's comments and shell code, not on data - and a HIGH 'ConfigMap stores secrets' on the one chart built to keep the password out of everything Helm renders is exactly the finding a reader should not take at face value. --- valkey.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/valkey.md b/valkey.md index f921d2a..8e9671b 100644 --- a/valkey.md +++ b/valkey.md @@ -259,6 +259,8 @@ Two limits of that coverage, named so they are not mistaken for tested: - **The machinery runs one variant per chart**, so the non-persistent path is covered by a local render only. - **`fsGroup` itself is not proven.** k3d's `local-path` volumes are node-directory backed and created world-writable, so the container can write whether or not the kubelet applied `fsGroup`. The test proves writability, not the ownership mechanism. (A hostPath PV fixture would be worse: the kubelet does not apply `fsGroup` to those at all.) +The Trivy scan carries two documented exceptions for this chart (`ci/trivy/trivyignore.yaml`), both keyword matches against the ConfigMap's **comments and shell code** rather than data: `KSV-0109` ("ConfigMap stores secrets") matches the probe script's `pass="$(sed …)"` line and a comment containing the word *password*, `KSV-01010` matches the key name `valkey.conf`. The ConfigMap holds no credential — which is the whole reason the password arrives as a mounted Secret file. Worth knowing before the next reader takes the HIGH finding at face value on the one chart designed to avoid it. + ## See also - [Chart style guide](Chart-Style-Guide) — the rules this chart implements