Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 770 – 소프트웨어 자재 명세서(Software Bill-of-Materials)를 통한 Python 패키지의 측정 가능성 개선

Author:
Seth Larson <seth at python.org>
Sponsor:
Brett Cannon <brett at python.org>
PEP-Delegate:
Brett Cannon <brett at python.org>
Discussions-To:
Discourse thread
Status:
Final
Type:
Standards Track
Topic:
Packaging
Created:
02-Jan-2025
Post-History:
05-Nov-2024, 06-Jan-2025
Resolution:
11-Apr-2025
Table of Contents

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

Important

This PEP is a historical document. The up-to-date, canonical spec, The .dist-info/sboms/ directory, is maintained on the PyPA specs page.

×

See the PyPA specification update process for how to propose changes.

초록

오늘날 거의 모든 Python 패키지는 소프트웨어 구성 분석(SCA) 도구로 정확하게 측정할 수 있습니다. 정확하게 측정할 수 없는 프로젝트의 경우, 측정 가능성을 개선하기 위해 Python 패키지에 구성 데이터를 주석으로 추가할 수 있는 기존 메커니즘이 없습니다.

소프트웨어 자재 명세서(Software Bill-of-Materials, SBOM)는 소프트웨어의 구성, 출처, 계보 등을 기술하는 방법으로, 특정 기술이나 생태계에 종속되지 않습니다. SBOM은 취약점 스캐너나 라이선스 스캐너 같은 SCA 도구의 입력으로 사용되며, 전 세계의 소프트웨어 규제와 프레임워크에서 점점 더 주목받고 있습니다.

이 PEP는 Python 패키지의 자동화된 소프트웨어 측정 가능성을 개선하는 수단으로 Python 패키지에 포함된 SBOM 문서를 사용할 것을 제안합니다.

동기

측정 가능성과 유령 의존성

Python 패키지는 “phantom dependency” 문제의 영향을 특히 크게 받습니다. 이 문제는 설치 용이성, 표준 호환성 등 여러 이유로 Python으로 작성되지 않은 소프트웨어 구성 요소가 Python 패키지에 포함되면서 생깁니다:

  • Python은 Rust, C, C++, Fortran, JavaScript 등 컴파일 언어나 Python이 아닌 언어를 사용하는 과학, 데이터, 웹, 머신 러닝 분야의 사용 사례를 지원합니다.
  • 사용자들은 설치가 쉽다는 이유로 Python wheel 형식을 선호합니다. 설치 단계에서는 어떤 코드도 실행되지 않으며, 아카이브의 압축을 푸는 작업만 수행됩니다.
  • Python wheel 형식은 공유 컴파일 라이브러리를 번들로 포함하도록 요구하지만, 이러한 라이브러리에 대한 메타데이터를 기록할 방법은 제공하지 않습니다.
  • Python 패키징과 관련된 패키지는 때때로 “부트스트래핑” 문제를 해결해야 하므로, 소스 코드 안에 순수 Python 프로젝트를 포함합니다.

이러한 소프트웨어 구성 요소는 Python 패키지 메타데이터로 기술할 수 없으므로 소프트웨어 구성 분석(SCA) 소프트웨어가 놓칠 가능성이 높으며, 이는 취약한 소프트웨어 구성 요소가 정확하게 보고되지 않을 수 있음을 의미합니다.

예를 들어, Python 패키지 Pillow의 wheel에는 빌드 과정에서 auditwheel이 번들로 포함한 공유 객체 라이브러리 16개가 들어 있습니다. Syft나 Grype 같은 일반적인 SCA 도구를 사용하면 이 공유 객체 라이브러리 중 어느 것도 탐지되지 않습니다. 포함된 모든 공유 라이브러리를 주석으로 기술한 SBOM 문서가 함께 포함되어 있다면, SCA 도구는 포함된 소프트웨어를 안정적으로 식별할 수 있습니다.

빌드 도구, 환경, 재현성

패키지의 런타임 의존성을 넘어, SBOM은 패키지를 빌드하는 데 사용된 도구와 환경도 기록할 수 있습니다. 빌드 재현성을 확보하려면 패키지를 빌드하는 데 사용된 정확한 도구와 버전을 기록해야 하는 경우가 많습니다. 빌드 재현성은 소프트웨어의 속성으로, 업스트림 소스와 비교하여 잘못 수정되었거나 악의적으로 수정된 소프트웨어 구성 요소를 탐지하는 데 사용할 수 있습니다. 빌드 도구와 버전의 목록이 기록되어 있지 않으면, 제3자가 빌드 재현성을 검증하기가 어렵거나 불가능해질 수 있습니다.

