GOPROXY 한 줄만으로도 go.mod 파일을 건드리지 않고 Go 빌드 결과를 SecureChain으로 전송할 수 있습니다.

주요 내용

• Go 모듈 해시는 파일 이름과 내용을 기반으로 하며, zip 인코딩을 반영하지 않으므로, 별도로 재구성된 아카이브라도 정확히 일치할 수 있습니다.
• 그렇기 때문에 GOPROXY를 스크리닝된 레지스트리로 설정하더라도, 기존에 설정해 둔 go.sum 항목은 무효화되지 않습니다.
• 정확한 복원 작업은 아카이브가 원본과 일치한다는 사실을 입증할 뿐, 원본이 안전하다는 것을 입증하는 것은 아닙니다.
• 변경 사항 자체는 하나의 환경 변수에 불과하며, 진정한 위험은 구성 변경의 불일치에 있습니다.

2026년 7월, 연구진은 npm, Packagist, Go 모듈 전반에 걸쳐 발생한 유지보수자 계정 해킹 사태를 ‘ PolinRider라는 북한과 연계된 캠페인과 연관지었습니다. 이 캠페인은 완전히 새로운 악성 패키지도 배포했지만, 특히 주목할 점은 기존 패키지에 일어난 일입니다. 공격자들은 수년간 문제 없이 운영되어 온 계정에 침투해, 그곳에서 새 버전을 배포했습니다.

해킹당한 유지보수 담당자의 계정에서 푸시된 새로운 모듈 버전은 처음 사용할 때 Go의 무결성 검사를 통과할 수 있습니다. go.sum과 체크섬 데이터베이스 모두 사용자가 게시된 것과 정확히 동일한 내용을 수신했음을 확인해 줍니다. 그러나 게시된 내용이 안전한지에 대해서는 어느 쪽도 판단하지 않습니다.

빌드에 스크리닝 단계를 추가하면 어딘가에서 마찰이 발생할 수 있습니다. 조정해야 할 새로운 패키지 식별자, 추적해야 할 버전, 아무도 예상하지 못했던 락파일 변경 등이 그 예입니다. Go는 비교적 큰 문제 없이 이 과정을 거치는데, 그 이유를 이해하는 것이 중요합니다. 이는 Go에서 검증 과정을 통해 무엇을 증명할 수 있고 무엇을 증명할 수 없는지를 설명해 주기 때문입니다.

Go 모듈 아카이브를 정확히 검증할 수 있는 이유

Go 모듈 zip 파일에는 소스 코드가 포함되어 있습니다. 가져올 때 컴파일되는 과정은 없으며, 아카이브 구조는 배포자가 그날그날 사용하는 패키징 스크립트에 따라 달라지는 것이 아니라, 문서화된 알고리즘을 따릅니다.

이로 인해 대부분의 사람들이 간과하는 결과가 발생합니다. Go는 아카이브 내의 파일 이름과 파일 내용을 바탕으로 모듈 해시를 계산합니다. zip 인코딩, 압축 방식, 파일별 수정 시간 및 기타 메타데이터는 모두 무시됩니다. 따라서 버전 관리 이력에 접근할 수 있는 사람이라면 누구나 모듈을 재구축하여, 두 zip 파일이 바이트 단위로 완전히 다르더라도 동일한 h1: 체크섬을 얻을 수 있습니다.

다른 생태계에서는 저장소와 공개된 아티팩트 사이에 더 많은 변수가 존재합니다. Maven은 컴파일된 JAR 파일을 배포합니다. Python 휠은 빌드 결과물입니다. npm 타르볼은 단순한 소스 코드일 수도 있고, prepack 스크립트가 남긴 결과물일 수도 있습니다. 이러한 사례 중 몇 가지에서는 재현 가능한 빌드 작업이 실질적인 진전을 이루었기 때문에, ‘불가능’과 ‘정확’ 사이를 명확히 구분할 수는 없습니다. 다만 Go의 체크섬은 처음부터 패키징 과정에서 발생하는 잡음을 무시하도록 설계되었기 때문에, 독립적인 재구성을 확인하는 데 드는 비용이 유난히 적게 듭니다.

