개발 뉴스
CodeQL 2.27.2 분석 강화…Go 쿼리와 macOS 빌드 환경도 달라진다
언어별 모델 개선과 별개로 커스텀 쿼리·러너 호환성을 점검해야 한다. GitHub.com 자동 배포와 GHES 적용 경로도 다르다.
- C++·Go·Rust·JavaScript 분석을 개선했다. 실제 사용하는 라이브러리와 구문에 해당하는 변화부터 확인해야 한다.
- Go CFG 구조와 일부 API가 바뀌어 커스텀 쿼리의 컴파일·탐지 의미를 함께 검증해야 한다.
- 컴파일 언어의 autobuild/manual 모드는 macOS 27 및 macOS 26·Xcode 27 조합에서 지원되지 않는다.
GitHub CodeQL 2.27.2는 분석할 수 있는 코드 경로를 넓히는 동시에 기존 분석 환경의 호환성도 바꾸는 업데이트다. 언어별 기능 추가만 읽고 적용하면 Go 커스텀 쿼리나 macOS 빌드에서 예상하지 못한 차이를 만날 수 있다. 개발팀이 이번 릴리스를 검토할 때는 분석 모델, 쿼리 구조, 실행 환경을 함께 살펴야 한다.
CodeQL 2.27.2 발표일과 릴리스 문서 날짜를 구분하기
GitHub는 2026년 10월 9일 Changelog에서 CodeQL 2.27.2 개선 사항을 소개했다. 공식 릴리스 변경 문서의 날짜 표기는 10월 7일이다. 이 기사에서는 뉴스 발표일과 릴리스 문서 날짜를 구분한다. [S1] [S2]
GitHub code scanning 운영자에게 뉴스 날짜보다 중요한 것은 실제 분석에 쓰이는 버전이다. 검증할 때 코드 커밋, CodeQL 본체, 쿼리 팩, 빌드 환경을 함께 기록할 필요가 있다. 아래 검증 순서는 편집자의 운영 제안이며 GitHub가 보장하는 성능이나 결과가 아니다. CodeQL 2.27.2 변경점은 이런 기준선 위에서 비교해야 의미가 있다.
CodeQL C++·Go·Rust·JavaScript, 언어별 분석 개선
C++에는 std::regex의 ECMAScript 문법을 다루는 파서와 Comdb2 C API의 SQL 인젝션 모델이 추가됐다. Go는 github.com/coder/websocket 경로를 지원하고, Rust는 await와 함께 쓰는 비동기 블록의 데이터 흐름을 개선했다. JavaScript/TypeScript는 Workflow SDK 지시문 인식과 Hapi 요청 입력 추적을 보완했다. [S1]
CodeQL C++, CodeQL Go, CodeQL Rust, CodeQL JavaScript의 변화는 서로 다른 코드 경로에 관계된다. 모든 언어의 탐지율이 일률적으로 높아졌다고 해석하기보다, 사용 중인 라이브러리와 구문을 대조해 검토 대상을 좁히는 편이 좋다. 새 경고가 생기면 입력 추적의 변화와 실제 코드 문제를 함께 확인해야 한다.
CodeQL Go CFG breaking change: 커스텀 쿼리가 우선 점검 대상
Go CFG는 공통 CFG 라이브러리를 사용하는 구조로 다시 작성됐다. 노드·엣지·기본 블록 경계 등에 의존하는 기존 쿼리는 수정이 필요할 수 있다. 공식 문서는 BasicBlocks::Cfg 제거, IfStmt.getCond 대신 IfStmt.getCondition 사용, 일부 반환 타입의 변경을 명시한다. [S2]
Go 소스코드가 그대로여도 커스텀 분석 쿼리의 가정은 달라질 수 있다. CodeQL 2.27.2 업그레이드 검증에서는 먼저 쿼리 컴파일 성공 여부를 확인하고, 이어 정상·위험 사례로 준비한 작은 테스트 코드에서 기대한 결과가 나오는지 비교하는 것이 합리적이다. 쿼리가 실행된다는 사실만으로 탐지 의미까지 같다고 결론 내려서는 안 된다.
macOS 27 CodeQL 제한, Xcode 조합까지 확인해야
컴파일 언어의 autobuild/manual 빌드 모드는 macOS 27에서 Xcode 버전과 관계없이 지원되지 않는다. macOS 26이라도 Xcode 27을 선택하면 같은 제한을 받는다. GitHub는 이 빌드 모드에 대해 macOS 26·Xcode 26 이하 조합을 안내하고 있다. [S1]
macOS 27 CodeQL 문제가 모든 언어와 모든 분석 방식의 중단을 뜻하는 것은 아니다. 실제 워크플로의 언어, 빌드 모드, 러너 이미지, 선택된 Xcode를 한 줄로 기록해 적용 범위를 판단해야 한다. build mode none 지원 개선은 진행 중인 작업으로 소개됐으므로, 이미 완성된 대체 경로로 간주하지 않는다. [S1]
| 환경 조합 | autobuild/manual 검토 |
|---|---|
| macOS 27 + 모든 Xcode | 컴파일 언어에서 지원되지 않음 |
| macOS 26 + Xcode 27 | 컴파일 언어에서 지원되지 않음 |
| macOS 26·Xcode 26 이하 | GitHub가 안내한 상한 조건. 실제 프로젝트 검증은 별도 필요 |
CodeQL 2.27.2 GHES 지원과 팀별 검증 순서
GitHub.com의 CodeQL 새 버전은 GitHub code scanning 이용자에게 자동 배포된다. GHES는 향후 릴리스에 새 기능이 포함될 예정이라고 안내돼 있다. 따라서 CodeQL 2.27.2 GHES 지원을 판단할 때 GitHub.com의 자동 배포 상태를 그대로 대입해서는 안 된다. [S1]
팀의 적용 순서는 다음처럼 구성할 수 있다. 먼저 현재 배포 경로와 버전 고정 여부를 확인한다. 다음으로 Go 커스텀 쿼리의 컴파일·의미를 비교한다. 이후 macOS 러너 조합을 확인하고, 같은 코드에서 업데이트 전후 결과를 검토한다. 새 경고를 무조건 취약점 증가로 해석하거나, 경고 감소를 곧바로 보안 개선으로 평가하는 일은 피한다.
이번 업데이트의 가치는 추가된 분석 모델과 운영 호환성을 함께 검토할 때 드러난다. 개발팀은 변경 목록을 읽는 데서 멈추지 말고, 실제 저장소의 쿼리와 러너 조합으로 결과를 재현해야 한다. 분석기의 변화와 코드의 변화를 나눠 기록하면 업그레이드 이후의 경고도 더 정확하게 해석할 수 있다.
