컨테이너 이미지 취약점 스캐닝과 SBOM 가이드: 작은 팀도 운영 가능한 DevSecOps 기준 > 인사이트

본문 바로가기

인사이트

#클라우드·DevOps

컨테이너 이미지 취약점 스캐닝과 SBOM 가이드: 작은 팀도 운영 가능한 DevSecOps 기준

컨테이너 이미지 취약점 스캐닝과 SBOM 운영을 보여주는 DevSecOps 대시보드
작은 팀의 DevSecOps는 도구 수보다 배포 전 차단 기준과 release 증적 관리가 중요합니다.

결론부터 말하면, 작은 Docker·Kubernetes 운영팀이 처음부터 모든 CVE를 배포 차단 대상으로 삼을 필요는 없습니다. 대신 최종 컨테이너 이미지 digest 기준으로 취약점 스캔을 자동 실행하고, 같은 release 단위로 SBOM, 스캔 리포트, 예외 승인 기록을 남기는 것이 최소 운영 기준입니다. 기본 차단선은 Critical, 그리고 수정 버전이 존재하거나 실제 공격 가능성이 높은 High부터 시작하는 편이 현실적입니다.

SBOM은 ‘있으면 좋은 문서’가 아니라 특정 버전의 소프트웨어가 무엇으로 구성됐는지 추적하는 release 증적입니다. 이미지 스캐너는 현재 알려진 취약점을 찾는 도구이고, SBOM은 나중에 새 CVE가 공개되거나 고객사가 보안 질의를 보냈을 때 영향을 빠르게 판정하기 위한 목록입니다. 두 가지를 분리해서 이해해야 경고 폭탄과 문서 업무 사이에서 팀이 멈추지 않습니다.

작은 팀의 1차 목표는 보안 조직을 흉내 내는 것이 아니라, 배포 전 위험을 어느 기준에서 멈추고 어떤 예외를 누가 승인했는지 반복 가능하게 만드는 것입니다.

1. 왜 지금 컨테이너 이미지 스캔과 SBOM을 같이 봐야 하나

컨테이너 기반 서비스는 애플리케이션 코드만 배포하지 않습니다. 베이스 이미지의 OS 패키지, 언어 런타임, 패키지 매니저 의존성, 빌드 과정에서 남은 유틸리티까지 하나의 이미지에 들어갑니다. 따라서 package.json이나 requirements.txt만 점검하면 운영 이미지의 실제 위험을 놓칠 수 있습니다.

