NPM, 보안 강화는 좋지만, 개발자들은 험난하다!

woodruffw의 댓글에 따르면, 현재 신뢰할 수 있는 게시(Trusted Publishing)는 특정 CI 제공업체(CI Providers)에 제한적으로 지원되며, 새로운 패키지의 첫 게시(First Publish)를 지원하지 않는다는 기술적 한계가 존재한다. 또한, 게시 시 필수적인 2단계 인증(Mandatory 2FA)과 같은 강력한 보안 메커니즘을 제공하지 못한다. 이러한 제약 사항은 고위험(High-Impact) 또는 중요한 패키지(Critical Packages)에 대한 신뢰할 수 있는 게시의 보편적인 적용을 어렵게 만든다.

fergie는 NPM 패키지(Package)가 주로 자원봉사자(Volunteers)에 의해 유지 관리되고 있으며, 보안 강화로 인한 추가적인 작업 부담에 대한 금전적 보상(Financial Compensation)이 부족하다고 지적한다. 오픈소스 라이선스(Open Source Licenses)는 사용자의 책임(Use at your own risk)을 강조하지만, 개발자들은 금전적 보상 없이 보안 관련 작업을 수행해야 하는 상황에 놓여 있다. 이러한 상황은 개발자들이 자율적인 개발 환경(Autonomous Development Environment)을 선호하게 만드는 요인으로 작용한다.

spankalee는 신뢰할 수 있는 게시(Trusted Publishing)를 도입하면서, CI 기반의 게시 설정(CI-based Publishing Setup)을 유지하면서 2단계 인증(2FA)을 추가하는 방식을 원한다고 언급한다. 하지만, 신뢰할 수 있는 게시(Trusted Publishing)는 의존성(Dependencies)의 보안 문제를 완전히 해결하지 못하며, 수동 검토(Manual Review)의 중요성을 강조한다. 또한, 의존성 분석(Dependency Analysis) 및 샌드박싱(Sandboxing) 도구의 필요성을 제기하며, 개발 프로세스(Development Process)의 효율성과 보안 간의 균형을 요구한다.

lloydatkinson은 신뢰할 수 있는 게시(Trusted Publishing)가 특정 CI 시스템(CI Systems)에 종속되는 문제를 지적하며, 이는 일종의 역 벤더 종속(Reverse Vendor Lock-in)이라고 비판한다. yoan9224는 신뢰할 수 있는 게시(Trusted Publishing)가 GitHub Actions와 같은 중앙 집중식 시스템(Centralized Systems)으로의 종속을 유도하여, 공격 표면(Attack Surface)을 증가시킬 수 있다고 경고한다. 이러한 중앙 집중화는 단일 시스템의 보안 취약점(Security Vulnerabilities)이 전체 생태계에 미치는 영향을 증폭시킬 수 있다.