[보안칼럼] AI 시대 SW 공급망 보안, 신뢰의 기준이 바뀌었다

박준석 엘에스웨어 상무 지난해 12월 3일 공개된 리액트 서버 컴포넌트 취약점은 최고 등급인 CVSS 10.0이었다. 공개 몇 시간 만에 국가 배후 조직들이 악용을 시작했고, 한 랜섬웨어 조직은 침입 1분 안에 암호화를 시작했다. 올해도 악용은 이어졌다. 취약점보다 무서운 것은 위치였다. 리액트는 수많은 제품에 구성요소로 포함돼 있고, 넥스트JS처럼 리액트를 통째로 내장한 프레임워크에서는 의존성 목록만 확인하는 도구로는 취약 여부를 알아채지 못했다. 조직들은 취약점을 고치기 전에 어디에 들어 있는지부터 찾아야 했다. 공급망의 다른 얼굴은 오염이다. 8월 4일에는 널리 쓰이는 자바스크립트 라이브러리 keyv의 유지보수자 계정이 탈취되자 웜은 30분 만에 아홉 조직으로 번졌고, 같은 날 400개 넘는 패키지가 오염됐다. 개발자가 직접 고르지 않은 패키지도 간접 의존성을 통해 들어온다. 자바스크립트 프로젝트 대부분이 쓰는 코딩 규칙 점검 도구 ESLint에 딸려 들어오기 때문이다. 웜은 인공지능(AI) 코딩 도구의 자동 실행 설정까지 저장소에 심었다. 취약점이든 오염이든 첫 질문은 같다. 우리 소프트웨어(SW) 어디에 들어 있는가. AI는 구성요소 관리를 더 어렵게 만든다. 올해 초 글로벌 개발자 설문에서 코드의 42%는 AI가 생성하거나 보조한 것이었지만 항상 검증한다는 응답은 절반에 못 미쳤다. 공급망의 경계도 넓어져 모델 가중치와 학습 데이터, 에이전트 스킬과 도구 연결 서버까지 구성요소가 됐다. 주요 7개국(G7)이 5월 'AI를 위한 소프트웨어 자재명세서(SBOM)' 최소 요소를 낸 이유다. 공격자도 AI를 활용하면서 취약점 공개에서 악용까지의 간격을 시간 단위로 줄였다는 보고가 잇따른다. 오픈소스 관리 현장에서 보면 AI가 가져온 가장 큰 변화는 코드 품질보다 출처와 검증 과정의 추적이 어려워진다는 점이다. 사람이 고른 라이브러리에는 문서를 읽고 라이선스를 확인한 판단의 흔적이 남지만, AI가 끌어온 의존성에는 검토 과정이 빠지기 쉽다. 이력 없는 익명의 기여자가 보낸 코드를 매일 병합하는 셈이다. 신뢰의 기준도 바뀌어야 한다. 누구를 믿을 것인가보다 무엇이 들어 있는지 검증할 수 있는가가 중요하다. 6월의 미아즈마 웜은 정상 출처 증명까지 달고 나왔다. 계정이 탈취되면 출처 증명도 신뢰하기 어렵다. 7월 미국 사이버보안·인프라보안국(CISA)이 15개국과 함께 갱신한 SBOM 최소 요소는 구성요소 검증의...