[Accepted] PEP 770 - Improving measurability of Python packages with Software Bill-of-Materials

원문 링크: PEP 770 - Improving measurability of Python packages with Software Bill-of-Materials

상태: Accepted 유형: Standards Track 작성일: 02-Jan-2025

PEP 770 – 소프트웨어 BOM(Bill-of-Materials)을 통한 Python 패키지 측정 가능성 개선

  • 작성자: Seth Larson
  • 스폰서: Brett Cannon
  • PEP 대리인: Brett Cannon
  • 상태: Accepted (수락됨)
  • 유형: Standards Track (표준 트랙)
  • 생성일: 2025년 1월 2일
  • 해결일: 2025년 4월 11일

초록 (Abstract)

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

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

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

동기 (Motivation)

측정 가능성과 유령 의존성 (Measurability and Phantom Dependencies)

Python 패키지는 “유령 의존성(phantom dependency)” 문제에 특히 영향을 받습니다. 이는 설치 용이성 및 표준과의 호환성 등 여러 이유로 Python이 아닌 다른 언어로 작성된 소프트웨어 구성 요소가 Python 패키지에 포함되는 경우를 말합니다.

  • Python은 Rust, C, C++, Fortran, JavaScript 등 컴파일되거나 Python이 아닌 언어를 사용하는 과학, 데이터, 웹, 머신러닝 사용 사례에 활용됩니다.
  • Python wheel 포맷은 설치 용이성 때문에 사용자들에게 선호됩니다. 설치 단계에서는 아카이브 압축 해제 외에 어떤 코드도 실행되지 않습니다.
  • Python wheel 포맷은 공유 컴파일된 라이브러리(shared compiled libraries)를 묶어야 하지만, 이러한 라이브러리에 대한 메타데이터를 인코딩할 방법이 없습니다.
  • Python 패키징 관련 패키지들은 때때로 “부트스트래핑(bootstrapping)” 문제를 해결해야 하므로 순수 Python 프로젝트를 소스 코드 내에 포함하기도 합니다.

이러한 소프트웨어 구성 요소는 Python 패키지 메타데이터를 사용하여 설명할 수 없으므로, 소프트웨어 구성 분석(SCA) 소프트웨어에 의해 누락될 가능성이 높습니다. 이는 취약한 소프트웨어 구성 요소가 정확하게 보고되지 않을 수 있음을 의미합니다.

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

빌드 도구, 환경 및 재현성 (Build Tools, Environment, and Reproducibility)

패키지의 런타임 의존성을 넘어서, SBOM은 패키지를 빌드하는 데 사용된 도구와 환경도 기록할 수 있습니다. 패키지를 빌드하는 데 사용된 정확한 도구와 버전을 기록하는 것은 종종 빌드 재현성을 확립하는 데 필요합니다. 빌드 재현성은 소프트웨어가 상위 소스와 비교했을 때 잘못되거나 악의적으로 수정된 소프트웨어 구성 요소를 감지하는 데 사용될 수 있는 속성입니다. 기록된 빌드 도구 및 버전 목록 없이는 제3자가 빌드 재현성을 확인하기 어렵거나 불가능해질 수 있습니다.

규제 (Regulations)

SBOM은 최근의 소프트웨어 보안 규제, 예를 들어 Secure Software Development Framework (SSDF) 및 Cyber Resilience Act (CRA)에 의해 요구됩니다. 이러한 규제에 포함됨에 따라, 오픈 소스 프로젝트의 SBOM 문서에 대한 수요가 높을 것으로 예상됩니다. 한 가지 목표는 SBOM이 필요한 오픈 소스 사용자가 기존 도구를 사용하여 자체적으로 서비스를 제공할 수 있도록 함으로써 오픈 소스 프로젝트 유지 관리자의 부담을 최소화하는 것입니다.

또 다른 목표는 SBOM 정보로 의존하는 프로젝트에 주석을 달아야 하는 사용자의 기여를 가능하게 하는 것입니다. 현재 Python 패키지에 대한 이러한 기여 결과를 전파할 메커니즘이 없으므로, 사용자가 이러한 유형의 작업에 기여할 유인이 없습니다.

근거 (Rationale)

Core Metadata 필드 대신 SBOM 표준 사용 (Using SBOM standards instead of Core Metadata fields)

