CodeQL rollout stalls in a polyglot monorepo
The organization enabled default setup for code scanning across 240 repositories after purchasing GitHub Advanced Security. Two weeks later, Security Overview shows 38 repositories with no analysis and 22 with configuration errors. The worst is platform-core, a 1.2M-line monorepo containing Java/Kotlin services built with Gradle, Python services, TypeScript front ends, C++ native modules built with CMake, and a Swift iOS app. Java analysis fails during autobuild because Gradle must authenticate to an internal Artifactory to download plugins; the C++ code needs a custom CMake toolchain file and environment variables; the Swift analysis exceeds the job time limit and is cancelled. TypeScript and Python analyze fine, but 70% of their alerts come from vendor/ and generated Protobuf sources. Platform teams refuse to maintain per-repository CodeQL workflows unless strictly necessary, build minutes are capped, and pull requests must be blocked on new critical findings before the next release.
1. Which setup should platform-core use, and how do you get Java, C++, and Swift analyzed? Explain the trade-offs.
Read the worked answer
Keep default setup everywhere it works; move only platform-core to advanced setup, because default setup cannot inject registry credentials, supply a custom CMake toolchain, or choose an Xcode scheme. Use one workflow with a language matrix and fail-fast: false.
- Java/Kotlin: run
./gradlew assemblewith credentials from Actions secrets (or mirror Artifactory into GitHub Packages), then rungithub/codeql-action/analyze. A manual build gives CodeQL compiled classes and generated-source context;build-mode: noneis simpler but is not available for every language and reduces fidelity. - C++:
build-mode: manual, install the toolchain, configure withcmake -DCMAKE_TOOLCHAIN_FILE=..., build, then analyze. - Swift: run on a macOS runner, build a single scheme, and schedule it nightly instead of per push to stay inside the job limit.
The trade-off is owning workflow maintenance and runner minutes. Keep default setup on the other 239 repositories and review exceptions quarterly rather than letting per-repo workflows sprawl.
2. How should vendored and generated code be excluded without hiding real findings, and what are the side effects?
Read the worked answer
Exclude vendor/ and the generated Protobuf output with paths-ignore, or scope analysis with paths to first-party source roots. Two cautions apply. First, path filters change analysis scope: alerts previously raised in excluded paths close on the next analysis, and genuinely vulnerable code later placed there will never be detected, so document the filter and review it whenever the directory layout changes.
Second, third-party code is not left unprotected: dependency graph, Dependabot alerts, and dependency review cover it at the dependency level, which is more accurate than scanning vendored copies. For generated sources, exclude the output directory and commit the generator configuration rather than dismissing individual alerts, since dismissals do not scale and reappear when files move.
Set an explicit category per language so analyses in the monorepo do not overwrite each other, and prove the filter with a test pull request containing a known finding in first-party code.
3. How do you make code scanning block merges without blocking hotfixes?
Read the worked answer
Create an enterprise or organization ruleset targeting the default branch with the code scanning rule, set the severity threshold to critical and high, and enable evaluation on pull requests and merge blocking. The rule evaluates results for the pull request head, so analysis must run on pull_request events for every language you want gated; default setup does this automatically, an advanced workflow does not unless it is triggered on pull_request.
Prove it with a deliberately vulnerable pattern on a branch, and confirm the merge button is blocked and the bypass is recorded. Provide a break-glass path: a ruleset bypass for a named team, with audit log review, otherwise urgent fixes stall and people disable the control entirely. Because path filters exclude vendored code, state in the policy that the gate covers first-party code only, and that dependency risk is handled by dependency review.