[2026-05-21] GitHub Actions 태그가 악성 커밋으로 변경… CI/CD 인증키 유출 위험

 

 

 

오늘의 뉴스클리핑의 이슈는 바로 GitHub Actions 태그가 악성 커밋으로 변경 입니다 - !

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

GitHub Actions 태그가 악성 커밋으로 변경

 

이번 기사는 개발자들이 자동화 배포와 테스트를 위해 많이 사용하는 GitHub Actions가 공급망 공격(Supply Chain Attack)에 악용된 사건을 다루고 있다. 공격자는 actions-cool/issues-helper 와 actions-cool/maintain-one-comment 라는 인기 GitHub Actions 저장소를 장악한 뒤, 기존 정상 태그(tag)를 악성 커밋으로 변경하였다. 이 때문에 해당 액션을 사용하던 개발사들의 CI/CD 파이프라인에서 악성 코드가 자동 실행되었고, 그 과정에서 GitHub Token, AWS Key, API Key 같은 민감한 인증정보가 탈취될 수 있었다. 특히 사용자는 정상 버전을 사용한다고 생각했지만 실제로는 공격자의 코드가 실행되었다는 점에서 매우 위험한 사건으로 평가된다. GitHub는 이후 해당 저장소 접근을 차단했으며, 보안업체들은 이번 공격이 기존 npm 공급망 공격 캠페인인 Mini Shai-Hulud 와 연관되어 있을 가능성이 높다고 분석하였다.

 

 

GitHub Actions 
1) GitHub에서 제공하는 자동화 기능이다
2) 코드 테스트, 빌드, 배포 등을 자동으로 수행

actions-cool/issues-helper
1) GitHub의 Issue 관리 자동화 Action
2) 버그 제보, 기능 요청, 작업 관리
3) 특정 단어 들어오면 자동 라벨 붙이기, 오래된 이슈 자동 닫기, 댓글 자동 달기, 담당자 자동 지정

actions-cool/maintain-one-comment
1) GitHub 댓글(Comment)을 자동 관리하는 Action
2) GitHub Actions는 실행될 때마다 댓글을 계속 새로 생성하는 경우가 있는데 이 action은 기존 댓글 하나를 계속 수정(update)

CI/CD
1) CI(Continuous Integration) / CD(Continuous Delivery/Deployment)
2) CI : 코드 변경 시 자동 테스트 및 통합
3) CD : 자동 배포
4) 개발부터 배포까지 자동화하는 시스템

 

 

 

 

 

 

 

공격과정 1 : GitHub Actions 태그 변조를 통한 악성 코드 삽입

공격자는 먼저 GitHub Actions 저장소의 권한을 탈취하거나 태그를 수정할 수 있는 권한을 확보하였다. 이후 v1, v2, v3 같은 기존 정상 태그를 공격자가 만든 Imposter Commit 으로 이동시켰다. Imposter Commit은 원래 저장소의 정상 커밋 기록에는 존재하지 않는 악성 커밋을 의미한다. 일반적으로 개발자는 아래와 같은 방식으로 GitHub Actions를 사용한다.

uses: actions-cool/issues-helper@v3

하지만 공격 이후에는 @v3 가 더 이상 정상 코드가 아닌 공격자의 악성 코드로 연결되었다. 따라서 해당 액션을 사용하는 기업이나 개발자의 GitHub Actions Workflow가 실행될 때마다 자동으로 악성 코드가 다운로드 및 실행되었다. 이 방식은 기존 Pull Request 검토 과정을 우회할 수 있기 때문에 탐지가 매우 어렵다.

Tag(태그) : 특정 버전을 가리키는 이름 -> 보통 개발자는 태그를 통해 특정 버전을 사용

Imposter Commit : 정상 저장소 기록에는 존재하지 않지만 공격자가 조작하여 연결한 악성 커밋을 의미

 

 

 

 

 

 

공격과정 2 : GitHub Runner 메모리 탈취 및 인증정보 유출

