프롤로그 — 공급망이 새로운 공격면이다

소프트웨어 보안의 무게중심이 바뀌었다. 10년 전에는 "내 코드의 버그를 막자"가 전부였다. 2026년의 정답은 다르다. "내 코드 + 내가 import한 5,000개 패키지 + 그 패키지의 빌드 환경 + 그 빌드 환경의 컨테이너 이미지 + 그 컨테이너 이미지의 base OS"까지 전부 검증해야 한다.

이 변화는 일련의 사건이 만들었다.

- **SolarWinds Orion(2020)** — Sunburst 백도어. 미국 연방기관과 포춘 500 기업 18,000곳에 침투. 빌드 시스템 침해.

- **Codecov bash uploader(2021)** — CI에 사용되는 bash 스크립트가 변조되어 환경변수 토큰이 유출.

- **Log4Shell(2021년 12월)** — Log4j 2.x JNDI 취약점 CVE-2021-44228. 거의 모든 Java 서비스 영향.

- **3CX desktop app(2023년 3월)** — Mandiant가 확인. 북한 연계 그룹. 빌드 파이프라인 침해 사례.

- **XZ Utils backdoor(2024년 3월)** — Jia Tan(가명)이 2년에 걸쳐 메인테이너 신뢰를 얻고 백도어 삽입. Andres Freund(MS PostgreSQL 엔지니어)가 우연히 발견. CVE-2024-3094.

- **npm 타이포스쿼팅** — 2023-2025년 동안 매주 보고. lodash → lodahs, requests → requets 등.

이 사건들이 만든 결론은 단순하다. **빌드 시점에 발생한 일을 사후 증명할 수 있어야 한다.** 그리고 **import하는 모든 의존성의 행동을 알아야 한다.**

이 글은 그 두 명제에 대한 2026년의 답이다. Sigstore가 서명을 키 없이 만들어 주고, SLSA가 빌드 무결성 레벨을 정의하며, SBOM이 "이 바이너리 안에 무엇이 들었는지"를 표준 포맷으로 기록한다. 60여 개 도구·표준·사건을 한 흐름으로 정리한다.

1장 · 왜 공급망 보안이 필요한가

2026년 공급망 위협의 다섯 축.

- **의존성 트리의 폭발** — 평범한 npm 프로젝트가 직간접으로 끌어오는 패키지 수가 1,500-3,000개. 각 패키지가 별개의 메인테이너 신뢰 모델을 갖는다.

- **빌드 환경의 불투명성** — 깃 레포의 코드와 npm에 올라간 tarball이 일치한다는 보장이 없다. event-stream(2018), ua-parser-js(2021), node-ipc(2022) 모두 같은 패턴.

- **베이스 이미지의 CVE 누적** — Docker Hub에 올라온 alpine, ubuntu, debian 이미지는 시간이 지날수록 CVE가 쌓인다. 마지막 빌드가 6개월 전이면 평균 30-60개의 미적용 보안 패치.

- **CI/CD 비밀의 유출 위험** — GitHub Actions, GitLab CI, CircleCI, Buildkite에 저장된 토큰이 워크플로 로그·캐시·아티팩트로 새는 사례.

- **법적 의무의 등장** — 미국 EO 14028, CISA Attestation Form, EU CRA, 한국 ISMS-P, 일본 IPA 가이드라인이 SBOM·attestation을 요구하기 시작.

각 축마다 별도의 도구·표준이 등장했다. 이 글의 구조는 그 다섯 축을 따라간다.

[공급망 보안의 6단계 — 2026 모델]

1. 소스 제어 — Git, SCM 정책, 코드 서명

2. 의존성 큐레이션 — Socket, Snyk, Phylum, Endor

3. 빌드 무결성 — SLSA, in-toto, GitHub OIDC, Tekton Chains

4. SBOM 생성 — Syft, CycloneDX, SPDX, CSAF

5. 아티팩트 서명 — cosign, Sigstore, Notary v2

6. 런타임 검증 — Kyverno, Sigstore policy-controller, OPA

각 단계가 다른 도구·다른 책임자를 가진다. 이 글은 단계별로 도구·표준·실제 사건을 정리한다.

2장 · 결정적 사건 — XZ Utils 백도어(CVE-2024-3094)

2024년 3월 28일, MS의 PostgreSQL 엔지니어 Andres Freund가 보안 메일링 리스트 oss-security에 글을 올렸다. 그 글이 2020년대 공급망 보안의 분수령이 되었다.

- **사건의 윤곽** — XZ Utils 5.6.0과 5.6.1에 백도어 코드 삽입. liblzma를 거쳐 OpenSSH의 sshd에 영향. 특정 RSA 키를 가진 사용자에게 인증 없이 RCE 권한을 부여.

- **메인테이너 신뢰 침투** — Jia Tan(또는 Jia Cheong Tan)이라는 가명이 2021년부터 활동. 2-3년에 걸쳐 patch, review, release 권한을 차근차근 획득.

- **사회공학적 압박** — Jigar Kumar 등 가명 계정이 원 메인테이너 Lasse Collin에게 "릴리즈가 늦다"는 압력 메일을 보냄. 결국 Jia Tan을 co-maintainer로 추가.

- **발견의 우연성** — Freund가 sshd 로그인 지연(0.5초)을 의아하게 여겨 perf로 추적했다가 발견. **사실상 우연.**

이 사건의 교훈은 명확하다.

- **메인테이너 신뢰는 영원하지 않다** — 한 명의 인간이 단일 실패점이 되면 안 된다.

- **이진 빌드와 소스의 차이 검증 필수** — XZ의 백도어는 tarball에는 있고 Git 레포에는 없는 코드였다.

- **재현 가능 빌드(Reproducible Build)의 중요성** — Debian과 Tor가 추진 중인 reproducible build였다면 차이 즉시 감지.

- **자동 탐지의 한계** — 정적 분석으로 못 잡았다. 행위 분석이 필요하다.

XZ Utils 사건 이후 OpenSSF의 Alpha-Omega 프로젝트가 핵심 OSS 메인테이너 지원을 확대했고, Sigstore·SLSA·Socket 같은 도구의 도입이 본격화되었다.

3장 · Sigstore — 키 없는 서명의 표준

**Sigstore**(sigstore.dev)는 2021년 Linux Foundation·Red Hat·Google이 공동 출범. OpenSSF 산하 프로젝트.

핵심 구성요소.

- **cosign** — 컨테이너 이미지·SBOM·바이너리에 서명. CLI 도구.

- **fulcio** — 단기 인증서 발급 CA. OIDC 토큰을 받아 5-10분 유효한 X.509 서명용 인증서 발급.

