공급망 보안은 보통 코드 저장소나 패치 관리부터 떠올리기 쉬워요. 그런데 이번 사례는 보안의 시야가 한 단계 더 앞, 사용자가 실제로 보는 화면까지 확장돼야 한다는 점을 분명하게 보여줍니다.
특히 웹 서비스에서는 배포된 뒤의 상태가 곧 서비스의 실제 상태예요. 어떤 코드가 저장소에 있는지보다, 브라우저에서 지금 무엇이 실행되는지가 더 중요해질 때가 있습니다.
제3자 프론트엔드에서 시작된 손실
Polymarket은 제3자 프론트엔드 공급업체가 악성 JavaScript*를 주입당하면서 약 300만 달러 손실을 입었다고 전해졌어요. 공격자는 백엔드나 스마트컨트랙트 자체를 건드리지 않았고, 사용자의 브라우저에서 돌아가는 클라이언트 측 코드에 접근했습니다.
핵심은 이 지점이에요. 거래를 처리하는 기반 시스템이 멀쩡해 보여도, 화면에 내려오는 스크립트가 바뀌면 사용자 경험과 실제 결과는 동시에 흔들릴 수 있습니다. 이번 사건은 공급망 보안이 개발 단계의 검사만으로 끝나지 않는다는 사실을 다시 드러냈어요.
Veracode의 브리핑도 같은 맥락을 짚습니다. 정적 분석이나 의존성 스캔은 저장소와 파이프라인 안의 위험을 잘 잡지만, 운영 중인 JavaScript가 바뀌는 순간까지 보장하지는 못해요. 결국 보안의 빈칸은 코드 작성 시점이 아니라 배포 이후의 실행 구간에 남습니다.
왜 지금 이 문제가 더 크게 보일까요
이번 이슈가 더 눈에 띄는 이유는 공격자가 백엔드가 아닌 프론트엔드 공급망을 건드렸기 때문이에요. 사용자는 늘 같은 웹페이지를 보고 있었을지 몰라도, 그 안에서 실행되는 스크립트는 어느 순간부터 공격자에게 유리하게 바뀌었을 수 있습니다.
여기에 제3자 위험이 점검 주기 안에서만 관리된다는 한계도 겹쳐요. 계약 시점이나 정기 점검에서 문제가 없었더라도, 실제 운영 중에는 공급업체의 배포 경로가 언제든 바뀔 수 있습니다. 보안은 문서를 확인하는 일에서 끝나지 않고, 지금 서비스 안에서 무엇이 실행되는지 계속 확인하는 문제로 옮겨가고 있어요.
서비스를 볼 때 함께 확인해야 할 기준
이런 사건을 볼 때는 “우리 시스템이 안전한가”보다 “우리 서비스의 실행 경로가 어디까지 통제되는가”를 먼저 물어봐야 해요. 저장소, 배포 파이프라인, 외부 스크립트, 브라우저에서 실제로 돌아가는 코드가 하나의 흐름으로 이어져 있는지 점검해야 합니다.
또 하나는 점검의 빈도예요. 벤더 평가가 정기 검토에 머문다면, 공격자는 그 사이를 노립니다. 외부 스크립트와 공급업체 접근 권한, 세션 이상 징후를 연속적으로 관찰할 수 있어야 보이지 않는 변경을 늦게라도 잡을 수 있어요.
D.Flick Note
이번 사건이 남기는 메시지는 단순해요. 보안 사고는 더 이상 내부 코드만의 문제가 아니고, 제품 화면에 실려 온 외부 코드도 같은 수준으로 봐야 한다는 점입니다. Polymarket은 백엔드가 아니라 브라우저에서 무너졌고, 그 사실이 공급망 보안의 무게중심을 다시 옮겨 놓았어요.
제품을 만드는 입장에서는 이제 “배포했다”가 끝이 아니에요. 사용자가 보는 순간까지 통제할 수 있느냐가 서비스 신뢰를 가르는 기준이 됩니다. 다음 장애나 침해를 볼 때, 우리는 저장소보다 먼저 무엇을 확인하게 될까요?
References
- <small style="color:#8a8f98;">• 악성 JavaScript: 사용자 브라우저에서 실행되며 화면 동작이나 거래 흐름을 바꾸는 스크립트</small>