Безопасность в пайплайне: SAST, SCA, secret-scan

Зачем безопасность как этап CI

Найти уязвимость или утёкший токен на проде дорого. Найти их в пайплайне, до выката, дёшево. Поэтому проверки безопасности встраивают в CI как обычный этап, рядом с тестами. Три вида проверок закрывают разные риски.

SAST: твой код

SAST (Static Application Security Testing) анализирует исходный код на опасные паттерны: SQL-инъекции, небезопасная работа с файлами, слабая криптография. Это статический анализ с уклоном в безопасность, и гоняется он как линтер, на каждый push.

sast:
  stage: scan
  script:
    - run-sast-tool .        # любой подходящий статический анализатор
  allow_failure: true        # на старте не блокируем, только сообщаем

allow_failure: true полезен в начале: проверка сообщает о находках, но не валит пайплайн, пока команда не разгребёт накопленное. Потом флаг убирают и делают проверку блокирующей.

SCA: чужой код

SCA (Software Composition Analysis) проверяет не твой код, а зависимости. Большая часть уязвимостей приходит из сторонних библиотек, и их версии сверяют с базами известных уязвимостей (CVE).

Сюда же относится сканирование образа: базовый образ и установленные в нём пакеты тоже имеют уязвимости. Эту тему подробнее разбирает урок про сканирование образов.

Secret-scan: утёкшие секреты

Secret scanning ищет в коде то, чего там быть не должно: токены, приватные ключи, пароли. Разработчик случайно закоммитил ключ, и проверка ловит это до того, как он уедет в общий репозиторий.

secret-detection:
  stage: scan
  script:
    - run-secret-scanner .

Важная оговорка: если секрет уже попал в коммит, мало его удалить. Он остаётся в истории git, поэтому секрет считают скомпрометированным и меняют. Проверка нужна, чтобы поймать утечку как можно раньше.

Сканер — процесс, а не один инструмент

Конкретных сканеров много (Trivy, Grype, Clair, semgrep и другие), и они меняются. Опираться на один инструмент как на истину в последней инстанции не стоит: базы уязвимостей у них разные, бывают ложные срабатывания и пропуски, а у самих вендоров случаются инциденты. Поэтому относись к сканеру как к одному источнику сигнала, а не приговору:

• сверяй находки и приоритизируй по реальному риску, а не по числу алертов;
• держи проверку обновляемой и при возможности дублируй разными инструментами на критичных местах;
• помни, что зелёный сканер не равно «безопасно»: он ловит известное, а не всё.

Что важно запомнить

В CI встраивают три вида проверок: SAST (свой код), SCA (зависимости и образ), secret-scan (утёкшие секреты). Дешевле поймать здесь, чем на проде.

На старте проверки делают мягкими (allow_failure), потом блокирующими. Утёкший в историю секрет считают скомпрометированным и меняют, а не просто удаляют.

Сканер — процесс и один из сигналов, а не единственная истина: базы разнятся, бывают ложные срабатывания, у вендоров случаются инциденты. Зелёный сканер не означает «безопасно».

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