Большинство стартер-китов ускоряют разработку, но без системной безопасности это приводит к техническому долгу. Часто безопасность внедряется позже, фрагментарно и зависит от конкретного инженера. Мы решили подойти системно: при создании AI-стартера для интеграций с Битрикс24 мы встроили безопасность в саму архитектуру с помощью ИИ-агентов.

Как ИИ помог усилить безопасность

ИИ-агенты не заменяли инженеров, а выступали в роли ассистентов. Они помогли:

• сформировать модель угроз;
• выявить слабые места в архитектуре;
• предложить сценарии атак;
• спроектировать черновики автоматизированных тестов.

Позже эти наработки дорабатывались вручную. Благодаря такому подходу безопасность стала частью стартер-кита: каждое приложение, созданное на его основе, автоматически наследует встроенные защитные механизмы.

Единая точка оркестрации: security-tests.sh

Ключевой элемент — скрипт ./scripts/security-tests.sh. Он запускает все проверки в едином сценарии, что обеспечивает:

• простоту использования — разработчику не нужно помнить отдельные команды;
• воспроизводимость — один и тот же сценарий работает и локально, и в CI;
• надёжность — невозможно пропустить одну из проверок;
• централизацию правил безопасности.

Это точка входа в security-пайплайн: один запуск — полный аудит.

Важно: локальный скрипт — это удобство для разработки, но не замена CI/CD. Критические проверки дублируются в пайплайне, чтобы исключить возможность их отключения через изменения в репозитории.

Что делает security-tests.sh

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

1. Аудит зависимостей

Проверяется:

• состав production-зависимостей;
• наличие известных уязвимостей (CVE);
• уровень критичности.

Если найдена уязвимость высокого уровня — процесс завершается с ошибкой. Это важно: современные атаки часто идут через цепочку поставок. Даже безопасный код может быть скомпрометирован через уязвимую библиотеку.

Если патча ещё нет или обновление ломает функциональность, предусмотрен механизм осознанных исключений (allowlist):

1. фиксация риска;
2. документирование причины;
3. временное разрешение использования уязвимой версии;
4. обязательное возвращение к исправлению позже.

ИИ-агенты помогли усилить fail-fast поведение и исключить «молчаливые» предупреждения.

2. Проверка утечек секретов

Самая частая причина инцидентов — человеческая ошибка. Сценарий ищет:

• .env-файлы в репозитории;
• хардкод API-ключей, токенов, webhook URL.

При обнаружении потенциальной утечки тесты останавливаются. Это позволяет выявить проблему до деплоя, независимо от внимательности разработчика.

Но одной проверки недостаточно. Также учитываются:

• ротация ключей при утечке;
• очистка истории git;
• контроль логов CI/CD;
• использование секрет-хранилищ.

ИИ помог расширить шаблоны поиска и выявить нетривиальные сценарии утечек.

3. Валидация конфигурации и окружения

Проверяется:

• корректность конфигурационных файлов;
• отсутствие небезопасных значений по умолчанию;
• соответствие production-требованиям.

Например, отключены ли debug-флаги, корректно ли используются переменные окружения, нет ли опасных fallback-настроек.

Используются инструменты статического анализа: линтеры, Semgrep, OWASP. ИИ помог выявить конфигурационные «серые зоны», которые легко пропустить вручную.

4. Контроль контейнерной сборки

Контейнер — часть attack surface. Проверяется:

• состав Docker-образа (уязвимости в базовом образе и пакетах);
• наличие лишних пакетов (компиляторы, сборщики);
• разделение build и runtime-слоёв (multi-stage build);
• минимизация финального образа.

Для анализа используется инструмент вроде Trivy. Он проверяет структуру Dockerfile, выявляет избыточные компоненты и оптимизирует runtime-слой.

Также учитываются практики эксплуатации:

• запуск не от root;
• контроль capabilities;
• проверка подписи образов (supply chain integrity).

Это снижает поверхность атаки и делает среду более предсказуемой.

Почему оркестрация важна

Разрозненные проверки ведут к пропуску уязвимостей, особенно в растущих командах. Единый скрипт security-tests.sh устраняет эту проблему: один вход, один сценарий, единая логика отказа. Безопасность становится неотъемлемой частью процесса, независимой от человека.

Как ИИ помог разработать тесты

ИИ-агенты:

• анализировали структуру проекта;
• предлагали векторы атак;
• генерировали черновики тестов;
• выявляли логические пробелы;
• валидировали сценарии отказа.