- **rekor** — 변경 불가능한 투명성 로그(transparency log). Merkle Tree 기반. 모든 서명이 공개 기록.

- **gitsign** — Git 커밋 서명용 cosign 변형. SSH 키 대신 OIDC 사용.

작동 원리는 "키 없는 서명(keyless signing)"이다.

- **OIDC 로그인** — GitHub Actions, Google, Microsoft, GitLab OIDC로 인증.

- **fulcio에 CSR 제출** — fulcio가 OIDC claim을 인증서에 박아서 단기 서명 인증서 발급.

- **cosign으로 서명** — 그 인증서로 아티팩트 서명. 직후 인증서·서명을 rekor에 기록.

- **검증** — 누구나 rekor의 투명성 로그와 fulcio의 인증서 체인을 따라 검증.

기존 PGP 서명의 문제 — 키 관리, 키 폐기, 키 분실 — 를 정면으로 우회한다. 키가 없으니 잃을 키도 없다. 모든 서명이 공개 로그에 기록되어 사후 부인이 불가능하다.

2026년 5월 기준으로 Kubernetes, npm 일부 패키지, PyPI 일부 패키지가 Sigstore 서명을 채택했다. GitHub Actions Artifact Attestations(2024년 5월 GA)도 내부적으로 Sigstore를 사용한다.

4장 · SLSA v1.1 — 공급망 무결성 레벨

**SLSA**(slsa.dev, "살사"라고 읽음)는 Supply-chain Levels for Software Artifacts. Google이 내부의 Binary Authorization for Borg(BAB)를 OSS로 일반화한 프레임워크. OpenSSF에서 관리.

- **v1.0** — 2023년 4월 발표. Build, Source, Dependency 트랙을 분리.

- **v1.1** — 2024년 후반 갱신. Build 트랙에 집중하고 Source·Dependency는 별도 작업으로.

Build 트랙 레벨.

- **Build Level 1** — provenance(누가, 어디서, 어떻게 빌드했는지)를 제공. 변조 방지는 아직 없음.

- **Build Level 2** — provenance가 서명되어 있고, 빌드 서비스가 호스팅됨. 빌더 신뢰 필요.

- **Build Level 3** — 빌더가 격리되어 다른 빌드의 영향 받지 않음. GitHub Actions Reusable Workflows + OIDC가 대표 사례.

SLSA Level 3을 달성하면 SolarWinds·Codecov 유형의 공격 — 빌드 환경 변조 — 에 강력한 방어선이 생긴다. 빌드 서비스 자체가 침해되지 않는 한, attacker가 임의 코드를 빌드 산출물에 끼워 넣지 못한다.

실무 적용 사례.

- **GitHub Actions** — `slsa-framework/slsa-github-generator` 액션으로 Level 3 빌드 가능.

- **GitLab CI** — Premium에서 provenance attestation 자동 생성.

- **Google Cloud Build** — Container Analysis API로 provenance 제공.

- **AWS CodeBuild** — Public Builds로 Build Level 3 지원(2024 GA).

5장 · in-toto — Attestation의 일반 프레임워크

**in-toto**(in-toto.io)는 NYU·Cornell에서 시작된 학술 프로젝트가 CNCF에 정착한 케이스. 2022년 CNCF Incubating 진입, 2024년 Graduated.

핵심 아이디어. **공급망의 각 단계에서 "내가 무엇을 했다"는 attestation(증언)을 발행하고, 다음 단계가 그것을 검증한다.**

- **Layout** — 파이프라인 정의. "이런 순서로, 이런 사람들이, 이런 작업을 해야 한다."

- **Step** — 각 단계의 입력·출력 해시.

- **Sublayout** — 큰 파이프라인의 일부 단계를 또 다른 layout으로 위임.

SLSA의 provenance는 in-toto attestation의 한 종류다. 즉 SLSA는 in-toto 형식을 빌려 빌드 무결성에 집중한 사양.

in-toto의 일반성은 다음을 의미한다.

- **SBOM도 attestation** — "이 아티팩트의 SBOM은 이것입니다"라는 증언.

- **취약점 스캔 결과도 attestation** — "이 시점에 Trivy로 스캔했고 결과는 이것입니다."

- **테스트 결과도 attestation** — "이 시점에 이런 테스트가 통과했습니다."

모든 증언이 Sigstore로 서명되고 rekor에 기록되면, 운영팀은 배포 직전에 "이 이미지가 충분한 attestation을 모았는가"를 정책 엔진(Kyverno, OPA)으로 강제할 수 있다.

6장 · GUAC — Attestation의 그래프 데이터베이스

**GUAC**(guac.sh, Graph for Understanding Artifact Composition)는 Kusari·Google·Purdue가 시작한 OpenSSF 프로젝트. 2023년 초 출범.

문제 의식. **SBOM·attestation·취약점 데이터가 여러 곳에 흩어져 있다. 한 곳에 모아 그래프로 질의할 수 있어야 한다.**

GUAC는 다음을 합친다.

- **SBOM** — Syft, Trivy가 만든 CycloneDX/SPDX 파일.

- **Attestation** — SLSA provenance, in-toto.

- **취약점** — OSV, GHSA, NVD에서 수집.

- **컨테이너 메타데이터** — registry에서 pull한 정보.

질의 예시.

Q: 우리가 운영 중인 모든 이미지에서 Log4j 2.14를 사용한 것은?

GUAC: registry/payments-api:v3.2.1, registry/inventory:v1.0.5 ...

Q: 이 이미지가 의존하는 모든 npm 패키지 중 Jia Tan과 같은

메인테이너 패턴을 보이는 것은?

GUAC: (graph traversal로 메인테이너·릴리즈 패턴 분석)

2026년 5월 기준으로 GUAC는 Alpha 단계지만 OpenSSF가 적극적으로 밀고 있다. Kusari가 SaaS 형태로 호스팅 서비스를 제공한다.

7장 · OpenSSF Scorecard — OSS 프로젝트 건강도 점수

**OpenSSF Scorecard**(github.com/ossf/scorecard)는 OSS 프로젝트의 보안 관행을 자동 점수화하는 도구. 2020년 출범.

점수 항목(체크 16개).

- **Code-Review** — 모든 변경이 코드 리뷰를 거치는가.

- **Branch-Protection** — main 브랜치 보호 설정.

- **Token-Permissions** — GitHub Actions 토큰의 권한 최소화.

- **Vulnerabilities** — 알려진 취약점 의존성 사용 여부.

- **Pinned-Dependencies** — 의존성을 SHA로 핀했는가.

- **Maintained** — 최근 90일 활동 여부.

- **License** — 라이선스 파일 존재.

