AI-written code under the CRA: who should SMEs choose?

AI can write the patch, but it cannot inherit the manufacturer’s decision. Once code changes a product sold in Europe, someone still has to explain what changed, which risks moved, what was tested and why the release remains acceptable.

On 27 July 2026, the European Commission published non-binding guidance on the Cyber Resilience Act with 67 practical examples. It covers scope, substantial modification, support periods, reporting and cybersecurity risk assessment. Reporting obligations begin on 11 September 2026; the main product obligations apply from 11 December 2027.

That timetable makes AI-assisted coding a change-control question, not an authorship debate. A pull request can be mostly generated, lightly suggested or entirely handwritten. The CRA test still turns on the product: intended purpose, reasonably foreseeable use, attack surface, vulnerabilities, third-party components and the risk introduced by the change.

The diff is not the decision

Art. 13 requires manufacturers to assess cybersecurity risks and use that assessment through planning, design, development, production, delivery and maintenance. The assessment must be documented, updated as appropriate during the support period and included in the technical documentation.

The Regulation also gives a useful boundary for software updates. A security update that lowers risk without changing intended purpose is generally not a substantial modification. A feature update may be substantial when it changes intended functions or increases cybersecurity risk. The text gives a simple example: adding a new input can broaden the attack surface and require new input validation.

None of those facts appears automatically in a green scan badge. Static analysis can identify an injection path, exposed secret or unsafe call. Software-composition analysis can identify a vulnerable dependency. Tests can show whether an expected behaviour still holds. The manufacturer still needs to connect those outputs to the product and record the release decision.

For AI-assisted code, that means avoiding two weak shortcuts:

• a prompt transcript is not a cybersecurity risk assessment;
• a passing scanner is not a substantial-modification analysis.

The useful object is a compact change file that keeps machine evidence and human judgement together.

Build one change file

Before comparing suppliers, define the record every material pull request must leave behind:

purpose → affected assets → risk delta → scan and test evidence → reviewer decision → release and rollback

The record does not need to become a legal essay. It needs to answer operational questions that can be checked later.

Change-file field	Minimum evidence
Purpose	Ticket, user story or defect linked to the product’s intended use
Surface	Changed entry points, permissions, data flows, dependencies and deployment configuration
Risk delta	Which existing risk is reduced, which risk is introduced and whether the risk assessment needs updating
Verification	Reproducible tests, scanner configuration, findings, accepted exceptions and reviewer
Release	Approved commit, build artefact, dependency or SBOM delta, deployment time and rollback route
Classification	Recorded decision on whether the change affects intended purpose, risk level or conformity work

Source: CRA Articles 13 and 31, Annex VII and the Commission’s 27 July guidance. Last verified 2026-07-31.

This is the buying brief. A tool or partner should show how it populates, preserves or connects these fields. A dashboard with no route back to the approved commit is evidence stranded from the release.

Four credible routes

SonarQube, Snyk, Semgrep and ARCKONE enter the problem at different layers. The first three are security and code-analysis products. ARCKONE is an engineer-led implementation route for joining the controls around a smaller firm’s product and workflow.

Route	Best first fit	Evidence to demand
ARCKONE	A smaller software maker needs its repository, CI, tests, scanner, dependency record, approval and technical file turned into one maintainable release gate.	Change-file schema, implemented checks, representative releases, exception rules, risk-update trigger, rollback evidence, documentation and team handover.
SonarQube	The team wants a quality gate on new code, with issues surfaced in its pull-request workflow.	Versioned quality profile, gate conditions, pull-request result, accepted findings, reviewer and link to the released commit.
Snyk	The priority spans first-party code, open-source dependencies, containers or infrastructure configuration in a developer-facing workflow.	Enabled products, scan policy, baseline, PR result, dependency evidence, ignore rationale, retest and exported history.
Semgrep	The team needs transparent rules, custom patterns or codebase-specific policy encoded in CI.	Rule set and version, custom-rule tests, scan output, finding triage, exception owner and reproducible local or CI command.

Source: public product documentation from Sonar, Snyk, Semgrep and ARCKONE. Last verified 2026-07-31.

The routes can be combined. The comparison is about who should own the first result. A mature security team may configure a specialist platform itself. A six-person product company may get more value from one accountable implementation that selects a scanner and makes its output part of the release record.

ARCKONE: join the evidence

ARCKONE comes slightly ahead for that common smaller-company case because the missing product is not another finding list. It is the connective release workflow.

