Grype: сканирование уязвимостей образов и файлов

Логотип Grype

Быстрые ссылки

Установка Grype
Базовые сканы
Сканирование файловой системы
Фильтрация уязвимостей
Игнорирование уязвимостей
Работа с SBOM
Настройка вывода Grype
База уязвимостей
Руководство действий и чеклисты
Краткое резюме

Grype — это открытый сканер уязвимостей, который обнаруживает проблемы в контейнерных образах и директориях на файловой системе. Grype разрабатывается Anchore, но поставляется как автономный исполняемый файл. Это делает его быстрым для освоения и лёгким для интеграции в локальные утилиты и CI-пайплайны.

Почему сканировать? Известные уязвимости попадают в ваше ПО через устаревшие пакеты ОС, уязвимые зависимости языков программирования или небезопасные базовые образы. Регулярное сканирование артефактов помогает выявлять и исправлять проблемы до того, как злоумышленник ими воспользуется.

Установка Grype

Grype распространяется в виде предварительно собранных бинарников для форматов:

deb

rpm

а также исходников для Linux и релизов для macOS. Самый простой способ — взять последний релиз на GitHub и установить через пакетный менеджер или просто скопировать бинарник в каталог, включённый в PATH.

Автоматическая установка через скрипт — удобно для локальных тестовых машин и CI-агентов:

curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

Проверьте работоспособность командой grype. CLI выведет список доступных команд и опций.

Советы по установке

Для серверов в изолированных сетях скачайте бинарник заранее и проверьте контрольную сумму релиза. Проверки подписей зависят от релиза проекта.
На macOS можно использовать Homebrew, если доступен релиз для вашей версии.

Базовые сканы

В простейшем виде Grype принимает единственный аргумент — образ контейнера или путь на файловой системе для сканирования. Для образов используйте валидный тег реестра. Grype использует доступные Docker-креденшелы для скачивания образов из Docker Hub и приватных реестров.

Пример сканирования образа с Docker Hub:

grype alpine:latest

Если у вас есть экспортированный образ в tar-архиве, тоже можно сканировать:

grype saved-image.tar

При первом запуске Grype автоматически скачивает свою базу уязвимостей. Сейчас её размер находится в пределах сотен мегабайт (зависит от релиза). После загрузки базы, Grype извлечёт имена пакетов из образа, сопоставит их с базой и покажет найденные уязвимости.

Снимок экрана: сканирование контейнера Grype

Результаты выводятся в виде таблицы в терминале. Для каждой записи вы увидите идентификатор уязвимости (CVE), имя пакета и уровень серьёзности. Если уязвимость исправлена в более новой версии пакета — в колонке FIXED-IN появится версия исправления. Это помогает быстро понять, можно ли устранить проблему через обновление пакета.

Grype поддерживает пакеты популярных дистрибутивов Linux, а также менеджеры пакетов и форматы зависимостей: RubyGems, NPM/Yarn, Python (Egg, Wheel, Poetry), Java-модули (JAR, WAR, EAR, JPI, HPI) и другие.

Советы по интерпретации результатов

Сначала сортируйте по уровню серьёзности и по наличию FIXED-IN.
Для библиотек пользовательского кода смотрите на transitive-отношения (кто вызывает зависимость).
Если версии пакетов в образе фиксированы (pin), учтите трудоёмкость обновления.

Сканирование файловых систем

Grype позволяет сканировать директории на машине. Это полезно, когда вы хотите найти уязвимости в исходниках и зависимостях до сборки образа. Используйте префикс dir: и укажите путь к корню проекта:

grype dir:/example-dir

Grype просматривает совместимые артефакты в указанной директории, индексирует найденные файлы и проверяет их на предмет известных уязвимостей.

Снимок экрана: сканирование файловой системы Grype

Сканирование директории возвращает те же типы результатов, что и сканирование образов. Для больших проектов это может занять несколько минут — планируйте время для CI или локальных проверок.

Полезные сценарии

Локальная проверка перед коммитом: подключите Grype к pre-commit или запустите в локальном скрипте.
Проверка монорепозиториев: фильтруйте по поддиректориям, чтобы сократить время сканирования.
Анализ зависимостей перед сборкой образа: используйте для раннего обнаружения.

Фильтрация уязвимостей

Grype поддерживает флаги фильтрации, которые помогают сузить отчёт до интересующих вас уязвимостей или опций разрешения:

--only-fixed — показывать только уязвимости, которые уже закреплены в более новых версиях пакетов.
--fail-on high — завершить с ошибкой при обнаружении уязвимости уровня high или выше. Вместо high можно подставить critical, high, medium или low.

Примеры использования в CI

