settings.xml의 단 한 가지 실수만으로도 전체 Maven 빌드가 의존성 혼란에 빠질 수 있습니다

주요 내용

• 고정 버전의 경우, Maven은 저장소를 순서대로 조회한 후 해당 버전을 보유한 첫 번째 저장소에서 좌표 정보를 가져옵니다.
• 의존성의 자체 POM은 빌드에 리포지토리를 추가할 수 있으며, 기본적으로 이를 막는 것은 없습니다.
• A mirrorOf line은 Maven 측을 차단하지만, 리포지토리 관리자는 여전히 공개 리포지토리가 귀하의 네임스페이스에 유입되지 않도록 관리해야 합니다.

많은 엔터프라이즈 자바 개발 팀에는 settings.xml 몇 년 동안 아무도 손대지 않은 파일입니다. 작동은 합니다. 빌드는 성공적으로 완료되고, CI는 정상(green)을 표시하지만, 아무도 이 파일을 열어보지 않습니다. 그래도 한 번쯤 살펴볼 가치가 있습니다. 이 파일은 모든 아티팩트의 출처를 결정하며, 그 내용이 팀이 생각하는 것보다 훨씬 더 유연하게 허용되는 경우가 많기 때문입니다. 빌드 과정은 리포지토리 선언이 한 번 잘못 지정된 것만으로도, 공개 인터넷 외부의 내부 좌표를 참조하게 될 수 있습니다. 이러한 간극이 바로 Maven 의존성 혼란이며, 이는 npm이나 pip와는 다르게 작동합니다. 고정 버전의 경우 Maven은 버전 번호를 비교하지 않습니다. 대신 빌드가 먼저 요청하는 리포지토리가 어디인지 비교합니다.

Maven의 종속성 혼동 현상이 npm 및 pip와 다르게 작동하는 이유

pip는 다음 방법을 통해 한 번에 여러 인덱스를 지정할 수 있습니다. --index-url 그리고 --extra-index-url, 그런 다음 이 조건에 부합하는 버전 중에서 가장 높은 버전을 선택합니다. 게시 internal-utils 99.0.0이 공개적으로 등록되어 있으며, 이는 동일한 이름의 내부 패키지보다 우선합니다. npm은 다르게 동작합니다. 패키지는 해당 범위에 대해 구성된 레지스트리 중 하나, 또는 범위 매핑이 존재하지 않을 경우 공개 레지스트리에서 버전을 확인합니다. npm 공격이 성공하는 이유는 내부 패키지가 비공개 레지스트리에 범위가 지정된 적이 없어 클라이언트가 공개 레지스트리와만 통신하기 때문이지, npm이 버전을 집계하여 가장 높은 버전을 선택하기 때문이 아닙니다. Maven은 고정 버전의 경우 그런 방식으로 작동하지 않습니다. Maven은 버전을 의존성 그래프 먼저, 그런 다음 정확히 그 것을 찾아다닌다 groupId:artifactId:version, GAV 좌표입니다. 더 높은 버전을 공개적으로 게시한다고 해서 별다른 효과가 없는 이유는, 이를 요청하는 것이 없기 때문입니다. 이는 유효한 저장소 순서, 먼저 설정을 확인한 다음, 프로젝트의 POM 계층 구조를 확인하고, 그다음 의존성 POM을 확인하며, 해당 아티팩트가 포함된 첫 번째 POM을 선택합니다.