각 항목 0-10점, 평균이 프로젝트 점수. 10점이 만점.

활용.

- **deps.dev**(Google) — 모든 OSS 패키지의 Scorecard 점수를 자동 표시.

- **Securityscorecards.dev** — 점수 시각화 대시보드.

- **GitHub Action** — 자신의 프로젝트에 Scorecard 워크플로 추가.

Scorecard는 "이 패키지를 import해도 되는가"의 자동 평가 기준으로 점점 더 많이 사용된다. Endor Labs, Snyk 등 상용 도구도 Scorecard 점수를 의존성 위험 평가에 통합한다.

8장 · Frizbee · AllStar — 보조 OpenSSF 도구

**Frizbee**(github.com/stacklok/frizbee)는 Stacklok이 만든 작은 도구. GitHub Actions와 컨테이너 이미지를 SHA로 핀(pin)한다.

Before

- uses: actions/checkout@v4

After (Frizbee 적용)

- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

태그(`v4`)는 메인테이너가 새 SHA로 옮길 수 있다. tj-actions/changed-files 사건(2025년 3월 GitHub Action 자체 변조)이 그 위험을 보여주었다. SHA 핀은 임시 변조에 영향 받지 않는다.

**AllStar**(github.com/ossf/allstar)는 OpenSSF가 만든 정책 봇. GitHub 조직에서 다음을 자동 강제.

- **Branch Protection** — main에 직접 push 금지, PR 리뷰 의무 등.

- **Binary Artifacts** — 레포에 .exe·.dll·.so 같은 바이너리 금지.

- **Outside Collaborators** — 외부 협력자 권한 제한.

- **SECURITY.md** — 보안 정책 파일 존재 여부.

AllStar는 발견 시 이슈를 자동 생성하고, 일정 기간 미해결이면 Pull Request로 수정안을 제안한다. OpenSSF·Sigstore·CNCF 본인들의 GitHub 조직이 AllStar를 운영 중.

9장 · OSV-Scanner · OSV.dev — Open Source Vulnerabilities

**OSV**(osv.dev, Open Source Vulnerabilities)는 Google이 2021년 초 출범시킨 취약점 데이터베이스. **NVD의 대안.**

NVD의 문제.

- **느린 등록** — CVE 발급 후 NVD에 등록되기까지 수개월 지연.

- **2024년 NVD 슬로다운** — NIST 인력 부족으로 2024년 2월부터 NVD 분석이 사실상 중단. 미국 정부 OSS 보안 전체에 큰 충격.

- **버전 범위 표현의 불일치** — vulnerable_software_list 같은 CPE 매칭이 정밀하지 않음.

OSV의 강점.

- **JSON 스키마 표준** — 누구나 새 데이터베이스를 OSV 형식으로 발행 가능.

- **자동 import** — GHSA(GitHub), RustSec, PyPA Advisory, npm Advisory를 자동 통합.

- **언어·생태계별 분리** — npm, PyPI, Go, Maven, NuGet 등 각각의 데이터셋.

- **버전 범위 정밀 매칭** — 패키지 매니저의 의미론(semver, PEP 440)에 맞게 매칭.

**OSV-Scanner**(github.com/google/osv-scanner)는 OSV 데이터를 사용하는 로컬 스캐너. lockfile(package-lock.json, Cargo.lock 등)을 읽어 취약점을 보고한다. 무료·오픈소스.

2024년 NVD 슬로다운 이후 OSV는 사실상 NVD 의존을 끊은 첫 대규모 DB로 자리 잡았다. CISA도 OSV를 KEV(Known Exploited Vulnerabilities) 데이터와 연동.

10장 · SBOM 포맷 — CycloneDX 1.6 vs SPDX 3.0

SBOM(Software Bill of Materials)을 표현하는 두 표준이 평행 발전 중이다.

**CycloneDX**(cyclonedx.org).

- **운영 주체** — OWASP.

- **버전** — 1.6(2024년 4월).

- **포맷** — JSON, XML, ProtoBuf.

- **강점** — VEX(Vulnerability Exploitability eXchange) 통합, ML 모델·서비스·하드웨어 BOM 지원. 보안 도구 중심으로 빠른 채택.

**SPDX**(spdx.dev).

- **운영 주체** — Linux Foundation.

- **버전** — 3.0(2024년 4월).

- **포맷** — JSON-LD, RDF/XML, Tag-Value.

- **강점** — ISO/IEC 5962:2021 국제 표준. 라이선스 정보 표현이 강력. 법무·컴플라이언스 중심으로 채택.

선택 기준.

- **보안 중심이면 CycloneDX** — VEX 통합 강점, JSON이 가벼움.

- **컴플라이언스·라이선스 중심이면 SPDX** — ISO 표준, 라이선스 메타데이터 강함.

- **둘 다 출력하기** — Syft·Trivy 모두 두 포맷 동시 출력 지원. 듀얼 발행이 무난.

미국 EO 14028, CISA Attestation은 두 포맷 모두 허용한다. EU CRA도 SBOM 포맷을 강제하지 않는다.

11장 · SWID Tags · CSAF — 보조 SBOM/취약점 표준

**SWID Tags**(ISO/IEC 19770-2)는 소프트웨어 식별 태그. NIST가 미국 정부 시스템에 권장. 패키지 설치 시 함께 배포되는 XML 파일로, 누가·언제·무엇을 설치했는지 기록.

SWID는 SBOM보다 정밀한 단일 패키지 식별에 강하다. 다만 CycloneDX·SPDX만큼 보편적이지는 않다.

**CSAF**(Common Security Advisory Framework)는 OASIS가 표준화. 취약점 공지의 JSON 포맷.

- **2.0** — 2022년 발표.

- **VEX 통합** — CSAF VEX 프로파일로 "이 취약점이 우리 제품에 영향 없음" 같은 진술 표준화.

- **사용 사례** — Red Hat, SUSE, Cisco, Siemens가 보안 공지를 CSAF로 발행.

CSAF는 SBOM과 짝을 이룬다. SBOM이 "이 안에 무엇이 있는가", CSAF가 "그것에 어떤 취약점이 영향을 미치는가"를 기계가 읽을 수 있는 형태로 답한다.

12장 · Syft · Grype — Anchore의 SBOM 도구

**Syft**(github.com/anchore/syft)는 Anchore가 만든 멀티 포맷 SBOM 생성기. 무료·오픈소스.

- **입력** — 컨테이너 이미지, 파일시스템 디렉토리, OCI archive.

- **출력 포맷** — CycloneDX, SPDX, Syft JSON, GitHub Dependency Snapshot, text.

