"범위 밖"이라는 면죄부: 버그바운티는 왜 인증정보 노출을 외면하는가

조직의 핵심 크레덴셜이 공개 저장소에 수년간 방치되었다. 보안 업계의 답은 "Out of scope."

두 개의 키, 두 개의 프로그램, 사라진 책임

보안 리서치팀이 공개 GitHub 저장소에서 Admin 레벨 또는 그에 준하는 광범위한 권한을 가진 API 키 두 개를 발견했다. 인터넷 깊숙한 곳이 아니다. 브라우저만 있으면 누구든 볼 수 있는 Public 저장소에 평문으로 올라가 있었다. 문제는 이 키들을 제보한 뒤에 벌어진 일이다.

첫 번째 키: Slack Bot Token (3년 노출)

공개 GitHub 저장소에 3년간 방치된 Slack Bot Token이었다. Slack은 더 이상 단순한 메신저가 아니다. 수백 개의 채널에서 전략 논의, 인사 관련 대화, 고객 데이터, 기술 인프라 정보가 실시간으로 오간다.

부여된 scope에 따라 채널 메시지 열람, 파일 다운로드, 사용자 목록 조회 등 광범위한 접근이 가능한 상태였다. 그러나 더 심각한 것은 Lateral Movement 가능성이다. Slack 채널에는 다른 서비스의 인증정보가 공유되는 일이 적지 않다. "스테이징 서버 접속 정보", "AWS 키 공유합니다" 같은 메시지가 핀 메시지나 DM, 비공개 채널에 남아 있는 조직은 드물지 않다. 봇과 웹훅 연동은 Slack을 CI/CD, Jira, GitHub, 모니터링 시스템 등 수십 개 서비스와 연결한다. Slack Connect 채널을 통해서는 파트너 조직의 데이터까지 노출될 수 있다. 하나의 Bot Token이 조직 전체 기술 스택의 지도를 제공하는 셈이다.

리서치팀은 이 건을 해당 조직의 공식 버그바운티 프로그램에 제보했다. 돌아온 분류는 "Out of scope."

여기서 근본적인 모순이 드러난다. API 키는 회사의 자산이다. 버그바운티 프로그램의 목적도 결국 이런 자산을 보호하는 것이다. 취약점을 찾는 이유가 결국 회사 자산에 대한 비인가 접근을 막기 위해서인데, 그 자산에 직접 접근을 부여하는 키가 공개되어 있는 상황을 "범위 밖"이라고 분류하는 것은 프로그램의 존재 목적 자체와 모순된다.

두 번째 키: Asana Admin API Key (2년 노출)

원래 독립적으로 운영되던 조직이 통합되면서 넘어온 키였다. 중요한 것은 통합 이후에도 인수한 조직이 이 Asana 워크스페이스를 직접 사용하고 있었다는 점이다. 방치된 유물이 아니라 프로젝트 타임라인, 업무 배정, 전략 문서가 오가는 현역 인프라였다. 이 키는 공개 GitHub 저장소에 2년간 노출되었고, 워크스페이스 내 모든 프로젝트에 대한 전체 읽기/쓰기 권한을 가지고 있었다.

이 건도 공식 버그바운티에 제보했다. 결과는 역시 "Out of scope." 원래 다른 조직에서 온 자산이니 범위 밖이라는 논리였다. 직접 사용하고 관리하면서도 보안 책임은 범위 밖이라는 뜻이다.

"Out of scope"가 만드는 사각지대

두 사례의 공통점은 조직이 자체 크레덴셜 노출을 관리 대상으로 인식하지 않는다는 점, 그리고 "Out of scope"라는 분류가 그 사각지대를 공식화하고 있다는 점이다.

