• Arquitetura: x86_64 apenas
• Acesso à Internet necessário para a compilação inicial (descarrega o tarball de origem, módulos Go, pacotes Wolfi)

Requisitos Windows

Todos os comandos de compilação e carregamento funcionam em qualquer terminal (PowerShell, CMD ou bash). Ainda é necessário um shell Unix para um passo:

• bash tests/test.sh — o script de teste usa bash e coreutils (timeout, grep, sed)

Instale o Git Bash (incluído no Git for Windows) antes de executar os testes da imagem.

Estrutura do Projeto

Compilação

Usando Make

Comandos manuais

O passo 2 gera e assina automaticamente packages/x86_64/APKINDEX.tar.gz.

Executar

Após carregar a imagem, execute o dasel:

Estas opções aplicam a camada de runtime da estratégia de defesa em profundidade descrita em Proteção da Imagem: sistema de ficheiros raiz imutável, zero capacidades Linux e sem caminhos de escalada de privilégios.

Teste

Usando Make

Comandos manuais

O script de teste verifica:

• A imagem carrega e dasel version reporta v3.3.1
• Extração de chave JSON (-i json 'test')
• Conversão JSON para YAML (-i json -o yaml --root)
• Correção CVE: YAML malicioso "billion laughs" desencadeia "yaml expansion budget exceeded" em vez de ficar suspenso

Correção CVE-2026-33320

A vulnerabilidade permite consumo ilimitado de CPU/memória através de aliases YAML aninhados exponencialmente (ataque billion laughs). O patch em melange/CVE-2026-33320.patch adiciona duas medidas de segurança ao leitor YAML do dasel: um limite de profundidade de expansão (32) que limita o aninhamento recursivo de aliases, e um orçamento de expansão (1000) que limita o total de desreferências de alias por documento. Quando qualquer limite é atingido, a descodificação retorna um erro imediatamente.

Segurança, Reprodutibilidade e Minimalidade

• Segurança: CVE-2026-33320 corrigido em tempo de compilação. Todos os pacotes são assinados. A imagem contém apenas 3 pacotes APK (wolfi-baselayout, ca-certificates-bundle, dasel)
• Reprodutibilidade: YAML declarativo para pacote e imagem. Tarball de origem fixado por SHA256. Todas as versões de ferramentas documentadas. Binário Go compilado com -trimpath para remover caminhos de compilação locais
• Minimalidade: Sem shell, sem gestor de pacotes na imagem final - apenas o binário dasel, certificados CA e baselayout

Proteção da Imagem

A imagem aplica defesa em profundidade além da embalagem mínima:

Verificação de Vulnerabilidades

A imagem construída (dasel.tar) foi analisada com ferramentas padrão da indústria para validar a postura de segurança além da correção CVE em si.

Syft (geração de SBOM)

O Syft extraiu 36 pacotes da imagem inspecionando os metadados do módulo Go do binário:

• 3 pacotes APK: wolfi-baselayout 20230201-r29, ca-certificates-bundle 20260413-r0, dasel 3.3.1-r0
• 32 módulos Go: incluindo 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 mais 25
• 19 ficheiros inventariados: /usr/bin/dasel, /etc/ssl/certs/ca-certificates.crt, APK DB, SBOMs por pacote, e ficheiros de configuração do baselayout

Grype (scanner de vulnerabilidades)

O SBOM que gerei foi inspecionado com o Grype sem outras vulnerabilidades encontradas em qualquer um dos 32 módulos Go ou 3 pacotes APK.

Submissão

Pressupostos

• Apenas x86_64 - compilação de arquitetura única. Multi-arquitetura exigiria opções --arch adicionais
• Chaves de assinatura descartáveis - geradas localmente e ignoradas pelo git. Numa configuração de produção, as chaves privadas de assinatura devem ser armazenadas num gestor de segredos, não no sistema de ficheiros local. mesmo que ficheiros ignorados pelo git possam ser expostos através de ferramentas de backup, montagens de volumes de contentores ou uma estação de trabalho comprometida.
• Dependência do SO Wolfi - a compilação e a imagem final dependem de pacotes Wolfi (busybox, go, ca-certificates-bundle). Se uma vulnerabilidade for descoberta em algum desses pacotes upstream, afetaria esta imagem também. Manter os pacotes Wolfi atualizados ou subscrever aos seus avisos de segurança seria necessário em produção
• Wrappers Docker Compose - melange e apko são executados como contentores Docker via compose.yaml. Isto foi desenvolvido no Kali 2025.3 e verificado no Windows 10 com Docker Desktop 29.3.1
• Script de teste requer bash - tests/test.sh usa timeout (coreutils) e CLI Docker. Todos os outros comandos são docker puro e funcionam a partir do PowerShell ou CMD. No Windows, execute o script de teste a partir do Git Bash (consulte requisitos Windows)

Lacuna na Cobertura do SBOM

O apko gera automaticamente SBOMs SPDX em tempo de compilação na pasta sbom/ (sbom/sbom-x86_64.spdx.json, sbom/sbom-index.spdx.json). Estes monitorizam os 3 pacotes APK instalados com versões, CPEs, proveniência da fonte e referências à definição de compilação do Melange. No entanto, não incluem dependências de módulos Go compiladas no binário dasel. Decidi analisá-los e usei o Syft para fechar esta lacuna, extraindo todos os 32 módulos Go dos metadados incorporados do binário.

Para ambiente de produção, deveria haver alguma automatização da extração do SBOM que verificasse periodicamente. Depois, talvez anexar os resultados do SBOM com algo como https://github.com/nedlir/CVEnotifier que escrevi em Golang para encontrar vulnerabilidades inéditas na cadeia de fornecimento.

Comandos executados e resultados

Melhorias futuras

• Compilações multi-arquitetura - suportar várias arquiteturas para construir este contentor.

• Pipeline CI/CD - automatizar compilação + teste no GitHub Actions com ações de contentor melange/apko

• SBOM a nível Go no melange - executar syft durante o pipeline de compilação do melange e incorporar o SBOM de módulo Go juntamente com o APK