- **감지 패키지** — npm, PyPI, Maven, Go modules, Rust crates, RubyGems, Debian/RPM 패키지, Java JAR, Python wheels.

syft alpine:3.20 -o cyclonedx-json=sbom.cdx.json

syft alpine:3.20 -o spdx-json=sbom.spdx.json

**Grype**(github.com/anchore/grype)는 같은 Anchore의 취약점 스캐너. Syft가 만든 SBOM을 입력으로 받는다.

- **DB** — NVD + OSV + GitHub Advisory + Anchore의 큐레이션.

- **출력** — table, JSON, SARIF.

- **VEX 지원** — `--vex` 옵션으로 거짓 양성 제거.

Anchore Enterprise는 Syft·Grype를 SaaS·온프렘 플랫폼으로 묶어 정책 엔진(Anchore Policy)을 추가한다.

13장 · Trivy · Microsoft SBOM Tool

**Trivy**(github.com/aquasecurity/trivy)는 Aqua Security가 만든 종합 보안 스캐너. iter79에서 별도로 다뤘지만 공급망 보안에서 중심 도구.

- **컨테이너 이미지 스캔** — OS 패키지 + 언어 의존성 + IaC + 시크릿.

- **SBOM 생성** — CycloneDX, SPDX 출력.

- **SBOM 스캔** — 기존 SBOM을 입력으로 받아 취약점 스캔.

trivy image --format cyclonedx --output sbom.json alpine:3.20

trivy sbom sbom.json

Trivy는 무료·오픈소스. Aqua Enterprise(상용)는 클러스터 전체 스캔·정책·CI 통합 추가.

**Microsoft SBOM Tool**(github.com/microsoft/sbom-tool)은 MS 사내용으로 시작해 2022년 OSS화. Windows·.NET 생태계에 강점. SPDX 2.2 출력.

sbom-tool generate -b ./build -bc ./src -nsb https://example.com/sbom

MS는 사내 모든 빌드에 SBOM Tool을 의무화. Visual Studio·Azure DevOps와 통합.

14장 · GitHub Dependency Graph · Dependabot · Snyk SBOM

**GitHub Dependency Graph**는 GitHub이 자동 생성하는 의존성 트리. 거의 모든 패키지 매니저 lockfile을 파싱.

- **Dependabot Alerts** — 의존성 취약점 발견 시 자동 알림.

- **Dependabot Security Updates** — 자동 PR 생성으로 패치 적용.

- **Dependency Review** — PR에서 새 의존성 추가 시 라이선스·취약점 차이 표시.

- **SBOM Export** — Settings → Dependency graph → Export SBOM (SPDX 2.3).

GitHub Advanced Security(GHAS)를 구매하면 CodeQL(SAST) + Secret Scanning + Push Protection 등 추가.

**Snyk SBOM**(snyk.io)은 상용 제품의 SBOM 모듈. Snyk Open Source(의존성 스캔)와 Snyk Code(SAST), Snyk Container(이미지 스캔)와 통합. CycloneDX·SPDX 출력.

**Mend**(formerly WhiteSource, mend.io)도 같은 카테고리. 라이선스 컴플라이언스에 강점. SBOM 모듈로 CycloneDX 출력.

15장 · Image Signing — cosign · Notary v2 · TUF

이미지 서명의 표준이 여러 개 공존한다.

**cosign / Sigstore** — 3장 참고. 키 없는 서명. 사실상 사실상의 표준(de facto).

**Notary v2**(notaryproject.dev)는 CNCF Incubating 프로젝트. Docker Notary v1의 후속.

- **OCI Image 표준 채택** — 서명을 OCI artifact로 registry에 저장.

- **다양한 서명 알고리즘** — RSA, ECDSA, EdDSA.

- **Azure Key Vault, AWS KMS 통합** — 엔터프라이즈 KMS 친화.

- **notation CLI** — cosign과 유사하나 키 기반.

Notary v2와 cosign은 동일 OCI registry에 공존할 수 있다. AWS·Azure는 KMS 기반 키를 선호해 Notary v2를 밀고, Google·OpenSSF는 cosign을 민다.

**Docker Content Trust(DCT)**는 Notary v1 시절의 legacy. 2026년에는 거의 사용되지 않음.

**TUF**(theupdateframework.io, The Update Framework)는 CNCF Graduated. 업데이트 메커니즘의 일반 프레임워크. cosign·notation 모두 TUF의 원리를 일부 차용. PyPI의 PEP 458 secure package signing이 TUF 기반.

16장 · Chainguard Images · Wolfi OS — Distroless의 진화

**Chainguard**(chainguard.dev)는 2021년 Dan Lorenc, Kim Lewandowski 등 Google 출신이 창립. Sigstore 공동 창립자들이 만든 회사.

핵심 제품 — **Chainguard Images**.

- **이미지 종류** — nginx, python, go, node, php, openjdk, postgres 등 350여 종.

- **베이스** — 자체 OS인 **Wolfi**.

- **특징** — distroless(쉘 없음), Sigstore 서명, SBOM 동봉, **목표 CVE 0개**.

Wolfi의 차별점.

- **undistro** — 기존 distro와 다르게 시작한 OS. glibc 기반(Alpine은 musl).

- **rolling release** — 패키지 최신 버전 즉시 반영.

- **빌드 도구** — apko(이미지 빌더), melange(패키지 빌더) 모두 OSS.

가격(2026년 5월).

- **Chainguard Free** — 공개 이미지 사용 무료(community).

- **Chainguard Production** — SLA, 장기 지원, 사내 mirror, FIPS 인증 이미지. 가격 비공개(엔터프라이즈).

- **Chainguard Custom** — 사용자 정의 베이스 이미지 빌드 서비스.

전략적으로 Red Hat UBI, Google Distroless의 시장을 정조준한다. 2024-2025년 Chainguard는 시리즈 D 1억 4천만 USD 등을 모으며 평가액 약 30억 USD를 기록.

17장 · Google Distroless · Red Hat UBI Minimal · BuildPacks

**Google Distroless**(github.com/GoogleContainerTools/distroless)는 Google이 2017년 출범시킨 OSS. 쉘·패키지 매니저 없는 최소 이미지.

- **base-nossl** — 단순 cgo 미사용 Go 바이너리용.

- **cc** — glibc 포함, C/C++/Go.

- **nodejs / java / python** — 언어 런타임 포함, 패키지 매니저 없음.

Distroless는 무료·오픈소스. 하지만 Chainguard와 달리 SBOM·서명·CVE 모니터링 같은 부가 서비스는 없다.

