tj-actions/changed-files 침해 사건 - NHI 보안을 중심으로
23,000개 넘는 저장소가 쓰던 GitHub Action이 변조되고 버전 태그까지 소급 조작되면서 CI/CD 시크릿이 빌드 로그로 새어 나왔습니다. 사건을 NHI 관점에서 읽습니다.


목차(6)
사이버 보안 환경은 끊임없이 변화하고 있으며 사람과 비인간 신원(NHI) 모두를 대상으로 하는 새로운 위협이 등장하고 있습니다. 최근 인기 있는 tj-actions/changed-files GitHub Action에서 발생한 사건은 종종 간과되는 이러한 머신 ID를 보호하는 것이 얼마나 중요한지를 명확히 보여주는 사례입니다. StepSecurity Harden-Runner가 감지한 이 침해 사고는 소프트웨어 개발 라이프사이클 내 NHI와 관련된 심각한 위험을 강조하며 효과적인 사고 대응을 포함한 강력한 NHI 보안 관행의 필요성을 강조합니다.
tj-actions/changed-files 사건 이해
2025년 3월, StepSecurity는 23,000개 이상의 리포지토리에서 사용되는 널리 사용되는 tj-actions/changed-files GitHub Action에 영향을 미치는 심각한 보안 사건을 탐지했습니다. 공격자들은 악의적으로 액션의 코드를 수정하고 여러 버전 태그를 소급하여 손상된 커밋을 가리키도록 업데이트했습니다. 이 악성 코드는 GitHub Actions 빌드 로그에서 CI/CD 비밀을 유출하도록 설계되었습니다. 이러한 워크플로 로그가 공개 리포지토리와 같이 공개적으로 접근 가능했다면, 누구든지 이러한 비밀을 탈취할 수 있었습니다.
공격은 2025년 3월 14일 PST 오전 9시경에 시작되었습니다. StepSecurity의 Harden-Runner는 워크플로 트래픽에서 예상치 못한 네트워크 엔드포인트가 나타났을 때 이상 행위 탐지를 통해 문제를 식별했습니다. 추가 분석 결과, GitHub Actions Runner 프로세스의 메모리에서 비밀을 추출하기 위해 악성 Python 스크립트가 다운로드 및 실행되고 있음이 밝혀졌습니다.
비인간 신원으로서의 GitHub Actions
GitHub Actions와 그것이 사용하는 비밀은 비인간 신원(NHI)의 주요 예시라는 점을 이해하는 것이 중요합니다. 이러한 자동화된 워크플로는 API 키, 토큰 및 서비스 계정과 함께 직접적인 사람의 개입 없이 작동하지만 중요한 리소스에 접근하고 수정할 수 있는 권한을 갖고 있습니다. GitHub Actions의 맥락에서 비밀은 종종 클라우드 공급자, 패키지 레지스트리 및 기타 민감한 시스템에 접근할 수 있는 권한을 부여합니다.
tj-actions/changed-files 사건은 NHI와 관련된 내재적인 위험을 완벽하게 보여줍니다.
자격증명 유출: 공격의 주요 목표는 연결된 시스템에 대한 무단 접근에 사용될 수 있는 민감한 CI/CD 비밀을 노출시키는 것이었습니다. 이는 OWASP 비인간 신원 Top 10의 NHI2:2025 - 비밀 유출과 직접적으로 일치합니다.취약한 제3자 NHI: tj-actions/changed-files 액션은 수많은 개발 워크플로에 통합된 제3자 구성 요소입니다. 이것의 침해는 겉보기에는 신뢰할 수 있는 외부 요소가 공격 벡터가 되는 NHI3:2025 - 취약한 제3자 NHI를 예시합니다. 조직은 종종 효율성을 높이기 위해 이러한 도구를 통합하지만 기본 NHI와 관련된 보안 위험을 완전히 평가하지 않습니다.가시성 및 모니터링 부족: Harden-Runner의 이상 행위 탐지와 같은 사전 예방적 보안 조치가 없었다면, 악성 활동은 상당 기간 동안 눈에 띄지 않아 광범위한 자격증명 탈취로 이어질 수 있었습니다. 이는 확장되는 NHI 환경에 대한 중앙 집중식 가시성 및 컨텍스트를 유지하는 데 따르는 어려움을 강조합니다.
교훈과 사고 대응의 중요한 역할
tj-actions/changed-files 사건은 NHI 보안을 강화하기 위한 귀중한 교훈을 제공하며 사고 대응은 가장 중요한 측면 중 하나입니다.
유출 가정: 이 사건은 "유출 가정" 사고방식을 강화합니다. 조직은 NHI가 이미 손상되었을 수 있다는 가정 하에 운영하고 의심스러운 활동을 탐지하고 대응하기 위해 지속적인 모니터링을 구현해야 합니다.신속한 대응을 위한 조기 탐지의 필요성: StepSecurity Harden-Runner는 예상치 못한 네트워크 엔드포인트를 식별함으로써 특히 이상 행위 모니터링 기능을 통해 침해를 조기에 탐지하는 데 중요한 역할을 했습니다. 조기 탐지는 잠재적 손상을 최소화하기 위한 시기적절하고 효과적인 사고 대응을 시작하는 데 매우 중요합니다.즉각적인 수정이 핵심: 침해 탐지 즉시 StepSecurity는 사용자의 복구를 돕기 위해 무료의 안전한 대체 액션(step-security/changed-files)을 신속하게 발표했습니다. 이는 미리 정의된 사고 대응 플레이북과 솔루션을 신속하게 제공할 수 있는 능력의 중요성을 보여줍니다. 악성 코드가 포함된 리포지토리를 삭제했다가 다시 복원한 GitHub의 조치 또한 사고 대응 프로세스의 일부를 구성합니다.커뮤니케이션 및 투명성: StepSecurity는 사건 발견 즉시 블로그 게시물을 통해 사용자에게 적극적으로 경고하고 지속적인 업데이트를 제공했습니다. 또한 커뮤니티 질문에 답변하기 위해 Office Hour를 주최했습니다. 이는 보안 사고 발생 시 명확하고 시기적절한 커뮤니케이션의 중요성을 강조합니다.즉각적인 해결을 넘어선 포괄적인 수정 전략: 손상된 액션을 교체하는 것이 중요하지만 포괄적인 사고 대응에는 잠재적으로 손상된 비밀을 식별하고 폐기하는 것도 포함됩니다. 영향을 받은 액션을 사용하는 공개 리포지토리를 가진 조직은 빌드 로그에서 유출된 비밀로 인해 즉시 복구 단계를 검토하라는 권고를 받았습니다.
이는 즉각적인 취약점 패치 그 이상으로 강력한 수정 워크플로의 필요성을 강조합니다.제3자 공급망 보안 고려 및 사고 대비: 조직은 개발 파이프라인에서 사용되는 모든 제3자 도구 또는 통합을 철저히 검증하고 관련 NHI에 부여된 권한을 이해해야 합니다. 이 검증 프로세스에는 공급업체의 사고 대응 능력 및 절차를 이해하는 것이 포함되어야 합니다.NHI 사고의 특수성을 고려한 대응의 필요성: tj-actions/changed-files 사건은 비인간 신원에 특화된 사고 대응 프로세스의 필요성을 강조합니다. 이러한 프로세스는 NHI의 고유한 특성과 자동화된 프로세스를 중단시킬 수 있는 잠재적 영향과 같은 요소를 고려해야 합니다.
NHI 보안 태세 및 사고 대응 역량 강화
tj-actions/changed-files 침해 및 기타 NHI 위협으로 강조된 위험을 완화하고 향후 사고에 효과적으로 대응하기 위해 조직은 다음 사항을 구현하는 것을 고려해야 합니다.
NHI마다 담당자를 정하고, 필요한 권한만 부여하며, 사용이 끝난 자격증명은 폐기해야 합니다. 침해가 의심되면 발급 서비스에서 키를 교체하거나 취소하고 사용 기록을 조사하세요. Cremit은 지원하는 연결 소스의 노출을 찾고, 지원되는 자격증명의 유효성을 확인하며, 결과를 담당자에게 연결합니다. 자격증명을 자동 폐기하거나 의심 활동을 격리하지는 않습니다.
NHI 사고 대응 계획에는 영향을 받은 워크플로 확인, 자격증명 교체·폐기, 제공자 로그 조사, 신뢰할 수 있는 빌드 복구 절차를 담으세요. Cremit의 노출 탐지 결과는 키가 발견된 위치를 파악하는 데 도움이 됩니다. 실제 사용 내역과 피해 범위는 CI·클라우드 제공자의 기록을 따로 조사해야 합니다. 타사 통합과 권한도 정기적으로 재검토하세요.
결론: 사전 예방적 NHI 보안 및 강력한 사고 대응이 필수적입니다.
tj-actions/changed-files 침해는 CI 워크플로에 쓰는 자격증명의 담당자와 권한을 파악해 두어야 한다는 점을 보여줍니다. 노출 여부를 검사하고, 침해가 의심되면 키를 발급한 서비스에서 교체하거나 폐기한 뒤 관련 로그를 조사하세요. Cremit의 탐지 결과는 이 조사에서 노출 위치를 찾는 데 사용할 수 있습니다.
관련 글
이어서 읽기
GhostAction 사고 분석: 악성 워크플로가 Git 이력의 키를 수집하는 방식
공개 워크플로 100개의 네 버전과 우버 저장소의 변경 기록을 대조했습니다. Git 이력에서 삭제된 키를 수집하는 경로, 전송 실패를 정상 종료로 처리하는 동작, 자격증명의 권한에 따른 대응 순서를 설명합니다.
MCP 서버의 API 키는 헤더가 아닌 대화창을 거쳐 전달됩니다
공식 MCP 레지스트리의 원격 서버마다 initialize 요청을 한 번씩 보냈습니다. 응답한 22,027곳 중 71.3%가 헤더 인증 없이 세션을 허용했고, 도구 인자로 전달되는 자격증명 필드는 3,705개였습니다. 그중 마스킹 대상으로 지정된 필드는 3개뿐이었습니다.
목록에 없을 뿐, 비공개는 아닙니다
2026년 9월 공개 표면 33곳에서 유효한 자격증명 23,912개를 확인했습니다. 7,468건은 권한 범위를 분류했고, 1,277건에는 다른 키의 발급 권한이 있었습니다. 실제 재발급 여부는 시험하지 않았습니다.
다음 글을 메일로 받아보세요
Cremit의 월간 자격증명 보안 브리프. 한 통에 핵심만 담습니다.