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.
jklein committed 2026-09-27 11:28:00 +00:00
1 parent d91927d2d0
commit 2ef3077b37
1 file changed
+2
+2
@@ -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