Главная уязвимость ИИ-кодогенерации
Основная претензия к коду, написанному искусственным интеллектом, заключается в низком уровне его надежности и безопасности. Стремясь как можно быстрее выдать работающее решение, языковые модели часто пренебрегают тестами, игнорируют обработку крайних случаев и допускают критические уязвимости вроде 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)

andy-takker
17.06.2026 13:04Мне казалось, что с этим всем уже давно не надо заморачиваться с появлением superpowers и встренными в него brainstorming, writing-plans и test-driven-development.
Сначала просишь побрейнштормить и раскопать задачу, потом составляешь с ним подробный план и потом указываешь, что для выполнения нужно использовать TDD.
Если надо, то допиливаешь план руками, а он это потом будет делать.
Вот только что для качества тестов мы в команде используем файлик с описанием договоренностей по тестам (в моем случае Python pytest): как называть, куда класть, какие либы для тестов использовать и т. д. Но это у каждой команды или проекта свое должно быть, тут универсальных подходов нет.
+ к предыдущему комментатору, что надо очень тщательно прописывать бизнес-логику или еще желательно тест-кейсы ему скормить, чтобы наверняка было, и то лажает периодически.
Genius_Russian_Coders
На практике: если просить модель сначала написать тесты, а потом код под них — покрытие веток выходит заметно лучше. По безопасности: SQL-инъекции AI ещё ловит, а вот бизнес-логические дыры пропускает почти всегда. Ручной ревью пока не заменишь.