DevSecOps для самых маленьких: 6\n. Сканирование кода и зависимостей: почему нельзя идти в Зону без детектора
В «Сталкере» ты идёшь по Зоне и замечаешь впереди странную рябь воздуха. На первый взгляд ничего особенного, обычная земля. Но пока ты не проверил участок, ты не знаешь, что там. Может, безопасное место. А может, «жарка», которая сожжёт за секунду, или «трамплин», который подбросит в небо. Иногда рядом лежит ценный артефакт, ради которого стоило рискнуть. Сканирование кода и зависимостей работает так же. Код выглядит нормально, приложение собирается, тесты проходят. Но это не значит, что внутри нет уязвимостей, случайно оставленных токенов или небезопасных настроек.
И важный нюанс: детектор находит опасность, но не устраняет её. Сканер не исправит код сам. Он покажет проблему, иногда её серьёзность и способ исправления, а проверять и чинить будет команда.
Виды сканирования
SAST (Static Application Security Testing) анализирует исходный код без запуска. Находит, например, SQL-запрос, в который напрямую подставлены данные пользователя. Инструменты: Semgrep, Bandit (для Python). Находка не всегда настоящая уязвимость: инструмент может не видеть контекст, поэтому её нужно проверять.
SCA (Software Composition Analysis) ищет известные уязвимости (CVE) в сторонних библиотеках. Инструменты: Trivy, OWASP Dependency-Check. Одного package.json или requirements.txt мало: смотри фактически разрешённые версии и SBOM. И CVE ещё не значит, что ты уязвим: учитывай версию, применимость и достижимость.
Поиск секретов находит токены, пароли и ключи в коде и истории Git. Инструменты: Gitleaks, TruffleHog. Бывают ложные срабатывания, и настоящий секрет может не подойти под шаблон.
DAST (Dynamic Application Security Testing) проверяет работающее приложение запросами и разбирает ответы. Инструмент: OWASP ZAP. Запускай только на тестовом стенде: активные проверки на проде могут изменить данные. Полнота зависит от того, какие страницы и API сканер увидел.
IaC и конфигурации: Terraform, манифесты Kubernetes, Helm, Dockerfile. Инструменты: Trivy, Checkov. Разработчик получает предупреждение прямо в pull request.
Образы контейнеров: системные пакеты и библиотеки внутри образа. Инструменты: Trivy, Grype. Не заменяют остальные виды проверок.
Важно про Trivy
В марте 2026 Trivy стал жертвой атаки на цепочку поставок. 19 марта злоумышленники (группа TeamPCP) опубликовали вредоносные бинарь v0.69.4 и образы, а теги GitHub Actions trivy-action и setup-trivy перенаправили на вредоносные коммиты. Зловред воровал учётные данные из CI. Сканер, который должен был охранять пайплайн, сам стал входом в него.
Что с этим делать:
Фиксируй GitHub Actions по SHA коммита, а не по тегу: тег можно переписать.
Образы и бинари закрепляй по digest и проверяй версию по официальному уведомлению.
Если твои пайплайны запускали затронутые версии, считай секреты этих пайплайнов скомпрометированными и ротируй их.
Источники: Barracuda, Phoenix Security.
Минимальный пайплайн
# .gitlab-ci.yml (фрагмент). Версии и digest бери из проверенных релизовstages: [scan]
secrets: stage: scan image: name: ghcr.io/gitleaks/gitleaks:<версия>@sha256:<digest> entrypoint: [''] variables: GIT_DEPTH: 0 script: - gitleaks detect --source . --redact --verbose
sast: stage: scan image: semgrep/semgrep:<версия>@sha256:<digest> script: - semgrep scan --config p/owasp-top-ten --error
image-scan: stage: scan image: name: aquasec/trivy:<версия>@sha256:<digest> entrypoint: [''] script: # на старте поставь --exit-code 0: только отчёт, без блокировки - trivy image --severity HIGH,CRITICAL --exit-code 1 $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
Для приватного реестра Trivy понадобятся учётные данные. DAST запускается отдельно и только на стенде:
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://stage.example.com
Что делать с находками
Первый запуск на непроверявшемся проекте даст десятки или сотни находок. Часть окажется ложной, часть не затронет твой сценарий, а часть будет по-настоящему опасной. Это нормально. Ошибка — либо отключить сканер из-за шума, либо сделать все находки блокирующими и остановить разработку. Лучше так:
Разобрать: что найдено, где и применимо ли к приложению.
Расставить приоритеты: серьёзность, возможность эксплуатации, достижимость кода, доступность компонента, наличие исправления, последствия. CVSS — только часть картины.
Исправить важное: подтверждённые критичные проблемы и действующие секреты.
Оформить исключения: обоснование, ответственный, срок пересмотра.
Подстроить правила, не скрывая целые категории проблем.
Перепроверить после исправления.
Блокируй релиз при подтверждённой критичной проблеме; для секретов и опасных конфигураций определи отдельные критерии. Не каждая находка должна останавливать разработку, но у каждого серьёзного риска должны быть ответственный и срок.
Российские решения
AppSec.Code, PT Application Inspector, Solar appScreener, AppSec.Wave, PVS-Studio, SASTAV, СКАТмен (Инферит). Они не взаимозаменяемы: различаются языками, методами анализа, интеграциями и лицензиями; PVS-Studio в первую очередь про статический анализ кода. Сверь поддерживаемые языки и интеграцию с твоим CI/CD, а если нужны сертификаты, проверь их отдельно по реестру.
План внедрения
Шаг 1. Секреты. Gitleaks локально и в CI. Проверь, как команда реагирует на находки, и отзови утёкший токен.
Шаг 2. Зависимости и образы. Trivy или Grype. Сначала собирай отчёты и смотри, что встречается чаще всего, потом вводи критерии блокировки.
Шаг 3. SAST и конфигурации. Semgrep или анализатор для основного языка плюс проверка IaC. Реши, какие нарушения блокируют merge.
Шаг 4. DAST на стенде. OWASP ZAP в контролируемых сценариях, без продакшена и реальных данных.
Шаг 5. Постоянный контроль. Новые уязвимости находят и после релиза, поэтому периодически перепроверяй опубликованные образы и зависимости.
Шаг 6. Метрики. Время от находки до исправления, доля ложных срабатываний, число исключений без актуального обоснования.
Детектор в руках сталкера помогает заметить аномалию, но обходить её приходится самому. Сканер показывает, где искать проблему, а дальше нужны люди, приоритеты, исправления и повторная проверка. Не надо строить идеальный DevSecOps за день: запусти одну проверку, научись разбирать её результаты и только потом расширяй покрытие.
Обсуждаем статьи в Telegram-канале. Недушный ИнфоБез.
