컨테이너 SBOM 자동화 2026, Docker Buildx·Syft·CI 보안 게이트 기준

컨테이너 SBOM은 감사 문서가 아니라 빌드와 배포 사이에 걸어야 할 운영 증거다.

컨테이너 SBOM 자동화를 뒤로 미루면 보안 사고가 난 뒤에야 어떤 패키지가 들어갔는지 역추적하게 된다.

이미지 빌드는 매일 돌아가는데 SBOM 생성은 분기 감사 때만 한다면 취약점 대응 시간과 라이선스 검토 비용이 동시에 늘어난다.

Docker 문서는 BuildKit 기반 빌드에서 SBOM attestation을 만들고 최종 이미지에 SPDX JSON 형태로 붙이는 흐름을 안내한다.

그래서 2026년의 컨테이너 SBOM 자동화는 문서 생성이 아니라 Docker Buildx, Docker Scout, Syft, CI 게이트, 레지스트리 보존 정책을 하나로 묶는 일이다.

핵심 요약

• SBOM은 배포 후 감사 파일이 아니라 빌드 단계에서 생성하고 검증해야 할 증거다.
• Docker Buildx attestation은 이미지와 함께 SBOM을 보관하는 기본 출발점으로 적합하다.
• Syft와 CycloneDX·SPDX 포맷은 도구 독립성과 감사 호환성을 확보하는 보완 축이다.
• Kubernetes 배포 전에는 digest, attestation, 취약점 예외, 라이선스 검토 상태를 게이트로 나눠야 한다.

이 글이 필요한 사람

• 컨테이너 이미지를 매일 빌드하지만 어떤 패키지가 들어가는지 증거를 남기지 못한 플랫폼팀
• Docker Buildx와 GitHub Actions에서 SBOM을 만들고 레지스트리에 붙여야 하는 DevOps 담당자
• Kubernetes 배포 전에 이미지 출처, 취약점, 라이선스 예외를 차단 기준으로 정하려는 보안팀
• SPDX와 CycloneDX 중 어떤 포맷을 감사·조달·취약점 관리에 써야 할지 고르는 구매·컴플라이언스 담당자
• 오픈소스 패키지 이슈가 터질 때 서비스별 영향 범위를 빠르게 찾고 싶은 SRE 리드

컨테이너 SBOM 자동화의 범위

SBOM은 Software Bill of Materials의 약자로 이미지 안의 패키지, 버전, 라이선스, 식별자, 관계를 기계가 읽을 수 있게 기록하는 목록이다.

Docker의 SBOM attestation 문서는 빌드 중 생성한 SBOM이 최종 이미지와 연결될 때 공급망 투명성 확인에 쓸 수 있다고 설명한다.

Docker Scout 문서는 이미지에 SBOM attestation이 있으면 이를 우선 사용하고 없으면 이미지 내용을 인덱싱해 SBOM을 만든다고 설명한다.

Syft는 컨테이너 이미지와 파일시스템에서 SBOM을 만드는 CLI와 라이브러리로 SPDX와 CycloneDX 같은 여러 출력 형식을 지원한다.

이 네 가지를 합치면 컨테이너 SBOM 자동화는 생성, 보관, 검증, 차단, 예외 승인까지 포함하는 운영 파이프라인이다.

도구별 역할을 먼저 나눈다

영역	도구 후보	맡길 일	실패하면 생기는 문제
빌드 중 생성	Docker Buildx SBOM attestation	이미지 빌드와 동시에 SBOM을 만들고 레지스트리에 연결	배포된 digest와 감사 파일의 관계를 나중에 증명하기 어렵다
이미지 분석	Docker Scout	이미지 SBOM 확인과 취약점 분석 흐름에 연결	스캔 결과가 실제 배포 이미지와 다른 시점에 머물 수 있다
도구 독립 생성	Syft	이미지나 파일시스템에서 SPDX·CycloneDX 파일을 별도로 생성	특정 레지스트리나 SaaS에 묶이면 감사 재현성이 약해진다
배포 차단	Kubernetes admission 정책	digest와 attestation 유무를 배포 전 조건으로 확인	SBOM 없는 이미지가 운영 클러스터에 먼저 들어갈 수 있다

