왜 Runtime SBOM인가? 실행 중 소프트웨어 공급망을 지키는 5가지 핵심

새로운 취약점이 발표되는 순간, 보안팀이 가장 먼저 던지는 질문은 대개 하나입니다.

“우리 시스템에 해당 라이브러리가 있는가?”

문제는 이 질문에 즉시, 그리고 확실하게 답하기가 생각보다 어렵다는 데 있습니다. 빌드 기록에는 특정 버전의 라이브러리가 포함되어 있다고 나와 있고, 배포 문서도 정상적으로 관리되고 있을 수 있습니다. 그러나 그 정보만으로는 지금 이 순간 운영 서버에서 실제로 어떤 코드가 로드되어 실행 중인지까지 증명하기 어렵습니다.

예를 들어 운영 환경에서는 다음과 같은 변수가 발생할 수 있습니다.

배포 이후 설정 변경으로 특정 모듈이 추가 로드된 경우
플러그인, 에이전트, 동적 라이브러리가 실행 시점에 주입된 경우
개발·스테이징·운영 환경 간 구성 차이로 다른 의존성이 활성화된 경우
컨테이너 이미지에는 없었지만, 서버 환경에 남아 있던 구성 요소가 참조된 경우
긴급 패치나 수동 변경으로 빌드 산출물과 실제 운영 상태가 달라진 경우

이때 빌드 시점에 생성한 SBOM은 중요한 출발점이지만, 운영 환경의 현실을 완전히 보여주는 답은 아닐 수 있습니다. 빌드 SBOM이 “무엇을 만들었는가”를 설명한다면, 보안팀이 사고 대응 과정에서 정말 알고 싶은 것은 “무엇이 실제로 실행되고 있는가”입니다.

바로 이 지점에서 Runtime SBOM이 등장합니다.

Runtime SBOM은 애플리케이션이나 컨테이너가 실행되는 동안 실제로 로드된 라이브러리, 바이너리, 패키지, 플러그인 등의 구성 정보를 수집해 SBOM 형태로 정리하는 접근 방식입니다. 즉, 정적인 배포 명세서가 아니라 운영 중인 시스템의 살아 있는 소프트웨어 인벤토리에 가깝습니다.

이 방식은 새로운 취약점이 공개됐을 때 특히 강력합니다. 보안팀은 단순히 “해당 라이브러리가 저장소나 이미지에 포함됐는가”만 확인하는 데 그치지 않고, 다음과 같은 질문까지 검증할 수 있습니다.

취약한 라이브러리가 실제 운영 서버에서 실행 중인가?
어떤 서비스와 인스턴스에 영향을 주는가?
빌드 당시 승인되지 않은 모듈이 운영 환경에 존재하는가?
현재 실행 구성은 승인된 SBOM 및 배포 정책과 일치하는가?

이는 Software Security의 관점을 크게 바꿉니다. 보안은 더 이상 개발 단계에서 코드를 검사하고 배포 전에 취약점을 차단하는 활동만으로 완성되지 않습니다. 운영 환경에서 실제 상태를 지속적으로 확인하고, 빌드 결과와 실행 결과의 차이를 발견하는 과정까지 포함해야 합니다.

결국 Runtime SBOM의 핵심 가치는 단순한 목록 생성에 있지 않습니다. 그것은 조직이 운영 중인 소프트웨어를 제대로 이해하고 있는지, 그리고 침해·취약점·비인가 변경의 징후를 얼마나 빠르게 발견할 수 있는지를 검증하는 기술입니다.

빌드 기록과 실행 현실 사이의 간극: Software Security가 놓치기 쉬운 지점

같은 소스 코드로 빌드했고, CI/CD 파이프라인에서 SBOM까지 생성했습니다. 그렇다면 운영 서버도 그 SBOM에 적힌 구성 요소만 실행하고 있을까요?

현실은 더 복잡합니다. 개발·검증·운영 환경은 서로 다른 설정, 플러그인, 환경 변수, 컨테이너 이미지, 외부 라이브러리를 가질 수 있습니다. 저장소에 보관된 SBOM은 “무엇을 만들었는지”를 보여주지만, 운영 환경은 “무엇이 실제로 실행되고 있는지”를 보여줍니다.

