SBOM은 성분 목록이지, 위생 검사가 아닙니다.

주요 내용

• CISA의 2026년 최소 구성 요소는 2026년 7월 29일, 2021년 미국 국가통신정보청(NTIA)의 기준치를 대체하였으며, 17개의 데이터 필드를 규정했습니다.
• 행정관리예산국(OMB)은 2026년 1월 연방 보안 소프트웨어 인증 관련 지침서를 철회했으며, 이에 따라 SBOM 요청 여부는 각 기관의 재량에 맡기게 되었다.
• CRA SBOM 요건은 2027년 12월 11일부터 시행되며, 최상위 종속성을 최소 적용 범위로 규정하고 있습니다.
• 구성 요소가 SBOM에 정확하게 기재되어 있더라도 악성일 수 있고, 변조되었을 수 있으며, 수정 없이 방치될 수도 있습니다.

SBOM 관련 요구 사항이 변화하고 있습니다. 미국 행정관리예산국(OMB)은 2026년 1월에 연방 인증 메모를 철회했으며, FDA는 2월에 의료기기 사이버보안 지침을 재발행했습니다. 또한 CISA는 7월에 SBOM 데이터에 대한 2021년 기준치를 대체했으며, EU의 사이버 복원력 법(CRA)은 2027년 12월부터 제조업체에 SBOM 제출을 의무화하기 시작합니다. SBOM이 요구되는 곳이라면 어디에서든, 귀사가 제출해야 하는 것은 소프트웨어에 포함된 구성 요소 목록입니다.

그 목록은 유용합니다. 식품 포장에 기재된 성분 표에는 해당 제품에 땅콩이 포함되어 있다는 사실이 명시되어 있는데, 알레르기가 있는 사람에게는 중요한 정보입니다. 공장이 위생적인지, 공급업체가 주장하는 대로 신뢰할 수 있는 곳인지 확인하려면 별도의 검사가 필요하며, 이는 또 다른 업무입니다.

SBOM도 같은 방식으로 작동합니다. SBOM을 작성한다고 해서 보안 위험이 사라지는 것은 아닙니다. 목록이 생성된 후에도 취약점이 있거나, 변조되었거나, 더 이상 유지보수되지 않는 구성 요소는 소프트웨어 내에 그대로 남아 있기 때문입니다. 또한 이 네 가지 규칙 중 어느 것도 단순히 목록 작성에서 그치지 않습니다. 연방 정부의 요구사항은 SBOM을 더 광범위한 보안 개발 관행의 일환으로 규정하고 있습니다. CISA의 공식 문서에 따르면 SBOM은 여전히 분석이 필요한 데이터이며, FDA와 CRA는 한 걸음 더 나아가 SBOM에 나열된 구성 요소를 평가하고 패치를 적용해야 할 의무를 부과하고 있습니다.

2026년 10월 기준 SBOM 요구사항의 내용

현재 가장 중요한 규칙은 네 가지입니다. 표에는 요약된 내용이 나와 있으며, 이어지는 각 절에서 자세한 내용을 다룹니다.

SBOM 연방 규정 요건의 잔여 내용

2021년 5월에 서명된 행정명령 14028호는 연방 차원의 SBOM 의무화 조치의 시작을 알렸습니다. 제4조(e)(vii)항은 구매자에게 각 제품에 대한 SBOM을 직접 제공하거나 공개 웹사이트를 통해 제공하도록 하는 NIST 지침을 요구했습니다. 이 명령은 아직 철회되지는 않았으나, 이를 뒷받침하던 대부분의 제도적 장치는 철회되었습니다. 2025년 6월의 행정명령(EO 14306)은 2025년 1월에 서명된 행정명령 14144호에 추가되었던 증명 조항들을 삭제했으며, 여기에는 CISA가 공급업체의 증명을 중앙에서 검증하는 내용도 포함되었습니다. 그 후 2026년 1월 23일, OMB 메모 M-26-05는 ‘보안 소프트웨어 개발 증명 양식’의 근거가 되었던 메모인 M-22-18과 M-23-16을 철회했다.

