앱은 저위험이어도 빌드 파이프라인은 그렇지 않습니다.

그 판단은 어느 정도까지는 타당합니다

저희는 이런 이야기를 자주 듣고, 대개 합리적인 이유에서 나옵니다. 앱이 내부 대시보드, 데이터 파이프라인, 또는 사용자가 몇 명뿐인 작은 서비스라는 것입니다. 공격자가 원할 만한 것이 없습니다. 보안 예산은 고객 대면 제품에 먼저 쓰입니다.

이 논리는 애플리케이션에는 맞습니다. 하지만 애플리케이션이 빌드되는 방식에는 맞지 않습니다. 무엇을 출시하든 모든 팀에는 자격 증명이 담긴 CI 파이프라인과 직접 작성하지 않은 종속성 트리가 있습니다. 이것들은 공유되기 때문에 공격할 가치가 있으며, 이곳이 침해되면 그 자격 증명이 닿는 모든 곳, 즉 레지스트리, 클라우드 계정, 다른 리포지토리까지 영향이 미칩니다.

앱이 무엇을 하는지 상관하지 않은 공격들

다음 사고들은 어느 것도 특정 종류의 애플리케이션을 노리지 않았습니다. 각 사고는 팀이 소프트웨어를 빌드하는 데 사용한 도구나 패키지를 통해 팀에 도달했습니다.

tj-actions/changed-files, 2025년

변경된 파일을 감지하는 널리 쓰이는 GitHub Action이 침해되었습니다. CISA에 따르면 악성 버전은 2025년 3월 12일부터 3월 15일까지 활성 상태였으며, 이 침해로 액세스 키, GitHub 개인 액세스 토큰, npm 토큰, RSA 개인 키 등의 시크릿이 노출되었습니다. Wiz는 이 코드가 CI 러너 메모리를 덤프했기 때문에 공개 리포지토리에서는 시크릿이 워크플로 로그에 남았다고 보고했습니다. 버전 태그로 이 액션을 참조한 워크플로는 리포지토리의 내용과 상관없이 악성 코드를 실행했습니다.

Shai-Hulud npm 웜, 2025년

2025년 9월, CISA는 500개가 넘는 npm 패키지를 침해한 자기 복제 웜에 대해 경고했습니다. 이 웜은 GitHub 개인 액세스 토큰과 AWS, Google Cloud, Azure용 클라우드 API 키를 수집했습니다. Palo Alto Networks Unit 42는 이 웜이 탈취한 npm 토큰으로 피해자의 다른 패키지에 감염된 버전을 게시한 방식과, 이후의 공격 물결이 사전 설치(pre-install) 단계에서 실행되어 CI/CD 파이프라인으로 확산 범위를 넓힌 방식을 설명했습니다.

3:27

Codecov Bash Uploader, 2021년

공격자는 Codecov의 Docker 이미지 빌드 프로세스 오류를 통해 자격 증명을 빼내고, 많은 팀이 CI에서 실행하던 Bash Uploader 스크립트를 변조했습니다. 2021년 1월 31일부터 4월 1일까지 변조된 스크립트는 CI 환경에서 사용할 수 있는 자격 증명, 토큰, 키를 포함한 환경 변수를 제3자에게 보낼 수 있었습니다. 한 고객이 스크립트의 체크섬이 일치하지 않는 것을 발견하면서 드러났습니다.

xz utils, 2024년

Linux 배포판에 포함되어 있을 수 있는 데이터 압축 라이브러리인 XZ Utils 5.6.0 및 5.6.1 버전에 악성 코드가 심어졌습니다. CISA는 5.4.6 같은 침해되지 않은 버전으로 다운그레이드하고 악성 활동을 추적할 것을 권고했습니다. 압축 라이브러리는 종속성 중에서도 가장 눈에 띄지 않는 축에 속하지만, 그래도 표적이 되었습니다.

event-stream, 2018년

도움을 주는 메인테이너를 가장한 인물이 인기 npm 패키지 event-stream을 넘겨받아 3.3.6 버전에 악성 종속성 flatmap-stream을 추가했습니다. npm 팀은 페이로드가 Copay 비트코인 지갑이라는 특정 애플리케이션 하나를 노렸다고 보고했습니다. event-stream을 설치한 다른 모든 사용자도 악성 코드를 함께 받았습니다.

이 사고들의 공통점

