GitHub Actions에는 패키지 관리자가 있지만, 최악일 수 있다

• GitHub Actions는 워크플로 파일의 uses: 구문을 통해 패키지 의존성을 선언하고 실행하는 구조를 가지며, 이는 사실상 패키지 관리자 역할을 수행
• 그러나 락파일(lockfile), 무결성 해시, 전이 의존성 고정, 의존성 트리 가시성 등 다른 패키지 관리자들이 기본으로 제공하는 기능이 전혀 없음
• 연구 결과, 대부분의 GitHub Actions 사용자가 검증되지 않은 외부 코드를 실행하며, 코드 주입 취약점이 수천 개 워크플로에서 발견됨
• GitHub이 일부 완화책(불변 릴리스, SHA 고정 정책 등)을 도입했지만, 전이 의존성이나 재현성 문제는 여전히 해결되지 않음
• 이러한 구조적 결함은 소프트웨어 공급망 보안 전반에 영향을 미치며, GitHub Actions를 기반으로 한 다른 CI 시스템에도 동일한 문제가 전파됨

GitHub Actions의 패키지 관리 구조와 문제점

• uses: actions/checkout@v4 같은 구문은 의존성 선언이며, GitHub이 이를 해석해 다운로드 및 실행함
  • 이는 일반적인 패키지 관리 동작과 동일하지만, 락파일이 없어 실행마다 다른 버전이 선택될 수 있음
• 다른 패키지 관리자(npm, Cargo, NuGet 등)와 비교했을 때, Actions는 락파일, 전이 핀닝, 무결성 검증, 의존성 트리 가시성, 해석 명세 모두 결여
• 락파일 부재가 핵심 문제로, 실행 시마다 의존성 해석이 달라져 비결정적 빌드가 발생

보안 연구 결과와 취약성

• USENIX Security 2022 연구에 따르면, 99.7%의 리포지토리가 외부 개발자의 Actions를 실행하고, 97%는 검증되지 않은 제작자, 18%는 보안 업데이트 누락 상태
• 후속 연구에서는 2.7백만 워크플로 중 4,300개 이상에서 코드 주입 취약점이 발견됨
• GitHub Actions는 admittance control, execution control, code control, secrets 접근 제어 등 CI/CD 필수 보안 속성을 충분히 제공하지 않음

주요 기술적 결함

• 가변 버전 문제: @v4 같은 태그는 유지자가 새 커밋으로 재태깅할 수 있어, 코드가 조용히 변경됨
  • 락파일이 있다면 해당 태그가 어떤 SHA로 해석되었는지 기록 가능
• 전이 의존성 불투명성: Composite Action 내부에서 호출하는 다른 Action은 보이지 않으며 제어 불가
  • 연구에 따르면 JavaScript Actions의 54%가 보안 약점을 포함하며, 대부분이 간접 의존성에서 발생
  • tj-actions/changed-files 사건에서는 전이 의존성 업데이트를 통해 비밀 유출 공격이 발생
• 무결성 검증 부재: npm이나 Cargo는 해시를 기록해 다운로드 검증을 수행하지만, Actions는 SHA 기반 신뢰에만 의존
• 재실행 비재현성: GitHub 측이 “버전이 강제 푸시되면 최신 버전을 가져온다”고 명시, 같은 워크플로라도 다른 코드 실행 가능
• 의존성 트리 비가시성: npm의 npm ls나 Cargo의 cargo tree 같은 기능이 없어, 전체 의존성 구조를 확인할 방법 없음
• 해석 규칙 비공개: Actions의 의존성 해석은 문서화되지 않았으며, ActionManager.cs 코드에 단순한 재귀 다운로드 로직만 존재

추가 구조적 한계

• 중앙 레지스트리 부재: Actions는 Git 리포지토리에 존재하며, 보안 스캔·악성 탐지·타이포스쿼팅 방지 기능이 없음
• 공유 환경 문제: 여러 Action이 동일한 $PATH를 수정해 실행 순서에 따라 결과가 달라짐
• 오프라인 실행 불가: GitHub에서 매번 다운로드해야 하며, 네트워크 없이 실행 불가능
• 네임스페이스 취약성: GitHub 사용자명이 곧 네임스페이스로, 계정 탈취나 오타 공격에 노출
  • 락파일과 무결성 해시가 있다면 코드 변경 시 빌드 실패로 탐지 가능

설계 배경과 파급 효과

• Actions 러너는 원래 Azure DevOps 기반으로, 내부 신뢰 환경을 전제로 설계됨
  • GitHub이 이를 공용 마켓플레이스로 확장하면서 신뢰 모델을 재설계하지 않음
• 이로 인해 락파일, 무결성 검증, 전이 핀닝, 의존성 가시성 같은 기본 기능이 누락
• OIDC 기반 패키지 자동 배포 기능이 확산되면서, Actions의 보안 결함이 패키지 레지스트리 전체 공급망 보안에 영향
• GitLab CI는 integrity 키워드를 도입해 해시 검증을 지원하지만, GitHub은 동일 요청을 “계획 없음”으로 종료
• Forgejo Actions 등 GitHub 호환 CI 시스템도 동일한 구조를 유지해야 하므로, 결함이 생태계 전반으로 확산

개선 제안과 현황

• 커뮤니티는 락파일 지원(issue #2195) 을 요청했으나, GitHub은 2022년에 “계획 없음”으로 닫음
• Palo Alto 연구는 SHA 고정만으로는 전이 의존성 보호 불가함을 입증
• 일부 팀은 Dependabot 업데이트, 자체 리포지토리 벤더링, zizmor 보안 스캐너 등으로 보완
• 근본적 해결책은 모든 Action과 전이 의존성의 SHA 및 무결성 해시를 기록하는 락파일 도입
• GitHub이 이를 채택하지 않는 한, CI/CD 공급망의 신뢰성 확보는 불가능