CodeQL 2.27.2 변경점, 언어 분석 개선보다 먼저 확인할 호환성
GitHub CodeQL 업데이트의 적용 경로와 Go CFG 변경, macOS 빌드 제한을 팀 환경에 맞춰 읽기
정적 분석 엔진을 업데이트한 뒤 경고가 달라졌다면 코드 변화만을 원인으로 볼 수 없다. 분석 모델과 쿼리 라이브러리, 빌드 환경도 결과에 영향을 주는 점검 대상이다. 이번 업데이트를 검토하는 팀은 새 기능 목록과 함께 ‘현재 워크플로가 계속 실행되는가’를 먼저 살펴볼 필요가 있다.
GitHub CodeQL 업데이트, 두 날짜와 적용 경로
CodeQL 2.27.2의 공식 CLI 변경 기록은 2026년 10월 7일자이고, GitHub는 10월 9일 블로그에서 개선 내용을 소개했다. GitHub code scanning의 정적 분석 엔진 업데이트로 읽되 두 날짜를 동일한 발표 시점으로 합치지 않는 편이 정확하다. [1] [2]
GitHub.com에는 새 버전이 자동 배포된다. CodeQL 2.27.2 GHES 지원은 향후 GHES 릴리스에 포함될 예정이라고 안내됐으며, 소개 글에 구체적인 릴리스 날짜는 없다. 구버전 GHES의 수동 업그레이드는 안내 문서를 따라 확인해야 한다. [1]
팀의 CodeQL 2.27.2 업그레이드 계획에는 실행 위치를 먼저 적어 두자. 같은 저장소라도 GitHub.com의 기본 실행인지, 자체 워크플로의 CLI인지, GHES에서 운영하는 작업인지에 따라 확인할 설정과 적용 경로가 달라진다.
C++·Go·Rust·JavaScript 분석에서 달라진 부분
| 영역 | 확인된 변경 | 팀의 검토 대상 |
|---|---|---|
| CodeQL C++ | std::regex의 ECMAScript 문법 파서, Comdb2 SQL 인젝션 sink 모델 | 해당 API·정규식을 사용하는 코드 |
| CodeQL Go | github.com/coder/websocket 경로 모델링 | 해당 WebSocket 패키지 사용 여부 |
| CodeQL Rust | await와 함께 쓰는 async 블록의 데이터 흐름 개선 | 비동기 처리 경로 |
| CodeQL JavaScript | Workflow SDK 지시문 인식, Hapi 입력 추적 개선 | 관련 SDK·라우트 등록 코드 |
이 내용은 공식 변경 기록의 분석 범위이며, 모든 프로젝트에서 탐지율이나 속도가 같은 폭으로 좋아진다는 뜻은 아니다. [2] 적용 전후 비교에서는 같은 코드와 같은 쿼리 세트를 기준으로 결과를 확인하는 것이 좋다.
CodeQL Go CFG breaking change: 커스텀 쿼리 점검
Go CFG는 공통 라이브러리 기반으로 재작성됐다. 노드·간선·위치·기본 블록 경계 등 이전 표현에 의존한 쿼리는 수정이 필요할 수 있다. BasicBlocks::Cfg 제거와 IfStmt.getCond의 사용 중단 예정 처리도 변경 기록에 명시됐다. 대체 API는 IfStmt.getCondition이다. [2]
중요한 점은 Go 코드 전체가 호환되지 않는다는 의미가 아니라, 기존 CFG 표현을 전제로 만든 분석 코드가 검토 대상이라는 것이다. 내부 쿼리 팩을 운영한다면 해당 API 사용처와 제어 흐름 구조에 의존한 조건을 찾아 작은 대표 프로젝트에서 먼저 검증하자.
macOS 27 CodeQL 제한, Xcode 조합도 확인해야
GitHub는 컴파일 언어의 autobuild·manual 모드가 macOS 27에서는 Xcode 버전과 관계없이 지원되지 않고, macOS 26에서도 Xcode 27을 선택하면 지원되지 않는다고 안내했다. 해당 모드에는 최대 macOS 26·Xcode 26 조합을 사용하라는 설명이다. [1]
macOS 27 CodeQL 환경을 검토할 때 OS 버전만 확인하면 제한 조건을 놓칠 수 있다. 워크플로의 실제 러너와 선택된 Xcode, 빌드 모드까지 함께 기록하자. build mode none의 지원 개선 작업이 언급됐지만, 이를 모든 언어·프로젝트의 즉시 대체 수단으로 단정하면 안 된다.
팀이 관리하는 분석 환경에서는 OS·도구체인 업데이트와 분석 엔진 변경을 따로 검증할 수 있도록 계획하는 것이 좋다. 어떤 변경이 실패를 만들었는지 좁힐 수 있는 기록을 남겨 두면 전체 워크플로를 다시 설계하는 부담을 줄일 수 있다.
도입 결정은 경고 개수보다 재현 가능한 비교로
새 버전에서 경고가 늘어났다는 이유만으로 코드가 갑자기 나빠졌다고 판단하거나, 경고가 줄었다는 이유만으로 안전해졌다고 판단하는 것은 피하자. 팀이 확인해야 할 것은 변경된 경고의 원인과 조치 가능성이다.
우선 작은 저장소 한 곳에서 현재 설정을 기록하고, 적용 후 컴파일·분석 성공 여부와 경고 변화, 검토 시간을 비교하자. 커스텀 쿼리와 빌드 환경의 문제가 분리됐다면 그 결과를 바탕으로 확대 적용 범위를 정할 수 있다. 뉴스의 변경 목록을 우리 프로젝트의 검증 기록으로 바꾸는 단계가 업그레이드의 실질적인 마무리다.