공급업체마다 다른 점은, 실제로 레지스트리 규모에서 모든 모듈에 대해 매번 그러한 비교를 수행하느냐 여부입니다. 스크리닝 레지스트리는 모듈 경로의 VCS 이력을 가져와 사양에 따라 아카이브를 생성한 다음, 공개 프록시가 제공한 내용과 대조하여 확인할 수 있습니다. 불일치가 발생하면 해당 아카이브가 주장하는 출처의 소스와 일치하지 않는다는 것을 의미합니다.

이러한 구분은 언뜻 보이는 것보다 더 큰 의미를 지닙니다. 정확한 재구성은 아카이브가 주장하는 출처와 일치한다는 사실만을 알려줄 뿐, 출처 자체가 안전한지에 대해서는 아무것도 말해주지 않습니다. PolinRider 사건이 바로 그 대표적인 사례입니다. 공격자들은 합법적인 저장소를 직접 수정했으며, 경우에 따라 기존 커밋을 강제로 덮어쓰기도 했습니다. 해당 소스를 충실히 재구축하면 악성 콘텐츠도 그대로 재현됩니다. 재구축 과정은 저장소와 아카이브 사이의 변조를 포착합니다. 저장소 내부의 악성 코드를 포착하는 것은 별개의 작업입니다.

참고: 컴파일, 패키징 스크립트 또는 생성된 파일이 필요한 아티팩트의 경우, “소스 코드에서 재빌드”한다는 것은 해당 빌드 조건을 재현하는 것을 의미합니다. Go의 체크섬은 패키지된 소스 트리에서 직접 도출되므로, 비교 과정을 감사하기가 유난히 간단합니다. 공급업체에게 불일치 사항을 설명해 달라고 요청하지 말고, 실제로 불일치하는 부분을 보여달라고 요청하십시오.

go.sum이 계속 작동하는 이유

레지스트리가 모듈 아카이브를 재구성하면 해시 값이 바뀌게 되며, 조직 내의 모든 go.sum이 작동하지 않게 되나요?

아닙니다. 해시는 파일 트리를 포괄하고 패키징 세부 정보를 무시하기 때문에, 올바르게 재구성된 아카이브의 해시 값은 공개 프록시가 산출했을 값과 동일합니다. 기존 go.sum 항목들은 이 값을 기준으로 유효성 검증을 거치며, sum.golang.org 의 체크섬 데이터베이스와도 계속 일치합니다.

그렇기 때문에 이 전환 과정에서 go.mod나 go.sum 파일을 수정할 필요가 없습니다. 이는 우연히 짧은 마이그레이션 경로인 것이 아닙니다. 마이그레이션할 대상이 전혀 없기 때문입니다. 해시가 일치하는 것은 예상된 결과이며, 차이가 발생하더라도 이는 불편함이라기보다는 신호로 받아들여져야 합니다.

이 대칭성을 깨는 경우가 하나 있는데, 이는 각주보다는 단호한 답변이 필요한 사안입니다. Go는 모듈 경로와 버전을 함께 불변으로 취급합니다. 따라서 레지스트리가 업스트림에 이미 존재하는 버전에 대한 패치된 콘텐츠를 제공한다면, 해당 콘텐츠는 업스트림 체크섬을 재사용할 수 없습니다. 기존의 go.sum 항목은 변경된 바이트를 즉시 거부할 것이며, 공개 체크섬 데이터베이스는 계속해서 업스트림 해시를 유지할 것입니다. 따라서 패치된 모듈에는 별도의 버전, 별도의 모듈 경로, 또는 다른 통제된 신뢰 구성 등, 문서화된 자체 배포 메커니즘이 필요합니다. EOL(지원 종료) 이후 패치 적용이 전환 이유 중 하나라면, 배포를 계획하기 전에 TuxCare와 해당 메커니즘을 확인하십시오. 이것이 바로 “아무것도 변하지 않는다”는 말이 더 이상 사실이 아닌 유일한 경우입니다.

