Shai-Hulud의 손길이 469개 자격증명 위치로 확장됐다 — 그 의미는

2025년 8월 초, GitGuardian 연구팀은 Shai-Hulud 인포스틸러 웜의 최신 변종이 개발자 환경, CI/CD(지속적 통합/지속적 배포) 도구, 클라우드 설정, 그리고 AI 도구 설정에 이르기까지 469개 위치에서 자격증명을 탐색하도록 진화했음을 발견했다.

이전 변종은 189개 경로만 확인했다. 이 변화는 많은 것을 시사한다. 공격자들은 신뢰 관계 자체를 깨뜨리려는 시도를 멈추고, 그 신뢰 관계를 유지하는 데 이미 사용되고 있는 자격증명을 직접 이용하는 방식으로 전환했다.

소프트웨어 공급망은 항상 신뢰에 의존해왔다.

개발자는 패키지 레지스트리를 신뢰한다. 조직은 유지관리자를 신뢰한다. CI/CD 시스템은 주어진 자격증명과 신원을 신뢰한다. 애플리케이션은 빌드 중 내려받는 의존성 패키지를 신뢰한다.

공격자들은 이 신뢰 구조를 굳이 깨뜨릴 필요가 없다는 사실을 깨달았다. 자격증명과 상시 권한이 어디에 존재하는지만 찾으면 됐다.

이것이 현재 여러 생태계에서 소프트웨어 공급망 방어에 집중하게 만드는 배경이다. 패키지 레지스트리와 의존성을 보호하는 일은 여전히 중요하지만, 문제의 핵심, 즉 인포스틸러 웜이 성공하기 위해 반드시 필요한 요소는 그 시스템들 아래 깔려 있다.

공격자들은 재사용 가능한 권한을 사냥하고 있다. 다음 Shai-Hulud를 막으려면 자격증명 계층을 다루고 보안을 강화하는 것에서 시작해야 한다.

Shai-Hulud, 탈취한 자격증명을 지속적인 공급망 공격으로 전환

Shai-Hulud는 침해된 환경에서 공격을 이어가는 데 사용할 자격증명을 탐색하는, 점점 늘어나는 공급망 공격 유형에 속한다.

개발자 워크스테이션에서 발견된 토큰은 소스 코드 접근 권한을 열어줄 수 있다. 같은 코드에는 클라우드 자격증명이 포함돼 있을 가능성이 높고, 이는 인프라 접근 권한으로 이어진다. GitHub 토큰은 추가 저장소에 대한 쓰기 권한을 허용할 수 있다. 패키지 배포 자격증명은 공격자가 이미 개발자들이 신뢰하는 채널을 통해 소프트웨어를 배포하게 해준다. 자격증명은 하나의 침해 환경에서 다음 환경으로 이어지는 연결 고리가 된다.

더 넓은 생태계는 그 경로가 얼마나 직접적일 수 있는지 이미 목격했다. 보안 업계 뉴스 사이트나 정보 피드를 훑어보면, 여러 언어, 패키지 관리자, 운영 체제에 걸친 새로운 감염 사례가 끊임없이 등장한다.

자격증명 수집, 공격자에게 다음 발판 제공

현대 개발 환경은 소스 저장소 이상의 훨씬 많은 인증 정보를 담고 있다. .env 파일, 셸 히스토리, 패키지 관리자 설정처럼 예상할 수 있는 장소에 자격증명이 나타난다. 하지만 CLI 캐시, CI/CD 설정, IDE 설정에도 시크릿이 존재한다. 최근에는 AI 개발 도구 설정에서도 액세스 키가 발견되는 사례가 늘고 있다.

이것이 자격증명 수집 악성코드 제작자들이 탐색 범위를 계속 넓히는 이유다. 공격자는 수집 전에 어떤 자격증명이 가장 중요한지 반드시 알 필요가 없다. 가용한 것을 수집하고, 각 자격증명이 열어주는 것이 무엇인지 나중에 파악할 수 있다.

방어자는 반대 방향으로 문제를 풀어야 한다. 보안팀은 어떤 자격증명이 가장 중요한지 파악하고, 공격자가 이를 사용할 기회를 얻기 전에 노출 위험을 해소해야 한다.

배포 권한이 전파 경로를 만든다

패키지 배포용 자격증명은 특별한 주의가 필요하다. 자격증명 탈취를 소프트웨어 배포로 이어주어 공격을 앞으로 전파시키기 때문이다.

개발자가 패키지를 배포하는 데 사용하는 토큰은 다른 개발자, 빌드 시스템, 조직이 자동으로 사용하게 될 신뢰받는 패키지에 대한 권한을 지닌다. 바로 이 신뢰를 공격자가 악용한다. 이는 방어자에게 명확한 첫 번째 우선순위를 제시한다. 바로 도난 가능한 상시 배포 자격증명의 수를 줄이는 것이다.