한 도구로 모든 문제를 풀려고 하면 초기 설정은 단순하지만 감사와 예외 처리에서 막힌다.

반대로 도구를 너무 많이 섞으면 같은 이미지에 대해 서로 다른 SBOM 파일이 생겨 운영자가 어떤 파일을 믿어야 할지 모르게 된다.

도입 전에는 빌드 도구가 만드는 SBOM을 기준 증거로 삼고 보조 스캐너는 비교와 검증용으로 두는 원칙을 정하는 편이 안전하다.

Buildx attestation은 빌드 시점 증거를 남기는 방법이다

Docker 문서 기준으로 `docker buildx build`에 `--attest type=sbom` 또는 `--sbom=true`를 주면 SBOM attestation을 만들 수 있다.

빌드 중 스캔은 최종 이미지 스캔보다 빌드 단계 의존성까지 더 잘 드러낼 수 있다.

다만 Docker 문서는 기본적으로 최종 stage만 스캔될 수 있고 build context나 추가 stage를 포함하려면 `BUILDKIT_SBOM_SCAN_CONTEXT`와 `BUILDKIT_SBOM_SCAN_STAGE` 같은 설정을 검토해야 한다고 설명한다.

이 조건이면 multi-stage Dockerfile을 쓰는 팀은 최종 stage만 보고 안전하다고 판단하면 안 된다.

로컬에서 먼저 `--output type=local`로 `sbom.spdx.json`이 생성되는지 확인한 뒤 레지스트리 push 흐름에 붙이는 순서가 좋다.

Docker Scout와 Syft는 검증 관점이 다르다

Docker Scout는 Docker 생태계 안에서 이미지 SBOM을 확인하고 분석하는 흐름에 맞춰져 있다.

문서 기준으로 `docker scout sbom IMAGE`는 SBOM을 JSON으로 출력하고 `--format spdx`로 SPDX 출력도 만들 수 있다.

Syft는 Docker 이미지뿐 아니라 디렉터리, 아카이브, 여러 패키지 생태계를 대상으로 SBOM을 만드는 독립 CLI에 가깝다.

Docker 기반 표준 파이프라인이면 Buildx와 Scout로 시작하고, 감사 재현성과 도구 독립성이 필요하면 Syft 결과를 보조 증거로 보관하는 구성이 현실적이다.

두 결과가 다를 때는 어느 쪽이 틀렸다고 바로 단정하지 말고 스캔 대상, stage 범위, 패키지 관리자 인식 차이를 먼저 확인해야 한다.

SPDX와 CycloneDX는 목적이 다르다

포맷	강한 지점	먼저 고를 조건	주의점
SPDX	라이선스와 구성 정보 교환 표준화	조달, 법무, 감사 조직이 라이선스 근거를 요구한다	패키지 관계와 취약점 워크플로는 도구별 보강이 필요할 수 있다
CycloneDX	보안·취약점 관리 시스템과의 연동성	보안팀이 취약점 관리와 위험 추적을 SBOM에 연결한다	조직의 감사 도구가 CycloneDX 버전을 지원하는지 확인해야 한다
둘 다 보관	외부 감사와 내부 보안 대응을 함께 만족	규제, 고객 보안질의, 공급망 계약이 동시에 걸려 있다	저장 비용보다 파일명, digest 매핑, 보존기간 관리가 더 중요하다

SPDX는 시스템 구성과 라이선스 정보 교환을 표준화하는 흐름에 강하다.

CycloneDX는 소프트웨어 생태계 구성, 의존 관계, 취약점 대응 시스템 연동을 강조한다.

처음부터 하나만 고르기 어렵다면 CI에서는 둘 다 생성하되 배포 차단 기준은 하나의 기준 파일로 통일해야 한다.

CI에 붙일 때는 생성보다 검증 순서가 먼저다

Docker의 GitHub Actions 문서는 `docker/build-push-action`에서 SBOM 입력을 true로 두면 SBOM attestation을 추가할 수 있다고 안내한다.

