Skip to content

docs(server-delivery): model static-link as a blind spot, not a third layer #163

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
haksungjang merged 1 commit into from
Jun 17, 2026
Merged

docs(server-delivery): model static-link as a blind spot, not a third layer #163

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 7 additions & 6 deletions docs/guides/server-delivery.ko.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,15 +8,16 @@ description: 공급사가 납품 서버의 SBOM을 만드는 방법. OS rootfs,

납품 서버는 단일 소스 트리가 아닙니다. 운영체제가 있고, 그 위에 설치된 애플리케이션이 있으며, 빌드 과정에서 바이너리에 링크된 라이브러리가 있습니다. 이 중 하나만 스캔하면 나머지가 빠지고, 이것이 서버 SBOM이 반려되는 흔한 원인입니다.

이 가이드는 서버를 세 층으로 보고 각 층을 BomLens로 스캔합니다. 세 SBOM을 따로 제출하는 것이 기본이며, 그래야 각 층을 그 자체로 검토할 수 있습니다. 제출 시스템이 단일 파일을 요구할 때만 하나의 제품 SBOM으로 병합합니다([선택: 단일 SBOM으로 병합](#선택-단일-sbom으로-병합) 참고).
이 가이드는 서버를 두 층(OS와 애플리케이션)으로 보고 각 층을 BomLens로 스캔합니다. 층별 SBOM을 따로 제출하는 것이 기본이며, 그래야 각 층을 그 자체로 검토할 수 있습니다. 제출 시스템이 단일 파일을 요구할 때만 하나의 제품 SBOM으로 병합합니다([선택: 단일 SBOM으로 병합](#선택-단일-sbom으로-병합) 참고).

| 층 | 대상 | 누락 시 증상 |
|----|------|--------------|
| OS | 운영체제와 설치된 패키지 전체 (예: CentOS와 rpm 데이터베이스의 모든 패키지) | OS 취약점 누락 |
| 애플리케이션 | 납품 애플리케이션과 패키지 매니저 의존성(직접·전이) | 앱 의존성 누락 |
| 정적 링크 | 정적 링크되거나 수동으로 빌드된 라이브러리 (예: 정적 링크된 openssl, liblfds) | 가장 흔한 반려 원인 |

세 층 모두 BomLens 하나로 만듭니다. 층마다 입력만 바꾸면 됩니다. 요구사항은 세 층을 모두 도구로 생성하는 것이지, 하나의 파일로 합치는 것이 아닙니다.
두 층 외에, 정적 링크된 라이브러리(빌드 시 바이너리에 포함된 openssl·liblfds 등)는 사각지대입니다. 패키지 매니저가 선언하지 않고 OS 패키지 데이터베이스에도 올라 있지 않아 두 층의 스캔이 모두 놓칩니다. 따라서 별도로 탐지·기재해야 하며, 이를 빠뜨리는 것이 가장 흔한 반려 원인입니다. 아래 [정적 링크 라이브러리](#정적-링크-라이브러리--두-층의-사각지대)를 참고하세요.

두 층 모두 BomLens 하나로 만듭니다. 층마다 입력만 바꾸면 됩니다. 요구사항은 OS·애플리케이션·정적 링크 라이브러리를 모두 빠짐없이 담는 것이지, 하나의 파일로 합치는 것이 아닙니다.

## 공통 준비

Expand Down Expand Up @@ -59,9 +60,9 @@ $SBOM --project mms-relay-app --version 2.0.0 --all --generate-only

빌드를 먼저 하세요. 빌드나 설치 전 상태에서 스캔하면 전이 의존성이 해석되지 않습니다. 매니페스트가 없는 순수 CMake/Make 애플리케이션은 컴포넌트 목록이 희소해지므로, `--deep-license`로 자체 소스의 라이선스를 보강합니다.

## 3층 — 정적 링크 의존성
## 정적 링크 라이브러리 — 두 층의 사각지대

소스 스캐너는 바이너리에 정적 링크된 라이브러리를 보지 못하며, 바로 이 지점이 이 층이 필요한 이유입니다. 완전 자동 경로가 없으므로 두 가지를 함께 씁니다.
소스 스캐너는 바이너리에 정적 링크된 라이브러리를 보지 못하고, OS 패키지 데이터베이스에도 올라 있지 않습니다. 이것이 두 층이 남기는 사각지대입니다. 완전 자동 경로가 없으므로 두 가지를 함께 씁니다.

도구가 찾을 수 있는 만큼은 납품 바이너리나 펌웨어 이미지를 분석해 잡습니다.

Expand All @@ -75,7 +76,7 @@ $SBOM --project mms-relay-bin --version 2.0.0 \

## 제출 전 층별 자가 검증

세 SBOM을 그대로 제출합니다. 합친 파일이 아니라 각 SBOM을 따로 확인해, 문제를 그 층에서 바로 잡습니다. 각 SBOM이 올바른 형식이고 컴포넌트가 실제 purl을 갖는지 봅니다.
층별 SBOM과 정적 링크 SBOM을 그대로 제출합니다. 합친 파일이 아니라 각 SBOM을 따로 확인해, 문제를 해당 위치에서 바로 잡습니다. 각 SBOM이 올바른 형식이고 컴포넌트가 실제 purl을 갖는지 봅니다.

```bash
for bom in mms-relay-os_6.10_bom.json mms-relay-app_2.0.0_bom.json mms-relay-bin_2.0.0_bom.json; do
Expand Down
13 changes: 7 additions & 6 deletions docs/guides/server-delivery.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,15 +8,16 @@ description: How a supplier builds an SBOM for a delivered server — scan the O

A delivered server is not a single source tree. It is an operating system, the application installed on top of it, and libraries that were linked into the binaries during the build. A scan of any one of these misses the others, which is the usual reason a server SBOM is rejected.

This guide treats a server as three layers and scans each one with BomLens. Submit the three SBOMs separately — that is the default, and it keeps each layer reviewable on its own. Merge them into one product SBOM only when a submission system asks for a single file (see [Optional: merge into one SBOM](#optional-merge-into-one-sbom)).
This guide treats a server as two layers — the OS and the application — and scans each with BomLens. Submit the layer SBOMs separately — that is the default, and it keeps each reviewable on its own. Merge them into one product SBOM only when a submission system asks for a single file (see [Optional: merge into one SBOM](#optional-merge-into-one-sbom)).

| Layer | What it covers | Symptom if omitted |
|-------|----------------|--------------------|
| OS | The OS and its installed packages (e.g. CentOS plus everything in the rpm database) | OS vulnerabilities missing |
| Application | The delivered application and its package-manager dependencies, direct and transitive | Application dependencies missing |
| Static-link | Libraries statically linked or built by hand (e.g. a statically linked openssl, liblfds) | The most common rejection cause |

One tool, BomLens, produces all three. Only the input changes per layer. The requirement is that all three layers are generated with a tool — not that they end up in one file.
Beyond the two layers, statically linked libraries (for example an openssl or liblfds built into the binary) are a blind spot. A package manager does not declare them and the OS package database does not list them, so neither layer's scan finds them. They have to be detected and recorded separately, and missing them is the most common rejection cause — see [Static-link libraries](#static-link-libraries-a-blind-spot-of-both-layers) below.

One tool, BomLens, produces both layers; only the input changes. The requirement is that the OS, the application, and the static-link libraries are all accounted for — not that they end up in one file.

## Common setup

Expand Down Expand Up @@ -59,9 +60,9 @@ $SBOM --project mms-relay-app --version 2.0.0 --all --generate-only

Build first. Scanning before the build or install leaves transitive dependencies unresolved. For a pure CMake/Make application with no manifest, the component list is sparse; add `--deep-license` to record the first-party source licenses.

## Layer 3 — Static-link dependencies
## Static-link libraries (a blind spot of both layers)

Source scanners do not see libraries that were statically linked into a binary, which is exactly where this layer matters. There is no fully automatic path, so combine two approaches.
Source scanners do not see libraries that were statically linked into a binary, and neither does the OS package database — this is the blind spot the two layers leave. There is no fully automatic path, so combine two approaches.

Analyze the delivered binary or firmware image to catch what tooling can find:

Expand All @@ -75,7 +76,7 @@ For what the scan still misses, record the source and version by hand from the b

## Verify each layer before submitting

Submit the three SBOMs as they are. Check each one — not a combined file — so a gap is caught in the layer it belongs to. Confirm it is well formed and that its components carry real purls.
Submit the per-layer SBOMs (and the static-link SBOM) as they are. Check each one — not a combined file — so a gap is caught where it belongs. Confirm it is well formed and that its components carry real purls.

```bash
for bom in mms-relay-os_6.10_bom.json mms-relay-app_2.0.0_bom.json mms-relay-bin_2.0.0_bom.json; do
Expand Down
Loading