‘더 원 라인’

GOPROXY는 모듈 프록시 프로토콜을 구현하는 모든 URL을 허용하므로, 필터링된 레지스트리를 지정하는 것은 환경 변수를 변경하는 것만으로 가능합니다.

go env -w GOPROXY=<your SecureChain Go proxy URL>,direct

파이프 대신 ‘direct’ 앞에 쉼표를 사용하고, 각각이 실제로 어떤 이점을 제공하는지 파악하세요. 쉼표를 사용하면 Go는 404 또는 410 오류가 발생한 후에만 다음 항목으로 넘어갑니다. 파이프를 사용하면 타임아웃을 포함한 모든 오류 발생 시 바로 다음 항목으로 넘어가므로, 레지스트리 서비스 중단 시에도 레지스트리를 설치한 본래 목적을 달성하기 위해 빌드가 자동으로 우회됩니다. 어느 쪽이든, `direct`는 버전 관리 소스에서 직접 가져오는 것을 의미하며, 쉼표를 사용하더라도 404 오류가 발생하면 해당 소스로 연결됩니다. 레지스트리가 단순한 제안이 아닌 게이트 역할을 하도록 의도된 경우, 차단된 모듈은 ‘찾을 수 없음’이 아닌 다른 오류 메시지로 반환되어야 합니다. Go 언어 자체의 참조 문서는 바로 이러한 목적을 위해 403 오류를 언급하고 있습니다.

GOPROXY가 다음을 가리키든 상관없이 이 기능은 작동합니다. SecureChain 을 직접 가리키든, Artifactory나 Nexus와 같이 SecureChain을 가리키는 리포지토리 관리자를 가리키든 상관없이 작동합니다. 어느 쪽이든 동일한 모듈과 동일한 워크플로우가 적용됩니다.

CI의 경우, 이를 이미지에 직접 포함시키지 말고 환경 변수에 설정하십시오.

export GOPROXY=<your SecureChain Go proxy URL>,direct

export GOSUMDB=sum.golang.org

GOSUMDB를 명시적으로 켜 둔 것은 의도적인 조치입니다. 체크섬 검증과 레지스트리 검사는 서로 다른 문제를 다루며, 프록시를 교체한다고 해서 둘 중 어느 하나를 끄는 이유가 될 수는 없습니다.

전문가 팁: 개발자 머신에서는 `go env -w` 명령어로 GOPROXY를 설정하고, 빌드 에이전트에서는 CI 환경 변수를 통해 설정하세요. 그런 다음 실제 러너에서 `go env GOPROXY`를 실행하여 실제로 어떤 값이 설정되어 있는지 확인하세요. 기본 이미지에는 때때로 자체 값이 내장되어 제공되는데, 이것이 대개 롤아웃을 방해하는 원인입니다.

변하지 않는 것과 변하는 것

빌드 명령어에는 아무런 변화가 없으며, 저장소에도 아무런 변화가 없습니다. 달라지는 점은 아카이브의 출처와, 빌드 과정에서 해당 아카이브를 사용하기 전에 미리 확인이 이루어지는지 여부뿐입니다. 다만, 벤더드(vendored) 방식에 대해서는 한 가지 주의할 점이 있습니다. 벤더드 빌드는 vendor/ 디렉터리에서 직접 파일을 읽기 때문에 프록시에 전혀 요청을 보내지 않으므로, 디렉터리를 새로 고치지 않는 한 이 전환으로 인해 얻는 이점은 전혀 없습니다.

해상도 설정 전에 스크리닝이 추가하는 요소

Go에는 npm의 라이프사이클 스크립트에 해당하는 설치 시점 훅이 없는데, 이는 일반적으로 장점 중 하나로 꼽힙니다. 그렇다고 해서 모듈의 내용이 무해한 것은 아닙니다. 악의적인 소스 코드는 여전히 바이너리로 컴파일되어 포함되며, 리포지토리를 둘러싼 도구들 역시 자체적인 실행 경로를 열어줄 수 있습니다. PolinRider는 후자의 좋은 예시입니다. 페이로드는 Go의 init 함수에서 실행되는 코드가 아니라, 가짜 .woff2 글꼴 파일을 포함한 프로젝트 자산에 숨겨진 난독화된 자바스크립트 로더였습니다.

