공급망 공격은 기업의 내부 시스템을 직접 뚫는 대신, 이미 연결된 협력사나 소프트웨어를 거쳐 들어오는 공격이다.
기업은 클라우드 플랫폼, SaaS, 결제대행사, 외주 업체, API, 오픈소스 패키지, AI 도구에 의존하고, 이 가운데 일부는 내부 시스템이나 민감한 데이터에 접근한다(p.20).
AI가 없던 취약점을 만들지는 않는다.
다만 공격자가 취약점을 찾고, 이해하고, 악용하는 속도를 높여 공급망의 약한 고리를 더 쉽게 찾아내게 한다(p.20).
그래서 공급망 공격 대응도 바뀌어야 한다.
1년에 한 번 받는 설문 답변에 머물지 말고, 협력사 보안의 근거가 무엇인지, 지금도 유효한지 추적하고 다시 확인할 수 있는 증거로 관리해야 한다(p.21).
우리 회사가 기대고 있는 것들
기업의 보안 상태는 연결된 조직과 소프트웨어의 보안에도 점점 더 좌우된다.
누가 접근하는지, 어떤 데이터를 다루는지, 어떤 소프트웨어를 들여오는지부터 살펴봐야 한다(p.20).
| 의존 대상 | 예 | 확인할 점 |
|---|---|---|
| 클라우드 | 서버·저장소 플랫폼 | 어떤 데이터가 올라가나 |
| SaaS | 업무용 온라인 서비스 | 누가 어디까지 접근하나 |
| 결제대행 | 결제 처리업체 | 어떤 고객 정보를 다루나 |
| 외주 업체 | 개발·운영 협력사 | 내부 시스템 권한이 있나 |
| API | 외부 서비스 연동 | 어떤 업무가 의존하나 |
| 오픈소스 | 공개 패키지 | 어떤 소프트웨어가 들어오나 |
| AI 도구 | 코딩·업무 AI | 접근 권한과 연결 범위 |
공격자는 가장 강한 기업의 방어를 정면으로 뚫을 필요가 없다.
작은 공급업체나 외주 업체, 의존 소프트웨어에 이미 신뢰받는 경로가 있다면 그 경로를 이용한다(p.20).
공급망 공격을 살필 때 협력사 이름만 나열해서는 이런 연결 관계가 보이지 않는다.
AI가 공격자에게 준 것은 속도
공격자는 AI로 기술 문서를 처리하고, 공개 정보를 대량으로 찾고, 맞춤형 피싱 문구와 스크립트를 만들거나 고치고, 노출된 서비스를 분석한다.
예전에는 훨씬 많은 수작업이 필요했던 일이다(p.20).
그 결과 공급망에서 약한 연결 지점을 찾기가 쉬워졌고, 공급망 공격의 문턱도 그만큼 낮아졌다.
내부 통제가 강한 기업이라도 신뢰하는 외부 경로에서 비롯된 제3자 위험까지 함께 살펴야 하는 이유이다(p.20).
공급망 공격 사례: AI가 지어낸 유령 패키지
한 대형 교육·연구기관에서 연구원과 조교들이 자율형 AI 코딩 에이전트로 교육과정과 내부 연구 도구를 만들었다.
에이전트는 존재하지 않는 패키지 의존성, 이른바 '유령 라이브러리'를 반복해서 만들어 냈다(p.16).
이렇게 이어졌다(p.16-17) 공격자가 에이전트가 반복해 지어내는 패키지 이름을 추적했다.
그 이름으로 악성 코드를 담은 패키지를 공개 저장소에 등록했다.
이후 자동 빌드 과정이 그 패키지를 가져왔다.
민감한 학술 연구 자료와 기관 지식재산이 조용히 유출됐다.
업계에서는 이렇게 지어낸 패키지 이름을 노리는 수법을 '슬롭스쿼팅(slopsquatting)'이라고도 부른다.
AI 코딩 에이전트가 공급망 공격의 새 입구가 된 셈이다.
연간 설문지만으로는 부족한 이유
협력사 보안 설문지는 정보를 모으는 데 유용하다.
하지만 답변은 협력사의 자기 신고에 기대고, 제출된 정보도 빠르게 낡는다.
답변을 뒷받침하는 증거가 무엇인지, 최신 자료인지, 지난 검토 이후 달라진 점은 없는지는 고객사가 직접 확인해야 한다(p.20).
핵심은 설문에 바르게 답했느냐가 아니다.
몇 달이 지난 뒤에도 그 신뢰 판단을 설명할 수 있느냐가 중요하다(p.20).
공급망 보안, 증거로 관리하는 5가지
기고는 보안에 관한 '주장'에서 추적하고, 버전을 구분하고, 다시 확인할 수 있는 '증거'로 옮겨 가자고 제안한다(p.21).
| 할 일 | 이렇게 한다 |
|---|---|
| 의존 지도 | 업체 이름만이 아니라 접근 범위·다루는 데이터·들여오는 소프트웨어·기대는 업무까지 정리 |
| 증거 요구 | 답변과 함께 침투 테스트 보고서·인증·정책·취약점 조치 기록·독립 평가를 확인 |
| 출처 보존 | 누가 제공했는지, 언제 승인했는지, 어떤 버전을 봤는지, 이후 바뀌었는지 기록 |
| 민감 증거 비공개 | 보고서는 암호화·접근 통제. 블록체인은 문서를 올리지 않고 지문·시각·소유 기록만 남기는 데 활용 가능 |
| 상시 신뢰 | 증거의 만료·변경·교체가 보이게 해 1년 전 스냅샷에 기대지 않기 |
개발 쪽에서는 패키지가 들어오는 경로를 관리해야 한다.
AI 코딩 에이전트와 빌드 파이프라인이 공개 저장소에 제한 없이 접근하지 못하게 하고, 사설 미러에서 암호학적 출처 검증, 패키지 연령 기준, 자동 행위 검사를 거친 패키지만 받는다(p.17).
놓치기 쉬운 함정
가장 위험한 가정은 '검토할 때 사실이었으니 지금도 사실'이라는 생각이다.
침투 테스트 보고서는 새 보고서로 대체되고, 인증은 만료된다.
닫은 줄 알았던 취약점이 다시 열리고, 협력사의 환경도 바뀐다.
그사이 고객사는 같은 PDF와 설문 답변을 계속 근거로 삼는다(p.21).
협력사의 보안 상태가 바뀐 시점부터 고객사가 그것을 알아차리는 시점까지의 간격은 그 자체로 공격 표면이 된다(p.21).
출처와 변경 이력을 남겨도 그 기록만으로 보안 주장이 참이라고 증명되지는 않는다.
나쁜 증거는 여전히 나쁜 증거이기 때문이다(p.21).
자주 묻는 질문
Q1. 중소기업도 공급망 공격 대상이 되나?
그렇다. 작은 공급업체나 외주 업체가 큰 고객사로 이어지는 신뢰받는 경로를 갖고 있다면 공격자는 그 경로를 이용할 수 있다(p.20).
우리 회사가 쓰는 SaaS와 오픈소스 패키지까지 포함해 의존 관계를 파악하는 것부터 시작한다.
Q2. 협력사에는 무엇을 요구해야 하나?
설문 답변을 뒷받침할 증거를 요청한다.
위험이 큰 항목은 침투 테스트 보고서, 인증, 정책, 취약점 조치 기록, 독립 평가로 확인하고, 누가 제공했는지, 언제 승인했는지, 어떤 버전인지, 이후 바뀌었는지를 함께 기록한다(p.21).
Q3. AI 코딩 도구를 쓰지 말아야 하나?
아니다. KCBCA Signals가 던지는 질문도 AI 코딩의 속도를 크게 해치지 않으면서 유령 의존성 위험을 줄이는 방법이다(p.7).
답은 금지가 아니라 경계이다.
패키지가 사설 미러를 거쳐서만 들어오게 한다(p.17).
한눈에 정리
- 공급망 공격은 연결된 협력사·소프트웨어를 거쳐 들어온다
- AI는 약한 고리를 찾고 악용하는 속도를 높인다
- AI가 지어낸 패키지 이름이 악성 패키지로 돌아온 사례가 있다
- 연간 설문지에 머물지 말고 다시 확인할 수 있는 현재의 증거로 관리한다
앞으로의 공급망 보안은 설문지를 몇 장 보냈느냐보다, 지금의 증거로 그 협력사를 왜 계속 믿는지 설명할 수 있느냐로 평가받게 될 것이다(p.21).
KCBCA Signals Vol.1 Issue 1 원문 읽기
참고: KCBCA Signals Vol.1 Issue 1 Rob Goehring(Wisr.ai CEO) p.20-21 Jack Wong(KCBCA GLOBAL 이사) p.16-17 토론 질문 p.7
