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

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

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

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

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

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

  • сформировать модель угроз;

  • выявить слабые места в архитектуре;

  • предложить сценарии атак;

  • спроектировать автоматизированные тесты безопасности.

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

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

Единая точка оркестрации: 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 сделал её единым воспроизводимым механизмом.

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