[npm][보안] org member removal incident에서 owner 2FA 완료와 staged approval resume evidence를 같은 완료 신호로 보면 안 되는 이유

IT 리서치 노트

[npm][보안] org member removal incident에서 owner 2FA 완료와 staged approval resume evidence를 같은 완료 신호로 보면 안 되는 이유

npm incident에서 org member removal을 끝낸 뒤 staged publish까지 다시 열렸다고 적는 순간, 두 사건이 같은 완료 신호처럼 취급되기 쉽다. 하지만 2026년 8월 25일 기준 npm 공식 문서를 다시 보면 bypass-2FA token이 다루는 publish automation과 interactive 2FA가 필요한 governance·approve 사건은 다른 층이다. 이 글은 owner 2FA 완료와 staged approval resume evidence를 왜 같은 완료 신호로 보면 안 되는지, 그리고 incident note를 어떤 두 블록으로 나눠야 재발 설명이 쉬워지는지 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 org member removal incident에서는 owner 2FA 완료와 staged approval resume를 같은 완료 문장으로 적으면 안 된다. 전자는 계정·조직 운영 통제의 종료 신호이고, 후자는 package release 경로가 다시 열린 신호다. 둘 다 2FA가 등장하지만 확인 위치, owner, audit evidence가 다르다.

운영 메모는 최소한 governance block과 release block을 분리해야 한다. 그래야 owner는 권한 회수 완료를, release manager는 stage approve 재개를 서로 다른 의미로 보고할 수 있다. 이미 bypass 2FA와 governance 경계 글을 읽었다면, 이번 글은 그 경계를 incident 종료 기준으로 바꿔 쓰는 후속편이다.

2. 어디서 실제로 막히는가

실무에서 가장 흔한 착시는 '2FA가 끝났다'는 한 문장이다. owner가 interactive 2FA challenge를 끝낸 시각과, staged package approve가 다시 가능한 시각은 둘 다 2FA를 포함하지만 같은 로그가 아니다. owner 쪽은 org 또는 package governance의 통제 회수 사건이고, approve 쪽은 stage id와 release flow의 재개 사건이다.

이 둘이 섞이면 세 가지 문제가 생긴다. 첫째, org member removal은 끝났는데 package는 여전히 hold 상태일 수 있다. 둘째, package approve는 풀렸는데 team access revoke가 아직 덜 끝났을 수 있다. 셋째, CI가 정상이고 package가 보인다는 이유만으로 계정 운영 조치까지 끝났다고 잘못 보고하게 된다.

npm 문서는 2026년 8월 기준 bypass-2FA token이 account-identity와 governance 작업에 쓰이지 않는다고 적고, stage 문서는 stage publish와 approve를 별도 사건으로 나눈다. 이 둘을 합치면 'publish가 열렸다'와 '운영 통제가 닫혔다'를 같은 문장으로 쓸 근거가 사라진다.

• 증상: org member removal은 끝났는데 staged package approval은 아직 대기 상태다.
• 실패: owner 2FA 완료만 보고 incident를 종료한다.
• 막힘: stage id evidence와 governance evidence를 같은 audit 필드에 저장한다.
• 누락: package visible 시각과 team access revoke 시각을 따로 안 남긴다.

겉으로 비슷한 말	실제 뜻	왜 따로 적나
2FA 끝남	owner challenge 통과 또는 approve challenge 통과 중 하나	owner와 stage approver가 다를 수 있다
incident 종료	권한 회수와 release 재개가 모두 끝난 상태	둘 중 하나만 끝나도 위험이 남는다
publish 복구	stage approve 또는 direct publish path 복구	governance 조치가 자동으로 따라오지 않는다

3. 실무에서 적용하는 순서

가장 실용적인 runbook은 다섯 단계다. 먼저 owner 2FA 완료 시각을 적는다. 다음으로 team access revoke와 maintainer removal 완료 시각을 따로 적는다. 세 번째로 stage id와 현재 status를 조회한다. 네 번째로 approve resume evidence와 approver 2FA 시각을 적는다. 마지막으로 package page visibility와 dist-tag 상태를 저장한다.

1. owner 2FA 완료 시각과 owner identity를 기록한다.
2. team access revoke와 maintainer removal을 별도 줄로 적는다.
3. stage id와 현재 stage status를 조회한다.
4. approve resume evidence와 approver 2FA 시각을 저장한다.
5. package visibility와 dist-tag 회복을 마지막 신호로 남긴다.

incident 종료 전 최소 점검

1. owner 2FA 완료 화면을 확인한다
2. team access revoke 결과를 조회한다
3. stage id와 approve 결과를 저장한다
4. package page와 dist-tag 상태를 확인한다

이 절차의 핵심은 각 사건의 질문을 다르게 두는 데 있다. governance block의 질문은 '누가 더 이상 접근하지 못하나'이고, release block의 질문은 '어떤 stage가 다시 공개 경로로 흘렀나'다. 둘을 섞지 않으면 incident 회고에서 누락된 증거를 찾기도 쉬워진다.

특히 사람 승인 대기와 CI 성공을 같은 재개 신호로 보면 안 된다. CI가 문제 없이 stage publish를 계속 밀어 넣을 수 있어도 approve는 여전히 대기일 수 있고, 반대로 approve는 끝났는데 governance revoke가 아직 덜 마감됐을 수 있다.

