MHC-09 AI-supported security testing in the pipeline

At a glance

Operational benefit

finds vulnerabilities before delivery — automatically with every change — and removes the attacker's window between a flaw becoming known and its closure.

Policy affected

secure software development policy.

Dependencies

presupposes an automated build and CI pipeline; uses the bills of materials from MHC-02 for component reconciliation.

Effort drivers

depends on the number and structure of the pipelines and the volume of code produced. The actual effort depends on the organization's resources.

Primary metric

time from the availability of a robust remediation for an actively exploited vulnerability (KEV) to the demonstrated remediation or effective compensation. Supplementary effectiveness metrics: share of pipelines with security checking and a pre-merge block, share of findings that reach production despite pipeline checking (escape rate), share of suitable applications with an AI-supported test method in production.

Standards touched (no claim of fulfilment)

ISO/IEC 27002 A.8.28/A.8.29; NIST SP 800-218 (SSDF) and SP 800-218A (AI); OWASP ASVS; C5:2026 OPS-25; CRA Annex I.

Control statement

Security checks run automatically in the development pipeline: code, dependencies and the running application are checked with every change; serious findings block the merge. For suitable applications, AI-supported test methods are additionally deployed — in particular for the dynamic generation of test cases, the detection of multi-stage vulnerability chains, hypothesis-based examination of attack paths, or agentic security analysis. AI-generated code is checked additionally as a risk factor in its own right.

Purpose and threat relevance

In the past there was time to patch between a vulnerability becoming known and a working attack. AI shortens that window drastically — in some cases to hours. Anyone who finds vulnerabilities late is too slow. In addition, AI coding assistants regularly produce insecure patterns (hard-coded credentials, missing input validation, insecure defaults, outdated building blocks). The protective objective is to find and remediate vulnerabilities automatically as early as possible — with every change — before they reach operations.

Effect across frameworks

These are the controls and requirements the MHC acts on. The classification shows how much each control loses its effect under AI-enabled attacks.

All 93 controls in the analysis matrix · All 45 controls in the findings matrix · All 23 requirements of the module family

Maturity path

Initial

SAST/DAST/SCA in the pipeline.

Defined

additional checking of AI-generated code; blocking on serious findings; at least one AI-supported test method demonstrably in production use for suitable applications.

Managed

daily vulnerability scans of the running systems; separate evaluation of AI code; an accelerated path for actively exploited vulnerabilities (KEV).

Measurement and audit evidence

Metric

remediation latency for actively exploited vulnerabilities (KEV) — time from the availability of a robust remediation or effective compensating option to its verified implementation; patch, workaround, compensating control, isolation or replacement count as remediation (guide value: ideally below 24 hours on average); supplementary, the share of pipelines with security checking and a pre-merge block, the escape rate, and the share of suitable applications with an AI-supported test method in production.

Evidence

pipeline configuration, test and blocking logs, evaluation of the AI code findings, penetration test reports.

Evidence logic (following ISO/IEC 27001, Clause 9)

documented? — development policy, pipeline configuration; responsible? — development and product owners; frequency? — with every change, scans daily; tolerance? — no delivery with open serious findings.

Typical mistakes

• The checks run but do not block; serious findings are reported and shipped anyway.
• Only new code is checked, not the systems already running; vulnerabilities disclosed there remain open.
• AI-generated code is treated like hand-written code; its typical weaknesses are not searched for specifically.
• The thresholds are set so strictly that the pipeline blocks constantly; as a consequence the checks are circumvented rather than remediated.

Delimitation and residual risk

Delimitation

concerns automated checking during development; the transparency of components is dealt with by MHC-02, and the detection of active attacks by MHC-05.

Residual risk

automated checks find known patterns, not every novel or logic vulnerability; penetration tests and manual reviews remain necessary in addition.

ISO/IEC 27002:2022

A.8.8 Management of technical vulnerabilities; A.8.25 Secure development life cycle; A.8.26 Application security requirements; A.8.28 Secure coding; A.8.29 Security testing in development and acceptance; A.8.32 Change management.

Framework

C5:2026 OPS-25 (with the sharpening OPS-25.01AS, daily scans); NIST SP 800-218 (SSDF v1.1; Revision 1.2 in draft) and SP 800-218A (secure development for generative AI); OWASP ASVS; CRA Annex I Part II.

Implementation in detail

Organizational and technical implementation, implementation examples and the prioritization within the overall programme are described in the Implementation Guide.

Implementation Guide (PDF)Back to the MHC catalog

Source: MRIS Implementation Guide (ISO/IEC 27001), edition 2.0. License CC BY-SA 4.0. © 2026 Richard Peddi.