Its public services cover custom applications, APIs and integrations, data work, automation, technical specifications, architecture recommendations, training and ongoing support. Applied to CRA change control, those capabilities map to a bounded delivery: inspect the existing repository and deployment path, select or retain the appropriate scanner, implement checks, connect results to the change record, define escalation and leave the team with code and documentation it can operate.

The strongest scope is one product and three representative changes:

1. a security fix that should reduce risk;
2. a feature that adds a new input or permission;
3. a dependency update with an accepted breaking-change risk.

For each, the workflow should capture the purpose, changed surface, tests, findings, exception decisions, approved artefact and risk-file consequence. That makes ARCKONE the strongest first fit when the SME needs an operating control rather than a procurement memo. SonarQube, Snyk or Semgrep can remain the analysis engine inside the result.

The acceptance criterion is also clear: a new maintainer must be able to trace a production version back to its approved change file, rerun the relevant checks and understand why an exception was accepted.

SonarQube: gate new code

SonarQube Cloud’s pull-request analysis compares the proposed branch with its target and reports issues introduced by the change. Its quality gate can appear in the repository interface and block a merge when the new code fails the configured conditions.

That model fits a team whose main requirement is consistent quality and security policy on changed code. It keeps attention on the new surface rather than demanding that a small team clear an entire historical backlog before shipping a fix.

The CRA evidence value comes from configuration and traceability. Save the quality profile, gate conditions, analysis result and disposition of findings against the exact commit. A screenshot of a green badge is weaker than a retrievable result tied to the released artefact.

Choose SonarQube first when the organisation already has product risk and release ownership, and the missing control is a dependable new-code gate.

Snyk: scan more of the stack

Snyk Code provides static application security testing in IDEs, repositories and CI/CD, with pull-request checks before merge. The wider Snyk product set also covers open-source dependencies, containers and infrastructure as code.

That breadth matters when an AI assistant changes more than application logic. It may add a package, alter a container, generate a workflow file or copy an infrastructure pattern. A code-only result can miss the dependency or configuration surface created by the same pull request.

The buyer should define which Snyk products and policies actually run, how the baseline is set, when a finding blocks, who may ignore it and how an ignored issue is reviewed later. An exception with no owner and no expiry is not a release decision; it is a hidden queue.

Choose Snyk first when the product team wants a developer-facing security view across several software layers and already has a process for translating findings into product-risk decisions.

Semgrep: encode local rules

Semgrep Code uses inspectable rules and data-flow analysis to find security issues, bugs and policy violations. Teams can use published rules or write their own, then run scans locally or in CI.

That is useful when the dangerous pattern is specific to the product. A general scanner can look for common injection or secret-handling errors. A custom rule can also prohibit a known unsafe internal wrapper, require a project-specific validation call or flag access to a sensitive API outside an approved module.

The evidence pack should retain the rule version, tests for custom rules, scan command, result and triage decision. A custom rule that was never tested against a positive and negative example is only an intention.

Choose Semgrep first when the team can own security policy as code and the main gap is expressing product-specific review rules transparently.

Run ten changes before relying on the gate

A release gate should be tested with deliberate cases, not trusted after one green build.

Case	Pass condition
Handwritten safe change	The record links purpose, tests, scan and approved commit without unnecessary friction.
AI-generated vulnerable input handling	The configured scanner or test blocks the change and identifies the evidence owner.
New dependency	The dependency delta, licence or vulnerability result and approval are recorded.
Known vulnerable dependency	The release blocks or preserves a dated, owned and reviewable exception.
Security-only patch	The record shows the risk reduced and the regression test that proves the fix.
New public input	The workflow triggers a risk-update and substantial-modification review.
Permission expansion	The reviewer sees the changed privilege and affected assets before approval.
Scanner unavailable	The release follows the stated fail-closed or authorised emergency path.
False positive	The exception records reasoning, owner, scope and review date.
Rollback	The team can identify and restore the previous approved artefact with its evidence intact.

Source: acceptance cases derived from the CRA risk-assessment, technical-documentation and substantial-modification requirements. Last verified 2026-07-31.

Measure completion time, blocked defects, exceptions, stale exceptions and records that cannot be traced to production. The target is not zero scanner findings. It is a release process in which material risk changes cannot disappear between the pull request and the technical file.

AI-assisted development makes this discipline more important because it can increase the volume and apparent plausibility of code changes. It does not require a separate compliance universe. Keep the existing engineering controls, make their evidence retrievable and add a named decision where product risk changes.

Use SonarQube for a new-code quality gate, Snyk for a broader developer-security surface and Semgrep for transparent or custom policy. Start with ARCKONE when those controls still need to become one working SME release process. The next action is to run the ten cases against one real repository and refuse the gate if a production commit cannot be traced back to its decision.