Jason Miller / Securing AI-Generated Code in CI/CD Pipelines

Securing the Sentinel: DevSecOps for AI-Generated Code

Harness AI’s development speed without the security risks. This guide provides a strategic framework for securing your CI/CD pipeline against threats from AI-generated code, enabling safe innovation.

Executive Summary

The integration of Artificial Intelligence (AI) into software development, particularly through code generation assistants, is revolutionizing developer productivity and accelerating delivery cycles. However, this technological leap introduces a new and potent vector for vulnerability injection, fundamentally altering the application security landscape. While AI assistants excel at pattern replication and code scaffolding, they are systematically introducing security flaws at a rate that outpaces traditional security validation methods. This report provides an exhaustive analysis of this emergent threat and outlines a multi-layered, defense-in-depth framework for securing AI-generated code within a Continuous Integration/Continuous Deployment (CI/CD) pipeline.

The core finding of this analysis is that organizations must adopt a “distrust and verify” posture toward all AI-generated code. The risks are not merely theoretical; empirical studies consistently demonstrate that 30-50% of code produced by AI assistants contains security vulnerabilities, ranging from classic injection flaws to novel software supply chain attacks like “package hallucination.” This is compounded by a documented “automation bias,” where developers place undue trust in AI outputs, reducing the rigor of manual code reviews. The result is a multiplicative increase in the net risk of a vulnerability being introduced and reaching production.

A successful mitigation strategy cannot rely on a single tool or process. It requires a holistic DevSecOps framework that addresses the entire software development lifecycle (SDLC). This report details a four-layer defense strategy:

1. The Developer’s Workbench: Empowering developers through education on AI-specific risks, training in secure prompt engineering, and reinforcing the indispensable role of rigorous human code review.
2. The CI Pipeline: Implementing a gauntlet of automated security gates, including AI-aware Static Application Security Testing (SAST), Software Composition Analysis (SCA) to combat supply chain threats, comprehensive secrets scanning, and Infrastructure as Code (IaC) validation.
3. The CD Pipeline: Enforcing high-level organizational governance through Policy as Code (PaC) to ensure compliance with cost, security, and regulatory mandates that AI models cannot comprehend.
4. The Production Environment: Deploying runtime defenses like Application Detection and Response (ADR) as a final safety net to identify and block the exploitation of logical flaws and zero-day vulnerabilities missed by pre-deployment checks.

Ultimately, securing AI-generated code is not merely a tooling problem but a strategic imperative. It demands a paradigm shift that integrates new technologies, adapts existing processes, and cultivates a culture of critical scrutiny. This report provides the strategic guidance and tactical recommendations necessary for Chief Information Security Officers (CISOs), DevSecOps leaders, and security architects to navigate this new terrain, harnessing the power of AI without compromising the security and integrity of their software.

Section 1: The Unseen Risks of AI-Assisted Development

The adoption of AI coding assistants represents a fundamental shift in software development, but it also introduces a new and complex threat landscape. This section provides a data-driven analysis of this landscape, moving from the well-understood vulnerabilities that AI systematically injects into code to the novel, model-specific attack vectors that target the development process itself.

1.1 The AI Code Vulnerability Landscape: A Quantitative Analysis

The assertion that AI-generated code is insecure is not speculative; it is a conclusion supported by a growing body of empirical evidence. Multiple independent studies have consistently quantified the high prevalence of security flaws in the output of leading Large Language Models (LLMs), establishing a clear and present risk for any organization adopting these tools. The root cause is systemic: LLMs are trained on vast, unsanitized datasets of public source code from repositories like GitHub, which are known to contain buggy and insecure code.1 The models learn and replicate these insecure patterns, effectively functioning as high-speed vulnerability injection engines.

Prevalence of Vulnerabilities

The scale of the problem is significant. Analysis across different models and contexts reveals a consistent pattern of risk:

• A formal analysis by the FormAI project, which generated over 112,000 C programs with GPT-3.5, found that a staggering 51.24% of the programs contained at least one security vulnerability.7
• Research conducted at New York University evaluated 1,692 programs generated by GitHub Copilot and found that approximately 40% of its outputs were buggy or exploitable.7
• A comprehensive evaluation of five different LLMs by the Center for Security and Emerging Technology (CSET) at Georgetown University concluded that almost half of the code snippets produced contained bugs that were often impactful and could potentially lead to malicious exploitation.8
• More recent evaluations across a diverse range of models, including those from OpenAI and Meta, report that roughly one out of every three code completions is vulnerable, a figure that highlights the systemic nature of the issue.7

Common Vulnerability Examples (CWE/OWASP)

These statistics are not abstract; they manifest as well-understood and exploitable code-level flaws. AI models frequently generate code with classic vulnerabilities that security professionals have worked for decades to eradicate.

• SQL Injection (CWE-89): AI assistants often fail to use parameterized queries, instead opting for direct string concatenation, which is a textbook cause of SQL injection. The following AI-generated Java code for user authentication demonstrates this flaw perfectly 1:
  Java
  // AI-generated code for user authentication
  public boolean authenticateUser(String username, String password) {
  String query = “SELECT * FROM users WHERE username=’” + username + “’ AND password=’” + password + “’”;
  ResultSet result = statement.executeQuery(query);
  return result.next();
  }

  In this example, user-controlled username and password inputs are concatenated directly into the SQL query, allowing an attacker to bypass authentication with an input like ’ OR ‘1’=‘1.

• Cross-Site Scripting (XSS, CWE-79): AI-generated front-end code often neglects critical security controls for handling client-side data. This JavaScript snippet for storing user preferences in a cookie is a prime example 1:
  JavaScript
  // AI-generated code for storing user preferences
  function saveUserPreferences(userId, preferences) {
  document.cookie = `user_${userId}_prefs=${JSON.stringify(preferences)}`;
  console.log(“User preferences saved!”);
  }

  The code fails to set the HttpOnly, Secure, and SameSite flags on the cookie. This omission leaves the cookie vulnerable to theft via XSS attacks and susceptible to Cross-Site Request Forgery (CSRF), as it can be accessed by client-side scripts and sent in cross-site requests.

• Path Traversal and Insecure File Uploads (CWE-22, CWE-434): Server-side code generated by AI frequently lacks necessary input validation, especially for file operations. This Python Flask example for handling file uploads contains multiple critical flaws 1:
  Python
  # AI-generated code for handling file uploads
  @app.route(’/upload’, methods=)
  def upload_file():
  file = request.files[‘file’]
  filename = file.filename
  file.save(os.path.join(’/uploads’, filename))
  return ‘File uploaded successfully!’

  This code blindly trusts the user-supplied filename. An attacker could provide a filename like ../../etc/passwd to overwrite critical system files (Path Traversal). Furthermore, the lack of file type or size validation exposes the application to malicious script uploads and Denial-of-Service (DoS) attacks.

• Memory Safety Bugs (CWE-119, CWE-120): In low-level languages like C, AI models are prone to generating code with classic memory management errors, such as buffer overflows, array bounds violations, and null pointer dereferences.7 These vulnerabilities can lead to crashes, data corruption, and remote code execution.

• Hardcoded Secrets (CWE-798): A frequent and dangerous practice observed in AI-generated code is the embedding of credentials, API keys, or other secrets directly within the source code.7 This creates a severe risk of exposure if the code is committed to a version control system.

