-
[npm][보안] 같은 패키지인데 버전별 provenance 노출이 다를 때 version history와 visibility 변경 이력을 어떤 순서로 다시 보나기타개발지식/풀스택개발 2026. 7. 20. 09:14
IT 리서치 노트
[npm][보안] 같은 패키지인데 버전별 provenance 노출이 다를 때 version history와 visibility 변경 이력을 어떤 순서로 다시 보나
npm 패키지에서 어떤 버전은 provenance가 보이고 어떤 버전은 비어 있으면 보통 같은 저장소인데 왜 결과가 달라졌는지 막막해진다. 2026년 7월 20일 KST 기준 npm 공식 문서를 다시 보면 provenance는 버전 단위 UI, trusted publishing 경로, package visibility, public package 조건이 함께 맞아야 한다. 이 글은 같은 패키지인데 버전별 provenance 노출이 다를 때 version history와 visibility 변경 이력을 어떤 순서로 다시 보는 편이 빠른지 정리한 것이다.
1. 개요
결론부터 말하면 provenance 차이는 패키지 전체보다 버전별 이력으로 읽어야 한다. 먼저 어떤 버전이 trusted publishing 경로를 탔는지, 어떤 버전에서 visibility가 바뀌었는지, registry UI의 check mark가 언제 보였는지 시간축으로 붙여 두는 편이 빠르다.
그다음에야
npm audit signatures결과와 source link, package metadata를 비교한다. 단일 버전에서 CLI 검증이 통과했다고 해서 모든 버전의 registry provenance detail이 동일하게 보인다고 가정하면 안 된다.2. 어디서 실제로 막히는가
같은 패키지에서 버전별 provenance 노출이 달라지는 증상은 보통 세 갈래에서 나온다. 첫째, 일부 버전이 trusted publishing 경로가 아니라 token fallback이나 다른 publish path를 탔다. 둘째, package visibility가 특정 시점에 바뀌었다. 셋째, registry UI 확인 시점과 버전 배포 시점이 어긋났다.
npm 문서는 trusted publishing이면 provenance attestation이 자동 생성된다고 설명하고, 별도 문서에서 UI 기준을 Version field의 green check mark로 안내한다. 또 visibility 변경 문서는 웹사이트 반영 시간이 몇 분 안에 달라질 수 있다고 적는다. 세 문서를 같이 읽으면 provenance 증상은 버전, UI, visibility, publish path를 같이 기록해야 풀린다는 뜻이다.
- 증상: 같은 패키지인데 일부 버전만 green check mark가 보인다.
- 실패: 최신 버전 한 번만 검증하고 이전 버전 노출 차이를 설명하려 한다.
- 막힘: visibility 변경 시점을 provenance 생성 실패와 구분하지 않는다.
- 누락: publish timestamp와 workflow 경로를 버전별로 남기지 않는다.
보이는 차이 먼저 볼 이력 다음에 볼 항목 버전 A만 check mark가 없다 그 버전 publish path와 workflow token fallback 흔적, OIDC 여부 visibility 변경 뒤 UI가 비어 보인다 public/private 전환 시각 registry 반영 지연인지 확인 CLI 검증은 통과하지만 UI가 다르다 버전별 metadata와 source link scoped public package 조건 3. 실무에서 적용하는 순서
실무 점검 순서는 네 단계다. 먼저 버전별 publish timestamp를 뽑는다. 두 번째로 각 버전이 trusted publishing 경로를 탔는지와 token fallback 흔적이 있는지 적는다. 세 번째로 같은 기간의 visibility 변경 시각을 붙인다. 네 번째로 registry UI check mark와
npm audit signatures결과를 나란히 둔다.- 버전별 publish 시각을 먼저 적는다.
- 각 버전의 publish path와 workflow를 붙인다.
- visibility 변경 이력을 같은 타임라인에 놓는다.
- registry UI와 CLI verify 결과를 같이 본다.
실제로는 npm 패키지 페이지를 열고, 각 버전의 Version 필드를 클릭하고, check mark 유무를 캡처하고, 릴리스 로그에서 publish 시각을 복사하고, visibility 변경 시간을 붙이고, CLI verify 결과를 저장하고, source link를 다시 비교하고, 문제 버전을 재확인해야 한다. 이 동작이 빠지면 UI 공백과 actual publish path 차이를 같은 원인으로 묶기 쉽다.
이렇게 보면 UI 공백이 provenance 생성 실패인지, visibility 전환 여파인지, 혹은 특정 버전만 OIDC 경로를 못 탄 것인지 훨씬 빨리 갈린다. 버전마다 다른 결과를 전체 패키지 상태로 일반화하는 실수를 줄일 수 있다. 핵심은 열기, 클릭, 캡처, 복사, 저장, 비교, 재실행, 재확인을 버전마다 반복하는 것이다.
version=1.2.3 publish_path=trusted_publishing|token_fallback package_visibility=public|private registry_check_mark=yes|no audit_signatures=pass|fail source_link_match=yes|no published_at=2026-07-20T09:00+09:00이미 OIDC publish인지 token fallback인지 보는 글과 package visibility와 version 조건 글이 단일 버전 문제를 다뤘다면, 이번 글은 여러 버전을 시간축으로 묶어 보는 후속편이라고 보면 된다.
4. 공식 문서와 예시 화면으로 확인하기
첫 화면은 trusted publishing이면 provenance가 자동 생성된다는 핵심 문장이다. 이 문장 때문에 버전별 차이가 보이면 먼저 현재 버전이 정말 trusted publishing 경로를 탔는지부터 의심해야 한다.
즉 특정 버전만 provenance가 비어 있다면 플래그 누락보다 publish path 자체가 달랐는지, 혹은 그 버전이 조건을 충족하지 못했는지를 먼저 봐야 한다. 버전별 이력 비교가 필요한 이유가 여기 있다.
두 번째 자료는 registry UI에서 무엇을 실제 기준으로 삼아야 하는지 보여 준다. npm은 README 옆 Version 필드의 green check mark를 provenance 표시 기준으로 설명한다.
그래서 패키지 전체가 아니라 버전별로 어떤 UI가 보이는지 기록해야 한다. 같은 패키지인데 일부 버전만 check mark가 있는 증상은 version history 기준으로 봐야 빠르다.
세 번째 화면은 visibility 변경이 registry 웹사이트 노출에 실제 영향을 준다는 대목이다. 특정 시점에 public과 private을 오간 패키지는 버전별 provenance 노출 차이를 visibility 타임라인과 같이 봐야 한다.
즉 version history와 visibility 변경 시점을 분리해 적어 두지 않으면 UI 공백을 provenance 생성 실패로 오해할 수 있다. registry detail은 publish path와 visibility 이벤트의 교집합으로 봐야 한다.
네 번째 자료는 public scoped package 경로를 확인하는 기준이다. trusted publishing이 맞아도 해당 버전이 실제 public package 경로로 올라갔는지는 별도 질문이다.
따라서 같은 저장소에서 버전별 provenance 노출이 달라지면 publish 명령 경로, package visibility, registry page 반영 시간을 함께 비교해야 한다. 버전 하나의 CLI 성공만으로 전체 패키지 상태를 일반화하면 안 된다.
마지막 표는 버전별 provenance 차이를 어떤 순서로 기록할지 정리한 것이다. publish timestamp, visibility 변경, registry check mark, audit signatures 결과를 한 줄로 붙여야 흐름이 보인다.
이미 package visibility와 version 조건 글이 단일 버전 triage였다면, 이번 글은 여러 버전 사이의 차이를 읽는 메모다.
5. 주의사항과 리스크
첫 번째 리스크는 최신 버전의 CLI 검증 한 번으로 전체 패키지 provenance 상태를 판단하는 것이다. 두 번째는 visibility 변경 직후의 registry UI 공백을 생성 실패로 단정하는 것이다. 세 번째는 버전별 source link나 repository metadata 차이를 빼먹는 것이다.
운영 전에는 버전별 publish 기록과 visibility 이벤트를 릴리스 로그에 같이 남겨 두는 편이 좋다. 그래야 나중에 특정 버전만 provenance 노출이 다를 때 workflow를 다시 뒤집지 않고도 시간축부터 좁힐 수 있다.
- 버전별 publish path를 기록하지 않으면 같은 패키지 차이를 설명하기 어렵다.
- registry UI와 CLI verify 결과는 서로 다른 층이다.
- visibility 변경 시각을 provenance 문제와 분리해서 남긴다.
6. 결론
npm provenance 노출 차이는 같은 패키지라도 버전별 history로 읽어야 한다. publish path, visibility 변경, UI check mark, CLI verify 결과를 한 줄로 붙이면 원인이 훨씬 빨리 갈린다.
같은 npm provenance 가지에서 먼저 단일 버전 triage를 보고 싶다면 visibility와 version 조건 글, OIDC 경로부터 다시 보고 싶다면 token fallback 분기 글, setup 전체를 다시 보고 싶다면 Trusted Publishing 절차 글이 이어진다.
반대로 provenance 표시는 있는데 linked source repository를 찾을 수 없다는 메시지가 남는다면 이번에 정리한 repository.url·공개 범위·삭제 이력 점검 글을 함께 보면 같은 provenance 가지 안에서도 source link 단절 원인을 더 빨리 분리할 수 있다.
7. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