규제

SBOM은 Secure Software Development Framework (SSDF)와 Cyber Resilience Act (CRA) 같은 최근의 소프트웨어 보안 규제에서 요구됩니다. SBOM이 이러한 규제에 포함되었으므로 오픈 소스 프로젝트의 SBOM 문서에 대한 수요가 높을 것으로 예상됩니다. 한 가지 목표는 SBOM이 필요한 오픈 소스 사용자가 기존 도구를 사용해 스스로 해결할 수 있도록 하여 오픈 소스 프로젝트 유지 관리자에게 가해지는 요구를 최소화하는 것입니다.

또 다른 목표는 SBOM이 필요한 사용자가 자신이 의존하는 프로젝트에 SBOM 정보를 주석으로 추가하는 기여를 할 수 있도록 하는 것입니다. 현재는 Python 패키지에 대해 이러한 기여의 결과를 전파할 메커니즘이 없으므로, 사용자가 이런 종류의 작업에 기여할 동기가 없습니다.

근거

코어 메타데이터 필드 대신 SBOM 표준 사용하기

SBOM 표준이 제공하는 모든 필드를 Python 패키지 코어 메타데이터에 추가하려고 하면 새로운 코어 메타데이터 필드가 폭발적으로 늘어날 것이며, SBOM 표준이 해당 분야의 새로운 요구에 맞춰 계속 발전함에 따라 이를 최신 상태로 유지해야 하는 부담도 생깁니다.

대신 이 제안은 SBOM 고유의 메타데이터를 SBOM 문서에 위임하며, 이 문서는 Python 패키지 안의 dist-info 아래에 있는 이름이 지정된 디렉터리에 포함됩니다.

또한 이 표준은 코어 메타데이터를 SBOM으로 대체하는 것을 목표로 하지 않으며, 대신 SBOM 정보가 코어 메타데이터를 보완하는 데 초점을 맞춥니다. 포함된 SBOM에는 패키지 아카이브에 포함된 의존성에 대한 정보, 또는 코어 메타데이터로 인코딩할 수 없지만 SBOM 사용 사례와 관련이 있는 패키지 내 최상위 소프트웨어에 대한 정보(“소프트웨어 식별자”, “목적”, “지원 수준” 등)만 들어 있습니다.

0개 이상의 불투명한 SBOM 문서

이 PEP는 Python 패키지당 포함되는 SBOM 문서를 최대 하나로 제한하는 대신, Python 패키지에 하나 이상의 SBOM 문서를 포함할 수 있도록 제안합니다. 따라서 Python 패키지에 SBOM 데이터를 덧붙이려는 코드는 다른 SBOM 문서에 이미 담긴 데이터를 손상시킬 걱정 없이 그렇게 할 수 있습니다.

또한 이 PEP는 SBOM 문서 데이터를 불투명하게 취급하며, 담긴 SBOM 데이터의 처리는 SBOM 데이터의 최종 사용자에게 맡깁니다. 이 선택은 SBOM 표준이 활발히 개발되고 있는 분야로서 아직 단일한 결정적 SBOM 표준이 없고(앞으로도 없을 수 있으며), SBOM 표준이 Python 패키징 표준과 독립적으로 계속 발전할 수 있다는 점을 인정한 것입니다. SBOM 문서를 소비하는 도구들은 이러한 현실에 대응하기 위해 이미 다양한 SBOM 표준을 지원합니다.

이러한 결정에 따라 이 PEP는 어떤 SBOM 표준이든 지원할 수 있고 특정 표준을 다른 표준보다 우대하지 않으며, 그 결정은 SBOM을 생성하는 프로젝트와 도구, 그리고 이를 소비하는 사용자 도구에 맡깁니다.

새 메타데이터 버전 없이 Python 패키지에 데이터 추가하기

새로운 메타데이터 버전과 필드를 도입하려면 광범위한 장애를 피하기 위해 여러 프로젝트와 팀이 순서대로 해당 메타데이터 버전을 채택해야 합니다. 이 때문에 사용자와 도구가 새로운 패키징 기능을 사용하기 시작하기까지 대개 상당한 지연이 발생합니다.

