스물다섯 개를 손으로 세어 SBOM 으로 적는다

목표

잠금 파일 하나에서 '무엇이 들어 있는가' 를 직접 세어 CycloneDX 형식의 SBOM 으로
적고, 아무도 고르지 않은 패키지가 어느 경로로 들어왔는지 추적합니다.

왜 중요한가

사고가 난 뒤 가장 먼저 오는 질문은 "우리 그거 쓰나요" 입니다. 이 질문에 몇 시간
안에 답하지 못하는 조직은, 답이 '아니오' 여도 며칠을 태웁니다. 답을 빨리 내는
방법은 사고 뒤에 찾는 것이 아니라 릴리스마다 목록을 함께 만들어 두는 것입니다.
그런데 목록의 대부분은 우리가 고른 것이 아닙니다 — 직접 적은 의존 일곱 개가
스물다섯 개를 끌고 옵니다. 그 스물다섯 개가 실제로 배포에 실리는지, 빌드에만
쓰이는지도 갈라야 합니다. 고칠 목록과 급한 목록은 다른 목록이기 때문입니다.

단계

1. /opt/fixtures/sbom/release/package.json 에서 직접 의존을 뽑아 /root/sbom/01-direct.json 에 씁니다.
2. /opt/fixtures/sbom/release/package-lock.json 에서 설치된 전부를 세어 /root/sbom/02-installed.json 에 씁니다.
3. 운영과 개발 전용을 갈라 /root/sbom/03-scope.json 에 씁니다.
4. sock-ttl 이 어떤 경로로 들어왔는지 추적해 /root/sbom/04-why.json 에 씁니다.
5. CycloneDX 1.6 형식으로 /root/sbom/05-bom.json 을 만듭니다.
6. 산출물의 다이제스트를 /root/sbom/06-subject.json 에 못박습니다.
7. 배포에 실리는 것만 남겨 /root/sbom/07-runtime-bom.json 을 만듭니다.
8. 지난 릴리스와 견주어 /root/sbom/08-diff.json 을 만듭니다.

참고

• 작업은 전부 /root/sbom 아래에서 합니다. 먼저 mkdir -p /root/sbom 를 하세요.
• 재료는 /opt/fixtures/sbom 에 있습니다. 무엇이 왜 있는지는 MATERIAL-CARD.md 에 적어 두었습니다.
• 패키지 이름과 권고 번호는 실습용으로 지어낸 것입니다. 실제 패키지의 사정이 아닙니다.
• 이 이미지에는 syft 나 grype 가 없고 파드는 DNS 만 열려 있습니다. 잠금 파일을 직접

읽는 것이 이 실습의 방식이고, 그래야 도구가 무엇을 건너뛰는지도 보입니다.

• 흔한 실수 — 잠금 파일의 루트 항목(빈 문자열 키)을 함께 세어 개수가 하나 많아지는 것,

그리고 dev 플래그가 없는 항목을 개발 전용으로 잘못 세는 것입니다.

• 숫자를 지어 쓰지 마세요. 채점기가 같은 재료에서 다시 계산해 대조합니다.

단계 8개

1. 우리가 직접 고른 것부터 센다
2. 실제로 설치된 것을 센다
3. 배포에 실리는 것과 빌드에만 쓰는 것을 가른다
4. 아무도 고르지 않은 패키지가 어떻게 들어왔는지 추적한다
5. CycloneDX 형식으로 목록을 적는다
6. 목록이 어느 산출물의 것인지 못박는다
7. 배포 산출물에 실리는 것만 남긴다
8. 지난 릴리스와 무엇이 달라졌는지 센다