조직은 장기 유효 배포 토큰에 대한 의존도를 낮춰야 한다. 모든 소프트웨어 제작자가 OpenID Connect(OIDC) 또는 유사하게 범위가 제한된 메커니즘을 통해 단기 유효, 검증된 인증 방식을 채택하도록 장려해야 한다. Docker와 GitHub Actions의 최근 업데이트는 더 강력한 인증과 신뢰 발행(Trusted Publishing) 확대 등 이 방향으로 생태계를 이끌고 있다.

아직 교체할 수 없는 장기 유효 배포 자격증명은 민감한 핵심 인프라로 취급해야 한다.

자격증명은 보안팀이 별도로 관리하는 시스템들을 연결한다

보안팀은 전통적으로 조직을 보안 유형으로 구분해 생각한다. 소스 컨트롤 보안, CI/CD 보안, 클라우드 보안, 엔드포인트 보안, 애플리케이션 보안이 그것이다. 자격증명은 이 모든 분류와 직무 분리(separation-of-duties) 요건을 가로질러 존재한다. 개발자 한 명이 정상적인 하루 업무에서 GitHub, npm, AWS, Kubernetes, 내부 API, 빌드 인프라에 모두 인증할 수 있으며, CI/CD 파이프라인도 이에 못지않게 다양한 자격증명을 보유하는 경우가 많다.

개발자 환경에 남겨진 자격증명 하나가 완전히 다른 곳의 권한을 대표할 수 있다. 파일은 노트북에 있지만, 자격증명은 클라우드 리소스를 제어하거나 패키지 배포 권한을 부여할 수 있다.

시크릿이 발견된 위치는 이야기의 일부에 불과하다. 시크릿 관리 성숙도를 높이려는 조직은 해당 자격증명이 유효한지, 어떤 신원에 속하는지, 어떤 시스템이 허용하는지, 어떤 권한을 지니는지, 어떤 환경에 접근 가능한지, 누가 교정 책임을 갖는지도 알아야 한다.

이는 시크릿 탐지를 자격증명 위험 관리로 전환시킨다.

노출된 모든 시크릿이 동일한 위험을 만드는 것은 아니다

10만 건의 시크릿 발견 목록이 10만 건의 동등하게 긴급한 사건을 의미하지는 않는다.

이미 유효하지 않은 자격증명도 있다. 일부는 일회성 개발 환경에만 접근 가능하다. 더 적은 수만이 프로덕션 데이터베이스, 클라우드 인프라, 배포 시스템, 패키지 배포에 접근 권한을 제공한다. 이 발견들을 동일하게 취급하면 위험을 줄이는 대신 처리 대기열만 쌓인다.

유용한 교정 전략은 공격자가 무엇을 먼저 선택할지 묻는 것에서 시작된다. 그 답이 실질적인 작업 순서를 제공한다.

우선순위 1: 패키지 배포 키를 평문에서 제거하라

이것이 Shai-Hulud 변종 및 기타 인포스틸러 웜을 막기 위해 개발자와 팀이 추구해야 할 핵심 행동이다. 패키지를 관리하는 조직은 배포 토큰이 어디에 존재하는지 파악하고 상시 자격증명이 여전히 필요한지 판단해야 한다. 이 탐색은 저장소 이상으로 확장되어야 한다.

개발자와 파이프라인이 남겨두는 모든 곳에서 배포 자격증명을 찾아라

패키지 작성자는 정상 워크플로우의 일환으로 인증 키를 로컬 설정 파일에 기록하는 경우가 너무 많다. 하지만 시크릿은 Git에 커밋되지 않더라도 개발자 PC에서 실행되는 악성코드에 노출될 수 있다. 이것이 최근 공급망 공격이 개발자 작업 환경 자체를 점점 더 직접 노리는 이유이기도 하다.

보안팀과 개발팀은 패키지 배포 자격증명이 실제로 어디에 쌓이는지 가시성을 확보하고, 이를 제거할 계획을 세워야 한다.

가능한 곳에서 상시 배포 자격증명을 교체하라

공격자가 훔치기 가장 어려운 배포 자격증명은 존재하지 않는 것이다. 하지만 반드시 존재해야 한다면, 접근 권한이 부여되는 기간이 짧을수록 좋다.