예를 들어, 메타데이터 버전을 한 번 올리려면 PyPI, 여러 pyproject.toml 파싱 및 스키마 프로젝트, packaging 라이브러리를 업데이트하고 릴리스를 기다려야 하며, 그다음 pip와 다른 설치 프로그램이 packaging의 변경 사항을 번들링하여 릴리스해야 하고, 그 후에야 빌드 백엔드가 새 메타데이터 버전을 내보내기 시작할 수 있으며, 다시 릴리스를 기다린 뒤에야 비로소 프로젝트가 새 기능을 사용하기 시작할 수 있습니다. 이처럼 신중하게 접근하더라도 도구가 새 메타데이터 버전과 필드에서 고장 나지 않는다고 보장할 수는 없습니다.

이러한 지연을 피하고, SBOM을 포함하는 방법을 전반적으로 단순화하며, 빌드 백엔드와 도구에 유연성을 주기 위해, 이 PEP는 .dist-info 아래의 하위 디렉터리를 사용하여 새 메타데이터 필드와 버전 없이도 Python 패키지에 데이터를 안전하게 추가하는 방식을 제안합니다. 이 메커니즘을 통해 빌드 백엔드와 도구는 다른 프로젝트의 PEP 채택을 기다리는 선두 차단(head-of-line blocking) 없이, 승인 직후부터 이 PEP에 설명된 기능을 사용하기 시작할 수 있습니다.

.dist-info 또는 .data 디렉터리에 파일 저장하기

바이너리 배포판에서 소프트웨어 자체 이외의 파일을 저장할 수 있는 최상위 디렉터리는 .dist-info와 .data 두 가지입니다. 이 명세는 하위 디렉터리와 파일을 저장하는 데 .dist-info 디렉터리를 사용하기로 했습니다.

첫째, .dist-info는 바이너리 배포판과 환경에 설치된 패키지 사이의 연결을 유지하는 반면, .data 디렉터리는 설치된 패키지 안에 대응하는 위치가 없습니다. 대신 .data 디렉터리의 모든 내용은 환경에 설치된 모든 패키지 사이에서 병합되므로, 이름이 비슷한 파일끼리 충돌이 발생할 수 있습니다.

둘째, .data 디렉터리 아래의 하위 디렉터리를 사용하려면 Python sysconfig 모듈에 새로운 정의를 추가해야 합니다. 즉, 추가 디렉터리를 정의하려면 Python의 변경을 기다려야 하고, 그 디렉터리를 사용하려면 사용자가 새 Python 버전을 채택하기를 기다려야 합니다. .dist-info 아래의 하위 디렉터리에는 이러한 요구 사항이 없으며, 새 하위 디렉터리 이름이 등록되면 Python 버전이나 메타데이터 버전과 관계없이 모든 사용자, 빌드 백엔드, 설치 프로그램이 즉시 사용할 수 있습니다.

PEP 770과 PEP 725의 차이점은 무엇입니까?

PEP 725 (“pyproject.toml에서 외부 의존성 지정하기”)는 PEP 770과 다른 PEP이지만, Python 패키징 메타데이터 안에서 Python이 아닌 소프트웨어를 기술하려 한다는 점 등 몇 가지 유사점이 있습니다. 이 절에서는 두 PEP가 어떻게 서로 다른 정보를 추적하고 서로 다른 사용 사례에 기여하는지 보여 드리고자 합니다:

  • PEP 725는 “C 컴파일러”를 빌드 시점 의존성으로 요구하거나(virtual:compiler/c) 빌드 시점에 “OpenSSL 라이브러리”를 링크해야 하는 것(pkg:generic/openssl)과 같은 추상 의존성을 기술합니다. PEP 770은 AlmaLinux 배포판을 통해 배포되는 소프트웨어 라이브러리의 정확한 이름, 버전, 아키텍처, 해시(pkg:rpm/almalinux/libssl3@3.2.0)와 같이 “잠금 파일(lock file)”의 의존성에 더 가까운 구체적 의존성을 기술합니다. 빌드 의존성 같은 경우에는 PEP 725를 통해 의존성이 요청된 다음, 빌드 후 PEP 770에 따라 SBOM에 구체적으로 기록될 수 있습니다.
  • PEP 725는 소프트웨어를 빌드하거나 실행하는 데 사용되는 시스템이 제공하는 외부 의존성을 기술하기 위한 것입니다. PEP 770은 Python 패키지 아카이브 내부에 번들된 소프트웨어를 기술하기 위한 것이며, SBOM 문서는 시스템에 있는 소프트웨어를 기술하지 않습니다.
  • PEP 725는 주로 식별에 관한 것으로, 소프트웨어 식별자 목록을 사용합니다. PEP 770은 라이선스, 체크섬, 다운로드 위치 등 다양한 소프트웨어 속성을 기술하기 위해 SBOM 표준의 완전한 기능을 제공합니다.
  • PEP 725와 PEP 770은 사용자와 사용 사례가 서로 다릅니다. PEP 725는 주로 pyproject.toml에 의존성을 직접 작성하는 사람을 위한 것입니다. 이 정보를 사용하는 쪽은 빌드 백엔드, 그리고 소스에서 소프트웨어를 빌드하려는 사용자입니다. PEP 770은 주로 Python 패키지 아카이브에 포함할 SBOM 문서를 생성할 수 있는 도구와, 취약점 스캔이나 소프트웨어 분석 같은 다른 작업을 수행하기 위해 설치된 소프트웨어에 관한 SBOM 문서를 사용하려는 SBOM/SCA 도구를 위한 것입니다.