아이러니한 것은 두 조직 모두 "Out of scope"라고 분류해놓고 실제로는 조치를 취했다는 점이다. 키를 폐기하고 교체했다. 한 조직은 답변에서 제보 내용을 기반으로 다른 사례까지 광범위하게 검토하고 조치했다고 밝혔다. 위험을 인정하고, 제보의 가치를 활용하면서도 공식 분류는 "Out of scope"로 유지한 것이다. 범위 밖이라면서 범위 안의 대응을 한 셈이다. 이 모순이 현재 체계의 문제를 가장 직관적으로 보여준다.

이 두 건은 수십 건의 NHI 노출 리서치 중 대표적인 사례일 뿐이다. 매번 같은 패턴이 반복됐다. 보고서는 묵살되고, 치명적 접근 권한은 "Out of scope" 처리를 받았다. 사례가 쌓이면서 하나가 분명해졌다. 버그바운티의 인증정보 노출 대응 체계 자체가 망가져 있다는 것.

왜 이런 일이 반복되는가

반복되는 이유는 구조적이다. 버그바운티 프로그램의 설계 전제와 인증정보 노출이라는 위협의 성격이 근본적으로 어긋나 있다.

이론적 위험이 아니다. Toyota는 2022년 공개 GitHub 저장소에 약 5년간 방치된 access key로 296,019명의 고객 이메일 주소와 고객 ID가 노출됐다. Uber의 2016년 5,700만 명 데이터 유출 사고도 GitHub 저장소에 하드코딩된 AWS 인증정보에서 시작됐다. GitGuardian의 2025년 보고서에 따르면 2024년 한 해에만 공개 GitHub에서 2,380만 건의 시크릿이 탐지됐고, 이는 전년 대비 25% 증가한 수치다. 문제의 규모는 줄어들기는커녕 가속되고 있다.

자산 노출은 프로그램 버그가 아니다

버그바운티 프로그램은 '프로그램의 취약점(버그)'을 찾는 구조로 설계되었다. RCE, SQL Injection, XSS 같은 코드 레벨 결함을 보고하면, 잠재적 영향으로 심각도를 매기고 보상하는 체계다. CVSS가 이 체계를 뒷받침하고, 접수부터 보상까지 "exploit 가능한 결함을 보고하면 영향 기준으로 평가한다"는 전제가 깔려 있다.

API 키 노출은 성격 자체가 다르다. 유출된 인증정보는 exploit을 기다리는 프로그램 결함이 아니라, 그 자체가 회사 자산에 대한 접근 권한이다. 프로그램에 구멍이 뚫린 게 아니라, 금고 열쇠가 길거리에 놓여 있는 상황이다. 유효한 API 키가 Public 저장소에 올라간 순간, 위험은 이론이 아니라 현실이 된다. exploit을 짤 필요도, 체인을 구성할 필요도, PoC를 보여줄 필요도 없다. 키 자체가 접근 권한이다.

그런데 이게 취약점-exploit-영향이라는 기존 틀에 깔끔하게 맞지 않으니 가장 낮은 등급으로 분류되거나 아예 "Out of scope"가 된다. API 키 노출이 과소평가되는 이유는 위험이 낮아서가 아니라, 이 종류의 위험을 평가하는 도구가 없기 때문이다.

여기서 한 가지 중요한 구별이 필요하다. API 서비스를 제공하는 회사 입장에서 고객이 자신의 API 키를 부주의하게 노출하는 것까지 일일이 대응하기는 현실적으로 어렵고, 책임 소재도 다르다. 이 글에서 다루는 것은 회사 자체의 크레덴셜이 노출되는 경우다. 조직이 내부 인프라 접근에 사용하는 Slack Bot Token, Asana Admin Key처럼 조직의 핵심 자산에 접근을 부여하는 키가 공개 저장소에 올라가 있는 상황이다. 고객의 실수가 아니라 조직 자체의 자산 관리 실패다.

그렇다면 버그바운티 프로그램이 이 문제를 다루기에 적합한 채널인가? 솔직히 현재 구조로는 아니다. 버그바운티는 프로그램 취약점에 최적화된 체계이고, 회사 자산의 노출 식별은 다른 성격의 활동이다. 두 가지 방향이 있을 수 있다. 기존 버그바운티 프로그램의 범위를 확장해서 조직 크레덴셜 노출을 명시적으로 포함하거나, 인증정보 노출에 특화된 별도의 프로그램을 신설하는 것이다. 어느 쪽이든 현재의 "Out of scope" 상태보다는 낫다.