**Red Hat UBI Minimal**(catalog.redhat.com)은 Red Hat의 Universal Base Image. RHEL 호환. microdnf 패키지 매니저 포함(완전 distroless는 아님). 엔터프라이즈 RHEL 고객 친화.

**BuildPacks**(buildpacks.io)는 CNCF Incubating. 컨테이너 빌드를 Dockerfile 없이 자동화.

- **Paketo Buildpacks**(VMware) — Java, Node, Python, Go, Ruby 등.

- **Heroku Buildpacks** — Heroku PaaS의 빌드 시스템에서 유래.

- **Google Cloud Buildpacks** — Cloud Run, App Engine에서 사용.

BuildPacks의 장점 — Dockerfile 표면적 축소로 misconfiguration·취약점 감소. 자동 base image 업데이트.

**Apko, Melange**(github.com/chainguard-dev/apko, github.com/chainguard-dev/melange)는 Chainguard가 만든 빌드 도구. apko는 YAML 선언으로 이미지 생성, melange는 패키지 빌드. Wolfi 빌드의 기반.

18장 · Socket.dev — npm/PyPI 행동 분석

**Socket**(socket.dev)는 2022년 Feross Aboukhadijeh가 창립. Node.js 생태계의 베테랑(Standard JS, WebTorrent 등).

문제 의식. **npm·PyPI의 새 패키지·새 버전이 매일 수만 건 올라오는데, 사람이 일일이 검토할 수 없다.**

Socket의 접근.

- **AST 분석** — 모든 새 패키지를 정적 분석. 의심스러운 패턴(eval, child_process, fs.readFileSync 등) 자동 점수화.

- **install script 분석** — npm preinstall·postinstall, PyPI setup.py 코드를 실행 전 검사.

- **네트워크 통신 탐지** — 의심스러운 도메인·IP·텔레메트리 검출.

- **타이포스쿼팅 탐지** — 인기 패키지 이름과의 편집 거리 측정.

- **메인테이너 변경 추적** — 새 메인테이너 추가 시 알림.

PR에 Socket Bot이 댓글로 위험을 표시한다. GitHub Marketplace에서 무료로 설치 가능. 유료 플랜은 SAST·SBOM·정책 엔진을 추가.

가격(2026년 5월).

- **Free** — 오픈소스 프로젝트, 개인.

- **Team** — 월 사용자당 8 USD.

- **Enterprise** — 가격 협의.

XZ Utils 사건 직후 Socket이 자사 분석에서 Jia Tan의 특이 패턴(릴리즈 권한 추가 후 즉시 큰 변경)을 사후에 잡아낼 수 있었다고 발표. 비슷한 패턴 탐지를 본격 도입.

19장 · JFrog Xray · Black Duck — 엔터프라이즈 의존성 스캔

**JFrog Xray**(jfrog.com/xray)는 JFrog Artifactory의 보안 모듈. Artifactory를 쓰는 모든 회사에 자연스러운 추가 옵션.

- **타깃** — JFrog Artifactory 저장소의 모든 아티팩트.

- **스캔** — CVE, 라이선스, 운영 위험(deprecated 패키지 등).

- **차단 정책** — Artifactory에서 위험 패키지 다운로드 차단.

- **SBOM** — CycloneDX·SPDX 출력.

- **Curation**(2024 추가) — 안전한 패키지만 골라서 사내 레포에 미러링.

JFrog 통합이 강점이지만 그게 단점이기도. Artifactory를 안 쓰면 Xray 도입 이유가 약해진다.

**Black Duck**(blackduck.com)는 Synopsys의 SCA 사업을 2024년 9월에 분사한 회사. 정식 명칭은 Black Duck Software Composition Analysis.

- **역사** — 2002년 창립. SCA(Software Composition Analysis) 카테고리를 사실상 정의.

- **KnowledgeBase** — 500만 개 이상의 오픈소스 컴포넌트·라이선스 DB.

- **강점** — 라이선스 컴플라이언스, 듀딜리전스 보고서(M&A 시 사용).

- **SBOM** — CycloneDX·SPDX.

Black Duck은 라이선스 리스크에 강하고 가격이 비싸다. 자동차·의료·금융 같은 엄격한 산업에서 표준. 가격 비공개(엔터프라이즈).

20장 · Snyk Open Source · Snyk Container

**Snyk**(snyk.io)는 2015년 영국에서 창립. 2022년 가치 평가 80억 USD까지 갔다가 2023-2024 다운라운드.

제품군.

- **Snyk Open Source** — npm·PyPI·Maven·NuGet 등 의존성 스캔 + 라이선스.

- **Snyk Code** — SAST(자체 엔진, DeepCode 인수 기반).

- **Snyk Container** — 컨테이너 이미지 스캔.

- **Snyk IaC** — Terraform·Kubernetes·CloudFormation 스캔.

가격(2026년 5월).

- **Free** — 월 200회 테스트.

- **Team** — 월 사용자당 25 USD.

- **Enterprise** — 가격 협의.

Snyk의 강점 — 개발자 친화 UX, IDE 플러그인(VS Code, JetBrains), GitHub/GitLab 통합. 약점 — 가격이 빠르게 비싸진다.

2024년 Snyk은 SBOM 기능을 강화하고, AppRisk Pro라는 ASPM(Application Security Posture Management) 제품으로 확장 중. Endor Labs·Apiiro·OX Security·Cycode 같은 ASPM 신생 기업과 경쟁.

21장 · Phylum · Stacklok · Endor Labs — 차세대 공급망 보안

**Phylum**(phylum.io)는 2020년 창립. ML 기반 패키지 위험 점수화.

- **분석 모델** — 메인테이너, 코드 패턴, 라이브러리 이력 등 280+ heuristic.

- **타깃 패키지 매니저** — npm, PyPI, RubyGems, Maven, NuGet, Cargo, Go.

- **제로데이 차단** — 새 패키지가 등록되는 즉시 분석.

**Stacklok**(stacklok.com)은 2023년 Craig McLuckie(Kubernetes 공동 창립자), Luke Hinds(Sigstore 공동 창립자)가 창립.

- **제품 — Minder** — 공급망 보안 정책 엔진. Sigstore·OPA·GUAC 통합.

- **제품 — Trusty** — 패키지 위험 점수 무료 서비스.

- **제품 — Frizbee** — SHA 핀 도구(8장).

Stacklok은 본질적으로 Sigstore 창립자들이 회사화한 것. OSS 우선 전략.

**Endor Labs**(endorlabs.com)는 2022년 Varun Badhwar(전 Palo Alto/RedLock 창립자)가 창립.

- **Reachability Analysis** — "이 패키지의 취약점이 실제로 우리 코드에서 호출되는가" 정밀 추적. CVE 노이즈 큰폭 감소.