기관들은 여전히 해당 양식을 사용하고 계약 조건에 SBOM 제공을 포함시킬 수 있지만, 정부 차원의 정책상 더 이상 이 두 가지를 의무화하지는 않습니다. 연방 정부 구매자에게 소프트웨어를 판매하는 경우, 현재 SBOM 제출 의무가 있는지 여부는 해당 기관의 자체 정책과 체결 중인 계약에 따라 달라집니다.

2026년 SBOM 데이터에 대한 CISA 기준

2026년 7월 29일, CISA, NSA, FBI 및 15개 국제 파트너 기관은 ‘2026년 소프트웨어 부품 명세서(SBOM) 최소 구성 요소’를 발표했습니다. 이 문서는 행정명령 14028호에 따라 미국 국립통신정보청(NTIA)이 발표한 2021년 문서를 대체하며, 필수 데이터 필드 수를 7개에서 17개로 늘렸습니다. 새롭게 추가된 항목에는 SBOM 작성자 서명, 각 구성 요소에 대한 해시 값 및 해시 알고리즘, 구성 요소 라이선스, 생성 도구의 이름과 버전, 그리고 빌드 전후 등 SBOM이 생성된 라이프사이클 단계를 나타내는 생성 컨텍스트 등이 포함됩니다.

실무상 중요한 변경 사항이 두 가지 더 있습니다. 이제 커버리지에는 최소 깊이 제한이 없는 전이적 종속성이 포함되어야 하는 반면, 2021년 버전에서는 최상위 종속성만 요구했습니다. 또한 각 구성 요소에는 Package-URL과 같은 기계가 처리할 수 있는 식별자가 적어도 하나씩 있어야 합니다.

이 문서에 따르면, 해당 요소들은 새로운 요구 사항을 추가하는 것이 아니라, 조직이 SBOM을 생성하고 요청하는 방식을 개선하는 데 그친다고 합니다. 또한 SBOM의 정확성, 적용 범위 및 완전성에 대한 확인은 최소 필수 요소에서 제외되는데, 이는 서명이 제공하는 것과는 다른 품질 측정 기준이 필요하기 때문입니다.

참고: CISA의 자체적인 결론에 따르면, SBOM 자체는 소프트웨어 구성 요소에 관한 데이터일 뿐이며, 분석을 통해야만 그 데이터가 통찰력으로 전환된다고 합니다.

제524B조에 따른 FDA SBOM 요건

미국 의회는 2022년 12월 ‘식품·의약품 종합 개혁법(Food and Drug Omnibus Reform Act)’을 통해 FD&C법에 제524B조를 추가했습니다. 이 조항은 2023년 3월 29일 또는 그 이후에 제출된 “사이버 기기”에 대한 시판 전 신청에 적용되며, 여기서 ‘사이버 기기’란 소프트웨어를 포함하고, 인터넷에 연결될 수 있으며, 사이버 위협에 취약할 수 있는 특성을 지닌 기기를 의미합니다. FDA는 이 조항을 폭넓게 해석하여 펌웨어를 소프트웨어로 간주하고, USB 및 직렬 포트와 같은 연결 단자를 연결 수단으로 포함하고 있습니다. 적용 대상 제출 유형은 510(k), PMA, PDP, De Novo 및 HDE입니다. 제524B(b)(3)항에 따라 제조업체는 상용, 오픈소스 및 기성(off-the-shelf) 구성 요소를 포함하는 SBOM을 제출해야 합니다.

