Go 모듈 프록시를 자체 호스팅하는 방식은 아무것도 검증하지 않으며, 공격자들은 이 사실을 잘 알고 있다

주요 내용

• Go 모듈 프록시는 파일을 제공하기 위해 구축된 것이지, 해당 파일을 실행해도 안전한지 여부를 판단하기 위한 것이 아닙니다.
• GOPROXY 문자열에 포함된 한 글자에 따라, 작동이 중단된 프록시가 오류 메시지를 크게 알릴지, 아니면 조용히 빌드를 공용 인터넷으로 전송할지가 결정됩니다.
• GOPRIVATE는 일치하는 모든 경로에 대해 공개 체크섬 데이터베이스 조회를 건너뛰기 때문에, 하나의 광범위한 패턴만으로도 의도한 것보다 훨씬 더 광범위하게 해당 보호 기능을 비활성화할 수 있습니다.

2026년 5월, 연구원들은 ‘ BufferZoneCorp라는 GitHub 계정으로 게시된 악성 Go 모듈의 대량 유포를 지적했습니다. 페이로드에는 자격 증명 탈취 기능이 포함되어 있었지만, 흥미로운 점은 몇몇 Go 모듈이 노린 대상이 바로 빌드 시스템 그 자체였다는 것입니다. 이들은 GOPROXY를 변조하고, 체크섬 검증을 약화시키며, go.sum 파일을 수정하고, 워크플로우 경로에 가짜 Go 래퍼를 심어 나중에 CI 단계에서 실제 툴체인 대신 공격자의 바이너리가 실행되도록 했습니다. Go 보안 팀은 식별된 모듈들을 차단했습니다. 이 기법은 모듈 인프라가 보안 경계가 아닌 단순한 구성 요소로 취급되는 곳이라면 어디에서나 여전히 유효합니다.

캐싱은 이러한 인프라에 긴 기억력을 부여합니다. 모듈은 소스 코드가 변경되거나 사라진 후에도 오랫동안 접근 가능한 상태를 유지할 수 있으며, 과거 Go 백도어 사건은 그 영향이 얼마나 광범위한지 보여주었습니다. 해당 GitHub 태그가 조용히 재작성된 후에도 공개 Go 모듈 프록시는 3년 넘게 악성 버전을 계속 제공했습니다(자세한 내용은 아래에서 설명합니다). 이러한 지속성 문제는 팀들이 내부 모듈 프록시를 구축하고 GOPROXY를 그곳으로 지정하는 주요 이유 중 하나입니다.

그 직감은 틀리지 않습니다. 빌드 재현성이 향상되고, 캐시된 종속성이 더 이상 공용 프록시에 접속할 수 있는지 여부에 좌우되지 않으며, 마침내 조직이 어떤 종속성을 사용하고 있는지 한눈에 확인할 수 있는 곳이 생겼습니다.

하지만 보안 측면에서의 결론은 그렇지 않습니다. 모듈 프록시는 바이트 단위의 데이터를 전달할 뿐입니다. 프로토콜 자체에는 콘텐츠 검증 단계나 정책 메커니즘이 없으며, 반환하는 파일의 내용에 대해 어떠한 판단도 내리지 않습니다. 자체 프록시를 운영한다는 것은 캐시를 제어한다는 뜻입니다. 이는 유용하지만, 캐시에 어떤 내용이 들어가는지를 제어하는 것과는 별개의 문제입니다.

Go 모듈 프록시가 실제로 하는 역할

모듈 프록시 프로토콜은 의도적으로 간결하게 설계되었습니다. 프록시는 모듈 경로당 소수의 엔드포인트만 노출하는 HTTP 서버입니다:

그게 전부입니다. 그 목록에 있는 어떤 항목에도 서명, 스캔 결과, 정책 판정 결과, 또는 코드의 출처에 대한 검증 가능한 주장이 포함되어 있지 않습니다.

