SonarQube: 129 der 131 Befunde liegen in ci/ - Ausnahme, zwei echte Meldungen, und eine Deckungsluecke #95

New Issue

2026-10-06T23:14:40+02:00

jlab-bot commented

2026-10-06 23:14:40 +02:00

Erste Auswertung der SonarQube-Befunde für JLab-Helm-Charts auf sonar.jk-dev.de, über die API gelesen statt über das Dashboard. Das Ergebnis ist nicht, was die Kopfzahlen behaupten.

sonar-project.properties sagt selbst, wann dieser Moment kommt:

NO EXCLUSIONS, deliberately, for the first round. … If the first run produces noise that is genuinely not worth reading, the exclusions belong here, with the finding they answer named in a comment. Not before: an exclusion written on a guess hides whatever else matched it.

Der erste Lauf hat stattgefunden. Dies ist der Befund, den die Ausnahme beantworten soll.

Die Messwerte

Metrik	Wert
`bugs`	0
`vulnerabilities`	62
`code_smells`	69
`security_hotspots`	0
`security_rating`	3.0 (C)
`reliability_rating`	1.0 (A)
`sqale_rating`	1.0 (A)
`sqale_index`	345 Minuten
`duplicated_lines_density`	0.0
`ncloc` / `files`	17.763 / 198

131 offene Meldungen, alle mit Severity MAJOR: 62 VULNERABILITY, 69 CODE_SMELL.

129 von 131 liegen in `ci/`

Das ist der ganze Befund. Aufgeschlüsselt nach Regel, mit der Stelle, an der sie greift:

Regel	Anzahl	Typ	Meldung	wo
`kubernetes:S6865`	23	VULNERABILITY	„Bind this resource's automounted service account to RBAC or disable automounting."	`ci/`
`kubernetes:S6864`	23	VULNERABILITY	„Specify a memory limit for this container."	`ci/`
`kubernetes:S6873`	23	CODE_SMELL	„Specify a memory request for this container."	`ci/`
`kubernetes:S6897`	23	CODE_SMELL	„Specify a storage request for this container."	`ci/`
`kubernetes:S6892`	23	CODE_SMELL	„Specify a CPU request for this container."	`ci/`
`kubernetes:S6870`	14	VULNERABILITY	„Specify a storage limit for this container."	`ci/`
`kubernetes:S5849`	2	VULNERABILITY	„Make sure setting capabilities is safe here."	`samba`, `calibre-web-automated`

Die fünfmal exakt gleiche 23 ist kein Zufall: es ist einmal pro Fixture-Satz. Das sind die Wegwerf-Postgres-, Redis- und busybox-Deployments aus ci/<chart>/fixtures.yaml, die 90 Sekunden in einem k3d-Cluster leben und dann gelöscht werden. Sie haben bewusst keine Limits, keine Requests und einen automatisch eingehängten Service-Account-Token — es ist Testgerüst.

Das Sicherheits-Rating C dieses Projekts kommt also fast vollständig aus Dateien, die nie ausgerollt werden.

Die zwei echten Meldungen sind dokumentierte Abweichungen

Datei	Zeile
`samba/templates/samba.sfs.yaml`	84
`calibre-web-automated/templates/calibre-web-automated.sfs.yaml`	90

