Conteneur durci dasel v3.3.1

Ceci est un package melange et une image de conteneur apko pour dasel v3.3.1 avec un correctif au moment de la construction pour CVE-2026-33320 (expansion d'alias YAML sans limite). L'image est entièrement construite à partir d'un APK produit localement – aucune image amont préconstruite n'est utilisée.

Prérequis

• Architecture : x86_64 uniquement
• Accès Internet requis pour la construction initiale (télécharge l'archive source, les modules Go, les packages Wolfi)

Prérequis Windows

Toutes les commandes de construction et de chargement fonctionnent depuis n'importe quel terminal (PowerShell, CMD ou bash). Une étape nécessite encore un shell Unix :

• bash tests/test.sh — le script de test utilise bash et coreutils (timeout, grep, sed)

Installez Git Bash (fourni avec Git for Windows) avant d'exécuter les tests de l'image.

Structure du projet

.
├── .github/
├── melange/
│   ├── dasel.yaml
│   └── CVE-2026-33320.patch
├── apko/
│   └── dasel.yaml
├── tests/
│   └── test.sh
├── Makefile
├── compose.yaml
├── keys/                       # Généré, gitignoré
│   ├── melange.rsa
│   └── melange.rsa.pub
├── sbom/                       # Généré, gitignoré
│   ├── sbom-x86_64.spdx.json
│   └── sbom-index.spdx.json
├── packages/                   # Généré, gitignoré
│   └── x86_64/
│       ├── dasel-3.3.1-r0.apk
│       └── APKINDEX.tar.gz
└── README.md

Construction

Utilisation de Make

make build        # keygen (si nécessaire) + package + image
make test         # tests du package + tests de l'image
make all          # construction + test
make clean        # supprime tous les artefacts générés
make help         # liste toutes les cibles et variables

Commandes manuelles

# 1. Générer les clés de signature (unique)
docker compose run --rm melange keygen keys/melange.rsa

# 2. Construire le package APK (télécharge la source, applique le correctif CVE, compile)
docker compose run --rm melange build melange/dasel.yaml --arch x86_64 --signing-key keys/melange.rsa

# 3. Construire l'image OCI (consomme l'APK local)
docker compose run --rm apko build apko/dasel.yaml dasel:3.3.1 dasel.tar --arch x86_64 --sbom-path sbom/

L'étape 2 génère et signe automatiquement packages/x86_64/APKINDEX.tar.gz.

Exécution

Après avoir chargé l'image, exécutez dasel :

docker load --input dasel.tar

# Exemple : interroger un fichier JSON
echo '{"name": "dasel"}' | docker run --rm \
  --read-only \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  -i dasel:3.3.1-amd64 \
  -i json 'name'

Ces drapeaux imposent la couche d'exécution de la stratégie de défense en profondeur décrite dans Durcissement de l'image : un système de fichiers racine immuable, zéro capacité Linux et aucune voie d'escalade de privilèges.

Test

Utilisation de Make

make test          # tous les tests (package + image)
make package-test  # tests du package melange uniquement
make image-test    # tests de l'image uniquement (nécessite bash)

Commandes manuelles

# Tests du package
docker compose run --rm melange test melange/dasel.yaml --arch x86_64

# Tests de l'image (nécessite Git Bash sur Windows)
docker load --input dasel.tar
bash tests/test.sh

Le script de test vérifie :

• L'image se charge et dasel version rapporte v3.3.1
• L'extraction de clé JSON (-i json 'test')
• La conversion JSON vers YAML (-i json -o yaml --root)
• Le correctif CVE : un YAML malveillant « billion-laughs » déclenche "yaml expansion budget exceeded" au lieu de bloquer

Correctif CVE-2026-33320

La vulnérabilité permet une consommation illimitée de CPU/mémoire via des alias YAML imbriqués de manière exponentielle (attaque billion laughs). Le correctif dans melange/CVE-2026-33320.patch ajoute deux garde-fous au lecteur YAML de dasel : une limite de profondeur d'expansion (32) qui limite l'imbrication récursive des alias, et un budget d'expansion (1000) qui limite le nombre total de déréférencements d'alias par document. Lorsque l'une ou l'autre limite est atteinte, le décodage retourne immédiatement une erreur.

Sécurité, reproductibilité et minimalité

• Sécurité : CVE-2026-33320 corrigé au moment de la construction. Tous les packages sont signés. L'image contient seulement 3 packages APK (wolfi-baselayout, ca-certificates-bundle, dasel)
• Reproductibilité : YAML déclaratif pour le package et l'image. Archive source épinglée par SHA256. Toutes les versions des outils documentées. Binaire Go construit avec -trimpath pour supprimer les chemins de construction locaux
• Minimalité : Pas de shell, pas de gestionnaire de packages dans l'image finale – seulement le binaire dasel, les certificats CA et baselayout

Durcissement de l'image

L'image applique une défense en profondeur au-delà de l'empaquetage minimal :

Scan de vulnérabilités

L'image construite (dasel.tar) a été scannée avec des outils standard de l'industrie pour valider la posture de sécurité au-delà du correctif CVE lui-même.

Syft (génération de SBOM)

Syft a extrait 36 packages de l'image en inspectant les métadonnées des modules Go du binaire :

• 3 packages APK : wolfi-baselayout 20230201-r29, ca-certificates-bundle 20260413-r0, dasel 3.3.1-r0
• 32 modules Go : incluant go.yaml.in/yaml/v4, github.com/hashicorp/hcl/v2, github.com/pelletier/go-toml/v2, github.com/goccy/go-json, github.com/charmbracelet/bubbletea, golang.org/x/sys, golang.org/x/text, stdlib go1.25.9, et 25 autres
• 19 fichiers inventoriés : /usr/bin/dasel, /etc/ssl/certs/ca-certificates.crt, base de données APK, SBOM par package et fichiers de configuration baselayout

Grype (scanner de vulnérabilités)

Le SBOM que j'ai généré a été inspecté avec Grype, et aucune autre vulnérabilité n'a été trouvée parmi les 32 modules Go ou les 3 packages APK.

Soumission

Hypothèses

• x86_64 uniquement – construction mono-architecture. Multi-architecture nécessiterait des drapeaux --arch supplémentaires
• Clés de signature jetables – générées localement et gitignorées. Dans un environnement de production, les clés de signature privées devraient être stockées dans un gestionnaire de secrets, pas sur le système de fichiers local. Même les fichiers gitignorés peuvent être exposés via des outils de sauvegarde, des montages de volumes de conteneurs ou un poste de travail compromis.
• Dépendance à Wolfi OS – la construction et l'image finale dépendent des packages Wolfi (busybox, go, ca-certificates-bundle). Si une vulnérabilité est découverte dans l'un de ces packages amont, elle affecterait cette image également. Maintenir les packages Wolfi à jour ou s'abonner à leurs avis de sécurité serait nécessaire en production
• Wrappers Docker Compose – melange et apko sont exécutés en tant que conteneurs Docker via compose.yaml. Ceci a été développé sur Kali 2025.3 et vérifié sur Windows 10 avec Docker Desktop 29.3.1
• Le script de test nécessite bash – tests/test.sh utilise timeout (coreutils) et l'interface CLI Docker. Toutes les autres commandes sont du docker pur et fonctionnent depuis PowerShell ou CMD. Sous Windows, exécutez le script de test depuis Git Bash (voir Prérequis Windows)

Lacune de couverture SBOM

apko génère automatiquement des SBOM SPDX au moment de la construction dans le dossier sbom/ (sbom/sbom-x86_64.spdx.json, sbom/sbom-index.spdx.json). Ceux-ci suivent les 3 packages APK installés avec leurs versions, CPE, provenance des sources et références aux définitions de construction Melange. Cependant, ils n'incluent pas les dépendances de modules Go compilées dans le binaire dasel. J'ai décidé de les scanner et j'ai utilisé Syft pour combler cette lacune en extrayant les 32 modules Go des métadonnées intégrées du binaire.

Pour un environnement de production, il faudrait une certaine automatisation de l'extraction du SBOM qui interrogerait périodiquement. Ensuite, peut-être attacher les résultats du SBOM avec quelque chose comme https://github.com/nedlir/CVEnotifier que j'ai écrit en Golang pour trouver de nouvelles vulnérabilités dans la chaîne d'approvisionnement.

Commandes exécutées et résultats

Améliorations futures

• Constructions multi-architecture – prendre en charge plusieurs architectures pour la construction de ce conteneur.

• Pipeline CI/CD – automatiser la construction + test dans GitHub Actions avec les actions de conteneur melange/apko

• SBOM au niveau Go dans melange – exécuter syft pendant le pipeline de construction melange et intégrer le SBOM des modules Go à côté de l'APK