같은 문서에는 attestation을 이미지에 붙이려면 로컬 load가 아니라 레지스트리로 직접 push해야 한다는 조건도 나온다.

또 provenance attestation에는 build argument 값이 포함될 수 있으므로 비밀값을 build argument로 넘기지 말고 secret mount를 쓰라는 경고가 있다.

이 조건이면 CI 보안 게이트는 `SBOM 생성 성공`보다 `비밀값 노출 방지`, `digest 고정`, `파일 보관`, `취약점 예외 승인`을 함께 봐야 한다.

아래 예시는 공식 문서의 흐름을 참고한 스켈레톤이며 실제 registry, 권한, 태그 전략은 조직 정책에 맞게 바꿔야 한다.

name: container-image-sbom

on:
  push:
    branches: [main]

env:
  IMAGE_TAG: ghcr.io/example-org/example-app:replace-with-git-sha

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write

    steps:
      - uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v4

      - name: Login to registry
        uses: docker/login-action@v4
        with:
          registry: ghcr.io
          username: ci-user
          password: registry-token-from-secret-store

      - name: Build and push with SBOM
        uses: docker/build-push-action@v7
        with:
          context: .
          push: true
          tags: ghcr.io/example-org/example-app:replace-with-git-sha
          sbom: true
          provenance: mode=max

      - name: Export SBOM for audit archive
        run: |
          docker buildx imagetools inspect "$IMAGE_TAG" --format '<json .SBOM>' > sbom.spdx.json
          test -s sbom.spdx.json

Kubernetes 배포 전에는 admission 기준으로 바꾼다

Kubernetes admission controller는 API 서버에 저장되기 전 요청을 검사하거나 거부하는 단계다.

SBOM 자체를 Kubernetes 기본 기능만으로 모두 검증한다고 보면 과장이다.

실무에서는 이미지 digest 사용, attestation 존재, 스캐너 통과 결과, 예외 승인 티켓을 admission 정책이나 배포 도구의 사전 조건으로 묶는다.

이 경우 Kubernetes는 SBOM 생성 도구가 아니라 SBOM 없는 이미지가 운영에 들어오지 못하게 하는 마지막 문지기 역할을 맡는다.

관리형 클러스터를 쓰는 팀은 admission 확장 방식, 정책 엔진, 레지스트리 연동 권한, 실패 시 롤백 경로를 먼저 확인해야 한다.

도입 전 비용·보안·운영 판단표

판단 축	바로 도입할 조건	보류할 조건	확인 지표
비용	서비스 수가 많고 이미지별 의존성 추적 시간이 크다	이미지 수가 적고 수동 감사로 충분한 초기 검증 단계다	이미지 수, 월 빌드 수, 취약점 triage 시간
보안	고객 보안질의와 오픈소스 취약점 대응이 반복된다	SBOM 파일을 만들지만 누구도 보지 않는 상태다	critical 취약점 예외, digest 누락률, 비밀값 노출 점검
운영	CI와 레지스트리, Kubernetes 배포 경로가 표준화돼 있다	팀마다 빌드 도구와 태그 전략이 제각각이다	attestation 성공률, 스캔 실패율, 배포 차단 건수
컴플라이언스	라이선스 검토와 공급망 증빙이 계약 조건에 들어간다	포맷과 보존기간을 정하지 못했다	SPDX·CycloneDX 보관률, 감사 샘플 통과율

SBOM 자동화의 비용은 스캐너 가격보다 운영자가 경보를 해석하는 시간에서 커진다.

경보를 줄이려면 base image 정책, 예외 승인 기간, dev dependency 처리 기준, stage 스캔 범위를 먼저 좁혀야 한다.

보안팀은 critical 취약점 차단만 세우기보다 라이선스 미상, 출처 미상 base image, digest 없는 태그를 따로 분리해 봐야 한다.

운영팀은 빌드 실패가 잦을 때 전체 차단으로 가기 전에 warn 모드와 샘플링 리뷰로 튜닝 기간을 잡는 편이 좋다.

