SBOM (Software Bill of Materials)

이 글을 통해 SBOM 대한 생각을 정리하고, 여러 툴들을 이용해 SBOM을 만들며 보안 이슈를 확인해볼까 해요.

간단히 만들어 보는 과정만을 담고 있으므로 SBOM 생성/분석 툴들의 상세한 옵션들은 다루지 않을게요.

 

---

SBOM이란 무엇일까요?

SBOM은 Software Bill of Materials의 약자예요.

Maven을 사용해보신 개발자라면 BOM이라는 단어 그리고 Bill of Materials는 많이 접해보셨을 텐데요.

단어 뜻 그대로 "자재명세서"를 의미해요. '어떤 소프트웨어가 무엇으로 이루어져있지?'한다면 Bill of Materials를 통해 '아 이런 소프트웨어들이 내포되어 있구나!'라는 것을 알 수 있어요.

이러한 Maven BOM을 이용하여 여러 라이브러리들의 의존성 버전을 관리하고, 라이브러리 간 버전 충돌 방지 등의 이점을 얻을 수 있었죠.

 

SBOM도 비슷한 의미이지만, 하고자 하는 역할이 달라요.

SBOM 파일을 통해서 특정 소프트웨어가 어떤 라이브러리, 패키지, 라이선스 등 어떠한 구성요소로 이루어져 있는지 확인할 수 있어요.

하지만 Maven BOM에서는 빌드 간 편의성을 이를 관리했던 것과 달리 SBOM은 소프트웨어 공급망(Software Supply Chain)에 대한 가시성을 높이고, 소프트웨어 종속성을 편리하게 추적하고 관리하기 위한 용도로 활용돼요.

Maven은 Maven 생태계에서 빌드 환경에 편의를 위해 고안된 것이라면,
SBOM은 특정 언어 및 빌드 툴에 의존적인 형태가 아닌 소프트웨어에 대해 종속성에 대한 가시성을 높이고 편리하게 관리하기 위해 고안되었다고 볼 수 있어요.

 

 

왜 필요할까요?

그럼 '소프트웨어 공급망(Software Supply Chain)에 대한 가시성을 높이고, 소프트웨어 종속성을 편리하게 추적하고 관리하기 위한 용도'가 왜 필요할까요?

 

큰 프로젝트를 관리해보신 분이라면 라이브러리 종속성 관리의 어려움을 아실 거예요.

프로젝트가 커져감에 따라 필요한 기능들이 많아지고, 기능들을 손수 구현하는 것이 아닌 여러 라이브러리들을 사용하다보면 어느새 엄청나게 많은 라이브러리가 의존성 목록에 존재하게 돼요.

이와중에 컨테이너 환경이 도입되면서 빌드에 사용되는 툴/소스들을 관리하게 되고, 운영 컨테이너 내부적으로 사용되는 소프트웨어 등 추가적으로 관리해야하는 소프트웨어들은 엄청나게 많아요.

 

이 때, 특정 소프트웨어의 버전에 보안 취약점이 공개되었다고 해볼까요? 이 소프트웨어가 사용 중인지 어떻게 알 수 있을까요? 더 나아가 특정 버전이 사용 중인지 어떻게 알 수 있을까요?

맞아요. 모든 환경에서 사용중인지 직접 찾아보는 과정을 거쳐야 해요.

소규모 프로젝트라면 쉽게 확인할 수 있겠지만, 대규모 프로젝트라면 이 과정도 쉽지 않을 거예요.

 

만약 쉽게 찾더라도, 이를 보안 취약점이 공개될 때마다 수동으로 찾아봐야한다는 문제도 있어요.

CVE, GHSA 등 보안취약점은 계속적으로 추가되고 공개되는데, 그 때마다 내 소프트웨어가 이에 해당하는지 찾아보는 것은 비효율적이에요.

 

SBOM은 이러한 문제를 해결하기 위해 등장했어요.

 

SBOM

SBOM은 라이브러리, 패키지, 라이선스 등 소프트웨어의 구성요소 목록이에요.

• 패키지 이름, 버전, 작성자, 사용 위치, 배포되는 라이선스, 보안 취약점 등 중요한 정보를 캡슐화하여 제공해요.
• 단순한 목록이 아닌 소프트웨어 투명성을 위한 도구로서 보안, 규정 준수, 종속성 관리 측면에서 소프트웨어를 개선할 수 있도록 도와요.

 

미래에는 SBOM과 이를 통한 보안 취약점 관리 등이 필수적인 요소로 자리잡을 것으로 예상돼요.