고정 버전인 경우가 일반적이며, 바로 이 경우에만 수정 조치가 달라집니다. 순서가 중요하고, 정확한 좌표 일치가 중요하며, 버전 인플레이션은 상관없습니다. 공개 저장소가 내부 저장소보다 먼저 존재하고 해당 좌표가 그곳에 있다면, 공개 사본을 가져오게 됩니다. Maven Central은 이러한 과정을 다소 까다롭게 만듭니다. 네임스페이스 하에 게시하려면 DNS TXT 레코드를 통해 일치하는 도메인에 대한 관리 권한을 증명하거나, 일치하는 계정에 대한 관리 권한을 증명해야 합니다. io.github 스타일 네임스페이스 덕분에, 아무도 com.yourcompany 단순히 등록하지 않았다는 이유만으로 그런 것은 아닙니다. 진정한 위험은 다른 곳에 있습니다. 바로 여러분이 통제하지 못하는 네임스페이스, 백엔드 도메인이 조용히 만료되어 다른 이에게 인수된 네임스페이스, Central보다 공개 규칙이 덜 엄격한 저장소, 그리고 여러분의 트리 내 POM이 선언하는 모든 저장소 등이 바로 그것입니다. JitPack은 요청에 따라 지원되는 Git 프로젝트를 빌드하며, 의존성 POM은 사용자가 직접 선언하지 않아도 이를 리포지토리 세트에 추가할 수 있습니다. 해당 좌표는 Git 호스트와 계정을 따르기 때문에 완전히 개방된 환경은 아니지만, 사용자가 신뢰하기로 선택한 적이 없는 리포지토리입니다. 버전 범위와 SNAPSHOT은 버전 통합이 적용되는 영역입니다. 범위는 Maven 병합을 가능하게 합니다. maven-metadata.xml 여러 저장소를 가로질러 가장 높은 버전을 선택함으로써, 버전 기반 하이재킹 문제가 다시 대두되고 있습니다. SNAPSHOT의 경우 메타데이터가 기본 버전을 타임스탬프가 찍힌 빌드와 매핑하고 있으며, 해당 세트에 포함된 어떤 저장소라도 이 매핑을 변경할 수 있기 때문에 이와 관련된 위험이 따릅니다. 주의하세요: 범위는 유연해 보이지만, 리포지토리 간에 영향을 미치는 고정되지 않은 종속성처럼 작동합니다. 정확한 버전을 고정하고, 리포지토리 관리자가 업그레이드를 통제하도록 하세요.

settings.xml 파일이 실제로 Maven에 전달하는 정보

몇 블록 떨어진 곳에서 settings.xml 해결 과정이나 그 신뢰성에 영향을 미칩니다. <mirrors> 요청을 리디렉션하고, <profiles> 저장소를 추가할 수 있으며, <activeProfiles> 어떤 것이 적용되는지 결정하고, <servers> 인증 기능을 제공합니다. 그중 가장 중요한 것은 <mirrors>, 왜냐하면 a 적절한 무늬가 있는 거울 다른 모든 곳의 리포지토리 선언을 재정의합니다. 이것이 수정 사항 중 Maven 측에서 처리해야 할 부분입니다. 리포지토리 관리자에게는 여전히 공개 리포지토리에서 내부 네임스페이스를 제공하지 않도록 지시해야 하는데, 이는 다음 섹션에서 다룰 내용입니다.

<mirrors>
  <mirror>
    <id>internal-repo</id>
    <name>Internal Repository Manager</name>
    <url>https://nexus.example.com/repository/maven-public/</url>
    <mirrorOf>*</mirrorOf>
  </mirror>
</mirrors>

<mirrorOf>*</mirrorOf> 이는 어떤 POM에 어떻게 명시되어 있든 상관없이 모든 리포지토리 요청이 해당 URL로 전송된다는 뜻입니다. 이것이 바로 여러분이 원하는 것입니다. 하지만 많은 파일에는 다음과 같은 내용이 포함되어 있습니다.

미러링 전용 central 이 실수는 겉보기에는 올바르게 느껴지기 때문에 쉽게 저지르게 됩니다. 이 방법은 모두가 떠올리는 저장소를 포함하면서도, POM에 선언된 모든 저장소는 각자의 URL로 해결되도록 합니다. 어떤 경우인지 확인해 보세요.

mvn help:effective-settings

이 명령어는 전역 설정과 사용자 설정을 통합하여, 프로필 활성화 여부를 포함해 Maven이 실제로 사용하고 있는 설정을 출력합니다. CI 에이전트와 노트북 모두에서 실행해 보세요. 두 환경의 설정이 다를 수 있기 때문입니다.

아무도 설정하지 않은 전이적 리포지토리 주입

바로 이게 함정입니다 Java 개발자 찾아보지 않은 사람들. 의존 관계 그 자체는 POM은 리포지토리를 선언할 수 있습니다, 그리고 Maven은 이를 준수합니다. 라이브러리를 하나 추가하기만 해도 해당 라이브러리가 해결 세트에 리포지토리를 추가할 수 있습니다. 이는 수년 전부터 문서화되어 온 동작이며, 이를 막는 기본 설정도 없습니다. 따라서 빌드 과정에서 여러분이 들어본 적도 없는, 어떤 타동사 종속 관계 4단계 깊이에 있으며, 아무도 검토하지 않은 URL에 위치해 있습니다.

mvn help:effective-pom | grep -A 8 '<repository>'

이는 부모 POM과 프로필을 포함하여, 사용자의 POM 계층 구조가 생성하는 목록을 보여줍니다. 여기서 빠진 부분은 종속성 POM이 기여하는 모든 요소인데, 해당 저장소들은 사용자의 POM에 병합되는 것이 아니라 해결 시점에 세트에 추가되기 때문입니다. 전체적인 상황을 파악하려면 실제 빌드 과정을 지켜보세요.

