오픈소스 공급망 공격, 2026년 개발자 대응

오픈소스 공급망 공격, 2026년 개발자 대응

요약

2026년 들어 소프트웨어 공급망이 보안의 최전선이 됐다. 최근 국내 보도에 따르면, 글로벌 보안기업 소나타입은 2025년 새로 식별한 악성 오픈소스 패키지가 45만 개를 넘었다고 밝혔고, 리버싱랩스는 악성 패키지 탐지가 전년 대비 73% 증가했다고 보고했다. 개발자가 매일 쓰는 npm·PyPI·Maven Central이 곧 공격 표면이 됐다는 뜻이다. 핵심은 하나다. '내가 짠 코드'가 아니라 '내가 가져다 쓴 부품'이 뚫린다.

공격은 어디로 들어오나

공급망 공격의 통로는 대체로 정해져 있다.

• 타이포스쿼팅: 정상 패키지와 철자가 비슷한 악성 패키지를 올려, 오타 설치를 노린다.
• 계정 탈취: 인기 패키지 관리자의 계정을 털어 정상 패키지에 악성 코드를 심는다. 이름도 출처도 정상이라 알아채기 어렵다.
• 설치 훅: preinstall 같은 스크립트에 코드를 심어, npm install 순간 실행되게 한다.
• 전이 의존성: 내가 직접 추가하지 않았지만 딸려 들어온 하위 의존성에 악성 코드가 숨는다.

최근에는 AI 개발 도구까지 표적이 됐다. 정상적인 보안 감사 도구처럼 위장한 패키지가 자격증명을 외부로 빼돌리거나, 저장소 설정 파일에 악의적 지시문을 심어 AI 에이전트가 민감 정보를 유출하도록 유도한 사례도 보고됐다.

왜 지금 심해졌나

현대 애플리케이션은 대부분 오픈소스 '부품'의 조립이다. 단일 패키지 하나가 뚫리면 그걸 쓰는 수만 개 프로젝트로 피해가 번진다. 여기에 AI 코딩 도구가 확산되면서, 개발자가 AI가 제안한 패키지의 출처·취약점·라이선스를 매번 확인하기 어려워졌다. 개발 속도는 빨라졌는데 검증이 따라가지 못하는 것이다. 실제로 버라이즌 2026 데이터 침해 조사 보고서(DBIR)는 침해 사례의 31%가 소프트웨어 취약점 악용에서 시작됐다고 분석했다.

국내에서도 정책 과제가 됐다. 과학기술정보통신부와 국가정보원은 'AI 일상화 시대를 준비하는 SW 공급망 보안 강화 로드맵'을 발표했고, 2027년까지 공공 분야에 소프트웨어 구성요소 목록(SBOM) 제출을 제도화하는 방향이 논의되고 있다.

개발자가 지금 할 것

거창한 도구 도입 전에, 기본기부터 챙길 수 있다.

# 1) 알려진 취약점 스캔 (npm 예시)
npm audit

# 2) 정확한 버전 고정 - lockfile을 반드시 커밋
#    package-lock.json / pom.xml / gradle.lockfile

# 3) 설치 시 스크립트 실행 차단 (신뢰 전까지)
npm install --ignore-scripts

핵심 습관은 네 가지다. 첫째, lockfile을 반드시 커밋해 의존성 버전을 고정한다. 둘째, 패키지를 추가하기 전에 이름·다운로드 수·최근 관리 상태를 확인한다(타이포스쿼팅 방지). 셋째, CI 파이프라인에 의존성 스캔(SCA)과 SBOM 생성을 넣어 자동으로 검증한다. 넷째, AI가 제안한 패키지도 그대로 믿지 말고 출처를 한 번 더 확인한다.

마무리

공급망 보안의 출발점이 '완성된 서비스'에서 '코드가 만들어지는 순간'으로 앞당겨지고 있다. 이제는 무엇을 만들었는지만큼, 무엇을 가져다 썼는지를 아는 것이 보안의 기본이 됐다. 오늘 당장 할 수 있는 일은 단순하다 — lockfile을 커밋하고, audit를 돌리고, 새 의존성의 출처를 한 번 더 확인하는 것이다.