- **Phantom Dependencies** — package.json에 없는데 실제로 import되는 패키지 검출.

- **License Risk** — 듀얼 라이선스, 카피레프트 위험.

- **SBOM + VEX** — 자동 VEX 생성으로 "영향 없음" 표시.

Endor Labs는 시리즈 B 7천만 USD(2023), 2024년 1.6억 USD 추가. ASPM 카테고리 리더 중 하나.

22장 · GitHub Actions OIDC + Artifact Attestations

**GitHub Actions OIDC**는 GitHub Actions 워크플로가 OIDC 토큰을 받아 외부 클라우드(AWS, GCP, Azure)에 IAM 역할로 인증하는 메커니즘. 2022년 GA. 정적 secret(AWS_ACCESS_KEY) 제거.

permissions:

id-token: write

contents: read

jobs:

deploy:

runs-on: ubuntu-latest

steps:

- uses: aws-actions/configure-aws-credentials@v4

with:

role-to-assume: arn:aws:iam::123:role/github-actions

aws-region: us-east-1

**GitHub Artifact Attestations**(2024년 5월 GA)는 OIDC + Sigstore + in-toto의 통합. 워크플로 산출물에 자동으로 provenance를 첨부.

- uses: actions/attest-build-provenance@v1

with:

subject-path: dist/myapp

이 한 줄로 SLSA Build Level 3 수준의 provenance가 자동 생성, Sigstore 서명, rekor에 기록된다. 검증은 `gh attestation verify`.

2026년 5월 현재 GitHub Actions는 OSS 공급망 보안의 사실상 표준. GitLab CI, CircleCI도 유사 OIDC를 제공하지만 채택률은 GitHub이 압도적.

23장 · GitLab CI · Buildkite · Tekton Chains

**GitLab CI**는 GitLab의 내장 CI/CD. 2023년부터 SLSA provenance 생성을 Premium 이상에서 지원.

- **OIDC** — `id_tokens` 키워드로 AWS·GCP·HashiCorp Vault 인증.

- **Container Scanning** — Trivy 통합.

- **Dependency Scanning** — Gemnasium(GitLab 자체) + 외부 DB.

- **SBOM Export** — Ultimate에서 CycloneDX 출력.

**Buildkite**(buildkite.com)는 호주에서 시작한 CI. Hybrid 모델(SaaS 컨트롤 플레인 + 자체 호스팅 에이전트). 2024년부터 Signed Pipelines 기능. 파이프라인 정의 자체를 서명해 변조 방지.

**CircleCI**는 2023년 1월 자체 보안 사고(고객 secret 유출) 후 OIDC 강조. 2024년 SLSA Level 3 자동화.

**Tekton Chains**(tekton.dev/docs/chains)는 CNCF Tekton의 보안 모듈. Tekton 파이프라인의 모든 TaskRun·PipelineRun에 자동 attestation 생성. Sigstore 서명. Red Hat OpenShift Pipelines 기본 포함.

24장 · 패키지 매니저의 OIDC 서명 — PyPI · npm · RubyGems

패키지 매니저들이 OIDC로 발행자 검증을 도입했다. 메인테이너의 비밀번호·API 토큰 유출이 곧 악성 릴리즈로 이어지는 위험을 줄인다.

**PyPI Trusted Publishers**(docs.pypi.org/trusted-publishers)는 2023년 4월 GA. GitHub Actions·GitLab CI·Google Cloud Build의 OIDC 토큰을 직접 신뢰. 별도 PyPI API 토큰 불필요.

- uses: pypa/gh-action-pypi-publish@release/v1

with:

No api-token! OIDC만 사용

repository-url: https://upload.pypi.org/legacy/

PyPI는 2024년 11월 보안 패키지에 대한 외부 점검을 강화하고 2FA 의무화 완료.

**npm provenance**(docs.npmjs.com/generating-provenance-statements)는 2023년 4월 GA. `npm publish --provenance` 옵션. GitHub Actions OIDC 기반. provenance가 npm 패키지 페이지에 "Provenance" 배지로 표시.

**RubyGems trusted publishing**도 2024년 후반 도입. 비슷한 OIDC 기반.

**Crates.io**(Rust)는 2024년 새 보안 모델을 발표(RFC 2706 등). aud 검증·OIDC 기반.

**Maven Central**은 2024년 PGP 서명을 강화하고, signing portal을 새로 만들었다. OIDC 직접 도입은 2026년 진행 중.

25장 · 취약점 데이터베이스 비교 — NVD · OSV · GHSA · KEV

**NVD**(nvd.nist.gov)는 NIST의 National Vulnerability Database. CVE에 CVSS 점수·CPE 매칭 추가. 2024년 2월부터 분석이 지연됨이 광범위하게 알려졌고, NIST가 외부 위탁 등 대안 발표.

**OSV**(osv.dev)는 9장 참고. 2024년 NVD 슬로다운 이후 사실상 OSS 표준.

**GHSA**(GitHub Security Advisories, github.com/advisories)는 GitHub이 발행하는 advisory. CVE 발급도 자동 처리. Dependabot의 데이터 소스.

**KEV**(CISA Known Exploited Vulnerabilities, cisa.gov/known-exploited-vulnerabilities-catalog)는 미국 CISA가 운영. 실제로 공격에 사용된 CVE만 기재. 미국 연방 시스템은 KEV 등재 CVE를 단기간 내 패치 의무.

선택 기준.

- **포괄성** — NVD가 가장 광범위했으나 2024년 슬로다운으로 OSV·GHSA에 우위 상실.

- **속도** — GHSA·OSV가 가장 빠름.

- **실제 위험** — KEV가 가장 정확. 양보다 질.

- **상용 데이터** — Snyk DB, Rapid7, Tenable DB가 자체 큐레이션 추가.

26장 · 규제 환경 — US EO 14028 · CISA · EU CRA · NIST SSDF

**Executive Order 14028**(2021년 5월, 바이든)은 미국 연방기관 사이버보안 강화. SBOM·zero trust·incident reporting 의무.

**NIST SSDF**(Secure Software Development Framework, NIST SP 800-218)는 EO 14028의 후속. 안전한 SDLC 실천 가이드. 4개 그룹·19개 실천 항목.

**CISA Secure Software Development Attestation Form**(2024년 3월 발표)은 EO 14028 이행 핵심. 미국 연방기관에 소프트웨어를 판매하는 벤더가 CEO·임원 서명으로 NIST SSDF 준수를 선언. 거짓 진술 시 형사 처벌 가능.

**EU Cyber Resilience Act(CRA)**는 2024년 10월 EU 의회 채택. 2027년 12월 본격 시행 예정. 디지털 제품에 사이버보안 의무.