따라서 해상도 조정 전 스크리닝은 악성 콘텐츠가 빌드 환경에 도달하기 전에 이를 차단할 수 있는 가장 초기 단계의 자동화된 기회 중 하나입니다.

이 문제에는 세 가지 유형이 나타나며, 각각에 대해 서로 다른 세 가지 해답이 필요합니다.

리포지토리 해킹을 당한 모듈 경로는, Go가 이미 수행하고 있는 체크섬 검증을 위반하지 않고도 정상적인 경로를 통해 새로운 악성 버전을 제공할 수 있습니다. 이러한 검증은 리포지토리의 소유권이나 의도가 아닌 모듈의 내용을 인증하기 때문입니다. 해킹당한 VCS 소스 코드에서 다시 빌드하는 것도 소용이 없는데, 리포지토리가 이제 공격자의 소유가 되었기 때문입니다. 대신, 모듈을 불러오기 전에 내용을 검사하여 악성코드가 있는지 확인해야 합니다.

계정이 해킹당한 후 업스트림에 게시된 버전의 사례가 바로 PolinRider 사건입니다. go.sum과 체크섬 데이터베이스는 해당 바이트가 안전한지 여부가 아니라, 동일한 바이트인지 여부를 판단하기 때문에 이를 성공적으로 인증할 수 있습니다. 이러한 간극을 메워주는 것이 바로 스크리닝입니다.

CVE가 포함된 버려진 모듈은 완전히 다른 문제입니다. 악성 코드가 유입된 것은 아닙니다. 단지 유지보수 담당자가 기존에 존재하던 문제를 더 이상 수정하지 않게 된 것뿐입니다. 보안 권고문을 통해 이에 대한 정보를 확인할 수 있지만, 해당 모듈을 ‘종료’한다는 것은 작성자가 떠난 후에도 모듈에 패치를 계속 적용해야 한다는 것을 의미하며, 이는 ‘검증’이 아닌 ‘유지 관리’에 해당합니다. 바로 이것이 ‘무한 수명 주기 지원(ELS)’이 다루는 부분입니다.

이번 계정 탈취 사건의 규모는 주목할 만합니다. 연구진은 이 캠페인을 통해 배포된 108개의 고유 패키지 중 80개의 Go 모듈에서 에서 침해 흔적을 발견했으며, 총 162개의 악성 릴리스 아티팩트를 확인했고, ‘Contagious Interview’(일명 ‘Famous Chollima’)의 일환으로 해당 활동을 추적했습니다. 이 모듈들은 새로 등록된 유사 이름의 계정이 아닌, 수년간의 정상적인 사용 이력을 가진 계정을 통해 침해되었는데, 이는 무결성 검증만으로는 결코 포착할 수 없는 바로 그 유형의 사례입니다. 이러한 새로운 버전은 첫 번째 검증 단계에서 통과되는데, 해시 값이 해당 버전과 연관된 모든 콘텐츠를 충실하게 인증하기 때문이며, 오랫동안 신뢰받아 온 유지보수자가 배포한 것이라면 겉보기에는 의심스럽지 않게 보이기 때문이다.

특히 Go의 경우 여기서 다소 불편한 문제가 있습니다. Go 모듈은 일반적으로 레지스트리에 별도로 업로드되지 않고 VCS 태그나 커밋에서 직접 가져오기 때문에, 공격자가 별도의 인증 정보를 확보하지 않아도 리포지토리가 해킹당하면 그 영향이 모듈 생태계 전체로 확산될 수 있습니다. 연구진은 별도의 업로드 단계가 필요한 생태계에서는 해킹당한 한 관리자의 계정에서 악성 릴리스가 발견되지 않았다고 지적했는데, 이는 공격자들이 그 단계까지 진행하지 못했음을 의미할 수 있습니다.

