SBOM 파일을 만들었다고 해서 소프트웨어 공급망 규정 준수가 끝나는 것은 아닙니다. 같은 제품이라도 소스코드에서 만든 구성 목록과 실제 배포 파일에서 확인한 구성 목록은 달라질 수 있습니다. SBOM 규정 준수 컨설팅의 핵심은 이 차이를 설명하고, 납품 제품의 구성과 취약점 대응 이력을 검증 가능한 증거로 연결하는 데 있습니다.
SBOM 규정 준수 컨설팅이 해결해야 할 문제
좋은 컨설팅은 도구 설치보다 먼저 무엇을 입증해야 하는지 정의합니다. SBOM은 소프트웨어를 구성하는 구성요소와 관계를 구조화한 명세서입니다. 부품명만 나열한 문서와 달리, 구성요소의 버전, 식별자, 공급자, 의존 관계 등을 통해 특정 제품에 무엇이 포함됐는지 추적하도록 돕습니다. 다만 모든 항목이 모든 형식이나 계약에서 동일하게 필수인 것은 아니므로, 실제 제출 목적에 맞는 기준을 정해야 합니다.
기업이 요구받는 증거는 서로 다를 수 있습니다. 고객사는 납품한 실행 파일의 구성 목록을 원하고, 내부 보안팀은 개발 중 사용하는 의존성까지 확인하려 하며, 법무팀은 오픈소스 라이선스 의무를 검토할 수 있습니다. 이 목적을 하나의 검사 결과로 처리하면 빠지는 영역이 생깁니다. 컨설팅 범위에는 규제 적용성, 고객 계약, 분석 대상, 산출물 형식, 운영 책임을 각각 구분하는 작업이 포함되어야 합니다.
대표적인 산출물은 요구사항 대응표, 구성요소 식별 기준, 생성 절차, 검증 결과, 취약점 처리 절차, 증적 보관 정책입니다. 요구사항 대응표는 어떤 의무를 어떤 문서나 시스템 기록으로 입증할지 보여 줍니다. 생성 절차에는 분석 도구뿐 아니라 실행 시점과 실패 처리 방식도 들어갑니다. 증적 보관 정책은 제품 출시 후 문의가 들어왔을 때 당시의 목록과 판단 근거를 복원할 수 있도록 설계합니다.
계약서에는 완료의 의미도 구체적으로 적는 편이 좋습니다. 문서가 생성되는지만 확인할 것인지, 실제 산출물과 일치하는지 표본 검증할 것인지, 담당자가 스스로 재생성할 수 있어야 하는지에 따라 업무량이 달라집니다. 컨설턴트의 설명 없이 내부 담당자가 같은 결과를 재현할 수 있는 상태가 운영 이관의 실질적인 기준이 됩니다.
SBOM 의무화 한국: 법률과 납품 조건을 구분하기
국내 기업이라는 이유만으로 모든 소프트웨어에 동일한 SBOM 제출 의무가 적용된다고 단정하면 안 됩니다. 적용 여부는 법률과 하위 규정, 산업별 지침, 공공 조달 조건, 고객 계약에 따라 달라집니다. 정책 문서에서 활용을 권고하는 것과 특정 계약에서 제출을 의무화하는 것도 다릅니다. 따라서 국내 적용 검토에서는 문서의 이름보다 실제 구속력과 적용 대상을 확인해야 합니다.
첫 단계는 제품과 거래 관계를 분류하는 것입니다. 자체 서비스를 운영하는지, 설치형 소프트웨어를 납품하는지, 장비에 소프트웨어를 포함해 판매하는지에 따라 확인할 요구사항이 달라집니다. 해외 고객에게 공급하는 부품이라면 최종 제조사가 자체 규정 준수를 위해 구성 목록을 요구할 수도 있습니다. 이때 직접적인 법적 의무와 계약상 협조 의무는 별도로 기록하는 것이 정확합니다.
요구사항을 검토할 때는 대상 제품, 적용 시점, 제출 형식, 제출 주기, 공개 범위를 한 묶음으로 확인해야 합니다. 예를 들어 고객이 정기 제출을 요구해도 출시마다 제출하는지, 정해진 간격으로 제출하는지에 따라 자동화 설계가 달라집니다. 외부 제공이 필요하다면 구성요소 정보에 영업비밀이나 내부 경로가 섞이는지도 점검해야 합니다. 필요한 정보를 삭제해 목록의 유용성을 훼손하지 않으면서, 불필요한 내부 메타데이터는 줄이는 균형이 필요합니다.
확인 결과는 근거 문서와 함께 유지해야 합니다. 해당 조항, 적용 이유, 담당 부서, 재검토 조건을 기록하면 계약이 바뀌거나 새로운 제품군이 추가됐을 때 판단을 반복하기 쉽습니다. 국내 의무 범위를 설명하는 자료는 공식 법령과 계약 원문에 대조해야 하며, 법적 해석이 필요한 부분은 법무 담당자나 적격 전문가의 검토 대상으로 남겨 두는 편이 안전합니다.
EU CRA SBOM 요구사항과 기술문서의 연결
유럽연합 사이버복원력법인 CRA는 SBOM만 제출하면 충족되는 규정이 아닙니다. 적용 대상인 디지털 요소가 포함된 제품에 대해 보안 설계, 취약점 처리, 지원, 기술문서, 적합성 평가 등 여러 의무를 연결합니다. 유럽연합 시장에 제품을 공급하는 한국 기업도 제품 범위와 공급망에서의 역할에 따라 의무를 검토해야 합니다. 제조업체, 수입업체, 유통업체의 책임이 같지 않다는 점도 중요합니다.
CRA의 취약점 처리 요구사항에는 제품에 포함된 구성요소와 취약점을 식별하고 문서화하기 위해 기계 판독 가능한 SBOM을 작성하는 내용이 포함됩니다. 최소한 최상위 의존성을 포함하도록 요구하지만, 이것을 모든 하위 의존성을 무시해도 된다는 의미로 받아들이면 곤란합니다. 실제 취약점 분석에는 전이 의존성이나 장비 내부 구성요소가 필요할 수 있습니다. SPDX와 CycloneDX는 검토할 수 있는 표준 형식이지만, 법문이 이 두 형식만을 유일한 선택지로 지정한 것은 아닙니다.
SBOM을 일반 대중에게 모두 공개해야 한다는 의무와 감독기관에 필요한 자료를 제공해야 한다는 의무도 구별해야 합니다. 기술문서에는 구성 목록과 취약점 처리 체계를 연결하고, 적법한 요청에 대응할 수 있도록 관리하는 방식이 적절합니다. CRA의 기술문서와 적합성 선언 보관 의무는 제품의 시장 출시 후 10년 또는 지원 기간 중 더 긴 기간을 기준으로 합니다. 이를 구성 목록 파일 하나만 10년 보관하면 충분하다는 식으로 단순화하지 말고, 출시별 목록과 관련 판단 기록을 함께 보존할 필요가 있습니다.
적용 일정은 계획에 직접 영향을 주므로 구체적으로 구분해야 합니다. CRA는 2024년 12월 10일 발효됐으며, 주요 의무는 2027년 12월 11일부터 적용됩니다. 악용 중인 취약점과 제품 보안에 영향을 주는 심각한 사고에 관한 보고 의무는 2026년 9월 11일부터 적용됩니다. 모든 발견 취약점이 동일하게 보고 대상이 되는 것은 아니므로, 보고 대상 판단과 내부 대응 절차를 별도로 설계해야 합니다.
적합성 평가 역시 제품 분류에 따라 달라집니다. 모든 제품에 제삼자 평가가 필요한 것은 아니며, 중요하거나 핵심적인 제품 범주에서는 적용되는 평가 경로를 추가로 확인해야 합니다. CE 표시는 별도의 보안 인증과 같은 의미로 단정할 수 없습니다. 컨설팅에서는 CRA 공식 규정인 유럽연합 규정 2024/2847과 적용 가능한 지침을 근거로 제품 분류, 평가 경로, 기술문서 범위를 연결해야 합니다.
SPDX CycloneDX 차이: 형식보다 교환 목적이 먼저
두 형식 가운데 무엇이 우월한지를 묻기보다, 받는 조직이 어떤 정보를 어떤 방식으로 처리하는지 확인하는 것이 먼저입니다. SPDX는 소프트웨어 구성요소, 라이선스, 관계 등 정보를 교환하는 표준으로 널리 사용됩니다. CycloneDX도 구성요소와 의존 관계를 표현하며, 보안 분석 및 공급망 정보를 다루는 데 활용됩니다. 특정 형식을 선택했다고 해서 취약점 탐지 정확도나 규정 준수 수준이 자동으로 높아지지는 않습니다.
실무에서는 고객의 수신 시스템이 지원하는 형식과 명세 판본이 중요한 제약입니다. 생성 도구가 파일을 내보내더라도 수신 시스템에서 일부 필드를 읽지 못하면 정보가 유실될 수 있습니다. 의존 관계, 구성요소 식별자, 라이선스 표현, 외부 참조가 실제로 보존되는지 표본 문서로 확인해야 합니다. 특히 형식 변환을 거치는 경우에는 변환 전후 구성요소 수만 비교하지 말고 관계와 의미가 유지되는지도 점검해야 합니다.
명세에 맞는 문서와 내용이 정확한 문서는 다릅니다. 구조 검증에 통과해도 구성요소 버전이 틀리거나 실제 배포되지 않은 개발 의존성이 포함될 수 있습니다. 반대로 생성 도구가 지원하지 않는 필드 때문에 구조상 문제를 일으킬 수도 있습니다. 따라서 구조 검증, 필수 항목 검증, 실제 제품과의 대조를 별도 단계로 운영하는 것이 좋습니다.
내부 기준 형식은 하나로 정하되 고객별 출력 형식을 추가하는 방식도 검토할 수 있습니다. 다만 변환 과정에서 누락되는 정보를 문서화하고, 원본을 함께 보관해야 합니다. 형식 선택 회의에서는 파일 확장자보다 구성요소의 정체성, 의존 관계의 깊이, 수정 이력, 기밀 정보 처리 방식을 합의하는 데 시간을 쓰는 편이 생산적입니다.
SBOM 도구 비교와 블랙덕 SBOM 대안 평가
도구 비교는 기능 목록보다 동일한 제품을 분석했을 때의 결과 차이를 중심으로 진행해야 합니다. 상용 소프트웨어 구성 분석 플랫폼과 공개 도구는 지원 범위, 정책 관리, 운영 지원 방식이 다릅니다. 블랙덕 SBOM 대안을 검토하는 경우에도 단순히 구성 목록 생성 여부만 비교하면 기존에 사용하던 라이선스 검토나 승인 절차를 놓칠 수 있습니다. 대체하려는 기능과 그대로 유지해야 하는 기능을 먼저 나눠야 합니다.
공개 도구의 예로 Syft는 소프트웨어 구성 목록 생성에, Trivy는 취약점 점검과 구성 목록 관련 작업에, cdxgen은 다양한 개발 생태계의 구성 목록 생성에 활용됩니다. 각 도구의 지원 언어, 분석 방식, 출력 형식은 배포판과 설정에 따라 달라질 수 있습니다. 제품 소개만으로 지원 여부를 확정하지 말고 실제 프로젝트에서 결과를 확인해야 합니다. 이러한 도구가 상용 플랫폼의 모든 관리 기능을 그대로 대체한다고 가정해서도 안 됩니다.
평가용 표본에는 단순한 공개 패키지 프로젝트만 넣지 않는 편이 좋습니다. 내부 공통 라이브러리, 복사해 넣은 소스코드, 컨테이너 운영체제 패키지, 사전 컴파일된 파일처럼 실제 업무에서 어려움을 만드는 요소를 포함해야 합니다. 같은 구성요소를 중복으로 잡는지, 출처를 설명할 수 있는지, 버전을 정확히 식별하는지도 확인합니다. 탐지 개수가 많다는 사실만으로 정확도가 높다고 판단할 수는 없습니다.
운영 평가에는 폐쇄망 사용 가능성, 외부 전송 데이터, 권한 관리, 변경 이력, 자동화 연동, 지원 체계가 포함됩니다. 공개 도구를 여러 개 조합하면 사용료 부담을 줄일 수 있지만, 연동과 유지보수 책임은 내부에 남습니다. 상용 도구도 별도 설정이나 수동 검토가 필요할 수 있습니다. 최종 비교 기준은 특정 브랜드에 대한 선호가 아니라 누락 위험, 검증 노력, 운영 책임을 포함한 전체 부담이어야 합니다.
SBOM 자동 생성 도구를 개발 과정에 연결하는 방법
자동화의 핵심은 자주 실행하는 것이 아니라 정확한 출시물에 연결하는 것입니다. 개발 저장소에서 생성한 목록은 선언된 의존성을 보여 주지만, 패키징 과정에서 추가되거나 제거되는 구성요소까지 항상 반영하지는 못합니다. 컨테이너나 설치 파일을 분석하면 배포 상태를 더 직접적으로 확인할 수 있지만, 원래의 의존 관계나 공급자 정보를 충분히 복원하지 못할 수 있습니다. 두 결과를 목적에 맞게 결합하는 설계가 필요합니다.
생성 시점은 의존성 확정, 빌드 완료, 출시 승인 단계와 연결하는 것이 좋습니다. 의존성 잠금 파일이 바뀌면 개발 단계의 목록을 갱신하고, 배포 산출물이 완성되면 출시용 목록을 생성합니다. 이후 제품 버전, 빌드 식별자, 산출물 해시와 연결해 보관합니다. 같은 제품 이름을 가진 여러 빌드가 존재해도 어느 목록이 어느 파일에 대응하는지 구분할 수 있어야 합니다.
생성 실패를 어떻게 처리할지도 미리 정해야 합니다. 도구 실행이 실패했는데 빈 파일을 정상 산출물처럼 저장하거나, 이전 출시의 목록을 새 버전에 복사하면 자동화가 오히려 잘못된 확신을 줍니다. 필수 항목 누락과 구조 오류를 검사하고, 정책에 따라 배포를 보류하거나 담당자의 예외 승인을 받도록 해야 합니다. 예외에는 사유, 영향, 책임자, 재검토 조건을 남깁니다.
파일 해시는 대상 산출물을 식별하는 데 도움이 되지만, 구성 목록의 내용이 정확하다는 사실까지 보증하지는 않습니다. 서명도 발행자와 무결성을 확인하는 수단이지 구성요소 탐지가 완전하다는 증거는 아닙니다. 따라서 자동 생성 이후에도 누락 가능성이 높은 영역을 표본 검증해야 합니다. 자동화와 검증을 서로 대체하는 관계로 보지 않는 것이 운영 품질을 유지하는 출발점입니다.
SBOM 도입 방법: 시범 운영에서 전사 체계로
전사 도입은 모든 저장소에 도구를 한꺼번에 설치하는 방식보다 대표 제품의 전체 과정을 검증하는 방식이 효과적입니다. 첫 대상은 담당자가 명확하고 빌드 과정이 재현 가능하며 고객 요구가 구체적인 제품이 적합합니다. 너무 단순한 예제만 선택하면 실제 납품 과정의 문제를 발견하기 어렵습니다. 반대로 처음부터 가장 복잡한 제품만 선택하면 기본 절차를 정리하기 전에 예외 처리에 업무가 집중될 수 있습니다.
시범 운영에서는 제품 경계를 먼저 정의합니다. 서버 프로그램, 실행 환경, 설치 프로그램, 장비 내부 소프트웨어 중 무엇을 같은 제품으로 다룰지 정해야 합니다. 개발용 도구와 실제 포함 구성요소도 구분합니다. 이후 자동 생성 결과를 빌드 기록과 대조하고, 식별되지 않은 내부 구성요소에 이름과 버전 부여 규칙을 적용합니다. 이 작업이 정리되어야 다른 제품으로 확장할 때 결과의 일관성을 유지할 수 있습니다.
취약점 대응은 목록 생성과 별도 흐름으로 설계합니다. 구성요소 식별자를 취약점 정보와 연결한 뒤 제품에 실제로 영향을 주는지 검토하고, 수정이나 완화 조치를 결정합니다. 영향을 받지 않는다는 판단에는 실행 경로, 사용 기능, 적용 조건 같은 근거가 필요합니다. 이러한 판단을 기계 판독 가능한 방식으로 전달할 때는 VEX를 활용할 수 있지만, 근거 없는 제외 표시가 되어서는 안 됩니다.
역할 분담도 출시 절차에 포함해야 합니다. 개발팀은 구성 정보와 변경 내용을 확인하고, 보안팀은 취약점 판별과 우선순위를 검토하며, 법무 담당자는 라이선스 및 계약상 의무를 점검할 수 있습니다. 출시 책임자는 필요한 증적이 갖춰졌는지 확인합니다. 공급업체 구성 목록은 파일을 받는 데서 끝내지 말고 대상 버전, 제공 주기, 오류 정정 방식, 취약점 통보 경로까지 합의해야 지속적으로 활용할 수 있습니다.
SBOM 컨설팅 비용을 좌우하는 범위와 운영 부담
컨설팅 비용은 저장소 개수보다 분석 난도와 요구되는 증거 수준에 더 크게 좌우될 수 있습니다. 비슷한 구조의 저장소가 여러 개 있는 경우와 서로 다른 언어, 운영체제, 장비 구성으로 된 제품을 다루는 경우는 업무량이 다릅니다. 소스코드 접근이 제한되거나 오래된 빌드 환경을 재현해야 하면 조사와 검증 시간이 늘어납니다. 금액 비교 전에 어떤 제품과 어떤 출시 과정을 포함하는지 맞추는 것이 우선입니다.
비용 항목은 초기 진단, 시범 구현, 자동화 연동, 정책 수립, 교육, 운영 지원으로 나누면 이해하기 쉽습니다. 도구 사용료와 컨설팅 작업비는 별도로 볼 필요가 있습니다. 내부 담당자의 투입 시간, 분석 서버 운영, 결과 보관, 취약점 검토도 전체 비용에 포함됩니다. 공개 도구를 사용한다고 해서 이 운영 비용까지 사라지는 것은 아닙니다.
업무 범위서에는 산출물 수량보다 검수 기준을 명확히 적어야 합니다. 예를 들어 대표 출시물과 구성 목록이 연결되는지, 필수 정보가 누락됐을 때 감지되는지, 담당자가 문서대로 재생성할 수 있는지를 기준으로 삼을 수 있습니다. 규제 해석 의견, 적합성 평가 지원, 제삼자 시험, 법률 자문이 포함되는지도 구분해야 합니다. 서로 다른 범위의 금액을 그대로 비교하면 더 저렴한 제안이 실제로는 필요한 업무를 제외했을 가능성을 놓칩니다.
운영 부담을 줄이려면 수동 검토가 반복되는 원인을 먼저 찾아야 합니다. 내부 패키지의 버전 규칙이 불명확하거나 공급업체 자료가 제품과 연결되지 않으면 매번 사람이 확인해야 합니다. 이런 원인을 정리하는 작업은 초기 비용을 늘릴 수 있지만 반복 업무를 줄일 여지가 있습니다. 비용 판단은 도입 시점의 금액뿐 아니라 출시마다 필요한 검토와 유지보수까지 포함해 이루어져야 합니다.
SBOM 규정 준수에서 자주 생기는 오해
가장 흔한 오해는 구성 목록이 곧 보안 인증이라는 생각입니다. 목록에 구성요소가 기록됐다는 사실은 그 구성요소가 안전하거나 취약점이 없다는 뜻이 아닙니다. 반대로 취약점 식별자가 발견됐다고 해서 제품이 반드시 악용 가능한 상태라는 뜻도 아닙니다. 목록은 판단의 출발점이고, 실제 영향 분석과 대응 기록이 그 다음 단계입니다.
의존성이 없는 자체 개발 프로그램에는 목록이 필요 없다는 주장도 주의해야 합니다. 직접 작성한 코드만 있다고 생각해도 실행 환경, 운영체제 패키지, 포함된 라이브러리, 장비 구성요소가 존재할 수 있습니다. 다만 외부에서 운영하는 모든 시스템을 무조건 제품 구성요소로 넣는 것도 적절하지 않습니다. 제품 경계와 제공 방식에 따라 포함 범위를 설명할 수 있어야 합니다.
한 번 만든 목록을 계속 사용해도 된다는 생각은 제품 변경을 놓치게 만듭니다. 동일한 제품 버전 표기를 유지하더라도 재빌드, 패키지 교체, 기반 이미지 변경으로 구성은 달라질 수 있습니다. 구성 목록을 출시 산출물에 연결해야 하는 이유가 여기에 있습니다. 취약점 정보가 바뀌었지만 제품 구성은 바뀌지 않은 경우에는 목록 자체와 취약점 평가 이력을 구분해 관리하는 편이 정확합니다.
외부에 목록을 전달하면 영업비밀이 모두 공개된다는 우려도 범위를 나눠 판단해야 합니다. 내부 저장 경로, 계정 정보, 불필요한 개발 환경 정보는 제거할 수 있지만, 핵심 구성요소 정보를 임의로 삭제하면 납품 요구를 충족하지 못할 수 있습니다. 수신자 권한과 전달 목적에 맞는 공개 정책이 필요합니다. 보안팀, 개발팀, 법무팀이 같은 제출 기준을 공유하면 과도한 공개와 불완전한 제공을 함께 줄일 수 있습니다.
SBOM 도입을 위한 실무 점검과 다음 단계
첫 번째 실행 과제는 대표 제품 하나에 대해 요구사항과 현재 증거 사이의 차이를 정리하는 것입니다. 제품 책임자, 배포 방식, 대상 시장, 고객 제출 조건, 사용하는 구성요소 형식을 기록합니다. 이어 실제 출시 파일과 현재 생성 가능한 구성 목록을 대조합니다. 이 과정에서 발견한 누락, 버전 불일치, 공급업체 자료 부족을 개선 과제로 분류하면 도구 선정 전에 해야 할 일이 선명해집니다.
시범 운영의 완료 기준은 파일 생성 성공보다 넓게 잡아야 합니다. 담당자가 생성 과정을 재현할 수 있고, 출시물과 목록의 연결을 설명할 수 있으며, 취약점 발견 시 처리 담당자를 정할 수 있어야 합니다. 외부 제출본과 내부 보관본의 차이도 문서화합니다. 이런 기준을 충족한 뒤 다른 제품군으로 확대하면 제품별 예외를 공통 정책 안에서 관리하기 쉬워집니다.
규정 준수 체계의 품질은 문서의 양보다 질문에 답하는 능력에서 드러납니다. 특정 구성요소가 어느 출시물에 포함됐는지, 그 제품이 어떤 영향을 받는지, 누가 어떤 근거로 대응을 결정했는지 설명할 수 있어야 합니다. 도구는 이 답을 만드는 속도를 높이고, 컨설팅은 답이 일관되게 나오도록 절차와 책임을 정리합니다. 제품 요구사항, 구성 목록, 취약점 판단, 출시 기록이 연결되는 체계를 구축하는 것이 지속 가능한 운영의 기준입니다.