참고: 이 프로토콜은 예측 가능한 경로 구조를 따르는 일반 HTTP GET 요청이므로, NGINX가 제공하는 파일 디렉터리는 기술적으로 유효한 Go 모듈 프록시로 간주됩니다. 이것이 바로 프록시가 Go 커뮤니티에 빠르게 확산된 이유 중 하나이며, 사용자가 직접 해당 기능을 구현하지 않는 한 프록시 중 대부분이 아무런 검증도 수행하지 않는 이유이기도 합니다.

Go에서의 검증은 프록시가 아닌 클라이언트 측에서 이루어집니다. `go` 명령어는 다운로드된 모듈의 내용을 go.sum에 저장된 해시와 대조하여 확인합니다. 해당 해시가 아직 기록되어 있지 않은 경우, 일반적으로 체크섬 데이터베이스(독립적인 추가 전용 로그)에서 해시를 가져온 후 go.sum에 기록합니다. 일단 기록되면, 이후 빌드에서는 저장된 해시와 비교하기만 하면 됩니다.

따라서 대부분의 팀이 프록시의 장점이라고 여기는 보안 기능은 사실 go.sum과 GOSUMDB의 기능입니다. 프록시를 실행하든 proxy.golang.org 에 직접 접속하든 상관없이 정확히 동일하게 작동합니다.

쉼표와 파이프가 대체 동작을 결정합니다

GOPROXY는 소스 목록을 받아 처리하며, 소스들을 구분하는 문자에 따라 해당 소스 중 하나가 오류가 발생했을 때 취해지는 조치가 달라집니다.

# 404 또는 410 오류 시에만 다음 항목으로 넘어갑니다.

GOPROXY=https://goproxy.internal.example.com,direct

# 어떤 오류가 발생하더라도 다음 항목으로 넘어감

GOPROXY=https://goproxy.internal.example.com|direct

이 다이어그램은 위의 예시들에서와 같이 ‘direct’가 목록에서 바로 다음 소스라고 가정하고 있습니다. 파이프 기호만 단독으로 사용될 경우, 이는 단순히 다음에 오는 것으로 넘어간다는 의미일 뿐입니다.

쉼표(,)는 go 명령어에 현재 소스에서 모듈이 존재하지 않는다고 명시적으로 보고하거나(404 또는 410 오류), 그 외의 오류가 발생했을 때만 다음 소스를 시도하도록 지시합니다. 파이프(|)는 타임아웃, TLS 오류, 500 오류 등 어떤 오류가 발생하더라도 다음 소스를 시도하도록 지시합니다.

이것이 사고 발생 중에 어떤 의미를 갖는지 상상해 보세요. 내부 프록시의 배포에 문제가 생겨 502 오류가 발생하기 시작합니다. ‘pipe’ 뒤에 ‘direct’가 따라오는 구성이 설정되어 있다면, 조직 전체의 모든 빌드가 조용히 공개 버전 관리 시스템에서 모듈을 조회하기 시작합니다.

전문가 팁: 런북에 설정되어 있다고 명시된 내용이 아니라, CI에 실제로 어떤 설정이 적용되어 있는지 확인하세요. GOFLAGS와 GOPROXY는 기본 이미지에서 상속되는 경향이 있으며, 2년 전 누군가가 불안정한 배포를 해결하기 위해 추가한 파이프라인은 빌드 결과가 계속 성공(green)으로 나오기 때문에 그 이후의 모든 검토 과정을 거치면서도 그대로 남아 있게 되는 대표적인 사례입니다.

대부분의 GOPROXY 문자열 끝에 붙는 ‘direct’도 따로 살펴볼 필요가 있습니다. 이 옵션은 프록시에서 결과를 찾지 못했을 때 툴체인이 버전 관리 시스템으로 되돌아가도록 지시하므로, 프록시가 한 번도 본 적 없는 모듈 경로도 평소와 마찬가지로 업스트림 저장소에서 바로 해결됩니다. 프록시를 구축한 목적이 유일한 신뢰할 수 있는 정보원 역할을 하는 것이라면, ‘direct’ 옵션은 이를 은연중에 무효화해 버립니다.

