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.
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
|
||||
|
||||
Reference in new issue
Block a user