1.2 Beyond Code Flaws: The OWASP Top 10 for LLM Applications

Securing the use of AI in development requires looking beyond the generated code itself. The interaction with the LLM represents a new and distinct attack surface. The OWASP Foundation has identified the most critical risks in this domain in its “Top 10 for Large Language Model Applications.” Several of these risks have direct and severe implications for a DevSecOps pipeline.

• LLM01: Prompt Injection: This is a critical vulnerability where an attacker crafts a malicious prompt to hijack the LLM’s output.10 In a development context, an attacker could provide a user with a seemingly innocuous text block to paste into their IDE’s AI assistant. This text could contain hidden instructions, causing the AI to generate code with a backdoor, leak sensitive information from the developer’s session context, or perform other unauthorized actions.7 The AI becomes an unwitting Trojan horse, executing the attacker’s will within the trusted development environment.
• LLM02: Insecure Output Handling: This risk arises when an application fails to properly validate, sanitize, or handle the output from an LLM before passing it to downstream systems.10 For a CI/CD pipeline, this is a direct threat. For example, an LLM might be used to automatically generate configuration files (e.g., Kubernetes YAML) or test scripts. If the LLM’s output is not rigorously validated, it could contain malicious commands or configurations, leading to vulnerabilities like Server-Side Request Forgery (SSRF) or Remote Code Execution (RCE) during the build, test, or deployment stages.12
• LLM03: Training Data Poisoning: This is a sophisticated supply chain attack where adversaries intentionally contaminate an LLM’s training data with biased or malicious examples.2 A poisoned model could be manipulated to systematically suggest insecure coding patterns, recommend vulnerable open-source libraries, or generate code with hidden backdoors whenever it encounters specific triggers.7 This attack is particularly insidious because it corrupts the AI tool at its source, making the vulnerabilities it produces appear as normal, trusted output.
• LLM05: Supply Chain Vulnerabilities: This category encompasses traditional software supply chain risks as they apply to the components used to build and deploy LLM-powered applications.10 This includes vulnerabilities in the machine learning frameworks, libraries, and pre-trained models that organizations might use. This risk is directly linked to the threat of package hallucinations, where the AI itself becomes a vector for supply chain attacks.
• LLM06: Sensitive Information Disclosure: LLMs can inadvertently reveal confidential data they were trained on or leak sensitive information provided within a prompt’s context window.10 In a CI/CD pipeline, developers might paste proprietary code snippets or configuration details into a prompt to get assistance. This data could then be retained by the model provider or potentially be exposed to other users, leading to intellectual property theft or the leakage of secrets.

1.3 The Software Supply Chain Under Siege: Package Hallucinations and Poisoned Models

AI coding assistants have introduced a novel and highly effective attack vector against the software supply chain through a phenomenon known as “package hallucination.” This vulnerability allows attackers to weaponize the developer’s trust in the AI tool to distribute malware.

Package Hallucination and the “Slopsquatting” Attack

Package hallucination occurs when an AI assistant confidently suggests code that references a software package or library that does not exist in any official repository.14 This is not a rare anomaly; studies have shown that open-source LLMs can have hallucination rates exceeding 21%.15

This flaw has given rise to a new attack called “slopsquatting,” which is more targeted and predictable than traditional typosquatting. The attack chain is dangerously simple and effective 15:

1. Reconnaissance: An attacker probes various LLMs with common development queries to identify hallucinated package names that are frequently and consistently recommended. Because LLM outputs can be semi-deterministic, these phantom packages are often predictable.19
2. Preemption: The attacker registers a malicious package under the identified hallucinated name on a public repository like PyPI (for Python) or npm (for JavaScript).
3. Recommendation: An unsuspecting developer, working on a task, receives a code suggestion from their AI assistant that includes an import statement and an instruction to install the now-malicious package.
4. Execution: Trusting the AI’s output, the developer runs the installation command (pip install or npm install). The package manager successfully finds the attacker’s package and executes its installation script, which contains malware. This compromises the developer’s machine, the CI/CD environment, or injects malicious code directly into the application.

The viability of this attack was demonstrated in the “huggingface-cli” incident. A security researcher noticed an AI repeatedly suggesting this non-existent package, registered a harmless placeholder on PyPI, and observed thousands of downloads within days from developers at major tech companies who had blindly trusted the AI’s suggestion.15

Poisoned and Malicious Models

A related and equally severe threat involves the direct compromise of pre-trained AI models, which are often shared on public hubs.13 Attackers can embed malicious code within the model files themselves, particularly when using unsafe serialization formats like Python’s

pickle. When a developer or a CI/CD pipeline downloads and loads this tainted model, the embedded malicious code executes, leading to a full system compromise.13 This attack bypasses source code scanning entirely, as the malicious payload is hidden within the binary model artifact.

1.4 The Human Factor: Automation Bias and the Erosion of Scrutiny

Perhaps the most insidious risk introduced by AI coding assistants is not technical but psychological. The efficiency and authoritative nature of AI tools foster an “automation bias,” a cognitive tendency for humans to over-trust the output of automated systems. This leads to a dangerous erosion of the critical scrutiny that is foundational to secure software development.

• Over-reliance and the Comprehension Gap (OWASP LLM09): Developers, particularly those who are less experienced, may accept and integrate AI-generated code without fully understanding its logic or security implications.1 This creates a “comprehension gap,” where the deployed codebase becomes a black box that the team cannot effectively maintain or secure.1
• Diminished Responsibility and Review: Research indicates that developers often feel less personal responsibility for code generated by an AI and consequently spend less time reviewing it.23 This leads to a significant reduction in the effectiveness of manual code review, which has traditionally been a critical defense against subtle bugs and logic flaws. Studies have shown that developers using AI tools can, in some cases, write
  more insecure code than those working without them, precisely because this critical human validation step is weakened.23
• The Illusion of Security: A deeply concerning trend is the growing misconception that AI-generated code is inherently more secure than human-written code. A 2023 industry survey revealed that 76% of technology workers held this belief.14 This false confidence is a direct result of automation bias and creates a cultural environment where questioning the AI’s output is discouraged, and insecure code is more likely to be accepted without challenge. The appropriate mental model is not to treat the AI as a senior expert but as an untrusted, albeit very fast, junior developer whose work requires rigorous verification.7

Section 2: A Multi-Layered Defense Strategy for the AI-Powered CI/CD Pipeline

Given the systemic nature of vulnerabilities introduced by AI, a single security control is insufficient. A robust defense requires a multi-layered strategy that integrates security into every stage of the CI/CD pipeline, from the developer’s local environment to the production runtime. This defense-in-depth approach assumes that vulnerabilities may be introduced at any point and that each subsequent layer serves as a backstop for failures in the previous one. This section details four critical layers of protection.

2.1 Layer 1: The Developer’s Workbench - Proactive Security at the Source

The most efficient and cost-effective point to address a security vulnerability is at its origin: the developer’s integrated development environment (IDE). This “shift-left” layer focuses on preventing insecure code from being committed in the first place by equipping developers with the necessary knowledge, practices, and real-time feedback mechanisms.

2.1.1 Secure Prompt Engineering

The quality and security of AI-generated code are directly influenced by the quality of the prompts provided. Secure prompt engineering is the practice of crafting instructions that explicitly guide the AI model toward secure and robust outputs. It is the first and most fundamental line of defense.