- **CE 마크** — 해킹 가능성이 있는 제품(IoT, 소프트웨어)에 CE 마크 의무.

- **SBOM** — 시장에 출시하는 모든 제품에 SBOM 동봉.

- **취약점 보고** — 24시간 내 ENISA·국가 CSIRT 보고.

- **벌금** — 매출 2.5 % 또는 15M EUR 중 큰 금액.

OSS 메인테이너는 처음에는 우려가 컸으나(OSS 면제 명시) 최종안에서 "상업적으로 제공되는 모든 디지털 제품"으로 한정되어 비-상업적 OSS는 면제.

**PCI DSS 4.0**(2024년 3월 의무화)은 결제 카드 산업 표준. SBOM·SAST/DAST·secret 관리 강화.

27장 · 한국·일본 공급망 보안 가이드라인

**한국**.

- **ISMS-P**(정보보호 및 개인정보보호 관리체계 인증) — KISA가 운영. 공급망 보안 항목이 2024년 개정에서 강화.

- **금융보안원(FSI) SBOM 가이드**(2024년 9월 발표) — 금융기관의 SBOM 도입 권고안. CycloneDX·SPDX 권고.

- **삼성 SDS, LG CNS, NCSOFT** — 사내 SBOM 시스템 운영. 자체 의존성 큐레이션 레지스트리.

- **Naver Whale, Kakao 보안센터** — 외부 패키지 사용 정책 강화. 2024년 KakaoTalk 보안 사고 후 공급망 점검.

- **소프트웨어 진흥법** — 2024년 개정으로 공공 SW 사업에 SBOM 요구.

**일본**.

- **IPA Software Supply Chain Security Guidelines**(2023년 12월 1.0판) — 정보처리추진기구가 발표. CycloneDX 권고.

- **NISC**(내각관방 사이버보안센터) — 정부 시스템 공급망 보안 표준.

- **METI**(경제산업성) — 사이버보안 경영 가이드라인 3.0에 공급망 항목 추가.

- **NTT Communications**(Group-CSIRT) — SBOM·SCA 자체 운영. 사내 안전 패키지 레지스트리.

- **GMO Cybersecurity by IERAE** — SBOM·SCA 컨설팅 + JVN 통합 솔루션.

- **자동차 산업** — UN R155 사이버보안 의무화로 토요타·혼다·닛산이 1차 협력사까지 SBOM 요구.

28장 · 산업별 특수 요구 — 의료 · 자동차 · 금융

**의료(미국)**. FDA가 2023년 10월부터 의료기기에 대한 사이버보안 의무화. Section 524B 의료기기 사이버보안.

- **SBOM 의무** — 모든 신규 의료기기 510(k) 제출 시 SBOM 동반.

- **취약점 모니터링** — 출하 후 평생 모니터링.

- **소프트웨어 업데이트** — 보안 패치 배포 계획 제출.

GE Healthcare, Medtronic, Philips, Siemens Healthineers가 자체 SBOM 워크플로 강화.

**자동차**. UN R155(2022년부터 신차 형식 인증 의무)와 ISO/SAE 21434.

- **CSMS**(Cyber Security Management System) — 자동차 OEM·1차 협력사 의무.

- **SBOM·VEX** — 차량 소프트웨어 컴포넌트 추적.

- **OTA 업데이트** — 무선 보안 패치 배포 표준.

토요타·BMW·GM·포드·테슬라가 모두 영향. 한국 현대차·기아도 글로벌 판매에서 R155 영향권.

**금융**. PCI DSS 4.0(2024년 3월), 한국 전자금융감독규정, 일본 FISC 안전대책기준.

- **결제 카드 환경** — SBOM·SAST/DAST 의무.

- **시스템 리스크** — 결제 단절이 시스템 리스크. 3rd party SW 위험 평가 필수.

한국 금융보안원의 2024년 SBOM 가이드도 이 흐름.

29장 · 실전 도입 로드맵 — 0개월부터 12개월까지

도입은 점진적이어야 한다. 한 번에 모든 도구를 던지면 개발팀이 무력화된다. 12개월 로드맵 예시.

[0-1개월] 가시성 확보

- GitHub Dependency Graph + Dependabot 활성화 (무료)

- Trivy로 모든 컨테이너 이미지 스캔 시작

- Syft로 SBOM 생성 시범 (CycloneDX 출력)

[1-3개월] 자동화 도입

- Socket Bot GitHub Marketplace 설치

- Snyk 또는 Endor Labs PoC 진행

- CI/CD에 OIDC 도입 (GitHub Actions → AWS IAM Role)

[3-6개월] 빌드 무결성

- SLSA Build Level 2 달성 (provenance 자동 생성)

- GitHub Actions Artifact Attestations 도입

- Sigstore cosign으로 컨테이너 이미지 서명

[6-9개월] 베이스 이미지 강화

- Chainguard Images 또는 Google Distroless 전환

- Frizbee로 모든 GitHub Action을 SHA 핀

[9-12개월] 정책 강제

- Kyverno 또는 Sigstore policy-controller로

서명 안된 이미지 배포 차단

- SLSA Build Level 3 달성

- SBOM·VEX를 고객·감사인에게 정기 발행

각 단계는 측정 가능한 산출물이 있어야 한다. "SBOM이 있다"는 만족이 아니라 "취약점 평균 패치 시간이 30일에서 7일로 줄었다"가 진짜 목표.

30장 · 의사결정 — 어떤 도구를 언제 쓸 것인가

[OSS·개인 프로젝트]

→ GitHub Dependabot + Trivy + Sigstore (모두 무료)

→ OpenSSF Scorecard 점수 모니터링

→ 의존성 적게 유지

[스타트업·중소 SaaS]

→ Snyk Free 또는 Socket Free

→ GitHub Actions Artifact Attestations

→ Chainguard Images (community)

→ Syft로 SBOM 자동 생성

[엔터프라이즈 — 금융·의료·자동차]

→ JFrog Xray (Artifactory 사용 시)

→ Black Duck (라이선스 컴플라이언스)

→ Chainguard Production

→ Endor Labs 또는 Snyk Enterprise

→ SLSA Level 3 + cosign + Kyverno

[정부·국방]

→ CISA Attestation Form 작성

→ NIST SSDF 전면 이행

→ SBOM + VEX 정기 발행

→ KEV 등재 CVE 단기간 내 패치

선택의 핵심은 "필요한 만큼"이다. 의존성 50개짜리 프로젝트에 Endor Labs Enterprise는 과잉. 의존성 5,000개짜리 결제 시스템에 Trivy만 쓰는 것은 부족.