포기는 동일한 노출 현상의 좀 더 은은한 형태입니다. 최근 1,310만 개의 오픈소스 패키지를 대상으로 한 분석에 따르면 에 따르면, 패키지 수 대신 종속 리포지토리를 기준으로 가중치를 적용했을 때 Go의 ‘대역 외(out-of-band)’ 비중은 33.2%에서 57.9% 사이로 나타났습니다. 이 차이가 발생하는 이유는 정의에 따른 것입니다. 상단 수치는 지난 730일 동안 릴리스가 없는 모든 패키지를 포함합니다. 하한치 역시 해당 기간 동안 리포지토리 커밋이 전혀 없는 경우를 기준으로 합니다. 어느 쪽이든, 언급된 Go 예시들(gopkg.in/yaml.v2, jwt-go, AWS SDK for Go v1)은 우리와 밀접한 관련이 있습니다. 선별 여부와 상관없이 어떤 레지스트리 아키텍처도 이 문제를 단독으로 해결할 수는 없습니다. 지속적인 패치 작업이 필요하며, 이것이 바로 앞서 언급한 세 번째 사례가 존재하는 이유입니다.

빌드를 깨지 않고 배포하기

네 단계로 이루어져 있으며, 속도보다 순서가 더 중요합니다.

2단계에서는 회의적인 검토자가 실제로 요구할 만한 근거를 제시합니다.

go clean -modcache

go mod 다운로드

go mod verify

각 명령어가 무엇을 확인하는지 정확히 파악해 두는 것이 좋습니다. 캐시가 비어 있는 상태에서 `go mod download`는 필요한 모듈을 새로운 레지스트리를 통해 강제로 불러오고, 커밋된 `go.sum` 항목이나 해시가 아직 기록되지 않은 경우 구성된 체크섬 데이터베이스에 대조하여 인증합니다. 그 다음 `go mod verify`는 캐시된 내용이 다운로드된 이후 변경되지 않았는지 확인합니다. 이 두 단계를 마친 후 평소와 같이 빌드나 테스트를 실행하면, 호환성 주장은 벤더 환경이 아닌 사용자의 환경에서 프로젝트의 현재 의존성을 기준으로 검증됩니다.

4단계는 정책이 실제 적용으로 이어지는 단계입니다. 출구(egress)가 차단되기 전까지는 GOPROXY는 누구나 무시하고 금요일 배포를 차단 해제할 수 있는 권장 사항에 불과합니다. proxy.golang.org를 단순히 차단하는 것만으로는 충분하지 않습니다. 왜냐하면 그 뒤에 붙은 ‘direct’ 설정으로 인해 GitHub 및 관련 사이트로 404 오류가 전송되기 때문입니다. 레지스트리를 허용 목록에 추가하고 나머지는 차단하십시오. 규칙을 전환하기 전에 한 가지 확인 사항이 있습니다. 체크섬 검증은 여전히 체크섬 데이터베이스에 직접 또는 이를 미러링하는 프록시를 통해 접근해야 하므로, 첫 번째 파이프라인 오류가 발생했을 때 비로소 알게 되는 일이 없도록 해당 조회 작업이 계속 정상적으로 해결되는지 확인하십시오.

전문가 팁: 프로덕션 환경에 배포하기 전에 스테이징 환경에서 4단계를 충분히 오래 실행하여 평소의 빌드 워크플로우를 점검해 보세요. 이를 통해 아무도 모르게 직접 해결되고 있던 파이프라인의 실제 현황이 드러나게 되며, 이러한 현황을 지금 목록으로 파악해 두는 것이 나중에 사고로 발생하는 것보다 훨씬 낫습니다.

Go 공급망을 안전하게 확보하세요

