SBOM 의무화 시대, 소프트웨어 공급망 보안 전략이 바뀌고 있다

오픈소스 활용이 급증하고 공급망 공격 위협이 커지면서, 소프트웨어 보안 전략이 근본적인 전환점을 맞고 있음

• SBOM 기반 공급망 가시성 확보가 글로벌 보안 규제 대응의 핵심으로 부상
  • 미국 행정명령을 비롯해 SBOM 제출 요구가 전 세계적으로 확대
  • 소프트웨어 구성요소의 투명성과 추적 가능성이 필수 평가 기준이 됨

SBOM은 더 이상 선택이 아닌 필수 — 글로벌 표준으로 자리잡으면서, 국내 기업들도 대응 체계 구축이 시급해지고 있음

• 쿠도커뮤니케이션이 Black Duck과 함께 소프트웨어 공급망 보안 전략 제시

  • Black Duck SCA가 제공하는 통합 관리 체계
    • 오픈소스 구성요소 식별
    • 취약점 분석
    • 라이선스 리스크 관리
    • SBOM 자동 생성 (SPDX, CycloneDX 국제 표준 포맷 지원)

• 기존 AppSec vs 새로운 접근

  • 기존: 개발 완료 후 사후 점검 방식 → 개발-보안 간 충돌 발생
  • Black Duck: "실제 위험 기반" 보안 모델 — 공격 가능성과 비즈니스 영향도 기준으로 위험 판단
  • 개발 단계에서 보안을 내재화, 코드·오픈소스·SBOM·규제까지 통합 가시성 제공

• 보안 리스크가 복잡해지는 이유

  • 오픈소스, 외주 코드, AI 생성 코드 비중 증가
  • 취약점 수는 많지만 실제 위험도 판단이 어려움
  • 수작업 대응으로 개발 생산성과 보안 수준 동시 저하

• 금융·공공·엔터프라이즈 시장 중심으로 SBOM 대응, 오픈소스 보안 관리, 규제 대응 컨설팅 확대 계획

---

기술 맥락

SBOM이 갑자기 주목받게 된 배경을 설명하면, 2021년 미국 바이든 행정부의 사이버보안 행정명령이 결정적이었어요. 연방 기관에 소프트웨어를 납품하려면 SBOM을 제출해야 하는데, 이게 사실상 글로벌 표준이 되어가고 있거든요. 한국 기업도 미국 시장에 소프트웨어를 수출하려면 피할 수 없는 요건이에요.

DevSecOps 관점에서 보면, SCA 도구는 CI/CD 파이프라인에 통합되어 코드를 커밋하거나 빌드할 때 자동으로 오픈소스 구성요소를 스캔해요. 개발 완료 후에 보안팀이 따로 점검하는 게 아니라, 개발 과정 자체에 보안 검증이 녹아있는 구조거든요. 이래야 취약점을 초기에 잡을 수 있고, 나중에 뒤늦게 발견해서 릴리스가 밀리는 일도 줄어들어요.

AI 생성 코드가 보안을 더 복잡하게 만드는 이유가 있어요. 사람이 작성한 코드는 어떤 라이브러리를 왜 가져다 썼는지 맥락이 남지만, AI가 생성한 코드는 어떤 학습 데이터에서 가져온 패턴인지 추적이 안 되거든요. 라이선스 충돌이나 알려진 취약점이 포함된 코드가 무의식적으로 섞여 들어올 수 있어서, SBOM과 SCA 도구의 역할이 더 중요해지고 있어요.