이 차이가 바로 현대 Software Security와 공급망 보안에서 가장 까다로운 사각지대가 됩니다.

빌드 시점 SBOM이 알려주는 것과 알려주지 못하는 것

빌드 시점 SBOM은 소스 코드, 패키지 매니저, 컨테이너 이미지, 빌드 산출물을 분석해 구성 요소 목록을 만듭니다. 예를 들어 Gradle, npm, Maven 같은 도구의 의존성 정보를 기반으로 라이브러리 이름, 버전, 라이선스, 간접 의존 관계를 기록합니다.

이 방식은 다음과 같은 질문에 강합니다.

어떤 오픈소스와 라이브러리가 빌드에 포함됐는가?
알려진 취약점이 포함된 패키지가 있는가?
허용하지 않는 라이선스가 사용됐는가?
배포 전에 정책 위반을 차단할 수 있는가?

하지만 빌드 SBOM만으로는 운영 환경의 모든 변수를 설명하기 어렵습니다. 특히 다음 상황에서는 기록과 현실이 달라질 수 있습니다.

운영 서버에만 존재하는 외부 JAR, 네이티브 라이브러리, 플러그인
환경별 설정에 따라 선택적으로 활성화되는 모듈
컨테이너 기동 뒤 다운로드되거나 마운트되는 구성 요소
관리자가 긴급 조치 과정에서 추가한 패치 파일
애플리케이션 서버 또는 운영체제 수준에서 동적으로 로드되는 라이브러리
빌드 이후 변경된 베이스 이미지와 실행 환경

즉, SBOM이 정확하게 생성됐더라도 그것은 특정 시점의 빌드 결과를 설명하는 문서일 수 있습니다. 운영 서버에서 실제로 메모리에 올라가고 호출되는 코드까지 보장하는 증거는 아닙니다.

빌드 SBOM은 설계도에 가깝고, Runtime SBOM은 현재 가동 중인 건물의 상태 점검표에 가깝습니다.

“저장소의 기록”과 “운영 서버의 사실”은 왜 달라질까

개발 환경에서는 최신 라이브러리를 사용했지만, 운영 환경은 호환성 문제로 이전 버전을 유지하는 경우가 있습니다. 반대로 운영 장애를 해결하기 위해 특정 모듈을 임시로 교체하거나, 외부 솔루션이 추가 라이브러리를 삽입하는 경우도 있습니다.

컨테이너 환경에서도 차이는 발생합니다. 이미지 생성 시점에는 안전했던 구성이라도, 실행 중 볼륨 마운트나 초기화 스크립트, 외부 레지스트리 연동을 통해 새로운 파일이 유입될 수 있습니다. Java 애플리케이션의 경우 애플리케이션 서버 설정, 클래스패스, 플러그인 구조에 따라 빌드 단계에서 명확히 드러나지 않은 코드가 실행될 가능성도 있습니다.

이 문제는 취약점 대응 때 더욱 선명해집니다. 새로운 CVE가 발표됐을 때 보안팀이 궁금한 것은 단순히 “취약 라이브러리를 구매하거나 빌드한 적이 있는가”가 아닙니다.

실제로 필요한 질문은 다음과 같습니다.

취약한 구성 요소가 현재 운영 중인 서버에 존재하는가?
존재한다면, 실제로 로드되거나 실행되고 있는가?
어느 서비스, 어느 버전, 어느 컨테이너에서 사용되는가?
빌드 시점 SBOM과 운영 환경 사이에 승인되지 않은 차이가 있는가?
즉시 패치해야 하는 대상은 무엇인가?

이 질문에 빠르게 답하지 못하면, 취약점 대응은 전체 시스템을 대상으로 한 광범위한 추정 작업이 됩니다. 반대로 실행 현실을 파악하면 실제 위험이 높은 대상을 우선 처리하는 위험 기반 대응이 가능해집니다.

