의존성 벤더링으로 공급망 공격 막기
공급망 공격(Supply Chain Attack) 증가로 소프트웨어 재사용 방식에 대한 근본적인 재검토가 필요함
자동화된 패키지 관리(Automated Package Management)의 편리함 이면에 숨겨진 위험성 지적
의존성 벤더링(Vendoring Dependencies)을 통해 코드 통제력을 강화하고 공격 표면을 줄이는 방안 제시
커뮤니티에서는 Nix/Guix, Zig의 패키지 관리 방식 등 대안적 접근법에 대한 논의 활발
의존성 벤더링(Vendoring Dependencies)의 제안과 효과
제안된 해결책은 npm, cargo와 같은 자동화된 패키지 관리 대신, 모든 의존성을 프로젝트 소스 코드에 직접 포함(벤더링)하는 방식이다. 이는 공급망 공격(Supply Chain Attack)의 확산을 근본적으로 차단하는 방화벽(Firebreak) 역할을 한다. 또한, 의존성 사용 비용(Cost of Using Dependencies)을 증가시켜 개발자가 불필요한 라이브러리 사용을 재고하게 만들고, 숨겨진 코드 복잡성(Hidden Code Complexity)을 가시화하는 부수적 효과를 기대할 수 있다.
Nix/Guix 및 Zig의 패키지 관리 방식 비교
커뮤니티에서는 Nix/Guix의 선언적 빌드 환경(Declarative Build Environment)과 Zig의 콘텐츠 해시 기반 패키지 관리(Content Hash-based Package Management)가 벤더링과 유사한 효과를 제공한다고 언급한다. 특히 Nix는 모든 빌드 과정을 재현 가능하게 만들어 빌드 재현성(Build Reproducibility)을 높이며, Zig는 글로벌 및 로컬 캐시(Global and Local Cache)를 활용하여 의존성 유실 문제에 대응한다. 이는 벤더링의 복잡성을 완화하는 대안으로 주목받는다.
대규모 조직의 모노레포(Monorepo)와 의존성 관리
Google, Facebook 등 대규모 기업의 모노레포(Monorepo) 사례는 벤더링의 복잡성 상한선이 생각보다 높을 수 있음을 시사한다. 하지만 이는 해당 기업들이 막대한 인력과 자원(Sufficient Thrust)을 투입하기에 가능한 일이며, 대부분의 조직에게는 지속 가능하지 않다는 비판이 제기된다. Facebook의 경우, 크로스-레포 의존성 업데이트(Cross-Repo Dependency Updates)에 대한 엄격한 정책이 오히려 복잡성을 야기한다는 지적이 있다.
벤더링의 단점: 코드 공유 및 보안 스캐닝
벤더링의 주요 단점으로는 트랜지티브 의존성(Transitive Dependencies)의 공유가 어려워지고, 코드 재사용성(Code Reusability)이 감소한다는 점이 지적된다. 또한, 복사된 의존성에 포함된 잠재적 버그나 취약점(Latent Bugs or Vulnerabilities)을 보안 스캐너가 탐지하기 어려워질 수 있다는 우려도 나온다. 이는 자동화된 보안 감사(Automated Security Audits)의 효율성을 저해할 수 있다.
패키지 관리 시스템의 역사적 맥락과 문제점
토론에서는 apt와 같은 시스템 레벨 패키지 관리자가 언어 레벨 패키지 관리자보다 먼저 등장한 점을 지적한다. 초기 RubyGems의 전역 설치(System-wide Installs) 방식은 프로젝트 격리 문제를 야기했으며, Python의 `pip`와 `virtualenv` 또는 Ruby의 Bundler는 이러한 문제를 해결하기 위한 노력의 결과물이다. 이는 프로젝트 격리(Project Isolation)의 중요성을 강조하며, 벤더링이 이러한 맥락에서 이해될 수 있음을 시사한다.
