Axios 개발 도구 침해 사건과 OpenAI의 대응: 서드파티 리스크가 다시 도마 위로

익숙한 라이브러리에서 시작된 사건

혹시 자바스크립트로 HTTP 요청을 다뤄본 분이라면 Axios라는 이름이 친숙하실 거예요. fetch보다 사용하기 편하고, 인터셉터나 자동 JSON 변환 같은 기능을 제공해서 npm 다운로드 수가 매주 수천만 건에 달하는 초인기 라이브러리거든요. 그런데 최근 Axios 생태계의 일부 개발 도구가 침해당하는 사건이 발생했고, OpenAI가 이에 대한 자사의 대응을 공식적으로 발표했어요.

사건의 정확한 메커니즘은 공급망 공격(supply chain attack)의 한 유형으로 보여요. 이게 뭐냐면, 우리가 직접 만든 코드가 아니라 npm이나 PyPI 같은 곳에서 가져다 쓰는 외부 패키지에 악성 코드가 심어지는 공격이에요. 한 번 침해되면 그 패키지를 쓰는 모든 프로젝트가 잠재적 피해자가 되니까, 파급력이 어마어마해요.

OpenAI는 어떻게 대응했나

OpenAI는 자사 환경에서 해당 도구가 어떻게 사용되고 있었는지, 어떤 시스템이 영향을 받을 수 있었는지 신속하게 조사했다고 밝혔어요. 핵심은 고객 데이터나 API 키 같은 민감 정보가 유출되지는 않았다는 점이에요. 발견 즉시 영향받은 컴포넌트를 격리하고, 의존성을 안전한 버전으로 교체하고, 관련 자격 증명을 회전(rotate)시켰다고 해요.

자격 증명 회전이라는 게 뭐냐면, 토큰이나 API 키, 비밀번호 같은 것들을 새로 발급해서 기존 것을 무효화하는 절차예요. 만약 공격자가 어떤 키를 훔쳤더라도, 회전이 끝나면 그 키는 더 이상 동작하지 않으니까 피해를 차단할 수 있어요. 보안 사고 대응의 기본 중의 기본이지만, 큰 조직에서 모든 키를 일괄 회전시키는 건 실제로는 꽤 복잡한 작업이에요.

공급망 공격이 왜 점점 심각해질까

현대 소프트웨어는 정말 많은 외부 의존성 위에서 돌아가요. 평범한 웹 프로젝트 하나만 만들어도 node_modules 폴더에 수백, 수천 개의 패키지가 들어가잖아요. 그 패키지들은 또 각자의 의존성을 가지고 있고요. 결국 우리는 우리가 직접 본 적도 없는 수많은 코드를 신뢰하면서 쓰고 있는 셈이에요.

공격자 입장에서는 인기 패키지 하나만 장악하면 수십만 개의 프로젝트에 동시에 침투할 수 있으니까, 가성비가 너무 좋은 공격이에요. 최근 몇 년간 event-stream 사건, ua-parser-js 사건, PyTorch nightly 사건 등 굵직한 공급망 공격이 계속 일어났고, 그 빈도가 점점 늘고 있어요.

어떻게 막을 수 있을까

완벽한 방어는 어렵지만, 위험을 낮추는 방법은 여러 가지 있어요. 첫째, 의존성 잠금(lock file)을 잘 쓰는 거예요. package-lock.json이나 yarn.lock을 커밋해두면, 누군가 패키지 버전을 슬쩍 바꿔치기 해도 빌드 시점에 다른 버전이 깔리는 일을 막을 수 있어요.

둘째, SCA(Software Composition Analysis) 도구를 써서 의존성 트리에 알려진 취약점이 있는지 자동 스캔하는 거예요. Snyk, Dependabot, GitHub의 Advanced Security 같은 도구들이 이런 일을 해줘요. 셋째, SBOM(Software Bill of Materials)을 관리해서 우리 시스템에 어떤 패키지의 어떤 버전이 들어 있는지 항상 파악하고 있어야 해요. 사고가 터졌을 때 "우리는 영향받았는가?"를 빠르게 답할 수 있어야 하거든요.

넷째, 자격 증명 최소 권한 원칙을 지켜야 해요. 빌드 환경이나 CI/CD에서 쓰는 토큰은 꼭 필요한 권한만 가지도록 좁혀두는 거죠. 그래야 공격자가 토큰을 훔쳐도 할 수 있는 일이 제한되니까요.

업계 흐름에서 보면

미국에서는 바이든 행정부 시절부터 SBOM 의무화 같은 정책이 추진되어 왔고, 유럽도 사이버 회복력 법(Cyber Resilience Act)을 통해 비슷한 방향으로 가고 있어요. 한국도 SW 공급망 보안에 대한 가이드라인이 점점 구체화되고 있는 상황이에요. 즉, 공급망 보안은 이제 "보안팀의 업무"가 아니라 "모든 개발자의 일상 업무"가 되어가고 있어요.

OpenAI 같은 큰 회사가 사고에 대해 이렇게 빠르고 투명하게 발표하는 건 좋은 신호예요. 예전에는 사고를 숨기는 분위기가 강했는데, 이제는 "우리가 이렇게 대응했다"를 공개하는 게 신뢰 회복의 정석이 되어가고 있거든요.

한국 개발자에게 주는 시사점

당장 오늘 할 수 있는 일을 정리하면, 우선 여러분 프로젝트의 package.json을 한 번 열어보세요. 직접 추가하지 않은 의심스러운 패키지가 있는지, 너무 마이너한데 별표 수가 적은 패키지를 깊은 의존성에 두고 있는지 확인하는 거예요. 그리고 GitHub 저장소에 Dependabot 알람을 켜두는 것만으로도 상당한 보호 효과가 있어요.

사내에서 AI 코딩 도구나 LLM API를 쓰는 팀이라면, 그 도구들이 의존하는 SDK나 라이브러리도 한 번 점검해보세요. AI 관련 도구들은 빠르게 업데이트되다 보니 보안 검증이 충분하지 않은 경우가 종종 있거든요.

마무리

우리 코드의 진짜 표면적은 우리가 쓴 코드뿐 아니라, 우리가 가져다 쓴 모든 패키지를 합한 것이에요. 그 사실을 잊지 않는 게 공급망 보안의 출발점이에요. 여러분은 의존성 관리에 대해 어떤 원칙을 가지고 계신가요? 사내에서 SBOM이나 SCA 도입 경험이 있다면 댓글로 공유해주세요.