• 현재는 아직 필수적인 요소로 보여지지는 않아요. 하지만 추후 시간이 지남에 따라 SBOM의 중요성이 부각되면서 필수적인 요소로 보여질 것 같아요 (복잡한 소프트웨어 생태계에서 보안을 위한 스탠다드 느낌).
• CI/CD 단계에서도 SBOM을 생성하고, 이를 통해 보안 취약점을 분석하는 작업을 하게 될 거예요. 또한, Private Registry에 올라간 이미지들에 대하여 정기적인 SBOM을 이용한 보안 분석이 수행될 거예요 (빌드 될 때 발견되지 않은 보안취약점/잠재적인 보안취약점 발견을 위한 프로세스).

 

당연하겠지만 그냥 '내가 Markdown으로 라이브러리 목록 작성해서 만들어야지~'는 SBOM이 아니에요.

위 목적에 맞게 정해진 스펙으로 만들어진 것이 SBOM이며 여러 포맷을 지원하고 있어요. 이에 대해서는 뒤에서 알아볼게요!

SBOM과 그 필요성에 대해 더 자세히 보고 싶다면, anchore의 글을 참고하시면 좋아요.

 

---

SBOM 생성하기

이제, SBOM을 만들어볼까요?

SBOM은 정해진 형식이 있는 파일이에요. 고로, 저희가 수동으로 만들기보단 툴을 이용해서 만들어요.

 

Syft 이용하기

SBOM에는 여러 포맷(Syft, CycloneDX, SPDX등)이 있으며, 이를 만드는 툴(Trivy, Syft, Docker Scout 등)도 여러가지가 존재해요.

• 참고) 지금으로부터 2년이 되긴했는데, 포맷에 대해 설명한 IT WORLD (한국어로 작성된) 기사가 있네요.

 

이 중 많이 활용되고 있는 Syft 툴을 이용해볼까요?

GitHub - anchore/syft: CLI tool and library for generating a Software Bill of Materials from container images and filesystems

 

Syft는 앞서 이야기한 3개의 포맷을 다 지원하기 때문에(syft output formats), 원하는 포맷을 타겟해서 SBOM을 생성할 수 있어요.

사용 방법은 간단해요. CLI를 설치하고 단순히 특정 컨테이너 이미지를 넘겨주기만 하면 돼요.

$ syft tree9295/sbom-test-spring:0.0.1 -o syft-json > syft.sbom.json
 ✔ Loaded image                      tree9295/sbom-test-
 ✔ Parsed image                    sha256:916882e8fb9a6cb4
 ✔ Cataloged contents              5c7a714ff592cac86f4d3ff
   ├── ✔ Packages                        [51 packages]
   ├── ✔ File digests                    [220 files]
   ├── ✔ File metadata                   [220 locations]
   └── ✔ Executables                     [107 executables]

• 설치 방법은 Syft README를 참고해주세요.
• 테스트를 위해 Spring boot 3.2.1 + Web/MVC을 이용해 구성된 container를 배포해두었어요 (tree9295/sbom-test-spring)
• 만약 다른 format을 이용하고 싶다면, `-o cyclonedx-json` 같이 output option으로 설정하시면 돼요.

 

 

결과 확인

위 결과로 만들어진 syft.sbom.json 파일을 살펴볼까요?

파일의 양이 많아 전체를 담지는 못했지만, 아래와 같이 사용된 라이브러리와 그 정보들을 담고 있는 것을 확인할 수 있어요.

여기서 알아야하는 것은 저희가 사용했다고 생각한 라이브러리(spring boot 등) 뿐 아니라 Container 이미지에서 사용하고 있는 기본 툴들에 대한 정보도 다 포함되어 있다는 거예요.

 

어떻게 만드는걸까요?

이렇게 SBOM을 만들어보았는데요. 한 가지 궁금증이 들어요.

Syft 같은 SBOM 생성 툴들은 단순 Container image로 SBOM을 어떻게 만들 수 있었던 걸까요?

 

아시다시피 Container image는 단순 애플리케이션이 아닌 애플리케이션을 실행하기 위한 환경도 포함하고 있어요.

이러한 모든 것들은 Container image 내 File system에 존재해요.

• 가끔 Container image가 마법 같이 바로 애플리케이션을 실행시켜주는 단순 실행 프로그램으로 아시는 분들이 있어요. Container image는 애플리케이션과 그 실행에 필요한 모든 종속성을 포함하는 완전한 패키지예요. 오해하면 안 돼요.

 

Syft는 이걸 이용해요.

Container image 내 파일들을 스캔하고, 패키지 정보를 수집한 뒤 구조화된 SBOM 형태로 변환하여 사용자가 원하는 포맷으로 출력해요.

