빌드 산출물이 쌓인 창고의 옆문 — Artifactory 인증 처리에 생긴 틈

이미지 출처: CISA KEV

사내에서 아티팩트 저장소는 보통 "그냥 있는 것"으로 취급됨. CI가 빌드한 jar와 컨테이너 이미지가 흘러들어가고, 배포 파이프라인이 그걸 다시 꺼내 쓰는 통로일 뿐이라 여겨지기 때문임. 그런데 그 창고의 문을 여는 절차 자체가 헐거우면, 창고 안 물건은 물론이고 그 물건을 받아 쓰는 모든 시스템이 함께 흔들림. CVE-2026-82329로 등록된 JFrog Artifactory의 부적절한 인증(Improper Authentication) 이슈가 딱 그 지점을 건드림.

핵심 요약

• Artifactory의 인증 처리 과정에서 신원 검증이 제대로 이뤄지지 않아, 정상 자격증명 없이 접근이 성립할 수 있는 문제임
• 아티팩트 저장소는 공급망의 상류이므로, 한 번의 인증 우회가 다운스트림 배포 전체의 신뢰를 깨뜨림
• 방어는 벤더 패치 적용이 1순위이고, 그 전까지는 노출면 축소·인증 로그 이상탐지·아티팩트 무결성 검증으로 버티는 게 현실적임

왜 '인증 우회'가 저장소에서 특히 아픈가

부적절한 인증은 개념 자체는 단순함. 시스템이 "너 누구야"를 묻긴 하는데, 그 대답을 검증하는 로직이 어딘가에서 헐겁게 끊어지는 것임. 토큰 서명을 확인하지 않거나, 특정 경로나 헤더 조합에서 인증 필터가 우회되거나, 익명 접근 경로가 의도보다 넓게 열리는 식의 문제들이 전부 이 범주에 들어감.

다만 같은 결함이라도 어디에 있느냐에 따라 체감 위험이 완전히 달라짐. 사내 위키에 인증 우회가 있으면 문서가 새는 사고지만, 아티팩트 저장소에 있으면 이야기가 달라짐. 이유는 이럼.

• 상류 위치: 저장소의 산출물은 수십 개 서비스로 퍼져나감. 여기 하나를 건드리면 다운스트림 전체가 오염될 수 있음
• 신뢰 전제: 배포 파이프라인은 보통 "우리 저장소에서 받은 건 안전하다"는 가정 위에서 동작함. 그 가정이 검증 없이 굴러가는 조직이 많음
• 자격증명 저수지: 저장소 설정에는 외부 레지스트리 자격증명, 원격 리포지터리 토큰, 서명키 참조 같은 것들이 함께 들어 있는 경우가 흔함

공격 시나리오는 개념 수준으로만

구체적인 요청 형태나 페이로드를 늘어놓을 생각은 없음. 방어자 입장에서 필요한 건 "어떤 모양으로 벌어지는가"에 대한 감각이지 재현 절차가 아니기 때문임. 흐름은 대략 이럼: 인증이 성립하지 않아야 할 요청이 인증된 것처럼 처리됨 → 배포 권한이 있는 컨텍스트로 리포지터리에 쓰기가 가능해짐 → 정상 버전과 구분되지 않는 산출물이 저장소에 자리 잡음 → CI/CD가 평소처럼 그걸 당겨 배포함.

여기서 무서운 건 마지막 단계가 완전히 정상적인 동작이라는 점임. 파이프라인은 아무 잘못도 하지 않고, 로그도 깨끗하고, 알림도 울리지 않음. 그래서 이런 유형은 사고 인지가 늦음.

탐지 — 무엇을 보면 보이는가

패치 전후 모두 챙겨야 하는 관측 포인트를 정리하면 이럼.

