Главная уязвимость ИИ-кодогенерации

Основная претензия к коду, написанному искусственным интеллектом, заключается в низком уровне его надежности и безопасности. Стремясь как можно быстрее выдать работающее решение, языковые модели часто пренебрегают тестами, игнорируют обработку крайних случаев и допускают критические уязвимости вроде SQL-инъекций или межсайтового скриптинга (XSS).

Модели оптимизированы под генерацию быстрых ответов. Написание тестов и аудит безопасности требуют дополнительных вычислительных ресурсов и траты контекста. Если эти требования не зафиксированы жестко в системных инструкциях, нейросеть просто пропустит их.

Эту проблему решают структурированные рабочие процессы (workflows).


Как работают исполняемые workflows в proagents

В отличие от простых текстовых промптов, воркфлоу в библиотеке proagents представляют собой пошаговые алгоритмы. Они заставляют ИИ-ассистента следовать строгому регламенту в процессе написания и проверки кода.

В библиотеке содержится 521 готовый воркфлоу. Рассмотрим три ключевых сценария из разделов тестирования и безопасности с конкретными примерами реализации:

1. Строгий цикл разработки (tdd-workflow.md)

Этот воркфлоу запрещает модели писать функциональный код сразу. Он заставляет ее следовать классическому циклу Red-Green-Refactor.

Пример TDD в действии при создании функции валидации email (Vitest / Jest):

Шаг 1: ИИ пишет тест, который падает (RED-фаза):

import { describe, it, expect } from 'vitest';
import { validateEmail } from './validator';

describe('validateEmail', () => {
  it('должен возвращать true для корректных адресов', () => {
    expect(validateEmail('test@example.com')).toBe(true);
  });

  it('должен возвращать false для некорректных адресов', () => {
    expect(validateEmail('invalid-email')).toBe(false);
    expect(validateEmail('')).toBe(false);
  });
});

Шаг 2: ИИ пишет минимальный код для прохождения тестов (GREEN-фаза):

export function validateEmail(email: string): boolean {
  if (!email) return false;
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return emailRegex.test(email);
}

2. Моделирование угроз (owasp-threat-modeling.md)

Инструкция обязывает модель проводить анализ потенциальных угроз перед написанием кода, взаимодействующего с базой данных или обрабатывающего пользовательский ввод. Модель обязана проверить код на соответствие десяти самым критическим рискам безопасности по версии OWASP, выявить потенциальные точки отказа и внедрить защитные механизмы.

Шаблон таблицы моделирования угроз, который ИИ заполняет перед работой:

Компонент / Эндпоинт

Потенциальная угроза (STRIDE)

Категория OWASP

Мера предотвращения (Mitigation)

POST /api/register

SQL-инъекция через поле username

A03:2021-Injection

Использовать параметризованные запросы Prisma ORM + валидацию Zod

POST /api/register

XSS через вредоносный скрипт в поле BIO

A03:2021-Injection

Санитизация ввода через dompurify / escape-html

POST /api/register

Подбор паролей brute-force

A02:2021-Cryptographic Failures

Настройка rate-limiter (express-rate-limit) + хэширование argon2

Пример безопасной валидации с помощью Zod на основе этих мер:

import { z } from 'zod';
import escapeHtml from 'escape-html';

export const RegistrationSchema = z.object({
  username: z.string().min(3).max(30).regex(/^[a-zA-Z0-9_]+$/),
  email: z.string().email(),
  bio: z.string().max(500).transform((val) => escapeHtml(val)) // защита от XSS
});

3. Проверка перед деплоем (production-deployment.md)

Чек-лист готовности к релизу. Воркфлоу заставляет модель проверить качество логирования ошибок, убедиться в отсутствии захардкоженных API-ключей, проверить корректность заголовков безопасности и настроить параметры кеширования.


Как внедрить workflows в рабочий процесс

Для интеграции этих процессов используется CLI-инструмент библиотеки proagents.

Клонируем репозиторий:

git clone https://github.com/Arlandaren/proagents.git
cd proagents

Устанавливаем TDD и OWASP воркфлоу в Cursor:

./proagents install tdd-workflow --cursor
./proagents install owasp-threat-modeling --cursor

Теперь при выполнении сложных задач Cursor будет действовать по шагам, прописанным в воркфлоу, проверяя безопасность каждого этапа разработки.