명세

이 PEP를 구현하는 데 필요한 변경 사항은 다음과 같습니다:

  • .dist-info/sboms 하위 디렉터리를 명시적으로 예약합니다.
  • 빌드된 배포판(휠) 및 설치된 프로젝트 명세에 대한 추가 사항

위 내용에 더해, 포함된 SBOM 문서와 기타 Python 패키지 메타데이터를 사용하여 Python 패키지에 대한 완전한 SBOM 문서를 생성하는 도구를 위한 정보성 PEP가 작성될 것입니다.

.dist-info/sboms 디렉터리 예약

이 PEP는 distribution archive 및 installed project 프로젝트 유형의 .dist-info 디렉터리에서 허용되는 예약된 하위 디렉터리 이름의 새 레지스트리를 도입합니다. 이 레지스트리에 대한 향후 추가는 PEP 절차를 통해 이루어집니다. 이 레지스트리의 초깃값은 다음과 같습니다:

하위 디렉터리 이름 PEP / 표준
licenses PEP 639
license_files PEP 639 (초안 전용)
LICENSES REUSE 라이선스 프레임워크
sboms PEP 770

이 디렉터리 이름을 선택하면서 하위 호환성 문제를 피하기 위한 전체 방법론은 하위 호환성을 참조하십시오.

프로젝트 형식의 SBOM 파일

기존 명세에 몇 가지 내용이 추가됩니다.

빌드된 배포판 (휠)
휠 명세는 예약된 디렉터리 이름의 새 레지스트리를 추가하고, .dist-info/sboms 하위 디렉터리가 지정된 경우 해당 디렉터리에 SBOM 파일이 들어 있음을 반영하도록 갱신됩니다.
설치된 프로젝트
설치된 프로젝트 기록(Recording Installed Projects) 명세는 .dist-info/sboms 하위 디렉터리가 지정된 경우 해당 디렉터리에 SBOM 파일이 들어 있으며, 이 디렉터리의 모든 파일은 설치 도구가 휠에서 반드시 복사해야 한다(MUST)는 내용을 반영하도록 갱신될 것입니다.

SBOM 데이터 상호 운용성

이 PEP는 SBOM 표준이 활발히 개발되고 있는 분야임을 인정하여, SBOM 문서에 포함된 데이터를 불투명한(opaque) 것으로 취급합니다. 그러나 SBOM 데이터 생성자가 고려해야 할 몇 가지 사항이 있으며, 이를 따르면 Python 패키지에서 제공되는 SBOM 데이터의 상호 운용성과 사용성이 향상됩니다:

  • SBOM 문서는 CycloneDX 또는 SPDX와 같이 널리 받아들여지는 SBOM 표준을 사용하는 것이 좋습니다(SHOULD).
  • SBOM 문서는 사용 중인 SBOM 표준에서 지원하는 경우 UTF-8로 인코딩된 JSON(RFC 8259)을 사용하는 것이 좋습니다(SHOULD).
  • SBOM 문서는 사용 중인 SBOM 표준의 모든 필수 필드를 포함하는 것이 좋습니다(SHOULD).
  • SBOM 문서는 사용 중인 SBOM 표준의 “생성 시각” 및 “생성 도구” 필드를 포함하는 것이 좋습니다(SHOULD). 이 정보는 빌드되는 Python 패키지의 여러 단계를 재구성하려는 사용자에게 중요합니다.
  • SBOM 문서가 기술하는 주요 구성 요소는 Python 패키지 내의 최상위 소프트웨어여야 합니다(SHOULD)(예를 들어, Pillow 패키지의 경우 “pkg:pypi/pillow”).
  • 주 구성 요소가 아닌 모든 구성 요소는 관계 그래프에서 구성 요소 간의 관계를 보여 주는 경로를 하나 이상 가지는 것이 좋습니다(SHOULD). 이 정보가 포함되지 않으면 SCA 도구가 관계 그래프 밖에 있는 구성 요소를 제외할 수 있습니다.
  • 모든 소프트웨어 구성 요소는 이름, 버전 및 하나 이상의 소프트웨어 식별자(PURL, CPE, 다운로드 URL)를 가지는 것이 좋습니다(SHOULD).

