위협 피드는 남의 데이터베이스다: 악성코드 인텔리전스를 대규모로 수집하는 데 실제로 필요한 것

권고 사항은 공유 위협 인텔리전스를 소비하라는 것이다. ISAC(정보공유분석센터)에 가입하고, 커뮤니티 피드를 파이프라인에 연결하라. 이는 합리적인 조언이며 나도 동의한다. 누구도 운영 매뉴얼을 이야기하지 않는다는 점이 문제인데, 접근 자체는 결코 어려운 부분이 아니기 때문이다. 위협 피드는 남의 데이터베이스다. 남이 만든 프로세스로 구축되고, 남의 판단으로 형성되었으며, 남이 겪은 최악의 하루가 지금 이 순간 그 안에 앉아 자동화가 조치를 취하길 기다리고 있다.

나는 GitHub에서 Dependabot을 운영하는 팀을 이끌고 있다. 이 시스템은 2026년 기준으로 3,000만 개 이상의 저장소를 모니터링하며 취약하거나 악성인 의존성을 탐지한다. 올해 우리는 OpenSSF의 malicious-packages 저장소에서 커뮤니티 인텔리전스를 수집해, 3월부터 악성코드를 탐지해온 npm에서 8개 패키지 생태계 전체로 악성 패키지 경보를 확장했다. 악성코드 경보는 피드 인제스션의 혹독한 테스트 케이스다. 일반 취약점처럼 업그레이드로 해결할 수 없다. 패키지를 완전히 제거하고, 빌드 과정에서 접촉한 모든 자격증명을 교체해야 한다. 그리고 볼륨은 멈추지 않는다. 2026년 5월까지 1년 동안 우리는 하루 평균 약 18개의 새로운 악성 npm 패키지를 목록에 등록했다.

실제 운영을 통해 살아남은 다섯 가지 교훈이 있으며, 이 교훈들은 패키지 악성코드 보고서를 수집하든, OSV 레코드를 수집하든, ISAC 지표를 수집하든 가리지 않는다. 커뮤니티 데이터가 자동화에 입력된다면 이 교훈은 모두에게 적용된다.

출처 추적이 곧 실행 취소 버튼이다

가장 불편한 질문을 먼저 던져야 한다. 레코드가 파이프라인으로 어떻게 들어오는지가 아니라, 어떻게 빠져나가는지다. 상류 소스는 실수를 출판한다. 보고서가 잘못된 패키지 이름에 붙는다. 연구자가 결과를 철회한다. 새벽 2시에 대량 임포트가 잘못된다. 이는 '만약'의 문제가 아니라 '언제'의 문제이므로, 수집한 모든 레코드는 그것을 생성한 정확한 상류 변경 단위까지 추적 가능해야 하며, 임포트는 하나의 동작으로 몇 분 안에 일괄 롤백될 수 있어야 한다.

출처 추적은 피처 플래그, 롤백과 같은 선반 위에 있어야 한다. 기록 보존이 아니라 운영 제어다. 의심스러운 레코드가 등장했을 때 모든 것이 해당 레코드를 들여온 정확한 상류 변경 단위를 추적할 수 있느냐에 달려 있다. "그 변경에서 들어온 모든 것을 되돌려라"는 빠른 수정이다. "데이터베이스를 뒤져 가능하면 찾아보자"는 최악의 한 주를 뜻한다.

당신은 자신이 만든 물을 마실 것이다

커뮤니티 인텔리전스에 기여하는 동시에 소비하는 조직이라면, 조만간 자신의 결과물이 낯선 타임스탬프를 달고 되돌아올 것이다. 커뮤니티 저장소는 다수의 기여자로부터 보고서를 집계하고, 집계 과정에서 누가 무엇을 처음 발견했는지에 대한 맥락이 제거된다. 아무 생각 없이 수집하면 자신의 보고서가 독립적인 확인처럼 파이프라인에 다시 들어오거나, 원본 레코드와 충돌해 같은 패키지에 중복 경보를 발생시키는 에코 챔버를 만들게 된다.

해결책은 단순하다. 기여한 내용에 핑거프린트를 찍고, 수신되는 모든 레코드를 그 핑거프린트와 대조한 뒤, 자신의 메아리는 입구에서 걸러낸다. 어떤 레코드를 확증으로 취급하기 전에, 소비자는 한 가지 질문에 답할 수 있어야 한다. 이것이 우리에게서 시작된 것인가? 이에 답하지 못하는 팀은 자신의 목소리를 측정하며 그것을 합의라고 부르는 것이다.