Ключевой эффект — сокращение blind spots. ИИ работает как корректор, расширяя пространство проверки. Но эффективность зависит от качества промптов: нужно чётко описывать архитектуру, модули и риски. Тогда тесты получаются глубокими и ориентированными на реальные угрозы.

Что получают приложения на базе стартера

Каждый новый проект автоматически наследует:

• скрипт security-tests.sh;
• единый security-пайплайн;
• аудит зависимостей;
• проверку утечек секретов;
• стандартизированную CI-интеграцию;
• контроль контейнерной сборки.

Разработчику не нужно проектировать безопасность с нуля — она уже встроена. Это особенно ценно для open-source, партнёрских решений и проектов с требованиями к аудиту.

Но у подхода есть границы. Стартер не покрывает:

• работу с OAuth и scopes;
• проверку подписи вебхуков;
• защиту от CSRF;
• требования Маркетплейса Битрикс24.

Это осознанное разделение: стартер даёт фундамент, а платформенные особенности — зона ответственности разработчика.

Бизнес-ценность подхода

Компания получает:

• снижение риска инцидентов;
• экономию времени команды;
• быстрый старт новых проектов;
• единый стандарт безопасности;
• упрощение аудита;
• ускоренный онбординг разработчиков.

Безопасность «из коробки» экономит десятки часов на настройку каждого проекта.

Разработчики получают:

• одну команду для запуска;
• предсказуемое поведение;
• меньше ручной настройки;
• меньше ошибок из-за человеческого фактора.

Безопасность как архитектурный стандарт

Стартер-кит — это не просто шаблон. Это стандартизированная инженерная среда. ИИ-агенты помогли спроектировать систему тестов, а security-tests.sh сделал её воспроизводимой. Теперь безопасность — не реакция на инциденты, а часть архитектуры с первого коммита.

Привет! Меня зовут Владимир Верхотуров, я занимаюсь DevRel в Битрикс24. Я обеспечиваю связь наших партнёров и клиентов и внутренних команд, чтобы интеграции и решения на базе REST и других инструментов запускались быстро, стабильно и предсказуемо.

Сегодня хочу рассказать, как устроена безопасность внутринашего AI-стартера, который упрощает и ускоряет разработку кастомных интеграций с порталом Битрикс24. Если интересно посмотреть, как он работает в деле, вот 2 статьи с примерами:

• Пишем первое приложение с AI-стартером, чтобы видеть прибыли и убытки
• Добавляем в бизнес-портал Битрикс24 роботов для автоматизации

Что будет в этой статье:

• Как стабильно внедрять в проекты безопасность
• Единая точка оркестрации: security-tests.sh
• Что делает security-tests.sh
• Почему оркестрация принципиально важна
• Как ИИ помог нам разработать сами тесты
• Что получают все приложения на базе стартера
• Бизнес-ценность подхода
• Безопасность как архитектурный стандарт

Как стабильно внедрять в проекты безопасность

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

При создании стартер-кита мы решили системно подойти к вопросу безопасности. Для усиления архитектурных решений мы использовали ИИ-агентов как инженерный инструмент. Агенты помогли:

• сформировать модель угроз;
• выявить слабые места в архитектуре;
• предложить сценарии атак;
• спроектировать автоматизированные тесты безопасности.

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

В результате безопасность встроена в сам стартер. Каждое приложение, созданное на его базе, автоматически наследует этот уровень защиты.

Единая точка оркестрации: security-tests.sh

Ключевой элемент всей системы — оркестратор тестов:

./scripts/security-tests.sh

Скриптsecurity-tests.shзапускает весь набор проверок и объединяет их в единый сценарий. Это кажется простой деталью, но архитектурно это принципиально важно. В чём преимущества:

• разработчику не нужно помнить отдельные команды;
• упрощает интеграцию с CI: один сценарий используется и локально, и в пайплайне сборки, поэтому результаты проверки всегда воспроизводимы.
• невозможно забыть одну из проверок;
• правила безопасности централизованы.

Получается, чтоsecurity-tests.sh— это точка входа в security-пайплайн проекта: один запуск — полный аудит.

Здесь есть важное архитектурное ограничение: локальный скрипт — это удобный инструмент для старта и разработки, но не единственный уровень защиты. Для production-сценариев критические проверки должны дублироваться на стороне CI/CD-инфраструктуры.  Это исключает ситуацию, когда проверки можно отключить изменением скрипта в репозитории.