두 번째 사례는 "Out of scope"가 어떻게 도구에서 방패로 변질되는지 보여주는 전형이다. 조직이 직접 사용하고 관리하고 있는 자산을 "원래 다른 조직에서 넘어왔다"는 이유로 범위 밖으로 분류했다. 실제 위험과는 관계없는 행정적 회피다. 경계 설정 수단이어야 할 scope이 사각지대 정당화 수단으로 쓰이기 시작하는 순간, 프로그램이 무엇을 위해 존재하는지 답하기 어려워진다.

"그냥 설정 오류일 뿐"

자주 나오는 반론이 있다. "인증정보 노출은 설정 문제지 취약점이 아니다. IT 위생 관리 영역이지 버그바운티 영역이 아니다."

표면적으로는 맞는 말이다. Private이어야 할 저장소에 시크릿을 커밋했거나 로테이션을 안 한 것이고, 코드 결함이 아니라 프로세스 실패다. 그런데 한 단계만 더 생각해보자. RCE도 결국 나쁜 코드의 결과다. 입력값 검증 실패, 메모리 오처리, 경계 검사 미흡. 하지만 아무도 RCE를 "나쁜 코드"라는 원인으로 평가하지 않는다. 공격자가 무엇을 할 수 있는가, 즉 영향으로 평가한다. 원인은 심각도에 들어가지 않는다.

인증정보 노출에만 원인("설정 오류")을 기준으로 평가하고, 다른 모든 것은 영향을 기준으로 평가하는 것은 일관된 원칙이 아니라 이중 잣대다. Public 저장소에 노출된 Admin 레벨 API 키가 부여하는 비인가 접근은, 원인이 부주의한 커밋이든 CI/CD 설정 오류든 퇴사자가 남긴 스크립트든 동일하다. 피해 범위는 같다.

심각도는 "무엇이 일어날 수 있느냐"로 정해야 한다. "어떻게 일어났느냐"가 아니라.

빠진 차원: 시간

인증정보 유출 평가에서 가장 치명적인 사각지대는 시간이다. 코드 취약점은 발견하고 패치하면 끝이지만, 유출된 인증정보는 공개된 순간부터 폐기될 때까지 끊김 없이 접근 가능한 상태가 유지된다. 키가 살아 있는 한, 찾는 사람 누구나 제한 없이 사용할 수 있다.

첫 번째 사례의 Slack Bot Token은 3년간, Asana Admin API Key는 2년간 Public 저장소에 노출되어 있었다. 그런데 이 노출 기간을 심각도에 반영하는 프로그램은 거의 없다. 가중치도 배수도 없이, 진행 중인 침해를 커밋 당일의 스냅샷 하나로 평가한다.

GitHub은 이미 Secret Scanning을 운영하며 노출된 시크릿을 탐지해 벤더에게 알림을 보내고 있다. 그런데도 앞선 사례들은 3년, 2년간 방치되었다. 탐지 도구가 있다고 문제가 해결되는 것이 아니다. 탐지된 노출에 대응하는 체계, 즉 누가 책임지고, 어떻게 평가하고, 얼마나 빨리 폐기하는가의 문제가 남는다. 탐지와 대응 사이의 간극이 곧 공격자의 기회다.

보안 업계는 수십 년간 취약점 심각도 모델을 다듬어왔다. 이제 그 모델이 현실을 따라잡을 때다. 인증정보 유출은 기존 exploit 체인 취약점과 근본적으로 다른 위협이고, 많은 경우 더 위험하다. 기존 도구로는 이 위험을 제대로 잴 수 없다는 것을 인정하는 것이 첫걸음이다.

NHI 노출 심각도 지표: 빠진 것을 채우는 프레임워크