2026년 2월 3일에 재발행된 FDA의 지침은 기본 항목 이상의 정보를 요구하고 있습니다. 이 지침은 각 구성 요소의 항목에 지원 상태(예: 활발히 유지 관리 중, 더 이상 유지 관리되지 않음, 폐기됨 등)와 지원 종료일을 포함할 것을 권장하며, 제조업체가 지원이 종료될 경우 타사 구성 요소를 어떻게 업데이트하거나 교체할지 계획을 수립할 것을 권고합니다. 이 지침은 구속력이 없으며, CISA의 2026년 개정안보다 앞서 발표된 것으로, 여전히 NTIA의 2021년 기준 속성 관련 작업을 인용하고 있습니다. 법령 자체에는 패치 적용 의무가 추가되었습니다. 제524B(b)(2)조는 사이버 기기 제조업체가 알려진 용납할 수 없는 취약점에 대해서는 정기적인 주기로, 통제 불가능한 위험을 초래할 수 있는 중대한 취약점에 대해서는 정기 주기 외에 업데이트 및 패치를 제공하도록 요구하고 있습니다.

CRA SBOM 요건과 그로 인해 남겨진 불확실한 부분

‘사이버 복원력법’ 부속서 I, 제2부, 제1항은 제조업체가 취약점과 구성 요소를 식별하고 문서화할 것을 요구하며, 여기에는 최소한 최상위 종속성을 포함하는, 일반적으로 사용되는 기계 판독 가능 형식의 SBOM을 작성하는 것도 포함됩니다. 이 규정은 2024년 12월 10일에 발효되었으며, SBOM 제출 의무를 포함한 주요 의무 사항은 2027년 12월 11일부터 적용됩니다. SBOM은 기술 문서에 포함되며, 시장 감시 당국은 규정 준수 여부를 확인하기 위해 필요한 경우 사유를 제시하고 이를 요청할 수 있습니다. 사용자와의 공유는 선택 사항입니다.

동 부속서 제2부에서는 또한 제조업체가 보안 업데이트 제공 등을 통해 취약점을 지체 없이 해결하고 시정할 것을 요구하고 있습니다. 제13조는 오픈소스를 포함한 제3자 구성 요소를 통합할 때 적정한 주의 의무를 부과하며, 구성 요소에서 취약점을 발견한 제조업체는 이를 유지 관리자에게 보고한 후 자사 제품에서 이를 수정해야 합니다. 따라서 SBOM 의무에는 SBOM 자체만으로는 충족할 수 없는 추가적인 의무들이 수반됩니다. 목록은 제품에 무엇이 포함되어 있는지 보여줄 뿐이지만, 해당 구성 요소를 검토하고 수정하는 작업은 여전히 제조사가 수행해야 할 일입니다. 또한 최상위 수준에 그치는 방식은 실제로 이러한 의무를 이행하는 데 방해가 됩니다. 보안 권고가 발표될 때, 영향을 받는 구성 요소는 대개 전이적 종속성인 경우가 많은데, 최상위 종속성까지만 포함하는 SBOM으로는 해당 구성 요소가 제품에 포함되어 있는지 여부를 알 수 없습니다. 최소 요건 이상의 수준으로 구축된 SBOM을 사용하면 수정 의무를 이행하기가 더 수월합니다.

NIST의 역할

NIST SBOM 요구 사항을 찾고 계신다면, 가장 먼저 알아야 할 점은 NIST가 자체적으로 SBOM 데이터 요소를 공개하지 않는다는 것입니다. NTIA가 2021년에 기준을 마련했고, CISA가 현재의 기준을 정했습니다. NIST의 역할은 프로세스 지침을 제공하는 것입니다. 보안 소프트웨어 개발 프레임워크 (SSDF, SP 800-218, 버전 1.1)는 SBOM을 제작자가 릴리스의 모든 구성 요소에 대해 보관해야 하는 출처 데이터의 예시로 나열하고 있습니다. SSDF는 연방 정부 공급업체들에게 중요한 의미를 지녔는데, 이는 OMB가 1월에 폐지한 확인서 양식에서 공급업체들이 SSDF 준수를 확인하도록 요구했기 때문입니다. 해당 양식이 폐지된 이후에도 기관은 여전히 확인서를 요청할 수 있지만, 정부 차원의 정책상 더 이상 이를 의무화하지는 않습니다.

