SBOM과 SLSA — 소프트웨어에도 '전성분표'가 필요한 이유

SBOM(Software Bill of Materials)은 소프트웨어의 전성분표다. 이 프로그램 안에 어떤 오픈소스 라이브러리가, 어떤 버전으로, 어디서 왔는지를 목록으로 정리한 문서다. 식품 포장 뒤의 원재료 표시와 똑같은 발상이다. 무엇이 들어있는지 알아야, 그 안에서 문제가 터졌을 때 내가 영향받는지 즉시 판단할 수 있다.

SLSA(Supply-chain Levels for Software Artifacts)는 그 부품들이 만들어져 내 손에 오기까지의 과정이 조작되지 않았음을 보증하는 틀이다. SBOM이 "무엇이 들어있나"라면 SLSA는 "그게 믿을 만한 경로로 왔나"를 다룬다. 요즘 공급망 보안 이야기가 나오면 이 둘이 세트로 등장하는 이유다.

왜 공급망이 표적이 됐나

생각해보면 당연한 흐름이다. 오늘날 어떤 앱을 열어봐도 직접 짠 코드는 일부고, 나머지 대부분은 오픈소스 라이브러리와 그 라이브러리가 또 끌어온 라이브러리들로 채워진다. 의존성이 나무처럼 뻗어 수백, 수천 개에 이른다. 공격자 입장에서 이건 매력적인 지형이다. 잘 지켜진 회사 하나를 정면으로 뚫는 대신, 그 회사를 포함해 모두가 무심코 갖다 쓰는 인기 라이브러리 하나에 악성코드를 심으면 된다.

이런 공격이 무서운 이유는 신뢰를 역이용하기 때문이다. 우리는 유명한 오픈소스 패키지를 별 의심 없이 설치한다. 자동 업데이트까지 걸어둔다. 그 신뢰의 통로를 타고 악성 버전이 흘러들면, 방화벽도 백신도 "정상적인 업데이트"로 인식한다. 정문을 지키는 데 익숙한 방어 체계가 정작 안에서 열린 문에는 무력한 것이다.

SBOM이 하는 일 — 알아야 지킨다

어느 라이브러리에서 심각한 취약점이 발견됐다고 하자. 이때 조직이 던지는 첫 질문은 언제나 같다. "우리가 그걸 쓰고 있나? 어디에?" SBOM이 없으면 이 질문에 며칠이 걸린다. 수많은 프로젝트를 사람이 일일이 뒤져야 하기 때문이다. 그 사이 공격자는 이미 움직이고 있다.

SBOM이 있으면 답이 검색 한 번으로 나온다. 어떤 제품의 어느 버전에 문제의 라이브러리가 들어있는지 목록에서 바로 찾을 수 있다. 대응 속도가 며칠에서 몇 분으로 줄어든다. SBOM은 화려한 방어 무기가 아니라, 불이 났을 때 어디에 무엇이 있는지 알려주는 건물 도면 같은 것이다. 도면 없이 불을 끄는 건 불가능하다.

표준 포맷이 중요한 이유

SBOM은 사람이 아니라 도구가 자동으로 읽어야 쓸모가 있다. 그래서 SPDX나 CycloneDX 같은 표준 포맷으로 만든다. 형식이 통일돼야 취약점 데이터베이스와 자동으로 대조하고, 새 취약점이 공개되는 순간 영향받는 제품을 기계가 알아서 골라낼 수 있다. 사람 손으로 관리하는 엑셀 목록은 만드는 순간 낡기 시작하지만, 빌드 과정에서 자동 생성되는 SBOM은 항상 최신이다.

서명과 출처 증명 — SLSA의 몫

SBOM으로 "무엇이 들어있나"를 알았다면, 다음 질문은 "이게 정말 원본이 맞나"다. 여기서 서명이 등장한다. 만든 사람이 결과물에 암호학적 서명을 남기면, 받는 쪽은 그 서명을 검증해 중간에 누가 바꿔치기하지 않았음을 확인한다. 봉인 스티커가 뜯겨 있으면 사지 않는 것과 같은 이치다.

SLSA는 여기서 한 걸음 더 나아간다. 결과물이 어떤 소스로부터, 어떤 빌드 환경에서, 어떤 과정을 거쳐 만들어졌는지를 자동으로 기록하고 증명하게 한다. 이 출처 기록이 있으면, 누군가 빌드 과정 중간에 몰래 악성코드를 끼워 넣는 공격을 잡아낼 수 있다. 개발자의 노트북이 아니라 통제된 빌드 시스템에서만 배포본이 나오게 강제하는 것도 SLSA가 권하는 실천이다.

작은 팀은 어디서 시작할까

대기업 이야기처럼 들릴 수 있지만, 시작점은 소박하다. 나는 세 가지만 챙기라고 말한다. 첫째, 빌드 파이프라인에서 SBOM을 자동 생성하도록 켠다. 요즘 도구들은 명령 한 줄로 이걸 해준다. 둘째, 배포하는 결과물에 서명을 붙이고, 받는 쪽에서 검증하게 한다. 셋째, 의존성을 자동으로 감시해 취약점이 뜨면 알림을 받는 장치를 건다. 이 세 가지만 갖춰도 공급망 공격의 상당수는 걸러진다. 완벽을 노리기보다, 도면과 봉인 스티커를 먼저 갖추는 것이 순서다.

자주 묻는 질문

SBOM만 있으면 공급망 공격을 막을 수 있나요?

막는 게 아니라 빠르게 대응하는 도구입니다. SBOM은 취약점이 터졌을 때 "우리가 영향받는가"를 즉시 알려줍니다. 실제 방어는 서명 검증, 출처 증명, 의존성 감시가 함께 맡습니다. SBOM은 그 대응의 출발점이 되는 지도라고 보면 됩니다.

SBOM은 어떻게 만드나요?

대부분 빌드 파이프라인에 도구를 붙여 자동 생성합니다. 사람이 손으로 목록을 관리하면 만드는 순간부터 낡기 시작하므로 권하지 않습니다. SPDX나 CycloneDX 같은 표준 포맷으로 뽑아야 취약점 데이터베이스와 자동으로 대조할 수 있습니다.

SLSA와 SBOM은 뭐가 다른가요?

SBOM은 결과물 안에 무엇이 들어있는지를 다루고, SLSA는 그 결과물이 신뢰할 수 있는 과정을 거쳐 만들어졌는지를 다룹니다. 하나는 성분표, 다른 하나는 제조 이력 증명입니다. 둘은 경쟁 관계가 아니라 서로를 보완합니다.

오픈소스를 안 쓰면 이런 걱정이 없지 않나요?

현실적으로 오픈소스를 완전히 배제한 개발은 거의 불가능하고, 배제한다고 안전해지지도 않습니다. 자체 코드에도 취약점은 생깁니다. 핵심은 오픈소스를 피하는 게 아니라, 무엇을 쓰는지 파악하고 출처를 검증하며 취약점을 빠르게 추적하는 체계를 갖추는 것입니다.