악성 GitHub Action이 실행되면 공격자는 GitHub Runner 내부에서 여러 단계를 수행하였다. 먼저 Bun JavaScript Runtime을 다운로드한 뒤, GitHub Runner 프로세스인 Runner.Worker 의 메모리를 읽어 인증정보를 추출하였다. 이후 탈취한 데이터를 공격자가 제어하는 외부 서버(t.m-kosche[.]com)로 HTTPS 통신을 통해 전송하였다. 이 과정에서 GitHub Access Token, AWS 클라우드 인증키, Docker 인증정보, 배포 서버 계정, API Key, 환경 변수(.env)와 같은 정보가 유출될 수 있었다. 특히 CI/CD 환경에는 운영 서버 접근 권한이나 클라우드 관리자 권한이 저장되어 있는 경우가 많기 때문에, 단순 정보 유출을 넘어 실제 서버 침해나 추가 공급망 공격으로 이어질 위험성이 매우 높다. 보안업체 StepSecurity는 SHA Commit을 고정하지 않은 대부분의 Workflow가 영향을 받을 수 있다고 경고하였다.

Runner : GitHub Actions Workflow를 실제로 실행하는 서버 또는 가상환경

SHA Commit : Git의 고유 커밋 식별값 -> 특정 코드 상태를 정확히 지정

 

 

 

 

 

 

시사점

이번 사건은 최근 공격자들이 단순 웹사이트 공격보다 개발 생태계 자체를 노리고 있다는 점을 보여준다. 과거에는 서버를 직접 공격하는 방식이 많았다면, 최근에는 GitHub, npm, PyPI, CI/CD 같은 개발 인프라를 공격하여 더 큰 피해를 유발하는 형태로 변화하고 있다. 특히 오픈소스 기반 개발 환경에서는 하나의 라이브러리나 GitHub Action만 해킹되어도 수천 개 기업이 동시에 영향을 받을 수 있기 때문에 공급망 공격의 위험성이 매우 크다.
또한 개발자들이 편의성을 위해 @v3 같은 태그 기반 버전 관리를 사용하는 경우가 많은데, 이번 사건은 태그 자체가 공격자에 의해 변경될 수 있다는 문제를 보여주었다. 따라서 앞으로는 아래처럼 정확한 Commit SHA를 고정하는 방식이 중요해지고 있다.

uses: actions-cool/issues-helper@a1b2c3d4...

이 방식은 태그가 변조되더라도 특정 정상 커밋만 실행되도록 제한할 수 있어 상대적으로 안전하다. 이번 사건은 SolarWinds Supply Chain Attack, 3CX Supply Chain Attack 같은 대형 공급망 공격 사례와 비슷한 흐름으로 볼 수 있으며, 앞으로도 DevSecOps 및 CI/CD 보안의 중요성이 더욱 커질 것으로 보인다.

 

 

 

 

 

 

 

개인의견

이번 사건이 단순 GitHub 해킹 사건이 아니라 개발 환경 자체가 공격 표면이 되고 있다는 점에서 매우 중요하다고 생각한다. 예전에는 보안 담당자들이 웹 서버나 방화벽 중심으로 방어를 고민했다면, 이제는 GitHub Actions, npm 패키지, Docker 이미지 같은 개발 파이프라인 전체를 관리해야 하는 시대가 되었다고 느꼈다. 특히 이번 공격은 개발자가 별다른 실수를 하지 않았더라도 정상적으로 사용하던 오픈소스가 공격당하면서 피해가 발생했다는 점이 인상적이었다. 이는 개인의 보안 의식만으로 해결할 수 없는 문제이며, 기업 차원에서 CI/CD 보안 정책과 오픈소스 검증 체계를 강화해야 한다는 필요성을 보여준다. 또한 앞으로 GitHub 로그 분석, CI/CD 위협 탐지, API Key 유출 모니터링 같은 기술이 더욱 중요해질 것이라고 생각한다. 기존 네트워크 중심 보안뿐 아니라 DevSecOps 보안까지 이해하는 인력이 앞으로 더 경쟁력을 가질 것으로 보인다.

 

 

기사 출처 : https://thehackernews.com/2026/05/github-actions-supply-chain-attack.html