dasel v3.3.1 강화 컨테이너

이것은 CVE-2026-33320 (무제한 YAML 별칭 확장)에 대한 빌드 시 패치가 적용된 dasel v3.3.1용 melange 패키지 및 apko 컨테이너 이미지입니다. 이미지는 로컬에서 생성된 APK로 완전히 빌드되며, 사전 빌드된 업스트림 이미지를 사용하지 않습니다.

전제 조건

• 아키텍처: x86_64 전용
• 초기 빌드에는 인터넷 접속 필요 (소스 tarball, Go 모듈, Wolfi 패키지 다운로드)

Windows 요구 사항

모든 빌드 및 로드 명령은 모든 터미널(PowerShell, CMD 또는 bash)에서 작동합니다. 한 단계는 여전히 Unix 셸이 필요합니다.

• bash tests/test.sh — 테스트 스크립트는 bash와 coreutils(timeout, grep, sed)를 사용합니다.

이미지 테스트를 실행하기 전에 Git Bash (Git for Windows 포함)를 설치하세요.

프로젝트 구조

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

빌드

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

수동 명령어

# 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/

2단계는 자동으로 packages/x86_64/APKINDEX.tar.gz를 생성하고 서명합니다.

실행

이미지를 로드한 후 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'

이 플래그들은 이미지 강화에서 설명된 심층 방어 전략의 런타임 계층을 적용합니다: 불변의 루트 파일시스템, 제로 Linux 능력, 권한 상승 경로 없음.

테스트

Make 사용

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

수동 명령어

# 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

테스트 스크립트는 다음을 확인합니다:

• 이미지 로드 및 dasel version이 v3.3.1을 보고
• JSON 키 추출 (-i json 'test')
• JSON에서 YAML로 변환 (-i json -o yaml --root)
• CVE 패치: 악의적인 billion-laughs YAML이 중단 대신 "yaml expansion budget exceeded"를 트리거

CVE-2026-33320 수정

이 취약점은 지수적으로 중첩된 YAML 별칭(billion laughs 공격)을 통해 무제한 CPU/메모리 소비를 허용합니다. melange/CVE-2026-33320.patch의 패치는 dasel의 YAML 리더에 두 가지 보호 장치를 추가합니다: 재귀 별칭 중첩을 제한하는 확장 깊이 제한(32)과 문서당 총 별칭 역참조를 제한하는 확장 예산(1000)입니다. 어느 한계에 도달하면 디코딩이 즉시 오류를 반환합니다.

보안, 재현성 및 최소성

• 보안: CVE-2026-33320이 빌드 시 패치됨. 모든 패키지가 서명됨. 이미지에는 3개의 APK 패키지(wolfi-baselayout, ca-certificates-bundle, dasel)만 포함됨.
• 재현성: 패키지와 이미지 모두 선언적 YAML 사용. 소스 tarball이 SHA256으로 고정됨. 모든 도구 버전이 문서화됨. Go 바이너리는 -trimpath로 빌드되어 로컬 빌드 경로 제거.
• 최소성: 최종 이미지에 셸, 패키지 관리자 없음 - dasel 바이너리, CA 인증서, baselayout만 있음.

이미지 강화

이미지는 최소 패키징을 넘어 심층 방어를 적용합니다:

취약점 스캔

빌드된 이미지(dasel.tar)는 CVE 패치 자체를 넘어 보안 태세를 검증하기 위해 업계 표준 도구로 스캔되었습니다.

Syft (SBOM 생성)

Syft는 Go 바이너리의 모듈 메타데이터를 검사하여 이미지에서 36개 패키지를 추출했습니다:

• 3개의 APK 패키지: wolfi-baselayout 20230201-r29, ca-certificates-bundle 20260413-r0, dasel 3.3.1-r0
• 32개의 Go 모듈: 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 및 25개 더 포함
• 19개 파일 목록: /usr/bin/dasel, /etc/ssl/certs/ca-certificates.crt, APK DB, 패키지별 SBOM 및 baselayout 설정 파일

Grype (취약점 스캐너)

생성된 SBOM은 Grype로 검사되었으며, 32개의 Go 모듈 또는 3개의 APK 패키지에서 다른 취약점이 발견되지 않았습니다.

제출

가정

• x86_64 전용 - 단일 아키텍처 빌드. 다중 아키텍처는 추가 --arch 플래그가 필요함.
• 일회용 서명 키 - 로컬에서 생성되고 gitignore 처리됨. 프로덕션 환경에서는 개인 서명 키를 로컬 파일시스템이 아닌 시크릿 매니저에 저장해야 합니다. gitignore 처리된 파일이라도 백업 도구, 컨테이너 볼륨 마운트 또는 손상된 워크스테이션을 통해 노출될 수 있습니다.
• Wolfi OS 종속성 - 빌드 및 최종 이미지는 Wolfi 패키지(busybox, go, ca-certificates-bundle)에 의존함. 이러한 업스트림 패키지에서 취약점이 발견되면 이 이미지에도 영향을 미칩니다. 프로덕션에서는 Wolfi 패키지를 최신 상태로 유지하거나 보안 권고를 구독하는 것이 필요합니다.
• Docker Compose 래퍼 - melange와 apko는 compose.yaml을 통해 Docker 컨테이너로 실행됨. Kali 2025.3에서 개발되었으며 Windows 10 + Docker Desktop 29.3.1에서 확인됨.
• 테스트 스크립트는 bash 필요 - tests/test.sh는 timeout(coreutils) 및 Docker CLI를 사용함. 다른 모든 명령어는 순수 docker이며 PowerShell 또는 CMD에서 작동함. Windows에서는 Git Bash에서 테스트 스크립트를 실행하세요 (Windows 요구 사항 참조).

SBOM 적용 범위 격차

apko는 빌드 시 sbom/ 폴더에 SPDX SBOM을 자동으로 생성합니다 (sbom/sbom-x86_64.spdx.json, sbom/sbom-index.spdx.json). 이는 설치된 3개의 APK 패키지의 버전, CPE, 소스 출처 및 Melange 빌드 정의 참조를 추적합니다. 그러나 dasel 바이너리에 컴파일된 Go 모듈 종속성은 포함하지 않습니다. 이 격차를 해소하기 위해 Syft를 사용하여 바이너리의 임베디드 메타데이터에서 모든 32개의 Go 모듈을 추출했습니다.

프로덕션 환경에서는 주기적으로 폴링하는 SBOM 추출 자동화가 필요합니다. 그런 다음 공급망에서 새로운 취약점을 찾기 위해 Golang으로 작성한 https://github.com/nedlir/CVEnotifier와 같은 도구에 SBOM 결과를 연결할 수 있습니다.

실행된 명령어 및 결과

향후 개선 사항

• 다중 아키텍처 빌드 - 이 컨테이너 빌드를 위해 여러 아키텍처 지원.
• CI/CD 파이프라인 - melange/apko 컨테이너 액션을 사용하여 GitHub Actions에서 빌드 + 테스트 자동화.
• melange에서 Go 수준 SBOM - melange 빌드 파이프라인 중 syft를 실행하고 APK와 함께 Go 모듈 SBOM을 포함.