Sonar acquires Gitar: implications for code verification governance

At a glance

What this is: Sonar’s acquisition of Gitar is positioned as a move to add AI-native code review and remediation into a multilayer verification model for AI-assisted software development.

Why it matters: It matters because teams adopting AI coding tools need stronger verification controls, clearer review boundaries, and governance that treats generated code as untrusted until validated.

Context

AI-assisted coding changes the control problem from writing software to validating it. When code can be generated quickly, plausibly, and repeatedly, the governance gap shifts to verification depth, review consistency, and whether failures are caught before changes reach production. That is especially relevant where AI tools sit inside pull request workflows and can alter the pace and shape of human review.

This article sits at the intersection of application security, software assurance, and identity governance for AI systems. The important question is not whether AI can produce code, but how organisations preserve trustworthy review, accountable approval, and auditable change control when agentic tooling starts participating in the development lifecycle.

Key questions

Q: How should security teams govern AI-generated code in production environments?

A: Security teams should treat AI-generated code as normal production code with extra provenance risk. Require architectural review, test coverage, static analysis, and approval before merge. Then bind the agent and the build pipeline to least privilege, short-lived credentials, and complete audit logging so implementation speed does not outrun control.

Q: When does automated code review become a governance risk instead of a productivity gain?

A: It becomes a governance risk when the reviewer can change code, not just comment on it, and when the organization cannot explain who authorised those changes. At that point, the review system is acting as a privileged non-human participant in delivery, which requires clear controls over branch access, logging, and rollback.

Q: What breaks when teams rely on test coverage or complexity metrics to judge AI-generated code?

A: Proxy metrics can be gamed by agents and may not reflect real code quality. Test coverage can rise without meaningful assurance, and complexity scores can miss whether the code is understandable or safe to ship. Teams need evaluation criteria tied to semantic correctness, maintainability, and production risk, not just numbers that are easy to optimize.

Q: What is the difference between code generation and code verification in AI pipelines?

A: Code generation produces a plausible implementation, while code verification determines whether that implementation is trustworthy enough to merge and ship. In AI pipelines, the distinction matters because the tool that writes code is not the same control that proves the code is safe, maintainable, and ready for production.

Technical breakdown

Multilayer code verification for AI-assisted development

AI-assisted development creates a control gap because code generation and code trust are not the same thing. A verification layer has to inspect syntax, data flows, control flows, dependencies, and security issues before code is treated as production-ready. In practical terms, this is a zero-trust model for code: generated output remains untrusted until deterministic analysis and review confirm it is safe, maintainable, and reliable. That matters because AI tools can produce convincing answers that hide defects deep in the implementation.

Practical implication: separate code generation from code approval and require independent verification before merge.

Agentic code review and closed-loop remediation

AI-native review systems go beyond detection by proposing fixes, rerunning checks, and iterating until CI passes. That changes the economics of review, but it also changes governance expectations because remediation becomes part of the control path rather than a separate human task. The technical risk is that automated repair can mask root causes if the control only checks whether tests pass. Strong governance therefore needs visibility into what changed, why it changed, and whether the final state is explainable and auditable.

Practical implication: track automated fix loops as controlled changes, not just successful builds.

Verification as a trust boundary in the SDLC

Verification becomes the trust boundary when AI systems can write and modify code at speed. In that model, the important control is not merely code scanning after the fact, but continuous assurance from pull request to merge to build. Zero-trust verification means no single check is sufficient and no agent-generated output should bypass layered controls. This is particularly relevant where AI tooling can act on context, generate fixes, and influence commit history without a human re-reading every line.

Practical implication: design the SDLC so every AI-assisted change passes layered controls before it is considered trusted.

NHI Mgmt Group analysis

Verification, not generation, is becoming the real control plane for AI-assisted software delivery. The operational risk is no longer limited to whether an AI model can write code, but whether organisations can prove that what it wrote was checked with enough depth before release. That shifts governance from developer productivity to trustworthiness of the change path. Practitioners should treat validation coverage as the primary risk measure, not output volume.

AI-native review tools only help if they preserve auditability and do not collapse into invisible automation. When a system generates fixes and iterates until CI passes, the process can look efficient while hiding why a change was accepted. That creates a governance gap around explainability, evidence retention, and accountable approval. Practitioners should insist on traceable remediation history and reviewer oversight for any automated fix loop.

Zero-trust verification is a useful framing only when teams apply it to code, context, and approval boundaries together. A single scanner or a single review step does not resolve the problem of plausible but flawed AI output. The more AI participates in development, the more organisations need layered controls that distinguish generation, validation, and authorization. Practitioners should re-evaluate whether their current SDLC assumes too much trust in code before it is actually verified.

Code verification governance is now part of AI governance, not just application security. If an AI system can influence what gets merged, then the organisation is also governing an AI-enabled decision process. That makes the control model relevant to software supply chain integrity, change management, and AI risk oversight at the same time. Practitioners should align engineering controls with broader AI governance expectations rather than treating them as separate programmes.

Agentic Code Verification Gap: The core failure mode is assuming that successful CI means trustworthy code. In AI-assisted workflows, an agent can generate a plausible fix that passes tests while still leaving architectural or security debt behind. Practitioners should measure whether their verification stack can detect acceptable-looking but unsafe changes before merge.

From our research library:

• By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
• Read next: AI Coding Agents Security Guide

What this signals

AI code verification debt: As AI coding tools move faster than human review capacity, the risk is not just more defects but more accepted defects that look correct at merge time. Programmes should assume that quality gates need to shift left and become more granular, especially where agents can iterate until CI passes.

Verification frameworks such as NIST SP 800-207 Zero Trust Architecture are relevant here because the core issue is trust placement, not code volume. In this context, the governance question is whether every AI-assisted change is still being checked as if it were potentially hostile or simply incomplete.

90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs. That matters here because AI-assisted development increasingly depends on machine identities, service accounts, and automated tooling that can change code without a traditional human approval flow.

For practitioners

• Define verification as a mandatory control Treat AI-generated code as untrusted until it passes layered checks for reliability, maintainability, and security in the pull request workflow.
• Require traceable remediation for automated fixes Record what the AI changed, why it changed it, and which checks were rerun so automated repair remains auditable.
• Separate approval from test success Do not let passing CI become the only acceptance signal when an agent has proposed and applied the fix.
• Review AI participation in the SDLC Map where AI tools can create, revise, or commit code and classify those touchpoints as governance boundaries, not productivity shortcuts.

Key takeaways

• The central issue is not whether AI can write code, but whether organisations can verify AI-assisted changes before they become trusted production assets.
• A pass in CI does not prove that AI-generated code is safe, maintainable, or explainable, especially when automated tools keep iterating until checks succeed.
• Teams need layered verification, traceable remediation, and clear approval boundaries so AI participation in development does not erode code governance.

Key terms

• AI-native code review: AI-native code review is the use of models and automated reasoning systems to inspect code, identify defects, and propose fixes inside the development workflow. It extends beyond static scanning by attempting to understand context, test outcomes, and intended behaviour, which creates both speed benefits and governance risks.
• Zero Trust Verification Boundary: The set of systems and identities that a programme actively validates before trusting access. If the boundary excludes a major cloud tenant, the programme is only partially operating as Zero Trust, even if the policy language says otherwise.
• Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.
• Verifier coverage: Verifier coverage is the share of real task failures that a training check can detect. High coverage means the verifier closely matches the true objective, while low coverage creates exploitable gaps where a model can score well without actually solving the underlying problem.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and agentic AI identity for practitioners who need to govern non-human access paths. It helps security and identity teams translate governance principles into controls that fit modern software and AI delivery pipelines.