Composer의 GitHub Action에서 발생한 GitHub_TOKEN 노출 이해하기

지속적 통합(CI) 파이프라인의 보안은 종종 조직의 중요한 취약점 포인트가 됩니다. 최근 보안 권고(GHSA-f9f8-rm49-7jv2)를 통해 GitHub Action의 로그에서 GITHUB_TOKEN이 부주의하게 노출된 특정 사례가 주목받았습니다. 이 사건은 민감한 자격 증명이 로깅 메커니즘을 통해 얼마나 쉽게 유출될 수 있는지, 그리고 서드파티 액션에 대해 이를 검증하는 것이 얼마나 중요한지를 보여주는 중요한 경고입니다.

노출의 성격

GitHub Actions 자체의 시스템적 결함임을 시사하는 초기 보고 및 제목들과는 달리, 이 취약점은 GitHub 플랫폼의 핵심 인프라 결함이 아니었습니다. 대신, 문제는 Composer 프로젝트(PHP용 의존성 관리자)에서 제공하는 특정 GitHub Action 내에 존재했습니다.

워크플로우가 GITHUB_TOKEN을 사용하여 인증될 때, GitHub Actions는 일반적으로 이러한 비밀 정보를 로그에서 별표(*)로 대체하여 마스킹 처리합니다. 그러나 만약 어떤 액션이 플랫폼의 마스킹 메커니즘이 인식하지 못하는 방식으로 동일한 토큰을 수정하거나 검증하는 작업을 수행한다면, 토큰이 평문으로 stdout/stderr 로그에 출력될 수 있습니다.

기술적 영향 및 위험

GitHub Actions 워크플로우 내에서 Composer를 사용하는 조직의 경우, 해당 워크플로우의 로그 파일에 접근할 수 있는 모든 사람이나 엔티티가 활성 GITHUB_TOKEN을 가져갈 수 있다는 위험이 있습니다.

GITHUB_TOKEN은 일반적으로 수명이 짧고 특정 저장소로 범위가 제한되어 있지만, 노출될 경우 공격자가 토큰에 할당된 권한과 동일한 작업을 수행할 수 있게 됩니다. 워크플로우 권한 설정에 따라, 이는 읽기 전용 액세스부터 코드 푸시 또는 릴리스 생성 능력까지 다양할 수 있습니다.

커뮤니티 논의 및 반론[\n\n기술적 논의는 이 사건을 둘러싼 CI/CD 도구의 보안 태세에 관한 몇 가지 핵심 사항을 강조했습니다:

비밀 정보 마스킹 실패

사용자들이 제기한 주요 우려 사항 중 하나는 왜 토큰이 유출되었는가 하는 점이었습니다. 한 기여자는 토큰의 유효성을 확인하기 위해 단순히 /rate_limit과 같은 무해한 엔드포인트를 호출하는 대신, 불투명한 인증 키의 구조를 검증하는 행위가 우발적인 노출로 이어지는 경우가 많은 위험한 관행임을 지적했습니다.

DevOps 복잡성

일부 실무자들은 GitHub Actions 생태계에 대해 불만을 표하며, 플랫폼이 초기 설정의 용이성을 위해 설계되었지만 "진지한 DevOps" 관행에 필요한 깊이가 부족하다고 주장합니다. 이러한 정서는 플랫폼이 엄격한 보안 기본값 대신 단순한 통합을 우선시함으로써 개발자들에게 함정을 만들 수 있음을 시사합니다.

완화 및 권장 사항

조직의 파이프라인을 보호하기 위해 다음 단계를 권장합니다:

1. Composer Actions 감사: GitHub Actions에서 Composer를 사용 중이라면, 이 노출 문제를 패치한 최신 버전의 Composer Action을 사용하고 있는지 확인하십시오.
2. 비밀 정보 마스킹 검증: 플랫폼의 내장 마스킹에만 의존하지 마십시오. 사용자 정의 스크립트나 서드파티 액션이 비밀 정보를 포함하는 환경 변수를 로그에 명시적으로 출력하지 않도록 하십시오.
3. 최소 권한 원칙: GITHUB_TOKEN 권한을 가능한 한 제한적으로 설정하십시오. 현재 GitHub는 잠재적인 유출의 피해 범위를 제한하기 위해 GITHUB_TOKEN에 대해 읽기 전용 권한 사용을 권장하고 있습니다.
4. 즉각적인 조치: 취약점 보고자가 제안한 대로, 사용 중인 액션의 Composer 버전이 확실하지 않다면, 업데이트될 때까지 해당 워크플로우를 비활성화하는 것을 고려하십시오.