TLDR overview
- AI is changing cyber risk on both sides: adversaries can move from discovery to exploitation faster, while developers and agents can produce more software change than manual review processes can absorb.
- The governance response cannot stop at a policy or an annual audit. Leaders increasingly need to show that secure-development, supply-chain and vulnerability controls operate continuously and can perform under pressure.
- Prevention at the codebase level turns formal governance into an operating model: standards are established centrally, changes are independently verified, release conditions are enforced and evidence is produced as controls operate.
- SonarQube provides a core technical control and evidence layer for this model, helping organizations reduce risk before software reaches production.
On June 22, 2026, the heads of the Five Eyes cyber security agencies issued a direct warning to business and technology leaders: AI is rapidly transforming cyber risk, and long-standing assumptions can become outdated in months rather than years. AI is increasing the speed, scale and sophistication of attacks, shrinking the time between vulnerability discovery and exploitation and making foundational controls more urgent.
The same shift is reshaping software production. Coding agents generate code, introduce dependencies and complete increasingly complex changes at a pace manual review was not designed to match. Attackers can exploit weaknesses faster at the same time as more code requires assurance.
That creates a formal governance problem. A software supply chain policy may define the right intentions, but it cannot by itself show that controls were applied to the changes that shipped. Periodic reviews are equally limited: they capture one moment while developers and agents continue to move changes through development, pull-request and CI/CD workflows.
The Five Eyes statement says leaders must be confident that controls will work under pressure, and that secure-by-design and secure-by-default must become standard practice rather than an aspiration. Acting on that direction means moving prevention into the codebase: translating policy into testable standards, verifying every change independently of its origin, enforcing release conditions and producing evidence as those controls operate.
What do NIS2 and the EU Cyber Resilience Act require for software security?
For organizations in scope, the EU’s NIS2 Directive requires appropriate and proportionate technical, operational and organizational cybersecurity measures. Article 21 specifically includes supply chain security; security in the acquisition, development and maintenance of network and information systems; vulnerability handling and disclosure; and policies and procedures for assessing whether cybersecurity measures are effective. NIS2 operates through national implementing laws, and its precise application depends on an entity’s sector, size, role and jurisdiction.
The EU Cyber Resilience Act goes further for manufacturers of covered products with digital elements. It requires cybersecurity to be addressed in product design, development, production, delivery and maintenance. It also requires vulnerability handling, regular security tests and reviews, due diligence when integrating third-party components and a machine-readable software bill of materials covering at least top-level dependencies. The CRA’s reporting obligations have applied since September 11, 2026; most other provisions apply from December 11, 2027.
These laws are technology-neutral, but they do make the operating expectation increasingly clear: covered organizations must be able to show how cybersecurity measures are implemented and assessed, not merely that a policy exists.
Non-binding government and cyber-agency publications reinforce that direction. Japan’s METI and National Cybersecurity Office connect SBOM use with vulnerability management, supply chain transparency and secure-by-design accountability, while Japan’s 2025 Cybersecurity Strategy identifies SBOMs as part of stronger supply chain risk management. France’s ANSSI supports secure-by-design, auditability, vulnerability management, code review and SBOMs in its open-source policy. CISA and G7 partners have also published non-mandatory minimum SBOM elements for AI systems. These sources do not create a single global rule, but they point toward the same priorities: secure development, component transparency, effective vulnerability handling and evidence that controls operate.
A policy proves intent; Operating evidence proves implementation
Periodic audits capture a point in time. Between audits, code continues to change across multiple workflows. If standards are checked only at the end, or evidence is reconstructed from spreadsheets and screenshots, the record is fragmented and often stale before an auditor sees it.
That creates three practical problems:
- Standards are applied inconsistently across teams, repositories and delivery paths.
- Leaders can only show that controls were documented, but can’t prove that they operated on the changes that shipped.
- Unclear controls for agentic code slow adoption in regulated and risk-sensitive environments.
The stronger position is prevention with evidence generated as controls operate.
How do you implement continuous security controls in a development pipeline?
Sonar describes its broader approach as the Agent Centric Development Cycle, organized around Guide, Verify and Solve. Those stages provide a useful model for continuous code governance.
Guide: Establish and Communicate the Standard
Guide begins by defining the constraints and standards within which agents operate. SonarQube quality profiles encode the organization’s quality and security standards, while quality gates establish the non-negotiable conditions agentic changes must meet.
Sonar Vortex brings those standards and codebase-specific context directly into the agent workflow before work begins. Together, they turn policy into clear, automated boundaries that guide how agents generate and modify code rather than relying on each agent to interpret governance requirements independently.
Verify: Analyze Every Change Independently of Its Origin
Guidance shapes what an agent produces; verification determines whether the result can be trusted. Sonar provides an independent analysis layer that assesses agentic code and dependencies against the defined standards rather than relying on the agent to review its own output.
Verification follows the change through the agentic workflow. Sonar Vortex verifies agent-generated changes within the workflow, while SonarQube independently analyzes the completed change and applies the relevant quality gate. The repository or CI/CD platform can then use that result to block changes that fail to meet the required standard. Configured as a required check, this makes prevention enforceable: agent-produced code cannot progress unless it meets the defined conditions.
Solve: Remediate Findings and Verify the Result
Findings should move through a governed path from detection to verified remediation. Gitar reviews pull requests and can push fixes for identified problems and CI failures. The SonarQube Remediation Agent addresses eligible issues in technical debt and the backlog, verifies each proposed fix through fresh analysis and returns successful fixes as reviewable pull requests.
Hunter Agent strengthens security discovery across the codebase by uncovering access control, business logic and authentication vulnerabilities that conventional analysis may miss. Its findings can then enter the same triage and remediation process as other SonarQube issues.
Together, these capabilities turn findings into preventive action, helping organizations identify, remediate and reverify weaknesses before they persist or spread across the codebase.
How can organizations prove software security controls are working to auditors?
Formal governance requires evidence that controls were established, operated and produced a result. Sonar can provide evidence of:
- How controls were established: configured quality profiles, analysis rules, quality gates and their assignment to projects.
- How controls operated: analysis history, issue records and quality-gate decisions showing that code was assessed against the assigned standard.
- What the controls found and resolved: security findings, dependency and license risks, issue ownership and status, proposed fixes and reanalysis results.
- What can be extracted as evidence: quality profile and quality gate configurations, dependencies, analysis, issue and remediation data, quality gate results, SBOMs and audit logs.
These records show how code-level controls were configured, applied and acted on over time.
Who is accountable for software security when using AI in development?
Using AI does not transfer accountability. The organization remains responsible for the security of the software it develops, operates or places on the market. Controls must therefore be comprehensive, consistently applied and reliable across every code change.
That accountability should translate into clear ownership:
- Security leaders set secure development, dependency and licensing requirements, including risk thresholds, exceptions and escalation paths.
- Engineering and platform leaders translate those requirements into automated analysis, repository controls, pipeline checks and release conditions.
- Product and legal teams determine the regulatory and contractual requirements that apply to each product and market.
- Compliance and assurance teams define the evidence required, test the controls and connect the resulting records to specific obligations.
Begin with the products and applications carrying the greatest regulatory or operational risk, then expand the model across the portfolio.
Measure four things: control coverage, exception management, security outcomes and evidence readiness. Useful indicators include the proportion of changes analyzed before merge, repositories with enforced gates, exception age, recurring findings, remediation time, dependency and SBOM coverage and the time needed to retrieve release evidence.
How is AI changing cybersecurity risk for software development teams?
AI has shortened the distance between software change and cyber risk. Governance must therefore operate where software is created, reviewed and released. Policies and documentation remain essential, but they must be backed by controls that work whenever code changes.
A defensible software supply chain connects governance directly to code delivery. Standards guide how agents work, every change undergoes independent verification, release conditions are enforced, findings move through verified remediation and evidence shows how those controls operated.
SonarQube provides a core technical control and evidence layer for this model. It helps organizations apply consistent quality and security standards, verify code and dependencies, govern release decisions and trace results over time, creating repeatable evidence across developer- and agent-produced code.
Take control of AI-era cyber risk where it enters the software. Explore how SonarQube turns policy into continuous, verifiable controls across every code change.

