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

Python 개선 제안 한국어 번역

PEP 770 – 소프트웨어 구성요소 명세서를 사용한 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 패키지에 포함된 SBOM 문서를 Python 패키지의 자동화된 소프트웨어 측정 가능성을 향상하기 위한 수단으로 사용할 것을 제안합니다.

동기

측정 가능성과 팬텀 의존성

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

  • Python은 Rust, C, C++, Fortran, JavaScript 등 컴파일 언어 또는 Python이 아닌 언어를 사용하는 과학, 데이터, 웹 및 머신 러닝 사용 사례를 지원합니다.
  • Python 휠 형식은 설치가 쉽기 때문에 사용자가 선호합니다. 설치 단계에서는 코드를 실행하지 않고 아카이브의 압축만 해제합니다.
  • Python 휠 형식에서는 이러한 라이브러리에 대한 메타데이터를 인코딩할 방법 없이 공유 컴파일 라이브러리를 번들로 포함해야 합니다.
  • Python 패키징과 관련된 패키지는 때때로 “bootstrapping” 문제를 해결해야 하므로, 순수 Python 프로젝트를 소스 코드 내부에 포함합니다.

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

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

빌드 도구, 환경 및 재현 가능성

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

규정

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

또 다른 목표는 SBOM이 필요한 사용자가 자신이 의존하는 프로젝트에 SBOM 정보를 주석으로 추가하는 데 기여할 수 있도록 하는 것입니다. 오늘날에는 이러한 기여의 결과를 Python 패키지에 전파할 메커니즘이 없으므로 사용자가 이러한 유형의 작업에 기여할 유인이 없습니다.

근거

Core Metadata 필드 대신 SBOM 표준 사용

SBOM 표준에서 제공하는 모든 필드를 Python 패키지 Core Metadata에 추가하려고 하면 새로운 Core Metadata 필드가 폭발적으로 늘어나며, 해당 영역의 새로운 요구 사항에 맞춰 SBOM 표준이 계속 발전함에 따라 최신 상태를 유지해야 하는 부담도 생깁니다.

대신 이 제안은 SBOM 관련 메타데이터를 Python 패키지에 포함되는 SBOM 문서에 위임하고, 해당 문서를 dist-info 아래의 이름이 지정된 디렉터리에 저장합니다.

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

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

Python 패키지마다 포함된 SBOM 문서를 최대 하나만 요구하는 대신, 이 PEP는 하나 이상의 SBOM 문서를 Python 패키지에 포함할 수 있도록 제안합니다. 이는 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는 새로운 메타데이터 필드와 버전이 필요하지 않도록 하면서 Python 패키지에 데이터를 안전하게 추가하기 위한 .dist-info 아래의 하위 디렉터리 사용을 제안합니다. 이 메커니즘을 사용하면 다른 프로젝트가 PEP를 채택할 때 발생하는 선두 차단 없이, 승인 직후 빌드 백엔드와 도구가 이 PEP에 설명된 기능을 사용하기 시작할 수 있습니다.

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

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

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

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

PEP 770과 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 배포판을 통해 배포되는 소프트웨어 라이브러리의 정확한 이름, 버전, 아키텍처 및 해시(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 도구를 위한 것입니다.

사양

이 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 파일이 포함되며 이 디렉터리의 모든 파일은 설치 도구가 휠에서 복사해야 한다는 내용을 반영하도록 업데이트됩니다.

SBOM 데이터 상호 운용성

이 PEP는 SBOM 표준이 활발히 개발되고 있음을 인식하여 SBOM 문서에 포함된 데이터를 불투명한 것으로 취급합니다. 그러나 Python 패키지에서 제공되는 SBOM 데이터의 상호 운용성과 사용성을 향상할 수 있도록 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 표준, 버전 또는 필드의 데이터는 검증하거나 거부해서는 안 됩니다.

하위 호환성

예약된 .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아래에 디렉터리를 배치하고 있음을 확인할 수 있으므로, 등록되지 않은 하위 디렉터리에 대해 빌드 프런트엔드가 오류를 발생시키도록 요구할 수 없습니다. 대신 이러한 상황에서는 빌드 프런트엔드가 사용자에게 경고하거나 오류를 발생시킬 수 있도록 권고합니다.

보안 영향

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

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 도구의 출력을 비교하는 benchmark is being created벤치마크가 여러 SBOM 생성 도구의 진행 상황을 추적하기 위해 생성되고 있습니다. 이 벤치마크를 통해 도구가 이 PEP와 Python 패키지를 지원하는 데 어떤 부분에서 부족한지 확인할 수 있습니다.

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

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

오픈 소스 의존성을 설명하는 SBOM 문서가 필요한 사용자는 항상 먼저 “직접 생성”해야 합니다. 위의 벤치마크를 사용하여 Python 패키지에 정확한 것으로 알려진 도구 목록을 문서화하고 사용자에게 권장할 수 있습니다. 추가적인 수동 SBOM 주석이 필요한 프로젝트의 경우, 이 데이터를 제공하는 방법과 데이터를 유지 관리하기 위한 도구를 권장할 수 있습니다.

의존성, Python 버전, 플랫폼, 아키텍처 등의 차이로 인해 SBOM 문서는 서로 다른 Python 패키지 아카이브에서 달라질 수 있습니다. 따라서 사용자는 실제로 다운로드하여 설치한 Python 패키지 아카이브에 포함된 SBOM 문서만 사용해야 하며, 특정 패키지 릴리스의 모든 아카이브에서 SBOM 문서가 동일하다고 가정해서는 안 됩니다.

참조 구현

번들된 공유 라이브러리 파일을 설명하는 CycloneDX SBOM 문서를 휠에 포함하도록 생성하는 Auditwheel fork는 다음과 같습니다. 이러한 SBOM 문서는 Syft 및 Grype SBOM·취약점 스캐너에서 예상대로 작동했습니다.

거부된 아이디어

단일 SBOM 표준 요구하기

보편적으로 받아들여지는 SBOM 표준은 없으며, 이 분야는 여전히 빠르게 발전하고 있습니다(예를 들어 SPDX는 2024년 4월 표준의 새로운 메이저 버전을 발표했습니다). 오늘날 SBOM을 둘러싼 대부분의 논의와 개발은 두 가지 SBOM 표준인 CycloneDX 및 SPDX에 초점을 맞추고 있습니다.

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

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

아카이브에서 SBOM 파일을 지정하기 위한 메타데이터 필드 사용

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

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

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

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

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

참고 자료

감사의 말

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