CVSS는 20년 넘게 코드 레벨 취약점 평가에 유효한 도구였다. 그러나 인증정보 노출은 다른 종류의 위협이다. 유출된 API 키에 exploit 체인은 필요 없다. 복사-붙여넣기면 끝이다. 공격 복잡도나 exploit 성숙도 같은 지표는 전부 의미를 잃는다.

CVSS를 버리자는 게 아니다. 여기서 제안하는 NHI 노출 심각도 지표(NHI Exposure Severity Index)는 CVSS를 대체하는 것이 아니라 보완하는 프레임워크다. 업계 표준들은 이미 인증정보 관리 요구사항을 체계적으로 다루고 있다. OWASP API Security Top 10(API2:2023 Broken Authentication), CWE-798(Use of Hard-coded Credentials), NIST SP 800-53 IA-5(Authenticator Management), NIST SP 800-63B(Authenticator Lifecycle Management), NIST CSF 2.0 PR.AA가 대표적이다. 그러나 이들은 예방과 통제 관점이다. 이미 발견된 인증정보의 심각도를 어떻게 체계적으로 평가할 것인가, 즉 발견 이후의 대응 기준에 대한 표준은 아직 없다. 그 빈자리를 채우는 것이 이 프레임워크의 목적이다.

이 프레임워크는 완성된 표준이 아니라 업계 논의를 위한 초안이다. 발견 시점에 유효한(active) 인증정보를 대상으로 하며, 실무 적용과 피드백을 통해 발전시켜 나가야 할 출발점이다.

6축 평가 체계

이 프레임워크는 인증정보 노출 건을 6개 독립 축으로 평가한다. 각 축은 1점(최저)에서 5점(최고)까지 채점된다.

평가의 기준은 조직에 대한 실질적 비즈니스 리스크다. 노출된 개별 에셋의 기술적 위험이 아니라, 해당 노출이 조직 전체에 미치는 비즈니스 리스크를 측정한다. NHI 노출에서 가장 중요하면서 기존 취약점 점수 체계가 무시하거나 간접적으로만 다루는 차원을 포착하도록 설계했다.

누적 위험 기간에 대한 참고: 인증정보가 노출된 순간, 그 자체로 즉각적인 보안 사고(incident)다. 기간이 짧다고 심각하지 않은 것이 아니다. 이 축이 측정하는 것은 시간이 지남에 따라 누적되는 조직 리스크다. 노출 기간이 길어질수록 잠재적 발견자가 늘어나고, 그 사이 조직 내에서 생성 및 유통된 민감 데이터의 양이 증가하며, 이미 악용되었을 확률이 높아진다. 24시간 노출과 3년 노출 모두 사고이지만, 3년간 누적된 위험은 질적으로 다르다.

각 축이 평가하는 대상은 다음과 같다.

6축 합산 최대 30점이고, 이 점수로 심각도 등급을 매긴다. 현재는 적용 용이성을 위해 6축에 동일 가중치를 부여했으나, 조직의 환경이나 산업 특성에 따라 특정 축에 가중치를 부여하는 확장이 가능하다. 예를 들어 금융 기관은 데이터 민감도에, SaaS 중심 조직은 횡적 이동 가능성에 더 높은 가중치를 둘 수 있다.

심각도 등급

등급 내에서 세부 판단은 조직의 컨텍스트가 채운다. 개발 샌드박스 인증정보 노출과 프로덕션 결제 시스템 노출은 같은 점수라도 다른 대응이 필요하다.

사례 채점

NHI 노출 심각도 지표를 두 사례에 적용하면, 현재 "Out of scope" 분류가 얼마나 현실과 괴리되어 있는지가 드러난다.

사례 A: Slack Bot Token (26/30, Critical)

