РУКОВОДСТВО 10 · ВЕБ-ПРИЛОЖЕНИЯ И API
Как устроить проверки безопасности в CI/CD
Проверка в CI должна относиться к конкретной сборке и давать релизному процессу понятный результат. Запускайте подготовленные сценарии на staging до продвижения в production. HTTP 202 означает принятую заявку, а не завершённый скан. Находка, техническая ошибка и неполное покрытие требуют разных решений; проверка после публикации не отменяет уже состоявшийся деплой.
Подключить проверку к CI/CDПонадобятся вход, подтверждение владения и согласие. Для авторизованных сценариев, мониторинга и CI нужен Pro или Business.
Содержание
Как проверить регрессию прав доступа в GitHub Actions
Подготовка сценария для конкретного коммита
После выкладки кандидата на staging запустите проверку для этой среды и ревизии коммита. Оставьте неизменными тестовые роли, приватный объект и ожидание для доступа A к объекту B. Сохраните JSON-отчёт как артефакт запуска.
Условия остановки релиза
У примера CLI три исхода: 0 — порог пройден, 1 — обнаружена блокирующая находка, 2 — результат неполный или произошла ошибка. И 1, и 2 должны остановить автоматическое продвижение релиза.
Первичные источники: GitHub: безопасность Actions
Краткий ответ и условия проверки
Проверка релиза должна отличать находки от незавершённого запуска. Таймаут, недоступный сканер или истёкший аккаунт не должны превращаться в успешный результат.
Изолированный staging, ограниченный CI-токен, идентификатор релиза и явная политика ошибок.
| Проверка | Ожидаемое доказательство |
|---|---|
| Действие | Запустите чистый, уязвимый и незавершённый примеры; проверьте исход CI и сохраните отчёт именно этого релиза. |
| Положительный и отрицательный контроль | Уязвимый пример даёт доказательство, исправленный — нет. Успешный контрольный запрос подтверждает доступность цели. |
| Блокировка или недостающие данные | Отметьте проверку как пропущенную или незавершённую с причиной. Отсутствие аккаунта, ответ WAF и таймаут не означают отсутствие проблем. |
| После исправления | Повторите проверку той же цели, аккаунта и объекта. Сохраните исходное доказательство и новый результат; покрытие ограничено выполненными сценариями. |
Продолжить: Посмотреть пример отчёта
Продолжить: Покрытие и необходимые данные
Что проверять на разных этапах
На PR удобно проверять исходники и состав зависимостей отдельными инструментами. На staging выполняется DAST работающего приложения с тестовыми аккаунтами. После production проверяется опубликованный контур и актуальность инвентаря. Не приписывайте одному этапу покрытие остальных. Scantelio не объявляет себя полным SAST-анализатором, а post-deploy запуск не является барьером перед уже завершённой публикацией.
Что подготовить перед интеграцией
Подготовьте проект, подтверждённую область, согласие, staging, тестовые аккаунты и объекты, проектный токен и квоту. Токен храните в CI secrets и ограничьте проектом. Внешние непроверенные PR не должны получать эти секреты. Зафиксируйте revision и deployment URL кандидата; они должны соответствовать действительно развёрнутому приложению, а не просто произвольным строкам из workflow.
Первичные источники: GitHub: безопасность Actions · OWASP: CI/CD
Продолжить: Проверка безопасности API с тестовыми аккаунтами
Подключить проверку к CI/CDРабочий пример запуска
В скачиваемом примере используется существующий cli/scantelio.mjs из этого репозитория, Node 22+ и реальные параметры --project, --environment, --deployment и --revision. SCANTELIO_TOKEN передаётся через окружение, не аргументом команды. Сохраните проверенную копию CLI и её контрольную сумму в своём репозитории; не запускайте бесконтрольно меняющийся удалённый файл. Пример не представляет собой отдельный опубликованный GitHub Action.
# Задайте SCANTELIO_API_URL, SCANTELIO_TOKEN и параметры проекта в CI.
export SCANTELIO_REVISION="$GITHUB_SHA"
bash run-ci.sh
# Сохраните scantelio-report.json как артефакт даже при ненулевом exit code.Как дождаться результата
CLI получает run_id и опрашивает состояния queued, preparing и running до терминального результата. У него есть ограничение ожидания; сетевой сбой даёт ошибку, а не успешную проверку. Повторный запрос с тем же SCANTELIO_IDEMPOTENCY_KEY должен возвращать тот же запуск. Отмена задания CI сама по себе не гарантирует отмену скана: при необходимости вызовите документированный endpoint отмены и отдельно сохраните результат.
Первичные источники: GitHub: безопасность Actions · OWASP: CI/CD
Продолжить: IDOR и BOLA: как проверить доступ к чужим данным в своём API
Правила допуска релиза
Базовая CI-интеграция доступна Pro. Business добавляет командные настройки политики и соответствующие функции управления. Политика определяет требуемые правила, порог серьёзности и обработку неполного покрытия. Качество поддерживаемого обнаружения в Pro и Business одинаковое. Не используйте continue-on-error как скрытый способ объявить неизвестный результат пройденным.
| Exit code CLI | Смысл | Действие pipeline |
|---|---|---|
| 0 | Условия gate выполнены | Разрешить следующий этап по вашей политике |
| 1 | Блокирующая подтверждённая находка | Остановить выпуск |
| 2 | Неполная проверка или ошибка | Не выдавать зелёный статус; разобраться и повторить |
Как обращаться с baseline и исключениями
Режим new требует действительного baseline из подходящего предыдущего запуска. Старая находка не исчезает из задачи команды: ей нужны решение, владелец и срок. Техническая ошибка сравнения не является отсутствием новых проблем. Если команда допускает исключение, оно должно иметь объяснение и контролируемое применение. Обновляйте baseline осознанно, а не автоматически после каждого проваленного запуска.
Первичные источники: GitHub: безопасность Actions · OWASP: CI/CD
Продолжить: Мониторинг CVE и зависимостей вашего приложения
Как защитить pipeline
Выдавайте workflow минимальные permissions, закрепляйте Actions по проверенным версиям или commit SHA и не запускайте недоверенную ветку с привилегированными секретами. Не печатайте токен, приватный deployment URL или полные доказательства в общий лог. Ограничьте доступ и срок хранения отчётов. Секрет из окружения может попасть в лог через ошибку приложения, поэтому одной автоматической маскировки недостаточно.
Как проверить всю цепочку
Проверьте проблемного кандидата, исправленного кандидата и отдельно неполное покрытие. В отчёте и задании должен совпадать revision; сохраните run_id как артефакт процесса. Учебный тест CLI воспроизводит решения 0, 1 и 2 на локальном контролируемом API. Это проверка контракта интеграции, а не заявление о выполнении вашего GitHub pipeline или production-деплоя. Полную цепочку своей среды нужно подтвердить после подключения.
Продолжить: Утечка .env .git или API-ключа: как закрыть доступ и проверить исправление
Воспроизводимые примеры и материалы
Учебные данные — синтетические. Файлы не содержат действующих ключей или клиентской базы. Запускайте примеры только в собственной изолированной тестовой среде.
Вопросы и ответы
CI доступен в Pro?
Да. Настраиваемые командные политики и дополнительные функции Business рассматриваются отдельно от базового запуска.
Можно блокировать только новые находки?
CLI поддерживает режим new с подходящим baseline. Без действительного baseline нельзя объявлять сравнение успешным.
Что делать при недоступном сканере?
Применить явно принятую политику сбоя. Не превращать техническую ошибку в passed.
Проверка после деплоя предотвращает деплой?
Нет. Для барьера проверку staging нужно поставить перед продвижением в production.
Можно передать production-админский токен?
Используйте минимальные тестовые права и подходящее окружение. Полномочия production-администратора не должны быть стандартным входом проверки.
Каждая CI-проверка расходует квоту?
Да, действует общий учёт запуска. Повторная доставка того же идемпотентного запроса не должна создавать второй оплачиваемый запуск.
Автор и источники
Редакция Scantelio: методика и границы проверки. Проверка примера: 2026-11-02.
Перенесите проверку на свой проект
Подключить проверку к CI/CDВыберите свой проект после входа. Ничего не сканируется без подтверждения и согласия.