피드로 돌아가기
Dev.to
원문 읽기
GitHub Actions 의존성을 추적하지 않아 2026년 Trivy 공급망 공격 때 76개 중 77개 릴리스 태그의 악성코드를 탐지하지 못한 문제를 ABOM(Actions Bill of Materials)으로 해결
Introducing the ABOM: Why Your CI/CD Pipelines Need a Bill of Materials
AI 요약
Context
GitHub Actions는 애플리케이션 코드의 SBOM(Software Bill of Materials)과 달리 파이프라인 의존성을 추적하지 않고 있다. 직접 명시하지 않은 composite actions, reusable workflows, 내장 도구(Trivy, Grype, Snyk 등)에 대한 가시성이 전무하다. 2026년 3월 Trivy 포이즈닝 공격 시 AWS 자격증명, Kubernetes 토큰, Docker 설정, SSH 키를 탈취한 후 npm 자격증명으로 자가증식 웜을 배포했으나 grep으로 검색 가능한 직접 의존성이 없어 피해 범위를 파악할 수 없었다.
Technical Solution
- ABOM 정의 및 구성: 직접 의존성(workflow에서 명시한 actions), 전이 의존성(composite actions, reusable workflows 내 actions), 내장 도구(action 메타데이터·입력값 분석으로 감지)를 재귀적으로 매핑
- 각 action 메타데이터 기록: owner, repository, version reference, SHA 고정 여부, workflow로부터의 전체 호출 체인 기록
- 표준 포맷 지원: CycloneDX 1.5(component + 의존성 그래프 + 취약점 매핑), SPDX 2.3(package + DEPENDS_ON 관계)으로 Dependency-Track, Grype 등 기존 도구와 통합
- CI 게이팅 구현: pull request마다 ABOM 생성 후 알려진 손상된 action 존재 시 빌드 실패(애플리케이션 CVE 게이팅과 동일한 방식)
- 운영 자동화:
abom scan명령어로 GitHub 메타데이터 페칭, 로컬 캐싱, 커뮤니티 관리 advisory 데이터베이스 조회
Key Takeaway
CI/CD 파이프라인은 클라우드 자격증명과 배포 권한을 가진 고가치 공격 대상이므로 애플리케이션 의존성과 동일한 수준의 SBOM 기반 추적 및 게이팅이 필수다. 직접 의존성 검색만으로는 공급망 침투 범위를 파악할 수 없으므로 전이 의존성과 내장 도구까지 포함한 완전한 인벤토리가 필요하다.