Slack은 단순 메시징이 아니라 현대 조직의 허브다. 채널에 공유된 AWS 키 하나, Jira 연동 웹훅 하나가 다음 공격의 출발점이 된다. Bot Token으로 이 모든 정보에 접근할 수 있었다는 것은 커뮤니케이션 침해를 넘어 조직 전체 인프라에 대한 정찰이 가능했다는 뜻이다. 프레임워크 기준 확실한 Critical 등급. 조직의 판단은 "Out of scope."

사례 B: Asana Admin API Key (24/30, Critical)

Asana 프로젝트 데이터는 조직의 전략 방향과 자원 배분, 운영 우선순위를 드러내는 정보다. 직접적 PII는 아니지만 경쟁 정보 수집이나 소셜 엔지니어링에 충분히 유용하다. 프레임워크 기준 Critical 등급이지만, 조직의 판단은 마찬가지로 "Out of scope."

두 사례 모두 체계적 평가에서 26점, 24점으로 Critical 등급이 나온다. 그런데 두 조직 모두 이를 관리 대상으로 인식하지 않았다. 하나의 위협 유형 전체를 제대로 된 기준 없이 분류하는 체계적 실패다.

악순환: 인증정보 사각지대가 만드는 위험

인증정보 노출을 "Out of scope"로 분류한 결과는 개별 보고서 안에서 끝나지 않는다. 보안 생태계 전체에 영향을 미치는 악순환으로 이어진다.

가장 직접적인 결과는 리서처 이탈이다. 보안 리서처도 노력 대비 보상이 합리적인 곳에 시간을 쓴다. 광범위한 권한의 API 키 유출을 찾아내고, 피해 범위를 문서화하고, 인증정보의 scope과 노출 기간을 증거로 정리해서 책임 있는 공개 보고서를 작성하는 데 수시간이 든다. 결과가 "Out of scope"이면, 같은 작업을 반복할 이유가 없다. 리서처는 인증정보 유출을 버그바운티에 보고하는 것을 멈춘다. 발견을 멈추는 게 아니라, 프로그램이 보고할 이유를 없애버렸기 때문이다.

리서처가 떠난다고 세상에 노출된 인증정보가 줄지는 않는다. 키는 여전히 Public 저장소에 그대로 있고, 바뀌는 것은 누가 찾고 어떻게 쓰느냐 뿐이다. Public GitHub은 누구에게나 열려 있다. 리서처가 쓰는 검색 쿼리는 국가 정찰팀, 금전 동기의 사이버 범죄자도 똑같이 쓸 수 있다. 리서처가 보고를 멈추면 인증정보가 안 보이게 되는 것이 아니라, 악의적 행위자만 발견하고 행동에 옮기는 상태가 된다.

위협을 공격자보다 먼저 찾으라고 만든 프로그램이, 공격자만 찾도록 보장하고 있다. 버그바운티의 존재 목적과 정반대의 결과다.

의도한 수명을 훨씬 넘겨 잔존하는 오래된 인증정보 문제는 NHI 보안의 독립적 실패 패턴으로 연구되어 왔다. 소유권이 불분명한 키도 마찬가지다. 그런데 이런 문제를 발견해서 보고하는 리서처가 "Out of scope"라는 답을 반복적으로 받으면, responsible disclosure 생태계 자체가 위축된다. 인증정보 리서처가 한 명 떠날 때마다, 조직의 Public 저장소에서 유출된 시크릿을 찾아줄 눈이 하나씩 사라진다.

이 결과들이 서로를 강화하며 순환한다. 리서처 이탈 → 인증정보를 공격자만 발견 → "Out of scope" 정책 아래 기업 위험 증가 → 보안 투자 대비 위험 증가로 신뢰 하락 → 더 많은 리서처 이탈. 그 안에 갇힌 조직은 문제를 점점 더 못 보게 된다. 문제를 보여줄 사람들을 스스로 내쫓고 있기 때문이다.

AI 코드 생성 시대: 크레덴셜 노출의 가속

인증정보 노출 문제는 앞으로 더 심해진다. AI 코딩 도구의 확산이 이미 그 방향으로 작용하고 있기 때문이다.