Runtime SBOM이 메우는 마지막 간극

Runtime SBOM은 애플리케이션이 실행되는 시점에 실제로 로드된 구성 요소를 수집해 SBOM 형태로 관리하는 접근입니다. 에이전트나 런타임 훅을 활용해 바이너리, 라이브러리, 패키지, 플러그인, 설정 정보 등을 관찰하고, 이를 빌드 시점 SBOM과 비교할 수 있습니다.

이때 핵심은 빌드 SBOM을 대체하는 것이 아닙니다. 두 SBOM은 서로 다른 질문에 답합니다.

구분	빌드 시점 SBOM	Runtime SBOM
기준 시점	빌드·패키징·배포 전	실행·운영 중
핵심 질문	무엇을 만들었는가?	무엇이 실제로 실행되는가?
주요 데이터	의존성 트리, 빌드 산출물, 이미지 구성	로드된 라이브러리, 실행 모듈, 운영 설정
주요 활용	배포 전 정책 검증, 취약점 사전 차단	운영 중 이상 탐지, 포렌식, 실제 영향 분석
대표 리스크	동적 로딩 및 운영 변경 미반영	성능 오버헤드, 수집 범위·정확도 관리

예를 들어 빌드 SBOM에 없는 라이브러리가 운영 서버에서 발견된다면, 이는 단순한 자산 누락이 아닐 수 있습니다. 승인되지 않은 변경, 잘못된 배포, 취약한 플러그인, 또는 공급망 침해 징후를 검토해야 하는 신호가 됩니다.

반대로 빌드 SBOM에는 취약 라이브러리가 기록돼 있지만 운영 환경에서 해당 모듈이 실제로 배포되지 않았거나 로드되지 않았다면, 대응 우선순위를 더 정교하게 조정할 수 있습니다.

무엇을 신뢰해야 할까: 하나가 아니라 ‘검증 가능한 연결’이다

저장소의 SBOM과 운영 서버의 Runtime SBOM 가운데 하나만 선택해야 하는 것은 아닙니다. 신뢰해야 할 대상은 두 데이터를 연결하는 검증 가능한 흐름입니다.

소스와 의존성 정보에서 빌드 SBOM을 생성하고
빌드 산출물과 SBOM에 서명하며
배포 과정에서 무결성과 정책을 검증하고
운영 환경에서 Runtime SBOM으로 실제 구성을 확인하고
두 결과의 차이를 지속적으로 분석하는 체계가 필요합니다.

이 연결이 갖춰질 때 조직은 “우리는 안전한 라이브러리를 빌드했다”는 주장에 머물지 않고, “현재 운영 중인 서비스가 승인된 구성으로 실행되고 있다”는 사실까지 입증할 수 있습니다.

결국 Software Security의 핵심은 문서를 많이 만드는 데 있지 않습니다. 빌드 기록과 실행 현실의 차이를 발견하고, 그 차이가 보안 위험으로 바뀌기 전에 통제하는 데 있습니다.

XSCAN Server Runtime과 Software Security: 실행 순간을 증거로 바꾸다

운영 서버에서 실제로 어떤 코드가 실행되고 있는지 자동으로 포착하고, 그 결과를 취약점·무결성 검증에 활용할 수 있다면 공급망 보안의 기준은 달라집니다. 빌드 당시 작성한 목록이 아니라, 지금 서비스 중인 시스템의 실체를 확인할 수 있기 때문입니다.

국내에서는 레드펜소프트의 XSCAN Server Runtime이 이러한 Runtime SBOM 접근법을 상용 솔루션으로 제시하고 있습니다. 핵심은 단순합니다. 애플리케이션이 실행되는 순간 로드되는 라이브러리, 패키지, 모듈, 플러그인 등을 식별하고 이를 SBOM 형태로 정리해 운영 환경의 구성 정보를 검증하는 것입니다.

빌드 결과물과 운영 현실의 간극

기존 Build-time SBOM은 개발과 배포 과정에서 매우 중요합니다. 소스 코드와 의존성 파일을 분석해 어떤 오픈소스와 라이브러리가 포함됐는지 기록하고, CI/CD 파이프라인에서 취약점을 검사할 수 있습니다.