GOPROXY=off는 가장 엄격한 옵션입니다. 이 옵션을 사용하면 go 명령어가 모듈을 전혀 다운로드하지 않으므로, 빌드에 필요한 모든 항목은 이미 모듈 캐시에 존재해야 합니다. 마지막 ‘direct’를 생략하면 그렇게까지 엄격하지는 않으면서도 소스 경계를 엄격하게 유지할 수 있습니다.

셀프 호스팅이 그 자체로는 아무것도 검증하지 못하는 이유

Athens는 안정적인 소프트웨어입니다. 모듈 프록시가 수행하도록 지정된 기능을 정확히 수행합니다.

이 제품에는 모듈 내부에 무엇이 들어 있는지에 대한 어떠한 견해도 포함되어 있지 않습니다. 내장된 악성코드 검사 기능도 없고도 없고, 아카이브가 소스 저장소와 일치하는지 확인하는 기능도 없으며, “이 모듈을 차단해 주세요. v1.4.2부터 새로운 동작을 시작했거든요.”라고 지정할 수 있는 기본 제공 방식도 없습니다. 표준 필터링은 코드가 수행하는 동작이 아니라 모듈 경로를 기준으로 작동합니다. Athens는 유효성 검사 후크를 제공하므로 운영자는 이를 통해 자체 스캔이나 정책 로직을 확장할 수 있습니다. 하지만 이러한 검증은 사용자가 직접 설계하고, 를 제공하므로 운영자는 이를 자체 스캔 또는 정책 로직으로 확장할 수 있지만, 해당 검증은 사용자가 직접 설계하고 실행하며 지속적으로 유지 관리해야 합니다.

이 취약점이 중요한 이유는 악의적인 Go 코드가 실행되는 위치 때문입니다. Go에는 npm 처럼 설치 시점에 코드를 검사하는 스크립트 후크가 없는데, 이는 Go의 확실한 장점입니다. 하지만 Go 모듈 내의 악성 코드는 여전히 나중에, 해당 패키지를 임포트하는 애플리케이션이나 도구가 실행될 때 실행되며, 일반적으로 프로그램 시작 시 호출되는 init() 함수를 통해 실행됩니다.

해당 모듈을 캐싱하고 제공하는 프록시는 사양에 비추어 볼 때 아무런 잘못도 저지르지 않았습니다. 이 프록시는 원래 의도된 대로 정확히 제 역할을 수행했을 뿐입니다.

진정한 문제는 프록시가 제공하는 아카이브가 해당 모듈 경로가 가리킨다고 주장하는 소스 저장소와 일치하는지 여부입니다. 프로토콜상 모듈 ZIP 파일이 특정 커밋과 일치해야 한다는 요구 사항은 없으므로, 이는 ‘인증’이 아닌 ‘아티팩트’에 해당합니다. 소스 코드로부터 모듈을 재컴파일한 후 그 결과를 제공된 경로의 내용과 비교하는 것은 별개의 검증 절차이며, 이는 아티팩트가 신뢰할 수 있는 저장소에 등록되거나 빌드에 제공되기 전에 반드시 수행되어야 합니다.

5가지 GOPROXY 아키텍처 비교

다섯 가지 전술은 팀들이 연습에서 수행하는 거의 모든 상황을 아우릅니다. 이 전술들을 구분 짓는 요소는 각 전술에서 어떤 선수가 스크린을 걸고, 누가 그 전술을 주도하느냐에 있습니다.

직접 폴백 기능이 있는 공개 프록시는 대부분의 팀이 처음에 사용하는 기본 설정이며, 평판보다 훨씬 낫습니다. proxy.golang.org 는 불변 캐시를 유지하므로, 한 번 제공된 버전은 업스트림 저장소가 삭제되더라도 변경되지 않은 상태로 계속 이용 가능합니다. 이는 진정한 보안 속성이며, 자체 호스팅으로는 이를 자동으로 재현할 수 없습니다.

아테네(Athens)와 같은 자체 호스팅 프록시는 많은 팀이 결국 선택하게 되는 방식이며, 솔직히 말해 이는 검증보다는 가용성과 가시성을 확보해 주는 수단이라고 할 수 있습니다.

