CI/CD : dependabot, CodeQL, audits bloquants et provenance de build - #10
Merged
Conversation
…uild
Alignement de la chaîne CI/CD sur SnmpLens, qui était nettement mieux outillé
côté analyse, puis ajout de ce qui manquait aux deux.
Repris de SnmpLens
------------------
- dependabot.yml : mises à jour hebdomadaires gomod, npm et github-actions.
C'est ce qui rend les actions épinglées par SHA maintenables — sans lui, un
épinglage gèle une action au commit du jour où il a été écrit, correctifs de
sécurité compris. Les x/* et la chaîne Svelte sont groupés : ces paquets sont
verrouillés les uns aux autres, des PR séparées se cassent mutuellement la CI.
- codeql.yml : analyse Go et JavaScript/TypeScript, requêtes security-and-quality,
plus un passage hebdomadaire. Aucun autre outil ici ne cherche un motif
exploitable dans le code qu'on écrit : go vet et staticcheck cherchent des
erreurs, govulncheck et npm audit des dépendances vulnérables connues. Le cron
compte autant que le déclenchement au push — une requête ajoutée à CodeQL après
qu'un commit a atterri ne le verrait jamais autrement.
- dependency-review sur les PR : bloque l'introduction d'une dépendance portant
un avis de sécurité. govulncheck ne sait pas faire ça, il rapporte sur ce qui
est déjà fusionné.
- govulncheck et npm audit --audit-level=high en CI, sans « || true ».
- staticcheck et vérification que go.mod est tidy.
- wails build sur les trois plateformes. C'est la différence la plus lourde de
conséquences : la CI ne compilait jamais l'application complète, seulement
go vet/test et le build frontend séparément. Elle pouvait donc être verte avec
un wails build cassé, et la casse n'apparaissait qu'au push du tag — c'est-à-dire
quand c'est déjà une release ratée.
Ajouté au-delà des deux projets
-------------------------------
- Attestation de provenance des artefacts (actions/attest-build-provenance).
Elle répond à une question que la signature Ed25519 du manifeste ne couvre
pas : cette signature prouve que les sommes ont été signées par le détenteur de
la clé, pas que les binaires ont été produits par ce dépôt via ce workflow.
Vérifiable sans faire confiance à notre outillage :
gh attestation verify <fichier> --repo Wasabules/SyslogStudio
- persist-credentials: false sur tous les checkouts. Aucun job ne pousse ;
laisser le token dans .git/config l'expose au code tiers exécuté ensuite.
- Groupes de concurrence : les pushes obsolètes d'une même PR sont annulés, ceux
de main jamais — chaque commit de la branche par défaut garde son verdict.
- Actions remontées aux versions courantes (checkout v7, setup-go v7,
setup-node v7, upload-artifact v7, download-artifact v8, gh-release v3).
Pièges rencontrés, et pourquoi le résultat est ce qu'il est
-----------------------------------------------------------
main.go porte //go:embed all:frontend/dist et ce répertoire est gitignoré, donc
tout ce qui compile le paquet main échoue sur « pattern all:frontend/dist: no
matching files found ». staticcheck s'arrête net ; govulncheck est plus insidieux,
il continue et ne rapporte que sur les sous-paquets — main paraissait sain parce
qu'il n'avait jamais été regardé. D'où le placeholder dans les deux jobs.
Même logique sur Linux pour les tags de build : sans libgtk/libwebkit et sans
-tags webkit2_41, les paquets Wails ne compilent pas et disparaissent du scan en
silence. L'étape « Confirm the tree builds before scanning it » est le fil-piège
qui transforme ce faux négatif en échec visible.
Corrige au passage la seule remontée de staticcheck sur l'arbre existant : une
affectation morte dans framing_test.go (SA4006), écrasée à la ligne suivante.
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Alignement de la chaîne CI/CD sur celle de SnmpLens, nettement mieux outillée
côté analyse, puis ajout de ce qui manquait aux deux projets.
Comparatif avant / après
go mod tidyvérifiéwails builden CIpersist-credentials: falseLes trois lignes où SyslogStudio était déjà devant tiennent à l'audit précédent
et sont conservées telles quelles — elles mériteraient d'être reportées sur
SnmpLens, en particulier la signature obligatoire : là-bas
updatersignest unno-op quand le secret est absent, donc une release peut sortir non signée sans
que rien n'échoue, et le manifeste ne porte pas de ligne
version, ce qui laissela porte ouverte au rejeu d'un ancien manifeste validement signé.
La différence qui compte le plus
La CI ne compilait jamais l'application complète — seulement
go vet,go test,svelte-checket le build frontend séparément. Elle pouvait donc êtreverte avec un
wails buildcassé, et la casse n'apparaissait qu'au push du tag,c'est-à-dire quand c'est déjà une release ratée. Le job
buildfait désormais unwails buildréel sur les trois plateformes publiées, ce qui couvre aussi lagénération des bindings.
Provenance de build
actions/attest-build-provenancerépond à une question que la signature Ed25519du manifeste ne couvre pas : cette signature prouve que les sommes ont été signées
par le détenteur de la clé, pas que les binaires proviennent de ce dépôt via ce
workflow. N'importe qui peut désormais vérifier un téléchargement sans faire
confiance à notre outillage :
Deux pièges rencontrés en route
main.goporte//go:embed all:frontend/distet ce répertoire est gitignoré,donc tout ce qui compile le paquet
mainéchoue surpattern all:frontend/dist: no matching files found. staticcheck s'arrête net — visible. govulncheck estplus insidieux : il continue et ne rapporte que sur les sous-paquets, si bien
que
mainparaissait sain parce qu'il n'avait jamais été analysé. D'où leplaceholder dans les deux jobs.
Même logique pour les tags de build sur Linux : sans libgtk/libwebkit et sans
-tags webkit2_41, les paquets Wails ne compilent pas et disparaissent du scanen silence. L'étape « Confirm the tree builds before scanning it » transforme ce
faux négatif en échec visible. Ce piège est également présent dans le job
securityde SnmpLens.Vérifié localement avant push
Les quatre nouveaux contrôles passent sur l'arbre actuel :
go mod tidynemodifie rien,
npm audit --omit=dev --audit-level=highest vert (les avisVite/esbuild sont en dev et n'affectent que
wails dev),govulncheckretournezéro, et
staticcheckest propre après correction de sa seule remontée — uneaffectation morte dans
framing_test.go(SA4006), écrasée à la ligne suivante.