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

결론부터 말하면, 작은 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 기준

권장 흐름은 단순합니다. 소스코드가 main 브랜치에 병합되고 이미지가 빌드되면, 그 이미지의 digest를 확정합니다. 이후 같은 digest에 대해 SBOM을 생성하고 취약점 스캔을 수행합니다. 기준을 넘는 항목이 있으면 배포를 막고, 기준 미만이거나 승인된 예외라면 registry에 push하고 배포합니다.
- 베이스 이미지 선택: 공식 이미지라 해도 태그만 믿지 말고 digest pinning을 검토합니다. slim, distroless, 최소 패키지 이미지는 CVE 노출면을 줄이는 데 도움이 되지만 디버깅 편의성과 트레이드오프가 있습니다.
- 이미지 빌드: 멀티스테이지 빌드를 사용해 빌드 도구와 테스트 도구가 런타임 이미지에 남지 않도록 합니다.
- SBOM 생성: 이미지 digest와 함께 SBOM 파일명을 남깁니다. 예: 서비스명, 버전, git commit, image digest, 생성일.
- 취약점 스캔: OS 패키지와 애플리케이션 패키지를 함께 확인합니다. 스캐너 DB 갱신 시점과 도구 버전도 기록합니다.
- 정책 판정: Critical·High 기준, 수정 버전 존재 여부, 예외 승인 여부를 기준으로 fail 또는 pass를 결정합니다.
- 증적 저장: SBOM, 스캔 리포트, 예외 승인 티켓 URL, 배포 승인자를 release evidence로 저장합니다.
- 배포: Kubernetes manifest에는 태그보다 digest를 사용하는 방향으로 전환합니다.
이미 GitOps를 운영 중이라면 이미지 스캔과 SBOM 생성은 배포 저장소에 변경이 반영되기 전 단계에 두는 것이 좋습니다. 배포 승인 흐름 자체가 아직 없다면 GitOps로 하는 소규모 팀 배포 자동화에서 설명한 것처럼 배포 선언과 실제 배포를 분리한 뒤 보안 게이트를 추가하는 순서가 부담이 적습니다.
| 파이프라인 단계 | 실행 작업 | 실패 기준 예시 | 남길 증적 |
|---|---|---|---|
| Pull Request | 언어 의존성 빠른 검사 | 새 Critical 직접 의존성 추가 | PR 코멘트 |
| Image Build | 이미지 빌드와 digest 산출 | 빌드 실패, 금지된 베이스 이미지 | image digest, Dockerfile |
| Security Gate | SBOM 생성, 취약점 스캔 | Critical, 수정 가능 High | SBOM, scan report |
| Exception Review | 예외 티켓 확인 | 만료된 예외, 근거 없는 예외 | 승인자, 만료일, 보완조치 |
| Deploy | digest 기반 배포 | 스캔되지 않은 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 포맷은 보통 CycloneDX와 SPDX 중에서 선택합니다. SPDX는 ISO/IEC 5962:2021로 언급되는 국제 open standard이며, CycloneDX는 OWASP 기반의 BOM 표준으로 SBOM뿐 아니라 SaaSBOM, VEX 등 공급망 보안 활용 범위를 넓혀 왔습니다. ([spdx.dev](https://spdx.dev/use/specifications/))
| 구분 | CycloneDX | SPDX | 작은 팀 판단 |
|---|---|---|---|
| 주요 강점 | 보안·취약점·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 + Grype | SBOM 생성과 취약점 매칭을 분리하고 싶은 팀 | SBOM 중심 워크플로우에 적합 | SBOM 생성 도구와 스캐너 매칭 결과 차이 |
| Docker Scout | Docker 기반 개발 경험이 강한 팀 | 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단계: CI에서만 hard fail. 운영자는 수동 배포를 줄이고 digest 배포 습관을 만든다.
- 2단계: staging namespace에서만 admission 정책을 dry-run 또는 audit 모드로 확인한다.
- 3단계: production에서 latest 태그 금지, 허용 registry 제한, digest 필수부터 강제한다.
- 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일 적용 로드맵

| 기간 | 할 일 | 완료 기준 |
|---|---|---|
| 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))

