최신 소프트웨어 패키지는 사이버 보안 관행의 발전 덕분에 그 어느 때보다 안전합니다. 그러나 가장 지능적인 위협에 직면해 있기 때문에 안전한 만큼 취약하기도 합니다. 다음과 같은 공급망 공격 태양풍 다음과 같은 심각한 취약점 Log4Shell 오늘날 소프트웨어 시스템이 직면한 최신 위협 중 하나입니다. 이와 같은 소프트웨어 공급망 공격은 효과가 역동적이고 직접 제어할 수 없는 시스템의 취약점을 악용하기 때문에 탐색하기가 더 어렵습니다.
그러나 이와 같은 소프트웨어 공급망 공격에 맞서기 위한 첫 번째 단계는 소프트웨어에 포함된 패키지, 종속성 및 구성 요소에 대한 명확한 지식을 갖는 것입니다. 이것이 바로 빌드에 대한 소프트웨어 자재 명세서(SBOM)를 생성하는 것이 중요한 이유입니다. 이는 소프트웨어 공급망의 취약점에 대한 가시성을 향상시킬 뿐만 아니라 규정 준수 목적으로도 중요해졌습니다. SBOM 생성은 최근에 의해 의무화되었습니다. 미국 연방정부가 발표한 행정명령 사이버 보안을 강화하고 소프트웨어 패키지에 사용되는 타사 구성 요소의 신뢰성을 보장합니다.
A에 따라 가트너 예측에 따르면, 중요 인프라 소프트웨어 개발을 담당하는 조직의 60%는 2025년까지 표준화된 SBOM을 필요로 할 것입니다. SBOM 생성은 조직의 표준 및 목표에 맞는 도구를 선택하고 소프트웨어 빌드 수명주기 단계를 결정하는 것부터 시작됩니다. SBOM을 적용하여 형식을 준수하는지 확인하고 취약점 스캔을 수행합니다. SBOM을 생성하는 것은 섬세하고 복잡한 프로세스입니다. 이 문서에서는 SBOM 생성이 필요한 시기와 소프트웨어에 맞게 생성하는 방법을 다룹니다.
소프트웨어 BOM을 생성하는 시기
소프트웨어 빌드와 전체 소프트웨어 공급망을 보호하려면 소프트웨어 자재 명세서(SBOM)를 생성하는 것이 필수적입니다. SBOM 생성은 소프트웨어 빌드 프로세스의 다양한 단계에 통합될 수 있습니다. 빌드 시간, 런타임 또는 소프트웨어에 대한 포렌식을 수행하는 동안 소스 코드를 사용하여 BOM을 생성할 수 있습니다. 이 중에서 전문가들은 빌드 시간 동안 SBOM을 생성할 것을 권장합니다. 이는 빌드 시 SBOM 생성기가 더 정확하고 더 완전한 종속성 목록을 생성하기 때문입니다. 그러나 이것이 항상 실용적인 것은 아니기 때문에 DevOps 수명 주기 중 언제든지 SBOM을 생성할 수 있습니다.
사용할 SBOM 생성 도구 유형은 SBOM 문서가 생성되는 DevOps 수명주기의 단계에 따라 다르다는 점은 주목할 가치가 있습니다. 다음은 빌드 수명 주기 동안 SBOM이 생성될 수 있는 다양한 단계입니다. 각 기간에는 서로 다른 장점과 장단점이 있습니다. 생성 중인 SBOM 데이터의 대상 고객과 사용 사례를 이해하고 최상의 결과를 제공하는 접근 방식을 선택하는 것이 가장 좋습니다.
소스코드 단계에서
매니페스트, 메타데이터 및 잠금 파일과 같은 아티팩트 및 관련 소스를 검사함으로써 소스 또는 바이너리 도구는 소스 코드 단계에서 소프트웨어 BOM을 생성합니다. 이 단계에서는 소프트웨어 구성 요소 분석이나 소프트웨어의 이진 분석을 수행할 수 있습니다.
SCA(소프트웨어 구성 요소 분석) 도구는 소프트웨어 일부와 해당 매니페스트 파일을 분석하여 해당 구성 요소를 확인하도록 설계되었습니다. 반면, 바이너리 분석 도구는 소프트웨어 메타데이터를 분석하고 아티팩트 정보를 구축하여 SBOM을 생성합니다. 이 단계에서 사용되는 분석 도구의 예로는 CycloneDX, It-Depends, Fossa, AppSonar, Cybellum, Black Duck 및 Fortress가 있습니다.
취약점 분석기를 소스 코드 단계에서 생성된 SBOM과 함께 사용하면 구축 중인 소프트웨어의 조기 취약점 경고를 받을 수 있습니다. 그러나 이 단계에서 생성된 SBOM에는 제한이 있습니다. 우선, 종속성 정보를 사용하여 빌드하는 동안 생성된 정보가 누락되는 경우가 많기 때문에 완전하지 않습니다. 또한 최종 배포된 제품에 사용되지 않은 구성 요소에 대한 정보도 포함될 수 있습니다.
빌드 시간 중
빌드 시스템을 활용하는 도구를 사용하여 빌드 시 SBOM을 생성하면 전이적 및 고정되지 않은 종속성을 포함하여 바이너리에 들어가는 내용에 대한 가장 정확한 지식을 얻을 수 있습니다. 이는 다음에서 지원됩니다. 소프트웨어 공급업체의 SBOM 생산 및 제공에 관한 NTIA 연구.
NTIA는 각각의 새로운 구성 요소 릴리스에 대해 SBOM을 생성할 것을 권장합니다. 이는 소프트웨어의 새 버전을 업데이트하거나 출시할 때마다 새로운 SBOM을 생성한다는 의미입니다. 공급업체는 이전 버전에서 실수를 발견하거나 이전에 문서화되지 않은 소프트웨어 구성 요소에 대한 새로운 정보를 배울 때마다 새로운 SBOM을 생성해야 합니다.
빌드 타임 동안 SBOM을 생성하려면 소프트웨어를 빌드하는 기본 환경에서 작동하는 플러그인을 사용하는 것이 포함됩니다. 대부분의 개발 환경에는 종속성 관리 시스템과 통합되어 SBOM을 자동으로 생성하는 플러그인이 있습니다. 빌드 타임 SBOM 생성기의 예로는 SPDX, CycloneDX Maven 플러그인 및 OWASP의 종속성 추적 검사가 있습니다.
빌드 타임 SBOM 생성기는 가장 포괄적이고 정확하지만 다른 방법에 비해 설정하기가 더 어렵습니다. 또한 이 방법은 일부 빌드 시스템에서는 작동하지 않으며 레거시 제품에는 이 방법을 사용할 수 없습니다.
런타임 중 SBOM 생성
런타임 중에 작동하는 SBOM 생성기는 런타임 중에 소프트웨어, 앱 서버 또는 플러그인이 사용하는 라이브러리를 캡처하도록 설계되었습니다. 이 유형의 생성기는 소프트웨어가 호출하는 모든 서비스뿐만 아니라 소프트웨어가 액세스하는 포트 및 활성 라이브러리도 자세히 설명합니다. 그러나 SBOM을 생성하는 이 방법은 널리 사용되지 않습니다. 또한 이 방법을 사용하여 생성된 데이터를 원본 SBOM 문서와 병합하기 위한 명확한 작업 흐름이 없습니다. JBOM 및 ThreatMapper 런타임 SBOM 생성기의 예입니다.
소프트웨어 BOM 생성 방법: 단계별 가이드
소프트웨어 BOM을 수동으로 생성하는 것은 개발자에게 시간이 많이 걸리고 지루한 작업입니다. 소프트웨어 프로그램의 모든 구성 요소를 이런 방식으로 나열하는 것은 대부분 비실용적입니다. 그러나 이제 이 프로세스를 단순화하는 다양한 SBOM 생성 도구를 사용할 수 있습니다. 이를 수행하는 방법은 조직의 표준과 개발 수명 주기 동안 SBOM을 생성하려는 시기에 따라 다릅니다.
SBOM 워크플로를 소프트웨어 빌드 파이프라인에 통합하면 SBOM 프로세스를 자동화할 수 있습니다. 스크라이브 플랫폼 소프트웨어 BOM 작성 방법을 단순화하는 도구 중 하나입니다. Scribe를 사용하면 한 곳에서 SBOM을 관리하고 공유할 수 있습니다. 이러한 방식으로 소프트웨어 구성 요소의 무결성을 검증하고 소프트웨어 파이프라인의 취약점을 원활하게 추적할 수 있습니다. 이 섹션은 Scribe를 사용하여 소프트웨어 BOM을 생성하기 위한 단계별 가이드입니다.
1단계: Scribe Trust Hub에 등록하고 로그인합니다.
시작하기 전에 Scribe 플랫폼에는 브라우저에서 액세스할 수 있는 웹 인터페이스인 Scribe Trust Hub가 있다는 점을 알아야 합니다. 그러나 Scribe 증거 수집기는 Linux 및 Mac 장치에서만 실행됩니다. Scribe를 사용하여 무결성 보고서 및 SBOM을 생성하려면 프로젝트의 빌드 스크립트를 수정하고 프로젝트를 Scribe에 연결하는 데 필요한 관련 코드 조각을 추가할 수 있는 권한이 있어야 합니다. Scribe는 컨테이너 이미지를 생성하는 프로그래밍 언어로 작성된 프로젝트에 대해 SBOM을 생성할 수 있지만 현재 릴리스는 Node.js 프로젝트에서만 작동합니다.
Scribe를 프로젝트에 통합하기 위한 첫 번째 단계는 Scribe Trust Hub에 등록하는 것입니다. 등록하고 로그인한 후 "제품" 탭으로 이동하여 설정을 클릭하세요. Scribe에는 이 페이지에 데모 제품이 있으며, 이를 통해 플랫폼의 사용법과 작동 방식을 알아볼 수 있습니다.
2단계: Scribe Trust Hub 통합
다음 단계는 Scribe를 프로젝트의 지속적 통합 파이프라인에 연결하는 것입니다. 이는 SBOM 생성 프로세스를 자동화합니다. 일반적으로 Scribe Trust Hub의 코드 조각을 CI 파이프라인의 두 지점에 추가할 수 있습니다. 소스 코드 체크아웃이나 최종 빌드 이미지에 코드를 배치할 수 있습니다. 첫 번째 옵션은 권장되지만 필수는 아니며, 두 번째 옵션은 필수입니다.
Scribe의 CI 설정은 현재 Kubernetes 및 GitHub Actions를 통한 Jenkins에서만 작동합니다. 이러한 CI 설정을 위해 Scribe를 통합하는 과정은 비슷합니다. 시작하려면 Scribe Hub 제품 설정 페이지에서 다음 자격 증명을 얻어야 합니다.
- 제품 키
- 고객 ID
- 클라이언트 비밀
제품 키는 제품마다 다르지만 클라이언트 자격 증명은 계정마다 고유합니다.
Jenkins를 위한 CI 통합 설정
Jenkins에 대한 CI 통합을 설정하려면 결제 지점 및/또는 Docker 이미지 생성 후 "Gensbom"(증거 수집 및 SBOM 생성을 위한 Scribe Trust Hubs의 도구)을 호출하는 코드 조각을 추가할 수 있습니다.
고유한 지침에 따라 위의 자격 증명을 빌드 환경에 추가하여 시작하세요. 젠킨스. 다음으로 지침에 따라 파이프라인에 코드 조각을 추가합니다. 여기를 클릭해 문의해주세요.
GitHub Actions에 대한 CI 통합 설정
GitHub Actions에 대한 CI 통합을 설정하는 프로세스는 Jenkins의 프로세스와 유사합니다. 주요 아이디어는 "Gensbom"으로 알려진 Scribe의 증거 수집기 및 SBOM 생성기를 호출하는 것입니다. 시작하려면 다음을 따르세요. GitHub 지침 지침에 따라 파이프라인에 제품 설정 자격 증명과 코드 조각을 추가합니다. 여기에서 지금 확인해 보세요.
Scribe Trust Hub를 다른 CI 시스템과 통합
Scribe는 Jenkins 및 GitHub 작업에 대한 기본 지원만 제공하지만 이를 다른 CI 시스템에도 사용할 수도 있습니다. 시작하려면 Unix 기반 명령줄 인터페이스에서 "Gensbom" 도구를 다운로드하세요. 다음으로 제품과 클라이언트 자격 증명을 추가한 다음 체크아웃 시 또는 최종 빌드 이미지 후에 빌드 스크립트에서 Scribe gensbom을 호출하세요.
3단계: 소프트웨어 BOM 생성
Scribe의 gensbom CLI 도구는 Docker 및 OCI(Open Containers Images)에 대한 소프트웨어 자재 명세서(SBOM)를 생성합니다. 이 도구는 Mac 또는 Linux 시스템에서만 실행됩니다. Scribe에서 생성된 최종 SBOM은 CycloneDX JSON 형식으로, 이는 SBOM으로 인식되는 표준 머신 및 사람이 읽을 수 있는 형식 중 하나입니다. 열려 있는 컨테이너 이미지는 경우에 따라 Docker, 로컬 디스크 또는 원격 레지스트리에서 추출할 수 있습니다.
SBOM이 생성되는 이미지의 이름, 디렉터리 및 경로에 대한 기본 설정이 있지만 원하는 경우 이러한 기본 설정을 적절하게 변경할 수 있습니다.
4단계: SBOM 내보내기
Scribe Trust Hub를 사용하면 소프트웨어 검증 프로세스의 일부로 소프트웨어 BOM을 원활하게 내보내고 공유할 수도 있습니다. SBOM은 CycloneDX JSON 보고 형식으로 생성되며 분석된 Docker 이미지의 모든 오픈 소스 종속성을 자세히 설명합니다. SBOM이 생성되면 한 번의 클릭으로 내보낼 수 있습니다. 보고서 오른쪽 상단에 'SBOM 내보내기' 버튼이 있습니다. 소프트웨어 BOM을 내보내려면 클릭하세요.
결론
소프트웨어 BOM을 생성하는 것은 소프트웨어 공급망을 보호하고 규정 준수 목적을 위해 점점 더 중요한 단계가 되고 있습니다. SBOM을 생성하는 이유에 관계없이 Scribe Trust Hub는 각 소프트웨어 빌드에 대한 SBOM 생성 워크플로를 자동화하는 사용하기 쉽고 유연한 방법입니다.