만약 여러분의 리포지토리에서 1단계와 2단계를 이미 통과했고, 이를 여러분의 go.sum과 대조해 확인했다면, 이것이 바로 보안 검토에 필요한 호환성 증빙 자료이며, 여러분이 직접 이를 마련한 것입니다. 무엇이 SecureChain for Go 가 여기에 더하는 것은 일회성 점검이 아닌 매 펫치(fetch) 시마다 이루어지는 지속적인 스크리닝이며, 모듈 관리자가 자리를 떠난 후에도 지속되는 패치 기능입니다. 이 패치는 도구 체인이 이미 기대하는 것과 동일한 모듈 프록시 프로토콜을 지원하는 레지스트리를 통해 제공됩니다. EOL(지원 종료) 이후 패치 기능에 의존하기 전에, 패치된 Go 모듈에 대한 문서화된 버전 관리 및 체크섬 메커니즘을 확인하여 이를 배포 과정에 반영할 수 있도록 하십시오.

SecureChain 견적 요청하기 SecureChain에 대한 견적을 요청하거나, SecureChain과 Chainguard를 비교해 보세요.

자주 묻는 질문

Go 모듈 프록시를 변경하려면 어떻게 해야 하나요?

GOPROXY 환경 변수를 레지스트리 URL로 설정할 때, ‘direct’ 앞에는 파이프(|) 대신 쉼표(,)를 사용하세요. ‘go env -w GOPROXY=…’ 명령을 실행하면 개발자 컴퓨터에 해당 설정이 반영됩니다. CI 환경에서는 베이스 이미지 대신 환경 변수에서 이 설정을 지정하세요.

Go 모듈 프록시를 변경하면 go.sum이 작동하지 않게 되나요?

아니요, 레지스트리가 동일한 모듈 내용을 제공하는 한 그렇습니다. Go의 모듈 해시는 zip 인코딩 세부 사항이 아닌 파일 이름과 파일 내용에서 파생되므로, 동일한 파일 구조를 가진 독립적으로 생성된 아카이브는 동일한 해시를 생성합니다. 패치된 모듈은 예외입니다. 정의상 내용이 다르면 해시도 달라지기 때문이며, 해당 내용의 버전 관리 및 인증 방식은 레지스트리의 패치된 모듈 전달 방식에 따라 달라집니다.

체크섬 데이터베이스를 계속 활성화해 둘 수 있을까요?

네, 그렇게 하셔야 합니다. GOSUMDB 검증과 레지스트리 검사는 서로 다른 문제를 다루며, ‘있는 그대로’ 제공되는 업스트림 모듈의 경우 설계상 해시가 일치합니다. 해당 모듈에 대해서는 GOSUMDB=sum.golang.org 설정을 활성화된 상태로 유지하고, 패치된 모듈은 레지스트리에서 해당 모듈에 대해 명시한 버전 관리 및 체크섬 메커니즘을 통해 처리하십시오.

다른 프록시를 사용하려면 go.mod 파일을 수정해야 하나요?

아니요. go.mod는 모듈 경로와 버전을 기록할 뿐이며, 사용자가 설정한 replace 지시문을 제외하고는 아카이브를 어디서 가져올지에 대해서는 아무런 영향도 미치지 않습니다. 프록시 선택은 환경 설정에서 결정됩니다.

호환성 주장을 직접 확인하려면 어떻게 해야 하나요?

`go clean -modcache` 명령어로 모듈 캐시를 지운 다음, 새로운 레지스트리를 통해 `go mod download`를 실행하여 Go가 기존 체크섬을 기준으로 모든 내용을 다시 가져오고 인증하도록 한 후, `go mod verify`를 실행하고 평소와 같이 빌드나 테스트 스위트를 진행하세요. 검증에 성공하면, 가져온 모듈이 프로젝트가 이미 신뢰하고 있는 해시와 일치한다는 의미입니다.

요약

기사 이름

GOPROXY: 검증된 모듈을 갖춘 대안

설명

검증된 Go 모듈 프록시 대안으로 전환하는 데는 GOPROXY 한 줄만 추가하면 됩니다. go.sum이 여전히 작동하는 이유, 선별 과정이 어떤 이점을 제공하는지, 그리고 이를 안전하게 도입하는 방법을 확인해 보세요.

작성자

팀 워커

게시자 이름

TuxCare

게시자 로고