SBOM 표준이 제공하는 모든 필드를 Python 패키지 Core Metadata에 추가하려고 시도하면 새로운 Core Metadata 필드가 폭증하게 될 것이며, SBOM 표준이 해당 분야의 새로운 요구 사항에 맞춰 계속 발전함에 따라 이를 최신 상태로 유지해야 할 필요성도 커질 것입니다.

대신 이 제안은 SBOM 관련 메타데이터를 dist-info 아래의 명명된 디렉토리에 포함된 SBOM 문서에 위임합니다.

이 표준은 Core Metadata를 SBOM으로 대체하는 것을 목표로 하지 않으며, 대신 SBOM 정보가 Core Metadata에 보충적인 역할을 하는 데 중점을 둡니다. 포함된 SBOM은 패키지 아카이브에 포함된 의존성 정보나 Core Metadata에 인코딩될 수 없지만 SBOM 사용 사례에 관련 있는 최상위 소프트웨어 정보(“소프트웨어 식별자”, “목적”, “지원 수준” 등)만을 포함합니다.

0개 이상의 불투명한 SBOM 문서 (Zero-or-more opaque SBOM documents)

Python 패키지당 최대 하나의 SBOM 문서를 요구하는 대신, 이 PEP는 하나 이상의 SBOM 문서가 Python 패키지에 포함될 수 있도록 제안합니다. 이는 Python 패키지에 SBOM 데이터를 주석으로 추가하려는 코드가 이미 다른 SBOM 문서에 포함된 데이터를 손상시킬 염려 없이 작업할 수 있음을 의미합니다.

또한 이 PEP는 SBOM 문서 데이터를 불투명하게 처리하며, 포함된 SBOM 데이터를 처리하는 것은 SBOM 데이터의 최종 사용자에게 맡깁니다. 이러한 선택은 SBOM 표준이 아직 단일한 확정적 표준이 없으며(그리고 앞으로도 없을 수 있음) Python 패키징 표준과 독립적으로 계속 발전할 수 있는 활발한 개발 영역임을 인정합니다. 이미 SBOM 문서를 소비하는 도구들은 이러한 현실을 처리하기 위해 다양한 SBOM 표준을 지원합니다.

이러한 결정은 이 PEP가 모든 SBOM 표준을 지원할 수 있으며 특정 표준을 선호하지 않고, 대신 생성 프로젝트 및 도구와 소비하는 사용자 도구에 결정을 위임함을 의미합니다.

새로운 메타데이터 버전 없이 Python 패키지에 데이터 추가 (Adding data to Python packages without new metadata versions)

새로운 메타데이터 버전과 필드를 출시하려면 광범위한 손상을 피하기 위해 많은 다른 프로젝트와 팀이 순차적으로 메타데이터 버전을 채택해야 합니다. 이러한 효과는 일반적으로 사용자와 도구가 새로운 패키징 기능을 얼마나 빨리 사용할 수 있는지에 상당한 지연을 의미합니다.

예를 들어, 단일 메타데이터 버전 범프는 PyPI, 다양한 pyproject.toml 파싱 및 스키마 프로젝트, 패키징 라이브러리에 대한 업데이트를 요구하고, 릴리스를 기다려야 하며, 그 다음 pip 및 기타 설치 프로그램이 패키징 변경 사항을 묶어 릴리스해야 합니다. 그 다음 빌드 백엔드는 새로운 메타데이터 버전을 발행하기 시작할 수 있으며, 다시 릴리스를 기다려야 하고, 그제서야 프로젝트가 새로운 기능을 사용하기 시작할 수 있습니다. 이러한 신중한 접근 방식에도 불구하고 새로운 메타데이터 버전과 필드에서 도구가 고장 나지 않을 것이라는 보장은 없습니다.

이러한 지연을 피하고, SBOM 포함 방식을 전체적으로 단순화하며, 빌드 백엔드와 도구에 유연성을 제공하기 위해 이 PEP는 새로운 메타데이터 필드와 버전을 필요로 하지 않으면서 Python 패키지에 데이터를 안전하게 추가하기 위해 .dist-info 아래의 서브디렉토리를 사용하는 것을 제안합니다. 이 메커니즘은 빌드 백엔드와 도구가 PEP가 승인된 직후 다른 프로젝트가 PEP를 채택하는 데 선행 블로킹 없이 이 PEP에 설명된 기능을 즉시 사용하기 시작할 수 있도록 합니다.

.dist-info 또는 .data 디렉토리에 파일 저장 (Storing files in the .dist-info or .data directory)

