npm의 공급망 강화 업데이트와 고려해야 할 사항

Source: The Hacker News

Overview

2025년 12월, Sha1‑Hulud 사건에 대응하여 npm은 공급망 공격을 줄이기 위한 주요 인증 개편을 완료했습니다. 개편은 확실한 진전이지만, 이러한 변화가 npm 프로젝트를 공급망 공격으로부터 완전히 면역하게 만들지는 않습니다. npm은 여전히 악성코드 공격에 취약합니다 – 보다 안전한 Node 커뮤니티를 위해 알아야 할 사항은 다음과 같습니다.

원래 문제부터 시작해봅시다

역사적으로 npm은 클래식 토큰—오래 지속되고 범위가 넓은 자격 증명에 의존했습니다. 이러한 토큰이 도난당하면 공격자는 공개적으로 검증 가능한 소스 코드를 필요로 하지 않고도 저자의 패키지에 악성 버전을 게시할 수 있었습니다. 이는 npm이 공급망 공격의 주요 경로가 되게 했습니다.

시간이 지나면서 수많은 실제 사례가 이 취약점을 입증했습니다. 최근 주목할 만한 사례는 다음과 같습니다:

• Shai‑Hulud
• Sha1‑Hulud
• chalk/debug

이러한 공격은 npm 생태계에서 보다 안전한 인증 메커니즘이 절실히 필요함을 강조합니다.

npm의 솔루션

보안 문제를 해결하기 위해 npm은 여러 핵심 변경 사항을 도입했습니다:

• 토큰 폐기 및 세션 기반 인증

  • 모든 기존 토큰이 폐기되었습니다.
  • npm은 이제 npm login을 통해 얻는 단기간 세션 토큰(보통 ≈ 2 시간)을 기본값으로 사용합니다.
  • 대화형 워크플로를 통한 퍼블리싱은 기본적으로 MFA를 요구합니다.

• OIDC 신뢰 퍼블리싱 장려

  • CI 시스템은 장기 비밀을 저장하는 대신 실행당 단기간 자격 증명을 얻을 수 있습니다.

이러한 관행은 다음과 같이 보안을 향상시킵니다:

1. 자격 증명이 빠르게 만료되도록 보장합니다.
2. 퍼블리싱과 같은 민감한 작업에 두 번째 인증 요소를 요구합니다.

Source: …

두 가지 중요한 문제 남아 있음

1. 지속되는 MFA‑피싱 위험

• ChalkJS와 같은 도구를 대상으로 한 최초 공격은 npm 콘솔을 겨냥한 성공적인 MFA‑피싱 이메일에서 시작되었습니다.
• 피싱 메시지(아래 원본 이메일 참조)에서는 유지관리자에게 사용자 로그인과 **일회용 비밀번호(OTP)**를 제공하도록 요청했습니다.
• 공격자는 짧은 시간 동안만 유효한 OTP를 입수하면 몇 분 안에 악성 코드를 업로드할 수 있었습니다.

원본 피싱 이메일 (발췌)
“귀하의 npm 계정에서 비정상적인 활동이 감지되었습니다. 로그인 자격 증명과 기기로 전송된 OTP를 입력하여 신원을 확인해 주세요.”

OTP가 짧은 기간만 유효하기 때문에, 공격자는 이를 이용해 신속하게 악성 패키지를 배포할 수 있습니다.

2. 퍼블리시 시 MFA는 여전히 선택 사항

• 개발자는 npm 콘솔에서 MFA 우회가 활성화된 90일 토큰을 직접 생성할 수 있습니다.
• 이러한 토큰은 기존의 장기 토큰과 동일하게 동작하여, 토큰 소유자가 관리하는 모든 패키지에 대한 읽기 및 쓰기 권한을 부여합니다.
• 공격자가 이러한 토큰을 사용해 콘솔에 접근하면, 저자 이름으로 새로운 악성 버전을 퍼블리시할 수 있어, npm이 자격 증명 정책을 강화하기 전과 같은 공급망 취약성을 재현하게 됩니다.

왜 중요한가