PyPI 및 기타 패키지 색인은 이 PEP가 명시하는 SBOM 문서의 내용을 검증할 수 있지만(MAY), 알 수 없는 SBOM 표준, 버전 또는 필드에 대한 데이터를 검증하거나 거부해서는 안 됩니다(MUST NOT).

하위 호환성

예약된 .dist-info/sboms 하위 디렉터리

새로 예약된 .dist-info/sboms 하위 디렉터리는 이전에 문서화되지 않았던 새로운 예약이므로, 기존 도구들이 전제하고 있는 가정을 깨뜨릴 가능성이 있습니다.

현재 어떤 .dist-info 하위 디렉터리 이름이 사용되고 있는지 확인하기 위해 PyPI의 패키지 아카이브에 있는 모든 파일을 대상으로 쿼리를 실행했습니다:

SELECT (
  regexp_extract(archive_path, '.*\.dist-info/([^/]+)/', 1) AS dirname,
  COUNT(DISTINCT project_name) AS projects
)
FROM '*.parquet'
WHERE archive_path LIKE '%.dist-info/%/%'
GROUP BY dirname ORDER BY projects DESC;

이 쿼리는 파일에 대한 레코드만 포함하므로 빈 디렉터리에 대한 결과는 반환하지 않는다는 점에 유의하십시오. 빈 디렉터리가 널리 사용되면서 어떤 식으로든 중요한 역할을 하고 있을 가능성은 낮으므로, 이는 이 방법을 사용할 때 감수하는 위험으로 받아들여집니다. 이 쿼리의 결과는 다음과 같습니다:

하위 디렉터리 고유 프로젝트 수
licenses 22,026
license_files 1,828
LICENSES 170
.ipynb_checkpoints 85
license 18
.wex 9
dist 8
include 6
build 5
tmp 4
src 3
calmjs_artifacts 3
.idea 2

위에 표시하지 않았지만, 단일 프로젝트에서만 사용되는 다른 하위 디렉터리 이름이 약 50개 더 있습니다. 이 결과로부터 다음을 알 수 있습니다:

  • .dist-info 아래의 하위 디렉터리 대부분은 라이선스와 관련된 것으로, 그중 하나(licenses)는 PEP 639에서 명시한 것이고 나머지(license_files, LICENSES)는 PEP 639의 초안 구현에서 비롯된 것입니다.
  • sboms 하위 디렉터리는 기존 용례와 충돌하지 않습니다.
  • .dist-info 아래의 다른 하위 디렉터리 이름은 널리 쓰이지 않거나 실수로 생긴 것으로 보입니다.

이 쿼리 결과로 이미 일부 프로젝트가 .dist-info 아래에 디렉터리를 두고 있음을 알 수 있으므로, 빌드 프런트엔드가 등록되지 않은 하위 디렉터리에 대해 오류를 발생시키도록 요구할 수는 없습니다. 대신 이러한 상황에서 빌드 프런트엔드가 사용자에게 경고하거나 오류를 발생시킬 수 있다(MAY)고 권장합니다.

보안 영향

SBOM 문서는 그 안에 인코딩된 정보만큼만 유용합니다. SBOM 문서에 잘못된 정보가 포함되어 있으면 SCA 도구가 하위 단계에서 잘못된 분석을 수행할 수 있습니다. 이러한 이유로 Python 패키지에 SBOM 데이터를 포함하는 도구는 자신이 기록하는 정보를 확신할 수 있어야 합니다. SBOM은 알려진 데이터뿐만 아니라 “알려진 미지(known unknowns)”도 기록할 수 있습니다. 기록하는 데이터가 확실하지 않을 때는 사용자가 추가로 분석할 수 있도록 이 방식을 사용할 것을 권장합니다.

