dasel v3.3.1 container indurito

Questo è un pacchetto melange e una immagine container apko per dasel v3.3.1 con una patch in fase di build per CVE-2026-33320 (espansione illimitata degli alias YAML). L'immagine è costruita interamente da un APK prodotto localmente - non viene utilizzata alcuna immagine upstream precompilata.

Prerequisiti

• Architettura: solo x86_64
• Accesso a Internet richiesto per la build iniziale (scarica il tarball dei sorgenti, i moduli Go e i pacchetti Wolfi)

Requisiti Windows

Tutti i comandi di build e caricamento funzionano da qualsiasi terminale (PowerShell, CMD o bash). Un passaggio richiede ancora una shell Unix:

• bash tests/test.sh — lo script di test usa bash e coreutils (timeout, grep, sed)

Installa Git Bash (incluso in Git for Windows) prima di eseguire i test dell'immagine.

Struttura del Progetto

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

Build

Uso di Make

make build        # keygen (if needed) + package + image
make test         # package tests + image tests
make all          # build + test
make clean        # remove all generated artifacts
make help         # list all targets and variables

Comandi manuali

# 1. Generate signing keys (one-time)
docker compose run --rm melange keygen keys/melange.rsa

# 2. Build the APK package (fetches source, applies CVE patch, compiles)
docker compose run --rm melange build melange/dasel.yaml --arch x86_64 --signing-key keys/melange.rsa

# 3. Build the OCI image (consumes the local APK)
docker compose run --rm apko build apko/dasel.yaml dasel:3.3.1 dasel.tar --arch x86_64 --sbom-path sbom/

Il passaggio 2 genera e firma automaticamente packages/x86_64/APKINDEX.tar.gz.

Esecuzione

Dopo aver caricato l'immagine, esegui dasel:

docker load --input dasel.tar

# Example: query a JSON file
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'

Questi flag applicano il livello runtime della strategia di difesa in profondità descritta in Indurimento dell'immagine: un filesystem root immutabile, zero capacità Linux e nessun percorso di escalation dei privilegi.

Test

Uso di Make

make test          # all tests (package + image)
make package-test  # melange package tests only
make image-test    # image tests only (requires bash)

Comandi manuali

# Package tests
docker compose run --rm melange test melange/dasel.yaml --arch x86_64

# Image tests (requires Git Bash on Windows)
docker load --input dasel.tar
bash tests/test.sh

Lo script di test verifica:

• L'immagine viene caricata e dasel version riporta v3.3.1
• Estrazione di chiavi JSON (-i json 'test')
• Conversione da JSON a YAML (-i json -o yaml --root)
• Patch CVE: uno YAML dannoso billion-laughs attiva "yaml expansion budget exceeded" invece di bloccarsi

Fix CVE-2026-33320

La vulnerabilità consente un consumo illimitato di CPU/memoria tramite alias YAML annidati esponenzialmente (attacco billion laughs). La patch in melange/CVE-2026-33320.patch aggiunge due salvaguardie al lettore YAML di dasel: un limite di profondità di espansione (32) che limita l'annidamento ricorsivo degli alias e un budget di espansione (1000) che limita il totale dei dereferenziamenti di alias per documento. Quando viene raggiunto uno dei due limiti, la decodifica restituisce immediatamente un errore.

Sicurezza, Riproducibilità e Minimalità

• Sicurezza: CVE-2026-33320 corretta in fase di build. Tutti i pacchetti sono firmati. L'immagine contiene solo 3 pacchetti APK (wolfi-baselayout, ca-certificates-bundle, dasel)
• Riproducibilità: YAML dichiarativo sia per il pacchetto sia per l'immagine. Tarball dei sorgenti ancorato tramite SHA256. Tutte le versioni degli strumenti documentate. Binario Go compilato con -trimpath per rimuovere i percorsi di build locali
• Minimalità: Nessuna shell, nessun package manager nell'immagine finale - solo il binario dasel, i certificati CA e baselayout

Indurimento dell'immagine

L'immagine applica una difesa in profondità oltre al packaging minimale:

Scansione delle Vulnerabilità

L'immagine costruita (dasel.tar) è stata scansionata con strumenti standard di settore per validare la postura di sicurezza oltre alla patch CVE in sé.

Syft (generazione SBOM)

Syft ha estratto 36 pacchetti dall'immagine ispezionando i metadati dei moduli del binario Go:

• 3 pacchetti APK: wolfi-baselayout 20230201-r29, ca-certificates-bundle 20260413-r0, dasel 3.3.1-r0
• 32 moduli Go: inclusi 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 e altri 25
• 19 file inventariati: /usr/bin/dasel, /etc/ssl/certs/ca-certificates.crt, database APK, SBOM per pacchetto e file di configurazione baselayout

Grype (scanner di vulnerabilità)

Lo SBOM che ho generato è stato esaminato con Grype e non sono state trovate altre vulnerabilità in nessuno dei 32 moduli Go o dei 3 pacchetti APK.

Consegna

Assunzioni

• Solo x86_64 - build a singola architettura. Il multi-arch richiederebbe flag --arch aggiuntivi
• Chiavi di firma usa e getta - generate localmente e ignorate da git. In una configurazione di produzione, le chiavi di firma private dovrebbero essere conservate in un secrets manager, non sul filesystem locale, anche se i file ignorati da git possono essere esposti tramite strumenti di backup, volumi montati nel container o una workstation compromessa.
• Dipendenza da Wolfi OS - la build e l'immagine finale dipendono dai pacchetti Wolfi (busybox, go, ca-certificates-bundle). Se viene scoperta una vulnerabilità in uno di questi pacchetti upstream, interesserebbe anche questa immagine. In produzione sarebbe necessario mantenere aggiornati i pacchetti Wolfi o iscriversi ai loro advisory di sicurezza
• Wrapper Docker Compose - melange e apko vengono eseguiti come container Docker tramite compose.yaml. Sviluppato su Kali 2025.3 e verificato su Windows 10 con Docker Desktop 29.3.1
• Lo script di test richiede bash - tests/test.sh usa timeout (coreutils) e la CLI Docker. Tutti gli altri comandi sono puramente docker e funzionano da PowerShell o CMD. Su Windows, esegui lo script di test da Git Bash (vedi Requisiti Windows)

Lacuna nella copertura SBOM

apko genera automaticamente SBOM SPDX in fase di build nella cartella sbom/ (sbom/sbom-x86_64.spdx.json, sbom/sbom-index.spdx.json). Questi tracciano i 3 pacchetti APK installati con versioni, CPE, provenienza dei sorgenti e riferimenti alle definizioni di build Melange. Tuttavia, non includono le dipendenze dei moduli Go compilate nel binario dasel. Ho deciso di scansionarli e ho usato Syft per colmare questa lacuna estraendo tutti i 32 moduli Go dai metadati incorporati nel binario.

Per l'ambiente di produzione dovrebbe esserci una certa automazione dell'estrazione degli SBOM che esegua un polling periodico. Poi magari allegare i risultati SBOM a qualcosa come https://github.com/nedlir/CVEnotifier che ho scritto in Golang per trovare nuove vulnerabilità nella supply chain.

Comandi eseguiti e risultati

Miglioramenti futuri

• Build multi-arch - supportare più architetture per la costruzione di questo container.

• Pipeline CI/CD - automatizzare build e test in GitHub Actions con le action per container melange/apko

• SBOM a livello Go in melange - eseguire syft durante la pipeline di build melange e incorporare lo SBOM dei moduli Go insieme all'APK