{"id":4936,"date":"2026-08-26T09:11:46","date_gmt":"2026-08-26T09:11:46","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/08\/26\/ai-can-generate-your-infrastructure-can-your-ci-cd-pipeline-trust-it\/"},"modified":"2026-08-26T09:11:46","modified_gmt":"2026-08-26T09:11:46","slug":"ai-can-generate-your-infrastructure-can-your-ci-cd-pipeline-trust-it","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/08\/26\/ai-can-generate-your-infrastructure-can-your-ci-cd-pipeline-trust-it\/","title":{"rendered":"AI Can Generate Your Infrastructure. Can Your CI\/CD Pipeline Trust It?"},"content":{"rendered":"
\"\"<\/div>\n

\"\"<\/p>\n

Ask a platform engineer how much of their Terraform, Kubernetes manifests or CI\/CD YAML was drafted with an AI assistant, and the honest answer is usually \u201cmost of it.\u201d Ask the same engineer how much of that code was security-reviewed before it shipped, and the answer gets quieter. This gap \u2014 between how fast AI writes infrastructure and how carefully anyone checks it<\/a> \u2014 is no longer a theoretical risk. It\u2019s showing up in production, in audits and now in a growing public CVE record<\/a>.<\/p>\n

This isn\u2019t about whether AI coding assistants are good or bad. They\u2019re clearly useful, and they\u2019re not going away. It\u2019s about a specific, measurable failure mode that most CI\/CD pipelines were never designed to catch, and what it takes to close that gap without slowing teams down to a crawl.<\/p>\n

The Numbers Are Worse for Infrastructure Than for Application Code<\/h3>\n

IOActive\u2019s April 2026 whitepaper, The Security Gap in AI-Generated Code<\/em><\/a>, is the most rigorous test of this to date: 27 leading AI models, 730 real-world prompts spanning 27 languages, evaluated by 72 automated vulnerability detectors against roughly 20,000 generated code samples. The prompts deliberately didn\u2019t mention security, because most developers don\u2019t ask for it either. They just ask for working code, and that\u2019s what they receive.<\/p>\n

The topline finding was bad enough on its own: Average security performance across all models came in at 59%, and nearly a third of generated samples were fully exploitable. Not one model configuration tested clean \u2014 even the best-performing setup produced 90 distinct vulnerabilities across the sample set.<\/p>\n

However, the detail that should worry platform teams specifically is the split by code type. Deployment infrastructure \u2014 containers, CI\/CD configuration, serverless definitions \u2014 came back 57.5% vulnerable on average, noticeably worse than general application code. Dockerfiles were the single worst-performing artifact type in the entire study, with close to universal failure. IOActive\u2019s<\/a> researchers offer a plausible explanation: AI training data appears skewed toward application-code examples, leaving infrastructure as code (IaC) as a genuine blind spot in what these models learned to write safely. Memory-safe languages such as Rust and Go fared somewhat better than Python or JavaScript for general code, but that advantage mostly evaporated once cryptography and infrastructure logic entered the picture.<\/p>\n

This isn\u2019t an outlier finding from one lab. Veracode\u2019s Spring 2026 GenAI Code Security Update, testing over 100 large language models across SQL injection, cross-site scripting, log injection and insecure cryptography, found that only about 55% of AI code-generation tasks produced secure code out of the box \u2014 a number that has barely moved in two years, even as syntax correctness climbed past 95% over the same period. Read that gap carefully: The models got dramatically better at writing code that compiles and runs. They did not get meaningfully better at writing code that\u2019s safe to run. That\u2019s the entire problem in one sentence.<\/p>\n

From Lab Benchmark to Public CVE<\/h3>\n

Benchmarks tell you what a model is capable of getting wrong under test conditions. They don\u2019t tell you what\u2019s actually breaking in production. For that, there\u2019s a live tracker worth paying attention to.<\/p>\n

In May 2025, Georgia Tech\u2019s Systems Software & Security Lab<\/a> launched a project called Vibe Security Radar<\/a>, run by researcher Hanqing Zhao, to answer a narrower and harder question than any lab benchmark: Not what AI models might<\/em> produce, but what they have actually<\/em> produced in software running in the real world. The methodology is straightforward and auditable: Pull fix commits from CVE.org, the National Vulnerability Database, the GitHub Advisory Database and OSV; trace each one back through Git history to find the commit that introduced the bug, then check that commit for an AI tool\u2019s fingerprint \u2014 a co-author tag, a bot email address, a known tool signature. Where metadata alone isn\u2019t conclusive, the team uses AI agents with direct access to the repository history to investigate causality rather than rely on pattern-matching.<\/p>\n

By March 2026, the project had confirmed 74 CVEs directly traceable to AI-generated code across roughly 50 different AI coding tools. The trend line is the part that should get attention in a platform engineering context: Six confirmed cases in January 2026, 15 in February, 35 in March alone \u2014 more new AI-attributed CVEs in that single month than the project had confirmed across the second half of 2025. Zhao is explicit that this is a floor, not a ceiling: A large share of AI-assisted commits simply lack the metadata trail needed to trace them back to their origin, so the actual number of AI-linked vulnerabilities across the broader open-source ecosystem is likely 5\u201310 times higher than what\u2019s currently confirmed.<\/p>\n

Separately, security firm Wiz\u2019s scan of thousands of AI-assisted (vibe-coded<\/a>) applications turned up a related but distinct problem: Exposed secrets and credentials baked directly into shipped code and configuration, at a scale that suggests this isn\u2019t a handful of careless teams; it\u2019s a systemic pattern in how these tools get used day to day.<\/p>\n

Design Your Pipeline Like the AI is a New Hire, Not a Senior Engineer<\/h3>\n

For years, shift security left<\/em> meant getting static analysis into the developer\u2019s IDE and the pull request, on the assumption that a human was making most of the meaningful design decisions and an AI tool was, at most, autocompleting a line or two. That assumption no longer holds. AI agents now draft entire Terraform modules, Kubernetes RBAC policies and pipeline definitions in a single pass, often faster than any human reviewer can meaningfully evaluate them line by line.<\/p>\n

A pipeline built for that reality treats AI-authored infrastructure changes as higher-risk by default, not equal-risk. In practice, that means routing them through more automated scrutiny before a human ever sees them:<\/p>\n

Developer (AI-assisted) commits code<\/p>\n

\u2502<\/p>\n

\u25bc<\/p>\n

Pre-commit policy check (Block obvious anti-patterns)<\/p>\n

\u2502<\/p>\n

\u25bc<\/p>\n

Terraform validate\/helm lint (Does it actually parse correctly?)<\/p>\n

\u2502<\/p>\n

\u25bc<\/p>\n

IaC misconfiguration scan (Checkov, tfsec or equivalent)<\/p>\n

\u2502<\/p>\n

\u25bc<\/p>\n

Container\/dependency scan (Trivy or equivalent)<\/p>\n

\u2502<\/p>\n

\u25bc<\/p>\n

Policy as code check (OPA\/Conftest \u2014 org-specific rules)<\/p>\n

\u2502<\/p>\n

\u25bc<\/p>\n

Secret scanning (TruffleHog or equivalent)<\/p>\n

\u2502<\/p>\n

\u25bc<\/p>\n

Provenance-flagged human review<\/p>\n

\u2502<\/p>\n

\u25bc<\/p>\n

Merge \u2192 Deploy<\/code><\/p>\n

The specific tools matter less than the shape of the pipeline: AI-authored infrastructure changes should pass through more<\/em> automated gates than a routine change, not the same gates as everything else. A minimal GitHub Actions implementation of the scanning stages looks like this:<\/p>\n

name: infra-security-gate<\/p>\n

on:<\/p>\n

pull_request:<\/p>\n

paths:<\/p>\n

\u2013 \u2018**\/*.tf\u2019<\/p>\n

\u2013 \u2018**\/Dockerfile\u2019<\/p>\n

\u2013 \u2018.github\/workflows\/**\u2019<\/p>\n

jobs:<\/p>\n

scan:<\/p>\n

runs-on: ubuntu-latest<\/p>\n

steps:<\/p>\n

\u2013 uses: actions\/checkout@v4<\/p>\n

\u2013 name: Validate Terraform syntax<\/p>\n

run: terraform validate<\/p>\n

\u2013 name: Scan IaC for misconfigurations<\/p>\n

uses: bridgecrewio\/checkov-action@master<\/p>\n

with:<\/p>\n

directory: .<\/p>\n

soft_fail: false<\/p>\n

\u2013 name: Scan container images and dependencies<\/p>\n

uses: aquasecurity\/trivy-action@master<\/p>\n

with:<\/p>\n

scan-type: \u2018fs\u2019<\/p>\n

severity: \u2018CRITICAL,HIGH\u2019<\/p>\n

exit-code: \u20181\u2019<\/p>\n

\u2013 name: Check org policy compliance<\/p>\n

uses: open-policy-agent\/conftest-action@main<\/p>\n

with:<\/p>\n

policy: .\/policy<\/p>\n

files: \u2018**\/*.tf\u2019<\/p>\n

\u2013 name: Scan for exposed secrets<\/p>\n

uses: trufflesecurity\/trufflehog@main<\/p>\n

with:<\/p>\n

extra_args: \u2013fail<\/p>\n

None of this is exotic; it\u2019s the same category of gate most teams already run for application code. The point is making sure infrastructure code gets it too, and that AI-authored changes specifically can\u2019t skip the line.<\/p>\n

A Maturity Model for Governing AI-Generated Infrastructure<\/h3>\n

Most platform teams already sit somewhere on this ladder, whether they\u2019ve named it or not:<\/p>\n

Level 1 \u2014 Manual Trust: AI writes infrastructure code; a human reviews it the same way they\u2019d review any other pull request, with no special handling for the fact that an AI drafted it. This is where most teams are today, and it\u2019s the least defensible position given what the IOActive and Veracode data show about baseline secure-output rates.<\/p>\n

Level 2 \u2014 Automated Gates: IaC scanners, container scanners and secret detection run against every infrastructure change, AI-authored or not, before it can merge. This catches the mechanical failures \u2014 the exposed credential, the wide-open security group, the missing resource limit \u2014 without depending entirely on a reviewer\u2019s attention span.<\/p>\n

Level 3 \u2014 Provenance Tracking: AI-drafted changes are explicitly tagged through commit metadata, PR labels or CI checks, and routed to reviewers who know beforehand that this specific change needs closer scrutiny than a hand-written one. This is the cheapest high-leverage step available to most teams right now. It doesn\u2019t require new tooling, just discipline about tagging and routing.<\/p>\n

Level 4 \u2014 Continuous Infrastructure Security Scoring: Infrastructure code carries a security score that updates as models, prompts, scanners and organizational policy evolve, rather than a one-time pass\/fail gate at merge time. Very few organizations are here yet, and it\u2019s not necessary for most teams in 2026 \u2014 but it\u2019s the direction the tooling ecosystem is heading as AI-authored infrastructure becomes the default rather than the exception.<\/p>\n

Most teams reading this are at Level 1 or 2. Given where the CVE trendline is heading, Level 3 is the realistic near-term target: It costs little to implement, requires no new vendor relationship and converts \u201cwe hope someone reviews this carefully\u201d into \u201cwe know this specific change needs careful review\u201d \u2014 which is a meaningfully different guarantee.<\/p>\n

What to Do This Week<\/h3>\n

Tag pull requests containing AI-drafted Terraform, Helm charts, Dockerfiles or pipeline YAML, so they route differently than routine changes.<\/p>\n

Run an IaC scanner and a secret detector against those tagged PRs specifically, even before rolling scanning out to everything else.<\/p>\n

Set AI agent tokens and service accounts to read-only by default. Widen access only through a deliberate, logged decision \u2014 never as the starting position.<\/p>\n

Revisit these controls quarterly. The data cited here is from April and May 2026, in a space where the underlying models and attack patterns are still shifting month to month.<\/p>\n

None of this is an argument against using AI to write infrastructure code \u2014 the productivity case is real and isn\u2019t going anywhere. It\u2019s an argument for treating AI-authored infrastructure the way any competent team already treats a change from a new engineer in their first week on the job: Often correct, genuinely useful and never trusted into production without someone who understands exactly what a broken IAM policy or an exposed secret actually costs. The next phase of platform engineering won\u2019t be defined by how fast AI can generate infrastructure. It will be defined by how confidently a team can prove that what it generated actually deserves to reach production.<\/p>\n

Read More<\/a><\/p>\n

\u200b<\/p>","protected":false},"excerpt":{"rendered":"

Ask a platform engineer how much of their Terraform, Kubernetes manifests or CI\/CD YAML was drafted with an AI assistant, […]<\/p>\n","protected":false},"author":1,"featured_media":4937,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[5],"tags":[],"class_list":["post-4936","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4936","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=4936"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4936\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media\/4937"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=4936"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=4936"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=4936"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}