목표는 항상 평문으로 존재하는 재사용 가능한 배포 권한을 제거하는 것이다. 조직은 지원되는 모든 곳에서 패키지 배포를 단기 유효, 신원 기반 메커니즘으로 이동시켜야 한다. OIDC 기반 신뢰 발행(Trusted Publishing)이 한 가지 예다. 대부분의 클라우드 플랫폼은 AWS STS와 같은 페더레이션 보안 토큰 서비스로 나아가고 있어, 아티팩트를 푸시하는 플랫폼 전반에 걸쳐 워크로드 검증이 가능해진다. 이 영역은 각 패키지 도구 생태계에서도 계속 발전하고 있다.

아직 교체할 수 없는 정적 자격증명은 더 엄격한 통제가 필요하다. 발견 가능하고, 검증되고, 소유자가 있으며, 모니터링되고, 노출 시 교체될 수 있어야 한다.

이 노력은 자연스럽게 개발과 보안 사이에 위치한다. 개발자는 패키지가 어떻게 빌드되고 릴리스되는지 이해하는 반면, 보안팀은 정책을 수립하고 해당 워크플로우 전반에서 자격증명 노출을 파악한다.

어느 쪽도 혼자서는 해결할 수 없다.

우선순위 2: 노출된 프로덕션 자격증명을 제거하라

전파 경로를 차단하면 감염 확산을 막을 수 있지만 피해를 멈추지는 못한다. 배포 자격증명 다음으로 조직은 핵심 프로덕션 시스템에 대한 접근 권한을 제공하는 자격증명에 집중해야 한다. 여기서 자격증명 교정이 위험 관리로 전환된다.

격리된 개발 환경에 연결된 노출 자격증명은 제한적인 피해를 만들 수 있다. 프로덕션 인프라에 대한 쓰기 접근 권한을 가진 유효한 자격증명은 완전히 다른 사건이다.

각 조직은 미션 크리티컬의 범위에 대한 자체 계층적 관점을 가져야 하지만, 다음이 좋은 기본 목록이 될 수 있다:

• 프로덕션 클라우드 계정
• 고객 정보가 담긴 데이터베이스
• 서명 인프라
• Kubernetes 클러스터
• 배포 도구
• 관리자 인터페이스

물어야 할 질문은 "공격자가 탈취한 접근 권한으로 악의적인 행동을 한다면 무슨 일이 벌어지는가?"이다. 유효성은 여기서 매우 유용한 필터다. 실제 피해 범위를 파악하면 장기 유효 시크릿을 제거하거나 최소한 시크릿을 교체할 시스템을 우선순위화하는 데 도움이 된다.

공유 자격증명은 환경 사이에 숨겨진 경로를 만든다

자격증명이 재사용될 때 환경 경계도 흐려진다. 스테이징에서 발견된 자격증명이 프로덕션에서도 인증될 수 있다. 개발자의 로컬 환경에 복사된 토큰이 자동화를 위해 의도된 권한을 유지할 수 있다. 동일한 자격증명이 원래 목적이 잊힌 지 한참 후에도 여러 시스템에 나타날 수 있다.

시크릿을 찾는 것은 첫 번째 단계에 불과하다. 시크릿을 뒤에 있는 신원, 권한, 리소스, 환경, 소유자와 다시 매핑하지 않으면 경보는 그저 노이즈에 불과하다. DevOps, 플랫폼, IAM(신원 및 접근 관리), 보안 팀을 포함한 여러 팀이 각각 퍼즐 조각을 가지고 있으며, 교정은 이 조각들을 모아야 한다.

우선순위 3: 나머지 노출된 시크릿 전체를 위험도 순으로 정렬하라

패키지 배포와 명확한 프로덕션 접근 권한을 처리하고 나면, 조직은 나머지 자격증명 인벤토리를 체계적으로 처리할 수 있다. 목표는 무작위로 모든 것을 교체하는 것이 아니다. 가장 유용한 자격증명을 공격자의 경로에서 지속적으로 제거하는 실행 계획을 수립하는 것이다.

유효성은 좋은 시작점이지만 전부는 아니다

유효한 자격증명은 이미 만료되거나 폐기된 것보다 더 즉각적인 주의가 필요하다. 규모에서 이 구분은 매우 중요하다. GitGuardian의 '시크릿 확산 현황(State of Secrets Sprawl)' 연구에 따르면 2025년 한 해만 공개 GitHub 커밋에 신규 하드코딩 시크릿이 2,865만 건 추가됐으며, 이는 전년 대비 34% 증가한 수치다.

이 규모에서 수동 분류는 현실적이지 않다. 조직은 어떤 발견이 여전히 사용 가능한 인증을 나타내는지 파악하고, 이를 처리 대기열 앞으로 이동시켜야 한다.