В CI можно настроить пайплайн так, чтобы сборка падала при fail-on high и прошла при medium и ниже.
Для релизов стадии production можно включить --only-fixed, чтобы заранее узнать, какие уязвимости уже закрыты.

Игнорирование уязвимостей

Игнорирование полезно для исключения ложных срабатываний или для временного принятия риска (например, когда уязвимость не применима к вашему использованию пакета). Игнорирование делается через конфигурационный YAML-файл Grype.

Пример минимального файла игнорирования:

ignore:
  - vulnerability: CVE-2021-12345

Игнорирование по типу пакета — пример для npm:

ignore:
  - package:
      type: npm

Сохраните конфигурацию как .grype.yaml или .grype/config.yaml в рабочей директории. Grype автоматически подхватит файл при запуске. Также поддерживается глобальный конфиг ~/.grype.yaml. Конфигурации из рабочей директории и глобальной будут объединены при запуске.

Поведение при игнорировании

Игнорируемые уязвимости не влияют на код выхода Grype.
В JSON-отчёте они попадают в поле ignoredMatches.
В терминальном табличном отчёте такие записи обычно не показываются.

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

Шаблон заметки об игнорировании

Дата принятия решения
Кто принял
Причина (например, неэксплуатируемый код, устаревшая среда)
План пересмотра (дата/условие)

Работа с SBOM

Grype может использовать SBOM, сгенерированные Syft (тоже проект Anchore). Syft создаёт список зависимостей образа, который затем можно проверить Grype.

Пример создания SBOM в формате JSON:

syft alpine:latest -o json > alpine-sbom.json

Сканирование SBOM через Grype:

grype sbom:/alpine-sbom.json

Когда использовать SBOM

Если вы уже индексировали образы и хотите периодически перепроверять зависимости без повторного скачивания образа.
В изолированных средах, где прямой доступ к реестру ограничен.
Для интеграции в системы управления рисками и архивации списка зависимостей.

Совет: храните SBOM рядом с артефактами сборки в CI, чтобы всегда иметь точную историческую картину зависимостей.

Настройка вывода Grype

Grype поддерживает четыре формата вывода. Переключение происходит через флаг -o:

table — по умолчанию, удобная таблица для терминала.
json — подробный JSON-отчёт, хорошо подходит для архивирования и автоматизированной обработки.
cyclonedx — CycloneDX-совместимый XML, пригоден для SBOM-пайплайнов.
template — пользовательский вывод с использованием Go-шаблонов.

Формат template принимает путь к файлу Go-шаблона. Пример использования:

grype alpine:latest -o output-template.tmpl

Пример простого шаблона CSV (фрагмент):

{{range .Matches}}{{.Vulnerability.ID}},{{.Artifact.Name}},{{.Vulnerability.Severity}}
{{end}}

Шаблон может ссылаться на предоставленные Grype переменные и генерировать HTML, Markdown, CSV или любую другую структуру.

Практические рекомендации

Используйте json для CI-артефактов и хранения результатов.
Для интеграции с системами визуализации или баг-трекерами эксплуатируйте шаблоны.

База уязвимостей

База уязвимостей Grype хранит сведения о всех известных уязвимостях. После загрузки кешируется локально и переиспользуется до появления обновления. Обычно ручные действия не требуются.

Команды для управления локальной базой:

grype db check

grype db update

Если вы разворачиваете Grype в окружении без доступа в Интернет (air-gapped), заранее скачайте базу и поместите её в нужный каталог. По умолчанию Grype периодически проверяет обновления базы. Отключить автоматические проверки можно, установив переменную окружения:

export GRYPE_DB_AUTO_UPDATE=false

Когда принудительное обновление нужно

Подготовка образов и агентов для изолированных сред.
Подготовка отчётов перед крупным релизом.
Если вы заметили расхождения между результатами Grype и другими источниками — обновите базу и повторите скан.

Руководство действий при обнаружении уязвимости

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

Классифицируйте уязвимость по уровню риска: critical, high, medium, low.
Проверьте колонку FIXED-IN. Если фикс есть — спланируйте обновление зависимости или базового образа.
Оцените воздействие на ваше приложение: задействована ли уязвимая функция в вашем сценарии.
Если обновление невозможно, примените временные меры: ограничение сетевого доступа, конфигурационные фиксы, WAF-правила.
Документируйте решение и сроки повторной проверки.

Критерии приёмки

Для каждой уязвимости уровня high/critical есть назначенный ответственный.
Если доступна исправленная версия, план обновления внесён в задачу и срок.
Если уязвимость отмечена как принятая (ignored), в документе есть причина и срок пересмотра.

Чеклист для ролей

Разработчик:

Запустить grype dir: локально перед PR.
Описать, какие зависимости обновлены и почему.

