uv audit 사용 전 알아둘 것: 취약점 검사와 악성 패키지 검사는 다릅니다

철망 바구니의 종이 봉투들과 별도 접시에 놓인 검은 봉투. 이해를 돕기 위한 AI 생성 개념 이미지입니다.

잠금 파일은 같은 의존성 조합을 다시 설치하도록 돕지만 그 조합이 안전하다고 보증하지 않습니다. 알려진 취약점이 있는 정상 패키지와, 탈취·typosquatting 등으로 악성 행위가 보고된 패키지는 조사와 대응이 다릅니다.

uv의 검사 결과를 볼 때는 무엇을 조회했는지, 어떤 데이터베이스를 기준으로 했는지, 패키지가 이미 설치·실행됐는지를 분리해야 합니다.

uv audit 발표에는 두 경로가 있습니다

Astral의 2026년 6월 8일 발표는 의존성의 알려진 취약점·deprecated/quarantine 같은 adverse status를 검사하는 uv audit와, 설치·동기화 때 알려진 악성 패키지 정보를 조회하는 기능을 구분합니다. 두 기능 모두 발표와 현재 문서에서 preview로 다뤄지고, 악성 패키지 검사는 opt-in으로 안내됩니다.

현재 CLI 문서는 설치한 버전에서 사용할 수 있는 옵션과 대상을 확인하는 정본입니다. 기본적으로 프로젝트의 extras와 dependency groups도 audit 대상이 되며, 필요하면 group·extra를 제외하거나 JSON·SARIF 형식으로 결과를 내보낼 수 있습니다. 발표 당시 기본값을 미래 버전에도 그대로 적용하지 않습니다.

uv --version
uv audit --help

# lock을 갱신하지 않고 audit하고, CI용 SARIF로 출력하는 예
uv audit --locked --output-format sarif

# 알려진 악성 패키지 조회를 켠 동기화 예
UV_MALWARE_CHECK=1 uv sync --locked

uv audit --locked는 lockfile이 최신이고 변경되지 않는지 요구합니다. UV_MALWARE_CHECK=1은 sync 과정에서 현재 lock 해상도에 알려진 MAL advisory가 매칭되는지 확인하는 별도 경로입니다. 먼저 버전과 도움말을 기록한 뒤 검사 범위와 형식을 고정해야 결과를 재현할 수 있습니다. 이 명령은 문서 기반 확인 예시이며 여기서 실행한 결과는 아닙니다.

네 가지 상태를 혼동하지 않습니다

상태	의미	다음 행동
잠금 성공	resolver가 버전 조합을 선택	테스트와 별도 안전 검사
알려진 취약점 발견	특정 버전에 공개 advisory가 매칭	영향 경로와 수정 버전 확인
deprecated/quarantine 상태	패키지 상태에 불리한 신호가 매칭	유지보수·배포 출처와 대체 경로 확인
알려진 악성 패키지 매칭	현재 공개된 MAL advisory가 lock 해상도에 매칭	설치·실행·비밀 노출 조사
결과 없음	조회 데이터에서 매칭 없음	안전 보증이 아니라 미발견

스캐너 결과가 0이라고 새 취약점, 비공개 사고, 빌드 스크립트 위험이 사라지는 것은 아닙니다. 특히 악성 패키지 검사는 공개 advisory에 의존하므로 아직 보고되지 않은 변조나 악성 동작을 판별하지 못합니다. 반대로 advisory가 있다고 내 애플리케이션이 반드시 취약 경로를 실행한다는 뜻도 아닙니다.

정상 취약점과 악성 패키지 대응이 다른 이유

가상의 정상 라이브러리 1.2.3에 특정 입력에서 발생하는 취약점이 있다고 합시다. 해당 기능을 사용하는지 확인하고 수정 버전으로 올린 뒤 회귀 테스트할 수 있습니다.

악성 패키지가 이미 설치되고 실행됐다면 단순 삭제로 끝나지 않습니다. uv 발표가 설명하듯 PyPI에서 배포판이 quarantine돼도 lockfile이 object storage의 직접 배포 파일을 가리키면 설치 경로가 남을 수 있으므로, lock·index·배포 파일의 출처를 함께 확인해야 합니다. 설치 스크립트가 환경 변수, 저장소 토큰, SSH 키에 접근했을 가능성도 조사해야 합니다.

1. 영향 장비와 CI 작업을 격리합니다.
2. 설치·실행 시각과 프로세스·네트워크 로그를 보존합니다.
3. 노출 가능성이 있는 토큰과 키를 폐기·회전합니다.
4. 깨끗한 이미지에서 환경을 다시 만듭니다.
5. lock과 패키지 출처가 유입된 변경을 추적합니다.
6. 동일 이름·유사 이름 패키지가 다른 저장소에 없는지 확인합니다.

이 절차는 일반적인 사고 대응 출발점이며 조직의 보안 담당 절차가 우선합니다.

CI에서는 실패 기준을 명시합니다

검사 명령을 추가하는 것만으로 정책이 생기지 않습니다.

항목	정할 내용
대상	프로젝트 전체, 특정 group, 설치 환경
advisory	어느 심각도·상태에서 실패할지
예외	소유자, 근거, 만료일
네트워크	조회 서비스 허용과 캐시 정책
결과 보존	도구 버전, DB 시점, lock commit
악성 신호	즉시 중단과 사고 대응 연결

영구 ignore를 늘리기보다 예외마다 만료일과 대체 계획을 두는 편이 낫습니다. 잠금 파일 변경 PR에서는 audit 결과와 테스트를 같이 검토합니다.

공급망 검사는 한 도구로 닫히지 않습니다

추가로 볼 항목은 다음과 같습니다.

• 패키지 이름과 공식 배포자 확인
• index와 mirror 출처 고정
• 가능하면 배포 파일 해시 검증
• CI 설치 토큰의 최소 권한
• 빌드 스크립트와 native binary 검토
• 생성된 SBOM과 배포 이미지 대조

uv audit은 알려진 advisory와 상태를 조회하는 한 층이고, malware check도 공개된 MAL advisory를 기준으로 sync를 막는 경로입니다. 재현 가능한 lock, 코드 리뷰, 비밀 관리, 패키지 실행 전 격리와 런타임 탐지는 별도 층입니다.

정리

uv.lock은 버전을 고정하고 uv audit은 알려진 문제를 조회합니다. 알려진 취약점과 악성 패키지 신호는 대응 범위가 다르며, 악성 패키지가 실행됐다면 토큰 회전과 장비 조사까지 고려해야 합니다. 결과 없음은 안전 인증이 아닙니다.

자료 확인일은 2026년 9월 7일입니다. Astral 발표와 CLI 문서를 기준으로 정리했으며 실제 프로젝트 검사나 악성코드 분석을 수행하지 않았습니다.