Cremit

// 방법론

사고가 어떻게 인덱싱되는가

범위

이 인덱스는 크리덴셜을 외부로 빼내는 공급망 패키지 — npm, PyPI, GitHub Actions, VS Code 마켓플레이스, Hugging Face 전반을 다룹니다. 그게 전부입니다. 구체적으로:

  • 대상: AWS/GCP/Azure/Apple 크리덴셜 파일, npm/PyPI 발행 토큰, GitHub PAT, SSH 키, 브라우저 쿠키 및 비밀번호 저장소, OS 키체인 및 비밀번호 관리자, AI 도구 API 키(Anthropic, OpenAI 등), Slack/Discord 토큰, 암호화폐 지갑 파일 및 시드 구문, GitHub Actions 시크릿, VS Code 확장 인증 토큰, Hugging Face 액세스 토큰을 읽어 외부로 전송하는 패키지.
  • 비대상: 패키지명 폴루션 / tea.xyz 평판 농장, 페이로드 없는 일반 타이포스쿼트, 개발자 머신의 크리덴셜이 아닌 최종 사용자 dApp 상호작용을 노리는 지갑 드레이너, 랜섬웨어 / 파괴 목적 패키지.

좁은 범위가 핵심입니다. 더 넓은 공급망 firehose가 필요하다면 OSV.dev와 Socket.dev가 이미 잘 다루고 있습니다. 이 인덱스는 보안팀과 기자가 "이번 주에 어떤 크리덴셜 탈취 패키지가 나왔는가"를 노이즈 없이 조회할 수 있는 안정된 참조 지점을 제공합니다.

큐레이션 사고의 포함 기준

큐레이션 아카이브는 라이브 모니터보다 더 엄격한 기준을 적용합니다:

  • 노출이 최소 하나의 1차 출처(벤더 공시, 공식 권고, 소송 자료, 규제기관 파일)에 의해 확인되어야 합니다.
  • 최소 하나의 독립 2차 출처가 뒷받침해야 합니다.
  • 크리덴셜·토큰 탈취가 중심 발견 사항이어야 합니다(다른 사고 분류의 부수적 세부가 아닌).

라이브 모니터 시그널

개별 패키지 캐스케이드(휴리스틱 → 정적 분석 → 분류기) 외에도, 라이브 모니터는 단일 이벤트 분석으로는 놓치는 조직적 활동을 캠페인 디텍터로 노출합니다. 한 publisher가 24시간 내 2개 이상의 사칭 이름을 동시에 푸시하는 경우, 서로 무관해 보이는 두 패키지가 동일한 전체 webhook URL로 POST하는 경우, 또는 서로 다른 계정에서 동일한 tarball 해시가 등장하는 경우입니다. publisher 클러스터 판단은 로컬 1.5B 모델이 하지만, 그 앞단에 적대적 디스크립션 가드를 둡니다 — 공격자가 소형 모델을 속이기 위해 의도적으로 "security research PoC","internal vendor utility", "critical security patch for [브랜드] internal toolkit" 같은 문구로 디스크립션을 위장하기 때문입니다. 해당 문구가 발견되면 LLM 판단을 건너뛰고 즉시 의심 클러스터로 표면화합니다.

출처 분류

  • 1차 출처(primary)는 벤더 보안 공지, 공식 사고 리포트, 규제 제출, 사법 기록.
  • 리포팅 출처(reporting)는 신뢰할 수 있는 보안 매체(Bleeping Computer, The Record, KrebsOnSecurity 등).
  • 분석 출처(analysis)는 독립 연구자의 기술적 분석 글로, 보통 1차 공시에 없는 깊이를 보강합니다.

상태 값

  • confirmed — 1차 출처 한 곳 이상이 확인.
  • suspected — 정황 증거 있음, 1차 공시 아직 없음.
  • rumored — 검증 가능한 증거 없이 떠도는 주장. 그 주장 자체가 주목할 만한 사건이 된 경우에만 포함합니다.
  • resolved — 확인된 사건에 대해 조치가 문서화되었고 추가 노출 가능성이 없는 경우.

NHI Severity Index

유출된 NHI 자산의 영향을 세 축으로 측정하는 0–10점 점수:

  • Blast radius (영향 반경) — 크리덴셜이 미치는 시스템·조직의 범위: single-org → cross-platform → ecosystem-wide.
  • Reachability (도달 범위) — 크리덴셜이 어느 환경에 있는가: developer-env → staging → production.
  • Privilege level (권한 수준) — 크리덴셜이 사용되었을 때 할 수 있는 행동: read-only → service → admin.

점수는 알고리즘이 아닌 편집부의 판단이며, 근거는 모든 사고 페이지의 Cremit Analysis 섹션에 명시합니다.

검토 프로세스

  1. 1차·2차 출처를 바탕으로 초안 작성.
  2. Frontmatter는 Zod 스키마로 검증; slug, sources, dates는 자동 검사.
  3. 병합 전 Cremit 리서치팀의 편집 검토.
  4. 중요한 새 정보가 나오면 라이브 항목을 다시 검토합니다.

오류 정정

오류는 정정합니다. 리포지토리에 이슈를 열거나 hello@cremit.io로 사고 slug와 정정이 필요한 구체 주장을 적어 보내주세요. 모든 항목에 last_updated를 기록합니다.