바이너리 배포판에는 소프트웨어 자체 외의 파일을 저장할 수 있는 두 개의 최상위 디렉토리가 있습니다: .dist-info와 .data. 이 사양은 서브디렉토리와 파일을 저장하기 위해 .dist-info 디렉토리를 사용하기로 결정했습니다.

첫째, .data 디렉토리는 설치된 패키지에 해당 위치가 없지만, .dist-info는 바이너리 배포판과 환경에 설치된 패키지 간의 링크를 보존합니다. .data 디렉토리는 대신 환경에 설치된 모든 패키지 간에 모든 내용이 병합되어 유사한 이름의 파일 간에 충돌이 발생할 수 있습니다.

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

PEP 770과 PEP 725의 차이점 (What are the differences between PEP 770 and PEP 725?)

PEP 725(“pyproject.toml에 외부 의존성 지정”)는 Python 패키징 메타데이터 내에서 Python이 아닌 소프트웨어를 설명하려고 시도한다는 점에서 PEP 770과 일부 유사점을 가진 다른 PEP입니다. 이 섹션은 이 두 PEP가 추적하는 정보와 제공하는 사용 사례가 어떻게 다른지 보여주는 것을 목표로 합니다.

  • PEP 725는 빌드 시간 의존성으로 “C 컴파일러”를 요구하는 추상적인 의존성(virtual:compiler/c)이나 빌드 시 “OpenSSL 라이브러리”를 연결해야 하는 경우(pkg:generic/openssl)를 설명합니다.
  • PEP 770은 AlmaLinux 배포판을 통해 배포되는 소프트웨어 라이브러리의 정확한 이름, 버전, 아키텍처 및 해시와 같은 “잠금 파일(lock file)”의 의존성에 더 가까운 구체적인 의존성을 설명합니다 (pkg:rpm/almalinux/libssl3@3.2.0). 빌드 의존성과 같은 경우, 이는 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 도구를 위한 것입니다.

사양 (Specification)

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

  • .dist-info/sboms 서브디렉토리를 명시적으로 예약합니다.
  • 빌드된 배포판(wheel) 및 설치된 프로젝트 사양에 추가됩니다.

위 외에도, 포함된 SBOM 문서와 기타 Python 패키지 메타데이터를 소비하여 Python 패키지에 대한 완전한 SBOM 문서를 생성하는 도구를 위한 정보성 PEP가 생성될 예정입니다.

.dist-info/sboms 디렉토리 예약 (Reserving the .dist-info/sboms directory)

이 PEP는 배포 아카이브 및 설치된 프로젝트 유형에 대해 .dist-info 디렉토리에서 허용되는 예약된 서브디렉토리 이름의 새 레지스트리를 도입합니다. 이 레지스트리에 대한 향후 추가는 PEP 프로세스를 통해 이루어집니다. 이 레지스트리의 초기 값은 다음과 같습니다.

서브디렉토리 이름 PEP / 표준
licenses PEP 639
license_files PEP 639 (초안만 해당)
LICENSES REUSE 라이선스 프레임워크
sboms PEP 770

이 디렉토리 이름을 선택할 때 역호환성 문제를 피하기 위한 완전한 방법론은 “Backwards Compatibility” 섹션을 참조하십시오.

프로젝트 형식의 SBOM 파일 (SBOM files in project formats)

기존 사양에 몇 가지 추가 사항이 있을 것입니다.

  • 빌드된 배포판 (wheels): wheel 사양은 새로운 예약 디렉토리 이름 레지스트리를 추가하고, .dist-info/sboms 서브디렉토리가 지정되면 해당 디렉토리가 SBOM 파일을 포함함을 반영하도록 업데이트될 것입니다.
  • 설치된 프로젝트: 설치된 프로젝트 기록(Recording Installed Projects) 사양은 .dist-info/sboms 서브디렉토리가 지정되면 해당 디렉토리가 SBOM 파일을 포함하며, 이 디렉토리의 모든 파일은 설치 도구에 의해 wheels에서 복사되어야 함을 반영하도록 업데이트될 것입니다.

SBOM 데이터 상호 운용성 (SBOM data interoperability)

이 PEP는 SBOM 표준이 활발한 개발 영역임을 인식하여 SBOM 문서에 포함된 데이터를 불투명하게 처리합니다. 그러나 SBOM 데이터 생산자가 따를 경우 Python 패키지에서 사용할 수 있는 SBOM 데이터의 상호 운용성과 유용성을 향상시킬 몇 가지 고려 사항이 있습니다.

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