• 자세히는 Syft 내 Cataloger들이 stereoscope 라이브러리를 이용하여 image 내 파일들을 스캔하고 정보를 수집해요.
• 이에 대한 자세한 내용은 Syft Architecture를 참고해주세요.
• Syft는 binary 파일에 대해서도 분석을 수행해요 (Improving Syft's Binary Detection)

 

---

SBOM을 통해 보안취약점 분석하기

SBOM을 만들었다고 해볼까요? 그럼 보안 위험이 해결되는 걸까요?

당연히 아니에요. 이를 보고 이해하고 보안 위험 등 운영상의 문제가 있는 부분을 찾을 수 있는 툴이 필요해요.

 

생성된 SBOM을 이용하여 보안 취약점을 분석하는 툴들도 여러가지 존재해요.

이 글에서는 Grype을 이용하여 분석해볼게요.

GitHub - anchore/grype: A vulnerability scanner for container images and filesystems

• Grype는 Syft를 만든 anchore에서 만들었어요.
• 설치 방법은 Grype README를 참고해주세요.

 

사실 Syft를 이용하여 SBOM을 만들지 않아도 Grype 내부에서 Syft를 이용하고 있어 SBOM을 만들고 바로 분석까지 수행이 가능해요.

• ex) `grype tree9295/sbom-test-spring:0.0.1`

 

하지만 저희는 만들어 둔 SBOM을 이용해볼게요.

앞선 예제로 사용했던 sbom-test-spring 이미지는 Spring boot 3.2.1을 이용하고 있어요.

해당 라이브러리는 spring web 6.1.2 버전을 이용하고 있는데요. 이 버전에서는 High 등급 3개의 보안 취약점이 발견되었어요.

• Spring web 6.1.2 Vulnerabilities
• Spring Security Advisories List

 

만든 SBOM을 Grype에서 분석하여 위 보안취약점이 검출되는지 확인해볼게요.

$ grype syft.sbom.json
 ✔ Scanned for vulnerabilities     [12 vulnerability matches]
   ├── by severity: 0 critical, 6 high, 4 medium, 0 low, 0 negligible (2 unknown)
   └── by status:   12 fixed, 0 not-fixed, 0 ignored
NAME                    INSTALLED  FIXED-IN  TYPE          VULNERABILITY        SEVERITY
libcrypto3              3.3.2-r0   3.3.2-r1  apk           CVE-2024-9143        Unknown
libssl3                 3.3.2-r0   3.3.2-r1  apk           CVE-2024-9143        Unknown
...
spring-web              6.1.2      6.1.5     java-archive  GHSA-hgjh-9rj2-g67j  High
spring-web              6.1.2      6.1.4     java-archive  GHSA-ccgv-vj62-xf9h  High
spring-web              6.1.2      6.1.6     java-archive  GHSA-2wrp-6fg6-hmc5  High
spring-web              6.1.2      6.1.12    java-archive  GHSA-2rmj-mq67-h97g  Medium
...

위에서 보았던 것처럼 3개의 GHSA High 보안취약점이 확인되는 것을 볼 수 있어요.

• 예상하지 못했던 컨테이너에 포함된 다양한 다른 보안취약점까지 확인되는 것을 볼 수 있어요.
• GHSA는 Github에서 관리되는 보안 취약점 데이터베이스예요. CVE와 개념은 같은데, Github에 존재하는 프로젝트와 관련된 취약점에 초점을 맞춘 것이라고 이해하시면 돼요.

 

위 결과에서 알 수 있듯 단순 보안취약점 검출을 넘어

• 어떤 타입인지
• 어떤 Vulnerability인지
• 그리고 제일 중요한 어떤 버전에서 fix 되었는지

까지 다양한 정보를 보여줘요.

 

이렇게 분석된 결과를 바탕으로 보안 취약점 등 이슈를 보고하거나 수정해 나갈 수 있어요.

각 보안취약점을 무조건 수정해야한다는 것은 아니에요.
문제 발현조건들이 다 다를 수 있으니 위 리포트를 바탕으로 Vulnerability report를 보고 파악해보는 것이 중요해요.

 

---

파이프라인 구성하기

SBOM 생성과 분석이 포함된 파이프라인 구성은 인프라 구성상황에 따라 다르기에 여러 예시를 첨부하는 것으로 대신할게요.

 

예시) DevSecOps CI/CD

 

예시) Grype를 이용한 Github action pipeline 구성

 

예시) Syft SBOM, Sigstore 컨테이너 서명을 통한 SBOM 증명(attestation) 과정

 

---

결론

이렇게 SBOM을 만들고, SBOM을 분석하여 보안 취약점을 파악해보았어요.

이는 어떻게 활용될 수 있을까요?

CI/CD 및 정기적인 보안 프로세스에서 컨테이너 이미지에 대해 보안취약점, 부적격 라이센스 이용 등을 손쉽게 파악해볼 수 있을 거예요.

 

가끔 회사 공지 혹은 메일로 오는 것들을 생각해봐요. 'XXX 취약점으로 인한 버전 확인 요청', 'XXX 소프트웨어 라이센스 변경으로 인한 이용 확인 요청' 등 귀찮은 작업들이 수두룩 하지 않나요?