• 인증 이벤트의 결측: 접근 로그에는 리포지터리 read/write가 찍혔는데, 대응하는 로그인·토큰 발급 이벤트가 앞에 없는 경우. 인증 우회 계열은 이 '앞뒤 안 맞음'으로 드러나는 일이 많음
• 주체 프로파일 이탈: 평소 pull만 하던 서비스 계정이 갑자기 push를 하거나, 특정 리포지터리만 만지던 주체가 광범위한 경로를 훑는 패턴
• 비정상 시간대·출처: CI 러너 대역이 아닌 IP에서 들어온 배포성 요청. 저장소는 접근 출처가 비교적 정형적이라 이 탐지가 잘 먹힘
• 산출물 메타데이터 불일치: 체크섬은 새로 갱신됐는데 대응하는 빌드 잡 기록이 없는 아티팩트. CI 빌드 ID와 저장소 업로드 기록을 조인해두면 이런 고아 아티팩트가 튀어나옴
• 덮어쓰기 시도: 이미 배포된 릴리스 버전에 대한 재업로드. 정책상 금지돼 있더라도 시도 자체를 알림으로 올려두면 좋음

완화 — 순서대로 하면 되는 것들

• 패치가 1순위: 인증 로직 결함은 설정으로 우회해 막기 어려운 부류임. 벤더가 배포한 고정 버전으로 올리는 게 유일하게 확실한 조치임. 자체 호스팅 인스턴스는 특히 미뤄지기 쉬우니 담당자를 명시해두는 게 좋음
• 노출면 축소: Artifactory 관리·API 엔드포인트를 인터넷에 그대로 열어둘 이유는 거의 없음. VPN이나 사내망, 최소한 IP 허용목록 뒤로 넣는 것만으로도 실질 위험이 크게 줄어듦
• 익명 접근 재점검: 오래 굴린 인스턴스일수록 "잠깐 열어두고 잊은" 익명 read 설정이 남아 있음. 리포지터리별로 한 번씩 훑어볼 만함
• 권한 최소화: CI용 토큰에 관리자 권한이 붙어 있는 경우가 생각보다 많음. 읽기용과 배포용을 분리하고, 배포용은 대상 리포지터리를 좁히는 게 기본임
• 무결성 검증을 배포 단계에도: 저장소를 무조건 믿지 말고, 배포 직전에 서명 검증이나 체크섬 대조를 한 겹 더 두는 것. 인증 우회가 나더라도 여기서 걸릴 수 있음
• 불변 태그 정책: 릴리스 아티팩트는 덮어쓰기 불가로 잠가두기. 조용한 교체를 막는 가장 값싼 방법임

사고가 났다고 가정하면

이런 유형은 "우리는 안 당했다"를 증명하기가 은근히 까다로움. 그래서 점검할 때는 순서를 정해두는 게 편함. 먼저 취약 버전으로 운영된 기간을 특정하고, 그 구간의 리포지터리 쓰기 이력을 전부 뽑음. 그다음 각 업로드를 CI 빌드 기록과 대조해서 출처 없는 항목을 걸러냄. 마지막으로 그 기간에 발급되거나 사용된 토큰을 전부 회전시킴. 토큰 회전은 귀찮지만, 인증 계열 취약점 대응에서 생략하면 나중에 후회하는 단계임.

마무리

개인적으로는 이런 공급망 상류 취약점을 볼 때마다 "우리 조직은 저장소를 얼마나 믿고 있나"를 다시 재보게 됨. 대부분은 생각보다 훨씬 많이 믿고 있고, 그 믿음에 대한 검증 장치는 생각보다 훨씬 적음. 패치는 당연히 해야 하는 일이고, 그와 별개로 "저장소가 뚫려도 배포는 안 뚫리게" 만드는 이중 방어선을 하나쯤 깔아두면 다음번에 비슷한 CVE가 떠도 훨씬 덜 급해짐.

여러분 조직의 아티팩트 저장소는 지금 어디까지 열려 있나요? 익명 접근 설정 한 줄, CI 토큰 권한 한 칸부터 같이 점검해보아요. 비슷한 사례 겪어보셨다면 댓글로 공유해주시면 저도 배우겠습니다!