매일 아침 배포하는 컨테이너 이미지 속에 정확히 어떤 라이브러리가 들어있는지, 그리고 그 라이브러리들이 빌드 과정에서 변조되지 않았다고 100% 확신하시나요? 2025년 한 해 동안 발생한 소프트웨어 공급망 공격의 60% 이상이 신뢰받는 오픈소스 패키지의 취약점을 악용했다는 통계는, 우리가 더 이상 ‘이미지 스캔’만으로는 안전을 보장받을 수 없는 시대에 살고 있음을 보여줍니다. 이제는 단순히 성벽을 높이 쌓는 보안을 넘어, 우리가 사용하는 모든 소프트웨어 부품의 출처와 무결성을 증명해야 하는 시대예요.
소프트웨어 공급망 보안(SSCS), 왜 지금 당장 시작해야 할까요?
불과 몇 년 전까지만 해도 우리는 이미지 스캐닝(Image Scanning)만으로 충분하다고 믿었어요. 하지만 공격자들은 똑똑해졌죠. 그들은 런타임 환경이 아니라, 개발자가 코드를 작성하고 빌드하는 ‘파이프라인’ 자체를 공격하기 시작했습니다. 빌드 서버에 침투해 정상적인 코드에 악성 스크립트를 살짝 끼워 넣는 식이죠. 이렇게 만들어진 이미지는 보안 스캔을 통과하더라도 실행되는 순간 시스템을 장악하게 됩니다.
2026년의 클라우드 네이티브 환경에서 SSCS(Software Supply Chain Security)는 선택이 아닌 생존의 문제입니다. 특히 금융, 의료, 공공 부문에서는 이미 소프트웨어 자재 명세서(SBOM) 제출이 의무화되고 있어요. 여러분의 서비스가 글로벌 시장으로 진출하거나 기업용 솔루션으로 공급되길 원한다면, ‘우리 인프라는 안전해요’라는 말 대신 ‘여기 우리가 사용한 모든 모듈의 증명서가 있습니다’라고 답할 수 있어야 합니다.
1단계: 투명한 설계도, SBOM(Software Bill of Materials) 자동화하기
공급망 보안의 시작은 우리가 무엇을 쓰고 있는지 정확히 아는 것에서 출발해요. 편의점에서 식품을 살 때 뒷면의 원재료 함량을 확인하듯, 컨테이너 이미지의 ‘성분표’를 만드는 것이죠.
SBOM 생성 도구의 활용
현재 업계 표준으로 자리 잡은 SPDX나 CycloneDX 형식을 지원하는 도구를 CI/CD 파이프라인에 이식해야 합니다.
- Syft나 Trivy 같은 도구를 활용하면 빌드 단계에서 자동으로 이미지 내의 모든 종속성을 추출할 수 있어요.
- 중요 포인트: 단순히 리스트를 뽑는 것에 그치지 말고, 이를 VEX(Vulnerability Exploitability eXchange) 정보와 결합하세요. ‘취약점은 있지만, 우리 환경에서는 실행되지 않아 안전하다’는 정보를 함께 기록해야 보안 팀의 불필요한 리소스 낭비를 막을 수 있습니다.
파이프라인 통합 예시
GitHub Actions나 GitLab CI를 사용 중이라면, 빌드가 끝난 직후 SBOM 생성 단계를 추가하세요. 생성된 JSON 파일은 아티팩트 저장소에 이미지와 함께 보관되어야 하며, 나중에 사고가 터졌을 때 즉시 ‘우리가 이 취약한 라이브러리를 어디 어디에 썼지?’를 1분 안에 파악할 수 있게 해줍니다.
2단계: 디지털 인감 증명, Cosign을 활용한 이미지 서명
SBOM이 성분표라면, 이미지 서명(Signing)은 이 제품이 정품임을 보증하는 인감도장과 같습니다. 누군가 중간에 이미지를 가로채서 악성 코드를 심고 다시 올리는 것을 방지하는 핵심 기술이죠.
Sigstore 프로젝트와 Cosign
과거에는 복잡한 키 관리(KMS) 때문에 서명을 도입하기 어려웠지만, 이제는 Sigstore 프로젝트의 Cosign 덕분에 훨씬 쉬워졌어요.
- Keyless 서명: 특정 키를 관리할 필요 없이, OIDC(OpenID Connect)를 통해 개발자의 신원을 확인하고 짧은 수명의 인증서로 서명할 수 있습니다.
- Attestation(증명): 단순히 “이 이미지는 내가 만들었어”라고 서명하는 것을 넘어, “이 이미지는 특정 테스트를 통과했고, 보안 스캔에서 High 위험도가 0개였음을 증명해”라는 정보를 서명 데이터에 포함할 수 있어요.
이 과정을 통해 운영 환경의 쿠버네티스는 “검증된 파이프라인에서 생성되고, 테스트를 통과했다는 서명이 있는 이미지”만 실행하도록 강제할 수 있게 됩니다.
3단계: 쿠버네티스의 문지기, 어드미션 컨트롤러로 강제하기
아무리 좋은 보안 가이드라인이 있어도 사람이 실수하면 끝이죠. 그래서 시스템이 스스로를 보호하도록 설정해야 합니다. 이때 사용하는 것이 Policy as Code(PaC) 개념입니다.
Kyverno 또는 OPA Gatekeeper 활용
쿠버네티스 클러스터에 Kyverno를 설치하면 다음과 같은 정책을 아주 쉽게 적용할 수 있어요.
- “서명이 없는 이미지는 배포를 거부한다.”
- “특정 레지스트리(예: 사내 프라이빗 ECR/GCR)가 아닌 곳에서 온 이미지는 실행하지 않는다.”
- “최근 24시간 이내에 보안 스캔을 받지 않은 이미지는 배포를 차단한다.”
💡 멘토의 팁: 처음부터 모든 정책을 ‘Enforce(차단)’ 모드로 두면 개발 팀의 원성을 살 수 있어요. 초기 한 달간은 ‘Audit(감사)’ 모드로 설정해 어떤 이미지가 정책을 위반하는지 모니터링하고, 팀원들에게 보안 필요성을 충분히 공유한 뒤 차단 모드로 전환하는 지혜가 필요합니다.
4단계: SLSA 프레임워크로 보안 수준 체계화하기
우리 회사의 보안이 어느 수준인지 궁금하다면 SLSA(Supply-chain Levels for Software Artifacts) 프레임워크를 참고해 보세요. 살사(Salsa)라고 읽는 이 프레임워크는 소프트웨어 공급망 보안의 성숙도를 레벨 1부터 4까지 정의합니다.
- Level 1: 빌드 프로세스가 문서화되어 있고, SBOM이 생성되는 수준.
- Level 2: 호스팅된 빌드 서비스를 사용하며, 서비스가 서명된 증명서를 제공하는 수준.
- Level 3: 빌드 인프라가 신뢰할 수 있고, 변조 방지(Hardened)가 된 수준.
현재 대부분의 기업은 레벨 1~2 사이에 머물러 있습니다. 2026년에는 레벨 3를 달성하는 것이 클라우드 네이티브 엔지니어의 핵심 역량이 될 거예요. 이를 위해 빌드 환경 자체를 격리된 일회성 컨테이너에서 수행하는 전략을 고민해 보세요.
5단계: 실전 적용 시나리오 – AWS와 GCP 환경에서
클라우드 벤더사들도 이 흐름에 적극적으로 동참하고 있습니다.
- AWS 환경: Amazon ECR은 이제 자체적인 이미지 스캔을 넘어, Inspector와 통합된 SBOM 내보내기 기능을 제공합니다. 서명 데이터는 AWS KMS와 연동하여 관리 효율성을 높일 수 있죠.
- GCP 환경: Artifact Analysis와 Binary Authorization을 활용하세요. 구글 클라우드는 이미 ‘검증된 빌드’만 GKE에 배포할 수 있는 매우 강력한 기본 도구들을 갖추고 있어, 설정 몇 번만으로도 수준 높은 공급망 보안을 구축할 수 있습니다.
결론: 보안은 ‘속도’를 늦추는 것이 아니라 ‘안전’하게 달리기 위한 것
보안 절차가 까다로워지면 개발 속도가 느려진다고 불평하는 동료들이 있을지도 몰라요. 하지만 사고가 터졌을 때 서비스 전체가 중단되고 데이터가 유출되는 손실에 비하면, 파이프라인에 보안 단계를 추가하는 비용은 아주 미미합니다.
공급망 보안의 핵심은 자동화입니다. 개발자가 신경 쓰지 않아도 뒤에서 묵묵히 SBOM이 생성되고, 서명이 붙고, 정책에 따라 검증되는 시스템을 만들어 주세요. 그것이 바로 2026년형 DevOps 엔지니어가 추구해야 할 진정한 ‘신뢰의 가치’니까요.
오늘 바로 여러분의 파이프라인에 syft 명령어를 한 줄 추가해 보는 건 어떨까요? 작은 시작이 여러분의 인프라를 무너뜨릴 수 없는 요새로 만들어줄 거예요.
요약 및 체크리스트
- SBOM 도입: 모든 컨테이너 이미지의 성분표를 자동 생성하세요.
- 이미지 서명: Cosign과 Sigstore를 활용해 빌드 결과물의 무결성을 보장하세요.
- 배포 정책 강제: Kyverno 등을 통해 검증되지 않은 이미지의 클러스터 진입을 차단하세요.
- SLSA 준수: 점진적으로 빌드 환경의 보안 성숙도를 높여가세요.
- VEX 활용: 보안 취약점의 실제 노출 여부를 관리해 운영 노이즈를 줄이세요.