계약서에 NIST 기준을 따르라고 명시되어 있다면, 개발 관행을 SSDF에 맞춰 조정하고, CISA 2026 요소를 충족하는 SBOM을 생성한 뒤, 릴리스할 때마다 이를 다시 생성해야 합니다. 아직 2026 요소를 의무화하는 규제 기관은 없지만, 이는 공개된 기준 중 가장 엄격한 것이며, 이 기준에 따라 작성된 SBOM은 FDA 및 CRA의 최소 요건도 충족합니다. 구매자가 어떤 요소를 중요하게 여기는지는 계약서 문구에 따라 결정되므로, 먼저 계약서 내용을 꼼꼼히 확인하시기 바랍니다.

이 규칙은 누가 SBOM을 작성해야 하는지, 그리고 SBOM에 어떤 내용이 포함되어야 하는지를 규정하고 있습니다. FDA와 CRA는 후속 조치, 패치 적용 및 실사 의무에 대해서도 명시하고 있지만, 이를 어떻게 수행해야 하는지에 대해서는 거의 언급하지 않습니다. 바로 이 부분에서 SBOM만으로는 부족해집니다.

규정을 준수하는 SBOM만으로는 할 수 없는 것

위의 모든 SBOM 요구 사항을 충족하면, 소프트웨어에 포함된 내용을 기록한 문서를 확보하게 됩니다. 이 문서에는 이름과 버전뿐만 아니라 각 구성 요소의 해시 값 및 작성자 서명과 같은 정보도 기록될 수 있습니다. 다른 문서들도 함께 포함될 수 있습니다. VEX(Vulnerability Exploitability eXchange) 진술서는 나열된 취약점이 제품에 영향을 미치는지 여부를 명시하며, 출처 증명서는 아티팩트를 이를 생성한 빌드와 연결해 줍니다. 이러한 모든 정보를 확보했더라도, 그 외에도 세 가지 검증이 별도로 수행됩니다.

이 유물은 그 출처와 일치하는가?

2026년 기준안에서는 각 구성 요소의 실행 가능 아티팩트에 대한 해시 값과 SBOM 작성자의 서명을 요구합니다. 해시 값은 설명된 아티팩트를 식별하며, 서명은 명시된 작성자가 SBOM에 서명했고 이후 수정되지 않았음을 보장합니다. 두 가지 모두 아티팩트를 프로젝트가 가리키는 소스 저장소와 비교하지는 않습니다. 해킹당한 유지보수자 계정이 조작된 릴리스를 게시하거나, 레지스트리 패키지에 프로젝트 저장소에 없는 코드가 포함된 경우, SBOM은 이를 다른 항목과 마찬가지로 다운로드한 파일의 해시 값과 일치하는 해시 값과 함께 기록합니다.

아티팩트를 소스 코드와 대조하여 확인하는 방법에는 여러 가지가 있습니다. 예를 들어, 출처 증명(provenance attestation)은 아티팩트를 이를 생성한 빌드와 연결해 줍니다. 소스 코드로부터 재빌드하면 레지스트리의 아티팩트가 직접 빌드한 아티팩트로 대체되므로, 배포하는 내용에는 리포지토리에 있는 내용만 포함됩니다. 이 두 방법 모두 동일한 한계가 있습니다. 이 방법들은 아티팩트가 소스 코드와 일치하는지 여부를 확인할 뿐, 소스 코드가 깨끗한지는 확인하지 않습니다. 해킹당한 계정이나 악의적인 커밋도 이 두 가지 검사 모두를 통과할 수 있습니다.

애초에 그 부품을 승인했어야 했을까?

타이포스쿼트, 네임스페이스 사칭, 악의적인 설치 동작을 보이는 패키지 등은 다른 패키지와 마찬가지로 모두 목록에 포함됩니다. SBOM의 역할은 무엇이 해결되었는지를 기록하는 것이며, 실제로 그렇게 했습니다. 패키지를 해결할지 여부는 이미 이전에 결정된 사항이며, CRA는 이러한 결정을 타사 구성 요소를 통합할 때 수행해야 할 적정 주의 의무의 일환으로 규정하고 있습니다.