하지만 운영 환경은 언제나 빌드 결과물과 완전히 같다고 단정하기 어렵습니다.

환경별 설정에 따라 특정 모듈만 동적으로 로드될 수 있습니다.
플러그인, 네이티브 라이브러리, 외부 에이전트가 운영 서버에서 추가될 수 있습니다.
긴급 패치나 수동 설정 변경으로 배포 당시와 다른 구성이 실행될 수 있습니다.
컨테이너와 가상화 환경에서는 이미지, 런타임, 설정값의 조합에 따라 실제 동작 구성이 달라질 수 있습니다.

이 지점에서 Runtime SBOM은 중요한 역할을 합니다. “무엇을 만들었는가”를 기록하는 데서 멈추지 않고, “무엇이 현재 실행 중인가”를 증명하는 운영 보안 데이터를 제공하기 때문입니다.

실행 중인 구성 요소를 보안 인벤토리로 전환

XSCAN Server Runtime과 같은 접근법은 운영 서버 또는 애플리케이션 런타임에서 실제 로드된 구성 요소를 수집하고, 이를 기반으로 실행 시점의 SBOM을 생성하는 방향에 초점을 둡니다.

이렇게 생성된 Runtime SBOM은 다음과 같은 질문에 답하는 데 활용될 수 있습니다.

현재 서비스에서 실제로 사용 중인 오픈소스와 라이브러리는 무엇인가?
특정 취약점이 발표됐을 때, 해당 구성 요소가 운영 서버에 존재하는가?
존재한다면 단순 설치 상태인가, 실제 실행·로드 상태인가?
빌드 시점 SBOM에 없던 모듈이나 비인가 구성 요소가 추가됐는가?
배포 아티팩트와 운영 환경의 구성·무결성 정보는 일치하는가?

예를 들어 치명적인 오픈소스 취약점이 공개됐을 때, 조직은 단순히 전체 자산을 광범위하게 검색하는 데 그치기 쉽습니다. 반면 Runtime SBOM을 활용하면 실제 운영 중인 서비스에서 해당 라이브러리가 로드됐는지, 어떤 버전이 사용되고 있는지, 우선 대응이 필요한 시스템은 어디인지 더 빠르게 좁혀갈 수 있습니다.

취약점 점검을 넘어 무결성 검증까지

Runtime SBOM의 가치는 취약점 식별에만 있지 않습니다. 공급망 공격은 정상적인 빌드·배포 흐름 밖에서 악성 모듈이 삽입되거나, 운영 환경의 구성 요소가 변조되는 방식으로도 발생할 수 있습니다.

따라서 실행 시점의 구성 정보를 빌드·배포 단계에서 생성한 SBOM과 비교하면 다음과 같은 이상 징후를 확인하는 데 도움이 됩니다.

검증 대상	확인할 수 있는 보안 의미
빌드 SBOM과 Runtime SBOM의 차이	승인되지 않은 모듈, 누락된 구성 요소, 환경별 변경 사항 식별
라이브러리 버전 정보	취약 버전의 실제 사용 여부 및 패치 우선순위 판단
실행 파일·패키지 무결성	변조 또는 비정상 교체 가능성 점검
설정·실행 환경 정보	운영 환경에서만 발생하는 보안 위험 추적
SBOM 서명·검증 정보	구성 목록의 신뢰성과 유통 과정의 추적성 강화

이러한 검증 체계가 갖춰지면 보안팀은 “취약한 패키지가 설치돼 있는가”라는 질문을 넘어, “취약한 코드가 지금 이 서비스에서 실행되고 있는가”라는 더 실질적인 질문에 대응할 수 있습니다. 이것이 Software Security 관점에서 Runtime SBOM이 주목받는 이유입니다.

운영 단계가 공급망 보안의 마지막 빈칸을 채운다