SBOM 문서는 Python 패키지가 빌드된 원래 시스템에 대한 정보(예를 들어 운영 체제 이름과 버전, 드물게는 경로 이름)를 담을 수 있기 때문입니다. 이 정보는 SBOM을 통해 Python 패키지에서 설치 프로그램으로 “유출”될 가능성이 있습니다. 이 정보가 민감한 정보라면 보안 위험이 될 수 있습니다.

교육 방법

Python과 Python 패키지의 일반적인 사용자는 대부분 이 표준의 세부 사항을 알 필요가 없습니다. 이 표준의 세부 사항은 Python 패키지 유지 관리자, 그리고 SBOM 생성 도구나 취약점 스캐너 같은 SCA 도구 개발자에게 가장 중요합니다.

Python 패키지 유지 관리자는 무엇을 알아야 합니까?

Python 패키지 메타데이터는 이미 패키지 아카이브에 포함된 최상위 소프트웨어를 기술할 수 있지만, 패키지 아카이브에 최상위 소프트웨어 외의 다른 소프트웨어 구성 요소가 들어 있다면 어떻게 해야 합니까? 예를 들어 “Pillow”의 Python 휠에는 libjpeg, libpng, libwebp 등 몇 가지 다른 소프트웨어 라이브러리가 번들로 포함되어 있습니다. 이 PEP는 바로 이러한 상황, 즉 번들된 소프트웨어에 관한 메타데이터를 Python 패키지에 추가할 때 가장 유용합니다.

일부 빌드 도구는 번들된 의존성에 자동으로 주석을 달 수 있습니다. 일반적으로 도구는 번들된 의존성이 “패키징 생태계”(PyPI, Linux 배포판, Crates.io, NPM 등)에서 온 경우 해당 의존성에 자동으로 주석을 달 수 있습니다.

SBOM 도구 작성자는 무엇을 알아야 합니까?

SBOM 생성 도구 개발자는 이 PEP가 존재한다는 사실과 Python 패키지가 패키지 아카이브 안에 SBOM 문서를 게시하기 시작할 수 있다는 사실을 알아야 합니다. 특정 Python 패키지나 Python 환경에 대한 SBOM 문서를 생성할 때 이 정보를 포함해야 합니다.

이 PEP에서 설명하는 메커니즘을 포함한 Python 패키징 메타데이터를 Python 패키지를 기술하는 SBOM 문서로 변환하는 방법을 설명하는 후속 정보성 PEP가 작성될 예정입니다. 정보성 PEP가 완성되면 SBOM 도구의 PEP 770 도입을 촉진하기 위해 해당 정보성 PEP를 명시적으로 연결한 추적 이슈를 열 예정입니다.

다양한 Python 패키징 입력(패키지 아카이브, 설치된 패키지, 환경, 컨테이너 이미지)으로 실행했을 때 여러 SBOM 도구의 출력을 비교하여 여러 SBOM 생성 도구의 진행 상황을 추적하기 위한 벤치마크를 만들고 있습니다. 이 벤치마크를 통해 도구가 이 PEP와 Python 패키지를 지원하는 데 어떤 부분이 부족한지 알 수 있을 것입니다.

SBOM 문서 사용자는 무엇을 알아야 합니까?

이 PEP의 사용자 중 상당수는 이 PEP의 존재를 모를 것이며, 대신 사용하는 소프트웨어 구성 분석 도구, SBOM 도구, 취약점 스캐너가 업그레이드 후 더 포괄적인 정보를 제공하기 시작할 뿐입니다. 이 새로운 정보의 출처에 관심이 있는 사용자를 위해 SBOM 메타데이터의 “tool” 필드가 이미 SBOM을 생성하는 프로젝트로의 연결을 제공합니다.

자신의 오픈 소스 의존성을 기술하는 SBOM 문서가 필요한 사용자에게 첫 단계는 항상 “직접 만드는 것”이어야 합니다. 위의 벤치마크를 활용하면 Python 패키지에 대해 정확하다고 알려진 도구 목록을 문서화하여 사용자에게 추천할 수 있습니다. 추가로 수동 SBOM 어노테이션이 필요한 프로젝트의 경우, 이 데이터를 기여하기 위한 팁과 데이터를 유지 관리하기 위한 도구를 권장할 수 있습니다.