• Principles of Secure Prompting: The core principles are specificity, context, and constraints.26 Vague prompts yield generic and often insecure code. A Stanford study found that well-structured prompts increased the generation of correct code by 71%.27 This principle extends directly to security.
• Actionable Techniques:
  • Explicit Security Requirements: Developers must learn to embed security constraints directly into their prompts. Instead of asking, “Write a Python function to upload a file,” a more secure prompt would be, “Write a Python Flask function to securely handle file uploads. It must prevent path traversal attacks, validate that the file type is either PNG or JPEG, and enforce a maximum file size of 5 MB”.1
  • Chain-of-Thought Prompting: This technique forces the AI to reason about its process before generating code, which can lead to more secure outcomes. For example, a developer could prompt: “I need a user authentication function. First, list the common security risks associated with authentication, such as SQL injection and weak password hashing. Second, describe the best practices to mitigate these risks. Third, write a Python function that implements these secure practices using parameterized queries and the Argon2 hashing algorithm”.27
  • Contextual Priming with Secure Examples: Providing the AI with examples of secure code or snippets from trusted security documentation (like OWASP guidelines) within the prompt can significantly improve the security of its output. This “primes” the model to follow established secure patterns.27

2.1.2 The Indispensable Human Review

Despite advances in AI, human oversight remains the most critical security control. AI models lack true contextual understanding of a project’s business logic, architecture, and specific threat model. Therefore, all AI-generated code must be treated as untrusted and subjected to a rigorous manual review process.9

• Focus of AI Code Reviews: Human reviewers should not waste time on syntax or boilerplate, which AI handles well. Instead, their expertise is best applied to areas where AI is weak:
  • Business Logic Flaws: Does the code correctly implement the business requirement in a secure manner?
  • Contextual Security: Is the code secure within the context of the entire application and its deployment environment?
  • Edge Cases and Error Handling: Has the AI adequately handled all potential failure modes and edge cases without leaking sensitive information? 24
• Adopting a “Zero-Trust” Mindset: The most effective practice is to treat AI-generated code as a first draft from an unproven junior developer. It must be read, understood, and validated by a human developer before it is accepted.7 This approach directly counters the dangerous effects of automation bias.

2.1.3 Developer Education and AI Security Training

To effectively engineer secure prompts and conduct meaningful code reviews, developers must be educated on the unique risks posed by AI.

• Essential Training Curriculum: Organizations must implement mandatory training programs that cover:
  • The OWASP Top 10 for LLM Applications: To understand the new attack surface related to the AI models themselves.29
  • Common AI-Generated Vulnerabilities: Training developers to recognize the specific insecure patterns that AI assistants frequently produce (e.g., direct string concatenation in queries, missing input validation).1
  • Secure Prompt Engineering: Formal training on the techniques described above to guide AI toward better outputs.
• Cultural Shift: The ultimate goal of this training is to instill a culture of healthy skepticism. Developers should be empowered and encouraged to question, validate, and, when necessary, reject AI-generated suggestions. The organizational mindset must shift from “trust but verify” to a more secure posture of “distrust and verify” for all AI-generated assets.9

2.2 Layer 2: The CI Pipeline - Automated Gates and Guardrails

The Continuous Integration (CI) pipeline serves as the central enforcement point for an organization’s security policies. Each time a developer commits code—whether human- or AI-written—it must pass through a series of automated security checks. These gates act as a non-negotiable quality and security baseline, preventing vulnerabilities from being merged into the main codebase. The high velocity of AI-generated code makes this automated gauntlet more critical than ever.

A comprehensive security strategy for AI-generated assets requires a “triad” of scanning capabilities—SAST, SCA, and IaC scanning—working in concert. AI generates output across all these domains: application logic, dependency manifests, and infrastructure definitions. A vulnerability in any one of these areas can compromise the entire system. Relying on only one or two scanning types creates predictable blind spots that attackers can exploit. Therefore, organizations must implement a holistic scanning platform or a tightly integrated set of tools that cover all three facets of AI-generated output.

2.2.1 Static Application Security Testing (SAST)

SAST tools analyze application source code for security vulnerabilities without executing it. This is the first and most critical automated check for the code itself.31 Modern SAST tools are becoming increasingly “AI-aware,” leveraging machine learning to improve detection accuracy, reduce false positives, and provide context-aware remediation suggestions that accelerate the fix process.31

• Key Tooling: Leading SAST solutions include Checkmarx 23, SonarQube 36, and Snyk Code.38 These tools integrate directly into the CI pipeline and often provide real-time feedback in the developer’s IDE, catching issues as code is written.
• Configuration for AI-Generated Code:
  • SonarQube AI Code Assurance: SonarQube offers a specific feature set for managing AI-generated code. By labeling a project as “Contains AI-generated code,” organizations can apply a stricter, dedicated quality gate called “Sonar way for AI Code.” This gate enforces more rigorous conditions on new code, such as requiring zero new issues, a minimum of 80% test coverage, and low code duplication. This ensures that the higher volume of code produced by AI is held to a higher standard of quality and security.40
  • Custom Rules: A crucial capability is the ability to define custom rules. As teams identify recurring insecure patterns or anti-patterns specific to the LLMs they use, they can codify these checks. For instance, a custom rule in Snyk or SonarQube could be written to flag any use of a particular library function that the organization’s AI model consistently implements in an insecure way.47 This allows the SAST tool to be tailored to the specific risk profile of the organization’s AI usage.

2.2.2 Software Composition Analysis (SCA)

SCA tools identify all open-source and third-party components within an application, checking them against databases of known vulnerabilities (CVEs) and ensuring compliance with licensing policies. In the age of AI, SCA is the primary defense against software supply chain attacks, particularly those stemming from package hallucinations.56

• Key Tooling: Prominent SCA tools include Snyk Open Source 38, Mend.io 58, and SCANOSS.57 These tools must be integrated as a blocking step in the CI pipeline, failing the build if a high-severity vulnerability is detected in a dependency.
• Mitigating Package Hallucinations: To counter the threat of slopsquatting, SCA workflows must be enhanced. The pipeline should not only scan for known CVEs but also perform real-time validation of every new dependency introduced in a commit. This involves checking the package’s existence, age, download velocity, and reputation against trusted registries. This process should be coupled with a strict organizational policy of using an internal, curated package repository or an allowlist of vetted dependencies. Any package suggested by an AI that is not on this list should be automatically blocked by the CI pipeline pending a manual security review.15

2.2.3 Secrets Scanning

AI models, trained on public code, are notoriously prone to generating code that includes hardcoded secrets like API keys, database credentials, and private tokens.6 The accidental commitment of these secrets to version control is a critical risk that must be mitigated automatically.

• Key Tooling: Gitleaks is a powerful and widely adopted open-source tool for detecting secrets in Git repositories.60 It can be integrated as a pre-commit hook to prevent secrets from being committed locally, and more importantly, as a blocking step in the CI pipeline using integrations like the official Gitleaks GitHub Action.65
• Custom Rules for AI-Specific Secrets: Gitleaks operates on a set of regular expressions defined in a configuration file (e.g., .gitleaks.toml). While its default ruleset is comprehensive, organizations should create custom rules to detect patterns specific to their internal tools or novel secret formats that their AI assistants might generate. This ensures the scanner can adapt to new and unforeseen leakage patterns.60

