공개 저장소에서 코드를 가져올 때 주의해야 하며, 의존성 트리를 검증하는 것이 중요함. 이는 공개 저장소의 맬웨어가 언어 모델(Large Language Models, LLMs)과 같은 자동화 도구에 어떤 영향을 미칠지에 대한 질문을 제기함. 예를 들어, GitHub Copilot과 같은 도구가 코딩 질문에 대한 응답으로 실수로 맬웨어를 포함할 가능성이 있음.
GitHub가 Usenet이 실패한 것과 같은 방식으로 실패하고 있음을 지적함. 누구나 GitHub에 저장소를 만들 수 있으며, 공식 저장소와 스패머의 저장소를 구별할 방법이 없음. Amazon이 "모든 것을 파는 상점"을 목표로 할 때, 대부분의 상품이 쓰레기라는 문제에 직면함. GitHub은 "모두를 위한 저장소"인지, 아니면 "이 코드를 신뢰할 수 있는가"에 대한 정체성을 확립해야 함.
공급망 문제가 심각함을 토로함. npm 릴리스를 대상으로 하지 않지만, 프로젝트 모니터링을 위해 socket.dev를 사용하고 있음. BrowserBox 프로젝트는 약 800개의 의존성을 사용하며, 이 중 19개가 최상위 의존성임. 모든 의존성을 npm의 @browserbox 네임스페이스로 스냅샷하여 취약점을 추적하고 패치하는 방법을 고려 중임.
개발자는 작업, 취미, 개인용으로 최소 세 개의 환경을 분리해야 함을 강조함. 신뢰할 수 있는 저장소와 소유자라도 샌드박스 가상 머신에서 코드를 실행하는 것이 현명함.
작은 팀에서 많은 주간 다운로드를 받는 SDK를 개발하는 경우, snyk, aikido.dev, renovate 기반 솔루션 등을 평가 중임. 이러한 도구들이 문제를 해결하는 데 도움이 될지 명확하지 않으며, snyk에서 경험한 것처럼 많은 거짓 긍정을 처리하는 것은 어려움.
curl과 sudo를 사용한 쉘 스크립트 설치 방식이 곧 끝날지 궁금함을 표현함. 이 방식은 기사에서 언급된 감염된 소프트웨어와 밀접한 관련이 있음.
npm에서 --ignore-scripts 옵션을 사용하여 맬웨어 실행을 방지할 수 있음.
1년 미만의 시간에 트로이 목마 바이러스가 포함된 저장소가 있었음을 언급함.
보안 문제에 대한 최신 게시물이 LLM 스타트업에 자금을 제공하라는 광고로 이어짐을 비판함. 이러한 스타트업들이 보안 격차의 일부만을 해결할 수 있으며, 다수의 스타트업과 계약을 맺는 것이 비용과 통합 문제를 야기할 수 있음.
지속적인 보안 보고에 따라 개발 환경의 보안을 점진적으로 개선하고 있음. VSCode 개발 컨테이너, GitHub Codespaces, OWASP 지침 읽기, socket.dev를 사용한 npm/파이썬 패키지 리뷰 등을 시도 중임.
Hacker News 의견
--ignore-scripts옵션을 사용하여 맬웨어 실행을 방지할 수 있음.