[SEC-009][중급] 의존성과 SBOM으로 공급망 위험 줄이기 > IT 기술 공유

• 목록

[이번 수업]

프로그램은 직접 쓴 코드뿐 아니라 라이브러리, 빌드 도구, 컨테이너 이미지에 의존합니다. 소프트웨어 공급망의 위험을 이해하고 SBOM으로 구성요소와 관계를 기록하는 기초를 익힙니다.

[선수지식]

TOOL-003의 패키지 관리자·의존성과 DEVOPS-007의 아티팩트 관리를 먼저 알면 좋습니다. Python 3로 파일 하나를 실행할 수 있으면 됩니다.

[학습목표]

1. 직접 의존성과 전이 의존성을 구분합니다.
2. SBOM의 구성요소·버전·식별자·관계를 읽습니다.
3. 소스부터 배포까지 공급망 검증 지점을 설명합니다.

[핵심개념]

소프트웨어 공급망은 소스 코드, 의존성, 빌드, 패키지 저장소, 배포 결과물이 이어지는 흐름입니다. 내가 명시한 패키지는 직접 의존성이고, 그 패키지가 다시 사용하는 항목은 전이 의존성입니다. 이름이 비슷한 가짜 패키지, 탈취된 유지관리 계정, 변조된 빌드 결과, 오래된 취약 버전은 서로 다른 지점의 위험입니다.

SBOM(Software Bill of Materials)은 소프트웨어 자재 명세서, 즉 특정 제품 버전에 들어간 구성요소와 관계를 기계가 읽게 적은 목록입니다. 이름과 버전에 더해 공급자, 고유 식별자, 의존 관계, 작성 시점을 관리합니다. SPDX와 CycloneDX는 대표적인 공개 형식입니다. SBOM은 구성의 투명성을 높이지만 안전을 보증하거나 취약점을 자동 수정하지는 않습니다.

잠금 파일로 버전을 고정하고 공식 저장소와 허용 목록을 사용하며, 받은 아티팩트의 해시·서명·출처 정보를 검증합니다. 빌드는 격리 환경에서 최소 권한으로 수행하고 결과와 생성 과정을 연결하는 출처 증명도 보관합니다. 새 취약점은 나중에 공개되므로 보관한 SBOM을 계속 다시 대조합니다. 사용하지 않는 의존성은 제거하고 업데이트는 테스트 후 배포합니다.

[따라하기]

다음은 CycloneDX 1.7 형식의 작은 학습용 SBOM을 읽는 로컬 예제입니다. 패키지를 설치하거나 네트워크에 접속하지 않습니다. `sbom_check.py`로 저장합니다.

```python
sbom = {
    "bomFormat": "CycloneDX",
    "specVersion": "1.7",
    "version": 1,
    "metadata": {"component": {
        "type": "application", "name": "local-demo",
        "version": "1.0.0", "bom-ref": "app-local-demo",
    }},
    "components": [{
        "type": "library", "name": "sample-parser",
        "version": "1.2.3", "bom-ref": "lib-sample-parser",
    }],
    "dependencies": [{
        "ref": "app-local-demo",
        "dependsOn": ["lib-sample-parser"],
    }],
}

component = sbom["components"][0]
print("형식:", sbom["bomFormat"], sbom["specVersion"])
print("구성요소:", component["name"], component["version"])
print("고유 참조:", component["bom-ref"])
print("의존 대상:", sbom["dependencies"][0]["dependsOn"])
```

macOS·Linux는 `python3 sbom_check.py`, Windows PowerShell은 `py sbom_check.py`로 실행합니다. 예상 결과에는 `CycloneDX 1.7`, `sample-parser 1.2.3`, 고유 참조와 의존 대상 목록이 나옵니다. 구조 학습용 최소 자료이므로 실제 배포용 SBOM은 공식 도구로 만들고 스키마를 검증합니다.

[흔한 실수]

최상위 패키지만 적어 전이 의존성을 빠뜨리거나 여러 릴리스에 같은 SBOM을 붙이면 실제 구성과 어긋납니다. 버전을 고정했다고 안전한 것도 아닙니다. 취약점이 없다는 결과는 검사 시점과 데이터 범위에 한정됩니다. CVE 번호만 보고 결정하지 말고 포함 버전, 실행 경로, 수정 버전, 호환성, 완화책을 함께 확인합니다.

[보안 주의]

출처가 불분명한 패키지를 확인 목적으로 설치하지 말고 격리된 검사 환경을 씁니다. 빌드·저장소 토큰은 읽기와 배포 권한을 분리하고 로그나 SBOM에 넣지 않습니다. 서명 키는 일반 빌드 환경과 분리해 보호하고 검증 실패를 경고만 남긴 채 통과시키지 않습니다. SBOM 공개 범위는 투명성과 내부 구조 노출을 함께 검토합니다. 모든 활동은 본인 소유 코드나 허가된 환경의 방어 점검으로 제한합니다.

[직접 해볼 과제]

예제에 `sample-parser`가 의존하는 `sample-codec`을 추가하세요. 버전과 고유 참조를 넣고 dependencies에서 직접·전이 관계가 구분되도록 출력합니다.

[확인문제]

1. 직접 의존성과 전이 의존성은 어떻게 다른가요?
2. SBOM이 있어도 안전을 자동으로 보장하지 못하는 이유는 무엇인가요?
3. 배포 뒤에도 SBOM을 새 취약점 정보와 다시 대조해야 하는 이유는 무엇인가요?

[다음 학습]

SEC-010에서는 코드·의존성·실행 환경을 대상으로 보안 테스트와 취약점 관리 흐름을 설계합니다.

[공식 참고 자료]

- NIST SSDF 1.1: https://csrc.nist.gov/pubs/sp/800/218/final
- CISA 2025 SBOM 최소 요소: https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf
- SPDX 3.0.1 공식 사양: https://spdx.github.io/spdx-spec/
- CycloneDX 1.7 사양 개요: https://cyclonedx.org/specification/overview/
- SLSA 1.2 공급망 사양: https://slsa.dev/spec/v1.2/