리포지토리 관리자 프록시는 중앙 집중식 액세스 제어 기능을 제공하며, 라이선스를 취득한 제품 및 정책 애드온에 따라 구성 요소를 정책에 대조하여 감사하고, 기준을 충족하지 못하는 구성 요소를 격리할 수 있습니다. 그러나 일반적인 프록시 기능만으로는 아티팩트가 경로에 명시된 소스에서 재빌드되었으며, 해당 소스와 일치한다는 사실을 보장할 수 없습니다.

검증 및 재구축된 레지스트리는 처음 네 가지의 변형이 아니라 별개의 범주에 속합니다. 이 방식은 각 모듈을 소스 코드부터 다시 구축하고, 제공하기 전에 악성코드 여부를 검사하기 때문에, ‘검증’ 열에 ‘예’라고 표시된 유일한 항목입니다. 이것이 바로 SecureChain for Go 가 구축된 모델이며, Go 지원은 2026년 4분기로 예정되어 있습니다.

프록시 캐시 악용의 원인

Go 모듈 인프라를 대상으로 한 캐시 관련 사고는 대개 비슷한 양상을 띠는데, 2025년 초에 발생한 한 사례가 이를 잘 보여줍니다. 그해 2월, 연구원들은 github.com/boltdb-go/bolt 라는 모듈이, 사고 보고 당시 8,000개 이상의 종속 패키지를 보유한 널리 사용되는 임베디드 키/값 저장소인 BoltDB를 사칭하고 있음을 발견했습니다.

이 위협 행위자는 2021년 11월에 이미 악성 버전을 공개한 뒤, GitHub 태그를 수정하여 정상적인 커밋을 가리키도록 했습니다. 이로 인해 저장소를 수동으로 검토하는 사람은 아무도 문제가 있다는 사실을 알아차리지 못했습니다. Go 모듈 프록시는 이미 원래의 악성 버전을 캐시에 저장해 둔 상태였는데, 해당 캐시는 변경 불가능하도록 설계되어 있었기 때문에, 연구진이 결국 이를 타이포스쿼트으로 지목할 때까지 3년 넘게 남아 있었습니다.

이는 체크섬 오류가 아니었습니다. boltdb-go/bolt는 별개의, 사칭된 모듈 경로였기 때문에, 가짜 모듈이 일치해야 할 실제 BoltDB에 대한 신뢰할 수 있는 체크섬이 존재하지 않았습니다. Go의 무결성 검사는 타이포스쿼팅 모듈 자체의 바이트를 문제없이 인증해 주었는데, 그것이 바로 해당 검사가 해결해야 할 문제였기 때문입니다. 백도어는 이름 지정 측면에서 성공했습니다.

이러한 구분은 중요합니다. 왜냐하면 이는 첫 사용 시의 순수한 신뢰와는 다르기 때문입니다. 공개 모듈의 경우, 클라이언트는 일반적으로 특정 버전에 대한 해시가 처음 필요할 때 독립적으로 인증된 로그인 체크섬 데이터베이스를 확인하므로, 프록시는 이미 기록된 버전에 대한 신뢰할 수 있는 값을 일방적으로 변경할 수 없습니다. 자체 호스팅 프록시는 여전히 클라이언트가 어떤 아티팩트를 먼저 보게 될지 결정하지만, GOSUMDB가 설치된 상태에서는 해당 아티팩트가 승인될지 여부를 결정하는 주체는 프록시가 아닌 체크섬 데이터베이스입니다.

하지만 이러한 조치들 중 어느 것도 모듈이 애초에 신뢰할 만한지 여부를 검증하지는 못하며, 바로 이 틈을 타이포스쿼트가 악용하는 것입니다. 또한, 공개된 부분은 GOPRIVATE와 일치하는 항목이나 GOSUMDB가 ‘off’로 설정된 환경에서 실행되는 경우에는 적용되지 않습니다.

GOPRIVATE가 은밀하게 비활성화하는 기능

GOPRIVATE가 존재하는 데는 타당한 이유가 있습니다. 비공개 모듈은 공개 프록시를 통해 요청되어서는 안 되며, 모듈 경로 자체가 빌드 중인 프로젝트에 대한 정보를 유출할 수 있으므로 해당 경로가 공개 체크섬 데이터베이스로 전송되어서도 안 됩니다.