2.2.4 Infrastructure as Code (IaC) Scanning

AI assistants are increasingly used to generate IaC for platforms like Terraform and Pulumi. This code, like application code, can contain security misconfigurations, such as creating publicly accessible S3 buckets or overly permissive firewall rules.

• Key Tooling: Checkmarx KICS (Keeping Infrastructure as Code Secure) is an open-source static analysis tool specifically designed to scan IaC files.35 It supports a wide range of platforms, including Terraform, Kubernetes, and CloudFormation, and comes with a vast library of queries to detect thousands of potential misconfigurations. Other tools like Trivy and Open Policy Agent can also be used for this purpose.
• CI Pipeline Integration: KICS should be integrated into the CI pipeline to scan all IaC files on every pull request. The pipeline can be configured to post a summary of the findings as a comment on the PR, providing immediate feedback to the developer and reviewers. For critical misconfigurations, the pipeline should be configured to fail, blocking the merge until the issue is remediated. This automated check ensures that insecure infrastructure configurations suggested by an AI are caught before they are ever provisioned.74

The following table provides a strategic, at-a-glance comparison of the automated security tooling required to address the risks of AI-generated code. It evaluates tool categories against criteria specifically relevant to the challenges of a high-velocity, AI-driven development environment.

2.3 Layer 3: The CD Pipeline - Enforcing Governance with Policy as Code (PaC)

While IaC scanning (Layer 2) is excellent at detecting known security misconfigurations within a resource’s definition, Policy as Code (PaC) operates at a higher level of abstraction. It is designed to enforce broad, organization-wide governance rules that AI-generated code will almost certainly be unaware of. These rules often relate to compliance, cost control, and operational best practices. PaC acts as a crucial gate in the Continuous Deployment (CD) pipeline, ensuring that even technically valid infrastructure configurations adhere to business and regulatory constraints.

• The Role of PaC in an AI-Driven World: An AI assistant might generate a perfectly secure and functional Terraform configuration for a new database. However, it has no intrinsic knowledge of organizational policies. It might, for example:
  • Provision the database in a geographic region that violates data residency requirements like GDPR.
  • Select an expensive, high-performance instance type for a development environment, violating cost-control policies.
  • Fail to apply a mandatory set of tags (e.g., cost-center, owner) required for internal accounting and resource tracking.

PaC frameworks are designed to catch precisely these kinds of violations. They evaluate the final infrastructure plan against a codified set of rules before deployment is allowed to proceed.

• Comparative Analysis of PaC Frameworks:
  • Terraform Sentinel: Integrated with Terraform Cloud and Enterprise, Sentinel is a proprietary PaC framework that uses its own policy language.78 Policies can enforce a wide range of rules, such as restricting AWS instance types to an approved list, requiring specific tags on all resources, or preventing the destruction of critical production infrastructure. Sentinel offers three enforcement levels:
    advisory (warns but does not block), soft-mandatory (blocks but can be overridden by an administrator), and hard-mandatory (blocks without exception), providing flexible governance.
  • Pulumi CrossGuard: Pulumi’s PaC offering, CrossGuard, distinguishes itself by allowing policies to be written in general-purpose programming languages like Python and TypeScript.79 This approach offers superior flexibility, enabling complex logic, integration with external data sources (e.g., calling an internal API to validate a cost center tag), and the ability for teams to use their existing programming skills and testing frameworks to develop and validate policies. A CrossGuard policy can be applied to any Pulumi stack, regardless of the language the stack itself is written in.79

By integrating PaC into the CD pipeline, organizations can create a powerful, automated governance layer that enforces business rules on infrastructure defined by both humans and AI, ensuring that speed does not come at the cost of compliance.

2.4 Layer 4: The Production Environment - Runtime Protection and Response

The final and most crucial layer of a defense-in-depth strategy is protecting applications in their production environment. No matter how rigorous pre-deployment checks are, some vulnerabilities will inevitably slip through. This is especially true for AI-generated code, which is prone to subtle business logic flaws, zero-day vulnerabilities in its dependencies, and other complex issues that static analysis cannot detect. Runtime protection provides the essential safety net to detect and respond to active attacks as they happen.

• Introducing Application Detection and Response (ADR): ADR is an emerging category of security tooling designed to provide deep visibility into the runtime behavior of applications.85 Unlike traditional tools that focus on network or infrastructure perimeters, ADR operates at the application layer itself. It uses lightweight sensors, often leveraging technologies like eBPF, to monitor code execution, data flows, and library function calls in real-time without impacting performance.85
• The Mechanism of ADR: The core principle of ADR is behavioral analysis.
  1. Baselining: The ADR tool observes the application during normal operation to establish a baseline of expected behavior. This includes profiling which functions are called, how libraries are used, and what data flows occur.85
  2. Anomaly Detection: It then continuously monitors the application for deviations from this baseline. These anomalies are strong indicators of a potential compromise.85
  3. Response: When a high-confidence threat is detected, advanced ADR solutions can automatically block the malicious activity, such as by terminating a specific function call or isolating a compromised component, often without needing to take the entire application offline.85
• Relevance for Securing AI-Generated Code: ADR is uniquely suited to address the vulnerabilities that are most likely to be missed by the previous security layers.
  • Detecting Exploitation of Logical Flaws: AI code may contain subtle flaws in business logic (e.g., a broken access control vulnerability where a user can access another user’s data by manipulating an ID). SAST tools often struggle to identify these context-dependent flaws. ADR, however, can detect the exploitation of such a flaw at runtime by identifying an anomalous sequence of function calls or an unexpected data access pattern.91
  • Mitigating Zero-Day Supply Chain Attacks: If a malicious package suggested by an AI (a “package hallucination”) makes it through the CI pipeline and into production, ADR provides a critical last line of defense. Even if the vulnerability is a zero-day with no known signature, ADR can detect the package’s malicious behavior. For example, if a data serialization library like PyYaml suddenly attempts to execute a shell command or open a network socket, ADR will flag this as a severe deviation from its established behavioral profile and can block the action.85
  • Securing GenAI Frameworks and Mitigating LLM Risks: ADR solutions can be specifically configured to monitor the behavior of embedded open-source GenAI frameworks like Meta’s Llama. By profiling the libraries within these frameworks, ADR can validate and control the model’s inputs and outputs at runtime. This capability can help detect and mitigate the effects of attacks like prompt injection, where an attacker tries to trick the model into executing harmful code or leaking data.85

By implementing ADR, organizations can close the final gap in their security posture, ensuring they have the visibility and response capabilities to handle the dynamic and often unpredictable threats that can emerge from applications built with AI-generated code.

Section 3: Governance and Organizational Readiness for Secure AI Adoption

Implementing the technical controls detailed in the previous section is necessary but not sufficient for securing AI-assisted development. A successful strategy requires a foundation of strong governance and organizational readiness. Ad-hoc tooling and processes will fail under the scale and velocity of AI-driven development. Instead, organizations must adopt a structured, repeatable framework for managing AI risk and deliberately build a program to oversee its implementation.

3.1 Implementing the NIST AI Risk Management Framework (RMF)