공급망 보안은 개발 단계의 SAST, 오픈소스 분석을 위한 SCA, 배포 전 이미지 스캔, CI/CD 정책 검증만으로 완성되지 않습니다. 소프트웨어는 결국 운영 환경에서 사용자와 만나고, 공격 역시 그 지점에서 현실화됩니다.

Runtime SBOM은 개발·빌드·배포 과정에서 축적한 보안 정보를 운영 단계까지 연결합니다. 즉, DevSecOps가 만든 신뢰의 사슬이 실제 서비스 환경에서도 유지되는지 확인하는 장치가 될 수 있습니다.

다만 도입 시에는 몇 가지 검토가 필요합니다.

런타임 수집 에이전트나 모니터링 기능이 서비스 성능에 미치는 영향
Java, 네이티브 바이너리, 컨테이너, 동적 플러그인 등 환경별 관찰 범위
CycloneDX, SPDX 등 표준 SBOM 포맷과 기존 보안 도구의 연동성
수집된 SBOM의 정확도와 디지털 서명 기반 신뢰성
취약점 탐지 이후 담당자 지정, 패치, 예외 승인, 재검증으로 이어지는 대응 프로세스

결국 XSCAN Server Runtime이 제시하는 메시지는 명확합니다. 공급망 보안은 더 이상 “배포 전에 검사하는 일”에 머물 수 없습니다. 실행 순간의 구성 자체를 증거로 확보하고 검증하는 것, 그것이 운영 환경 중심의 새로운 Software Security 기준이 되고 있습니다.

SBOM을 목록이 아닌 신뢰 체계로 만드는 Software Security 전략

SBOM을 만들었다는 사실만으로 시스템이 안전해지는 것은 아닙니다. 부정확한 목록, 검증되지 않은 출처, 서명 없는 파일은 오히려 “보안이 관리되고 있다”는 착각을 만들 수 있습니다. 진짜 Software Security는 SBOM을 단순한 문서가 아니라, 생성부터 배포·운영·폐기까지 추적하고 검증할 수 있는 신뢰 체계로 다루는 데서 시작됩니다.

정확한 SBOM이 보안 대응의 출발점입니다

SBOM의 첫 번째 조건은 정확성입니다. 실제로 포함되지 않은 구성 요소가 목록에 있거나, 반대로 운영 중인 라이브러리가 누락되면 취약점 대응의 우선순위가 왜곡됩니다. 특히 간접 의존성, 컨테이너 베이스 이미지, 런타임 플러그인, 동적 로딩 모듈은 정적 분석만으로 놓치기 쉽습니다.

따라서 조직은 빌드 단계에서 생성한 SBOM을 기본 자산으로 관리하되, 운영 환경에서 확인한 Runtime SBOM으로 이를 지속적으로 보완해야 합니다.

빌드 시점 SBOM: 소스, 패키지 매니저, 빌드 산출물을 기준으로 구성 요소를 식별합니다.
배포 시점 검증: 배포되는 이미지·패키지·바이너리가 승인된 SBOM과 일치하는지 확인합니다.
실행 시점 SBOM: 실제 서버나 컨테이너에서 로드된 라이브러리와 모듈을 확인합니다.

이 세 결과가 서로 연결되어야 “무엇을 만들었는가”뿐 아니라 “무엇이 실제로 실행되고 있는가”까지 설명할 수 있습니다.

출처와 변경 이력을 증명해야 합니다

SBOM에는 라이브러리 이름과 버전만 기록해서는 충분하지 않습니다. 해당 구성 요소가 어디서 왔고, 어떤 과정을 거쳐 제품에 포함됐는지를 함께 추적할 수 있어야 합니다.

예를 들어 동일한 버전의 오픈소스 패키지라도 공식 저장소에서 내려받은 것인지, 내부 미러 저장소를 거친 것인지, 개발자가 임의로 수정한 파일인지에 따라 신뢰 수준은 달라집니다. 공급망 공격자는 정상 패키지와 유사한 이름을 사용하거나, 빌드 과정에 악성 코드를 주입하는 방식으로 침투할 수 있습니다.

이를 줄이기 위해서는 다음 정보가 SBOM 및 배포 메타데이터와 연결되어야 합니다.