핵심은 코드를 만드는 사람의 범위가 근본적으로 달라졌다는 점이다. GitHub Copilot, ChatGPT, Claude 등 AI 도구의 보편화로 이제 비개발자도 코드를 생성하고 배포한다. 마케터가 자동화 스크립트를 만들고, 데이터 분석가가 API 연동 코드를 작성하고, 기획자가 프로토타입을 직접 배포한다. 개발자(전문가)도 놓치는 크레덴셜 하드코딩을, 보안 인식이 상대적으로 낮은 비개발자가 놓치는 것은 당연한 결과다.

AI가 생성한 코드에 인증정보가 포함되는 경로도 다양하다. 컨텍스트 윈도우에 .env 파일이 포함된 상태에서 코드가 생성되거나, AI가 설정 파일이나 인프라 코드(Terraform 등)에 예시 키를 그대로 남기거나, "이 API에 연결하는 코드를 작성해줘"라는 요청에 실제 컨텍스트에서 추론한 값을 포함시키기도 한다. 생성된 코드가 충분한 검토 없이 커밋되면 인증정보가 공개 저장소에 올라간다.

전통적인 인증정보 유출이 개발자 개인의 부주의에서 비롯되었다면, AI 시대의 유출은 여기에 생성 속도가 결합된 결과다. 코드가 만들어지는 속도가 검토 속도를 앞지르고, CI/CD 파이프라인이 배포까지 자동화한다. 크레덴셜이 공개 환경에 도달하는 경로는 더 짧아지고 더 빨라졌다.

AI로 인한 인증정보 유출은 더 빈번해진다. 이를 탐지하고 보고하는 체계가 없는 상태에서 "Out of scope" 분류를 고수한다면, 공격자만 이득을 보는 구조가 굳어질 뿐이다.

한국 기업에게: ISMS-P 실효성 강화와 "인증정보 관리" 의무화

글로벌 버그바운티의 구조적 문제와 별개로, 한국 기업에게는 훨씬 더 직접적인 규제 맥락이 있다. 2026년 4월 과학기술정보통신부·개인정보보호위원회가 발표한 「정보보호 및 개인정보보호 관리체계 인증제 실효성 강화방안」은 ISMS·ISMS-P 제도를 구조적으로 개편한다. 핵심 변화는 네 가지다.

첫째, ISMS-P 의무화. 자율 취득이었던 ISMS-P 인증이 2027년 하반기부터 공공·민간 대규모 개인정보처리자, 이동통신사업자, 본인확인기관 등에 의무화된다. 의무화 대상이 미취득할 경우 과징금 감경 대상에서 제외된다.

둘째, 인증 3단계 차등화. 매출액 1조 이상 주요 ISP·IDC, 매출액 3조 이상 정보통신서비스제공자 등 국민생활 파급력이 큰 사업자는 강화인증(Advanced) 군으로 분류되어, 기존 ISMS 80개 기준에 더해 20개 강화 인증기준(세부 점검항목 76개)이 추가로 적용된다.

셋째, 강화 인증기준에 "인증정보 관리" 명시. 강화 인증기준 예시에는 다음이 포함된다.

인증정보 관리: 액세스 토큰, API 키 등 인증정보의 전체 생명주기를 체계적으로 관리

이와 함께 자동화된 계정 관리(생성·수정·비활성화·삭제 상태 변경 실시간 반영), 사용자 인증 강화(적응형 인증), 정보자산 식별 자동화, 무결성 검증이 같은 축에서 요구된다. 글로벌 바운티 프로그램이 "범위 밖"으로 분류하는 바로 그 API 키 노출이, 한국 규제에서는 강화 인증기준의 명시적 관리 대상이다.

넷째, 기술심사·현장실증 도입과 인증 취소. 기존 서면 증적 중심 심사에서 취약점 점검, 모의침투, 소스코드 진단(CVE·CCE·CWE 기반), 이상행위 모니터링 실증 등 기술심사로 전환된다. 중대결함(EoS, 보안패치 미적용, 로그 미보관 등)이 보완조치 기한(100일) 내에 해소되지 않으면 인증 취소 절차가 작동한다. 제도 시행 이래 사례가 없던 인증 취소가 실제로 가능해진다.