PyPI 및 기타 인덱스는 이 PEP에서 지정한 SBOM 문서의 내용을 검증할 수 있지만, 알려지지 않은 SBOM 표준, 버전 또는 필드에 대한 데이터를 검증하거나 거부해서는 안 됩니다.

역호환성 (Backwards Compatibility)

예약된 .dist-info/sboms 서브디렉토리 (Reserved .dist-info/sboms subdirectory)

새로운 예약된 .dist-info/sboms 서브디렉토리는 이전에 문서화되지 않은 새로운 예약이므로, 기존 도구들이 가지고 있는 가정(assumption)을 깨뜨릴 잠재력이 있습니다.

현재 어떤 .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

위 결과에서 알 수 있듯이, .dist-info 아래의 대부분의 서브디렉토리는 라이선스와 관련이 있으며, 그 중 하나(licenses)는 PEP 639에 의해 지정되고 다른 것들(license_files, LICENSES)은 PEP 639의 초안 구현에서 비롯된 것입니다. sboms 서브디렉토리는 기존 사용과 충돌하지 않습니다. .dist-info 아래의 다른 서브디렉토리 이름은 널리 사용되지 않거나 우연한 것으로 보입니다.

이 쿼리 결과, 이미 일부 프로젝트가 .dist-info 아래에 디렉토리를 배치하고 있음을 알 수 있으므로, 빌드 프론트엔드가 등록되지 않은 서브디렉토리에 대해 오류를 발생시키도록 요구할 수는 없습니다. 대신 빌드 프론트엔드는 이 시나리오에서 사용자에게 경고하거나 오류를 발생시킬 수 있도록 권장됩니다.

보안 영향 (Security Implications)

SBOM 문서는 인코딩된 정보만큼만 유용합니다. SBOM 문서에 잘못된 정보가 포함되어 있으면 SCA 도구에 의한 잘못된 다운스트림 분석이 발생할 수 있습니다. 이러한 이유로 Python 패키지에 SBOM 데이터를 포함하는 도구는 기록하는 정보에 대해 확신을 갖는 것이 중요합니다. SBOM은 알려진 데이터 외에도 “알려진 미지(known unknowns)”를 기록할 수 있습니다. 이 관행은 기록되는 데이터에 대해 확신이 없을 때 사용자에게 추가 분석을 허용하기 위해 권장됩니다.

SBOM 문서는 Python 패키지가 빌드된 원래 시스템에 대한 정보(예: 운영 체제 이름 및 버전, 덜 일반적으로는 경로 이름)를 인코딩할 수 있기 때문입니다. 이 정보는 SBOM을 통해 Python 패키지에서 설치 프로그램으로 “유출”될 가능성이 있습니다. 이 정보가 민감한 경우 보안 위험을 초래할 수 있습니다.

교육 방법 (How to Teach This)

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

Python 패키지 유지 관리자가 알아야 할 사항 (What do Python package maintainers need to know?)

Python 패키지 메타데이터는 이미 패키지 아카이브에 포함된 최상위 소프트웨어를 설명할 수 있지만, 패키지 아카이브에 최상위 소프트웨어 외에 다른 소프트웨어 구성 요소가 포함되어 있다면 어떨까요? 예를 들어, “Pillow”용 Python wheel에는 libjpeg, libpng, libwebp 등과 같이 번들된 여러 다른 소프트웨어 라이브러리가 포함되어 있습니다. 이 시나리오는 이 PEP가 가장 유용한 경우로, 번들된 소프트웨어에 대한 메타데이터를 Python 패키지에 추가하는 것입니다.

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

SBOM 도구 작성자가 알아야 할 사항 (What do SBOM tool authors need to know?)

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

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

다양한 Python 패키징 입력(패키지 아카이브, 설치된 패키지, 환경, 컨테이너 이미지)으로 실행했을 때 서로 다른 SBOM 도구의 출력을 비교하는 벤치마크가 생성되고 있으며, 이는 다양한 SBOM 생성 도구의 진행 상황을 추적하기 위한 것입니다. 이 벤치마크는 도구들이 이 PEP 및 Python 패키지 지원에서 어떤 간극을 가지고 있는지 알려줄 것입니다.

SBOM 문서 사용자가 알아야 할 사항 (What do users of SBOM documents need to know?)