• 퍼블리시 시 MFA를 채택하는 개발자가 늘어나는 것은 긍정적인 변화이며, 향후 공격의 빈도와 영향을 줄이는 데 도움이 됩니다.
• 그러나 OIDC와 퍼블리시 시 MFA가 여전히 선택 사항이기 때문에, 자격 증명 기반 공급망 침해의 근본적인 위험은 여전히 존재합니다.

결론

다음 상황이 발생한다면:

1. npm 콘솔에 대한 MFA‑피싱 시도가 여전히 성공하고,
2. 콘솔 접근이 새로운 패키지/버전을 퍼블리시할 수 있는 권한과 동일하다면,

개발자는 남아 있는 공급망 위험에 대해 경계를 늦추지 않아야 합니다. 퍼블리시를 위한 MFA(및 OIDC) 적용을 선택이 아닌 필수 보안 기준으로 만들어야 합니다.

권고 사항

1. OIDC 채택 촉진 – OpenID Connect의 광범위한 사용을 지속적으로 추진합니다. OIDC는 매우 공격하기 어렵고 많은 공급망 공격 경로를 크게 제거할 수 있습니다.

2. 패키지 업로드에 MFA 적용 – 모든 로컬 패키지 배포에 대해 다중 인증(이메일 코드, 일회용 비밀번호 등)을 요구합니다. 이는 Shai‑Hulud와 같은 위협의 영향을 줄이고 MFA를 우회하는 맞춤 토큰 사용을 방지합니다.

3. 릴리스에 보안 메타데이터 추가 – 각 패키지 릴리스에 명시적인 메타데이터(예: MFA 상태, 토큰 유형, 보안 인증)를 포함하여 개발자가 최선의 공급망 보안 관행을 따르지 않는 패키지 또는 유지관리자를 식별하고 회피할 수 있도록 합니다.

npm이 영구 토큰을 제거하고 기본 설정을 개선한 최근 조치는 중요한 진전입니다. 그러나 단기간에 사용되는 신원 기반 자격 증명이 표준이 되고 자동화를 위해 MFA 우회가 더 이상 필요하지 않게 될 때까지, 손상된 빌드 시스템으로 인한 위험은 여전히 실질적으로 존재할 것입니다.

새로운 방법

우리는 유지 관리자를 대신해 악성 패키지를 npm에 업로드하는 공급망 공격에 대해 논의해 왔습니다. 공개된 아티팩트를 다운로드하는 대신 검증 가능한 업스트림 소스에서 모든 npm 패키지를 빌드한다면 위험을 크게 줄일 수 있습니다. 바로 Chainguard Libraries for JavaScript가 고객에게 제공하는 방식입니다.

• 핵심 인사이트: 손상된 npm 패키지 공개 데이터베이스를 검토한 Chainguard 분석(링크)에 따르면 악성 패키지의 98.5 %가 업스트림 소스 코드가 아니라 공개된 아티팩트에만 악성코드를 포함하고 있었습니다.
• 결과: 소스에서 빌드하면 과거 데이터를 기준으로 공격 표면을 약 98.5 % 감소시킬 수 있습니다. Chainguard의 저장소는 npm에 나타나는 악성 버전을 절대 공개하지 않기 때문입니다.

왜 중요한가

이상적인 상황에서 고객은 다음을 통해 최고의 보안을 달성합니다:

1. Chainguard Libraries를 사용해 검증된 소스 빌드를 가져오기.
2. “보안 스위스 치즈 모델”에 명시된 추가 권고사항을 적용해 각 레이어마다 보호를 추가하기.

이 두 가지 조치를 결합하면 조직은 가능한 가장 강력한 방어를 구축할 수 있습니다.

자세히 알아보기

Chainguard Libraries for JavaScript에 대해 더 알고 싶다면, 우리 팀에 연락해 주세요.

참고: 이 글은 Chainguard의 수석 솔루션 엔지니어 Adam La Morre가 신중하게 작성하고 기여한 내용입니다.

이 글이 마음에 드셨나요?

더 많은 독점 콘텐츠를 보려면 팔로우하세요:

• Google News
• Twitter
• LinkedIn