DevOps/CI инженер:

Интегрировать grype в пайплайн сборки.
Настроить артефакт json и хранить его с билдами.

Инженер по безопасности:

Периодически сканировать production-образы.
Поддерживать правила игнорирования и аудиты принятий риска.

План действий при инциденте (runbook)

Тригер: обнаружен CVE уровня critical в используемом образе.
Оповестить ответственных групп — Dev, SecOps и релевантных владельцев сервиса.
Оценить эксплойтабельность (можно ли использовать уязвимость извне).
Если есть фикс — подготовить тестовую сборку с обновлённой зависимостью и запустить регрессии.
Развернуть обновление на канаре или тестовом окружении, мониторить метрики и логи.
При успешной проверке — промотать обновление в продакшн и закрыть инцидент.

Если фикс отсутствует:

Временно изолируйте сервис, внедрите сетевые/конфигурационные ограничения и подготовьте план мониторинга.

Дополнительные материалы: шаблоны и примеры

Пример .grype.yaml с комментарием (фрагмент):

ignore:
  - vulnerability: CVE-2021-12345
  - package:
      name: left-pad
      version: 1.3.0
      type: npm

Пример CI-скрипта (bash) для GitLab CI, который скачивает Grype и запускает сканирование:

script:
  - curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
  - grype my-registry.example.com/my-app:$CI_COMMIT_SHA -o json > grype-report.json
  - cat grype-report.json
  - if grype my-registry.example.com/my-app:$CI_COMMIT_SHA --fail-on high; then echo "No high vulnerabilities"; else exit 1; fi

Пример Go-шаблона для преобразования в CSV (файл output-template.tmpl):

Vulnerability,Package,Severity,FixVersion
{{range .Matches}}{{.Vulnerability.ID}},{{.Artifact.Name}},{{.Vulnerability.Severity}},{{index .Vulnerability.FixVersions 0}}
{{end}}

Когда Grype может не подойти

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

Альтернативные подходы

Использовать коммерческие сканеры с поддержкой vulnerability-management и SLA.
Комбинировать Grype с другими инструментами (например, Clair, Trivy, Snyk) для кросс-проверки результатов.

Модель зрелости использования Grype

Уровень 1 — локальные проверки разработчиков перед коммитом.
Уровень 2 — интеграция в CI с артефактами JSON.
Уровень 3 — регулярные сканы образов в реестре и отчётность для безопасности.
Уровень 4 — автоматизированное управление инцидентами и связка с системой трекинга уязвимостей.

Выход на следующий уровень требует политики реагирования и ответственных владельцев.

Краткая памятка (cheat sheet)

Сканирование образа: grype alpine:latest
Сканирование tar-архива: grype saved-image.tar
Сканирование директории: grype dir:/path
Использование SBOM: grype sbom:/path/to/sbom.json
Принудительное обновление базы: grype db update
Отключение авто-обновления: export GRYPE_DB_AUTO_UPDATE=false

1‑строчный глоссарий

SBOM — Software Bill of Materials, список компонентов и зависимостей.
CVE — идентификатор уязвимости в публичных базах.
FIXED-IN — версия пакета, в которой уязвимость исправлена.
ignore — список исключений для Grype.

Риск-матрица и смягчения (качественно)

Critical/High: немедленное расследование, план обновления или временные ограничения доступа.
Medium: запланированное обновление в спринте, мониторинг.
Low: оценка релевантности, документирование и регулярный пересмотр.

Тесты и критерии приёмки

Тест: запуск сканирования в CI должен вернуть код 0 при отсутствии high/critical уязвимостей (с настройкой --fail-on).
Критерии приёмки: JSON-отчёт создаётся и сохраняется как артефакт сборки; для всех high/critical уязвимостей назначены ответственные и сроки.

Социальные материалы

Краткое объявление для команды (≤200 слов):

Grype — лёгкий инструмент для поиска уязвимостей в контейнерных образах и директориях. Мы добавили его в наш локальный набор инструментов и CI. Пожалуйста, запускайте grype dir: перед PR и обращайте внимание на столбец FIXED-IN в отчётах. Инженеры безопасности будут регулярно проверять артефакты и помогать с планированием обновлений.

Социальный превью (OG):

OG title: Grype — быстрое сканирование уязвимостей
OG описание: Лёгкий CLI-сканер для образов и файловых систем. Инструкции по установке, конфигурации и интеграции в CI.

Краткое резюме

Grype упрощает обнаружение известных уязвимостей в образах и директориях. Инструмент легко запускать локально и интегрировать в CI. Для продакшн-процессов добавьте политики реагирования, храните JSON-артефакты и назначайте ответственных за критические находки.

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