구성 요소의 이름, 버전, 해시값
패키지 공급자와 다운로드 경로
사용된 빌드 도구와 빌드 환경
빌드 시간, 담당 파이프라인, 승인 이력
배포 대상 서버·컨테이너 이미지·서비스 버전
변경 사유와 예외 승인 기록

핵심은 “이 라이브러리가 있다”가 아니라, “이 라이브러리가 신뢰할 수 있는 출처에서 왔으며 승인된 절차를 거쳐 배포됐다”고 증명하는 것입니다.

디지털 서명으로 SBOM 자체를 보호해야 합니다

SBOM도 하나의 중요한 보안 자산입니다. 공격자가 SBOM 파일을 조작하면 취약한 구성 요소를 숨기거나, 존재하지 않는 정보를 추가해 보안팀의 판단을 흐릴 수 있습니다. 따라서 SBOM은 생성 직후부터 무결성을 보호해야 합니다.

실무에서는 다음과 같은 흐름을 고려할 수 있습니다.

CI/CD 파이프라인에서 빌드 산출물과 SBOM을 함께 생성합니다.
생성된 SBOM에 디지털 서명 또는 해시를 적용합니다.
아티팩트 저장소에 바이너리, 컨테이너 이미지, SBOM, 서명 정보를 함께 보관합니다.
배포 단계에서 이미지와 SBOM의 해시·서명을 검증합니다.
운영 환경에서 Runtime SBOM을 수집해 승인된 구성과 비교합니다.

이 구조가 갖춰지면 배포 대상이 승인된 산출물인지, SBOM이 사후에 변조되지 않았는지, 실제 운영 환경이 정책과 일치하는지를 단계별로 확인할 수 있습니다.

SBOM은 생성물이 아니라 생애주기 관리 대상입니다

취약점 정보는 계속 바뀝니다. 오늘 안전한 라이브러리도 내일 새로운 CVE가 공개되면 즉시 점검 대상이 됩니다. 그래서 SBOM은 한 번 만들어 저장하는 문서가 아니라, 지속적으로 갱신·검증·폐기해야 하는 생애주기 자산입니다.

효율적인 관리 체계에는 다음이 필요합니다.

버전 관리: 애플리케이션 릴리스별 SBOM을 보존하고 차이를 비교합니다.
취약점 연계: 새 취약점이 공개되면 SBOM 인벤토리와 자동으로 교차 분석합니다.
정책 관리: 금지된 라이선스, 지원 종료 구성 요소, 고위험 패키지를 탐지합니다.
예외 관리: 즉시 조치가 어려운 취약점은 보완 통제와 만료일을 기록합니다.
폐기 관리: 서비스 종료나 구성 요소 교체 시 관련 SBOM과 증적의 보존 정책을 적용합니다.

특히 운영 환경에서는 Runtime SBOM을 통해 승인되지 않은 모듈, 오래된 라이브러리, 환경별 설정 차이를 찾아내야 합니다. 이는 감사 대응을 위한 자료를 넘어, 실제 공격 표면을 줄이는 운영 보안 활동입니다.

신뢰할 수 있는 SBOM은 운영 가시성으로 완성됩니다

공급망 보안의 궁극적인 질문은 단순합니다. “지금 이 시스템에서 무엇이 실행되고 있으며, 그것을 신뢰할 수 있는가?”입니다.

빌드 단계의 SBOM, 서명된 배포 산출물, 운영 중 수집된 Runtime SBOM을 연결하면 이 질문에 더 정확하게 답할 수 있습니다. 개발팀은 승인되지 않은 의존성 사용을 줄일 수 있고, 보안팀은 취약점 영향을 빠르게 판단할 수 있으며, 운영팀은 실제 서버 구성과 정책 간의 차이를 확인할 수 있습니다.

결국 SBOM의 가치는 목록의 길이에 있지 않습니다. 생성 경로가 검증되고, 변경 이력이 남으며, 배포와 실행 환경까지 연결될 때 비로소 SBOM은 공급망을 지키는 신뢰의 기반이 됩니다.

