SBOM 생성은 성공했지만, CI에 올린 앱의 의존성 목록과 맞지 않습니다.
이번 주에는 생성 명령이 어떤 의존성 그래프를 사용했는지 먼저 확인하고, Package.resolved와 제품 범위, 생성 시점을 같은 제출물 기준으로 맞추세요. 파일 형식 검증만으로는 SBOM이 전달된 산출물에 속한다고 증명할 수 없습니다.
Swift Package 유지 관리자: Swift 6.4 SBOM을 의존성 검토나 배포 과정에 넣어야 하는 경우에 적합합니다.
Apple 플랫폼 CI 엔지니어: macOS 빌드 제품과 SBOM의 범위가 같은지 확인하려는 경우에 적합합니다.
개발 보안 및 규정 준수 담당자: 생성부터 보관, 추적까지의 검토 절차를 정리하려는 경우에 적합합니다.
마지막 업데이트: 2026년 10월 26일. Swift 6.4의 SBOM 지원 여부와 명령 동작은 Swift 6.4 출시 안내, SE-0509 제안, SwiftPM SBOM 문서를 기준으로 확인했습니다.
SECTION 01 불일치 증거를 먼저 분류합니다
생성 성공과 범위 일치의 차이
Swift 6.4 출시 자료는 SwiftPM의 SBOM 생성을 안내하며, SE-0509는 해당 기능을 Swift 6.4에 구현된 제안으로 표시합니다. 다만 명령이 파일을 만들었다는 사실은 의존성 범위가 실제 빌드와 같다는 뜻이 아닙니다. SwiftPM 생성 문서와 SE-0509의 명령 옵션 설명을 열어, 실행한 명령과 선택한 출력 형식, 입력 그래프를 확인하세요.
swift package generate-sbom과 swift build에서 얻은 정보는 어떻게 다른가요? swift package generate-sbom은 SBOM을 생성하는 패키지 관리자 명령입니다. 빌드 명령을 실행했다는 사실만으로 SBOM이 빌드에 결합되지는 않습니다. 실제 CI 로그에서 SBOM 생성 명령이 별도로 실행됐는지, 사용한 옵션이 무엇인지 확인하고, 문서에 적힌 그래프 범위를 빌드 로그와 대조해야 합니다.
| 점검 대상 | 확인할 증거 | 놓치기 쉬운 차이 |
|---|---|---|
| 패키지 의존성 그래프 | SBOM 생성 명령과 SwiftPM 문서 | 패키지 전체 정보가 특정 제품의 실제 빌드 범위를 그대로 나타내지는 않을 수 있습니다 |
| 빌드 의존성 그래프 | 빌드 명령, 선택한 제품, 빌드 로그 | 빌드 조건이나 제품 선택에 따라 포함되는 의존성이 달라질 수 있습니다 |
| SBOM 출력 파일 | 형식과 생성 단계 | 파일을 읽을 수 있어도 앱 산출물과의 연결은 별도로 확인해야 합니다 |
Swift Package Manager SBOM에 구성 요소가 더 많거나 적게 보이는 이유는 무엇인가요? 생성에 사용한 그래프와 빌드 대상이 다를 수 있기 때문입니다. SE-0509에서 설명하는 제품 의존성 및 필터링 동작을 확인하고, 구성 요소 수만으로 누락 여부나 완전성을 판단하지 마세요.
주의: 패키지에서 해석된 의존성과 특정 제품을 만들 때 사용된 의존성은 같은 범위라고 단정할 수 없습니다. 생성 명령, 제품 이름, 빌드 로그를 함께 보관해야 차이를 설명할 수 있습니다.
SECTION 02 제품과 잠금 상태를 맞춥니다
여러 제품을 제공하는 패키지라면 전체 패키지 범위의 SBOM을 특정 앱 제품의 목록으로 오해하기 쉽습니다. 제품 단위와 타깃 단위도 같지 않습니다. CI에서 어떤 제품을 빌드했는지, 생성 명령이 패키지 전체를 대상으로 했는지, 결과 파일이 어느 단계에서 저장됐는지를 기록하세요.
다중 제품 프로젝트의 SBOM 범위는 어떻게 확인하나요? 제품별 빌드 명령과 내보낸 파일을 나란히 놓고, 각 SBOM의 구성 요소가 해당 제품에 연결되는지 검토합니다. 하나의 제품에 대한 목록을 앱 전체의 의존성 목록으로 취급하지 마세요.
| 증거 | 대조 방법 | 불일치 신호 |
|---|---|---|
| Package.resolved | 빌드와 SBOM 생성 단계에서 사용한 파일 및 변경 상태 비교 | 생성 단계 전에 파일이 바뀌었거나 다른 작업 공간을 사용함 |
| 제품 이름 | 빌드 대상과 SBOM 생성 대상 비교 | 패키지 이름만 있고 실제 배포 제품과 연결되지 않음 |
| 실행 순서 | 체크아웃, 의존성 해석, 빌드, 생성, 보관 로그 비교 | 빌드 이후 의존성을 다시 해석하거나 별도 작업 공간에서 생성함 |
Package.resolved는 패키지 의존성 상태를 확인하는 단서입니다. PackageDescription의 패키지 의존성 설명과 패키지 정보 명령 문서를 참고하되, 잠금 파일 하나만으로 어떤 제품이 실제 빌드됐는지 증명하려 하지 마세요.
Package.resolved가 같으면 SBOM도 같아야 하나요? 그렇지 않습니다. 같은 잠금 상태라도 생성 대상 제품이나 그래프, 실행 시점이 다르면 목록이 달라질 수 있습니다. CI에서 파일 경로와 수정 여부를 확인하고, 의존성 해석 이후 빌드와 SBOM 생성이 같은 작업 공간을 사용했는지 검토하세요.
SECTION 03 생성 시점과 추적 정보를 연결합니다
빌드가 끝난 뒤 별도 단계에서 SBOM을 만들면, 그 사이 의존성 상태나 작업 공간이 달라졌는지 확인해야 합니다. 독립 생성 명령이 어떤 그래프를 읽는지는 SwiftPM 문서와 실제 사용 옵션을 기준으로 판단하세요. 추측으로 빌드 산출물에 자동 연결된다고 가정해서는 안 됩니다.
CycloneDX 또는 SPDX 파일이 올바르게 읽히는지 검증하는 일도 필요합니다. CycloneDX 검증 안내와 SPDX 직렬화 및 검증 규칙을 따라 형식을 확인하세요. 형식이 유효하다는 결과는 제품 범위가 맞다는 증거도, SBOM이 바이너리에 서명되거나 자동으로 결합됐다는 증거도 아닙니다. 앱 보관과 배포 단계는 Apple의 앱 배포 안내와 별도로 대조하세요.
기억할 점: 형식 검증, 의존성 범위 검토, 산출물 출처 추적은 서로 다른 확인 항목입니다. 파일 이름에 제출물 식별 정보를 넣는 것만으로 연결이 보장되지는 않으므로 CI 기록과 보관 경로도 함께 남기세요.
SECTION 04 macOS CI 인수 점검표
다음 항목을 같은 제출물 기준으로 완료한 뒤 결과를 인수하세요.
- [ ] 체크아웃한 제출물 식별 정보와 작업 디렉터리를 빌드 로그에 남깁니다.
- [ ] 의존성 해석이 끝난 뒤 Package.resolved의 경로와 상태를 보관합니다.
- [ ] 빌드한 제품 이름과 실제 배포 대상이 일치하는지 확인합니다.
- [ ] SBOM 생성 명령, 옵션, 출력 형식을 기록하고 사용한 그래프 범위를 문서와 대조합니다.
- [ ] 빌드와 SBOM 생성 사이에 의존성 상태나 작업 공간이 바뀌지 않았는지 확인합니다.
- [ ] CycloneDX 또는 SPDX 파일을 형식에 맞게 검증하고, 제품 및 의존성 관계를 검토합니다.
- [ ] 빌드 로그, 앱 산출물, SBOM을 같은 CI 실행의 보관 기록으로 묶어 다시 내려받아 확인합니다.
이 과정에서 SwiftPM의 SBOM 생성과 macOS용 앱 빌드에는 Apple 플랫폼 도구 체인이 필요할 수 있습니다. 형식 파일의 정적 검토는 다른 환경에서도 맡길 수 있지만, 그 검토만으로 Xcode 빌드 결과와 제품 범위를 재현했다고 볼 수는 없습니다. 팀의 도구 체인을 반복 재현해야 한다면 원격 Mac 개발 환경 선택과 VPSNIX 요금 안내을 함께 살펴보세요.
Linux 전용 실행기는 macOS 및 Xcode 빌드를 대신할 수 없습니다. 반대로 개인 Mac은 절전, 업데이트, 로컬 자격 증명 관리가 운영 부담이 될 수 있고, 장기적으로 고정된 부하를 돌리거나 물리 포트가 필요한 팀에는 원격 임대가 맞지 않을 수 있습니다. 다만 도구 체인을 재현할 macOS 환경이 일시적으로 필요하다면, Mac을 직접 구매하기 전에 VPSNIX 원격 Mac 임대를 비교해 보는 편이 비용과 운영 범위를 결정하는 데 도움이 됩니다.