앞의 두 사례를 한국 기준에 대입하면

3년짜리 Slack Bot Token, 2년짜리 Asana Admin API Key의 경우, 해외 프로그램에서는 "Out of scope"였지만, 한국 강화 인증기준에 대입하면 "인증정보 생명주기 관리 부재"에 정확히 해당한다. 강화인증 대상 사업자라면 2027년부터 이런 상태가 단순한 운영 미흡이 아니라 인증 취소 사유로 평가될 수 있다. 게다가 기술심사에서 취약점 점검·소스코드 진단이 실제로 수행되므로, "서면상 관리하고 있다"는 답변만으로 통과하지 못한다.

한국 기업 보안 담당자가 지금 점검해야 할 것

강화 인증기준 적용까지 남은 시간은 제한적이다. 특히 강화인증 대상이거나, 매출액·개인정보 처리량 기준으로 ISMS-P 의무화 대상에 편입될 가능성이 있는 조직이라면 다음 항목을 지금 점검해야 한다.

• 인증정보 인벤토리 확보. 조직이 발급·사용 중인 API 키, 액세스 토큰, SaaS 크레덴셜, 시스템 계정을 전수 식별. 식별되지 않은 자산은 관리할 수 없고, 관리되지 않는 인증정보가 바로 "방치된 3년짜리 Slack Bot Token"이 되는 경로다.
• 생명주기 관리 자동화. 수동 스프레드시트 관리는 규모 단위에서 실패한다. 생성·회전·폐기 상태 변경이 실시간 반영되는 체계가 강화 인증기준의 요구사항이다.
• 공개 저장소 상시 모니터링. GitHub Secret Scanning 알림 수신만으로는 부족하다. 조직 내부 레포부터 개발자 개인 레포, AI 코딩 도구로 생성된 코드까지 포함하는 탐지 체계가 필요하다.
• 인증정보 노출 대응 플레이북. 노출 확인 → 폐기 → 회전 → 영향 분석의 표준 절차가 문서화되어 있어야 한다. 탐지와 대응 사이의 간극이 공격자의 기회이며, 기술심사에서 플레이북과 실행 로그가 함께 검증된다.
• 인증정보 노출에 대한 바운티 scope 재정의 (해당 조직에 한함). 자사 버그바운티 프로그램을 운영 중이라면, 조직 자체 크레덴셜 노출을 명시적으로 scope에 포함시키는 것 자체가 "체계적 관리"의 근거가 된다. 심사 과정에서 관리 체계를 증빙할 때 활용 가능한 근거 중 하나다.

준비되지 않은 상태로 강화 인증기준이 적용되기 시작하면, 실사 단계에서 드러나는 것은 단일 키의 노출이 아니라 관리체계 부재다. 후자는 개별 사고 대응보다 훨씬 고치기 어렵다.

바뀌어야 할 것들

버그바운티 운영 조직에게

프로그램의 scope 정의를 점검해야 한다. SaaS 인증정보를 다루는가? 조직 통합 과정에서 유입된 키와 토큰을 다루는가? 답이 아니오라면 그 자체가 침해 사고의 주요 경로를 비워둔 것이다. 2018년이나 2020년에 작성한 scope 정의는, 평균적 기업이 수십 개 SaaS를 운영하고 각각이 유출 가능한 NHI를 생성하는 2026년 현실을 반영하지 못한다.

더 근본적으로, 인증정보 노출을 기존 버그바운티 프로그램에 포함할 것인지, 별도의 자산 노출 식별 프로그램을 만들 것인지를 결정해야 한다. 프로그램 취약점(버그)과 자산 노출(크레덴셜)은 성격이 다르고, 평가 기준도 달라야 한다.

credential exposure를 정식 바운티로 처리하는 프로그램은 이미 존재한다. 2019년 Starbucks 버그바운티에 제보된 JumpCloud API 키 노출(HackerOne #716292)이 대표적이다. 공개 GitHub 저장소에서 발견된 단일 API 키 한 건이 CWE-798(Use of Hard-coded Credentials)로 분류되고 CVSS 9.7(Critical)로 채점되었다. 바운티가 지급되었고, 공개 공시까지 완결됐다. 기술적 불가능이 아니라 의지와 분류 체계의 문제라는 사실을 보여주는 실제 선례다. 어느 방향이든 "Out of scope"로 방치하는 현재 상태가 조직에 가장 불리한 선택이다.

평가 방법론에서는 시간에 걸친 누적 리스크(blast-radius-over-time)를 심각도의 핵심 요소로 포함해야 한다. 수년간 노출된 인증정보는 며칠 내 발견되어 패치된 코드 취약점과 근본적으로 다른 위협이다. "범위 밖"은 불편한 발견에 대한 반사적 답변이 되어서는 안 된다. 조직이 자산을 사용하고, 관리하고, 민감한 데이터를 저장하고 있다면, 그 자산에 접근을 부여하는 인증정보는 원래 어떤 법적 주체가 만들었는지와 상관없이 조직의 문제다.

보안 리서처에게

인증정보 노출 보고를 멈추면 안 된다. 떠나고 싶은 마음은 이해하지만 그 빈자리는 공격자만 채운다. 보고할 때 NHI 노출 심각도 지표 같은 프레임워크 기반 심각도 평가를 함께 제출하여 무시하기 어려운 근거를 만들어야 한다.

"Out of scope"로 분류되면 재평가를 공식 요청하고, 이 키가 부여하는 접근이 왜 조직의 관리 대상이 아닌지에 대한 서면 설명을 요구해야 한다. 정당화를 강제하는 것만으로도 묵살이 얼마나 근거 없는지 드러나는 경우가 많다.

NHI 노출 심각도 지표의 활용

버그바운티 플랫폼은 CVSS 옆에 인증정보 전용 평가 체계를 놓는 것을 진지하게 검토해야 한다. 6개 축은 scope 경계나 관성이 아닌 실제 위험을 기준으로 논의할 수 있는 공통 언어다. 리서처가 제보할 때, 운영자가 평가할 때, 같은 척도를 보고 같은 언어로 대화할 수 있어야 한다.

공개: 이 사례들은 Cremit 리서치팀이 NHI 노출 연구 중 발견한 것이다. 두 건 모두 공식 버그바운티 채널을 통해 보고했고, 해당 인증정보는 각 조직에서 폐기 및 교체 완료되었다.

한국 시장 각도

국내 보안 시장은 ISMS-P 의무 대상 확대, AI 기본법 제정, 개인정보보호법 과징금 강화가 동시에 진행되는 전환기에 있다. 금융권은 전자금융감독규정, 공공기관은 국가기반 정보통신시설 지정 기준과 CSAP 인증이 함께 적용되며, 이에 따라 기업은 통제 체계를 단일 인증 기준이 아닌 다층 규제 매트릭스로 재설계해야 한다.

• ISMS-P, CSAP, 전자금융감독규정 간 중복 통제 매핑 테이블 구축
• AI 기본법 적용 대상 시스템 식별 및 대응 로드맵 수립
• 개인정보보호법 강화 대응을 위한 경영진 보고 체계 정례화

관련 글

• 다크웹에서 거래되는 API Key, 해커들의 새로운 타깃
• Secret 확산과 Non Human Identity: 증가하는 보안 문제
• MCP와 A2A: AI 시대에 비인간 아이덴티티 보안이 중요한 이유

---

Argus로 NHI 보안 자동화

Cremit의 Argus는 공개·비공개 저장소의 노출된 크레덴셜을 상시 탐지하고, 팀별 소유권을 매핑하며, 회전 워크플로우를 자동화합니다. 14일 무료 체험: argus.cremit.io.