실무 시나리오 1: 스타트업의 단일 레지스트리 표준화

스타트업은 서비스 수가 적어도 이미지 태그가 `latest` 위주로 흘러가면 취약점 공지 때 영향 범위를 찾기 어렵다.

이 경우 첫 단계는 모든 배포를 digest 기준으로 고정하고 GitHub Actions에서 Buildx SBOM attestation을 붙이는 것이다.

Syft는 주 1회 전체 이미지에 대해 별도 SPDX와 CycloneDX 파일을 만들어 registry 결과와 차이를 비교하는 용도로 두면 충분하다.

비용을 줄이려면 모든 pull request에서 무거운 스캔을 돌리기보다 main merge와 release tag에서 차단 게이트를 강화하는 방식이 낫다.

이 조건이면 SBOM 자동화는 보안 조직이 없는 팀에서도 장애 대응 시간을 줄이는 운영 장부가 된다.

실무 시나리오 2: 엔터프라이즈의 고객 보안질의 대응

엔터프라이즈는 고객사가 특정 라이브러리 취약점, 오픈소스 라이선스, 공급망 증빙을 한 번에 요구하는 경우가 많다.

이때 SBOM 파일만 모아두면 답변은 빨라지지만 어떤 고객 환경에 어떤 digest가 배포됐는지 모르면 증빙이 끊긴다.

레지스트리 digest, SBOM 파일, 취약점 스캔 결과, 예외 승인 티켓, 배포 이력을 하나의 감사 키로 묶어야 한다.

Kubernetes admission 정책은 SBOM 없는 이미지를 막는 선에서 시작하고 고객별 SLA가 있는 서비스부터 차단 기준을 강화하는 편이 안전하다.

보안팀은 SBOM 보존기간과 고객 답변 템플릿을 정하고 플랫폼팀은 CI 실패 로그와 예외 승인 흐름을 자동화해야 한다.

운영 정책 스켈레톤

아래 YAML은 특정 제품을 강제하는 문서가 아니라 컨테이너 SBOM 자동화 책임과 차단 기준을 나누기 위한 틀이다.

# sbom-required-policy.yaml
# 목적: 컨테이너 이미지가 운영 환경에 들어가기 전 SBOM, 출처, 취약점 게이트를 통과했는지 기록한다.
# 실제 도구명과 차단 기준은 조직의 레지스트리, 스캐너, Kubernetes 배포 방식에 맞게 수정한다.

image_gate:
  required_artifacts:
    - sbom
    - provenance
    - vulnerability_scan_result
  accepted_sbom_formats:
    - spdx-json
    - cyclonedx-json
  allowed_generators:
    - docker-buildx
    - docker-scout
    - syft

registry_policy:
  immutable_tags: true
  digest_required: true
  attestation_required_before_deploy: true
  artifact_retention_days: team_defined

risk_threshold:
  block_if_critical_vulnerability_without_exception: true
  block_if_missing_license_field: review_required
  block_if_unknown_base_image_owner: true
  allow_temporary_exception_days: team_defined

auditing:
  owner: platform-security
  evidence_storage: artifact_repository
  monthly_sample_review: true
  kubernetes_admission_check: staged_rollout

핵심은 SBOM 파일을 만드는 팀과 배포를 승인하는 팀이 달라도 같은 digest와 같은 예외 기준을 보게 만드는 것이다.

정책이 없으면 SBOM은 보안팀 공유 드라이브에 쌓이는 파일이 되고 배포 게이트와 연결되지 않는다.

SBOM 파일 사전 점검 스크립트

CI가 SBOM 파일을 만들었다고 해도 파일이 비어 있거나 포맷이 바뀌면 감사 증거로 쓰기 어렵다.

아래 Python 예시는 SPDX와 CycloneDX JSON의 최소 구조를 확인하는 가벼운 게이트다.

# sbom_ci_guard.py
# 목적: CI에서 생성된 SBOM 파일이 비어 있거나 최소 필드를 잃었을 때 배포를 멈춘다.
# SPDX와 CycloneDX 모두 조직마다 세부 필드가 달라질 수 있으므로 실제 운영 전 샘플 파일로 보정한다.