의존성, Python 버전, 플랫폼, 아키텍처 등의 차이로 인해 SBOM 문서는 Python 패키지 아카이브마다 다를 수 있다는 점에 유의하십시오. 이러한 이유로 사용자는 실제로 내려받아 설치한 Python 패키지 아카이브에 포함된 SBOM 문서만 사용해야 하며(SHOULD), 특정 패키지 릴리스의 모든 아카이브에서 SBOM 문서가 같다고 가정해서는 안 됩니다.

참조 구현

번들된 공유 라이브러리 파일을 기술하는 CycloneDX SBOM 문서를 생성하여 휠에 포함하는 Auditwheel 포크입니다. 이 SBOM 문서는 Syft SBOM 도구와 Grype 취약점 스캐너에서 기대한 대로 동작했습니다.

기각된 아이디어

단일 SBOM 표준 요구

보편적으로 받아들여지는 SBOM 표준은 없으며, 이 분야는 여전히 빠르게 발전하고 있습니다(예를 들어 SPDX는 2024년 4월에 표준의 새 메이저 버전을 발표했습니다). 오늘날 SBOM에 관한 논의와 개발은 대부분 CycloneDX와 SPDX라는 두 가지 SBOM 표준에 집중되어 있습니다.

확실한 승자가 나타나기 전에 Python 생태계를 특정 표준에 묶어 두지 않기 위해, 이 PEP는 SBOM 문서를 불투명한 것으로 취급하며 SBOM 문서 데이터를 사용하는 다운스트림 소비자와의 호환성을 높이기 위한 권고만 제시합니다.

이 PEP의 어떤 결정도 향후 PEP가 단일 SBOM 표준을 선택하는 것을 제한하지 않습니다. 오늘날 SBOM 데이터를 사용하는 도구는 이러한 상황에 대응하기 위해 이미 여러 형식을 지원해야 하므로, 향후 표준이 단 하나의 표준만 요구하도록 갱신되더라도 다운스트림 SBOM 도구에는 아무런 영향을 주지 않을 것입니다.

메타데이터 필드를 사용하여 아카이브 내 SBOM 파일 지정하기

이 명세의 이전 버전에서는 Sbom-File 메타데이터 필드를 사용하여 소스 또는 바이너리 배포 아카이브 내의 SBOM 파일을 지정했습니다. 이렇게 하면 License-File 필드를 사용하여 아카이브 내 라이선스 파일을 열거하는 PEP 639와 구현이 비슷해집니다.

이 접근 방식의 주요 문제는 SBOM 파일이 정적 출처와 동적 출처 모두에서 나올 수 있다는 점입니다. 예를 들어 버전 관리되는 소스 코드, 빌드 백엔드, 또는 빌드가 완료된 후 SBOM 파일을 추가하는 도구(auditwheel 등)에서 나올 수 있습니다.

메타데이터 필드는 정적이거나 동적이어야 하며, 둘 다일 수는 없습니다. 이는 SBOM 데이터에 대한 최선의 시나리오, 즉 Python 패키지를 빌드하는 동안 사용자의 개입이나 인지 없이 도구가 SBOM 파일을 자동으로 추가하는 시나리오와 정면으로 충돌합니다. 이 상황을 거의 항상 정적인 라이선스 파일의 경우와 비교해 보십시오.

639 방식의 접근은 결국 폐기되었고, 대신 .dist-info/sboms 디렉터리에 존재하는 것만으로 SBOM을 정의하는 방식이 채택되었습니다. 이 접근 방식을 사용하면 빌드 백엔드와 도구가 정적/동적 충돌 없이 자체 SBOM 데이터를 추가할 수 있습니다.

.dist-info/sboms 디렉터리에 추가할 SBOM 파일을 정적으로 정의하는 절차는 향후 PEP에서 정의할 것입니다.

참고 문헌

감사의 글

PEP 639를 작성하고 채택까지 이끌어 주신 Karolina Surma에게 감사드립니다. 이 PEP의 초기 설계는 PEP 639에서 많은 영향을 받았으며, .dist-info 아래의 하위 디렉터리에 파일을 저장하는 비슷한 접근 방식을 채택했습니다.