유효성만으로는 여전히 전체 이야기를 말해주지 않는다. 공유 개발 서비스에 대한 유효한 자격증명은 주의가 필요하다. 프로덕션 클라우드 계정에 대한 관리자 접근 권한을 가진 유효한 자격증명은 훨씬 더 많은 주의가 필요하다.

유용한 우선순위 지정은 다음 맥락을 추가한다:

• 자격증명이 아직 유효한가?
• 프로덕션, 스테이징, 개발 환경 중 어디에 접근하는가?
• 어떤 신원을 나타내는가?
• 해당 신원은 어떤 권한을 가지는가?
• 어떤 리소스에 접근 가능한가?
• 자격증명이 다른 어디서 사용되고 있는가?
• 자격증명을 소유하고 교체하거나 폐기할 수 있는 담당자는 누구인가?

이 질문들에 대한 감사 가능한 답변을 확보하는 노력이 압도적인 유출 시크릿 목록을 실제 교정 계획으로 전환시킨다.

자격증명 위험 감소는 반복 가능한 프로그램을 필요로 한다

이번 Shai-Hulud 공격의 새로운 물결, 또는 그 어떤 변종도 일회성 자격증명 정리 작업 이상의 대응을 이끌어내야 한다.

개발자들이 소프트웨어를 계속 만들고, 서비스들이 서로 통합되고, 파이프라인이 발전하고, 새로운 도구들이 환경에 들어오면서 자격증명은 계속 쌓일 가능성이 높다. 대응은 반복 가능한 사이클이 되어야 한다.

조직은 먼저 보유한 것에 대한 광범위한 가시성을 확보해야 한다. 모든 자격증명의 단일 인벤토리가 필요하다. 이는 소스 코드와 Git 히스토리를 포함하지만, 현대의 공격은 CI/CD 시스템과 인증 정보가 쌓이는 개발자 환경까지 더 멀리 살펴볼 필요성을 보여준다.

탐지는 간단한 질문에 답해야 한다. 재사용 가능한 권한이 현재 어디에 존재하는가? 이는 감사 가능해야 하며, 이미 볼트에 등록된 '알려진' 시크릿만을 단순히 반영해서는 안 된다. 볼트 외부에 존재하는 시크릿 비율은 규모에서 시크릿 보안을 다룰 때 매우 중요한 지표다. 그 고아 평문 시크릿들을 처리할 방법이 없는 교정 계획은 결국 실패한다.

실제 위험에 따라 교정하라

다음 단계는 우선순위 지정이다. 이 글에서 설명한 것처럼, 배포 자격증명과 유효한 프로덕션 자격증명이 목록 최상단에 있어야 한다. 나머지 시크릿은 유효성, 환경, 신원, 권한, 소유권 및 기타 가용 맥락을 활용해 순위를 매겨야 한다. 교정은 이후 구분되지 않은 미처리 누적 항목 대신 관리 가능한 대기열을 통해 진행된다.

상시 자격증명이 공격 경로를 다시 만들지 못하도록 막아라

마지막으로, 조직은 동일한 자격증명 계층이 스스로 재구축되지 않도록 막아야 한다. 이는 새로운 하드코딩 시크릿을 차단하고, 가능한 곳에서 워크플로우를 단기 유효 자격증명으로 이동시키며, 개발자 환경에서 자격증명을 보호하고, 새로운 노출이 또 다른 대규모 교정 프로젝트가 되기 전에 포착하는 것을 의미한다.

"탐지, 교정, 예방"은 공격 후 발동하는 긴급 대응이 아닌 지속적인 사이클로 인식되어야 한다.

다음 Shai-Hulud 물결은 훔칠 자격증명이 더 적어야 한다

다음 Shai-Hulud 변종은 거의 확실히 새로운 곳을 살펴볼 것이며, 우리가 시작했던 469라는 숫자를 넘어설 것이다. 공격자들은 현대 소프트웨어 환경이 재사용 가능한 권한으로 가득 차 있다는 것을 배웠기 때문에 계속해서 경로와 개발자 도구를 탐색 목록에 추가할 것이다.

우리는 다음 인포스틸러가 어디를 볼지 모든 장소를 외워서 이 경쟁에서 이길 수 없다. 상시 권한을 제거하고 노출된 자격증명을 존재하는 모든 곳에서 없애는 것으로 이긴다.

그것이 자격증명 계층이 독자적인 보안 문제로 취급되어야 하는 이유다. 재사용 가능한 권한이 어디에 존재하는지 탐지하라. 가장 큰 위험을 만드는 자격증명을 교정하라. 그 노출이 다시 쌓이지 않도록 예방하라.

우리의 목표는 새로운 웜이 도착할 때마다 찾아서 악용할 수 있는 키가 더 적어지도록 보장하는 것이어야 한다.