In May 2026, InfoQ published GitHub Enhances CodeQL with Declarative Security Modeling for Faster, More Flexible Analysis, announcing that declarative security models were introduced to CodeQL, making SAST (Static Application Security Testing) query authoring and updates 5 to 10 times faster than before. CodeQL queries—once considered writeable only by specialized security engineers—have now entered a practical realm where custom development teams can operate them.
In custom development projects handling sensitive data, such as SaaS, internal business systems, and e-commerce, whether SAST can be integrated across projects determines quality and engineering effort. This article outlines architectural guidelines for operating CodeQL's declarative models in custom development, reusing cross-project security knowledge, and structuring contract terms.
What changed
CodeQL's declarative security modeling brings about three fundamental changes:
| Item | Legacy CodeQL | Declarative model |
|---|---|---|
| Query authoring | Written procedurally | Intent declared in YAML |
| Learning curve | Several weeks to months | A few days |
| Cross-language | Rewritten per language | Multiple languages via a single model |
| Customization | For advanced specialists | Feasible for custom development engineers |
The "cross-language" capability is an especially significant change. Being able to cover TypeScript, Python, Go, Java, and C# with a single threat model provides a powerful advantage in custom development projects where multiple languages coexist.
This aligns with the cross-project security automation discussed in Operating source code secrets audits in custom development, and lowering the barrier of "inability to write queries" carries major significance.
Four operational tiers for CodeQL in custom development
When running CodeQL across projects, organizing operations into the following four tiers is effective.
[Tier 1: 標準クエリセット]
├ OWASP Top 10 / CWE Top 25 を全案件適用
├ 認証 / セッション / 入力検証 / SSRF / SQLi
└ 月次でアップデート
[Tier 2: 業界別クエリセット]
├ EC: 決済 / 在庫操作 / 個人情報マスキング
├ 医療: HIPAA 相当 / アクセスログ強制
├ 金融: PCI-DSS 相当 / 監査ログ
└ SaaS: テナント分離 / RBAC
[Tier 3: 顧客固有クエリ]
├ 顧客固有の脅威モデルを宣言型でモデル化
├ 案件専用 GitHub Org に配置
└ ペアプロでセキュリティチームと共同作成
[Tier 4: 自動修正 PR]
├ 検出 → 修正 PR 自動作成
├ 人間レビュー必須のラベル付与
└ 修正パターンを Tier 1 〜 2 に逆輸入In particular, Tier 4 automated remediation PRs have become dramatically easier to implement when combined with Claude Code Auto Mode. This applies the Approval Gates mechanism discussed in Operating Claude Code Auto Mode safely in custom development to "security fixes," the area requiring the most stringent authorization.
Transforming cross-project security knowledge into intellectual assets
The greatest advantage of the declarative model is that security knowledge can be accumulated as corporate intellectual assets. Structuring storage destinations and sharing scopes as follows facilitates smooth ongoing operations.
| Knowledge type | Storage destination | Sharing scope |
|---|---|---|
| Industry-standard threat models | Shared repository | All projects |
| Language-specific patterns | Language-specific packages | All projects using the language |
| Client-specific queries | Project-dedicated repository | Applicable project only |
| Best practices | Internal documentation | All engineers |
In particular, "industry-standard threat models" cut initial setup costs by two-thirds in projects such as "enhancing security for e-commerce." This architecture enables CodeQL's declarative model to directly render the core competitive advantage of custom development—"reusing insights from past projects in new initiatives"—machine-readable.
"SAST operational terms" to include in custom development contracts
In custom development contracts incorporating CodeQL into projects, explicitly state the following terms.
| Clause | Details | What the client should verify |
|---|---|---|
| Target scope | Repositories, branches, and excluded paths | Handling of legacy code |
| Query sets | Combination of standard, industry, and client-specific queries | Validity of industry queries |
| Remediation SLA upon detection | Resolution deadlines for High / Medium / Low | Feasibility of deadlines |
| Automated remediation PRs | Generation scope of automated PRs and approvers | Designating authorized approvers |
| Handling false positives | Responsibility for false positive tuning | Improvement loop |
| Monthly reports | Detected count / fixed / unaddressed | Report format |
In particular, if a "remediation SLA upon detection" is not clearly documented upfront, "we will fix it eventually" becomes indefinite. Agree upon concrete targets such as High = 24 hours, Medium = 7 business days, Low = 30 days.
This shares the philosophy of continuous security covered in Continuous penetration testing with AWS security agents, making "remediating within deadlines" rather than "merely detecting" the core commitment of the contract.
Five common pitfalls
Finally, we share common pitfalls encountered when operating CodeQL in custom development.
Pitfall 1: Detecting issues without a remediation workflow
Setting "detected count" as the sole KPI causes remediation to be deprioritized, allowing vulnerabilities to accumulate. Make remediation completion rate the primary KPI, treating detected count as a secondary metric.
Pitfall 2: Applying the exact same queries to all projects
Threat models differ between e-commerce and internal enterprise systems. Applying uniform queries across all projects creates noise and overlooked risks simultaneously. Always apply Tier 2 industry queries.
Pitfall 3: Neglecting false positive tuning
Leaving false positives unaddressed fosters a culture where development teams ignore alerts. Maintain a loop of false positive → query adjustment → deployment within a two-week turnaround.
Pitfall 4: Immediately merging automated remediation PRs
"Merging remediation PRs generated by Claude Code immediately simply because they are security fixes" is dangerous. Require at least one human review and passing tests without exception.
Pitfall 5: Client PMs failing to review reports
When only the development team reviews reports, discovery of critical vulnerabilities is delayed. Incorporate a monthly meeting into the contract to review reports together with the client's PM.
Summary — From "authored by dedicated security teams" to "operated by custom development teams"
CodeQL's declarative security modeling marks the turning point from "SAST that only specialists can author" to "SAST that custom development engineers can operate." The declarative model transforms the competitive advantage of "accumulating cross-industry threat models as intellectual assets" into a practical reality on client engagements.
Because the required effort for designing CodeQL integrations into CI and establishing end-to-end workflows from detection to remediation varies greatly depending on repository scale and threat models, we provide custom estimates after discussing your requirements. If you want to "run continuous security audits" or "detect vulnerabilities but struggle with remediation workflows," please feel free to reach out via our contact form.
Sources
- GitHub Enhances CodeQL with Declarative Security Modeling for Faster, More Flexible Analysis（InfoQ）
- Operating source code secrets audits in custom development (GH Media)
- Continuous penetration testing with AWS security agents (GH Media)
- Safely Operating Claude Code Auto Mode in Custom Development (GH Media)