mvn -X dependency:resolve 2>&1 | grep -E 'Using mirror|Repositories \(' | sort -u

“리포지토리” 줄에는 Maven이 종속성 및 플러그인에 사용한 세트가 명시되어 있으며, “미러 사용” 줄에는 어떤 선언이 리디렉션되었는지 표시됩니다. 이 명령을 실행하면 사용자가 의도치 않게 추가한 리포지토리가 발견될 수 있습니다. 현실 점검: Maven이 의존성에서 선언한 저장소를 존중하는 것은 취약점이 아니며, 이 기능은 사라지지 않을 것입니다. 이는 누군가가 공급망 공격을 생각하기 훨씬 전부터 존재해 온 것이며, <mirrorOf>*</mirrorOf> 이는 해당 선언이 원래 URL로 전달되는 것을 막는 표준적인 설정 방법입니다. 한 가지 더 고려해야 할 점이 있습니다. <pluginRepositories> 는 다음과 별개의 블록입니다. <repositories>, 그리고 거울이 있는 * 이 두 가지를 모두 지원하지만, 저장소별 미러는 일반적으로 그렇지 않습니다. 플러그인은 JVM에 대한 전체 접근 권한을 가지고 실행되므로, 런타임 클래스패스에 있는 어떤 것보다 더 높은 권한을 가집니다.

빌드에서 이미 캐시된 항목 감사하기

이 캐시는 흔히 알려진 것보다 훨씬 정교합니다. Maven은 아티팩트를 ~/.m2/repository, 그리고 Maven Resolver의 향상된 로컬 리포지토리 관리 기능은 각 다운로드가 어떤 원격 리포지토리에서 이루어졌는지 기록합니다. 이후 빌드에서 해당 아티팩트를 요청할 때, 원본 리포지토리가 범위 내에 포함되지 않으면 Resolver는 캐시된 사본을 없는 것으로 간주하고, 현재 범위 내에 있는 리포지토리를 통해 다시 해결합니다. 이러한 추적 기능은 제어 수단이자 기록 증거가 됩니다. Maven은 각 아티팩트 옆에 해당 원본 데이터를 기록합니다.

find ~/.m2/repository -name '_remote.repositories' \
  -exec grep -L 'internal-repo' {} +

이 목록에는 미러 ID가 명시되지 않은 추적 파일들이 나열되어 있습니다. 하나의 파일이 여러 아티팩트를 포함할 수 있고, 로컬 설치 시 원본 정보가 비어 있는 경우가 있으므로, 이를 아티팩트별 출처 정보라기보다는 대략적인 선별 정보로 간주하십시오. 익숙하지 않은 ID는 다른 리포지토리 구성 하에서 해결된 것을 의미하므로, 이를 추적해 볼 가치가 있습니다. 가장 중요한 좌표에 대해서는 공개적으로 존재하는지 확인해 보십시오.

curl -s -o /dev/null -w "%{http_code}\n" \
  https://repo.maven.apache.org/maven2/com/yourcompany/billing-core/

200 응답 코드는 Central에 해당 groupId 및 artifactId 경로에 콘텐츠가 있음을 의미합니다. 해당 항목이 비공개일 것으로 예상했다면, 그곳에 무엇이 있는지, 그리고 검증된 네임스페이스 클레임을 누가 보유하고 있는지 확인하십시오. 전문가 팁: 중요한 내부 좌표에 대해 이러한 점검을 정기적으로 수행하고, 빌드가 접근할 수 있으며 네임스페이스 규칙이 덜 엄격한 다른 공개 저장소도 점검 대상에 포함시키십시오. 신뢰하는 좌표 하에서 예상치 못하게 공개된 항목은 우선적으로 찾아내는 것이 좋습니다.

리포지토리 관리자에서 자신의 좌표 차단하기