국내에서도 SBOM 기반 공급망 보안은 실험 주제가 아니라 정책·지원사업의 언어로 들어오고 있습니다. KISA는 2026년 공급망 보안 모델 구축 지원사업 공고에서 SBOM을 활용한 공급망 보안 모델 구축을 사업 목적으로 제시했고, 공고 기준 총 28억 원 규모로 8개 과제를 지원한다고 안내했습니다. 또한 과기정통부와 KISA 주관의 SBOM 기반 공급망 보안 모델 구축 사례집도 2026년 4월 발행 자료로 등록돼 있습니다. ([kisa.or.kr](https://www.kisa.or.kr/401/form?lang_type=KO&page=2&postSeq=3616&utm_source=openai))

해외 기준도 방향은 비슷합니다. CISA의 SBOM 최소 요소 문서는 소프트웨어 버전이나 업데이트마다 연결된 SBOM을 생성하고, 가능한 transitive dependency까지 포함하며, 의도적으로 알 수 없거나 누락된 항목은 Known Unknowns로 식별하라고 설명합니다. NIST SSDF는 보안 개발 관행을 SDLC에 통합하고 취약점 리스크를 줄이기 위한 공통 언어로 제시됩니다. ([cisa.gov](https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf?utm_source=openai))

스타트업이나 정부지원사업으로 MVP를 만든 팀 입장에서는 이 흐름을 과장해서 받아들일 필요는 없습니다. 다만 공공·대기업 납품, 보안 설문, SaaS 고객 실사, 투자사 기술 DD에서 ‘배포 이미지의 취약점은 어떻게 확인하나요’, ‘SBOM을 제공할 수 있나요’라는 질문이 나왔을 때 아무 기록도 없는 상태는 피해야 합니다.

2. 최소 운영 기준: 작은 팀은 이 표부터 정하면 됩니다

운영 항목왜 필요한가작은 팀 기본값주의할 점
스캔 대상소스 의존성이 아니라 실제 배포 이미지 위험을 확인최종 이미지 digest 기준으로 스캔latest 태그 기준 스캔은 재현성이 약함
SBOM 생성나중에 새 CVE나 고객 질의 발생 시 영향 범위 확인release마다 CycloneDX JSON 또는 SPDX JSON 생성생성만 하고 release와 연결하지 않으면 감사 대응에 약함
배포 차단치명적 위험의 운영 반영을 막기 위함Critical, 수정 버전 있는 High 우선 차단모든 Medium까지 막으면 배포가 자주 멈춤
예외 승인패치 불가·오탐·미사용 코드 등 현실적 상황 처리담당자, 만료일, 근거, 보완조치 기록만료 없는 allowlist는 사실상 방치
보관고객사·감사·장애 후 추적에 필요이미지 digest, SBOM, 스캔 리포트, 예외 티켓 묶음 보관CI artifact 단기 보관만으로는 부족할 수 있음
재스캔새 CVE는 배포 후에도 발견됨운영 이미지 또는 SBOM을 주기적으로 재스캔빌드 시점 통과가 영구 안전을 의미하지 않음

이 기준은 보안 전담자가 없는 팀에서도 운영할 수 있어야 합니다. ‘누가 매일 리포트를 읽을 것인가’보다 ‘CI가 언제 멈추고, 예외는 어떤 티켓으로 남고, 다음 릴리스에서 무엇을 고칠 것인가’를 먼저 정해야 합니다.

3. CI/CD에 넣는 순서: 스캔은 최종 이미지 기준, 기록은 release 기준

CI/CD에서 이미지 스캔과 SBOM 생성을 자동화하는 워크플로우
스캔은 최종 이미지 기준, 증적은 release 기준으로 남겨야 운영과 감사 대응이 이어집니다.

권장 흐름은 단순합니다. 소스코드가 main 브랜치에 병합되고 이미지가 빌드되면, 그 이미지의 digest를 확정합니다. 이후 같은 digest에 대해 SBOM을 생성하고 취약점 스캔을 수행합니다. 기준을 넘는 항목이 있으면 배포를 막고, 기준 미만이거나 승인된 예외라면 registry에 push하고 배포합니다.

  1. 베이스 이미지 선택: 공식 이미지라 해도 태그만 믿지 말고 digest pinning을 검토합니다. slim, distroless, 최소 패키지 이미지는 CVE 노출면을 줄이는 데 도움이 되지만 디버깅 편의성과 트레이드오프가 있습니다.
  2. 이미지 빌드: 멀티스테이지 빌드를 사용해 빌드 도구와 테스트 도구가 런타임 이미지에 남지 않도록 합니다.
  3. SBOM 생성: 이미지 digest와 함께 SBOM 파일명을 남깁니다. 예: 서비스명, 버전, git commit, image digest, 생성일.
  4. 취약점 스캔: OS 패키지와 애플리케이션 패키지를 함께 확인합니다. 스캐너 DB 갱신 시점과 도구 버전도 기록합니다.
  5. 정책 판정: Critical·High 기준, 수정 버전 존재 여부, 예외 승인 여부를 기준으로 fail 또는 pass를 결정합니다.
  6. 증적 저장: SBOM, 스캔 리포트, 예외 승인 티켓 URL, 배포 승인자를 release evidence로 저장합니다.
  7. 배포: Kubernetes manifest에는 태그보다 digest를 사용하는 방향으로 전환합니다.

이미 GitOps를 운영 중이라면 이미지 스캔과 SBOM 생성은 배포 저장소에 변경이 반영되기 전 단계에 두는 것이 좋습니다. 배포 승인 흐름 자체가 아직 없다면 GitOps로 하는 소규모 팀 배포 자동화에서 설명한 것처럼 배포 선언과 실제 배포를 분리한 뒤 보안 게이트를 추가하는 순서가 부담이 적습니다.

파이프라인 단계실행 작업실패 기준 예시남길 증적
Pull Request언어 의존성 빠른 검사새 Critical 직접 의존성 추가PR 코멘트
Image Build이미지 빌드와 digest 산출빌드 실패, 금지된 베이스 이미지image digest, Dockerfile
Security GateSBOM 생성, 취약점 스캔Critical, 수정 가능 HighSBOM, scan report
Exception Review예외 티켓 확인만료된 예외, 근거 없는 예외승인자, 만료일, 보완조치
Deploydigest 기반 배포스캔되지 않은 digest배포 이력, 승인 로그

4. 배포 차단 기준: 모든 High를 막으면 오래 못 갑니다

컨테이너 스캔을 처음 붙이면 대부분의 팀이 같은 문제를 겪습니다. 경고가 너무 많고, 같은 이미지도 도구나 DB 갱신 시점에 따라 결과가 달라지며, 베이스 이미지에서 온 취약점은 당장 고칠 방법이 제한적입니다. 그래서 차단 정책은 보안 이상론이 아니라 운영 가능한 기준이어야 합니다.

등급권장 기본 정책처리 기준예외 가능 여부
Critical기본 차단수정 버전 적용, 베이스 이미지 교체, 영향 없음 입증가능하나 CTO·보안 책임자급 승인 권장
High조건부 차단수정 버전 존재, 네트워크 노출, 인증 우회·RCE 가능성 우선가능, 만료일 필수
Medium알림 및 백로그월간 패치 윈도우 또는 다음 스프린트 반영대부분 배포 차단 대상 아님
Low/Unknown기록추세 확인, 고객 요구 시 설명일반적으로 차단하지 않음

중요한 것은 ‘High니까 무조건 차단’이 아니라 ‘서비스에 실제로 영향을 줄 가능성이 높은 High를 차단’하는 것입니다. 예를 들어 런타임에 사용하지 않는 패키지, 공격 경로가 막힌 내부 도구, 패치가 아직 제공되지 않은 OS 패키지는 예외가 필요할 수 있습니다. 반대로 외부 요청을 처리하는 웹 프레임워크, 인증·세션 라이브러리, TLS·압축·이미지 처리 라이브러리의 Critical/High는 우선순위를 높여야 합니다.

예외 승인은 이렇게 남겨야 합니다

  • CVE ID와 패키지명, 현재 버전, 감지된 이미지 digest
  • 스캐너 이름, 스캐너 버전, 취약점 DB 갱신 시점
  • 수정 버전 존재 여부와 적용 불가 사유
  • 서비스 영향 판단: 해당 코드가 실제 호출되는지, 외부 노출 여부, 권한 요구 조건
  • 보완조치: 네트워크 제한, 기능 비활성화, WAF 룰, 설정 변경, 모니터링
  • 예외 만료일과 재검토 담당자

예외는 보안의 실패가 아니라 운영의 안전장치입니다. 다만 만료일 없는 예외, 사유가 ‘일정상 불가’뿐인 예외, 담당자가 없는 예외는 다음 보안 점검에서 가장 먼저 문제가 됩니다.

5. SBOM 포맷과 스캐너 선택 기준

SBOM 포맷과 컨테이너 이미지 스캐너를 비교하는 보안 대시보드
포맷과 도구는 정답이 하나가 아니라 고객 요구, CI 환경, 예외 관리 방식에 맞춰 선택해야 합니다.

SBOM 포맷은 보통 CycloneDX와 SPDX 중에서 선택합니다. SPDX는 ISO/IEC 5962:2021로 언급되는 국제 open standard이며, CycloneDX는 OWASP 기반의 BOM 표준으로 SBOM뿐 아니라 SaaSBOM, VEX 등 공급망 보안 활용 범위를 넓혀 왔습니다. ([spdx.dev](https://spdx.dev/use/specifications/))

구분CycloneDXSPDX작은 팀 판단
주요 강점보안·취약점·VEX 연계에 친화적라이선스·컴플라이언스·표준 조달 문맥에 강함보안 대응 중심이면 CycloneDX JSON부터 시작
고객 요구보안팀·제품보안팀에서 선호할 수 있음법무·오픈소스 컴플라이언스·공공 조달에서 요구될 수 있음고객사가 지정하면 해당 포맷을 우선
운영 난이도도구 지원이 넓고 JSON 처리 용이라이선스 필드 관리에 유리가능하면 하나를 표준으로 정하고 필요 시 둘 다 생성

스캐너는 Trivy, Syft·Grype, Docker Scout, 클라우드 registry 내장 스캐너 등 여러 선택지가 있습니다. Trivy는 컨테이너 이미지 대상 SBOM 생성과 SBOM 기반 취약점 스캔 흐름을 문서화하고 있고, Grype는 컨테이너 이미지·디렉터리·파일·아카이브·SBOM을 스캔 대상으로 지원한다고 설명합니다. Docker Scout도 이미지 등 artifact에서 SBOM을 생성하거나 표시하는 CLI를 제공합니다. ([trivy.dev](https://trivy.dev/docs/v0.57/guide/target/container_image/?utm_source=openai))

선택지적합한 팀장점확인할 점
Trivy빠르게 CI에 붙이고 싶은 팀이미지 스캔, SBOM 생성, 설정 검사 등 범용성이 높음DB 캐시, CI 실행 시간, 오탐 triage 방식
Syft + GrypeSBOM 생성과 취약점 매칭을 분리하고 싶은 팀SBOM 중심 워크플로우에 적합SBOM 생성 도구와 스캐너 매칭 결과 차이
Docker ScoutDocker 기반 개발 경험이 강한 팀Docker 생태계와 통합된 분석 경험조직 계정, registry, 리포트 공유 방식
클라우드 registry 스캐너AWS·GCP·Azure registry 중심 운영팀이미지 저장소와 운영 보안 대시보드 연결CI에서 hard fail로 쓸 수 있는지, SBOM export 가능 여부
상용 ASPM·CNAPP·SCA 플랫폼고객사 감사와 다수 서비스 운영팀대시보드, 정책, 이슈 연동, 리포팅이 강함비용, 운영 인력, 기존 CI와의 중복

처음부터 상용 플랫폼을 도입해야 하는 것은 아닙니다. 서비스가 1~3개이고 배포 빈도가 높지 않다면 오픈소스 CLI와 GitHub Actions, GitLab CI, Jenkins, Slack, Jira 또는 Notion 티켓만으로도 시작할 수 있습니다. 다만 고객사 제출 리포트가 반복되거나 예외가 누적되면 대시보드와 정책 관리가 필요해집니다.

6. SBOM은 어디에 보관해야 하나

SBOM 보관의 핵심은 ‘파일이 어딘가 있다’가 아니라 ‘어떤 고객 배포 버전과 연결되는지 재현 가능하다’입니다. 따라서 파일명과 메타데이터에는 최소한 서비스명, 애플리케이션 버전, git commit, 이미지 registry, image digest, 생성 도구, 생성 시점을 포함해야 합니다.

보관 방식장점단점추천 상황
CI artifact구현이 가장 쉬움보관 기간이 짧을 수 있음초기 PoC, 내부 검증
Object Storage권한·보관 기간·감사 로그 관리가 쉬움이미지 digest와 연결 규칙을 직접 설계해야 함소규모 SaaS의 현실적 기본값
OCI registry referrer이미지와 SBOM·서명·attestation을 함께 관리 가능registry와 도구 지원 상태 확인 필요Kubernetes·registry 중심 운영팀
보안 플랫폼검색, 리포트, 예외 관리가 편함비용과 운영 복잡도 증가고객 감사가 잦거나 서비스가 많은 팀
소스 저장소 커밋변경 이력 추적이 쉬움파일이 커지고 민감한 구성 정보 노출 우려권장 기본값은 아님

OCI artifact 방식은 이미지와 관련 보안 산출물을 함께 다루는 방향으로 발전하고 있습니다. ORAS 문서는 기존 artifact에 파일을 attach하는 명령을 제공하고, Kubernetes admission 단계에서는 Kyverno의 verifyImages 같은 정책으로 이미지 서명, digest, attestation 검증을 조합할 수 있습니다. 다만 이것은 1단계 도입 항목이라기보다 CI 스캔과 SBOM 보관이 안정화된 뒤 확장하는 영역입니다. ([oras.land](https://oras.land/docs/commands/oras_attach/?utm_source=openai))

7. 고객사와 감사 대응: SBOM을 그대로 다 공개해도 되나

SBOM에는 사용 중인 패키지와 버전이 들어갑니다. 이는 보안 투명성을 높이지만, 동시에 공격자가 관심을 가질 만한 구성 정보가 될 수도 있습니다. 따라서 고객사 요청이 있을 때는 계약 범위, NDA, 제공 포맷, 제공 대상, 보관 기간을 확인해야 합니다.

B2B SaaS라면 처음에는 세 단계로 나누는 편이 안전합니다. 첫째, 보안 설문용으로 ‘SBOM 생성 가능 여부, 생성 주기, 취약점 대응 프로세스’를 문서화합니다. 둘째, 고객사 보안팀이 요청하면 특정 버전의 SBOM을 제공하되 외부 공개 링크가 아니라 제한된 채널로 전달합니다. 셋째, 실제 취약점 질의가 오면 SBOM 전체보다 영향 여부, 패치 예정일, 보완조치, 예외 승인 상태를 요약한 보안 대응 메모를 함께 제공합니다.

공공·대기업 납품을 준비한다면 개발 산출물 인수인계 범위에도 SBOM과 취약점 리포트를 넣어야 합니다. 외주 개발 후 소스와 서버만 넘겨받고 보안 증적이 빠지는 경우가 많기 때문에, 계약·검수 단계에서는 외주개발 인수인계 체크리스트처럼 산출물 목록에 release evidence를 명시하는 것이 좋습니다.

8. Kubernetes에서는 언제 배포 차단 정책까지 가야 하나

CI에서 스캔을 통과한 이미지라도 운영자가 수동으로 다른 태그를 배포하거나, 오래된 manifest가 남아 있거나, 특정 namespace에서 예외가 누락되면 정책이 우회될 수 있습니다. 그래서 어느 정도 성숙한 팀은 admission controller 단계에서 ‘스캔되지 않은 이미지’, ‘digest가 없는 이미지’, ‘허용 registry가 아닌 이미지’, ‘서명 또는 attestation이 없는 이미지’를 막는 방향으로 갑니다.

다만 Kubernetes admission 정책을 너무 빨리 강제하면 개발팀이 장애 대응 중 긴급 패치를 못 하거나, registry 장애 시 배포가 멈추는 부작용도 생깁니다. 작은 팀은 다음 순서를 권장합니다.

  1. 1단계: CI에서만 hard fail. 운영자는 수동 배포를 줄이고 digest 배포 습관을 만든다.
  2. 2단계: staging namespace에서만 admission 정책을 dry-run 또는 audit 모드로 확인한다.
  3. 3단계: production에서 latest 태그 금지, 허용 registry 제한, digest 필수부터 강제한다.
  4. 4단계: 이미지 서명, SBOM attestation, 취약점 정책 검증을 강제한다.

운영 관측성도 함께 고려해야 합니다. 이미지 교체 후 특정 Pod에서 오류가 증가했는지, 취약점 패치가 성능이나 연결 안정성에 영향을 줬는지 확인하려면 배포 이력과 로그·메트릭·트레이스를 같이 봐야 합니다. 이 부분은 OpenTelemetry 관측성 가이드와 연결해 설계하면 보안 패치 후 장애 분석이 쉬워집니다.

9. 경고가 너무 많을 때 줄이는 실무 방법

취약점 수를 줄이는 가장 빠른 방법은 스캐너 예외를 늘리는 것이 아니라 이미지 자체를 줄이는 것입니다. 특히 Node.js, Python, Java 기반 SaaS 이미지는 빌드 도구, 패키지 캐시, 테스트 파일, 샘플 데이터, 사용하지 않는 OS 유틸리티가 남아 있는지 먼저 확인해야 합니다.

  • 베이스 이미지 표준화: 팀마다 다른 베이스 이미지를 쓰면 패치 기준도 흩어집니다. 서비스 유형별 표준 이미지를 정합니다.
  • 멀티스테이지 빌드: 컴파일러, 패키지 매니저 캐시, dev dependency가 런타임에 남지 않도록 합니다.
  • 패치 윈도우 운영: 매 배포마다 모든 Medium을 고치려 하지 말고 월 1회 베이스 이미지와 lockfile을 갱신합니다.
  • 직접 의존성 우선: 직접 추가한 패키지의 Critical/High를 먼저 고치고, transitive dependency는 상위 패키지 업그레이드 경로를 봅니다.
  • 도구 결과 비교: 중요한 release 전에는 한 번쯤 다른 스캐너로 교차 확인해 오탐·누락 가능성을 파악합니다.
  • 운영 노출도 반영: 인터넷 노출 서비스, 관리자 API, 파일 업로드·이미지 처리·인증 관련 컴포넌트를 우선합니다.

스캔 결과는 숫자 경쟁이 아닙니다. CVE 300개를 100개로 줄였다는 사실보다, 고객 데이터에 접근 가능한 경로의 Critical이 배포 전에 차단됐는지가 더 중요합니다.

10. 30일 적용 로드맵

컨테이너 보안 운영 체크리스트와 릴리스 증적 보관 화면
처음부터 완벽한 보안 플랫폼을 도입하기보다 30일 안에 반복 가능한 기준을 만드는 것이 우선입니다.
기간할 일완료 기준
1주차대상 서비스 1개 선정, 현재 이미지 스캔 수동 실행, SBOM 샘플 생성대표 이미지의 주요 CVE와 패키지 구성이 파악됨
2주차CI에 이미지 스캔과 SBOM 생성을 자동화, 리포트 artifact 저장main 병합 후 자동으로 scan report와 SBOM이 생성됨
3주차Critical·High 차단 기준과 예외 승인 템플릿 적용차단·예외·통과 케이스가 티켓으로 남음
4주차Object Storage 또는 registry에 release evidence 보관, Slack·이슈 알림 연결특정 배포 버전의 digest, SBOM, 스캔 결과, 예외 기록을 5분 안에 찾을 수 있음
이후운영 이미지 주기 재스캔, 베이스 이미지 패치 루틴, Kubernetes 정책 확장새 CVE 발생 시 영향 서비스와 조치 담당자가 자동으로 정리됨

의사결정 체크리스트

  • 최종 운영 이미지를 digest 기준으로 식별하고 있는가?
  • SBOM이 release마다 자동 생성되는가?
  • SBOM과 스캔 리포트가 같은 image digest와 연결되는가?
  • Critical과 High의 배포 차단 기준이 문서화돼 있는가?
  • 예외 승인에 만료일, 담당자, 보완조치가 포함되는가?
  • 베이스 이미지 업데이트 주기가 정해져 있는가?
  • 고객사 요청 시 제공 가능한 SBOM 포맷과 제공 절차가 있는가?
  • CI/CD 실패 시 개발자가 어디를 보고 무엇을 고쳐야 하는지 알 수 있는가?
  • 운영 중인 이미지에 대해 재스캔하거나 새 CVE 영향을 확인하는 절차가 있는가?
  • 보안 리포트가 팀의 이슈 트래커와 연결되는가?

AgentMit이 도울 수 있는 지점

AgentMit은 작은 팀이 유지하기 어려운 대형 보안 플랫폼부터 권하지 않습니다. SaaS, 관리자 대시보드, 업무 자동화, 정부지원사업 MVP를 Docker·Kubernetes 기반으로 운영하는 팀이라면 먼저 CI에서 이미지 스캔과 SBOM 생성을 자동화하고, Slack·이슈 트래커·release evidence 저장소를 연결하는 경량 구조를 제안합니다.

BizMit 같은 업무형 SaaS나 B2B 솔루션은 고객사 보안 설문, 관리자 권한, 배포 이력, 운영 로그까지 함께 봐야 합니다. 따라서 컨테이너 스캔만 붙이는 작업보다 ‘배포 전 차단 기준, 예외 승인, 증적 보관, 고객사 제출 리포트’를 하나의 운영 흐름으로 설계하는 것이 중요합니다. 파이프라인 설계나 기존 CI/CD 개선이 필요하다면 AgentMit 프로젝트 문의로 현재 배포 방식과 registry, CI 도구, 고객사 요구 수준을 함께 정리해 보시면 됩니다.

FAQ

Q1. 컨테이너 이미지 취약점 스캔은 빌드 전과 빌드 후 중 언제 해야 하나요?

배포 차단 기준은 빌드 후 완성된 이미지 digest 기준으로 적용하는 것이 안전합니다. 개발 중에는 빠른 피드백용 의존성 스캔을 병행할 수 있지만, 실제 운영에 올라가는 OS 패키지·런타임·앱 패키지는 최종 이미지에서 확정되기 때문입니다.

Q2. Critical 또는 High CVE가 나오면 무조건 배포를 중단해야 하나요?

작은 팀은 Critical과 수정 버전이 있는 High를 기본 차단 대상으로 두고, 실제 영향이 없거나 패치가 없는 항목은 만료일이 있는 예외 승인으로 관리하는 방식이 현실적입니다. 모든 High를 영구 차단하면 베이스 이미지나 간접 의존성 때문에 배포가 자주 멈출 수 있습니다.

Q3. SBOM 포맷은 CycloneDX와 SPDX 중 무엇을 선택해야 하나요?

보안 취약점 관리와 VEX 연계를 우선하면 CycloneDX JSON을 기본으로 두기 쉽고, 라이선스·조달·고객사 요구가 SPDX 중심이면 SPDX를 함께 생성하는 방식을 고려할 수 있습니다. 중요한 것은 포맷보다 release digest와 연결된 SBOM을 지속적으로 생성·보관하는 운영입니다.

Q4. SBOM은 어디에 보관하고 고객사에는 어떻게 제공하나요?

이미지 digest, SBOM 파일, 스캔 리포트, 예외 승인 기록을 같은 release 단위로 보관해야 합니다. 보관 위치는 OCI registry referrer, artifact storage, 보안 플랫폼 중 팀 운영에 맞게 선택하고, 고객사에는 계약 범위에 따라 버전별 SBOM 또는 취약점 대응 요약을 제공합니다.

Q5. 소규모 스타트업도 무료 도구만으로 SBOM과 이미지 스캔을 운영할 수 있나요?

가능합니다. Trivy, Syft·Grype 같은 오픈소스 CLI를 CI에 붙여 시작할 수 있습니다. 다만 무료 도구라도 경고 분류, 예외 승인, 보관 정책, 알림, 재스캔 주기를 정하지 않으면 리포트만 쌓이고 실제 리스크 관리는 되지 않습니다.

참고한 기준과 출처

이 글은 2026년 6월 기준 공개된 KISA 공급망 보안 지원사업 공고와 SBOM 사례집, CISA SBOM 최소 요소, NIST SSDF, SPDX·CycloneDX 공식 문서, Trivy·Grype·Docker Scout·Kyverno 공식 문서를 참고해 작은 팀 운영 기준으로 재구성했습니다. 각 도구의 세부 옵션, 가격, 클라우드 registry 지원 범위는 계정·버전·운영 환경에 따라 달라질 수 있으므로 실제 도입 전 현재 문서를 다시 확인해야 합니다. ([kisa.or.kr](https://www.kisa.or.kr/401/form?lang_type=KO&page=2&postSeq=3616&utm_source=openai))

자주 묻는 질문

컨테이너 이미지 취약점 스캔은 빌드 전과 빌드 후 중 언제 해야 하나요?
배포 차단 기준은 빌드 후 완성된 이미지 digest 기준으로 적용하는 것이 안전합니다. 개발 중에는 빠른 피드백용 의존성 스캔을 병행할 수 있지만, 실제 운영에 올라가는 OS 패키지·런타임·앱 패키지는 최종 이미지에서 확정되기 때문입니다.
Critical 또는 High CVE가 나오면 무조건 배포를 중단해야 하나요?
작은 팀은 Critical과 수정 버전이 있는 High를 기본 차단 대상으로 두고, 실제 영향이 없거나 패치가 없는 항목은 만료일이 있는 예외 승인으로 관리하는 방식이 현실적입니다. 모든 High를 영구 차단하면 베이스 이미지나 간접 의존성 때문에 배포가 자주 멈출 수 있습니다.
SBOM 포맷은 CycloneDX와 SPDX 중 무엇을 선택해야 하나요?
보안 취약점 관리와 VEX 연계를 우선하면 CycloneDX JSON을 기본으로 두기 쉽고, 라이선스·조달·고객사 요구가 SPDX 중심이면 SPDX를 함께 생성하는 방식을 고려할 수 있습니다. 중요한 것은 포맷보다 release digest와 연결된 SBOM을 지속적으로 생성·보관하는 운영입니다.
SBOM은 어디에 보관하고 고객사에는 어떻게 제공하나요?
이미지 digest, SBOM 파일, 스캔 리포트, 예외 승인 기록을 같은 release 단위로 보관해야 합니다. 보관 위치는 OCI registry referrer, artifact storage, 보안 플랫폼 중 팀 운영에 맞게 선택하고, 고객사에는 계약 범위에 따라 버전별 SBOM 또는 취약점 대응 요약을 제공합니다.
소규모 스타트업도 무료 도구만으로 SBOM과 이미지 스캔을 운영할 수 있나요?
가능합니다. Trivy, Syft·Grype 같은 오픈소스 CLI를 CI에 붙여 시작할 수 있습니다. 다만 무료 도구라도 경고 분류, 예외 승인, 보관 정책, 알림, 재스캔 주기를 정하지 않으면 리포트만 쌓이고 실제 리스크 관리는 되지 않습니다.
  • Company. 주식회사 에이전트밋
  • Addr.부산광역시 부산진구 서전로 8, 8층 101호 DD-33,34호(부전동) CEO. 윤성훈 Email. agentmit@naver.com
  • BR. 333-87-04232 TEL. 0507-1314-2790
Copyright © 2026 ~ 에이전트밋. All rights reserved.