The NIST AI Risk Management Framework (RMF) provides a structured, voluntary framework for organizations to govern, map, measure, and manage the risks associated with AI systems.92 While designed for AI systems broadly, its principles are directly applicable to the specific use case of managing the risks of AI code generation within a DevSecOps lifecycle. Adopting the AI RMF allows technical leaders to translate low-level security activities into a high-level, defensible risk management program that can be communicated to executive stakeholders and regulators.

• Applying the Four Core Functions to DevSecOps:
  • GOVERN: This function is foundational and establishes a culture of risk management. In the context of DevSecOps for AI, this involves:
    • Establishing Policies: Creating clear, enforceable policies on the acceptable use of specific AI coding assistants, data privacy requirements for prompts, and licensing compliance for AI-generated code.92
    • Defining Roles and Responsibilities: Explicitly assigning accountability for the review and approval of AI-generated code. This clarifies that while the AI assists, the developer remains fully responsible for the quality and security of their commits.23
    • Fostering a Risk-Aware Culture: Implementing the developer training programs outlined in Section 2 to ensure the entire engineering organization understands the risks and their role in mitigating them.92
  • MAP: This function focuses on identifying risks within a specific context. For each software project or team, this means:
    • Contextualizing Risk: Identifying where and how AI assistants are being used. For example, using AI to generate code for a critical authentication service carries a much higher risk than using it for scaffolding a simple user interface.92
    • Threat Modeling: Proactively identifying potential threats, such as the risk of prompt injection attacks against a specific workflow or the possibility of sensitive data leakage if developers use proprietary code in prompts to a public AI service.
  • MEASURE: This function is about developing and applying methodologies to assess and monitor AI risks. This is where the technical controls from the CI/CD pipeline provide the necessary data:
    • Quantitative Analysis: Using the outputs from SAST, SCA, secrets scanning, and IaC scanning tools to track key metrics. These include the rate of vulnerability injection by AI tools, the severity of those vulnerabilities, and the Mean Time to Remediate (MTTR).92
    • Benchmarking: Comparing the security posture of teams or projects that heavily use AI against those that do not, to measure the net impact on security.
    • Runtime Monitoring: Using data from ADR systems to measure the frequency of anomalous runtime behaviors in applications with significant AI-generated code contributions.
  • MANAGE: This function involves allocating resources to treat the risks identified and measured. In the DevSecOps workflow, this translates to:
    • Prioritization and Remediation: Using the data from the “Measure” phase to prioritize the most critical vulnerabilities for immediate remediation. This involves allocating developer time to fix issues flagged by security tools.92
    • Incident Response: Having well-defined incident response playbooks that are specifically tailored to security events involving AI-generated code, such as responding to a breach caused by a hallucinated malicious package.
    • Continuous Improvement: Using the findings from risk management activities to continuously refine the policies, tools, and training established in the “Govern” function, creating a feedback loop for improvement.

3.2 Building a DevSecOps for AI Program: A Readiness Checklist

A successful DevSecOps for AI program requires a deliberate and structured approach. The following checklist provides an actionable framework for organizations to assess their readiness, identify gaps, and structure their initiatives for the secure adoption of AI in software development.

1. Culture and Collaboration:

• [ ] Security Mindset: Is there a widely understood and accepted principle that security is everyone’s responsibility, including for AI-generated code? 95
• [ ] Developer Training: Have developers been formally trained on the specific risks of AI coding assistants, including the OWASP Top 10 for LLMs and secure prompt engineering? 96
• [ ] Cross-Functional Alignment: Do Development, Security, and Operations teams collaborate on defining AI usage policies and reviewing security tool findings? 97

2. Process and Workflow Integration:

• [ ] AI Footprint Mapping: Has the organization identified all the teams and projects using AI assistants and the specific tools being used? 96
• [ ] Threat Modeling: Is threat modeling, specifically considering AI-related attack vectors (e.g., prompt injection, data poisoning), a standard part of the design phase for critical applications? 95
• [ ] Mandatory Security Gates: Are automated security scans (SAST, SCA, Secrets, IaC) integrated into the CI pipeline as mandatory, non-bypassable checks for every pull request? 98
• [ ] Formal Code Review Process: Is there a formal, documented process for the human review of all AI-generated code, with a focus on business logic and contextual security? 23
• [ ] Incident Response Plan: Do incident response playbooks explicitly cover scenarios involving AI, such as a breach originating from a malicious hallucinated package? 96

3. Tooling and Technology:

• [ ] AI-Aware Tooling: Do the existing SAST and SCA tools have capabilities specifically designed for AI-generated code, such as AI-powered remediation or enhanced contextual analysis? 100
• [ ] Supply Chain Defense: Is there a centralized system for managing open-source dependencies (e.g., an internal registry or allowlist) and an SCA tool capable of real-time package verification to defend against slopsquatting? 17
• [ ] Comprehensive Secrets Scanning: Is an automated secrets scanner like Gitleaks deployed across all repositories and integrated into pre-commit hooks and CI pipelines? 96
• [ ] Runtime Protection: Has the organization evaluated or deployed an Application Detection and Response (ADR) solution for critical, internet-facing applications to monitor for runtime anomalies? 96

4. Governance and Measurement:

• [ ] Acceptable Use Policy: Is there a clear, written policy that defines which AI coding tools are approved for use and outlines the security responsibilities of developers who use them? 23
• [ ] Risk Management Framework: Has the organization formally adopted a risk management framework, such as the NIST AI RMF, to guide its AI governance strategy? 102
• [ ] Key Performance Indicators (KPIs): Have metrics been established to measure the impact of AI on both development velocity and security posture? (e.g., tracking code commit volume vs. the rate of high-severity vulnerabilities introduced). 103
• [ ] Continuous Feedback Loop: Is there a process for feeding the findings from security scans and incident reviews back into developer training and policy updates? 95

Section 4: Conclusion and Strategic Recommendations

The proliferation of AI coding assistants marks an inflection point for the software development industry. The productivity gains are undeniable, but they are inextricably linked to a new and complex set of security risks. This analysis has demonstrated that AI models, by their very nature as pattern-replication engines trained on flawed public data, act as a systemic vector for vulnerability injection. They consistently produce code with classic security weaknesses, introduce novel supply chain threats through package hallucinations, and foster a dangerous automation bias that erodes essential human oversight.

Attempting to address this challenge with isolated tools or ad-hoc processes is a strategy destined for failure. The velocity and scale of AI-generated code demand a correspondingly fast, scalable, and automated security response. The only viable path forward is a holistic, defense-in-depth DevSecOps strategy that embeds security controls across the entire SDLC—from the developer’s initial prompt to the application’s runtime behavior in production. This requires a paradigm shift: from viewing security as a quality gate to treating it as an intrinsic, non-negotiable attribute of the development process itself, where all AI-generated code is considered untrusted by default.

For CISOs, DevSecOps leaders, and technology executives, navigating this new landscape requires decisive action. The following strategic recommendations provide a prioritized roadmap for building a resilient and secure AI-assisted development program.

Strategic Recommendations for Leadership:

1. Mandate a “Zero-Trust Code” Policy: The first and most critical step is to dismantle the illusion of AI infallibility. Establish a formal, organization-wide policy that all AI-generated code is considered untrusted and potentially malicious until proven otherwise. This policy must mandate that all code, without exception, passes through non-bypassable automated security gates (SAST, SCA, Secrets, IaC) in the CI pipeline before it can be merged into a main branch.
2. Invest in an AI-Aware Security Toolchain: The increased volume of vulnerabilities introduced by AI necessitates a move beyond tools that merely find problems. Prioritize investment in a modern security toolchain that offers AI-specific detection capabilities and, most importantly, AI-powered automated remediation. Tools that can generate high-confidence, context-aware fixes and present them as one-click suggestions or automated pull requests are essential to managing risk at scale without crippling developer velocity. The key metric of success must shift from Mean Time to Detect (MTTD) to Mean Time to Remediate (MTTR).
3. Launch a Comprehensive Developer Enablement Program: Technology and policy alone are insufficient without addressing the human element. Initiate mandatory, continuous training programs for all engineering staff. This education must focus on secure prompt engineering techniques, the specific limitations and risks of AI assistants (including the OWASP Top 10 for LLMs), and the organization’s new security review processes. The explicit goal is to actively combat automation bias and re-establish a culture of critical thinking and rigorous scrutiny.
4. Implement a Robust Software Supply Chain Defense: The threat of package hallucination and slopsquatting is immediate and severe. Establish a centralized policy and platform for open-source dependency management. This should include maintaining an internal allowlist or private registry of vetted, approved packages. Integrate a real-time SCA tool into the CI pipeline that is configured to block the installation of any dependency not on the approved list, providing a powerful defense against this novel attack vector.
5. Adopt a Formal Governance Framework: To ensure a structured, defensible, and repeatable approach to managing AI risk, formally adopt the NIST AI Risk Management Framework (RMF). Use the Govern, Map, Measure, and Manage functions as the strategic foundation for your DevSecOps for AI program. This framework provides a common language to align technical controls with business objectives and communicate the organization’s risk posture to executives, auditors, and regulators.
6. Pilot Runtime Protection for Critical Applications: Acknowledge that pre-deployment checks will never be perfect. As a final safety net, begin deploying Application Detection and Response (ADR) solutions on high-value, internet-facing applications. This provides a critical runtime defense capable of detecting and blocking the exploitation of subtle business logic flaws and zero-day vulnerabilities that static analysis tools are inherently unable to find, ensuring a resilient security posture against the most sophisticated threats.

Works cited