일부 생태계에서는 설치 또는 빌드 과정에서 패키지 코드를 실행합니다. npm 라이프사이클 스크립트는 설치 중에 실행되고, Rust의 build.rs 스크립트는 빌드 중에 실행되며, Python의 .pth 시작 후크는 인터프리터가 시작될 때마다 코드를 실행할 수 있습니다. 많은 파이프라인이 빌드 시점이나 그 이후에 SBOM을 생성하므로, 패키지는 실제로 실행된 후에야 관련 정보가 기록됩니다.

해결책이 있나요? 그리고 누가 그걸 만들 건가요?

SBOM과 자문 데이터를 통해 특정 구성 요소에 알려진 취약점이 있다는 사실을 알 수 있습니다. VEX 문서는 해당 취약점이 귀사의 제품에 영향을 미치는지 여부를 나타낼 수 있으며, FDA 지침에서 기록을 권장하는 지원 상태는 상류 공급업체가 여전히 존재하여 해당 취약점을 수정할 수 있는지 여부를 나타냅니다. 이 모든 정보는 문제를 설명해 줄 뿐, 패치를 제공해 주지는 않습니다.

업스트림에서 더 이상 유지보수되지 않는 버전 계열에 알려진 취약점이 있는 트리 내의 컴포넌트를 상상해 보세요. 때로는 프로젝트가 최신 메이저 릴리스에서 여전히 활성화되어 있기도 하고, 때로는 완전히 폐기된 경우도 있습니다. 어느 쪽이든, 사용 중인 버전을 업그레이드하거나, 교체하거나, 패치할 수 있습니다. 수정된 릴리스가 존재하지 않으면 업그레이드가 불가능하며, 릴리스가 있더라도 항상 안전한 것은 아닙니다. 교체한다는 것은 해당 컴포넌트를 사용한 모든 부분을 재작성해야 함을 의미하는데, 이는 여러분이 직접 선택하지 않은 전이적 의존성으로 도입된 경우 더욱 어렵습니다. 그러면 남은 방법은 현재 사용 중인 버전에 패치를 적용하는 것뿐입니다. 누군가는 수정 코드를 작성하거나, 해당 프로젝트가 여전히 활발히 진행 중이라면 최신 메이저 버전에서 백포트한 뒤, 컴포넌트의 동작이 여전히 호환되는지 확인해야 합니다. 이는 매우 세밀한 작업이며, 업스트림에서는 더 이상 유지 관리하지 않는 컴포넌트에 대해서는 수행하지 않을 작업입니다.

세 장의 수표를 나란히 놓으면 다음과 같습니다.

나머지 작업은 어떻게 진행되는지

세 가지 점검 과정은 각각 누군가가 반드시 수행해야 하는 작업입니다. 스크리닝은 패키지가 개발자 컴퓨터나 빌드 에이전트에 도달하기 전에 허용 여부를 결정합니다. 소스 코드로부터 재빌드하면 프로젝트 저장소의 코드와 일치하는 아티팩트를 얻을 수 있습니다. 지속적인 패치 적용은 업스트림의 개발 속도가 느려지거나 중단된 후에도 구성 요소가 수정된 상태를 유지하도록 합니다.

SSDF에 따르면, NIST의 프레임워크는 타사 구성 요소의 예시로, 사용 전 검토, 각 구성 요소가 여전히 유지 관리되고 있는지 확인, 유지 관리되지 않는 구성 요소에 대한 대비 계획 수립, 바이너리의 출처를 확인할 수 없는 경우 소스 코드로부터 빌드하는 것 등을 제시하고 있습니다.

보안 권고 사항이 발표되었을 때 “우리도 영향을 받는지”에 대한 답을 얻으려면 여전히 SBOM이 필요합니다. SBOM은 전이적 종속성을 포함하고 실제로 출하된 내용을 정확히 반영할 때만 이 질문에 제대로 답할 수 있는데, 이것이 바로 CRA의 최저 기준이 아닌 CISA의 2026년 기준에 맞춰 SBOM을 구축해야 하는 이유 중 하나입니다.

