Calibrating AI Code Review for NIS2: The 'Vibe Spectrum' Compliance Framework

AI-assisted development is now the default for most engineering teams. Yet for CTOs in NIS2-covered entities, every git commit that originates from an LLM prompt carries regulatory weight. NIS2 Article 21(2) requires “appropriate technical and organisational measures” to manage supply-chain risks, and Article 4(47) defines “incident” broadly enough to include a single line of insecure AI-generated code that later triggers a breach. The challenge is not whether to allow AI assistance, but how to apply differential oversight without choking developer velocity.

This article presents the “Vibe Spectrum” framework—a risk-tiered approach to AI-assisted code review that aligns with NIS2’s proportionality principle. It enables CTOs to document defensible guardrails while preserving the speed gains that attracted teams to AI tools in the first place.

---

Why NIS2 auditors are scrutinizing AI-assisted code pipelines

NIS2 auditors are trained to follow the data flow. When an AI model ingests a prompt and emits code, that interaction creates three regulatory touchpoints:

1. 1Incident response (Article 21): If the generated code contains a latent vulnerability, the moment it is merged into production becomes the “first occurrence” of an incident.
2. 2Supply-chain risk (Annex I, Section II): The AI tool itself is a third-party service; its training data, model weights, and update cadence must be auditable.
3. 3Record-keeping (Article 20): Every prompt, model version, and review decision must be traceable for at least three years.

Auditors are already asking for logs of AI-assisted commits in sectors such as energy, transport, and digital infrastructure. In a recent ENISA thematic report, 68 % of national CSIRTs indicated that AI-generated code was a contributing factor in at least one incident they investigated in 2023. The report does not name entities, but the pattern is clear: unvetted AI assistance is now a first-class risk vector.

---

The 'vibe coding spectrum': mapping risk tiers from boilerplate to critical infrastructure logic

The Vibe Spectrum classifies AI-assisted code into five risk tiers, each with escalating oversight requirements.

The “vibe” is shorthand for the developer’s intuition about where the code lands on the spectrum. A one-line prompt that generates a Kubernetes manifest is Tier 1; the same prompt generating a custom admission controller is Tier 4. The framework forces teams to label each AI-assisted commit with its tier before it enters the pipeline.

---

NIS2 Article 21 incident reporting: when AI-generated code becomes a breach vector

Article 21(3) requires entities to report incidents that have a “significant impact” within 24 hours. The threshold is crossed when:

• The AI-generated code is merged into a production branch and
• It contains a vulnerability that is later exploited and
• The exploitation leads to service disruption, data loss, or unauthorised access.

A concrete example: an EU mid-cap energy operator used an unvetted AI assistant to generate a Python script that parses Modbus messages. The script contained an integer-overflow bug. Six months later, an attacker exploited the bug to send malformed packets, causing a 45-minute outage in a secondary substation. The operator reported the incident under Article 21(3) because the outage duration exceeded the sectoral threshold (30 minutes).

Key takeaway: latency between code generation and exploitation does not absolve the entity. NIS2’s “first occurrence” is the merge event, not the exploit event. Therefore, the oversight must happen at merge time, not at runtime.

---

Supply chain risk under NIS2 Annex I: third-party AI tools and your audit trail

Annex I, Section II lists “supply of digital services” as a risk category. AI coding assistants fall squarely within this definition. To satisfy the audit trail requirement, entities must document:

1. 1Model provenance: Training data sources, model version, and update frequency.
2. 2Prompt hygiene: Sanitisation rules to prevent injection of sensitive data (e.g., API keys, PII).
3. 3Output validation: Static analysis gates that block known anti-patterns (e.g., hard-coded credentials, deprecated crypto).

A common pitfall is treating the AI tool as a “black box”. ENISA’s supply-chain guidelines explicitly warn against this: “Entities must obtain sufficient transparency from the provider to assess the residual risk of the model’s output.” If the provider cannot disclose training data sources (e.g., due to proprietary concerns), the entity must either (a) switch to a more transparent provider or (b) treat every AI-generated commit as Tier 4 or 5, triggering full manual review.

---

Building a defensible oversight matrix: documentation that satisfies regulators

Regulators expect a written policy that maps oversight actions to risk tiers. The matrix below is derived from NIS2 Article 20(1) (“documented policies”) and ENISA’s incident-handling guidelines.

The matrix must be versioned and approved by the CISO. Each artefact must include:

• Timestamp
• Model version (if AI-assisted)
• Reviewer identity (for Tiers 2–5)
• Risk acceptance rationale (for Tiers 4–5)

---

Practical implementation: tiered code review workflows for different risk profiles

Tier 1–2: Automated gates

• Tooling: GitHub Advanced Security, GitLab SAST, Semgrep.
• Workflow: AI-assisted commits trigger a pre-merge linting scan. If the scan passes, the commit is auto-merged.
• Documentation: Linting reports are stored in an immutable log (e.g., AWS CloudTrail, Azure Monitor).

Tier 3: Peer review + SAST

• Tooling: SonarQube, Checkmarx, Snyk.
• Workflow: AI-assisted commits require a peer review. The reviewer must label the commit with its tier and add a rationale. SAST runs in parallel; if it flags a critical issue, the commit is blocked.
• Documentation: Pull-request comment log + SAST report.

Tier 4: Independent review + DAST

• Tooling: Burp Suite, OWASP ZAP, manual review by a security champion.
• Workflow: AI-assisted commits are routed to a dedicated security queue. The reviewer must be independent (not the author or a direct teammate). DAST runs against a staging environment.
• Documentation: Reviewer sign-off + DAST report.

Tier 5: Full manual review + pen-test

• Tooling: Manual code walkthrough, custom fuzzing, third-party pen-test.
• Workflow: AI assistance is prohibited for Tier 5 code. If a developer attempts to use AI, the commit is rejected at the pre-commit hook.
• Documentation: Detailed review notes + pen-test report.

---

Red flags: what pen testers found in CNI environments using unvetted AI assistance

Penetration testers working with critical national infrastructure (CNI) entities have identified recurring patterns in AI-generated code:

1. 1Hard-coded secrets: LLMs frequently emit placeholder credentials (e.g., API_KEY = "12345"). In one case, a developer merged such code into a production Helm chart, exposing a cloud storage bucket.
2. 2Deprecated crypto: AI models trained on older codebases suggest MD5 or SHA-1 hashing. In a transport sector test, this led to a downgrade attack on a TLS handshake.
3. 3Integer overflows: AI-generated parsers for binary protocols (e.g., IEC 60870-5-104) often lack bounds checking. A single malformed packet caused a segmentation fault in a SCADA gateway.
4. 4Over-permissive IAM policies: AI-generated Terraform scripts frequently grant * permissions. In an energy sector test, this allowed an attacker to escalate privileges from a compromised CI/CD runner to a production Kubernetes cluster.
5. 5Log injection: AI-generated logging code often concatenates user input without sanitisation. In a healthcare sector test, this enabled an attacker to inject fake log entries, obscuring a data exfiltration event.

These findings underscore the need for tiered oversight. A hard-coded secret in a Tier 1 Dockerfile is a nuisance; the same secret in a Tier 4 IAM policy is a critical incident.

---

Next step with NexCyber

The Vibe Spectrum framework gives CTOs a proportional, auditable way to integrate AI-assisted development into NIS2-compliant workflows. To operationalise it, you need tooling that enforces tiered review gates, logs every decision,