많은 인기 있는 패키지 관리자는 손상된 저장소가 악성 코드를 주입하는 것을 적절하게 방지하지 못합니다. 암호화 해시와 서명이 이를 해결할 수 있지만, 수많은 패키지 관리자가 취약한 상태로 남아 있습니다. 테스트된 25개 관리자 중 절반 미만이 기본적으로 변조를 확인하는 lockfile을 사용했으며, 다운로드된 모든 패키지의 무결성을 확인한 관리자는 두 개뿐이었습니다. 개발자 시스템 침해가 더 어려워지면 공격자는 패키지 저장소를 표적으로 삼을 가능성이 높습니다. 암호화 솔루션은 복잡하며, 많은 구현이 설계 선택이나 리소스 제한으로 인해 부족합니다. 검증을 위해 lockfile에 암호화 해시를 포함하는 것이 일반적인 접근 방식이지만, 그 구현은 패키지 관리자마다 다릅니다. Go와 같이 기본적으로 패키지 무결성을 확인한 관리자는 소수였으며, 다른 관리자는 추가 구성이 필요하거나 통합 검증이 부족했습니다. 안전한 해시 배포의 필요성을 피하는 서명 검증 또한 일관성 없이 구현되었습니다. Go는 기본적으로 서명을 확인한 유일한 관리자였으며, 다른 관리자는 추가 설정이 필요하거나 서명 지원이 부족했습니다. 테스트는 암호화 설계 및 보안 수준의 상당한 차이를 드러냈습니다. Docker와 mitmproxy를 사용한 테스트 하네스가 악성 저장소로부터의 공격을 시뮬레이션하기 위해 개발되었습니다. 이 하네스는 손상된 서버에 대한 패키지 관리자의 보안을 동적으로 평가했습니다. HTTPS는 패키지 관리자에서 널리 사용되며, 암호화되지 않은 HTTP를 사용하는 cpanminus가 주목할 만한 예외입니다. 해시 함수는 파일 무결성을 보장하기 위한 것이지만, 문제는 올바른 해시가 패키지 관리자에게 어떻게 전달되는지에 있습니다. Vcpkg는 검증을 위해 소스 코드에 저장된 사전 계산된 콘텐츠 해시를 사용합니다. Lockfile은 패키지 관리자가 올바른 해시를 학습하는 더 일반적인 방법입니다. Bun, npm, Cargo와 같은 패키지 관리자는 자동 무결성 검사를 위해 해시가 포함된 lockfile을 사용합니다. Pip 및 Conda와 같은 일부 관리자는 실험적이거나 선택적인 lockfile 지원을 제공하는 반면, Maven 및 Composer와 같은 다른 관리자는 전용 lockfile이 부족합니다. 놀랍게도 일부 lockfile에는 Pub 및 pnpm과 같이 기본적으로 불일치가 무시될 수 있는 손상을 방지하지 못하는 해시가 포함되어 있습니다. Conan 및 CocoaPods는 암호화 무결성 검증이 아닌 식별자로 해시를 사용합니다.