이 PEP의 많은 사용자는 그 존재를 알지 못할 것입니다. 대신 그들의 소프트웨어 구성 분석 도구, SBOM 도구 또는 취약점 스캐너는 업그레이드 후에 단순히 더 포괄적인 정보를 제공하기 시작할 것입니다. 이 새로운 정보의 출처에 관심이 있는 사용자를 위해, SBOM 메타데이터의 “tool” 필드는 이미 SBOM을 생성하는 프로젝트에 대한 링크를 제공합니다.

오픈 소스 의존성에 대한 SBOM 문서가 필요한 사용자는 항상 “직접 생성”하는 것이 첫 번째 단계여야 합니다. 위의 벤치마크를 사용하여 Python 패키지에 대해 정확하다고 알려진 도구 목록을 문서화하고 사용자에게 추천할 수 있습니다. 추가적인 수동 SBOM 주석이 필요한 프로젝트의 경우: 이 데이터를 기여하는 팁과 데이터를 유지 관리하는 도구를 추천할 수 있습니다.

SBOM 문서는 의존성, Python 버전, 플랫폼, 아키텍처 등에 따라 다른 Python 패키지 아카이브마다 다를 수 있다는 점에 유의하십시오. 이러한 이유로 사용자는 실제로 다운로드하고 설치된 Python 패키지 아카이브에 포함된 SBOM 문서만 사용해야 하며, 주어진 패키지 릴리스의 모든 아카이브에 대해 SBOM 문서가 동일하다고 가정해서는 안 됩니다.

참조 구현 (Reference Implementation)

번들된 공유 라이브러리 파일을 설명하는 wheel에 포함할 CycloneDX SBOM 문서를 생성하는 auditwheel 포크. 이러한 SBOM 문서는 Syft 및 Grype SBOM 및 취약점 스캐너에 대해 예상대로 작동했습니다.

거부된 아이디어 (Rejected Ideas)

단일 SBOM 표준 요구 (Requiring a single SBOM standard)

전 세계적으로 통용되는 단일 SBOM 표준은 없으며, 이 분야는 여전히 빠르게 발전하고 있습니다(예: SPDX는 2024년 4월에 표준의 새로운 주요 버전을 발표했습니다). 오늘날 SBOM에 대한 대부분의 논의와 개발은 CycloneDX와 SPDX라는 두 가지 SBOM 표준에 초점을 맞추고 있습니다.

명확한 승자가 나타나기 전에 Python 생태계를 특정 표준에 고정하는 것을 피하기 위해, 이 PEP는 SBOM 문서를 불투명하게 처리하며, SBOM 문서 데이터의 다운스트림 소비자(downstream consumers)와의 호환성을 촉진하기 위한 권장 사항만을 제시합니다.

이 PEP의 어떤 결정도 미래의 PEP가 단일 SBOM 표준을 선택하는 것을 제한하지 않습니다. 오늘날 SBOM 데이터를 사용하는 도구는 이러한 상황을 처리하기 위해 이미 여러 형식을 지원해야 하므로, 단일 표준만 요구하도록 업데이트하는 미래 표준은 다운스트림 SBOM 도구에 영향을 미치지 않을 것입니다.

아카이브에 SBOM 파일을 지정하는 메타데이터 필드 사용 (Using metadata fields to specify SBOM files in archives)

이 사양의 이전 버전은 Sbom-File 메타데이터 필드를 사용하여 소스 또는 바이너리 배포 아카이브 내에서 SBOM 파일을 지정했습니다. 이는 License-File 필드를 사용하여 아카이브의 라이선스 파일을 열거하는 PEP 639와 유사하게 구현되었을 것입니다.

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

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

639 스타일 접근 방식은 궁극적으로 .dist-info/sboms 디렉토리에 SBOM이 존재한다는 것만으로 정의하는 방식으로 대체되었습니다. 이 접근 방식은 빌드 백엔드와 도구가 정적/동적 충돌 없이 자체 SBOM 데이터를 추가할 수 있도록 합니다.

향후 PEP는 .dist-info/sboms 디렉토리에 추가될 SBOM 파일을 정적으로 정의하는 프로세스를 정의할 것입니다.

참고 자료 (References)

감사 (Acknowledgements)

PEP 639를 작성하고 채택으로 이끈 Karolina Surma에게 감사합니다. 이 PEP의 초기 설계는 PEP 639에서 크게 영감을 받았으며, 파일을 저장하기 위해 .dist-info 아래의 서브디렉토리를 사용하는 유사한 접근 방식을 채택합니다.

이 번역이 Python 개발자분들께 PEP 770의 내용을 명확하게 이해하는 데 도움이 되기를 바랍니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments