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

조직의 핵심 자격증명이 공개 저장소에 수년간 방치되었다. 보안 업계의 답은 "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·ISMS-P 개편 계획과 자격증명 점검

개인정보보호위원회와 과학기술정보통신부는 2026년 4월 인증제 실효성 강화방안을 발표했습니다. 발표 당시 계획에는 중요 개인정보처리시스템 중심의 ISMS-P 의무 대상 확대, 위험도에 따른 인증 구분, 현장 기술심사, 사후 점검 강화가 포함됐습니다. 정부는 관련 시행령·고시·안내서를 고쳐 2027년부터 일부 제도를 적용할 계획이라고 밝혔습니다. 발표 자료를 곧바로 모든 기업에 적용되는 확정된 세부 의무로 읽어서는 안 됩니다.

공개된 보도자료만으로는 이 글의 기존 문구처럼 모든 API 키 노출이 인증 취소 사유가 된다거나, 특정 번호의 자격증명 관리 기준·고정된 조치 기한이 시행된다고 단정할 수 없습니다. 실제 인증 대상, 적용 시점, 심사 항목은 개정된 규정과 조직의 인증 범위를 확인해야 합니다.

규정과 별개로 지금 할 수 있는 일은 분명합니다. 자격증명의 담당자와 사용처를 기록하고, 공개 노출 여부와 유효성을 확인하고, 살아 있는 키는 발급 서비스에서 교체한 뒤 조치 증거를 남기세요. 사고 신고 여부는 실제 개인정보 유출 등 별도 법적 요건에 따라 판단해야 합니다.

공식 자료

개인정보보호위원회·과학기술정보통신부, 인증제 실효성 강화방안 발표 (2026-04-10)

바뀌어야 할 것들

버그바운티 운영 조직에게

프로그램의 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 노출을 조사하며 이 두 사례를 발견해 공식 버그바운티 채널로 보고했습니다. 해당 조직들은 이후 자격증명을 폐기하고 교체했습니다.

관련 글

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