시중에 나와 있는 공급망 보안 도구를 평가할 때는 각 도구가 공급망의 어느 단계에서 작동하는지 확인해야 합니다. 즉, 패키지가 사용자에게 전달되기 전인지, 설치 중인지, 아니면 아티팩트가 이미 배치된 후인지 살펴봐야 합니다. 이 분야의 많은 도구는 이미 존재하는 문제를 보고할 뿐이며, 설치, 빌드 또는 인터프리터 시작 과정에서 발생하는 공격은 보고서가 도착할 때쯤이면 이미 실행이 끝난 후입니다.

TuxCare의 SecureChain은 패키지가 사용자에게 전달되기 전에 작동합니다. 이 시스템은 패키지에 숨겨진 악성코드나 의심스러운 코드가 있는지 스캔하여, 검사에서 불합격된 패키지는 차단합니다. 그런 다음 격리된 빌드 환경에서 소스 코드를 기반으로 패키지를 재빌드합니다. 활성 구성 요소의 경우, CVE가 발견되면 SLA에 따라 취약점을 패치하며, 업스트림에서 패키지 유지 관리를 중단하더라도 Endless Lifecycle Support(ELS) 를 통해 지속적으로 수정 사항을 제공합니다. 지원 범위는 JavaScript, Python, Java, Go, Rust 및 PHP 패키지를 아우릅니다.

SBOM이 생성된 후 해야 할 일

2021년 이후 SBOM 요구사항은 여러 차례 변경되었으므로, 이 문서를 각 릴리스마다 재생성해야 하는 것으로 간주하고, 그보다 우선하여 위험을 줄이는 통제 조치를 마련하십시오. 아직 SBOM이 없다면, 전이적 종속성을 포함하여 CISA 2026 요소에 따라 작성하십시오. 이미 SBOM이 있다면, 최상위 종속성을 넘어 실제로 출시된 내용을 반영하고 있는지 확인하십시오. 그렇지 않은 경우, 다른 작업을 진행하기 전에 해결된 종속성 트리나 빌드된 아티팩트를 기반으로 깊이 제한 없이 새로운 문서를 생성하십시오. 그런 다음 이를 보안 권고 데이터와 대조하고, 취약한 구성 요소를 업스트림 수정 패치 유무에 따라 분류한 뒤, 수정 패치가 없는 구성 요소에 대해 어떻게 처리할지 결정하십시오. 해당 구성 요소를 교체하거나, 사용 중인 버전에 패치를 적용하거나, 명시적인 위험 수용을 기록할 수 있습니다.

SBOM에서 아무도 유지 관리하지 않는 패키지가 계속 표시된다면, SecureChain for Open Source가 위험한 패키지가 귀사의 환경에 도달하기 전에 이를 차단하고, 업스트림 지원이 종료된 후에도 지속적으로 패치를 적용하는 방식을 확인해 보십시오.

자주 묻는 질문

SBOM 요구사항이란 무엇인가요?

SBOM 요건은 소프트웨어 제조사가 제품에 포함된 구성 요소 목록인 소프트웨어 부품 명세서(SBOM)를 제공하도록 의무화하는 규정입니다. 주요 규정으로는 2023년부터 시행 중인 의료기기 관련 FDA 제524B조, 2027년 12월 11일부터 시행될 EU 사이버 복원력법(Cyber Resilience Act), 그리고 현재 미국 정부 기관들이 계약별로 설정하고 있는 연방 조달 조건 등이 있습니다. CISA의 2026년 최소 구성 요소(Minimum Elements)는 기본 데이터 필드를 정의하고 있습니다.

SBOM에 대한 연방 규정이 여전히 적용되고 있나요?

