빠른 요약

  • 악성 Rust 크레이트와 악용 가능한 VS Code 확장 동작에 관한 보고서는 공급망 위험이 프로덕션 의존성에만 머물지 않는다는 점을 보여준다. 에디터, 빌드 시스템, 플러그인 생태계도 애플리케이션 패키지와 같은 보안 모델에서 관리해야 한다.
  • 침해된 의존성이나 확장은 소스 코드, SSH 키, 배포 자격 증명이 있는 환경에서 실행될 수 있다. 개발 조직은 전체 툴체인을 소프트웨어 공격 표면으로 보고 통제해야 한다.
  • 다음 스프린트에서 에디터 확장과 빌드 도구를 목록화하고 각각의 코드 실행 위치를 파악한 뒤, 필요하지 않은 워크스테이션과 CI 러너에서 장기 자격 증명을 제거한다.

무슨 일이 있었나

컴파일 단계에서 실행되는 크레이트와 에디터 내부에서 동작하는 확장은 자산 목록에서 빠지기 쉬운 공격 표면이다. 그러나 개발자 워크스테이션이나 빌드 러너에서 코드를 실행할 수 있다면, 해당 의존성이 최종 프로덕션 런타임에 남지 않더라도 피해를 일으킬 수 있다.

Rust와 VS Code 관련 조사 결과가 나온 가운데 AWS는 Security Hub Extended에 공급망 보안 범주를 추가했다. 서로 별개의 사안이지만, 세 사례는 애플리케이션 라이브러리 스캔을 넘어 자산 파악, 예방 통제, 사고 대응을 연결해야 한다는 공통 과제를 드러낸다.

최근 보고서에서 확인된 위험은 무엇인가?

arrayref 공격 캠페인 분석에 따르면 악성 arrayref 버전과 다른 Rust 크레이트들은 컴파일 시점에 백도어를 실행했다. 분석은 해당 인프라가 Mastra와 axios 관련 최근 공급망 공격 활동과 상당 부분 겹치며, 이 신호를 DPRK 캠페인과 연관 지었다.

핵심은 실행 시점이다. 컴파일 단계의 코드는 소스와 자격 증명을 보유한 워크스테이션 또는 CI 환경에 접근할 수 있다. 최종 애플리케이션 산출물에 런타임 스캐너가 쉽게 찾을 형태의 백도어가 남지 않더라도 이미 빌드 환경은 영향을 받을 수 있다.

다른 공격 표면에서는 ProjectDiscovery가 Markdown Preview Enhanced를 분석했다. 약 950만 회 설치된 것으로 보고된 이 VS Code 확장을 Neo로 점검한 결과, 두 공격 표면에서 CVE 다섯 건이 발견됐다. 여기에는 일반 Markdown 파일이 미리보기 내부의 JavaScript 실행으로 이어질 수 있는 WaveDrom 렌더링 결함도 포함됐다.

이 사례들이 모든 크레이트나 에디터 확장이 위험하다는 뜻은 아니다. 다만 확장은 자동 업데이트될 수 있고 사용자 권한으로 실행되는 반면, 개발 도구는 애플리케이션의 소프트웨어 자재 명세서에 포함되지 않는 경우가 많다는 신뢰 모델의 공백을 보여준다.

애플리케이션 SBOM만으로 부족한 이유는?

SBOM은 일반적으로 제품을 빌드하거나 배포하는 데 사용된 구성 요소를 기술한다. 유용한 기준이지만, 제품이 만들어지기 전부터 소스 코드에 작용하는 에디터 확장, 컴파일러 플러그인, 빌드 스크립트, 패키지 관리자 훅, CI 유틸리티는 놓칠 수 있다.

운영 관점의 자산 목록은 최소 세 계층을 구분해야 한다. 애플리케이션 의존성은 산출물에 영향을 주고, 빌드 의존성은 산출물 생성 과정에 관여하며, 워크스테이션 도구는 저장소와 SSH 키, 서명 자료, 레지스트리 자격 증명 가까이에서 동작한다. 하나의 패키지가 여러 계층에 걸칠 수 있지만 필요한 통제는 서로 다르다.

공격 표면실행 지점영향받을 자산우선 통제
애플리케이션 의존성빌드 또는 런타임애플리케이션과 데이터버전 고정, 변경 검토, 의존성 스캔
빌드 도구컴파일러 또는 CI 러너산출물과 배포 시크릿격리 러너, 최소 권한, 재현 가능한 빌드
에디터 확장개발자 워크스테이션소스, SSH 키, 토큰허용 목록, 업데이트 통제, 자격 증명 분리

