← 블로그 목록

외주 개발의 숨은 공격 통로, SBOM과 의존성 검증을 발주 계약에 못 박는 법

2026.08.259분

발주사가 받는 것은 코드가 아니라 '의존성 뭉치'입니다

외주로 웹 서비스나 앱을 받으면 화면과 기능만 인수하는 것 같지만, 실제로는 그 밑에 깔린 수백 개의 오픈소스 라이브러리를 함께 인수합니다. 발주사 담당자는 소스코드를 열어 볼 일이 거의 없고, 어떤 외부 모듈이 어느 버전으로 들어왔는지 목록조차 받지 못하는 경우가 많습니다. 문제가 터지기 전까지 이 목록은 존재하지 않는 것이나 마찬가지입니다.

tilt shift lens photo of stainless steel chain

여기에 최근 개발 현장에서 빠르게 늘고 있는 AI 코딩 도구가 새로운 변수를 더합니다. 미국 UT San Antonio, U Oklahoma, Virginia Tech 연구진이 USENIX Security 2025에서 발표한 분석(2025년 8월)에 따르면, 16개 LLM이 생성한 코드 576,000개 표본에서 추천된 패키지의 19.7%가 실제로는 존재하지 않는 '환각' 패키지였습니다(상용 모델 약 5.2%, 오픈소스 모델 약 21.7%). 확인된 가짜 패키지명만 205,474개에 달했는데, 공격자가 이 이름을 미리 선점해 악성 코드를 올려 두면 개발자가 무심코 설치하는 순간 침투가 시작됩니다. 이를 '슬롭스쿼팅'이라 부릅니다.

이론적 위협이 아닙니다. 미국 CISA는 2025년 9월 23일 npm 생태계에서 자기전파형 공급망 침해('Shai-Hulud')가 광범위하게 발생했다고 긴급 경보를 냈습니다. 이 웜은 CI/CD 환경과 클라우드의 토큰·키 같은 비밀정보를 탈취해 유포했고, 앞선 8월 Nx 패키지 침해와 연결된 npm 최초의 자가확산형 공격으로 분석됐습니다. 외주 개발사가 쓰는 빌드 파이프라인 하나가 뚫리면 그 산출물을 받는 발주사까지 영향권에 들어갑니다.

왜 인수검수 이후가 아니라 계약 단계에서 막아야 하나

공급망 보안은 결과물을 다 받은 뒤 점검하려 하면 늦습니다. 이미 운영에 올라간 시스템에서 의존성 목록을 역추적하고 취약점을 걷어내는 일은 비용도, 협상력도 발주사에 불리하게 작동합니다. 계약서에 관련 조항이 없으면 외주사는 '요구 범위 밖'이라고 답할 수 있고, 발주사는 추가 비용을 떠안습니다.

정부도 이 흐름을 제도로 옮기고 있습니다. 과학기술정보통신부·국가정보원·디지털플랫폼정부위원회·KISA가 2024년 4월 18일 펴낸 「SW 공급망 보안 가이드라인 1.0」은 소프트웨어 구성요소 식별, 오픈소스·외부 모듈 사용현황 관리, SBOM(소프트웨어 자재명세서) 기반 취약점 영향범위 분석·대응을 상시 운영체계로 갖출 것을 요구합니다. SBOM은 결과물에 들어간 모든 구성요소를 이름·버전·출처 단위로 적은 명세서로, 문제가 된 라이브러리가 우리 시스템 어디에 얼마나 퍼져 있는지를 즉시 조회할 수 있게 해 줍니다.

green padlock on pink surface

AI 활용이 늘수록 이 명세의 중요성은 커집니다. Google DORA의 '2025 State of AI-assisted Software Development' 보고서는 AI 도입이 배포 처리량 증가와 상관되는 동시에 변경 실패·재작업·복구시간 증가 같은 불안정성과도 상관된다고 봤습니다. AI는 조직의 강점과 약점을 함께 키우는 증폭기이며, 그 효과는 플랫폼 품질 같은 시스템 성숙도에 좌우된다는 것입니다. 검증 절차가 없는 조직에서는 AI가 빠르게 만든 만큼 위험도 빠르게 쌓입니다.

RFP·계약·인수검수에 넣을 실무 체크리스트

추상적으로 '보안을 준수한다'가 아니라, 제출물과 판정 기준을 문서로 특정해야 실제로 작동합니다. 발주 단계별로 다음 항목을 요구조건으로 명문화해 보시기 바랍니다.

RFP·제안요청 단계

  • SBOM 제출 의무화: 납품물과 함께 표준 형식(예: SPDX, CycloneDX)의 SBOM을 제출하도록 명시하고, 직접·간접(전이) 의존성을 모두 포함하도록 요구합니다.
  • 의존성 출처·무결성 기준: 사용 패키지의 출처(공식 레지스트리 여부), 버전 고정(lockfile) 제출, 체크섬·서명 검증 결과를 함께 제출하도록 합니다.
  • AI 생성 코드 취급 규칙: 설치 전 패키지 실재 여부 확인 절차를 요구해 존재하지 않는 이름을 설치하는 슬롭스쿼팅 경로를 차단합니다.

계약 단계

  • 취약점 대응 SLA: 심각도별 조치 기한, 공지 의무, 재발 방지 조치를 조항으로 넣습니다.
  • 라이선스·책임 범위: 오픈소스 라이선스 목록과 준수 확인서를 산출물로 규정하고, 침해 발생 시 책임 소재를 정합니다.
  • 하자보수 기간 내 취약점 포함: 인수 후 발견된 알려진 취약점을 하자 범위에 포함시켜 사후 협상 부담을 줄입니다.

인수검수 단계

  • SBOM 대조 검수: 제출된 명세와 실제 빌드 산출물이 일치하는지 자동 스캔으로 확인합니다.
  • 알려진 취약점 스캔 결과 첨부: 검수 시점 기준 스캔 리포트와 미해결 항목의 조치 계획을 요구합니다.
  • 빌드 재현성: 동일 소스에서 동일 산출물이 나오는지 확인해 파이프라인 변조 가능성을 점검합니다.

맺으며

국내 스타트업과 중소기업은 개발 역량 상당 부분을 외주에 의존하지만, 공급망 보안을 계약 문서로 다루는 곳은 아직 많지 않습니다. 좋은 파트너를 고르는 일과 별개로, 발주사가 무엇을 제출받고 무엇으로 합격을 판정할지 먼저 정의해 두면 사고의 상당수는 계약 단계에서 걸러집니다. SBOM 제출, 의존성 출처·무결성 검증, 취약점 대응 절차 이 세 가지를 요구조건으로 문서에 못 박는 것이, 보이지 않는 수백 개의 의존성을 관리 가능한 자산으로 바꾸는 출발점입니다.