4. 공식 문서와 예시 화면으로 확인하기

첫 공식 화면은 npm 2FA 문서의 최신 경계다. 2026년 8월 기준 bypass-2FA token이 더 이상 account-identity와 account-governance 작업을 대신하지 못한다는 선을 먼저 고정해야 한다.

npm은 2026년 8월부터 account-identity와 governance 작업을 bypass-2FA token 밖으로 분리했다.

즉 org member removal 사건에서 token 기반 publish 성공과 사람 2FA 완료는 서로 다른 사건이다. publish가 계속 돌았다고 해서 owner 측 조치가 끝난 것은 아니다.

두 번째 자료는 package settings 쪽 규칙이다. publish access나 package settings 변경은 stage resume와 닮아 보이지만, 같은 완료 신호로 취급하면 안 되는 별도 통제면이라는 점이 여기서 드러난다.

package settings 변경은 publish 성공과 별도로 2FA 경계에서 관리해야 한다.

incident review 메모가 package publish 결과 중심으로만 적혀 있으면, 설정 변경이나 권한 회수의 완료 여부를 나중에 설명하기 어려워진다.

세 번째 화면은 staged publish의 핵심 차이다. stage 자체는 토큰으로 진행될 수 있어도 approve는 proof-of-presence, 즉 사람 2FA를 요구한다.

npm stage 문서는 staging과 approve를 서로 다른 2FA 사건으로 설명한다.

이 문장을 기준으로 보면 owner 2FA 완료 시각과 stage resume evidence를 한 줄에 적는 습관이 왜 위험한지 분명해진다. 두 사건은 책임자도 다르고 확인 화면도 다르다.

실무에서는 완료 신호를 둘로 구분하는 표를 먼저 만드는 편이 가장 빠르다. governance 쪽 완료와 release approval 쪽 완료를 같은 칸에 두면 incident가 닫히지 않는다.

owner 2FA 완료와 staged approval resume evidence를 다른 종료 신호로 나눈 표다.

이미 approve freeze timing 글이 시간축을 다뤘다면, 이번 표는 어떤 시간이 어떤 사건에 속하는지 더 선명하게 구분하는 단계다. approve actor와 reviewer 2FA timeline 글과도 자연스럽게 이어진다.

마지막 자료는 incident note 예시다. 같은 사건처럼 보이더라도 owner 2FA와 stage resume evidence를 다른 block으로 저장하면 누락이 줄어든다.

governance 완료와 stage resume evidence를 분리한 npm incident note 예시다.

이 메모 구조를 쓰면 누가 '운영자 승인 완료'를 말하는지와 누가 '배포 재개 가능'을 말하는지 곧바로 구분된다. org member removal 이후에는 이 두 문장을 절대 같은 완료 표현으로 쓰면 안 된다.

5. 주의사항과 리스크

첫 번째 리스크는 package visible 시각을 보고 owner 조치까지 끝났다고 오해하는 것이다. 두 번째는 owner 2FA 완료 시각만 보고 staged package approve evidence를 빼먹는 것이다. 세 번째는 release rollback 메모와 org member removal 메모를 같은 티켓 줄에 적어 나중에 누가 무엇을 확인했는지 불분명하게 만드는 것이다.

운영 중에는 최소한 owner_2fa_completed_at, team_access_revoked_at, approve_resumed_at, package_visible_at 네 값을 같이 남기는 편이 좋다. 이 네 값이 서로 다른 책임 경계의 종료 신호라는 점만 분명해도 대응이 훨씬 짧아진다.

실무에서는 owner 화면을 확인하고, revoke 결과를 조회하고, stage status를 저장하고, package 상태를 다시 확인하는 순서만 고정해도 보고 품질이 크게 올라간다.

• owner 2FA 완료는 governance 종료 신호다.
• approve resume은 release flow 재개 신호다.
• package visible은 live registry 반영 신호다.

6. 결론

org member removal incident에서 '2FA가 끝났다'는 한 문장은 너무 넓다. owner 2FA 완료와 staged approval resume evidence를 따로 남겨야 권한 회수와 release 재개가 둘 다 끝났는지 설명할 수 있다.

같은 incident를 더 좁혀 보고 싶다면 후속편인 member offboarding 기록과 team access revoke evidence 종료표 글을 이어서 보면 좋다. 이번 글이 governance와 staged approval resume을 갈랐다면, 후속편은 사람 제거와 team-package 권한 정리 자체를 따로 적는 방법까지 내려간다.

• governance 완료와 release 재개를 다른 줄로 적는다.
• stage id evidence와 owner challenge evidence를 분리한다.
• incident 종료는 두 사건이 모두 끝난 뒤 선언한다.

7. 참고 링크

1. https://docs.npmjs.com/about-two-factor-authentication/
2. https://docs.npmjs.com/requiring-2fa-for-package-publishing-and-settings-modification/
3. https://docs.npmjs.com/cli/v11/commands/npm-stage/
4. https://docs.npmjs.com/managing-team-access-to-organization-packages/
5. https://docs.npmjs.com/about-access-tokens/