또한 이는 편의 변수이며, 부작용이 발생하면 문제가 생깁니다. GOPRIVATE는 다음의 내용에 따라 GONOPROXY와 GONOSUMDB 모두에 기본값을 제공합니다. Go 모듈 참조에 따라에 따라 GONOPROXY와 GONOSUMDB 모두에 기본값을 제공합니다. 즉, 이 두 변수 중 하나가 별도로 설정되지 않는 한, 일치하는 모든 경로는 프록시와 공개 체크섬 데이터베이스에서 동시에 제외됩니다.

실제로는 바로 이 부분에서 문제가 발생합니다.

GOPRIVATE=github.com/yourcompany/*

충분히 좁히면, 원래 일치시키려 했던 조직과 일치하게 됩니다.

GOPRIVATE=*.example.com,github.com/*

두 번째 패턴은 GitHub에 호스팅된 모든 모듈을 공개 체크섬 데이터베이스에서 제외하는데, 이는 대부분의 Go 빌드가 가져오는 소스의 막대한 비중을 차지합니다. 패턴이 이런 식으로 범위가 넓어지는 것은 흔한 일입니다. 즉, 모듈 해결에 실패하면 이를 수정해야 하는데, 일치 조건을 완화하는 것만으로도 빌드가 즉시 성공으로 전환되기 때문입니다.

환경에 실제로 어떤 설정이 되어 있는지 확인해 보십시오:

go env GOPROXY GOSUMDB GOPRIVATE GONOPROXY GONOSUMDB GOFLAGS

이 코드를 그냥 노트북에서 실행하지 말고 CI 러너에서 실행하세요. CI는 기본 이미지 및 러너 구성에서 변수를 가져오기 때문에, 노트북과 CI 러너 간에 결과가 다를 수 있습니다.

의도적으로 설정하십시오. 라우팅과 체크섬 정책을 다르게 설정해야 할 때는 GONOPROXY와 GONOSUMDB를 직접 구성하십시오. 이러한 상황은 팀들이 예상하는 것보다 훨씬 자주 발생합니다. 신뢰할 수 있는 내부 프록시가 공용 및 사설 모듈 모두를 처리하는 경우, GONOPROXY=none을 설정하면 모든 트래픽이 해당 프록시를 통해 흐르게 되며, GONOSUMDB는 진정한 사설 경로만 처리합니다. 피해야 할 것은 그 반대의 경우로, 사설 경로가 공용 데이터베이스 조회 대상에 포함되면 빌드가 중단되거나 공용 서비스로 경로가 유출될 수 있습니다.

아키텍처 선택

결정은 결국 여러분이 실제로 해결하고자 하는 문제가 무엇인지에 달려 있으며, 그 점에 대해 솔직해지면 프로젝트 전체 기간을 상당히 단축할 수 있습니다.

만약 핵심 요인이 가용성과 빌드 재현성이라면, 자체 호스팅 프록시나 리포지토리 관리 도구를 운영하고, 파이프 대신 쉼표를 사용하며, 이를 더 이상 ‘보안 제어 수단’이라고 부르지 마십시오. 이는 본래 의도된 역할을 정확히 수행하는 훌륭한 인프라일 뿐입니다. 만약 핵심 요인이 조직이 무엇에 의존하고 있는지에 대한 가시성이라면, 거의 모든 프록시로도 이를 달성할 수 있으며, 리포지토리 관리 도구를 활용하면 운영 부담을 줄이면서도 더 나은 보고 기능을 얻을 수 있습니다.

허용되는 모듈을 결정하는 정책 적용이 핵심이라면, 경로 규칙을 지원하는 리포지토리 관리자는 최소한의 기반 역할을 하며, 실제 정책 적용은 해당 관리자의 정책 또는 방화벽 애드온에서 이루어집니다. Athens는 유효성 검사 후크를 통해 이러한 방향으로 활용될 수 있지만, 로직과 미세 조정, 그리고 알림 시스템은 사용자가 직접 관리해야 합니다.

드라이버가 모듈 콘텐츠가 신뢰할 만한지 확인하고 있는 경우, 프록시 프로토콜 자체만으로는 이에 대한 답을 줄 수 없습니다. 왜냐하면 프록시 프로토콜은 애초에 검증 단계를 포함하도록 설계되지 않았기 때문입니다. 이러한 제어는 프록시 외부에서 이루어져야 하거나, 아티팩트를 제공하기 전에 소스 코드와 대조하여 유효성을 검증하는 시스템에서 수행되어야 합니다.

그리고 만약 Go가 npm, PyPI, Maven, crates.io와 함께 스택에 포함되어 있다면, 이 모든 플랫폼에 걸쳐 아키텍처를 한 번에 결정하십시오. 서로 다른 5개 팀이 각각 운영하는 5개의 생태계별 프록시는 바로 이러한 방식으로 커버리지 공백을 초래합니다. PolinRider는 그 이유를 잘 보여주는 사례입니다. 이 이름으로 추적된 북한 관련 캠페인은 npm, Packagist, Go 모듈, Chrome 확장 프로그램을 통해 악성 패키지를 배포해 왔으며유포해 왔으며, 2026년 7월 연구진이 이를 보고했을 때도 여전히 활동 중이었습니다. 이 캠페인이 속한 더 광범위한 ‘Contagious Interview’ 클러스터는 npm, PyPI, Go, Rust 전반에 걸쳐 1,700개 이상의 악성 패키지 npm, PyPI, Go, Rust 전반에 걸쳐 1,700개 이상의 악성 패키지와 연관되어 있습니다. 스택 수준의 문제에는 5개의 서로 연결되지 않은 캐시가 아니라, 스택 수준의 해결책이 필요합니다.

프록시는 가용성, 지연 시간, 재현성 문제를 해결하기에 적합한 장소입니다. 반면 신뢰성 문제를 해결하기에는 부적합합니다. 이 두 가지 목표를 분리하여 처리하면 아키텍처를 단순하게 유지하고 정상 작동하는 프록시를 출시할 수 있습니다. 이 두 가지를 혼동하면 단순한 캐싱 프로젝트가 훨씬 더 방대한 정책 및 보안 엔지니어링 작업으로 변모하게 되며, 근본적으로 캐싱 구성 요소인 것에 복잡한 정책 계층이 억지로 덧씌워지는 결과를 초래할 실질적인 위험이 있습니다.

TuxCare SecureChain의 적용 분야

또한 프록시가 전혀 다루지 않는 문제가 하나 더 있습니다. 바로 더 이상 아무도 유지보수하지 않는 모듈들입니다. 캐시는 활동이 중단된 모듈을 활발히 유지보수되는 모듈과 똑같이 충실하게 처리하지만, 알려진 CVE가 있고 업스트림에서 수정되지 않은 패치되지 않은 모듈의 문제는 캐시 아키텍처로는 해결할 수 없습니다. 유지보수자가 손을 뗀 코드에 수정 사항을 역포트하는 것은 회귀 테스트와 동작 호환성을 중심으로 이루어지는 별개의 전문 분야이며, 이 때문에 대개 플랫폼 팀의 업무 범위 밖으로 제외되는 것입니다.

만약 여러분의 아키텍처에 검증이라는 요소가 빠져 있다면, 바로 그것이 공백입니다 SecureChain 는 일반적으로 동일한 스택에 속하는 생태계 전반에 걸쳐 그 간극을 메우기 위해 구축되었습니다. npm 는 오늘부터 서비스 중이며, Maven 및 PyPI 는 2026년 8월에 출시될 예정이며, Go와 Rust/crates.io, 그리고 Packagist/PHP 는 2026년 4분기에 차례로 지원될 예정입니다. 각 플랫폼에서 SecureChain은 소스 코드로부터 패키지를 재빌드하고, 빌드 단계에 도달하기 전인 가져오기 시점에 패키지를 검사하며, 패키지의 업스트림 개발이 중단된 후에도 알려진 취약점에 대한 패치를 지속적으로 적용합니다. 이것이 귀하의 GOPROXY 설정이나 나머지 스택과 어떻게 연동되는지 궁금하신가요? 저희에게 질문해 주세요 , 저희 팀이 자세히 안내해 드리겠습니다.

자주 묻는 질문

Go 모듈 프록시란 무엇인가요?

Go 모듈 프록시 프로토콜을 구현한 HTTP 서버입니다. 이 서버는 모듈 경로에 대한 버전 목록, 메타데이터, go.mod 파일 및 소스 아카이브를 제공합니다. 캐싱 및 라우팅 기능을 제공하며, 프로토콜 자체는 반환하는 콘텐츠에 대한 검증 기능을 포함하지 않습니다.

나만의 Go 모듈 프록시를 운영하면 빌드 보안이 강화되나요?

이는 가용성, 재현성, 가시성을 향상시키며, 이 모든 요소는 유용합니다. 프록시 프로토콜 자체에는 별도의 검증 단계가 없습니다. 콘텐츠 인증은 클라이언트 측에서 이루어집니다. 즉, go 명령어는 다운로드된 파일을 go.sum과 대조하여 확인하며, 해시가 아직 기록되지 않은 공개 모듈의 경우 체크섬 데이터베이스와 대조합니다. GOSUMDB가 비활성화되어 있거나 GOPRIVATE 또는 GONOSUMDB를 통해 해당 경로가 공개 데이터베이스에서 제외되지 않는 한, 프록시를 실행하든 안 하든 이 과정은 동일하게 작동합니다.

GOPROXY에서 쉼표와 파이프의 차이점은 무엇인가요?

쉼표(,)를 사용하면 404 또는 410 오류 발생 시에만 go 명령어가 다음 소스로 전달되며, 그 외의 모든 프록시 오류는 해결 과정을 중단시킵니다. 반면 파이프(|)를 사용하면 어떤 오류가 발생하더라도 명령어가 다음 단계로 전달되는데, 이는 프록시 장애 시에도 빌드가 단순히 실패하는 대신 아무런 경고 없이 공개 인터넷으로 전송될 수 있음을 의미합니다.

GOPRIVATE는 체크섬 검증을 비활성화하나요?

기본적으로 GOPRIVATE가 GONOSUMDB에 데이터를 제공하기 때문에, 일치하는 경로에 대해서는 공개 체크섬 데이터베이스 조회를 건너뜁니다. 기존 go.sum 항목은 이후의 콘텐츠 변경 사항을 여전히 감지할 수 있습니다.

비공개 Go 모듈 프록시를 운영하기에는 아테네만으로도 충분할까요?

가용성, 캐싱, 내부 모듈 배포 측면에서는 그렇습니다. 이 기능의 표준 필터링은 콘텐츠가 아닌 모듈 경로를 기준으로 작동하므로, 기본적으로 모듈이 악성인지, 또는 제공되는 아카이브가 소스 저장소와 일치하는지 여부를 알려주지 않습니다. 검증 후크를 확장하여 이러한 논리를 적용할 수는 있지만, 해당 부분은 사용자가 직접 설계하고 운영해야 합니다.

Go 빌드가 실제로 무엇을 신뢰하는지 어떻게 확인할 수 있나요?

CI 러너에서 `run go env GOPROXY GOSUMDB GOPRIVATE GONOPROXY GONOSUMDB GOFLAGS` 명령을 실행하세요. 베이스 이미지 및 러너 설정에서 상속된 구성은 로컬 개발 환경이나 런북에 명시된 설정과 종종 다릅니다.

요약

기사 이름

Go 모듈 프록시 옵션과 GOPROXY가 실제로 확인하는 사항

설명

Go 모듈 프록시는 캐싱과 라우팅 기능을 수행하며, 해당 프로토콜은 모듈 콘텐츠에 대해 어떠한 검증도 수행하지 않습니다. GOPROXY, GOPRIVATE 및 체크섬 데이터베이스의 결정 사항을 확인하십시오.

작성자

아르템 카라세프

게시자 이름

TuxCare

게시자 로고