Поэтому в итоге: локально получаем быстрый фидбек разработчику, а в CI — независимая и неизменяемая проверка.

Что делает security-tests.sh

Скрипт последовательно запускает специализированные проверки. Важно не просточтопроверяется, акак— с fail-fast логикой и предсказуемым поведением.

Если обнаружена критическая проблема — сборка сразу останавливается. Это позволяет избежать ситуации, когда предупреждение остаётся незамеченным и уязвимость попадает в production.

1. Аудит зависимостей

Проверяются:

• состав production-зависимостей;
• наличие известных уязвимостей (CVE);
• критичность найденных проблем.

Если обнаружены уязвимости высокого уровня — процесс завершается с ошибкой.

Почему это важно: современные атаки всё чаще происходят через цепочку поставки (supply-chain). Даже если ваш код безопасен, уязвимая зависимость может стать точкой входа.

Механизм проверки простой: анализируются зависимости проекта и версии библиотек.Если версия пакета известна как уязвимая — например, уязвимость исправлена в версии 5.7, а проект использует 5.6 — система сразу сигнализирует об этом.

Такая ситуация встречается довольно часто: разработчики обновляют зависимости не сразу, а менеджеры пакетов могут сообщать о наличии новой версии, но не блокируют сборку. Наш security-pipeline может остановить сборку, если используется версия с известной уязвимостью.

Но в реальной разработке есть нюансы. Иногда патча ещё нет. А иногда обновление ломает функциональность. Поэтому в пайплайне предусмотрен механизм осознанных исключений (allowlist):

1. Команда фиксирует риск.
2. Документирует причину.
3. Временно разрешает использование уязвимой версии.
4. Возвращается к исправлению позже.

Это важно, потому что иначе разработчики начнут обходить проверки, чтобы просто «задеплоить».

На этом этапе ИИ-агенты помогли смоделировать сценарии эксплуатации, исключить «молчаливые» предупреждения, усилить fail-fast поведение.

2. Проверка утечек секретов

Самая частая причина инцидентов — не сложная атака, а человеческая ошибка. Сценарий проверяет наличие.envв репозитории, хардкод API-ключей, токены, webhook URL и другие чувствительные строки.

Если обнаружена потенциальная утечка — тесты завершаются с ошибкой. Что это даёт:

1. Ошибка выявляется сразу, а не после деплоя.
2. Проверка автоматическая и не зависит от внимательности разработчика.

Подобные ошибки появляются часто: например, ключ случайно попадает в код или в репозиторий вместе с конфигурацией. Иногда такие значения оказываются и в публичных репозиториях. Поэтому проверка анализирует не только код, но и скрипты, конфигурации и структуру проекта — чтобы убедиться, что секреты не попали в репозиторий и используются через переменные окружения.

Но одной проверки недостаточно — есть другие реальные риски. Например, если секрет попал в историю git — его удаление из текущей версии не решает проблему. Ещё секреты могут утекать через логи CI/CD, а значения могут случайно сохраняться в артефактах сборки.

Поэтому в процесс включены дополнительные практики:

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

ИИ-агенты использовались для расширения шаблонов поиска и анализа нетривиальных сценариев утечек.

3. Валидация конфигурации и окружения

Безопасность — это не только код. Что ещё проверяется:

• корректность конфигурационных файлов;
• отсутствие небезопасных значений по умолчанию;
• соответствие production-требованиям.

Например, отключены ли debug-флаги, корректно ли используются переменные окружения, нет ли небезопасных fallback-настроек.

Внутри используются стандартные инструменты статического анализа, применяемые для разных языков: например, линтеры и анализаторы вроде Semgrep или OWASP. Они проверяют типовые проблемы: включённый debug-режим, небезопасные конфигурации и потенциально опасные конструкции в коде.

В итоге ИИ помог выявить потенциальные конфигурационные «серые зоны», которые легко пропустить вручную.

4. Контроль контейнерной сборки

Контейнер — это часть attack surface, то есть всех потенциальных точек атаки. Тесты анализируют несколько вещей.

Состав Docker-образа.Уязвимости могут быть в базовом образе, системных библиотеках и пакетах, которые подтягиваются при сборке.

Наличие лишних пакетов.В Docker-образах часто остаются пакеты, которые нужны только во время сборки: компиляторы, системы сборки, пакетные менеджеры. В production-контейнере они обычно не используются, но остаются доступными для атаки.