SBOM을 이용한다면 특정 버전을 사용하고 있는지도, 보안 취약점이 존재하는지도, 라이센스 문제가 있는지도 바로 파악이 가능할 거예요.

보안 부서 입장에서도, 플랫폼 운영 입장에서도, 소프트웨어를 직접 개발하는 개발자 입장에서도 아주 편리한 회사생활이 될 것 같네요 :-)

 

여기까지 긴 글 읽어주셔서 감사합니다.

 

 

---

부록 (끝내기는 아쉽지)

글을 작성하며, Spring boot를 주로 사용하는 개발자로서 "Spring boot에서는 SBOM 생성을 지원하는게 없을까?"를 중심으로 먼저 찾아보았었는데요.

이대로 간직하긴 아쉬워서 관련된 내용들은 부록으로나마 공유드릴게요.

 

Spring boot 3.3 actuator + CycloneDX plugin

SBOM support in Spring Boot 3.3

Spring boot 3.3부터는 actuator를 통해 SBOM을 출력하는 엔드포인트를 제공하도록 업데이트 되었어요.

이를 위해서는 아래와 같은 구성이 필요해요.

• CycloneDX plugin 추가 => id("org.cyclonedx.bom") version "1.8.2"
• Spring Web, Actuator 의존성 추가
• Actuator SBOM 활성화 및 노출 property 설정

 

위 설정을 완료한 뒤 `/actuator/sbom/application` endpoint에 접속하면

CycloneDX format의 SBOM이 노출된 것을 확인할 수 있어요.

 

이를 Grype를 통해 분석하고자 한다면, 아래와 같이 해볼 수 있어요.

$ curl http://{host}/actuator/sbom/application | grype

 

 

Cloud Native Buildpacks (CNB)

Spring boot에서는 CNB를 이용한 플러그인을 통해 손쉽게 Container image를 만들 수 있도록 지원하고 있어요.

• ex) `.gradlew bootBuildImage`
• 이와 관련되어 아래 문서들을 참고해보면 좋아요.
  • https://docs.spring.io/spring-boot/gradle-plugin/packaging-oci-image.html
  • https://docs.spring.io/spring-boot/reference/packaging/container-images/cloud-native-buildpacks.html
  • https://github.com/paketo-buildpacks/spring-boot
  • https://buildpacks.io/

 

이 때 CNB를 이용한 빌드 과정에서 syft가 사용되는 것을 볼 수 있어요.

$ ./gradlew bootBuildImage
...
    [creator]     paketo-buildpacks/syft              2.3.1
...
    [creator]     Paketo Buildpack for Syft 2.3.1
    [creator]       https://github.com/paketo-buildpacks/syft
...

 

 

Container Image를 확인해보면, `/layers/sbom/launch` 디렉토리 아래에 빌드 과정에서 만들어진 SBOM 목록이 존재하는 것을 볼 수 있어요.

$ find /layers/sbom/launch -name "*.json"
/layers/sbom/launch/buildpacksio_lifecycle/launcher/sbom.cdx.json
/layers/sbom/launch/buildpacksio_lifecycle/launcher/sbom.spdx.json
/layers/sbom/launch/buildpacksio_lifecycle/launcher/sbom.syft.json
/layers/sbom/launch/paketo-buildpacks_bellsoft-liberica/helper/sbom.syft.json
/layers/sbom/launch/paketo-buildpacks_bellsoft-liberica/jre/sbom.syft.json
/layers/sbom/launch/paketo-buildpacks_ca-certificates/helper/sbom.syft.json
/layers/sbom/launch/paketo-buildpacks_executable-jar/sbom.cdx.json
/layers/sbom/launch/paketo-buildpacks_executable-jar/sbom.syft.json
/layers/sbom/launch/paketo-buildpacks_spring-boot/helper/sbom.syft.json
/layers/sbom/launch/paketo-buildpacks_spring-boot/spring-cloud-bindings/sbom.syft.json
/layers/sbom/launch/sbom.legacy.json

 

• Buildpack을 이용해 빌드 과정에서 활용되는 라이브러리, 애플리케이션에서 사용되는 라이브러리 등 전체적으로 사용되는 모든 소프트웨어 구성요소를 SBOM로 구성해두고 있는 것을 볼 수 있어요.
• Paketo Buildpack 문서를 보면 이에 대해 더 자세히 설명하고 있어요.
  • Paketo buildpack - SBOM
  • Paketo buildpack - How to access the SBOM

 

Syft를 통해 해당 이미지를 분석해보면, 위 SBOM 파일들도 분석 대상에 포함되어 전체적인 하나의 SBOM 파일을 만들 것으로 예상돼요.