Software Security: 운영팀의 다음 질문, 실시간 가시성은 어디까지 필요한가

Runtime SBOM은 공급망 보안의 마지막 퍼즐처럼 보입니다. 빌드 시점에 기록된 의존성 목록을 넘어, 운영 환경에서 실제로 로드되고 실행되는 코드를 확인할 수 있기 때문입니다. 그러나 관찰 범위를 넓힌다고 해서 보안이 자동으로 완성되는 것은 아닙니다.

실행 중인 서버와 컨테이너를 지속적으로 분석하려면 에이전트, 런타임 훅, 로그 수집 체계가 필요합니다. 이 과정에서 성능 부담, 수집 데이터의 폭증, 오탐과 누락, 개인정보·기밀 설정값의 노출 가능성까지 함께 관리해야 합니다. 결국 운영팀은 다음 두 질문에 답해야 합니다.

무엇을 수집할 것인가?
그리고 수집한 정보를 어디까지 신뢰할 것인가?

관찰 범위는 넓을수록 좋은 것이 아니다

Runtime SBOM은 수집 대상에 따라 정확도와 운영 비용이 크게 달라집니다. 예를 들어 Java 기반 서비스라면 JAR 파일, 클래스 로더, 외부 라이브러리, 애플리케이션 서버 플러그인까지 관찰할 수 있습니다. 컨테이너 환경에서는 이미지 레이어, 실행 중인 프로세스, 마운트된 볼륨, 동적으로 내려받은 패키지까지 검토 대상이 될 수 있습니다.

하지만 모든 요소를 동일한 수준으로 수집하면 운영 복잡도가 빠르게 높아집니다.

관찰 대상	보안상 확인할 수 있는 내용	운영 시 고려할 점
패키지·라이브러리	실제 사용 중인 오픈소스와 버전	간접 의존성, 중복 패키지 식별 필요
실행 파일·바이너리	미등록 실행 파일, 변조 여부	해시 계산과 비교 정책 필요
동적 모듈·플러그인	운영 중에 추가된 코드	로드 시점 추적과 정상 기준선 필요
컨테이너 구성	이미지와 실행 환경의 차이	임시 컨테이너와 사이드카 관리 필요
환경 변수·설정 파일	실행 구성의 변경 여부	비밀정보 수집·마스킹 정책 필수
네트워크 연결	외부 다운로드와 비정상 통신	로그량 증가 및 개인정보 이슈 고려

따라서 초기 도입에서는 모든 런타임 행위를 수집하기보다, 자산 식별과 취약점 대응에 직접 필요한 정보부터 우선순위를 정하는 방식이 현실적입니다. 예를 들어 규제가 강한 서비스는 실행 중인 라이브러리와 컨테이너 이미지 무결성부터 점검하고, 이후 플러그인·설정 변경·외부 통신 분석으로 범위를 확장할 수 있습니다.

빌드 SBOM과 Runtime SBOM의 차이를 ‘경보’로 바꿔야 한다

Runtime SBOM의 핵심 가치는 단순히 새로운 목록을 만드는 데 있지 않습니다. 더 중요한 것은 빌드 시점에 승인된 구성과 운영 중 실제 구성의 차이를 찾아내는 것입니다.

대표적으로 다음과 같은 상황을 탐지할 수 있습니다.

빌드 SBOM에는 없던 라이브러리가 운영 서버에서 로드된 경우
승인되지 않은 플러그인이나 에이전트가 추가된 경우
긴급 조치 과정에서 수동으로 패치된 파일이 남아 있는 경우
컨테이너 이미지와 실제 실행 파일의 해시가 다른 경우
취약한 라이브러리가 존재하지만 실제 서비스에서 호출되지 않는 경우
개발 환경에는 없던 운영 전용 모듈이나 설정이 활성화된 경우

이 차이를 모두 치명적 사고로 판단해서는 안 됩니다. 운영 환경에는 모니터링 에이전트, 백업 도구, 인증 모듈처럼 정당한 사유로 추가되는 구성 요소가 존재합니다. 따라서 Software Security 관점에서 필요한 것은 “차이 발견” 자체보다 차이를 분류하고 승인 상태를 관리하는 정책입니다.

