Go 보안 업데이트, 설치만 하면 끝일까? eMudhra 대응과 바이너리 재빌드 확인

신뢰할 수 없는 키를 걷어내고 서버 구성 요소를 교체하는 모습을 표현한 생성형 개념 이미지. 실제 사고 현장이나 제품 화면이 아니다.

Go를 업데이트했는데 운영 서버도 안전해진 걸까? 이번 인증서 보안 대응에서는 설치된 Go뿐 아니라 실제 서비스 바이너리를 어떤 Go 버전으로 빌드했는지 확인해야 한다. 새 도구를 설치한 사실과 새 실행 파일이 배포된 사실은 별개다.

Go 보안팀은 October 26, 2026 eMudhra 인증서 사건에 대한 대응 과정을 공개했다. 패치 자체는 공식 릴리스 이력상 October 19, 2026 나온 Go 1.27.3과 1.26.10에 포함된다. 26일에 처음 패치가 나왔다고 읽으면 안 된다. Go 대응 회고, 공식 릴리스 이력

2026년 10월 27일 직접 확인·캡처한 Go 공식 회고의 제목과 발표일.

내 서버 인증서만 확인하면 되는 문제는 아니다

Go 보안팀에 따르면 문제가 된 중간 인증서의 키가 매우 약해 제3자가 개인키를 복구할 수 있었다. 이런 키로 발급한 인증서가 신뢰되면 TLS 상대방을 사칭할 위험이 생긴다.

확인 대상은 자신의 서비스에 설치한 인증서만이 아니다. 외부 HTTPS API나 TLS 기반 gRPC 서버에 연결하는 Go 프로그램도 상대 인증서를 검증한다. Go 팀은 Linux의 인증서 폐기 확인 환경을 중요한 대응 이유로 들었으며, 문제가 된 중간 인증서를 거치는 체인을 거부하도록 수정했다. 모든 eMudhra 인증서를 일괄 차단한다는 뜻으로 확대해서는 안 된다. Go 공식 설명

최초 릴리스 공지는 이를 CVE-2026-111943으로 식별하고 즉시 업데이트를 권고했다. 여기서 다루는 것은 이 공식 보안 대응이며, 특정 사용자의 서비스가 침해됐다는 주장은 아니다. 공식 보안 릴리스 공지

첫 번째 확인: 도구와 결과물을 나눠 본다

아래는 독자가 자신의 환경에서 사용할 점검 명령이다. 이 글을 위해 운영 서버에 실행한 결과나 취약점 재현 로그는 아니다.

파일을 지정하지 않은 go version은 Go 명령 자체의 버전을 보여준다. 파일을 지정하면 해당 파일을 빌드한 Go 버전을 확인하며, -m은 가능한 경우 내장된 모듈 정보도 출력한다. go version 공식 문서

따라서 개발 PC에서 새 버전이 출력되는 것만으로 운영 배포를 확인할 수는 없다. CI가 사용하는 빌더, 보관된 배포 파일, 컨테이너 이미지에 들어간 실행 파일을 각각 대조하는 것이 좋다.

운영 컨테이너 안에 Go 도구가 없다면, 승인된 절차로 동일한 배포 산출물을 점검 환경에서 확인할 수 있다. 이름만 같은 로컬 파일이 아니라 해시나 이미지 식별자로 대응 관계를 남긴다. 이는 공식 명령을 운영에 적용하기 위한 점검 방법이다.

두 번째 확인: 바이너리 취약점 검사

Go 팀은 govulncheck의 바이너리 모드도 안내한다. 도구를 이미 준비한 점검 환경에서는 다음과 같이 실행한다.

govulncheck는 알려진 취약점과 코드의 관련성을 분석한다. 바이너리 검사에서는 해당 실행 파일의 빌드 구성을 사용하지만, 소스 분석과 달리 상세 호출 그래프를 제공할 수 없다. 실행 파일에 남아 있지만 도달할 수 없는 코드가 보고되는 등 한계도 있다. govulncheck 공식 문서

검사 결과가 없다는 사실을 모든 보안 문제가 없다는 보증으로 바꾸면 안 된다. 이번 패치 버전 확인, 실제 산출물 확인, 서비스 동작 확인을 함께 남기는 편이 낫다.

CI에 연결한다면 출력 형식도 살펴본다. 공식 문서상 JSON·SARIF·OpenVEX 형식은 취약점 발견 여부와 관계없이 성공 종료할 수 있다. 이런 형식을 선택한 파이프라인은 종료 코드만 보고 통과시키지 말고 결과 내용을 판정해야 한다. 종료 코드 설명