Разделение build и runtime-слоёв.Во многих проектах используется multi-stage build: сначала приложение собирается в одном контейнере, а затем готовый результат копируется в другой, чтобы получился минимальный runtime-образ. Без этого разделения в финальный контейнер попадают лишние элементы, которые увеличивают размер контейнера и количество потенциальных уязвимостей.

Минимизация финального образапозволяет уменьшить количество библиотек, снизить attack surface и упростить проверку безопасности контейнера. Поэтому при анализе контейнера проверяется не только наличие уязвимостей, но и общая избыточность образа.

Для анализа контейнеров используется специализированный инструмент сканирования образов (например, Trivy), который проверяет:

• анализ структуры Dockerfile;
• выявление потенциальных избыточных компонентов;
• оптимизацию runtime-слоя.

Это снижает поверхность атаки и делает среду более предсказуемой.

Дополнительно мы учитываем практики реальной эксплуатации: запуск контейнера не от root, контроль capabilities и проверка подписи образов (supply chain integrity).

Вот несколько случаев, когда даже «чистый» образ может быть уязвим:

• Образ запускается с избыточными правами.
• Не проверяется его происхождение.
• В нём остались лишние инструменты.

Результат — снижение поверхности атаки и более предсказуемая среда исполнения.

Почему оркестрация принципиально важна

Частая ошибка в проектах — набор разрозненных проверок, когда безопасность разбита на несколько команд, разные конфигурации, отдельные инструменты. Тогда возникает риск, что какая-то проверка не будет выполнена. Это особенно опасно в растущих командах.

Единый скрипт security-tests.sh устраняет эту проблему, потому что с ним появляются один вход, один сценарий, единая логика отказа. Безопасность становится автоматической частью процесса, которая не зависит от человека.

Как ИИ помог нам разработать сами тесты

Что в итоге делали ИИ-агенты, чтобы сделать тесты безопасности:

• анализировали структуру проекта;
• предлагали возможные векторы атак;
• генерировали черновые тесты;
• помогали выявить логические пробелы;
• валидировали сценарии отказа.

Ключевой эффект получился в сокращении blind spots. Человек может пропустить сценарий, а ИИ помогает расширить пространство проверки. Это как автоматический корректор, который проверяет ошибки в тексте.

Эффективность работы агентов сильно зависит от качества постановки задачи. Если просто попросить агента «написать тест», результат почти наверняка будет поверхностным. Поэтому в промптах нужно расписывать всё подробнее: объяснить архитектуру проекта, указать интересующий модуль, описать, какие риски нужно проверить.

Точный подробный подход позволяет ИИ работать значительно точнее и быстрее. В итоге тесты получились неформальными и ориентированными на реальные риски.

Что получают все приложения на базе стартера

Каждый новый проект автоматически наследует:

• security-tests.sh,
• единый security-пайплайн,
• аудит зависимостей,
• проверку утечек,
• стандартизированную CI-интеграцию,
• проверку контейнерной сборки.

Разработчику не нужно проектировать безопасность заново, потому что она уже встроена в основу архитектуры. Это особенно важно для open-source сценариев, партнёрских разработчиков, проектов с требованиями к аудиту и команд, выпускающих несколько решений.

При этом у такого подхода, конечно, есть честные границы: стартер-кит даёт базовый уровень безопасности, но не покрывает всё. Что остаётся на стороне разработки:

• Корректная работа с OAuth и scopes.
• Проверка подписи входящих вебхуков.
• Защита от CSRF.
• Соответствие требованиям Маркетплейса Битрикс24.

Это осознанное разделение. Стартер даёт фундамент, а платформенные особенности — зона ответственности проекта.

Бизнес-ценность подхода

Для бизнеса это даёт не только защиту. Что ещё получает компания:

• Снижение вероятности инцидентов.
• Экономия времени команды.
• Быстрый старт новых проектов.
• Единый стандарт безопасности.
• Упрощение аудита.
• Ускоренный онбординг разработчиков.

Безопасность «из коробки» убирает десятки часов на настройку каждого нового проекта.

Разработчики  тоже получают плюсы:

• Одна команда запуска.
• Предсказуемое поведение.
• Меньше ручной настройки.
• Меньше ошибок из-за человеческого фактора.

Безопасность как архитектурный стандарт

Стартер-кит — это не просто шаблон проекта. Это стандартизированная инженерная среда.

ИИ-агенты помогли нам спроектировать систему тестов, а security-tests.sh сделал её единым воспроизводимым механизмом.

Со встроенными проверками безопасность перестаёт быть реакцией на инциденты и становится частью архитектуры — с первого коммита.