1. AI-Generated Code: The Security Blind Spot Your Team Can’t Ignore - Jit.io, accessed July 29, 2025, https://www.jit.io/resources/devsecops/ai-generated-code-the-security-blind-spot-your-team-cant-ignore
2. Vulnerabilities in AI Code Generators:Exploring Targeted Data Poisoning Attacks - arXiv, accessed July 29, 2025, https://arxiv.org/pdf/2308.04451
3. Securing AI-Generated Code - University of Minnesota, Morris Digital Well, accessed July 29, 2025, https://digitalcommons.morris.umn.edu/cgi/viewcontent.cgi?article=1167&context=horizons
4. Security Weaknesses of Copilot-Generated Code in GitHub Projects: An Empirical Study, accessed July 29, 2025, https://arxiv.org/html/2310.02059v3
5. (PDF) Security Weaknesses of Copilot-Generated Code in GitHub Projects: An Empirical Study - ResearchGate, accessed July 29, 2025, https://www.researchgate.net/publication/388754976_Security_Weaknesses_of_Copilot-Generated_Code_in_GitHub_Projects_An_Empirical_Study
6. Assessing the Security of GitHub Copilot’s Generated Code - A Targeted Replication Study - arXiv, accessed July 29, 2025, https://arxiv.org/pdf/2311.11177
7. Security Analysis and Validation of Generative-AI-Produced Code | by Adnan Masood, PhD., accessed July 29, 2025, https://medium.com/@adnanmasood/security-analysis-and-validation-of-generative-ai-produced-code-d4218078bd63
8. Cybersecurity Risks of AI-Generated Code - CSET, accessed July 29, 2025, https://cset.georgetown.edu/wp-content/uploads/CSET-Cybersecurity-Risks-of-AI-Generated-Code.pdf
9. AI Coding Assistants: 17 Risks (And How To Mitigate Them) - Forbes, accessed July 29, 2025, https://www.forbes.com/councils/forbestechcouncil/2025/03/21/ai-coding-assistants-17-risks-and-how-to-mitigate-them/
10. OWASP Top 10 LLM and GenAI - Snyk Learn, accessed July 29, 2025, https://learn.snyk.io/learning-paths/owasp-top-10-llm/
11. What are the OWASP Top 10 risks for LLMs? - Cloudflare, accessed July 29, 2025, https://www.cloudflare.com/learning/ai/owasp-top-10-risks-for-llms/
12. Quick Guide to OWASP Top 10 LLM: Threats, Examples & Prevention - Tigera, accessed July 29, 2025, https://www.tigera.io/learn/guides/llm-security/owasp-top-10-llm/
13. Malicious AI Models Undermine Software Supply-Chain Security, accessed July 29, 2025, https://cacm.acm.org/research/malicious-ai-models-undermine-software-supply-chain-security/
14. The Hidden Dangers of AI-Assisted Coding: Why You’re More Vulnerable Than Ever, accessed July 29, 2025, https://medium.com/@help_63034/the-hidden-dangers-of-ai-assisted-coding-why-youre-more-vulnerable-than-ever-b4914df49cd2
15. The Hidden AI Threat to Your Software Supply Chain - Check Point Blog, accessed July 29, 2025, https://blog.checkpoint.com/research/the-hidden-ai-threat-to-your-software-supply-chain/
16. Package Hallucinations: How LLMs Can Invent Vulnerabilities | USENIX, accessed July 29, 2025, https://www.usenix.org/publications/loginonline/we-have-package-you-comprehensive-analysis-package-hallucinations-code
17. AI Supply-Chain Security: Managing “Package Hallucination” Risks - Software Development Company Dubai UAE - Verbat Technologies, accessed July 29, 2025, https://www.verbat.com/blog/ai-supply-chain-security-managing-package-hallucination-risks/
18. UTSA researchers investigate AI threats in software development, accessed July 29, 2025, https://www.utsa.edu/today/2025/04/story/utsa-researchers-investigate-AI-threats.html
19. AI-Generated Code Creates Major Security Risk Through ‘Package Hallucinations’, accessed July 29, 2025, https://developers.slashdot.org/story/25/04/29/1837239/ai-generated-code-creates-major-security-risk-through-package-hallucinations
20. The Invisible Threat in Your Code Editor: AI’s Package Hallucination Problem, accessed July 29, 2025, https://c3.unu.edu/blog/the-invisible-threat-in-your-code-editor-ais-package-hallucination-problem
21. Generative AI Exacerbates Software Supply Chain Risks - FDD, accessed July 29, 2025, https://www.fdd.org/analysis/op_eds/2025/06/25/generative-ai-exacerbates-software-supply-chain-risks/
22. Unpickling Pytorch: Keeping Malicious AI Out | Sonatype Whitepaper, accessed July 29, 2025, https://www.sonatype.com/resources/whitepapers/unpickling-pytorch
23. 2025 CISO Guide to Securing AI-Generated Code - Checkmarx, accessed July 29, 2025, https://checkmarx.com/blog/ai-is-writing-your-code-whos-keeping-it-secure/
24. How to review code written by AI - Graphite, accessed July 29, 2025, https://graphite.dev/guides/how-to-review-code-written-by-ai
25. 5 security best practices for adopting generative AI code assistants like GitHub Copilot, accessed July 29, 2025, https://snyk.io/blog/5-security-best-practices-generative-ai-code-assistants-copilot/
26. Prompt Engineering in Code Generation: Creating AI-Assisted Solutions for Developers, accessed July 29, 2025, https://hyqoo.com/artificial-intelligence/prompt-engineering-in-code-generation-creating-ai-assisted-solutions-for-developers
27. Prompt Engineering for Code Generation: Examples & Best Practices, accessed July 29, 2025, https://margabagus.com/prompt-engineering-code-generation-practices/
28. AI Code Reviews - GitHub, accessed July 29, 2025, https://github.com/resources/articles/ai/ai-code-reviews
29. Generative AI for Software Development Skill Certificate - Coursera, accessed July 29, 2025, https://www.coursera.org/professional-certificates/generative-ai-for-software-development
30. Courses for Generative AI for Technologists and Developers - Skillsoft, accessed July 29, 2025, https://www.skillsoft.com/channel/generative-ai-for-technologists-and-developers-84ec299d-148d-4a4b-86f2-2eb47cd3e144
31. Top 10 AI-powered SAST tools in 2025 - Aikido, accessed July 29, 2025, https://www.aikido.dev/blog/top-10-ai-powered-sast-tools-in-2025
32. Leveraging AI To Enhance Static Code Analysis (SAST) - Checkmarx, accessed July 29, 2025, https://checkmarx.com/learn/sast/how-ai-enables-more-effective-static-application-security-testing/
33. Real-Time Static Application Security Testing (SAST) - Arnica.io, accessed July 29, 2025, https://www.arnica.io/use-cases/sast
34. DeepCode AI | AI Code Review | AI Security for SAST - Snyk, accessed July 29, 2025, https://snyk.io/platform/deepcode-ai/
35. AI Security for Application Security - Checkmarx, accessed July 29, 2025, https://checkmarx.com/glossary/what-ai-security/
36. 3 Steps for Securing Your AI-Generated Code - Qodo, accessed July 29, 2025, https://www.qodo.ai/blog/3-steps-securing-your-ai-generated-code/
37. Protecting your AI code: How SonarQube defends against the “Rules File Backdoor” | Sonar, accessed July 29, 2025, https://www.sonarsource.com/blog/protecting-your-ai-code/
38. Securing AI code with Snyk: A practical guide - PAELLADOC, accessed July 29, 2025, https://paelladoc.com/blog/securing-ai-code-with-snyk/
39. Secure AI-Generated Code | AI Coding Tools | AI Code Auto-fix - Snyk, accessed July 29, 2025, https://snyk.io/solutions/secure-ai-generated-code/
40. Setting up AI Code Assurance | SonarQube Server Documentation, accessed July 29, 2025, https://docs.sonarsource.com/sonarqube-server/2025.3/project-administration/ai-features/set-up-ai-code-assurance/
41. How to Protect AI-Generated Code Quality Using SonarQube AI Code Assurance, accessed July 29, 2025, https://www.sonarsource.com/learn/how-to-guide-for-ai-code-assurance/
42. Standards for AI Code Assurance - SonarQube Docs, accessed July 29, 2025, https://docs.sonarsource.com/sonarqube-server/latest/ai-capabilities/ai-code-assurance/
43. Quality gates for AI code | SonarQube Server Documentation, accessed July 29, 2025, https://docs.sonarsource.com/sonarqube-server/2025.1/instance-administration/analysis-functions/ai-code-assurance/quality-gates-for-ai-code/
44. Quality Gates | SonarQube Server Documentation, accessed July 29, 2025, https://docs.sonarsource.com/sonarqube-server/10.8/instance-administration/analysis-functions/quality-gates/
45. Project Information - SonarQube Server, accessed July 29, 2025, https://next.sonarqube.com/sonarqube/project/information?id=sonarqube
46. Ensuring AI Code Quality with SonarQube + Gemini Code Assist - Atamel.Dev, accessed July 29, 2025, https://atamel.dev/posts/2025/03-04_ensure_code_quality_sonarqube_gemini/
47. Adding coding rules - SonarQube Docs, accessed July 29, 2025, https://docs.sonarsource.com/sonarqube-server/9.8/extension-guide/adding-coding-rules/
48. Adding coding rules | SonarQube Server Documentation, accessed July 29, 2025, https://docs.sonarsource.com/sonarqube-server/10.8/extension-guide/adding-coding-rules/
49. Creating custom rules for Snyk Infrastructure as Code (Snyk IaC) - SecuritySenses, accessed July 29, 2025, https://securitysenses.com/videos/creating-custom-rules-snyk-infrastructure-code-snyk-iac
50. Creating custom rules for Snyk Code, accessed July 29, 2025, https://learn.snyk.io/lesson/custom-rules-for-snyk-code/
51. Best practices for Snyk Code custom rules | Snyk User Docs, accessed July 29, 2025, https://docs.snyk.io/scan-with-snyk/snyk-code/snyk-code-custom-rules/best-practices-for-snyk-code-custom-rules
52. AI Code Security: Snyk vs Semgrep vs CodeQL - sanj.dev, accessed July 29, 2025, https://sanj.dev/post/ai-code-security-tools-comparison
53. Create query | Snyk User Docs - Snyk Documentation, accessed July 29, 2025, https://docs.snyk.io/scan-with-snyk/snyk-code/snyk-code-custom-rules/create-query
54. Examples of IaC custom rules - Snyk User Docs, accessed July 29, 2025, https://docs.snyk.io/scan-with-snyk/snyk-iac/current-iac-custom-rules/writing-rules-using-the-sdk/examples-of-iac-custom-rules
55. Snyk IaC Custom Rules Examples - GitHub, accessed July 29, 2025, https://github.com/snyk/custom-rules-examples
56. Why SCA Should Be Part of Code Review Checks - Panto AI, accessed July 29, 2025, https://www.getpanto.ai/blogs/27-05-2025/why-sca-should-be-part-of-code-review-checks
57. Open Source in Ai-Generated Code | SCANOSS, accessed July 29, 2025, https://www.scanoss.com/open-source-in-ai-generated-code
58. AI generated code security | Mend, accessed July 29, 2025, https://www.mend.io/ai-generated-code-security/
59. Slopsquatting: When AI Agents Hallucinate Malicious Packages | Trend Micro (US), accessed July 29, 2025, https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/slopsquatting-when-ai-agents-hallucinate-malicious-packages
60. Securing Your Codebase with GitLeaks: A Comprehensive Guide - Crest Data, accessed July 29, 2025, https://www.crestdata.ai/blogs/securing-your-codebase-with-gitleaks-comprehensive-guide
61. Gitleaks - Open Source Secret Scannng, accessed July 29, 2025, https://gitleaks.io/
62. Gitleaks | CodeRabbit, accessed July 29, 2025, https://docs.coderabbit.ai/tools/gitleaks/
63. The Developer’s Guide to Using Gitleaks to Detect Hardcoded Secret - Jit.io, accessed July 29, 2025, https://www.jit.io/resources/appsec-tools/the-developers-guide-to-using-gitleaks-to-detect-hardcoded-secrets
64. Gitleaks - GitHub, accessed July 29, 2025, https://github.com/gitleaks
65. Zero Trust, Zero Noise: Build an AI‑Driven DevSecOps Pipeline with GitHub Actions | by DevOpsDynamo | Jul, 2025 | Medium, accessed July 29, 2025, https://medium.com/@DynamoDevOps/zero-trust-zero-noise-build-an-ai-driven-devsecops-pipeline-with-github-actions-af2189f32653
66. Protect your secrets using Gitleaks-Action - GitHub, accessed July 29, 2025, https://github.com/gitleaks/gitleaks-action
67. Prevent Secret Leaks with GitLeaks | by Aditya Hilman - Medium, accessed July 29, 2025, https://medium.com/@aditya.hilman_10961/prevent-secret-leaks-with-gitleaks-ff36cac818a2
68. Strengthen data security with custom PII detection rulesets - GitLab, accessed July 29, 2025, https://about.gitlab.com/blog/enhance-data-security-with-custom-pii-detection-rulesets/
69. gitleaks/gitleaks: Find secrets with Gitleaks - GitHub, accessed July 29, 2025, https://github.com/gitleaks/gitleaks
70. Gitleaks is a SAST tool for detecting hardcoded secrets like passwords, api keys, and tokens in git repos. Gitleaks aims to be the easy-to-use, all-in-one solution for finding secrets, past or present, in your code. : r/devops - Reddit, accessed July 29, 2025, https://www.reddit.com/r/devops/comments/hy4r5u/gitleaks_is_a_sast_tool_for_detecting_hardcoded/
71. KICs - Checkmarx, accessed July 29, 2025, https://checkmarx.com/product/kics/
72. IaC Security | Infrastructure as Code Scanning - Checkmarx, accessed July 29, 2025, https://checkmarx.com/product/iac-security/
73. KICS - Open Source Infrastructure as Code - Checkmarx, accessed July 29, 2025, https://checkmarx.com/product/opensource/kics-open-source-infrastructure-as-code-project/
74. Enhancing Infrastructure Security with Automated Terraform …, accessed July 29, 2025, https://medium.com/@satya.elipe/enhancing-infrastructure-security-with-automated-terraform-scanning-d7e22602ee88
75. checkmarx/kics-query-builder - Docker Image, accessed July 29, 2025, https://hub.docker.com/r/checkmarx/kics-query-builder
76. KICS - Checkmarx, accessed July 29, 2025, https://checkmarx.com/glossary/kics/
77. Checkmarx/kics-github-action, accessed July 29, 2025, https://github.com/Checkmarx/kics-github-action
78. Security best practices - AWS Prescriptive Guidance, accessed July 29, 2025, https://docs.aws.amazon.com/prescriptive-guidance/latest/terraform-aws-provider-best-practices/security.html
79. CrossGuard Guides (Policy as Code) | Pulumi Docs, accessed July 29, 2025, https://www.pulumi.com/docs/iac/crossguard/
80. Get Started with Policy as Code | CrossGuard | Pulumi Docs, accessed July 29, 2025, https://www.pulumi.com/docs/iac/crossguard/get-started/
81. Pulumi CrossGuard - Policy as Code for Any Cloud, accessed July 29, 2025, https://www.pulumi.com/crossguard/
82. Pulumi CrossGuard (Policy as code) FAQ - Docs, accessed July 29, 2025, https://www.pulumi.com/docs/iac/crossguard/faq/
83. Create a Custom Policy Pack | Pulumi Crossguard, accessed July 29, 2025, https://www.pulumi.com/tutorials/custom-policy-pack/create-policy-pack/
84. What Is Pulumi And How To Use It | Tutorial - Env0, accessed July 29, 2025, https://www.env0.com/blog/what-is-pulumi-and-how-to-use-it-with-env0
85. What is Application Detection and Response (ADR)? 2025 Guide …, accessed July 29, 2025, https://www.oligo.security/blog/what-is-adr-application-detection-and-response
86. Understanding Application Detection and Response (ADR …, accessed July 29, 2025, https://www.contrastsecurity.com/security-influencers/understanding-application-detection-and-response-adr-contrast-security
87. AI Speed Paradox | Securing AI Generated Code - Contrast Security, accessed July 29, 2025, https://www.contrastsecurity.com/security-influencers/ai-speed-paradox-securing-ai-generated-code-contrast-security
88. Kodem’s Approach to ADR: Rethinking Application Detection & Response, accessed July 29, 2025, https://www.kodemsecurity.com/resources/kodems-approach-to-adr-rethinking-application-detection-response
89. Your guide to Application Detection and Response (ADR) - OX Security, accessed July 29, 2025, https://www.ox.security/your-guide-to-application-detection-and-response-adr/
90. Application Detection and Response (ADR) - Apiiro, accessed July 29, 2025, https://apiiro.com/glossary/application-detection-and-response/
91. What is AI code security?: Cybersecurity risks of AI-generated code, accessed July 29, 2025, https://www.contrastsecurity.com/glossary/ai-code-security
92. The National Institute of Standards and Technology (NIST) Artificial Intelligence Risk Management | TrustArc, accessed July 29, 2025, https://trustarc.com/regulations/nist-ai-rmf/
93. NIST AI Risk Management Framework: A tl;dr - Wiz, accessed July 29, 2025, https://www.wiz.io/academy/nist-ai-risk-management-framework
94. NIST AI Risk Management Framework 1.0: Meaning, challenges, implementation, accessed July 29, 2025, https://www.scrut.io/post/nist-ai-risk-management-framework
95. DevSecOps Best Practices Checklist - Aptori, accessed July 29, 2025, https://www.aptori.com/blog/devsecops-best-practices-checklist
96. DevSecOps Best Practices in the Age of AI - Checkmarx, accessed July 29, 2025, https://checkmarx.com/learn/ai-security/devsecops-best-practices-in-the-age-of-ai/
97. A DevSecOps security checklist - GitLab, accessed July 29, 2025, https://about.gitlab.com/topics/devsecops/devsecops-security-checklist/
98. Key DevSecOps Checklists for Secure Development - XenonStack, accessed July 29, 2025, https://www.xenonstack.com/insights/devsecops-checklist
99. The Ultimate DevSecOps Checklist To Secure The Software Supply Chain - OpsMx, accessed July 29, 2025, https://www.opsmx.com/blog/ultimate-devsecops-checklist-to-secure-ci-cd-pipeline/
100. Revolutionizing DevSecOps: AI for Intelligent Security from Code to Cloud - DEV Community, accessed July 29, 2025, https://dev.to/vaib/revolutionizing-devsecops-ai-for-intelligent-security-from-code-to-cloud-2inc
101. DevSecOps Solutions & Automation Tools for CICD | Black Duck, accessed July 29, 2025, https://www.blackduck.com/solutions/devsecops.html
102. Your AI Readiness Assessment Checklist | icma.org, accessed July 29, 2025, https://icma.org/articles/pm-magazine/your-ai-readiness-assessment-checklist
103. How to put generative AI to work in your DevSecOps environment - GitLab, accessed July 29, 2025, https://about.gitlab.com/the-source/ai/how-to-put-generative-ai-to-work-in-your-devsecops-environment/