GitHub Actions, 보안 취약점으로 오픈소스 생태계 위협

GitHub Actions의 pull_request_target 트리거(Trigger)는 외부 기여자의 코드를 신뢰하는 데서 발생하는 문제점을 보여준다. 특히, 이 트리거는 풀(Pull) 요청(Request)의 컨텍스트에서 실행되면서, 쓰기 권한(Write Permission)을 가진 토큰에 접근할 수 있다. 실제 사례로, spotbugs, Ultralytics, nx, Trivy 등에서 이 취약점을 악용한 공격이 발생했다. 이러한 공격은 코드 실행(Code Execution), 비밀 정보 유출(Secret Leakage), 그리고 공급망 공격(Supply Chain Attack)으로 이어졌다.

GitHub Actions에서 액션(Action) 버전은 가변적인 Git 참조(Git References)로 관리되어, 공격자가 손쉽게 악성 코드를 주입할 수 있다. 특히, 태그(Tag)를 이용한 액션 버전 관리는, 공격자가 해당 태그를 조작하여 악성 코드(Malicious Code)를 삽입하는 것을 가능하게 한다. tj-actions/changed-files 사건과 Trivy 액션의 경우, 이러한 취약점을 통해 지속적인 공격(Persistent Attack)이 이루어졌다. 이러한 문제는 SHA(Secure Hash Algorithm) 고정(Pinning)을 통해 완화할 수 있지만, 근본적인 해결책은 아니다.

GitHub는 보안 강화를 위한 기능을 제공하지만, 대부분 옵트인(Opt-in) 방식으로 제공되어, 적극적으로 보안을 챙기는 프로젝트만 혜택을 받는다. 이러한 소극적인 접근 방식은, 보안 취약점(Security Vulnerabilities)을 인지하지 못하는 프로젝트를 위험에 노출시킨다. 또한, GitHub의 기본 설정(Default Settings)이 보안에 취약하게 설정되어 있어, 근본적인 문제 해결이 어렵다는 비판이 제기된다. Zizmor와 같은 제3자 도구를 통해 보안을 강화할 수 있지만, 플랫폼 자체의 개선이 필요하다.

GitHub Actions를 통한 신뢰할 수 있는 게시(Trusted Publishing)는, PyPI, npm, RubyGems, crates.io와 같은 패키지 레지스트리의 보안을 강화하기 위해 도입되었다. 하지만, 이 방식은 GitHub Actions의 보안에 전적으로 의존하게 되면서, 단일 실패 지점(Single Point of Failure)을 만든다. 즉, GitHub Actions가 공격받으면, 해당 플랫폼을 통해 게시된 모든 패키지가 위험에 노출될 수 있다. 따라서, OIDC(OpenID Connect) 기반의 인증(Authentication)을 강화하고, 무결성 검증(Integrity Verification)을 위한 추가적인 노력이 필요하다.