구매자에게 SBOM을 제공하도록 지침을 제시한 행정명령 제14028호는 여전히 유효합니다. 행정관리예산국(OMB)은 2026년 1월 23일, 보안 소프트웨어 증명서 제출을 의무화했던 메모(M-22-18 및 M-23-16)를 철회했습니다. 미국 정부 기관들은 여전히 계약 조건에 SBOM 제출을 요구할 수 있으므로, SBOM 제출 의무 여부는 구매자에 따라 달라집니다.

의료 기기에 대한 FDA의 SBOM 요건은 무엇인가요?

FD&C법 제524B조는 사이버 기기(즉, 인터넷에 연결될 수 있고 사이버 위협에 취약할 수 있는 소프트웨어가 탑재된 기기)에 대한 시판 전 제출 자료에 상용 소프트웨어, 오픈소스 소프트웨어 및 기성 소프트웨어를 포괄하는 SBOM을 포함할 것을 요구합니다. 또한 FDA의 2026년 2월 지침에서는 각 구성 요소의 지원 상태와 지원 종료일을 기재할 것을 권고하고 있습니다.

CRA SBOM 요건은 무엇인가요?

EU 사이버 복원력법(CRA)은 디지털 요소가 포함된 제품의 제조업체가 최소한 최상위 종속성을 포함하는, 일반적으로 사용되는 기계 판독 가능 형식의 SBOM을 작성하도록 요구합니다. 이 의무는 2027년 12월 11일부터 적용되며, 시장 감시 당국은 규정 준수 여부를 확인하기 위해 정당한 사유를 제시하고 SBOM 제출을 요청할 수 있습니다. 또한 CRA는 제조업체가 자사 제품 및 구성 요소의 취약점을 지체 없이 수정할 것을 요구합니다.

NIST SBOM 요구 사항을 어떻게 준수하고 계십니까?

NIST는 SBOM 데이터 요소를 정하지 않습니다. 이러한 요소들은 미국 상무부 산하 기관인 국립통신정보청(NTIA)의 2021년 기준안을 대체한 CISA의 ‘2026년 최소 요소’에서 비롯됩니다. NIST의 역할은 ‘보안 소프트웨어 개발 프레임워크(SP 800-218)’에 명시된 프로세스 지침을 제공하는 것이므로, 일반적으로 규정 준수를 위해서는 개발 관행을 해당 지침에 부합하도록 조정하고, CISA 요소 요건을 충족하는 SBOM을 생성하며, 릴리스할 때마다 이를 업데이트해야 합니다.

SBOM이 소프트웨어의 보안을 강화해 주는가?

그 자체로는 아닙니다. SBOM은 소프트웨어에 어떤 구성 요소가 포함되어 있는지 기록하여, 취약점이 공개되었을 때 대응하는 데 도움을 줍니다. SBOM은 패키지가 출처와 일치하는지 확인하거나, 해당 패키지가 설치되었어야 했는지 판단하거나, 패치를 제공하는 기능은 없습니다.

취약점이 있지만 업스트림에서 수정 패치가 제공되지 않는 구성 요소에 대해서는 어떻게 대처해야 할까요?

해당 구성 요소를 교체하거나 사용 중인 버전에 패치를 적용할 수 있습니다. 교체는 재작성을 의미할 수 있으며, 패치 적용은 업스트림 릴리스에 해당 수정 사항이 없기 때문에 누군가가 수정 코드를 작성하고 테스트해야 함을 의미합니다. 지원 기간이 만료된 오픈소스 패키지에 대해 확장 지원을 제공하는 벤더가 해당 패치를 제공할 수 있습니다. SBOM에 해당 구성 요소를 기재하면, 이를 변경하지 않고도 취약점 노출 사실을 문서화할 수 있습니다.

요약

기사 이름

SBOM 요구 사항 및 부품 명세서(BOM)가 할 수 없는 것

설명

SBOM 요구 사항은 미국 각 기관, FDA 및 EU CRA에 따라 다릅니다. SBOM이 할 수 없는 일과 SBOM 외부에서 이루어지는 세 가지 점검 사항에 대해 알아보세요.

작성자

아르템 카라세프

게시자 이름

TuxCare

게시자 로고