이 표는 각 보고서에 등장한 제품의 전체 기능을 설명하는 것이 아니라 권장 평가 프레임워크다. 외부 코드가 어디에서 실행되고, 그 위치에서 어떤 권한을 갖는지 확인하는 데 목적이 있다.

개발 조직은 어떤 통제를 바꿔야 하나?

먼저 확장, 빌드 플러그인, 로컬 유틸리티를 책임자가 지정된 자산 목록에 포함해야 한다. VS Code를 사용한다면 승인된 확장 목록을 정하고 게시자와 사용 범위를 검토한 뒤, 권한이 낮은 환경에서 업데이트를 시험하고 확대 배포하는 방식을 고려할 수 있다.

두 번째는 신뢰할 수 없는 코드가 실행됐을 때의 피해 범위를 줄이는 것이다. 꼭 필요하지 않은 워크스테이션과 CI 러너에는 장기 자격 증명을 두지 않고, 소스 읽기와 산출물 서명, 패키지 배포 권한을 분리해야 한다. 민감한 빌드 작업의 네트워크 접근을 제한하는 것도 한 실행 경로가 도달할 수 있는 범위를 줄인다.

세 번째로 의존성 변경을 검토 가능한 보안 이벤트로 취급해야 한다. lockfile 수정, 새 버전, 게시자 변경, 새로운 빌드 동작은 해당 구성 요소가 가진 권한에 비례해 검토할 필요가 있다. 이는 정책과 승인, 감사 추적을 일관되게 적용하는 관리형 Control Plane 설계와도 맞닿아 있다.

  • 개발 머신에서 코드를 실행할 수 있는 확장과 도구를 목록화한다.
  • 설치, 컴파일, 패키징 과정에서 실행되는 스크립트를 검토한다.
  • 패키지 배포 자격 증명을 일상적인 코드 편집 환경과 분리한다.
  • 예상하지 못한 lockfile, 게시자, 배포 출처 변경을 탐지한다.
  • 사고 발생 시 토큰 폐기와 러너 격리를 수행할 절차를 마련한다.

AWS의 통합 확대는 무엇을 시사하나?

AWS는 Supply Chain Security를 Security Hub Extended의 열 번째 범주로 추가했다. 공식 발표에 따르면 이 이니셔티브는 2월 이후 9개 범주의 14개 선별 파트너에서 10개 범주의 23개 파트너로 확대됐다.

중앙 대시보드 하나로 의존성이나 확장 위험을 해결할 수 있다는 의미는 아니다. 중요한 변화는 여러 도구의 공급망 보안 탐지 결과를 더 넓은 보안 운영 흐름과 연결하고, 공통 맥락에서 평가하고 대응하려는 방향이다.

앞으로는 통합의 품질을 살펴봐야 한다. 적용 범위가 의존성뿐 아니라 빌드 환경과 워크스테이션까지 포함하는지, 경고에 우선순위를 판단할 맥락이 충분한지, 탐지 후 자격 증명 폐기와 버전 차단 또는 호스트 격리까지 얼마나 빠르게 이어지는지가 핵심이다.

결론

  • 공급망 공격 표면에는 빌드 단계와 개발자 워크스테이션에서 실행되는 코드도 포함된다.
  • 애플리케이션 SBOM은 확장, 플러그인, 빌드 도구 목록을 대체하지 못한다.
  • 허용 목록, 최소 권한, 단기 자격 증명은 잠재적 피해 범위를 줄인다.
  • 중앙 가시성은 탐지 결과가 명확한 대응 절차로 연결될 때 가치가 있다.

관련 글

참고 자료

개발자가 주목해야 하는 이유

침해된 의존성이나 확장은 소스 코드, SSH 키, 배포 자격 증명이 있는 환경에서 실행될 수 있다. 개발 조직은 전체 툴체인을 소프트웨어 공격 표면으로 보고 통제해야 한다.

  1. 1다음 스프린트에서 에디터 확장과 빌드 도구를 목록화하고 각각의 코드 실행 위치를 파악한 뒤, 필요하지 않은 워크스테이션과 CI 러너에서 장기 자격 증명을 제거한다.