31장 · 자가 점검 체크리스트

공급망 보안 도구를 도입할 때 8가지 질문.

1. 의존성 lockfile이 있고, CI가 lockfile을 검증하나?

→ package-lock.json, poetry.lock 누락 시 즉시 도입.

2. 컨테이너 이미지가 매 빌드마다 스캔되나?

→ Trivy·Grype·Snyk Container 중 하나는 필수.

3. CI 토큰이 정적 secret인가, OIDC인가?

→ AWS_ACCESS_KEY 같은 정적 키는 즉시 OIDC로 교체.

4. 새 의존성 추가 시 누가 검토하나?

→ Socket·Phylum 같은 자동 분석 도입.

5. 베이스 이미지 출처를 추적할 수 있나?

→ Chainguard·Distroless·UBI 중 하나로 통일.

6. 빌드 산출물에 provenance가 있나?

→ SLSA Build Level 2 이상 권장.

7. 취약점 발견 시 평균 패치 시간은?

→ KEV는 24-72시간, 나머지는 30-90일 SLA.

8. SBOM을 고객·감사인에게 발행하나?

→ CISA Attestation·EU CRA 대비.

이 8개 중 5개 이상을 충족하지 못하면 공급망 공격에 노출되어 있다. SolarWinds·Log4Shell·XZ 같은 사건이 일어나면 회사가 회복하지 못한다.

에필로그 — 신뢰는 만드는 것이지 가정하는 것이 아니다

이 글이 그린 지도는 60여 개의 도구·표준·사건으로 가득하다. Sigstore·SLSA·SBOM·Chainguard·Socket·JFrog·Snyk·Endor Labs·Phylum·GUAC·in-toto·OpenSSF Scorecard·CycloneDX·SPDX. 각각이 자신의 자리에서 의미가 있다.

하지만 2026년 공급망 보안의 핵심 진실은 이렇다. **신뢰는 기본값이 아니다. 신뢰는 만드는 것이다.** 메인테이너의 이메일 주소, GitHub의 별 개수, npm 다운로드 수는 신뢰의 근거가 아니다. 서명, attestation, 재현 가능 빌드, 행위 분석이 신뢰의 근거다.

XZ Utils 사건이 보여준 교훈은 차갑다. 2년에 걸친 사회공학적 침투를 사람의 직관만으로 막을 수 없다. Andres Freund의 발견은 우연이었고, 다음 침투는 발견되지 않을 수 있다. 그 사실이 도구·표준·자동화의 도입을 미룰 수 없는 이유.

이 글을 다 읽었다면 오늘 한 가지만 정해두자. **자기 프로젝트의 의존성 트리를 한 번 출력해 보기.** `npm ls --all`, `pip list`, `mvn dependency:tree`, `go mod graph`. 그 출력에 1,500개 이상의 패키지가 있다면, 그것이 자기 회사의 진짜 공급망이다. 그 1,500개의 신뢰가 어떻게 형성되어 있는지 묻는 게 시작이다.

좋은 도구, 좋은 표준, 좋은 메인테이너. Sigstore와 SLSA는 그 세 가지를 잇는 다리일 뿐이다.

부록 · 빠른 명령어 참고

SBOM 생성

syft alpine:3.20 -o cyclonedx-json=sbom.cdx.json

trivy image --format spdx-json -o sbom.spdx.json alpine:3.20

이미지 서명 (cosign + GitHub OIDC)

cosign sign --yes registry.example.com/myapp:v1.0.0

이미지 검증

cosign verify --certificate-identity-regexp 'https://github.com/myorg/.*' \

--certificate-oidc-issuer https://token.actions.githubusercontent.com \

registry.example.com/myapp:v1.0.0

Attestation 검증 (GitHub CLI)

gh attestation verify oci://registry.example.com/myapp:v1.0.0 \

--repo myorg/myapp

OSV 스캔

osv-scanner --lockfile=package-lock.json

osv-scanner --docker alpine:3.20

Scorecard 점수 확인

scorecard --repo=github.com/myorg/myproject

참고 자료

- [OpenSSF](https://openssf.org/)

- [Sigstore](https://www.sigstore.dev/)

- [SLSA Framework](https://slsa.dev/)

- [in-toto](https://in-toto.io/)

- [GUAC](https://guac.sh/)

- [OpenSSF Scorecard](https://scorecard.dev/)

- [OSV.dev](https://osv.dev/)

- [CycloneDX](https://cyclonedx.org/)

- [SPDX](https://spdx.dev/)

- [CSAF (OASIS)](https://oasis-open.github.io/csaf-documentation/)

- [Syft (Anchore)](https://github.com/anchore/syft)

- [Grype (Anchore)](https://github.com/anchore/grype)

- [Trivy (Aqua)](https://trivy.dev/)

- [Microsoft SBOM Tool](https://github.com/microsoft/sbom-tool)

- [GitHub Artifact Attestations](https://docs.github.com/en/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds)

- [GitHub Advisory Database](https://github.com/advisories)

- [CISA KEV Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)

- [CISA Secure Software Development Attestation](https://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-form)

- [Executive Order 14028](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/)

- [NIST SSDF (SP 800-218)](https://csrc.nist.gov/publications/detail/sp/800-218/final)

- [EU Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)

- [Chainguard](https://www.chainguard.dev/) · [Wolfi](https://wolfi.dev/)

- [Google Distroless](https://github.com/GoogleContainerTools/distroless)

- [Red Hat UBI](https://catalog.redhat.com/software/base-images)

- [Socket](https://socket.dev/)

- [JFrog Xray](https://jfrog.com/xray/)

- [Black Duck](https://www.blackduck.com/)

- [Snyk](https://snyk.io/)

- [Phylum](https://www.phylum.io/) · [Stacklok](https://stacklok.com/) · [Endor Labs](https://www.endorlabs.com/)

- [PyPI Trusted Publishers](https://docs.pypi.org/trusted-publishers/)

- [npm Provenance](https://docs.npmjs.com/generating-provenance-statements)

- [Andres Freund XZ Backdoor Disclosure (oss-security)](https://www.openwall.com/lists/oss-security/2024/03/29/4)

- [Tekton Chains](https://tekton.dev/docs/chains/)

- [Frizbee (Stacklok)](https://github.com/stacklok/frizbee)

- [AllStar (OpenSSF)](https://github.com/ossf/allstar)

- [IPA Software Supply Chain Security Guidelines (Japan)](https://www.ipa.go.jp/security/reports/oversea/supplychain/index.html)

- [금융보안원 (Korea FSI)](https://www.fsec.or.kr/)

- [KISA ISMS-P](https://isms.kisa.or.kr/)