Сравнение подходов к генерации

Критерий

Базовый AI-ассистент

С воркфлоу из proagents

Написание тестов

Редко, только по прямому запросу

Обязательно, по циклу Red-Green-Refactor

Анализ уязвимостей

Не проводится

Автоматический аудит на соответствие OWASP

Обработка ошибок

Минимальная (часто пустые блоки catch)

Строгая типизация и логирование сбоев

Безопасность данных

Риск утечки секретов и хардкода токенов

Проверка переменных окружения на этапе кодинга


Практический пример: создание API-эндпоинта

Посмотрим, как меняется подход к написанию кода на примере создания функции авторизации пользователя.

Без использования воркфлоу (базовый AI):

app.post('/api/login', async (req, res) => {
  const { username, password } = req.body;
  const user = await db.query(`SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`);
  if (user) {
    res.json({ token: 'jwt-token-placeholder' });
  } else {
    res.status(401).send('Invalid credentials');
  }
});

Здесь допущены критические ошибки: уязвимость к SQL-инъекциям (прямая конкатенация строки запроса), хранение паролей в открытом виде и плейсхолдер вместо реальной генерации токенов.

С использованием воркфлоу owasp-threat-modeling:

import { Request, Response } from 'express';
import bcrypt from 'bcrypt';
import jwt from 'jsonwebtoken';

export async function handleLogin(req: Request, res: Response): Promise<void> {
  try {
    const { username, password } = req.body;
    if (!username || !password) {
      res.status(400).json({ error: 'Missing credentials' });
      return;
    }

    const query = 'SELECT id, password_hash FROM users WHERE username = $1';
    const result = await db.query(query, [username]);
    
    if (result.rows.length === 0) {
      res.status(401).json({ error: 'Invalid credentials' });
      return;
    }

    const user = result.rows[0];
    const isPasswordValid = await bcrypt.compare(password, user.password_hash);

    if (!isPasswordValid) {
      res.status(401).json({ error: 'Invalid credentials' });
      return;
    }

    const jwtSecret = process.env.JWT_SECRET;
    if (!jwtSecret) {
      throw new Error('JWT_SECRET env variable is not defined');
    }

    const token = jwt.sign({ userId: user.id }, jwtSecret, { expiresIn: '1h' });
    res.json({ token });
  } catch (error) {
    logger.error('Login error', { error });
    res.status(500).json({ error: 'Internal server error' });
  }
}

Воркфлоу заставил модель использовать параметризованные SQL-запросы для защиты от инъекций, применить bcrypt для хэширования паролей, реализовать проверку наличия секретного ключа в переменных окружения, типизировать параметры и добавить безопасное логирование без раскрытия чувствительных данных.


Открытый исходный код под лицензией MIT

База правил и воркфлоу proagents полностью открыта.

Ссылка на проект: github.com/Arlandaren/proagents

Если библиотека помогла вам повысить безопасность и надежность ваших приложений, поддержите проект звездой на GitHub. Ваши пуллреквесты с новыми сценариями тестирования и аудита безопасности приветствуются.

Комментарии (2)


  1. Genius_Russian_Coders
    17.06.2026 13:04

    На практике: если просить модель сначала написать тесты, а потом код под них — покрытие веток выходит заметно лучше. По безопасности: SQL-инъекции AI ещё ловит, а вот бизнес-логические дыры пропускает почти всегда. Ручной ревью пока не заменишь.


  1. andy-takker
    17.06.2026 13:04

    Мне казалось, что с этим всем уже давно не надо заморачиваться с появлением superpowers и встренными в него brainstorming, writing-plans и test-driven-development.

    Сначала просишь побрейнштормить и раскопать задачу, потом составляешь с ним подробный план и потом указываешь, что для выполнения нужно использовать TDD.
    Если надо, то допиливаешь план руками, а он это потом будет делать.

    Вот только что для качества тестов мы в команде используем файлик с описанием договоренностей по тестам (в моем случае Python pytest): как называть, куда класть, какие либы для тестов использовать и т. д. Но это у каждой команды или проекта свое должно быть, тут универсальных подходов нет.

    + к предыдущему комментатору, что надо очень тщательно прописывать бизнес-логику или еще желательно тест-кейсы ему скормить, чтобы наверняка было, и то лажает периодически.