Beide Charts begründen ihre Capabilities ausführlich in der eigenen values.yaml, wie die Konvention es verlangt — samba mit dem Multi-User-Dateiserver, der als root starten muss und je Sitzung den authentifizierten Nutzer annimmt, calibre-web-automated mit der PUID/PGID-Umschreibung des Abbilds. Die Regel ist eine Prüfaufforderung („Make sure … is safe here"), keine Fehlermeldung. Zu tun ist hier nichts am Code, sondern beide in SonarQube als geprüft zu markieren, mit Verweis auf die Begründung im Chart.

Ein Ergebnis, das als Abwesenheit daherkommt und eines ist

sonar-project.properties nennt die Geheimnis-Erkennung „the most valuable analyser here: the premise of this repository is that no credential ever lands in it … and until now nothing checked that premise."

Sie hat über alle Dateien gelaufen und nichts gefunden. Keine einzige Meldung der Geheimnis-Erkennung unter den 131. Die Prämisse des Repositories ist damit erstmals geprüft und nicht nur behauptet. Das gehört festgehalten, weil es sonst niemandem auffällt.

Die Falle in der naheliegenden Behebung

sonar.exclusions=ci/** setzt das Rating auf A und die Zahl auf 2. Und genau das wäre die schlechtere Lage, wenn man dabei nicht ausspricht, was die 2 bedeutet.

Es gibt 164 Chart-Template-Dateien in diesem Repository. Die Kubernetes-Regeln S6864 (Memory-Limit) und S6892 (CPU-Request) sind 23-mal auf Fixtures angesprungen und null Mal auf diesen 164 Dateien. Das ist nicht plausibel als „die Charts erfüllen die Regeln": die Konvention dieses Repositories setzt absichtlich keine CPU-Limits, und Limits werden über einen Helfer berechnet. Im Template steht also

          resources:
            {{- include "samba.effectiveResources" .Values.samba.resources | nindent 12 }}

und der Analysator kann daraus weder ein Limit bestätigen noch sein Fehlen — er schweigt. Zum Vergleich: Sonar meldet 198 analysierte Dateien, im Repo liegen 312 YAML-Dateien.

Die Charts sind also nicht geprüft und sauber, sie sind weitgehend ungeprüft. Eine Ausnahme für ci/** ohne diesen Satz erzeugt ein grünes Projekt, das fast nichts geprüft hat — und das ist die Art falscher Sicherheit, die dieses Repository sonst konsequent benennt.

Vorschlag

1. sonar.exclusions=ci/** in sonar-project.properties, mit dem Befund im Kommentar genannt, wie die Datei es selbst verlangt: 129 von 131 Meldungen, ausschließlich Wegwerf-Gerüst. Dieselbe Begründung trägt schon eine andere Stelle im Repo — renovate.json5 hat matchFileNames: ["ci/**"], enabled: false mit „test scaffolding, not shipped artifacts". Zwei Werkzeuge, dieselbe Einordnung.

2. Die zwei S5849 in SonarQube als geprüft markieren, mit Verweis auf die Begründung in der jeweiligen values.yaml. Kein Code-Eingriff.

3. Die Deckungslücke festhalten und messbar machen. Das ist der eigentliche Folgepunkt, und es gibt im Repo ein Vorbild: ci/run-trivy-config.sh scannt gerenderte Manifeste, nicht Templates, genau weil {{ }} kein YAML ist. Dieselbe Frage stellt sich für Sonar. Zu messen, nicht anzunehmen: einen Chart rendern, die Ausgabe scannen, und die Befundzahl gegen den Template-Scan stellen. Fällt sie deutlich höher aus, ist die Deckungslücke belegt und der Weg klar.

Bis dahin gehört auf die Wiki-Seite CI-CD und in den README-Sonar-Abschnitt — der die gemessene „Runs?"-Tabelle schon trägt — der Satz, dass der Kubernetes-Analysator die Chart-Templates nicht aussagekräftig abdeckt. Ein grünes Sonar-Projekt darf nicht als Aussage über die Charts gelesen werden.

Umfang

sonar-project.properties (eine Ausnahme plus Begründung)
SonarQube-seitig: zwei Meldungen als geprüft markieren — Handarbeit im Dashboard, nicht im Repository
Wiki CI-CD und README-Sonar-Abschnitt: die Deckungslücke
Nicht in diesem Umfang: die Messung aus Punkt 3 und eine etwaige Umstellung auf gerenderte Manifeste. Das ist ein eigenes Vorhaben, sobald die Messung vorliegt.

Nicht geprüft

Die Hotspot-API antwortet mit 403 — der Token hat dort keine Berechtigung. Der Messwert security_hotspots steht allerdings auf 0, es geht also inhaltlich nichts verloren.

Ob die 198 analysierten Dateien gegenüber 312 YAML-Dateien genau die 164 Templates auslassen, ist nicht aufgelöst: die Zahl zählt auch Shell-Skripte, Markdown und JSON mit. Die Aussage „die Templates sind weitgehend ungeprüft" stützt sich auf das Ausbleiben der Ressourcen-Regeln bei gleichzeitig helfer-gerenderten resources-Blöcken, nicht auf diese Differenz.

Erste Auswertung der SonarQube-Befunde für `JLab-Helm-Charts` auf `sonar.jk-dev.de`, über die API gelesen statt über das Dashboard. Das Ergebnis ist nicht, was die Kopfzahlen behaupten. `sonar-project.properties` sagt selbst, wann dieser Moment kommt: > **NO EXCLUSIONS, deliberately, for the first round.** … If the first run produces noise that is genuinely not worth reading, the exclusions belong here, **with the finding they answer named in a comment**. Not before: an exclusion written on a guess hides whatever else matched it. Der erste Lauf hat stattgefunden. Dies ist der Befund, den die Ausnahme beantworten soll. ## Die Messwerte | Metrik | Wert | | --- | --- | | `bugs` | **0** | | `vulnerabilities` | **62** | | `code_smells` | 69 | | `security_hotspots` | 0 | | `security_rating` | **3.0 (C)** | | `reliability_rating` | 1.0 (A) | | `sqale_rating` | 1.0 (A) | | `sqale_index` | 345 Minuten | | `duplicated_lines_density` | 0.0 | | `ncloc` / `files` | 17.763 / 198 | 131 offene Meldungen, **alle** mit Severity `MAJOR`: 62 `VULNERABILITY`, 69 `CODE_SMELL`. ## 129 von 131 liegen in `ci/` Das ist der ganze Befund. Aufgeschlüsselt nach Regel, mit der Stelle, an der sie greift: | Regel | Anzahl | Typ | Meldung | wo | | --- | --- | --- | --- | --- | | `kubernetes:S6865` | 23 | VULNERABILITY | „Bind this resource's automounted service account to RBAC or disable automounting." | `ci/` | | `kubernetes:S6864` | 23 | VULNERABILITY | „Specify a memory limit for this container." | `ci/` | | `kubernetes:S6873` | 23 | CODE_SMELL | „Specify a memory request for this container." | `ci/` | | `kubernetes:S6897` | 23 | CODE_SMELL | „Specify a storage request for this container." | `ci/` | | `kubernetes:S6892` | 23 | CODE_SMELL | „Specify a CPU request for this container." | `ci/` | | `kubernetes:S6870` | 14 | VULNERABILITY | „Specify a storage limit for this container." | `ci/` | | `kubernetes:S5849` | **2** | VULNERABILITY | „Make sure setting capabilities is safe here." | `samba`, `calibre-web-automated` | Die fünfmal exakt gleiche 23 ist kein Zufall: es ist einmal pro Fixture-Satz. Das sind die Wegwerf-Postgres-, Redis- und busybox-Deployments aus `ci/<chart>/fixtures.yaml`, die 90 Sekunden in einem k3d-Cluster leben und dann gelöscht werden. Sie haben bewusst keine Limits, keine Requests und einen automatisch eingehängten Service-Account-Token — es ist Testgerüst. **Das Sicherheits-Rating C dieses Projekts kommt also fast vollständig aus Dateien, die nie ausgerollt werden.** ## Die zwei echten Meldungen sind dokumentierte Abweichungen | Datei | Zeile | | --- | --- | | `samba/templates/samba.sfs.yaml` | 84 | | `calibre-web-automated/templates/calibre-web-automated.sfs.yaml` | 90 | Beide Charts begründen ihre Capabilities ausführlich in der eigenen `values.yaml`, wie die Konvention es verlangt — `samba` mit dem Multi-User-Dateiserver, der als root starten muss und je Sitzung den authentifizierten Nutzer annimmt, `calibre-web-automated` mit der PUID/PGID-Umschreibung des Abbilds. Die Regel ist eine Prüfaufforderung („Make sure … is safe here"), keine Fehlermeldung. **Zu tun ist hier nichts am Code**, sondern beide in SonarQube als geprüft zu markieren, mit Verweis auf die Begründung im Chart. ## Ein Ergebnis, das als Abwesenheit daherkommt und eines ist `sonar-project.properties` nennt die Geheimnis-Erkennung „the most valuable analyser here: the premise of this repository is that no credential ever lands in it … and until now nothing checked that premise." **Sie hat über alle Dateien gelaufen und nichts gefunden.** Keine einzige Meldung der Geheimnis-Erkennung unter den 131. Die Prämisse des Repositories ist damit erstmals geprüft und nicht nur behauptet. Das gehört festgehalten, weil es sonst niemandem auffällt. ## Die Falle in der naheliegenden Behebung `sonar.exclusions=ci/**` setzt das Rating auf A und die Zahl auf 2. **Und genau das wäre die schlechtere Lage**, wenn man dabei nicht ausspricht, was die 2 bedeutet. Es gibt **164 Chart-Template-Dateien** in diesem Repository. Die Kubernetes-Regeln `S6864` (Memory-Limit) und `S6892` (CPU-Request) sind 23-mal auf Fixtures angesprungen und **null Mal** auf diesen 164 Dateien. Das ist nicht plausibel als „die Charts erfüllen die Regeln": die Konvention dieses Repositories setzt **absichtlich keine CPU-Limits**, und Limits werden über einen Helfer berechnet. Im Template steht also ```yaml resources: {{- include "samba.effectiveResources" .Values.samba.resources | nindent 12 }} ``` und der Analysator kann daraus weder ein Limit bestätigen noch sein Fehlen — er schweigt. Zum Vergleich: Sonar meldet 198 analysierte Dateien, im Repo liegen 312 YAML-Dateien. **Die Charts sind also nicht geprüft und sauber, sie sind weitgehend ungeprüft.** Eine Ausnahme für `ci/**` ohne diesen Satz erzeugt ein grünes Projekt, das fast nichts geprüft hat — und das ist die Art falscher Sicherheit, die dieses Repository sonst konsequent benennt. ## Vorschlag **1. `sonar.exclusions=ci/**`** in `sonar-project.properties`, mit dem Befund im Kommentar genannt, wie die Datei es selbst verlangt: 129 von 131 Meldungen, ausschließlich Wegwerf-Gerüst. Dieselbe Begründung trägt schon eine andere Stelle im Repo — `renovate.json5` hat `matchFileNames: ["ci/**"], enabled: false` mit „test scaffolding, not shipped artifacts". Zwei Werkzeuge, dieselbe Einordnung. **2. Die zwei `S5849` in SonarQube als geprüft markieren**, mit Verweis auf die Begründung in der jeweiligen `values.yaml`. Kein Code-Eingriff. **3. Die Deckungslücke festhalten und messbar machen.** Das ist der eigentliche Folgepunkt, und es gibt im Repo ein Vorbild: `ci/run-trivy-config.sh` scannt **gerenderte** Manifeste, nicht Templates, genau weil `{{ }}` kein YAML ist. Dieselbe Frage stellt sich für Sonar. Zu messen, nicht anzunehmen: einen Chart rendern, die Ausgabe scannen, und die Befundzahl gegen den Template-Scan stellen. Fällt sie deutlich höher aus, ist die Deckungslücke belegt und der Weg klar. Bis dahin gehört auf die Wiki-Seite `CI-CD` und in den README-Sonar-Abschnitt — der die gemessene „Runs?"-Tabelle schon trägt — der Satz, dass der Kubernetes-Analysator die Chart-Templates **nicht** aussagekräftig abdeckt. Ein grünes Sonar-Projekt darf nicht als Aussage über die Charts gelesen werden. ## Umfang - `sonar-project.properties` (eine Ausnahme plus Begründung) - SonarQube-seitig: zwei Meldungen als geprüft markieren — Handarbeit im Dashboard, nicht im Repository - Wiki `CI-CD` und README-Sonar-Abschnitt: die Deckungslücke - **Nicht** in diesem Umfang: die Messung aus Punkt 3 und eine etwaige Umstellung auf gerenderte Manifeste. Das ist ein eigenes Vorhaben, sobald die Messung vorliegt. ## Nicht geprüft Die Hotspot-API antwortet mit **403** — der Token hat dort keine Berechtigung. Der Messwert `security_hotspots` steht allerdings auf 0, es geht also inhaltlich nichts verloren. Ob die 198 analysierten Dateien gegenüber 312 YAML-Dateien genau die 164 Templates auslassen, ist **nicht** aufgelöst: die Zahl zählt auch Shell-Skripte, Markdown und JSON mit. Die Aussage „die Templates sind weitgehend ungeprüft" stützt sich auf das Ausbleiben der Ressourcen-Regeln bei gleichzeitig helfer-gerenderten `resources`-Blöcken, nicht auf diese Differenz.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#95

SonarQube: 129 der 131 Befunde liegen in ci/ - Ausnahme, zwei echte Meldungen, und eine Deckungsluecke #95