import json
import sys
from pathlib import Path


def load_json(path):
    data = Path(path).read_text(encoding="utf-8")
    return json.loads(data)


def detect_format(doc):
    if "spdxVersion" in doc or "packages" in doc:
        return "spdx"
    if "bomFormat" in doc or "components" in doc:
        return "cyclonedx"
    return "unknown"


def package_count(doc, fmt):
    if fmt == "spdx":
        return len(doc.get("packages") or [])
    if fmt == "cyclonedx":
        return len(doc.get("components") or [])
    return 0


def main(path):
    doc = load_json(path)
    fmt = detect_format(doc)
    count = package_count(doc, fmt)
    if fmt == "unknown":
        raise SystemExit("SBOM format was not recognized")
    if count < 1:
        raise SystemExit("SBOM contains no packages or components")
    print(f"sbom_gate=pass format={fmt} packages={count}")


if __name__ == "__main__":
    main(sys.argv[1] if len(sys.argv) > 1 else "sbom.spdx.json")

실제 운영에서는 이 스크립트에 허용 라이선스 목록, base image 소유자, critical 취약점 예외 파일, 보존 경로 검증을 추가해야 한다.

검증 스크립트는 취약점 스캐너를 대체하지 않고 SBOM 자동화가 조용히 깨지는 상황을 먼저 막는 안전장치로 두는 편이 맞다.

도입 순서 체크리스트

1. 운영 중인 컨테이너 이미지, registry, CI workflow, Kubernetes 배포 경로를 목록화한다.
2. 이미지 태그가 아니라 digest 기준으로 배포 이력을 남길 수 있는지 확인한다.
3. Docker Buildx로 로컬 SBOM 파일을 만들고 multi-stage 빌드에서 빠지는 stage가 없는지 확인한다.
4. GitHub Actions 또는 사내 CI에서 SBOM attestation과 provenance 생성을 release build에 붙인다.
5. Syft로 독립 SBOM을 만들어 Buildx 결과와 패키지 수, 포맷, 라이선스 필드를 비교한다.
6. 취약점 scanner 결과와 SBOM digest를 같은 artifact 저장소에 보관한다.
7. Kubernetes admission 또는 배포 도구에서 digest, attestation, 스캔 통과 여부를 점진적으로 차단한다.
8. 예외 승인 기간, 담당자, 만료일, 고객 답변 템플릿을 운영 문서에 고정한다.

비용 리스크: 스캔은 무료여도 triage는 무료가 아니다

SBOM과 취약점 스캔을 모든 브랜치와 모든 이미지에서 무제한으로 돌리면 CI 시간과 운영자 triage가 같이 늘어난다.

오탐과 낮은 위험 경보를 정리하지 못하면 개발팀은 SBOM 게이트를 배포 방해 장치로 보기 시작한다.

초기에는 release build와 운영 배포 이미지를 우선하고 dev image와 실험 브랜치는 샘플링이나 warn 모드로 두는 편이 낫다.

비용 회고는 스캐너 청구액보다 취약점 영향 범위 파악 시간, 고객 보안질의 답변 시간, 빌드 실패 재시도 시간을 함께 봐야 한다.

보안 리스크: provenance가 비밀값을 새게 만들 수 있다

Docker의 GitHub Actions 문서는 provenance attestation에 build argument 값이 들어갈 수 있다는 경고를 명시한다.

개발자가 토큰이나 비밀번호를 build argument로 넘겼다면 SBOM 자동화보다 먼저 secret 전달 방식을 고쳐야 한다.

보안팀은 SBOM 파일의 민감도도 분리해야 한다.

패키지 목록 자체가 내부 기술 스택과 취약 지점을 드러낼 수 있으므로 공개 저장소와 고객 제공용 파일은 필드를 다르게 가져갈 수 있다.

운영 리스크: 파일은 있는데 배포와 연결되지 않는 경우

가장 흔한 실패는 CI에는 SBOM 파일이 있지만 운영 클러스터에는 어떤 digest가 배포됐는지 남지 않는 경우다.

