연구에서 제품으로: Cremit이 NHI 보안 공백을 메우기 위해 Cremit Platform을 만든 방법
지난 6개월간 실제 조직에서 비인간 정체성(NHI) 보안이 왜 실패하는지를 기록했다. 유출된 키를 "out of scope"로 분류하는 바운티부터 9편의 NHI 킬체인까지. Cremit Platform은 그 연구가 증명한 것으로부터 만들어진 제품이다.

목차(5)
목차
지난 6개월간 실제 조직에서 비인간 정체성(NHI) 보안이 왜 실패하는지를 기록했다. Cremit Platform은 그 기록으로부터 만들어진 제품이다.
Act 1. 반복해서 발견한 문제
이 방향을 확신하게 된 첫 글은 두 개의 키와 두 개의 버그 바운티 프로그램, 그리고 책임 공백에 관한 이야기였다. Slack Bot Token이 3년간, 실제 업무 워크스페이스에 연결된 Asana Admin API 키가 2년간 공개 GitHub 저장소에 노출돼 있었다. 두 건 모두 공식 바운티로 제보했고 돌아온 분류는 같았다. "Out of scope." Out of Scope Loophole 글에 정리한 이야기다.
두 사례가 기록할 가치가 있었던 이유는 희소성이 아니라 대표성이다. 조사 과정에서 접한 수십 건 중 가장 상징적인 두 건이었을 뿐, 패턴은 계속 반복됐다. 그래서 질문을 바꿨다. "Out of scope"가 증상을 가리키는 말이라면, 실제 질병은 어떻게 생겼는가. 그 질문이 NHI Kill Chain 시리즈 9편으로 이어졌다. 고아, 섀도, 노화, 과권한, 좀비, 드리프트, 공개 노출, 비귀속, 그리고 이를 꿰는 구조적 요약까지.
6개월의 작성을 마쳤을 때 남은 것은 한 장의 지도였다. 한 번의 통합을 위해 만든 키가 담당자보다 오래 살아남고, 재사용으로 권한이 누적되고, 아무도 기억 못 하는 운영 환경으로 흘러 들어가고, 결국 바운티가 인정조차 거부하는 자리로 유출된다. 사람은 퇴사하면 오프보딩된다. 자격증명은 그렇지 않다. 같은 문제를 반복해서 발견한 이유는 그 문제가 기본 상태이기 때문이다.
Act 2. 연구가 알려준 것
네 가지 관찰이 생각의 틀이 됐다.
가장 먼저 무너지는 것은 소유권이다. 거의 모든 사례에서 조직은 "이 자격증명의 소유자는 누구인가"에 답하지 못했다. 내부 추정으로 활성 NHI의 40~60%가 명확한 소유자가 없다. 키를 만든 엔지니어가 퇴사하거나 팀이 재편되는 순간 흔적은 사라진다. 로테이션, 폐기, 감사 모두 이 질문에 답할 수 있어야 성립한다. 그래서 Cremit Platform의 첫 원칙은 이렇다. 소유권 증명(attestation)은 선택이 아니며 지속돼야 한다. ISMS-P 2.5.5 외부자 보안 관리가 요구하는 책임 구조와도 맞닿는다.
대응 없는 탐지는 탐지가 없는 편보다 나쁘다. 공백은 탐지가 아닌 조치에 있었다. 살펴본 조직 다수는 노출 사실을 이미 알고 있었다. 없었던 것은 "찾았다"에서 "로테이션과 폐기까지 마쳤다"로 가는 경로였다. 그 간극이 공격자에게 열린 시간이다. Cremit Platform은 알림에서 멈추는 스캐너가 되지 않기로 했다.
SaaS 자격증명은 보안 프로그램에서 체계적으로 배제된다. 대부분의 프레임워크는 여전히 경계를 인프라 중심으로 정의한다. SaaS 토큰, OAuth 통합, CI/CD 봇, 벤더 API 키는 커버되지 않는 범주에 들어간다. "Out of scope"는 규칙이 아니라 범위 정의 문제의 증상이다. 원칙은 범위 확장. Slack Bot Token도 AWS 액세스 키와 같은 무게로 다뤄야 한다.
로테이션 정책은 문서로만 존재한다. 모든 조직이 정책을 보유하지만 일관되게 실행하는 곳은 거의 없었다. 수동 로테이션은 찾고, 소유자를 파악하고, 다운타임을 조율하고, 의존 시스템을 갱신하고, 검증하는 워크플로우다. 체크박스가 아니다. 노화 키 글에서 그 실패를 기록했다. 로테이션은 정책이 아닌 워크플로우에 통합돼야 한다. 이는 ISMS-P 자격증명 생명주기 관리의 실질적 이행 방식이다.
Act 3. Cremit Platform이 어떻게 만들어졌는가
Cremit Platform에는 네 개의 워크플로우가 있다. 각각의 한계도 함께 적는다.
탐지(Detection). 공개·비공개 저장소를 지속 스캔해 노출된 자격증명을 찾는다. GitHub Secret Scanning으로 충분하지 않은 이유는 세 가지다. 첫째, 알림이 벤더에게 가고 코드 소유 조직에는 가지 않는다. 둘째, 커버리지가 부분적이며 커스텀 토큰이 빠진다. 셋째, 소유권 계층이 없다. 한계: 자체 호스팅 Git 환경에서는 추가 설정이 필요하며 아직 다듬는 중이다.
소유권 매핑. "활성 NHI의 40~60%가 소유자 없음" 문제에 대응한다. 자격증명 도입 커밋의 최종 작성자, 브랜치 소유 이력, 참조된 파이프라인의 CI/CD 출처로 자동 추론하고 신뢰도가 낮으면 수동 증명 흐름으로 전환한다. 한계: 스쿼시 머지나 인수로 들어온 키에서는 추론이 약해 수동 증명 의존이 높아진다.
지속적 모니터링. 대부분의 스캐너는 최초 발견 제품이다. 어제 안전했던 키도 권한, 사용 패턴, 프로비저닝되지 않은 환경 등장으로 위험해진다. Cremit Platform은 행위를 시간 축으로 추적하고 변화에 알림을 보낸다. 한계: 기준선은 약 2주의 관측이 쌓인 뒤에야 의미가 있다.
로테이션 자동화. 탐지와 조치를 연결한다. 노출 확인 시 발급 서비스 통합으로 로테이션·폐기를 실행하고, 시크릿 스토어 갱신, 의존 저장소 PR 생성, 신규 자격증명 정상 동작 확인까지 조율한다. 모든 로테이션은 노출 탐지부터 검증까지 타임스탬프 기록이 남아 감사 증적으로 쓸 수 있다. 한계: AWS, GCP, Slack, GitHub 등 주요 플랫폼은 완전 자동화돼 있다. 그 외 서비스에는 로테이션 런북을 생성하고 진행을 추적하지만 실행하지는 않는다.
워크플로우는 연구에서 이미 길게 썼던 내용의 구현이다. 연구가 먼저였다.
Act 4. 연구가 제품 설계에 대해 증명한 것
제품이 모든 패턴의 모든 사례를 해결한다고 주장하지는 않는다. Cremit Platform의 워크플로우가 연구가 요구했기 때문에 존재한다고 주장할 뿐이다. 설계 압력이 연구 바깥에서 왔을 때는 거절했고 문서화한 실패 모드에서 왔을 때는 반영했다.
Act 5. 직접 스캔해 보는 편이 빠르다
여기 적은 내용이 지금 조직에서 보이는 상황과 겹친다면, 가장 빠른 확인 방법은 Cremit Platform을 직접 저장소에 연결해 보는 일이다. argus.cremit.io에서 통합 약정 없이 14일 무료 체험을 제공한다. 단일 조직의 공개 저장소 초기 스캔은 대부분 10분 안에 끝나며 결과는 이후 사용 여부와 무관하게 보관할 수 있다.
NHI Kill Chain 9편을 모두 발행한 뒤에야 제품 페이지를 공개했다. 그 순서가 중요하다. 주장의 출발은 연구다. 제품은 그 연구가 착지하는 지점이다. 연구를 먼저 읽고 싶다면 시리즈 개요가 가장 짧은 길이다. 같은 문제가 바운티를 만났을 때의 모습을 보려면 Out of Scope Loophole이 직접적이다. 우리 말을 믿는 것보다 직접 보는 편이 낫다.
이어서 읽기
회전되지 않은 API 키: 수년 된 자격증명이 여전히 프로덕션을 움직이는 이유 (NHI Kill Chain #3)
3년간 로테이션 없이 7개 시스템에 퍼진 AWS 키 하나. 공급망 공격으로 이 키가 탈취되었을 때, 공격자는 인프라 전체에 접근할 수 있었습니다. Aged Key 킬체인 분석과 단계적 로테이션 대응 가이드.
과도한 권한의 API 키: 하나의 자격증명이 너무 많은 것을 여는 문제 (NHI Kill Chain #4)
Stripe API 키 하나가 3년간 14곳에 복사되었습니다. QA 리포가 공개로 바뀌며 키가 노출됐습니다. 폐기하면 14개 서비스가 한꺼번에 멈춥니다.
대시보드는 시크릿 14,000개라고 합니다. 의미 있는 숫자는 525개입니다
시크릿 스캐너는 늘 큰 숫자를 내놓습니다. 그리고 그 숫자로 할 수 있는 일은 거의 없습니다. 탐지된 건을 하나씩 발급 서비스에 물어 검증했더니 다섯 자리 탐지 건수가 실제로 작동하는 자격증명 세 자리로 줄었습니다. 이 붕괴가 우선순위와 억제 정책, 그리고 경영진 보고에 무엇을 의미하는지 정리했습니다.
다음 글을 메일로 받아보세요
Cremit 리서치 팀의 월간 NHI 브리프. 한 통에 핵심만 담습니다.
