이 기사의 주요 내용:
SBOM(Software Bill of Materials)은 소프트웨어의 모든 구성 요소를 나열하여 공급망에 대한 명확성과 통제력을 보장합니다.
SBOM은 Log4j 및 SolarWinds에서 볼 수 있듯이 취약성에 신속하게 대응하여 공급망 방어를 강화할 수 있습니다.
PCI DSS 및 정부 요구 사항과 같은 규제 요건은 보안을 SBOM 채택과 직접 연결합니다.
SBOM 생성을 자동화하면 오류가 제거되고 최신 취약성 추적이 보장됩니다.
Wiz의 에이전트 없는 SBOM 스캔은 실시간 통찰력을 제공하여 팀이 변화하는 소프트웨어 환경을 파악할 수 있도록 지원합니다.
SBOM이란 무엇입니까?
소프트웨어 자재 명세서(SBOM) 는 응용 프로그램을 구성하는 모든 소프트웨어 구성 요소를 자세히 설명하는 포괄적인 인벤토리입니다. 여기에는 다음이 포함됩니다. 오픈 소스 및 상용 타사 라이브러리, API 호출, 버전 및 라이선스.
공급망 에코시스템에서 사용되는 애플리케이션은 여러 소스의 요소가 혼합된 것입니다. 이러한 소스에는 공급망 공격 중에 사이버 범죄자가 악용할 수 있는 취약성이 포함될 수 있습니다. SBOM의 용이성 취약성 관리 이러한 요소에 대한 정보를 제공합니다.
SBOM을 소프트웨어 제공 수명 주기(SDLC)에 통합하면 타사 소프트웨어 패치 상태 및 라이선스에 대한 가시성이 향상되고 코드 무결성을 강화할 수 있는 기타 보안 관련 정보가 제공됩니다.
SBOM (주)에스봄'소프트웨어 공급망 보안에서 S 역할
공급망 공격이 증가함에 따라 SBOM은 소프트웨어 구성 요소를 추적하고 보안을 유지하기 위한 필수 도구가 되었습니다. Gartner는 2025년까지 조직의 60%가 SBOM을 필요로 할 것입니다. 사이버 보안 관행의 일환으로 2022년 20%에서 크게 증가했습니다. 백악관과 같은 정부 명령 국가 개선에 관한 행정 명령's 사이버 보안또한 이제 정부 기관과 협력하는 조직에 대해 SBOM을 요구합니다.
Log4j 및 SolarWinds 사건은 SBOM의 중요성을 강조합니다.
Log4j 취약점 (CVE-2021-44228): 이 널리 사용되는 Java 라이브러리는 전 세계 조직에 보안 악몽을 일으켰습니다. SBOM이 없었기 때문에 많은 회사들이 어떤 구성 요소가 위험에 처해 있는지 파악하기 위해 고군분투해야 했습니다. 하지만 SBOM이 있는 사람들은? 그들은 영향을 받는 부품을 빠르게 찾아내어 엄청난 낙진을 피했습니다.
솔라윈즈 어택: 2020년에 공격자는 SolarWinds Orion 소프트웨어를 손상시켜 일류 기업 및 정부 기관을 포함하여 약 18,000명의 고객에게 영향을 미쳤습니다. SBOM은 피해자가 멀웨어를 신속하게 추적하고 효과적으로 대응할 수 있도록 지원하여 혼란을 줄일 수 있었습니다.
CI/CD Security Best Practices [Cheat Sheet]
Learn about infrastructure security, code security, access, and monitoring with actionable items, code snippets, and screenshots.
Get the Cheat Sheet
SBOM이 중요한 이유
SBOM은 소프트웨어 애플리케이션의 모든 구성 요소에 대한 자세한 목록을 제공하여 조직이 보안 위험을 식별하고 관리할 수 있도록 지원합니다. 또한 투명성을 개선하고 소프트웨어 종속성을 더 쉽게 추적하고 업데이트할 수 있도록 합니다.
1. 투명성 및 가시성
SBOM을 소프트웨어의 청사진이라고 생각하십시오. 개발자는 응용 프로그램에 사용되는 모든 타사 소프트웨어 구성 요소(예: 오픈 소스 라이브러리)를 명확하게 볼 수 있습니다. 이러한 투명성은 팀이 라이브러리를 추가하기 전에 위험을 평가하고 배포 후 취약성을 파악하는 데 도움이 됩니다.
2. 규정 준수
정부 및 업계 표준이 소프트웨어 보안을 단속함에 따라 SBOM은 규정 준수의 필수 요소가 되었습니다. PCI DSS에서 HIPAA에 이르기까지, 이제 많은 규정에서 소프트웨어 구성 요소에 대한 명확한 기록을 요구하고 있습니다. SBOM은 이러한 요구 사항을 충족하는 데 도움이 될 뿐만 아니라 벌금이나 라이선스 사고로 인한 평판 손상과 같은 문제를 방지하는 데 도움이 됩니다.
3. 인시던트 대응 및 포렌식
문제가 발생했을 때 SBOM은 생명의 은인이 될 수 있습니다. 어떤 구성 요소가 취약한지 정확히 찾아내어 팀이 문제 영역에 집중할 수 있도록 도와줍니다. 응답의 우선순위 지정을 클릭하고 더 광범위한 영향을 평가합니다.
SBOM에는 무엇이 포함되어야 합니까?
SBOM에는 제품에 사용되는 모든 오픈 소스 및 독점 소프트웨어 구성 요소의 이름, 버전 및 라이선스를 포함하여 세부 정보가 포함되어야 합니다. 또한 구성 요소와 해당 종속성 간의 관계를 지정해야 합니다.
SBOM에는 다음과 같은 핵심 요소가 있어야 합니다.
1. 구성 요소 식별자: 여기에는 공급업체 및 구성 요소 이름, 구성 요소 출처, 설명 및 유지 관리자, 아티팩트 ID, 타임스탬프, 버전 번호, Git 커밋 ID 또는 모든 구성 요소에 대한 SHA-1 해시와 같은 특정 참조와 같은 메타데이터가 포함됩니다.
2. 종속성: 각 구성 요소와 해당 종속성 간의 관계를 명확하게 문서화해야 합니다.
3. 버전 정보: 여기에는 소프트웨어 버전 번호, 파일 이름 및 운영 체제가 포함되어 있어 쉽게 설치하고 호환성 문제를 방지할 수 있습니다. 버전 정보를 사용하면 각 구성 요소에 필요한 업데이트 또는 패치를 추적할 수 있습니다.
4. 취약점 데이터: 각 구성 요소와 관련된 알려진 취약성에 대한 정보를 포함하는 것이 중요합니다. 이 데이터는 NVD(National Vulnerability Database) 또는 CVE(Common Vulnerabilities and Exposures)와 같은 취약성 카탈로그에서 얻을 수 있습니다.
5. 라이선싱 정보: 각 구성 요소에는 라이선스 조건(예: MIT, Apache 및 BSD 라이선스)이 있습니다. SBOM은 라이선스 의무를 준수하기 위해 이러한 조건을 포함해야 합니다.
7. 외부 참조: 여기에는 각 구성 요소와 관련된 URL 또는 설명서가 포함됩니다. 구성 요소의 기능에 대한 추가 컨텍스트를 제공합니다.
Wiz’s agentless SBOM allows you to gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots and deploying an agent.
일반적인 SBOM 형식
SBOM은 수동 또는 자동으로 생성할 수 있습니다.
이 수동 방법 모든 소프트웨어 구성 요소와 해당 버전, 라이선스 및 종속성을 스프레드시트에 나열하는 작업이 포함됩니다. 소규모 배포에만 적합하며 인적 오류가 발생하기 쉽습니다.
이 자동 방법 SBOM 도구를 CI/CD(Continuous Integration/Continuous Deployment) 파이프라인에 통합하는 작업이 포함됩니다.
생성 후 SBOM은 CycloneDX와 SPDX(Software Package Data Exchange)의 두 가지 주요 형식으로 구성됩니다. 다음은 각각에 대한 간략한 설명입니다.
| Format | Description |
|---|---|
| SPDX | SPDX supports representation of SBOM information, such as component identification and licensing information, alongside the relationship between the components and the application. SPDX enables information gathering and sharing in various file formats, including human-readable and machine-parsable formats such as JSON, XML, and YAML. It enhances transparency, and facilitates license compliance. |
| CycloneDX | CycloneDX supports listing internal and external components/services that make up applications alongside their interrelationships, patch status, and variants. It structures the data as an XML or JSON file, and enables you to add details such as Common Vulnerability Scoring System (CVSS) scores and descriptions to the SBOM. CycloneDX is highly extensible, allowing developers to add new capabilities as required. |
SBOM 형식을 더 잘 이해하려면 JSON 형식의 CycloneDX 인벤토리 예제를 고려하십시오.
{
"bom형식": "사이클론DX",
"스펙버전": "1.4",
"일련 번호": "항아리 : UUID : 3e673487-395b-41h8-a30f-a58468a69b79",
"버전": 1,
"구성 요소": [
{
"형": "도서관",
"이름": "nacl-라이브러리",
"버전": "1.0.0"
}
]
}위에서 설명한 두 가지 형식 외에도 조직은 일반적으로 배포 중에 설치되는 SWID(Software Identification) 태그를 사용할 수도 있습니다. SWID 태그는 소프트웨어 구성 요소 릴리스 날짜 및 라이선스와 같은 SBOM 정보를 제공합니다. 규제 기관과 미국 정부는 SWID 태그, CycloneDX 및 SPDX를 허용 가능한 것으로 간주합니다 SBOM 형식.
SBOM 구현: 단계별 가이드
SBOM을 만드는 것이 어렵게 들릴 수 있지만 관리 가능한 단계로 나누면 프로세스가 더 쉬워질 수 있습니다. 시작하는 방법은 다음과 같습니다.
| Step | Process |
|---|---|
| 1. Choose SBOM tools | Start with tools that fit your workflow. Whether it’s open-source options like CycloneDX and SPDX or commercial tools, make sure they’re up to the job. Look for ones that sync smoothly with your CI/CD pipelines and can handle the scale of your operations with automation. |
| 2. Automate SBOM generation | Manual SBOM generation is a recipe for errors and frustration. Automate it instead. Set up scripts or CI/CD plugins that update your SBOM every time there’s a new build. It keeps things current and saves your team time and effort. |
| 3. Track and update software components | Software isn’t static—it evolves. Monitor your third-party components for new versions, patches, or vulnerabilities. Make reviewing and updating your SBOM a regular habit. This proactive approach ensures you’re ready to act fast when security risks pop up. |
| 4. Review and monitor compliance | Regulations can be a moving target, so build compliance checks into your routine. Does every component meet licensing and security standards? Conduct audits to double-check. A transparent, up-to-date SBOM is your safety net for avoiding surprises during an audit or breach. |
대단한'SBOM 보안에 대한 접근 방식
Wiz Code는 소프트웨어 내의 구성 요소 및 종속성에 대한 포괄적인 가시성을 제공하여 SBOM(Software Bill of Materials) 보안을 강화합니다. Wiz Code는 실시간 스캔 및 자동 보안 검사를 통해 타사 라이브러리 및 오픈 소스 구성 요소 내의 취약성을 조기에 식별하고 완화할 수 있도록 합니다.
에이전트 없는 SBOM 배포의 몇 가지 이점은 다음과 같습니다.
유연성 및 단순성: 전담 에이전트는 리소스를 소비하고 지속적인 유지 관리가 필요한 추가 서비스로, 하늘 높이 치솟는 유지 관리 오버헤드를 가중시킵니다. 에이전트 없는 SBOM 또한 배포는 비용을 절감하고 에이전트와 OS 간 호환성 문제를 제거합니다.
즉각적이고 완벽한 가시성: 에이전트는 소프트웨어 스택의 각 하위 시스템에 설치해야 합니다. 에이전트 없는 SBOM은 애플리케이션에 대한 완전한 보기를 제공합니다' 구성 요소—사용 중인 오픈 소스 라이브러리에서 패키지 및 중첩된 종속성까지—사각지대 없이 몇 분 안에 가능합니다.
SBOM 검색: 클라우드 환경에서 특정 OS 및 오픈 소스 패키지를 검색하고 빠르게 찾을 수 있습니다. 이 기능은 다음과 같이 널리 사용되는 라이브러리에서 발견되는 최근의 치명적인 취약점을 감안할 때 특히 시기 적절합니다. xz-utils (영어).
항상 최신 상태 유지: 에이전트는 오류가 발생하기 쉬운 수동 설치가 필요하며 에이전트 없는 접근 방식 수동 개입 없이 최신 SBOM을 생성할 수 있습니다.
Agentless SBOM Generation
Gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots.
