SBOM은 컴플라이언스 체크리스트 그 이상이다
규제 당국과 고객이 이제 SBOM(소프트웨어 부품표)을 요구하기에, 많은 팀이 그것을 '산출물'로 취급한다——생성하고, 제출하고, 감사를 만족시킨다. 그것은 SBOM의 진짜 용도를 낭비하는 일이다. 좋은 SBOM은 결승선이 아니라 거버넌스의 출발점이다.
하나의 인벤토리, 세 가지 수준
모든 SBOM이 같지 않다.
- 무엇이 있는가: 컴포넌트와 버전을 나열한다. 최소 기준——그리고 대부분의 도구가 멈추는 지점.
- 얼마나 위험한가: 각 컴포넌트를 CVE / CNVD / CNNVD / EUVD에 매핑하고 라이선스를 표기한다.
- 무엇을 할 것인가: 도달 가능성과 악용 가능성을 결합해 무엇을 먼저 고칠지를 알려준다——500개짜리 백로그를 건네는 대신.
패키지 수준이 아니라 스니펫 수준으로
선언적 의존성 해석은 두 가지를 놓친다: 프로젝트에 복사·붙여넣기된 오픈소스 조각과, 개명·잘라내기·변조된 컴포넌트다. 스니펫 수준 지문 분석은 코드 자체를 지문화해 방대한 코퍼스와 대조한다. 그래서 '변장한' 오픈소스 코드를 잡아내고 조용히 변경된 라이선스를 가시화한다.
SBOM의 가치는 '모든 것을 나열'하는 데 있지 않고 '정확히 매핑'하는 데 있다. 목록이 아무리 완전해도 리스크에 매핑되지 않으면 그저 종이일 뿐이다.
인벤토리가 행동을 이끌게 하라
SBOM을 CI/CD에 연결하면 정적 문서에서 살아있는 방어로 바뀐다: 새로 도입된 고위험 컴포넌트는 즉시 차단되고, 라이선스 충돌은 경고를 발생시키며, 취약점 인텔리전스는 실시간으로 환류한다. 컴플라이언스는 부산물이고, 진짜 보상은 거버넌스 가능성이다.
그것이 CleanSource SCA의 설계 철학이다——인벤토리를 생성하는 데 그치지 않고 실행 가능한 거버넌스로 바꾼다.