정규화가 예산을 먹는다

위협 데이터는 화려한 부분이다. 실제 작업은 생태계들이 아무것도 동의하지 않는다는 데 있다. 한 레지스트리는 패키지 이름을 대소문자 구분으로 처리하는 반면 이웃 레지스트리는 그렇지 않다. 영향받는 버전은 한 형식에서는 정확한 핀으로, 다른 형식에서는 개방형 범위로 도착하는데, 경계 의미론이 미묘하게 달라 문제를 일으킨다. 심각도 어휘는 일치하기를 거부한다. 그리고 이 중 어느 것도 크게 실패하지 않는다. 버전 범위 하나가 잘못 매핑되면 영향받지 않은 수천 명에게 경보를 보내거나, 실제로 영향받은 사람들에게는 조용히 침묵하는데, 두 실패 모두 시스템 내부에서는 정상 동작처럼 보인다.

따라서 예산을 여기에 배정해야 한다. 매핑·검증 레이어가 우리 엔지니어링 비용의 대부분을 소비했으며 거의 모든 정확성 리스크를 담당한다. 통합 추정치가 대부분 전송과 저장으로 채워져 있다면, 그 추정치는 틀린 것이다.

자동화에는 검토자가 아니라 피해 반경이 필요하다

8개 생태계 전체에서 하루 수십 건의 레코드를 다루는 상황에서, 레코드별 수동 검토는 형식적 절차에 불과하다. 확장될 수 없으며, 가능한 척하는 것은 피로를 사용자에서 조용히 밀려드는 내부 대기열로 옮기는 것뿐이다. 우리의 악성코드 경보는 자동으로 게시된다. 아무도 각 건을 읽지 않는다. 이것은 설계 결정이며 나는 이를 지지한다.

이것이 정당한 이유는 신뢰가 아니라 엔지니어링에 있다. 단일 임포트 실행이 생성할 수 있는 경보 수를 제한하는 상한이 있어서, 손상된 상류 배치가 사람이 알아차리기 전에 경보를 범람시킬 수 없다. 모든 배치는 하나의 단위로 롤백된다. 평범한 하루와 비교해 볼륨·형태 이상 징후가 플래그된다. 자동화 파이프라인에 대한 올바른 질문은 각 레코드를 누가 승인하느냐가 아니다. 이 시스템이 사람이 알아차리기 전에 저지를 수 있는 최대 실수는 무엇이며, 얼마나 빨리 되돌릴 수 있는가?

크게 실패하고, 조용히 수리하지 마라

피드 인제스션에서 가장 유혹적인 결정은 조용한 수정이다. 상류 레코드가 잘못된 버전 범위를 담고 있고, 파서가 의도를 추측할 수 있으며, 그 추측이 아마도 맞을 것이다. 저항하라. 조용한 수정은 남의 오류를 자신의 책임으로 변환한다. 추측은 당신의 이름으로 나가고, 다운스트림 소비자들이 그것을 물려받으며, 상류 소스는 자신의 레코드가 손상되어 있었다는 사실을 영영 알지 못한다.

유효하지 않은 레코드는 격리 상태로 실패해야 하며 상류에 보고서를 생성해야 한다. 느리다. 그러나 정확하다. 또한 공동체의 더 나은 구성원이 되는 길이기도 하다. 소비자들이 사적으로 수정하는 대신 품질 신호를 되먹임할 때만 공유 인텔리전스가 개선되기 때문이다.

출시 전 점검

다음 피드 통합 전을 위한 짧은 자기 점검 항목. 임의의 레코드를 상류 출처까지 추적할 수 있는가? 임포트 배치를 단일 동작으로 되돌릴 수 있는가? 자신의 기여가 돌아올 때 알아볼 수 있는가? 정규화가 현실에서 그럴 것처럼 추정치를 지배하고 있는가? 그리고 상류 데이터가 손상되었을 때, 파이프라인이 거부하는가, 아니면 추측하는가?

공유 위협 인텔리전스는 이 업계가 동의한 몇 안 되는 아이디어 중 그 동의를 받을 만한 것이며, 그 배경의 커뮤니티 소스들은 더 적은 소비자가 아니라 더 많은 소비자를 필요로 한다. 그러나 피드는 뉴스레터 구독이 아니다. 자동화된 결과가 볼트로 연결된, 남의 데이터베이스의 실시간 복제본이다. 그 수준의 진지함으로 운영하면 사용자를 더 안전하게 만든다. 체크박스처럼 취급하면 조만간 남의 최악의 하루를 자신의 것으로 자동화하게 될 것이다.