Why AI code assistants need a security reality check

In this Help Net Security interview, Silviu Asandei, Security Specialist and Security Governance at Sonar, discusses how AI code assistants are transforming development workflows and impacting security. He explains how these tools can boost productivity but may also propagate vulnerabilities if not properly reviewed.

What security risks do AI code assistants pose that developers and organizations might overlook?

While AI code assistants enhance developer productivity, they introduce significant and often overlooked security risks across multiple domains. On the human level, over-reliance can foster a “false confidence,” leading to unscrutinized, insecure code and diminished developer skills. This can create a “generative monoculture” where a single flaw in a popular AI suggestion gets replicated widely.

Technically, these tools can generate code with vulnerabilities like SQL injection, embed hardcoded secrets, and suggest outdated dependencies. Using cloud-based assistants raises data privacy concerns, as proprietary code may be exposed or used for training, leading to IP and licensing infringements.

The AI models themselves are vulnerable to attacks such as prompt injection and data poisoning, as highlighted by the OWASP Top 10 for LLMs. Furthermore, AI assistants can become a new vector for software supply chain attacks, amplifying the potential attack surface by introducing vulnerabilities at scale. These multifaceted risks extend far beyond simple code errors, requiring a comprehensive security approach that addresses human factors, data governance, model integrity, and the broader software development lifecycle.

What are some best practices for reviewing or securing code generated by AI assistants?

Securing code generated by AI assistants demands a multi-layered strategy combining human diligence, robust technology, and clear organizational governance. The cornerstone of this approach is maintaining critical human oversight.

Developers must adopt a “trust but verify” mindset, treating AI suggestions as code from an inexperienced assistant that requires thorough review. It’s crucial not just to validate the code’s functionality but to fully understand its underlying logic and potential security implications. This vigilance should be formalized through a strengthened code review culture where AI-generated snippets receive extra scrutiny.

Technically, all code should be scanned using a suite of impartial security tools. This includes Static (SAST), Dynamic (DAST), and Software Composition Analysis (SCA) to detect vulnerabilities, runtime issues, and insecure dependencies, respectively. Developers should also practice secure prompt engineering by providing detailed context and explicitly asking the AI to incorporate security measures, for instance, by requesting code that prevents specific attacks like SQL injection.

These individual practices must be supported by strong organizational guardrails. Businesses need to establish clear AI usage policies, outlining which tools are approved and what data can be shared. Comprehensive developer training on AI risks, secure prompting, and critical assessment of AI output is essential.

Furthermore, enforcing the principle of least privilege for all AI-generated code and sandboxing agentic assistants can prevent potential harm. By fostering a collaborative environment where developers work with AI as a teammate and commit to continuous learning, organizations can safely leverage these powerful tools. This holistic approach ensures that productivity gains from AI do not come at the cost of security.

To what extent do training data and model architecture influence the security posture of code assistants? Are they prone to replicating insecure coding patterns?

AI code assistants’ security is fundamentally shaped by their training data and model architecture, both of which can lead to the generation of insecure code.

The training data, often sourced from vast public repositories, is a primary concern. If this data contains insecure coding practices, hardcoded secrets like API keys, or outdated libraries with known vulnerabilities, the AI learns and replicates these flaws. This can lead to suggestions containing vulnerabilities like SQL injection or the use of deprecated cryptographic functions. The model’s knowledge is limited to its training data, so it might recommend older, vulnerable components. Furthermore, malicious actors can intentionally poison the training data, causing the AI to generate harmful code.

The model’s architecture also contributes to security risks. Current models often lack a deep contextual understanding of a specific application’s security needs, generating syntactically correct but functionally insecure code. They struggle to differentiate between trusted developer instructions and untrusted user input, making them vulnerable to prompt injection attacks. A phenomenon known as “generative monoculture” can also arise, where the AI repeatedly suggests similar code structures. If this common code has a flaw, it can create a widespread vulnerability. Ultimately, these models prioritize replicating learned patterns over adhering to security principles, and their complex, “black box” nature makes it difficult to audit their reasoning and identify potential weaknesses.

Are there measurable differences in security between proprietary AI assistants (e.g., GitHub Copilot) and open-source models when it comes to code generation?

The most significant measurable security difference is data privacy, where self-hosted open source models have a distinct advantage. Regarding the security of the generated code itself, both model types are susceptible to similar flaws inherited from their training data. The ultimate security of the output depends more on factors like training data quality, prompt engineering, and rigorous human oversight than on whether the model is proprietary or open source.

The security of the output from any AI code assistant, proprietary or open source, largely depends on:

• The quality and security focus of its training data and fine-tuning.
• The sophistication of its architecture in understanding context and security requirements.
• The specificity and security-consciousness of the prompts used by the developer.
• The rigor of human review, testing, and validation processes applied to the generated code.

Are you seeing any patterns in how AI code assistants affect secure development lifecycles or DevSecOps practices?

AI code assistants are significantly reshaping secure development (DevSecOps) by introducing both challenges and opportunities. A primary pattern is the acceleration of development, which generates a high volume of code that overwhelms traditional security review capacities. This expands the attack surface and introduces new vulnerabilities, as AI can suggest insecure code, hardcoded secrets, or outdated libraries.

This new dynamic makes it critical to take “shift left” a step further to “start left”—integrating security checks at the start of the development lifecycle. It also necessitates the development of “AI-aware” security tools capable of scanning AI-generated code for its unique potential flaws. Human oversight remains crucial, with developers needing to adopt a “trust but verify” approach and adapt code review processes.

Adopting a “start left” mentality is crucial for development teams to confidently embrace AI-generated code. This ensures that from the very first line, all code—human or AI-assisted—is held to the highest quality and security standards. By identifying potential problems early, teams can prevent costly rework, increase their development velocity, and build a stronger foundation of trust in their code.

While AI can create risk to compliance and data leakage with things like “shadow AI” increasing, AI also presents an opportunity to enhance DevSecOps. AI-powered tools can automate threat detection, vulnerability assessment, and patching, leading to a new paradigm where AI is used to defend against AI-driven threats and secure AI-generated code.