수정 settings.xml 모든 요청을 하나의 URL을 통해 전달하지만, 그 URL이 그 다음에 어떤 작업을 수행하는지는 결정하지 않습니다. 내부 호스팅 리포지토리와 Central 프록시를 모두 보유한 그룹을 관리하는 관리자는 여전히 선택을 해야 합니다. 여기서 중요한 구성 항목은 두 가지입니다. 첫 번째는 순서입니다. Nexus Repository에서는 그룹 구성원을 순서대로 검색하여 가장 먼저 일치하는 항목이 우선되므로, 내부 호스팅 리포지토리가 Central 프록시보다 먼저 위치해야 합니다. Artifactory도 가상 리포지토리를 순서대로 해결합니다. ‘내부 우선(Internal-first)’을 적용하면, 공개적으로 동일한 좌표가 존재하더라도 좌표가 내부에서 우선적으로 해결됩니다. 두 번째는 Central 프록시에서 자체 좌표 패턴을 완전히 차단하는 것입니다. Nexus Repository는 다음을 통해 이를 수행합니다. 라우팅 규칙, 원격 저장소 또는, 더 나은 방법으로는 이를 통합하는 가상 저장소에 제외 패턴이 설정된 Artifactory. 어느 쪽이든, com/yourcompany/** 일반 인터넷으로 절대 전달되지 않습니다. 이 두 번째 제어 장치는 오류 발생 시에도 정상적으로 작동합니다. 순서는 구성이 올바르게 유지되는지에 달려 있습니다. 네임스페이스에 명시적인 차단 설정이 있으면 ‘closed’ 상태로 실패합니다.

배제 규칙과 아웃바운드 제한은 정책을 실제 적용으로 전환합니다. 구성 변경이 발생하거나, 다른 팀에서 기본 이미지를 상속받기도 하며, 금요일 릴리스를 진행하기 위해 누군가가 항상 저장소를 추가하곤 합니다. 아티팩트 트래픽의 경우, 빌드 에이전트에서 나가는 트래픽을 기본적으로 차단하고 승인된 리포지토리 관리자만 허용 목록에 포함시켜, Maven이 임의의 공개 리포지토리에 접근하는 것을 막습니다. 단일 Central 호스트명을 차단하는 것만으로는 충분하지 않습니다. Maven은 여러 이름으로 Central에 접근할 수 있으며, 종속성 POM이 완전히 다른 호스트를 도입할 수도 있기 때문입니다. 라우팅과 차단은 아티팩트가 어디서 오는지를 결정할 뿐, 아티팩트가 안전한지 여부는 평가하지 않습니다. JAR 파일은 빌드 산출물이며, 프로젝트가 연결된 소스 저장소와 반드시 일치해야 할 필요는 없습니다. 스캐너는 이미 저장된 내용을 검사하기 때문에 스캐닝만으로는 이러한 격차를 메울 수 없습니다. 통제된 환경에서 검증된 소스를 사용하여 패키지를 재빌드하면 불투명한 바이너리를 신뢰하는 대신 독립적인 출처를 확보할 수 있으며, 업스트림 빌드가 재현 가능한 경우 출력을 직접 비교할 수 있습니다.

Gradle에는 이 작업을 위한 더 나은 기본 기능이 있습니다

Gradle은 Maven보다 리포지토리 범위 지정을 더 잘 처리하므로, Maven에서 사용하던 방식을 그대로 가져오기보다는 Gradle의 기본 기능을 활용하는 것이 좋습니다. 콘텐츠 필터링을 통해 리포지토리가 제공할 수 있는 좌표 범위를 제한할 수 있습니다. 해당 구성을 다음 위치에 추가하십시오. dependencyResolutionManagement 에서 settings.gradle.kts, 여기서 동일한 블록은 하위 프로젝트가 자체 블록을 선언하는 것을 막을 수도 있습니다.

// settings.gradle.kts
dependencyResolutionManagement {
  repositoriesMode = RepositoriesMode.FAIL_ON_PROJECT_REPOS
  repositories {
    exclusiveContent {
      forRepository {
        maven { url = uri("https://nexus.example.com/repository/internal/") }
      }
      filter { includeGroupByRegex("com\\.yourcompany(\\..*)?") }
    }
    maven { url = uri("https://nexus.example.com/repository/maven-public/") }
  }
}

exclusiveContent 이는 해당 네임스페이스가 내부 저장소에서만 해결되며, 그 외의 다른 곳은 참조되지 않음을 의미합니다. 즉, 의존성 혼동 정렬 순서가 아니라 구조상 닫혀 있습니다. 해당 정규 표현식의 앵커링에 유의하세요. 왜냐하면 맨 앞의 com\.yourcompany.* 잘 어울립니다 com.yourcompanyevil, 바로 그 사고를 막기 위해 존재하는 바로 그 아슬아슬한 순간이다. FAIL_ON_PROJECT_REPOS 그러면 어떤 하위 프로젝트라도 자체 선언을 할 경우 빌드가 실패하게 되어, 결정 사항을 하나의 파일에만 집중시킵니다. Maven에는 이를 한 줄로 처리할 수 있는 방법이 없지만, 전혀 방법이 없는 것은 아닙니다. Enforcer 플러그인의 bannedRepositories 이 규칙은 빌드 세션의 저장소를 검사하며, 허용 목록(allowlist)으로 실행될 수 있습니다. 알아두면 좋은 팁: 결합 exclusiveContent Gradle을 사용하여 의존성 검증. 필터링은 어떤 저장소에서 좌표를 제공할지 결정하며, 메타데이터 검증은 아티팩트를 예상 체크섬과 대조하여 확인하고, 활성화된 경우 신뢰할 수 있는 서명도 확인합니다. 이 두 가지가 함께 라우팅과 무결성을 보장하는데, 이는 어떤 단일 Maven 구성으로도 달성할 수 없는 기능입니다. SNAPSHOT과 같은 변경되는 종속성은 이 범위를 벗어나므로, 이를 고정해야 하는 또 다른 이유가 됩니다.

Gap의 settings.xml 파일이 닫히지 않습니다

위의 모든 내용은 라우팅 계층에서 발생하는 Maven 의존성 혼동을 해결합니다: 올바른 mirrorOf 값, 그룹 순서 지정, 제외 규칙, 유출 제어. 이 모든 것들은 다음 질문, 즉 해당 아티팩트가 올바른 장소에서 도착한 후에도 안전한지에 대한 답을 주지 못합니다. 바로 그 점이 시큐어체인 을 위해 설계되었습니다. 이 솔루션은 공개된 Maven Central 해결 방식을 검증되고 소스 코드에서 재빌드된 대안으로 대체하며, 아티팩트가 배포된 후 이를 스캔하는 대신 의존성 해결 과정에서 모든 구성 요소를 철저히 검토합니다. 새로운 CVE는 지속적으로 패치되며, 지원 범위는 제품 수명 주기 종료 후에도 계속됩니다. 자세한 내용은 Java용 SecureChain 표지, 또는 데모 신청하기 자신이 만든 빌드를 상대로.

자주 묻는 질문

Maven 의존성 혼동이란 무엇인가요?

이는 빌드 과정에서 내부 좌표 대신 공개 저장소의 내부 좌표를 참조하는 공격입니다. 고정된 버전의 경우, 이 취약점은 버전 부풀림 때문이 아니라 설정, POM 계층 구조, 종속성 POM 순으로 적용되는 실제 저장소 순서에서 비롯됩니다.

Maven은 여러 저장소 중에서 가장 높은 버전을 선택하나요?

고정 버전의 경우에는 해당되지 않습니다. Maven은 의존성 그래프에서 버전을 확인한 다음, 해당 버전을 보유한 첫 번째 저장소에서 정확한 좌표를 찾아냅니다. 범위(range)나 SNAPSHOT 버전은 저장소 간에 비교가 이루어지기 때문에, 정확한 버전을 사용하는 것이 더 안전합니다.

mirrorOf는 무엇으로 설정해야 할까요?

다음으로 설정하세요 *, 이는 POM에 어떤 선언이 되어 있든 상관없이 모든 리포지토리 요청을 리포지토리 관리자를 통해 전달합니다. 이를 central Maven Central에서만 인터셉트하며, 프로젝트 또는 종속성 POM에 선언된 저장소는 직접 해결되도록 합니다.

의존성이 내 빌드에 리포지토리를 추가할 수 있나요?

네. Maven은 의존성의 POM에 선언된 리포지토리를 반영하므로, 전이적 의존성을 통해 리졸루션 세트에 리포지토리가 추가될 수 있습니다. 다음으로 설정된 미러는 * Maven이 원래 URL을 통해 해당 리소스에 접속하는 것을 차단합니다.

Maven 빌드에서 어떤 리포지토리를 사용하는지 어떻게 확인할 수 있나요?

실행 mvn help:effective-settings 설정 병합 및 프로필 활성화를 위해, mvn help:effective-pom POM 계층 구조에서 생성되는 목록에 대해서는, 그리고 mvn -X dependency:resolve 실제 빌드에서 사용된 세트를 확인하려면.

settings.xml 파일의 비밀번호를 암호화하는 것이 안전한가요?

파일 시스템을 읽을 수 있는 사람이라면 누구에게도 해당되지 않습니다. Maven 3의 유산 비밀번호 암호화 마스터 비밀번호를 디스크에 저장하며, 설정 보안 파일을 보유한 사람이라면 누구나 이를 복구할 수 있습니다. Maven 4 환경 변수나 GPG 에이전트에서 마스터 키를 가져올 수 있는 플러그인형 디스패처를 추가하지만, 해당 키를 보유한 사람은 여전히 모든 값을 복호화합니다. settings.xml. 어느 쪽이든, CI에서 실제 비밀 저장소의 인증 정보를 주입하십시오.