GitHub, Dependabot 버전 업데이트에 기본 3일 쿨다운 도입, HN은 실효성 논쟁

소프트웨어 설치를 두려워해야 하고 벤더가 미리 스캔해줄 거라 믿어야 하는 상황 자체가 문제임. 공급망이 이렇게 엉망이고 툴링이 이렇게 무능한데도 관심조차 없다는 게 웃김

이걸 공급망이라고 부를 수도 없음. 쓰는 솔루션 작성자랑 계약 관계가 하나도 없잖아

해결책이 뭘까 싶긴 함. 이건 npm 문제가 아니라 컴퓨팅 전반의 문제고, 이런 커뮤니티는 대체로 안전 명목의 제한이면 다 반대하잖아 (Manifest v3 봐라)

npm 같은 레지스트리가 다운로드 수 같은 생태계 영향력 기준으로 보안 요구사항을 차등 적용해야 하는 거 아닌가 싶음. 수백만 다운로드 패키지면 특별 보안 조치를 강제해야지

보안 업데이트는 즉시 열린다는데, 이거 실제 CVE나 취약점 리포트가 있어야 하는 거임? 패키지가 이미 털렸으면 가짜 critical update로 이 쿨다운을 그냥 우회할 수 있는 거 아닌가

GitHub 보안 권고(advisory)가 필요하고, GitHub이 검토한 권고만 알림을 트리거한다고 문서에 나와 있음

쿨다운이라는 게 그냥 멍청한 짓인 거 스스로 증명하는 거 아님

다들 쿨다운 걸면 문제를 그냥 뒤로 미루는 거 아닌가. 감염된 대규모 유저가 생긴 다음에야 누가 발견해서 신고하는 구조면 오히려 더 늦게 잡히는 거 아니냐는 생각이 듦

목표는 socket.dev 같은 보안 회사들이 자동 스캔할 시간을 벌어주는 거임. 사용자가 직접 당해서 발견하는 구조가 아니라 스캐너가 먼저 잡게 하려는 거지

최근 공급망 공격 중 사용자가 이상 행동 눈치채서 발견된 건 별로 없고, 대부분 메인테이너나 서드파티가 릴리즈 태그 안 맞는다든지 급하게 여러 버전 나온다든지 하는 패턴으로 발견함. 쿨다운이 다 막진 못해도 악성 릴리즈 발견 확률은 확실히 올려줌

다들 쿨다운을 조금씩 더 늘리면 결국 남보다 하루만 더 길게 잡으면 되는 경쟁이 되는 거 아니냐. 곰한테 쫓길 때 곰보다 빨리 뛸 필요 없이 친구보다만 빠르면 되는 거랑 똑같은 얘기임

사용자 입장에서는 쿨다운 기간에 어떤 보안 업체가 그 패키지를 실제로 감사했는지 알 방법이 없음. 그냥 희망 사항일 뿐이고, 의존성 자체를 줄이는 게 더 효과적인 전략임

postinstall 스크립트에서 뭘 curl해오는 악성 코드는 스캐너가 이미 다 잡음. 진짜 교묘한 건 실행 전엔 악성처럼 안 보이는 거라 3일로는 못 잡을 수도 있음

dependabot 때문에 회사 보안 담당자들이 업데이트 업데이트 업데이트만 외치는 게 너무 싫음. 문서화된 이슈가 명백히 관련 없어도 무조건 dependabot 말만 믿고 churn 만들어냄. 업데이트를 자주 하는 게 오히려 더 안 좋다고 생각함

팀에서 의존성을 극도로 보수적으로 가져가게 밀어붙이는 걸로 해결함. transitive dependency 많이 끌고오는 패키지는 특히 거르고, 이게 업데이트 churn, 의존성 지옥, 공급망 공격 표면을 한 번에 줄여줌

node 생태계 취약점 심각도 등급 매기는 방식이 너무 엉망임. 매주 High급 '취약점'이 새로 뜨는데 확인해보면 결국 dev-only 툴에 이상한 정규식 넣으면 테스트 러너가 OOM 나는 수준의 얘기임