• 빌드 시점이나 설치 시점에 발생했습니다. 악성 코드는 프로덕션 앱이 아니라 개발자 머신과 CI 러너에서 실행되었습니다.
• 자격 증명을 노렸습니다. 파이프라인의 토큰과 키가 목표였습니다. 빌드 중인 프로젝트 너머의 문까지 열어 주기 때문입니다.
• 신뢰받는 이름을 통해 들어왔습니다. 익숙한 액션, 익숙한 패키지, 익숙한 스크립트였습니다. 아무도 멀웨어를 설치하기로 선택하지 않았습니다.
• 사고 후 첫 질문은 같았습니다. 우리 빌드 중에 문제의 버전을 가져온 것이 있는가, 그리고 그것이 무엇에 접근할 수 있었는가? 각 빌드가 무엇을 사용했는지 기록이 없는 팀은 이를 재구성해야 했습니다.

최소한의 대응

기본을 다지는 데 보안 팀이 필요하지는 않습니다. GitHub와 CISA의 권고 대부분은 짧은 목록에 담깁니다.

1. 서드파티 GitHub Actions를 태그가 아닌 전체 커밋 SHA로 고정해, 태그가 옮겨져도 실행되는 내용이 바뀌지 않게 합니다.
2. 잠금 파일을 커밋하고 종속성 버전을 검증된 릴리스로 고정합니다.
3. CI 토큰에는 작동하는 범위에서 가장 좁은 권한을 부여하고, 사용 중인 무언가가 사고에 연루되면 토큰을 교체합니다.
4. 개발자 및 게시 계정에 피싱 방지 다중 인증을 요구합니다.
5. 각 빌드가 설치한 것을 기록해 두어, "우리가 영향을 받았는가?"에 기억이 아닌 데이터로 답할 수 있게 합니다.

처음 네 가지는 설정입니다. 다섯 번째는 도구가 필요하기 때문에 대부분의 소규모 팀이 건너뜁니다.

적은 노력으로 CRACI를 활용하는 방법

CRACI는 앱이나 워크플로를 바꾸지 않고도 기록을 대신 관리하고 네트워크 경계를 더합니다.

• 작업당 한 줄. runs-on을 craci로 바꾸면 됩니다. GitHub Actions 워크플로는 그대로이며, 실행 내역은 계속 GitHub에 표시됩니다.
• 모든 빌드에서 SBOM 생성. CRACI는 캐시에서 복원된 패키지를 포함해 각 작업이 실제로 가져오는 패키지를 기록하고, 결과를 CycloneDX 또는 SPDX로 내보냅니다.
• 작업별 네트워크 추적. 사고가 발표되면 어떤 빌드가 영향받은 패키지를 가져왔는지, 각 작업이 어디에 연결했는지 확인할 수 있습니다.
• 기본 거부로 전환할 수 있는 이그레스 정책. 작업에 필요한 패키지 소스만 허용하면, 손상된 단계가 찾아낸 것을 보낼 곳이 줄어듭니다. 정책은 실패 시 차단되며, 위반이 발생하면 알림이 발송됩니다.
• 지속적인 재평가. 모니터링 중인 SBOM은 새로운 취약점이 공개될 때마다 다시 확인되므로, 아무도 들여다보지 않았다는 이유만으로 오래된 빌드가 "깨끗한" 상태로 남지 않습니다.

한계도 분명히 말씀드립니다. 이그레스 정책으로는 tj-actions 침해가 공개 로그에 시크릿을 출력하는 것을 막지 못했을 것이며, 유출된 토큰을 되돌리는 도구는 없습니다. 고정과 교체는 여전히 중요합니다. CRACI가 바꾸는 것은 노출 여부를 얼마나 빨리 답할 수 있는지, 그리고 손상된 단계가 얼마나 멀리 닿을 수 있는지입니다.

첫 워크플로를 실행하려면 GitHub App을 설치하고 한 줄을 runs-on: craci로 바꾸기만 하면 됩니다.

비용

CRACI는 빌드 시간에 대해서만 요금을 부과합니다. vCPU 분당 $0.002(기본 2 vCPU 러너는 $0.004)이며, 초 단위로 측정되고, 월 요금이나 SBOM당 요금은 없습니다. 전체 조건은 요금을 참고하세요. 자격을 갖춘 스타트업은 스타트업 프로그램에 신청해 최소 100k 무료 빌드 시간(분)과 직접 온보딩 지원을 받을 수 있습니다.

EU에서 소프트웨어를 판매한다면 Cyber Resilience Act가 적용되는지도 확인해 볼 가치가 있습니다. CRA 가이드에서 적용 범위와 기한을 설명합니다.