예를 들어 다음과 같이 대응 기준을 나눌 수 있습니다.

즉시 차단 또는 격리: 미서명 바이너리, 알려진 악성 해시, 금지된 라이선스 구성 요소
긴급 검토: 고위험 취약점이 있는 실제 로드 라이브러리, 승인되지 않은 외부 다운로드
정상 예외 등록: 운영 모니터링 도구, 승인된 보안 에이전트, 임시 유지보수 모듈
추세 관찰: 비활성 의존성, 사용 여부가 불명확한 구성 요소

수집 데이터도 공격 대상이 될 수 있다

Runtime SBOM은 운영 환경의 상세한 구조를 담습니다. 어떤 라이브러리가 실행되고 있는지, 어떤 버전이 사용되는지, 어떤 설정이 적용됐는지를 보여주는 데이터는 방어팀에는 중요한 자산이지만 공격자에게도 유용한 정보가 될 수 있습니다.

특히 환경 변수와 설정 파일을 함께 수집할 때는 API 키, 데이터베이스 접속 정보, 내부 주소, 인증서 경로 같은 민감 정보가 포함될 가능성이 있습니다. 따라서 수집 체계에는 다음과 같은 보호 장치가 필요합니다.

민감한 환경 변수와 설정값의 마스킹·토큰화
SBOM 및 런타임 관찰 데이터의 암호화 저장
역할 기반 접근 제어(RBAC)를 통한 조회 권한 분리
수집 에이전트와 중앙 관리 서버 간 상호 인증
SBOM 생성·수정·예외 승인 이력에 대한 감사 로그 유지
보존 기간이 지난 원시 데이터의 안전한 삭제

또한 SBOM 자체의 신뢰성도 검증해야 합니다. 수집 에이전트가 변조되었거나, 공격자가 런타임 정보를 위장할 수 있다면 Runtime SBOM은 잘못된 판단의 근거가 될 수 있습니다. 에이전트 바이너리 서명 검증, 수집 데이터 무결성 확인, 생성된 SBOM의 디지털 서명과 이력 관리는 선택이 아니라 기본 통제 항목에 가깝습니다.

운영팀이 먼저 정해야 할 최소 기준

Runtime SBOM 도입은 보안 솔루션 구매만으로 끝나지 않습니다. 운영팀, 개발팀, 보안팀이 함께 기준선을 정의해야 실제 효과를 낼 수 있습니다.

우선 다음 네 가지를 합의하는 것이 좋습니다.

보호 우선순위가 높은 서비스 식별
외부 공개 서비스, 개인정보 처리 시스템, 공공·금융 규제 대상, 핵심 API부터 적용 범위를 정합니다.
신뢰할 수 있는 기준 SBOM 정의
CI/CD에서 생성된 빌드 SBOM, 서명된 배포 아티팩트, 승인된 컨테이너 이미지를 기준선으로 삼습니다.
운영 환경의 차이 허용 정책 수립
어떤 구성 변경은 자동 차단할지, 어떤 변경은 승인 절차를 거칠지 명확히 정합니다.
취약점 대응 프로세스 연결
Runtime SBOM에서 취약 구성 요소가 발견되면 담당자 알림, 영향 서비스 확인, 패치·롤백, 예외 승인까지 이어지는 절차를 마련합니다.

Runtime SBOM의 목적은 운영 환경을 과도하게 감시하는 데 있지 않습니다. 목적은 “지금 실제로 실행 중인 소프트웨어를 신뢰할 수 있는가”라는 질문에 빠르고 근거 있게 답하는 것입니다. 관찰 범위와 성능, 데이터 보호와 분석 정확도 사이의 균형을 설계할 때, Runtime SBOM은 단순한 인벤토리를 넘어 실질적인 Software Security 통제 수단이 될 수 있습니다.

왜 Runtime SBOM인가? 실행 중 소프트웨어 공급망을 지키는 5가지 핵심