소프트웨어 공급망 보안 — SBOM과 서명이 표준이 되는 이유

현대 소프트웨어는 거의 예외 없이 남의 코드 위에 서 있다. 애플리케이션 하나를 열어 보면 직접 작성한 부분은 얇은 층이고, 그 아래에는 수백 수천 개의 오픈소스 의존성이 깔려 있다. 편리하지만 그만큼 위험도 함께 상속받는다. 어느 구석의 작은 라이브러리 하나가 오염되면, 그것을 끌어다 쓴 모든 소프트웨어가 한꺼번에 흔들린다. 이것이 요즘 보안 논의의 중심에 선 '소프트웨어 공급망(supply chain)' 문제다.

그래서 등장한 것이 SBOM(소프트웨어 자재 명세서)과 아티팩트 서명이다. 낯선 약어처럼 보이지만 발상은 단순하다. 무엇으로 만들었는지 목록을 남기고, 그것이 진짜인지 서명으로 증명하자는 것이다. 왜 이것이 지금 표준이 되어 가는지 정리해 본다.

공급망 공격은 왜 무서운가

일반적인 해킹은 특정 대상의 방어를 뚫는다. 공급망 공격은 방향이 반대다. 많은 사람이 공통으로 신뢰하는 지점, 즉 인기 라이브러리나 빌드 도구, 패키지 저장소를 오염시킨다. 그러면 그것을 자동으로 내려받아 쓰는 수많은 하위 사용자에게 한 번에 악성 코드가 퍼진다. 방어자는 자기 코드만 잘 지켜서는 막을 수 없다. 신뢰의 사슬 어딘가가 끊기면 나도 영향을 받기 때문이다.

지난 몇 년간 이런 사건이 반복되며 업계는 뼈아픈 교훈을 얻었다. 특히 오랫동안 방치되다시피 한 핵심 유틸리티에 은밀히 악성 코드가 심어질 뻔한 사례들은, "널리 쓰인다고 해서 안전한 것은 아니다"라는 사실을 각인시켰다. 신뢰는 검증되어야 하는 것이지, 관성으로 유지되는 것이 아니다.

SBOM — 재료 목록을 남긴다

SBOM은 식품의 성분표에 비유하면 이해가 빠르다. 이 소프트웨어가 어떤 구성요소로, 어떤 버전으로, 어떤 라이선스로 만들어졌는지를 기계가 읽을 수 있는 형식으로 적어 둔 목록이다. 언뜻 단순해 보이지만 효과는 크다. 어떤 라이브러리에서 심각한 취약점이 발견됐을 때, SBOM이 있으면 "우리 제품 중 어디에 그게 들어 있나"를 몇 분 만에 찾아낼 수 있다. 없으면 수작업으로 며칠을 뒤져야 한다.

서명 — 진짜임을 증명한다

목록만으로는 부족하다. 내가 받은 파일이 정말 그 개발자가 만든 것인지, 중간에 바꿔치기당한 것은 아닌지 확인해야 한다. 그 역할을 하는 것이 아티팩트 서명이다. 배포자가 자기 키로 결과물에 서명하면, 사용자는 그 서명을 검증해 위변조 여부를 판단한다. 최근에는 키 관리의 부담을 줄이는 방식이 확산되면서, 서명이 소수 전문가의 일이 아니라 빌드 파이프라인의 기본 단계로 자리 잡고 있다.

여기에 '출처 증명(provenance)'이 더해지면 사슬이 더 촘촘해진다. 이 결과물이 어떤 소스에서, 어떤 빌드 시스템을 거쳐 만들어졌는지를 함께 기록하는 것이다. 그러면 "믿을 만한 파이프라인에서 나온 것만 신뢰한다"라는 정책을 세울 수 있다.

기존 방식과 무엇이 달라지나

규제가 흐름을 밀어붙인다

이 변화가 빨라지는 데에는 규제의 힘도 크다. 공공 조달과 규제 산업에서 "납품하려면 SBOM을 제출하라"라는 요구가 늘고 있다. 한번 이런 조건이 표준이 되면, 공급망 전체가 따라 움직인다. 큰 고객이 요구하면 협력사가 맞추고, 그 협력사가 다시 자기 협력사에 요구하는 식으로 파급된다. 보안이 '있으면 좋은 것'에서 '없으면 거래가 안 되는 것'으로 성격이 바뀌고 있는 셈이다.

• 가시성 — 내가 쓰는 모든 구성요소를 목록으로 관리
• 무결성 — 서명으로 위변조 여부를 판별
• 추적성 — 출처 증명으로 빌드 경로까지 확인

완벽한 방어는 없다. 그러나 방향은 분명하다. "믿고 쓴다"에서 "확인하고 쓴다"로 넘어가는 것, 그것이 지금 오픈소스 생태계가 통과하고 있는 성장통이자 성숙의 과정이라고 나는 본다.

자주 묻는 질문

SBOM은 개발자가 직접 손으로 만들어야 하나요?

아닙니다. 요즘은 빌드 과정에서 SBOM을 자동으로 생성해 주는 도구가 많아, 파이프라인에 한 번 붙여 두면 릴리스마다 자동으로 만들어집니다. 수작업으로 성분표를 채우는 방식이 아니라, 빌드가 스스로 목록을 기록하게 하는 것이 일반적입니다.

서명만 하면 공급망 공격을 완전히 막을 수 있나요?

완전한 방어는 아닙니다. 서명은 "받은 것이 진짜인지"를 확인해 주지만, 애초에 서명하는 개발자의 계정이 탈취되면 악성 코드에도 정상 서명이 붙을 수 있습니다. 그래서 서명은 SBOM, 출처 증명, 접근 통제 같은 다른 장치와 함께 겹겹이 쌓아야 효과가 큽니다.

작은 팀이나 개인 프로젝트도 이걸 도입해야 하나요?

규모가 작을수록 부담이 커 보이지만, 자동화 도구 덕분에 진입 문턱은 많이 낮아졌습니다. 최소한 의존성 목록을 관리하고 릴리스에 서명하는 것만으로도 위험을 크게 줄일 수 있으니, 여력이 되는 범위에서 점진적으로 도입하는 것을 권합니다.

SBOM이 있으면 취약점이 자동으로 고쳐지나요?

고쳐 주지는 않습니다. SBOM은 "어디에 무엇이 들어 있는지"를 알려 주는 지도일 뿐입니다. 다만 그 지도가 있으면 취약점이 공개됐을 때 영향 범위를 즉시 파악하고 우선순위를 정해 대응할 수 있어, 대응 속도가 결정적으로 빨라집니다.