What is a Software Bill of Materials (SBOM)?
NTIA(National Telecommunications and Information Administration)에 따르면 소프트웨어 자재 명세서(SBOM)는 소프트웨어 개발에 사용되는 구성 요소와 해당 소프트웨어 공급망 관계에 대한 공식 기록입니다. SBOM은 오픈 소스 소프트웨어(OSS)와 독점 소프트웨어(proprietary software)를 모두 다루며 소프트웨어 내의 잠재적인 취약점과 요소에 대한 투명성을 제공합니다. SBOM은 취약성 관리 및 제품 무결성을 위해 사용될 수 있습니다.
SBOM은 바이든 행정부 행정 명령에 포함되었으며 연방 정부에 소프트웨어를 판매하는 공급업체가 유지 관리해야 합니다.
SBOM은 다음과 같은 귀중한 자산을 포함합니다.
규제 준수
이전 소프트웨어 패키지와 OSS 업데이트 간의 호환성
소프트웨어 공급망 사이버 공격으로부터 고객 보호
소프트웨어 및 라이선스가 포함된 합병 시 보안 보호
Difference between SBOM and CBOM
2018 사이버 보안 자재 명세서(CBOM, Cybersecurity Bill of Materials)는 하나의 행정 명령 내에서 소프트웨어와 하드웨어를 모두 다루고 있습니다. SBOM은 코드 내의 소프트웨어 구성 요소와 버전, 패치, 라이선스, 업데이트 및 변경 내역만 문서화합니다.
Why are SBOMs important for cybersecurity?
소프트웨어 공급망을 겨냥한 사이버 공격이 증가하고 있습니다. 이러한 공격의 절반 이상이 확립된 APT(Advanced Persistal Threat) 사이버 범죄 그룹에서 발생합니다. 그들의 목표는 시스템에 대한 사용자와 공급업체의 신뢰를 활용하는 것입니다.
공급망을 취약하게 만드는 것은 사이버 사고를 둘러싼 투명성이 부족하기 때문입니다. 어떤 경우에는 개발자가 가능한 취약점을 인식하지 못하고 결과적으로 사용자도 취약할 수 있습니다. 오픈 소스 라이브러리는 다른 소프트웨어 구성 요소에 종속됩니다. Log4Shell 취약점과 같은 사례는 직접적인 소프트웨어 종속성(software dependency)이 아니라 다른 구성 요소에 의존하는 전이적 종속성이므로 많은 개발자가 확인하지 않는 구성 요소(이 경우 로깅 라이브러리)의 예입니다.
개발 팀은 이미 애플리케이션 보안(application security)의 필요성을 인식하고 있지만 SBOM은 소프트웨어 공급망과 잠재적인 취약점에 대한 추가적인 가시성을 제공하고 있습니다. 사용자가 소프트웨어 제품 내에서 취약점이 숨겨져 있을 수 있는 위치를 알고 소프트웨어의 구성 요소(특히 오픈 소스인 경우)를 알면 잠재적인 공격을 탐지하고 해결하기 위한 보안 도구를 배포할 수 있는 능력이 더 높아집니다.
사이버 공격이 발생하는 경우 SBOM을 사용하여 취약한 구성 요소가 있는 소프트웨어와 관련된 위험 유형을 식별할 수 있습니다. 이를 통해 사용자는 개발자와 협력하여 패치나 기타 완화 솔루션을 마련할 수 있습니다.
SBOMs Executive Order 14028
Log4Shell 이전에는 솔라윈즈 공급망 공격(SolarWinds supply chain attack) 및 Apache Struts와 관련된 Equifax 사고와 같은 기타 사이버 사고를 통해 대기업 및 기업뿐만 아니라 취약한 정부 기관이 중요 인프라 전반에 걸쳐 얼마나 취약한지 보여주었습니다. 또한 모든 조직이 소프트웨어 공급망에 얼마나 의존하고 있는지, 하나의 취약점이 악용되면 광범위한 연쇄 효과를 가져올 수 있음을 보여주었습니다.
미 행정명령 14028은 국립표준기술연구소(NIST), 국가안보국(NSA), 관리예산국(OMB), 사이버보안 및 인프라 보안국(CISA), 국가정보국장( DNI)는 소프트웨어 공급망의 보안을 개선하기 위한 표준 및 모범 사례를 개발합니다. 지침에는 다음이 포함됩니다.
When should you use a Software Bill of Materials?
소프트웨어 구성 요소의 새 릴리스마다 새 SBOM을 생성해야 합니다. 마찬가지로 구성 요소가 변경될 때마다 SBOM을 업데이트하여 변경 사항에 맞게 업데이트해야 합니다.
SBOM에 대한 NTIA 기준에는 다음 정보가 필요합니다.
저자 이름(author name)
공급 업체 이름(supplier name)
구성 요소 이름(component name)
구성요소 해시(component hash)
버전 문자열(version string)
식별자(identifier)
관계(relationship)
기본 요구 사항을 충족하기 위해 SBOM 표준은 여러 도구에서 사용할 수 있는 공통 형식을 제공하도록 개발되었습니다. 이러한 표준은 다음과 같습니다.
SPDX: 소프트웨어 제품 데이터 교환은 소프트웨어 패키지의 구성 요소, 라이센스 및 보안 정보를 전달하기 위한 개방형 표준입니다. SPDX는 각각 자체 SBO M을 사용하여 여러 서비스를 표준화합니다.
SWID: 소프트웨어 식별 태그는 수명주기를 정의하는 표준입니다. 태그는 소프트웨어 설치 프로세스의 일부로 엔드포인트에 추가됩니다. 네 가지 태그가 있습니다. 설치 전 단계에서 사용되는 코퍼스 태그; 제품 이름을 제공하고 글로벌 고유 식별자로 간주되는 기본 태그 소프트웨어에 적용된 패치를 설명하는 패치 태그; 추가 정보에 대한 보충 태그.
OWASP Cyclone DX: 공급망 구성 요소 분석 및 애플리케이션 보안에 사용되는 경량 SBOM 표준입니다.
VEX: Vulnerability Exploitability Exchange는 제품에 대한 추가 정보, 특히 구성 요소에서 발견된 취약점을 식별하고 교정을 위한 권장 조치를 제공합니다.
SBOMs and the integrity of the software
SBOM은 소프트웨어 공급망의 무결성을 확인하고 수집된 정보를 기반으로 위험 평가를 허용하도록 구성되어 있습니다. 높은 수준의 평가로서 SBOM은 공급망 내의 소프트웨어 구성 요소 재고를 위한 것입니다. 그러나 표준이 적용됨에 따라 SBOM은 OSS의 규정 준수 표준을 충족하게 됩니다. 예를 들어, SPDX 표준은 해당 구성 요소의 라이센스를 식별하고 라이센스(licenses) 준수를 보장하는 데 사용됩니다.
SLSA(Supply Chain Levels for Software Artifacts)는 공급망 내 오픈 소스 소프트웨어 아티팩트의 무결성을 유지하는 데 도움이 되는 표준 및 제어 세트입니다. Google에서 출시한 이 제품은 공급망 보안에 대한 NIST 권장 사항을 충족합니다. SLSA는 개발 프로세스 전반에 걸쳐 사용되는 광범위한 오픈 소스 소프트웨어를 보호하려는 노력에서 SBOM을 보완합니다.
Using SBOMs to find dependencies and vulnerabilities
SBOM의 주요 보안 목적은 소프트웨어 공급망 전체에서 취약점과 위험을 식별하는 것입니다. 취약점을 둘러싼 데이터는 구성 요소가 추가되거나 변경됨에 따라 지속적으로 변경되어 잠재적인 새로운 공격이 발생합니다. SBOM은 기본적으로 정적이므로 SBOM을 생성하는 데 사용되는 데이터는 지속적으로 변화하고 발전합니다.
SBOM은 취약성 분석을 수행하고 개발자가 위험을 줄이기 위해 종속성을 업데이트하는지 확인하려는 소프트웨어 고객을 위한 도구입니다. 그러나 모든 취약점이 동일한 수준의 위험을 나타내는 것은 아닙니다. 일부 취약점은 전혀 위험을 초래하지 않습니다. 이 문제를 해결하기 위해 NTIA는 두 가지 단계를 제공합니다.
개발/공급 측면에서는 취약점의 영향, 특히 소프트웨어의 특정 영역에 영향을 미칠지 여부를 결정해야 합니다.
취약성에 대한 정보는 SBOM 데이터를 통해 잘 전달되어야 하며, 취약성이 위험을 추가하지 않는다는 검증이 이루어져야 합니다.
SBOMs for supply chain security
SBOM은 다음과 같은 방법으로 소프트웨어 공급망에 보안을 추가합니다.
시스템 관계를 포함하여 소프트웨어 제품 전체에 대한 가시성 향상
취약점에 대한 정보 공유
개발자부터 사용자까지 공급망 전반에 걸쳐 커뮤니케이션이 향상되어 보안 위험을 더욱 쉽게 식별
규정 준수 표준 및 감사에 대한 심층적인 기록
SBOM은 소프트웨어 공급망 전반에 걸쳐 더 강력한 보호 기능과 위험 감지 기능을 제공하는 진화하는 보안 도구입니다. 소프트웨어의 각 구성 요소에 대한 보다 정확하고 자세한 정보를 통해 SBOM은 소프트웨어 생산 수명 주기 초기에 취약성을 발견할 수 있는 기회를 제공하고 결과적으로 피해가 발생하기 전에 완화할 수 있습니다.
SBOMs with Snyk
Snyk은 SBOM 구축 프로세스를 자동화하여 조직이 사용하는 오픈 소스 구성 요소 및 종속성을 보다 쉽게 추적할 수 있도록 해줍니다. 또한 이러한 개별 구성 요소를 스캔하여 잠재적인 취약점을 찾아내고 이를 해결하기 위한 실행 가능한 권장 사항을 제공할 수도 있습니다.
Snyk은 코드, 오픈 소스, 컨테이너에 대한 실행 가능한 수정 조언을 제공할 뿐만 아니라 소프트웨어 자재명세서(SBOM)의 내보내기와 평가를 제공하여 소프트웨어 투명성을 강화합니다.
컨테이너 또는 오픈 소스 종속성
외부 엔터티 또는 조직 내부와 공유할 수 있는 애플리케이션용 SBOM을 생성하고, 수신한 SBOM의 알려진 취약점을 테스트합니다.
전이적 종속성 적용 범위
Snyk는 직접적인 종속성을 뛰어 넘어 깊이 중첩된 전이적 종속성을 지원하므로 애플리케이션에 무엇이 있는지 정확히 알 수 있습니다.
API 또는 CLI를 통해 SBOM 생성
Snyk를 사용하면 CLI 또는 API에서 직접 SBOM을 내보낼 수 있으므로 SBOM 생성을 기존 워크플로에 통합할 수 있습니다.
산업 표준 형식
Snyk는 SPDX와 CycloneDX SBOM 형식을 모두 지원하므로 귀하와 귀하의 고객의 요구 사항을 충족할 수 있는 유연성을 제공합니다.
SBOM을 포함해 개발자가 매일 사용하는 도구에서 바로 퍼스트 파티 코드(first-party code), 오픈 소스 라이브러리, 컨테이너 이미지, 클라우드 인프라를 비롯한 소프트웨어 공급망의 중요한 구성 요소를 보호하는 데 도움을 주는 '스닉(Snyk)' 소프트웨어 공급망 솔루션을 확인해보세요.
▶ 스닉(Snyk)
https://www.softwidesec.com/Snyk
What is a Software Bill of Materials (SBOM)?
NTIA(National Telecommunications and Information Administration)에 따르면 소프트웨어 자재 명세서(SBOM)는 소프트웨어 개발에 사용되는 구성 요소와 해당 소프트웨어 공급망 관계에 대한 공식 기록입니다. SBOM은 오픈 소스 소프트웨어(OSS)와 독점 소프트웨어(proprietary software)를 모두 다루며 소프트웨어 내의 잠재적인 취약점과 요소에 대한 투명성을 제공합니다. SBOM은 취약성 관리 및 제품 무결성을 위해 사용될 수 있습니다.
SBOM은 바이든 행정부 행정 명령에 포함되었으며 연방 정부에 소프트웨어를 판매하는 공급업체가 유지 관리해야 합니다.
SBOM은 다음과 같은 귀중한 자산을 포함합니다.
규제 준수
이전 소프트웨어 패키지와 OSS 업데이트 간의 호환성
소프트웨어 공급망 사이버 공격으로부터 고객 보호
소프트웨어 및 라이선스가 포함된 합병 시 보안 보호
Difference between SBOM and CBOM
2018 사이버 보안 자재 명세서(CBOM, Cybersecurity Bill of Materials)는 하나의 행정 명령 내에서 소프트웨어와 하드웨어를 모두 다루고 있습니다. SBOM은 코드 내의 소프트웨어 구성 요소와 버전, 패치, 라이선스, 업데이트 및 변경 내역만 문서화합니다.
Why are SBOMs important for cybersecurity?
소프트웨어 공급망을 겨냥한 사이버 공격이 증가하고 있습니다. 이러한 공격의 절반 이상이 확립된 APT(Advanced Persistal Threat) 사이버 범죄 그룹에서 발생합니다. 그들의 목표는 시스템에 대한 사용자와 공급업체의 신뢰를 활용하는 것입니다.
공급망을 취약하게 만드는 것은 사이버 사고를 둘러싼 투명성이 부족하기 때문입니다. 어떤 경우에는 개발자가 가능한 취약점을 인식하지 못하고 결과적으로 사용자도 취약할 수 있습니다. 오픈 소스 라이브러리는 다른 소프트웨어 구성 요소에 종속됩니다. Log4Shell 취약점과 같은 사례는 직접적인 소프트웨어 종속성(software dependency)이 아니라 다른 구성 요소에 의존하는 전이적 종속성이므로 많은 개발자가 확인하지 않는 구성 요소(이 경우 로깅 라이브러리)의 예입니다.
개발 팀은 이미 애플리케이션 보안(application security)의 필요성을 인식하고 있지만 SBOM은 소프트웨어 공급망과 잠재적인 취약점에 대한 추가적인 가시성을 제공하고 있습니다. 사용자가 소프트웨어 제품 내에서 취약점이 숨겨져 있을 수 있는 위치를 알고 소프트웨어의 구성 요소(특히 오픈 소스인 경우)를 알면 잠재적인 공격을 탐지하고 해결하기 위한 보안 도구를 배포할 수 있는 능력이 더 높아집니다.
사이버 공격이 발생하는 경우 SBOM을 사용하여 취약한 구성 요소가 있는 소프트웨어와 관련된 위험 유형을 식별할 수 있습니다. 이를 통해 사용자는 개발자와 협력하여 패치나 기타 완화 솔루션을 마련할 수 있습니다.
SBOMs Executive Order 14028
Log4Shell 이전에는 솔라윈즈 공급망 공격(SolarWinds supply chain attack) 및 Apache Struts와 관련된 Equifax 사고와 같은 기타 사이버 사고를 통해 대기업 및 기업뿐만 아니라 취약한 정부 기관이 중요 인프라 전반에 걸쳐 얼마나 취약한지 보여주었습니다. 또한 모든 조직이 소프트웨어 공급망에 얼마나 의존하고 있는지, 하나의 취약점이 악용되면 광범위한 연쇄 효과를 가져올 수 있음을 보여주었습니다.
미 행정명령 14028은 국립표준기술연구소(NIST), 국가안보국(NSA), 관리예산국(OMB), 사이버보안 및 인프라 보안국(CISA), 국가정보국장( DNI)는 소프트웨어 공급망의 보안을 개선하기 위한 표준 및 모범 사례를 개발합니다. 지침에는 다음이 포함됩니다.
소프트웨어 보안을 평가하는 기준
개발자 및 공급업체 자체의 보안 관행을 평가하는 기준
보안 관행 준수를 입증하는 혁신적인 도구 또는 방법
When should you use a Software Bill of Materials?
소프트웨어 구성 요소의 새 릴리스마다 새 SBOM을 생성해야 합니다. 마찬가지로 구성 요소가 변경될 때마다 SBOM을 업데이트하여 변경 사항에 맞게 업데이트해야 합니다.
SBOM에 대한 NTIA 기준에는 다음 정보가 필요합니다.
저자 이름(author name)
공급 업체 이름(supplier name)
구성 요소 이름(component name)
구성요소 해시(component hash)
버전 문자열(version string)
식별자(identifier)
관계(relationship)
기본 요구 사항을 충족하기 위해 SBOM 표준은 여러 도구에서 사용할 수 있는 공통 형식을 제공하도록 개발되었습니다. 이러한 표준은 다음과 같습니다.
SPDX: 소프트웨어 제품 데이터 교환은 소프트웨어 패키지의 구성 요소, 라이센스 및 보안 정보를 전달하기 위한 개방형 표준입니다. SPDX는 각각 자체 SBO M을 사용하여 여러 서비스를 표준화합니다.
SWID: 소프트웨어 식별 태그는 수명주기를 정의하는 표준입니다. 태그는 소프트웨어 설치 프로세스의 일부로 엔드포인트에 추가됩니다. 네 가지 태그가 있습니다. 설치 전 단계에서 사용되는 코퍼스 태그; 제품 이름을 제공하고 글로벌 고유 식별자로 간주되는 기본 태그 소프트웨어에 적용된 패치를 설명하는 패치 태그; 추가 정보에 대한 보충 태그.
OWASP Cyclone DX: 공급망 구성 요소 분석 및 애플리케이션 보안에 사용되는 경량 SBOM 표준입니다.
VEX: Vulnerability Exploitability Exchange는 제품에 대한 추가 정보, 특히 구성 요소에서 발견된 취약점을 식별하고 교정을 위한 권장 조치를 제공합니다.
SBOMs and the integrity of the software
SBOM은 소프트웨어 공급망의 무결성을 확인하고 수집된 정보를 기반으로 위험 평가를 허용하도록 구성되어 있습니다. 높은 수준의 평가로서 SBOM은 공급망 내의 소프트웨어 구성 요소 재고를 위한 것입니다. 그러나 표준이 적용됨에 따라 SBOM은 OSS의 규정 준수 표준을 충족하게 됩니다. 예를 들어, SPDX 표준은 해당 구성 요소의 라이센스를 식별하고 라이센스(licenses) 준수를 보장하는 데 사용됩니다.
SLSA(Supply Chain Levels for Software Artifacts)는 공급망 내 오픈 소스 소프트웨어 아티팩트의 무결성을 유지하는 데 도움이 되는 표준 및 제어 세트입니다. Google에서 출시한 이 제품은 공급망 보안에 대한 NIST 권장 사항을 충족합니다. SLSA는 개발 프로세스 전반에 걸쳐 사용되는 광범위한 오픈 소스 소프트웨어를 보호하려는 노력에서 SBOM을 보완합니다.
Using SBOMs to find dependencies and vulnerabilities
SBOM의 주요 보안 목적은 소프트웨어 공급망 전체에서 취약점과 위험을 식별하는 것입니다. 취약점을 둘러싼 데이터는 구성 요소가 추가되거나 변경됨에 따라 지속적으로 변경되어 잠재적인 새로운 공격이 발생합니다. SBOM은 기본적으로 정적이므로 SBOM을 생성하는 데 사용되는 데이터는 지속적으로 변화하고 발전합니다.
SBOM은 취약성 분석을 수행하고 개발자가 위험을 줄이기 위해 종속성을 업데이트하는지 확인하려는 소프트웨어 고객을 위한 도구입니다. 그러나 모든 취약점이 동일한 수준의 위험을 나타내는 것은 아닙니다. 일부 취약점은 전혀 위험을 초래하지 않습니다. 이 문제를 해결하기 위해 NTIA는 두 가지 단계를 제공합니다.
개발/공급 측면에서는 취약점의 영향, 특히 소프트웨어의 특정 영역에 영향을 미칠지 여부를 결정해야 합니다.
취약성에 대한 정보는 SBOM 데이터를 통해 잘 전달되어야 하며, 취약성이 위험을 추가하지 않는다는 검증이 이루어져야 합니다.
SBOMs for supply chain security
SBOM은 다음과 같은 방법으로 소프트웨어 공급망에 보안을 추가합니다.
시스템 관계를 포함하여 소프트웨어 제품 전체에 대한 가시성 향상
취약점에 대한 정보 공유
개발자부터 사용자까지 공급망 전반에 걸쳐 커뮤니케이션이 향상되어 보안 위험을 더욱 쉽게 식별
규정 준수 표준 및 감사에 대한 심층적인 기록
SBOM은 소프트웨어 공급망 전반에 걸쳐 더 강력한 보호 기능과 위험 감지 기능을 제공하는 진화하는 보안 도구입니다. 소프트웨어의 각 구성 요소에 대한 보다 정확하고 자세한 정보를 통해 SBOM은 소프트웨어 생산 수명 주기 초기에 취약성을 발견할 수 있는 기회를 제공하고 결과적으로 피해가 발생하기 전에 완화할 수 있습니다.
SBOMs with Snyk
Snyk은 SBOM 구축 프로세스를 자동화하여 조직이 사용하는 오픈 소스 구성 요소 및 종속성을 보다 쉽게 추적할 수 있도록 해줍니다. 또한 이러한 개별 구성 요소를 스캔하여 잠재적인 취약점을 찾아내고 이를 해결하기 위한 실행 가능한 권장 사항을 제공할 수도 있습니다.
Snyk은 코드, 오픈 소스, 컨테이너에 대한 실행 가능한 수정 조언을 제공할 뿐만 아니라 소프트웨어 자재명세서(SBOM)의 내보내기와 평가를 제공하여 소프트웨어 투명성을 강화합니다.
컨테이너 또는 오픈 소스 종속성
외부 엔터티 또는 조직 내부와 공유할 수 있는 애플리케이션용 SBOM을 생성하고, 수신한 SBOM의 알려진 취약점을 테스트합니다.
전이적 종속성 적용 범위
Snyk는 직접적인 종속성을 뛰어 넘어 깊이 중첩된 전이적 종속성을 지원하므로 애플리케이션에 무엇이 있는지 정확히 알 수 있습니다.
API 또는 CLI를 통해 SBOM 생성
Snyk를 사용하면 CLI 또는 API에서 직접 SBOM을 내보낼 수 있으므로 SBOM 생성을 기존 워크플로에 통합할 수 있습니다.
산업 표준 형식
Snyk는 SPDX와 CycloneDX SBOM 형식을 모두 지원하므로 귀하와 귀하의 고객의 요구 사항을 충족할 수 있는 유연성을 제공합니다.
SBOM을 포함해 개발자가 매일 사용하는 도구에서 바로 퍼스트 파티 코드(first-party code), 오픈 소스 라이브러리, 컨테이너 이미지, 클라우드 인프라를 비롯한 소프트웨어 공급망의 중요한 구성 요소를 보호하는 데 도움을 주는 '스닉(Snyk)' 소프트웨어 공급망 솔루션을 확인해보세요.
▶ 스닉(Snyk)
https://www.softwidesec.com/Snyk