취약한 오픈소스 구성요소가 발견됐을 때, 조직이 운영하는 어떤 서비스에 그 구성요소가 들어 있는지 바로 확인할 수 있나요? 소프트웨어 공급망 규정 준수는 이 질문에 답할 수 있는 구성정보와 검증 기록을 갖추는 일에서 시작됩니다. 소프트웨어 자재 명세서인 SBOM의 작성부터 보안 도구 평가, 라이선스 검토, 운영 체계 연결까지 실제 업무에 필요한 기준을 살펴보겠습니다.
소프트웨어 공급망 규정 준수는 적용 범위 확인부터
같은 소프트웨어라도 납품 대상과 사용 환경에 따라 제출해야 하는 자료가 달라질 수 있습니다. 공공기관에 공급하는 제품, 금융 서비스에서 사용하는 시스템, 내부 업무용 애플리케이션에 동일한 의무가 있다고 가정하면 안 됩니다. 먼저 적용 법령과 감독 규정, 조달 조건, 고객 계약, 조직 내부 정책을 구분해야 합니다. 정책 발표나 추진 계획에 언급된 내용과 실제로 시행되는 법적 의무도 별도로 확인해야 합니다.
요구사항을 정리할 때는 단순히 ‘구성정보 제출’이라고 기록하지 않는 편이 좋습니다. 대상 제품, 제출 시점, 인정 형식, 필수 항목, 갱신 주기, 보관 기간, 검증 책임자를 각각 적어야 업무로 연결됩니다. 예를 들어 계약에서 배포본별 명세서를 요구한다면 개발 저장소를 분석한 결과만으로는 부족할 수 있습니다. 실제 고객에게 전달한 설치 파일이나 컨테이너 이미지와 명세서가 연결돼야 하기 때문입니다.
자산 분류도 함께 진행해야 합니다. 자체 개발 소프트웨어, 외부 구매 제품, 직접 사용하는 오픈소스, 외부 업체가 운영하는 서비스는 구성정보 확보 방식이 서로 다릅니다. 자체 개발 제품은 빌드 과정에서 정보를 수집할 수 있지만, 상용 제품은 공급업체의 제공 범위와 계약상 협조 의무를 확인해야 합니다. 서비스형 소프트웨어는 고객에게 배포 파일이 없으므로 구성정보 제공 방식과 책임 경계를 따로 협의할 필요가 있습니다.
이 과정의 결과물은 요구사항과 증빙을 연결한 목록입니다. 각 요구사항 옆에 담당 부서, 증빙 위치, 검토 상태, 미충족 사유를 기록하면 감사 준비와 개선 작업을 함께 관리할 수 있습니다. 규정 해석이 불명확하거나 여러 국가의 의무가 겹친다면 법무 담당자와 해당 분야 전문가의 검토가 필요합니다. 보안 도구가 만든 보고서 자체가 법적 적합성을 판정해 주는 것은 아닙니다.
SW 공급망 보안 가이드라인에서 SBOM의 역할
SBOM은 구성요소를 찾기 위한 기준 자료이지, 제품이 안전하다는 인증서는 아닙니다. 일반적으로 구성요소 이름과 버전, 공급자, 식별 정보, 구성요소 사이의 관계 등을 구조화해 기록합니다. 어떤 항목을 필수로 요구하는지는 적용 지침과 수신자의 조건에 따라 달라집니다. 작성 도구가 파일을 생성했다는 사실보다 대상 소프트웨어를 얼마나 정확히 설명하는지가 중요합니다.
직접 추가한 라이브러리만 기록하면 실제 공급망의 일부를 놓칠 수 있습니다. 그 라이브러리가 다시 사용하는 전이 의존성, 실행 환경에 포함된 운영체제 패키지, 제품에 복사해 넣은 외부 소스도 검토 대상입니다. 다만 개발용 테스트 도구와 실제 배포 구성요소를 구별하지 않으면 위험 평가가 불필요하게 커질 수 있습니다. 명세서에는 분석 대상과 포함 범위를 설명하는 정보가 함께 있어야 합니다.
구성정보는 취약점 데이터와 연결할 때 운영상 가치가 커집니다. 특정 취약점이 공개되면 영향을 받는 구성요소의 버전 범위를 확인하고, 자산 목록에서 관련 제품을 추적할 수 있습니다. 그러나 구성요소가 존재한다는 사실만으로 실제 공격이 가능하다고 판단해서는 안 됩니다. 문제가 있는 기능을 사용하는지, 외부 입력이 도달하는지, 보호 조치가 있는지를 추가로 검토해야 합니다.
미국 국립표준기술연구소의 공급망 위험 관리 관점에서도 구성정보는 다른 통제와 함께 활용하는 자료로 이해하는 것이 적절합니다. 공급업체 평가, 저장소 접근 통제, 빌드 환경 보호, 배포 무결성 확인, 사고 대응 절차를 대신하지 않습니다. SW 공급망 보안 가이드라인을 적용할 때 SBOM 생성만을 완료 기준으로 삼지 말아야 하는 이유입니다. 목록의 정확성과 그 목록을 활용하는 처리 절차를 함께 설계해야 합니다.
SBOM 작성 방법: 배포 결과물과 연결하기
가장 먼저 정할 것은 도구가 아니라 작성 대상입니다. 제품 전체인지, 개별 서비스인지, 특정 컨테이너 이미지인지에 따라 구성요소를 묶는 방식이 달라집니다. 제품 이름과 배포 버전, 빌드 식별자, 분석 대상 파일의 해시를 연결하면 어떤 결과물을 설명하는 문서인지 확인하기 쉽습니다. 동일한 버전 이름으로 서로 다른 파일을 배포하는 관행이 있다면 명세서 관리 전에 배포 식별 체계부터 정리해야 합니다.
다음으로 의존성 선언 파일과 버전 고정 파일을 수집합니다. 선언 파일은 허용되는 버전 범위를 담을 수 있고, 버전 고정 파일은 실제 선택된 의존성을 확인하는 데 도움이 됩니다. 여기에 빌드 결과물 분석을 더하면 소스 수준 정보와 배포 수준 정보를 비교할 수 있습니다. 분석 방법에 따라 누락되는 구성요소가 다르므로 한 가지 입력만으로 완전성을 단정하지 않는 것이 좋습니다.
컨테이너에서는 운영체제 패키지와 애플리케이션 패키지를 함께 확인해야 합니다. 여러 단계로 빌드하는 경우 빌드 도구가 최종 이미지에서 제거되기도 하므로, 빌드 환경 명세서와 실행 이미지 명세서의 목적을 구분해야 합니다. 반대로 실행 파일 내부에 묶인 라이브러리는 패키지 관리자 목록에 나타나지 않을 수 있습니다. 복사된 소스, 정적으로 결합된 코드, 공급업체가 포함한 바이너리는 별도 확인이 필요할 수 있습니다.
수집 후에는 이름과 버전 표기를 정리하고 구성요소 관계를 검증합니다. 같은 라이브러리가 다른 이름으로 중복 기록되거나, 서로 다른 패키지가 이름만 같아서 합쳐지는 문제를 점검해야 합니다. 라이선스를 확인하지 못한 항목은 추정값으로 채우지 말고 확인되지 않았다는 상태와 근거를 남겨야 합니다. 마지막으로 형식 검증, 필수 항목 점검, 배포본 연결 확인을 거쳐 승인된 파일을 배포 기록과 함께 보관합니다.
SPDX와 CycloneDX 차이: 형식보다 활용 목적
SPDX와 CycloneDX 차이를 단순히 ‘라이선스용’과 ‘보안용’으로 나누면 실제 선택에 도움이 되지 않습니다. SPDX는 소프트웨어 구성정보와 라이선스 정보를 교환하는 데 널리 활용되며, 구성요소 사이의 관계도 표현합니다. CycloneDX는 구성정보를 바탕으로 보안 분석과 운영에 필요한 정보를 교환하는 데 널리 쓰입니다. 두 형식 모두 구성요소 목록과 관계를 다룰 수 있어 목적이 상당 부분 겹칩니다.
실무에서는 수신자가 어떤 형식을 처리할 수 있는지가 우선입니다. 고객이 특정 형식과 명세 판본을 요구한다면 생성 도구가 그 조건을 지원하는지 확인해야 합니다. 같은 형식 이름을 사용하더라도 선택한 판본이나 확장 기능이 다르면 정보 처리 결과가 달라질 수 있습니다. 파일 구문을 읽는 기능과 모든 항목의 의미를 올바르게 해석하는 기능은 구분해서 평가해야 합니다.
SWID는 소프트웨어 식별과 자산 관리에 활용되는 태그 표준입니다. 공급망 관련 자료에서 함께 언급되지만, 상세한 의존성 관계를 중심으로 작성하는 명세서와 완전히 같은 역할을 한다고 보기는 어렵습니다. 따라서 세 형식을 단순히 동등한 대체재로 비교하기보다 식별, 구성정보 교환, 취약점 분석이라는 업무 목적을 먼저 정해야 합니다. 필요한 경우 서로 다른 표준의 정보를 연결하는 방식이 더 적합합니다.
형식 변환도 주의해야 합니다. 변환 도구가 파일을 만들어 냈더라도 원본의 관계 정보나 추가 속성이 모두 유지된다는 보장은 없습니다. 실제 제품의 표본 명세서를 변환한 뒤 구성요소 수, 관계, 식별자, 라이선스 표현, 문서 메타데이터가 어떻게 달라지는지 확인해야 합니다. 내부 표준 형식을 하나 정하더라도 외부 제출용 변환 결과는 별도로 검증하는 편이 안전합니다.
소프트웨어 공급망 보안 솔루션 비교의 핵심 기준
제품 비교는 기능 개수보다 동일한 대상을 얼마나 정확하게 분석하는지부터 시작해야 합니다. 같은 저장소와 같은 배포 파일을 여러 도구에 입력하고, 발견한 구성요소와 누락한 구성요소를 비교하면 차이가 드러납니다. 패키지 관리자 지원 범위뿐 아니라 바이너리, 컨테이너, 복사된 소스, 사내 패키지에 대한 분석 능력을 확인해야 합니다. 결과가 많은 도구가 반드시 더 정확한 도구는 아닙니다.
취약점 탐지 결과는 식별 정확성과 함께 평가해야 합니다. 이름이 비슷한 다른 패키지의 취약점을 연결하거나, 이미 수정된 공급업체 패키지를 원래 버전 번호만으로 판단하면 잘못된 경고가 발생할 수 있습니다. 도구가 패키지 출처와 배포판 수정 정보를 어떻게 다루는지 확인해야 합니다. 경고의 근거, 영향을 받는 버전 범위, 관련 설명을 담당자가 검토할 수 있어야 후속 판단이 가능합니다.
운영 기능에서는 자동 수집, 자산 연결, 예외 관리, 담당자 배정, 처리 이력 보존을 살펴봅니다. 취약점 경고가 보안팀에만 전달되고 제품 담당자에게 연결되지 않으면 분석 결과가 조치로 이어지기 어렵습니다. 개발자가 수정할 수 있는 단위로 결과를 전달하고, 수정된 빌드에서 문제가 해소됐는지 다시 확인할 수 있어야 합니다. 배포를 막는 정책과 경고만 하는 정책을 구분하는 기능도 중요합니다.
SBOM 솔루션 비교에는 데이터 통제와 운영 부담도 포함해야 합니다. 소스나 바이너리가 외부 서비스로 전송되는지, 사내 설치가 가능한지, 접근 권한과 감사 기록을 제공하는지 확인합니다. 비용은 라이선스 비용뿐 아니라 연동 개발, 분석 검토, 운영 인력, 저장 공간까지 고려해야 합니다. 평가 결과는 도구별 장단점과 미지원 영역을 기록해 남기고, 조직의 필수 요구사항을 충족하는지를 기준으로 판단하는 것이 좋습니다.
SBOM 도구 추천을 위한 역할별 선택법
모든 기능을 한 도구에서 해결하려 하기보다 생성과 분석, 관리 역할을 구분하면 선택이 쉬워집니다. Syft는 컨테이너 이미지와 파일시스템 등의 구성요소 목록을 만드는 용도로 활용됩니다. Trivy는 지원하는 분석 대상에 대해 취약점 점검과 구성정보 생성 등을 수행할 수 있습니다. 다만 지원 생태계와 출력 형식은 도구의 배포 상태에 따라 달라질 수 있으므로 실제 사용할 환경에서 검증해야 합니다.
CycloneDX 생태계에는 여러 개발 환경의 의존성을 명세서로 만드는 도구가 있습니다. 프로젝트의 의존성 해결 과정과 연결하면 선언된 목록보다 실제 선택된 패키지에 가까운 정보를 얻는 데 도움이 됩니다. 다만 생성기가 잘 처리하는 언어와 빌드 체계는 각각 다를 수 있습니다. 여러 언어를 사용하는 제품이라면 개별 결과를 어떻게 묶고 중복을 제거할지도 설계해야 합니다.
Dependency-Track은 구성정보를 받아 구성요소 위험을 분석하고 여러 프로젝트를 관리하는 용도로 활용됩니다. 이를 생성 도구와 연결하면 배포별 명세서를 지속적으로 분석하는 흐름을 만들 수 있습니다. 생성 도구가 우수하다고 해서 중앙 관리가 자동으로 해결되는 것은 아니며, 관리 플랫폼이 있다고 해서 입력 명세서의 품질이 보장되는 것도 아닙니다. 각 도구의 경계를 명확히 해야 장애와 누락의 원인을 찾기 쉽습니다.
SBOM 도구 추천을 요청하기 전에는 대표적인 정상 사례와 까다로운 사례를 준비하는 편이 좋습니다. 일반적인 웹 애플리케이션만 시험하면 사내 패키지, 정적 결합 프로그램, 공급업체 바이너리에서 발생하는 한계를 놓칠 수 있습니다. 평가에는 구성요소 누락, 잘못된 식별, 처리 시간, 수동 검토량, 결과 재현성을 포함합니다. 공개 도구와 상용 도구 모두 조직의 실제 배포 과정에서 같은 기준으로 시험해야 비교가 공정해집니다.
오픈소스 라이선스 규정 준수 도구와 검토 절차
취약점이 없다고 해서 오픈소스 사용 의무까지 충족되는 것은 아닙니다. 라이선스 검토는 사용한 코드의 조건과 실제 이용 방식을 함께 확인하는 별도의 업무입니다. 저작권 고지 보존, 라이선스 문서 제공, 수정 사항 표시, 소스 제공 의무 등이 검토 대상이 될 수 있습니다. 어떤 의무가 발생하는지는 해당 라이선스와 배포 형태, 결합 방식 등 구체적인 조건에 따라 달라집니다.
패키지 메타데이터의 라이선스 표기만 신뢰하면 오류가 생길 수 있습니다. 저장소의 선언과 배포 파일에 포함된 문서가 다르거나, 하나의 패키지에 여러 권리자의 코드가 포함되는 경우가 있기 때문입니다. ScanCode Toolkit은 파일의 라이선스와 저작권 정보를 분석하는 데 활용할 수 있고, FOSSology는 라이선스 분석과 검토 업무에 활용됩니다. 어느 도구든 자동 탐지 결과를 법률 판단으로 그대로 대체해서는 안 됩니다.
검토 과정에서는 선언된 라이선스와 실제 자료를 바탕으로 판단한 라이선스를 구분하는 것이 유용합니다. 근거 파일, 검토자, 판단 날짜, 허용 조건을 남기면 같은 구성요소를 다시 사용할 때 검토를 이어갈 수 있습니다. 이중 라이선스는 선택 가능한 조건을 확인해야 하며, 복합 라이선스 표현은 여러 조건이 함께 적용되는지 구별해야 합니다. 단순히 허용 목록에 있는 이름이 포함됐다는 이유만으로 승인하면 안 됩니다.
오픈소스 라이선스 규정 준수 도구의 출력은 배포 절차와 연결돼야 합니다. 고지문과 필요한 라이선스 문서를 제품에 포함했는지, 소스 제공 의무가 있다면 이행 방법이 준비됐는지 확인합니다. 구성요소가 바뀌면 고지 자료도 다시 생성하거나 검토해야 합니다. 의무 해석이 어렵거나 사업상 영향이 큰 경우에는 법무 검토를 거쳐 승인 조건을 기록하는 것이 적절합니다.
SW 공급망 보안 로드맵: 자동화와 운영 연결
자동화의 출발점은 모든 시스템을 한꺼번에 연결하는 것이 아니라 반복 가능한 기준 흐름을 만드는 것입니다. 대표 제품을 선정해 빌드 완료 시 구성정보를 생성하고, 형식과 필수 항목을 검사한 뒤, 배포 결과물과 함께 저장하는 과정을 먼저 정립합니다. 생성 실패나 분석 누락이 발생했을 때 누가 처리할지도 정해야 합니다. 성공한 경우만 기록하는 자동화는 감사와 장애 분석에 충분하지 않습니다.
그다음 중앙 자산 목록과 연결합니다. 제품 담당자, 운영 환경, 배포 상태, 고객 제공 여부를 함께 관리하면 구성요소 경고를 실제 책임자에게 전달할 수 있습니다. 개발 중인 결과물과 운영 중인 결과물을 구분해야 조치 우선순위도 합리적으로 정할 수 있습니다. 사용이 종료된 배포본의 기록은 보존 정책에 따라 관리하되, 활성 자산과 혼동되지 않도록 상태를 표시합니다.
지속적인 취약점 점검은 명세서를 매 순간 다시 만드는 것과 다릅니다. 배포 파일이 바뀌면 구성정보를 갱신하고, 취약점 정보가 바뀌면 저장된 구성정보를 다시 평가하는 방식으로 나눌 수 있습니다. 변경 이벤트와 점검 주기를 조합하면 같은 파일을 불필요하게 반복 분석하는 부담을 줄일 수 있습니다. 실시간 점검이라는 요구가 있다면 허용 지연과 대상 범위를 계약이나 운영 기준에서 구체화해야 합니다.
위험 처리에는 예외 승인과 재검토 조건이 필요합니다. 수정할 수 없는 외부 제품이나 즉시 업데이트하기 어려운 시스템은 임시 보호 조치, 공급업체 대응 계획, 검토 기한을 기록해야 합니다. 예외는 경고를 숨기는 기능이 아니라 판단 근거를 남기는 절차여야 합니다. 운영 지표도 생성 파일 수보다 배포본 연결률, 미확인 구성요소, 담당자 배정 상태, 조치 완료 검증 여부에 초점을 맞추는 편이 유용합니다.
SBOM 규정 준수에서 자주 생기는 오해
‘명세서를 제출했으니 규정 준수가 끝났다’는 판단이 가장 흔한 오해입니다. 제출 형식뿐 아니라 대상 범위, 정확성, 갱신, 취약점 처리, 증빙 보관 등 별도의 조건이 있을 수 있습니다. 구매한 소프트웨어의 명세서를 받았더라도 실제 설치된 배포본과 일치하는지 확인해야 합니다.
또한 구성요소 목록은 빌드 과정의 신뢰성을 직접 증명하지 않습니다. 누가 어떤 소스와 환경으로 결과물을 만들었는지 보여 주는 출처 증빙, 결과물 서명, 접근 통제 기록은 서로 다른 질문에 답합니다. 해시는 파일의 동일성을 확인하는 데 도움이 되지만, 그 파일이 안전하거나 적법하다는 사실까지 증명하지는 않습니다.
구성정보가 보안상 민감할 수 있다는 우려도 타당하지만, 무조건 공개하거나 무조건 비공개로 둘 필요는 없습니다. 내부 분석용 자료와 외부 제출용 자료의 범위를 나누고, 수신자의 필요와 계약 조건에 따라 접근 권한을 정할 수 있습니다. 다만 요구되는 정보를 임의로 삭제해 제출 요건을 훼손하지 않도록 보안 담당자와 계약 담당자가 함께 검토해야 합니다.
소프트웨어 공급망 보안 로드맵을 실행하는 점검표
첫 실행 과제는 대표 배포본 하나를 끝까지 추적해 보는 것입니다. 적용 요구사항을 정리하고, 실제 배포 파일에서 구성정보를 생성한 뒤, 취약점 분석과 라이선스 검토 결과를 담당자에게 연결합니다. 이 과정에서 누락되는 정보와 수작업이 필요한 지점을 기록하면 다음 자동화 대상이 명확해집니다. 처음부터 조직 전체의 완벽한 명세서를 목표로 삼기보다 검증 가능한 흐름을 확보하는 편이 현실적입니다.
완료 기준은 문서 존재 여부보다 재현 가능성으로 정하는 것이 좋습니다. 동일한 배포본에 대해 분석 범위를 설명할 수 있는지, 구성요소 식별의 근거가 있는지, 경고 처리와 예외 승인 기록을 확인할 수 있는지 점검합니다. 공급업체 자료가 부족하다면 미확인 상태와 보완 요청을 명시해야 합니다. 확인하지 못한 영역을 숨기지 않는 것이 공급망 관리의 신뢰성을 높입니다.
운영이 안정되면 제품군별 차이를 반영해 범위를 확장합니다. 웹 서비스, 데스크톱 프로그램, 임베디드 제품은 구성정보 수집 방식과 배포 주기가 다르므로 하나의 절차를 그대로 적용하기 어렵습니다. 공통 기준은 유지하되 분석 도구와 검토 항목은 제품 특성에 맞게 조정합니다. 결국 공급망 규정 준수의 핵심은 구성요소를 아는 것, 그 정보를 실제 배포본과 연결하는 것, 위험과 의무를 처리한 근거를 남기는 것입니다.