이 상태에서는 취약점 공지가 와도 SBOM 파일을 뒤지는 사람과 배포 이력을 뒤지는 사람이 서로 다른 표를 보게 된다.

레지스트리 digest, deployment manifest, SBOM artifact, scanner result를 같은 release id로 묶어야 운영이 단순해진다.

월간 회고에서는 SBOM 생성률보다 SBOM 없는 운영 이미지 수, 예외 만료 초과 건수, digest 없는 태그 사용률을 먼저 보는 편이 실전적이다.

함께 보면 좋은 글

취약점 테스트 자동화 2026, CI 보안 하네스 도입 전 비용·오탐 기준GitHub Actions CI/CD 비용 2026, 러너·캐시·보안 게이트 운영 기준쿠버네티스 운영 비용 2026, 클러스터·노드·로그 비용 줄이는 기준쿠버네티스 관제 대시보드 2026, SRE 운영실 만들기 전 모니터링·알림·권한 기준제로트러스트 보안 도입 2026, Cloudflare One·Entra·Okta 선택 기준데이터 품질 관리 2026, 데이터 플랫폼 도입 전 테스트·계약·모니터링 기준

자주 묻는 질문

컨테이너 SBOM 자동화는 Docker Buildx만 쓰면 충분한가요?

Docker Buildx attestation은 좋은 출발점이지만 감사 재현성과 포맷 호환성을 위해 Syft 같은 독립 생성 결과를 보조 증거로 두는 구성이 안전합니다.

SPDX와 CycloneDX 중 무엇을 먼저 골라야 하나요?

라이선스와 조달 감사가 핵심이면 SPDX를 먼저 보고, 취약점 관리 시스템 연동이 핵심이면 CycloneDX를 먼저 검토하는 편이 현실적입니다.

SBOM을 만들면 취약점 차단까지 자동으로 되나요?

SBOM은 패키지 목록 증거이고 차단은 scanner, 예외 정책, registry, admission 게이트가 함께 있어야 동작합니다.

Kubernetes에서 SBOM 없는 이미지를 바로 막아도 되나요?

초기에는 warn 모드와 핵심 서비스 한정으로 시작하고 digest와 attestation 누락률이 낮아진 뒤 전체 차단으로 넓히는 편이 안전합니다.

SBOM 파일은 어디에 보관해야 하나요?

이미지 digest와 release id로 찾을 수 있는 artifact 저장소에 보관하고 고객 제공용 파일과 내부 분석용 파일의 공개 범위를 분리해야 합니다.

개발팀 반발을 줄이려면 어떤 기준부터 적용해야 하나요?

처음부터 모든 취약점을 막지 말고 critical 취약점, digest 누락, SBOM 누락, 만료된 예외처럼 설명 가능한 기준부터 차단하는 편이 좋습니다.

출처와 확인일

• Docker Blog — SBOM Generation for Container Workflows (확인일: 2026-07-16)
• Docker Docs — SBOM attestations (확인일: 2026-07-16)
• Docker Docs — Docker Scout SBOMs (확인일: 2026-07-16)
• Docker Docs — Add SBOM and provenance attestations with GitHub Actions (확인일: 2026-07-16)
• Anchore Syft — CLI tool for generating SBOMs (확인일: 2026-07-16)
• CycloneDX — Software Bill of Materials capability (확인일: 2026-07-16)
• SPDX — SPDX overview (확인일: 2026-07-16)
• Kubernetes Docs — Admission Control in Kubernetes (확인일: 2026-07-16)

위 출처는 2026-07-16 기준으로 확인했으며 Docker 명령, GitHub Actions 버전, SBOM 포맷, Kubernetes 정책 방식은 이후 바뀔 수 있습니다.

이 글은 일반적인 기술 검토 자료이며 실제 보안 차단, 라이선스 판단, 고객 계약 조건은 공식 문서와 조직 내부 정책을 기준으로 결정해야 합니다.

Tech in Depth 더 보기

AI·개발·클라우드·보안 글 전체 목록에서 관련 글을 더 확인할 수 있습니다.

전체 글 목록 보기