Сканер уязвимостей для образов контейнеров и файловых систем. Легко установите бинарный файл, чтобы опробовать его. Работает с Syft, мощным инструментом SBOM (программная спецификация) для образов контейнеров и файловых систем.
Повестка дня: https://docs.google.com/document/d/1ZtSAa6fj2a6KRWviTn3WoJm09edvrNUp4Iz_dOjjyY8/edit?usp=sharing (присоединитесь к этой группе, чтобы получить доступ для записи)
Всем добро пожаловать!
Чтобы узнать о вариантах коммерческой поддержки Syft или Grype, свяжитесь с Anchore.
Функции
Сканируйте содержимое образа контейнера или файловой системы, чтобы найти известные уязвимости.
Найдите уязвимости для основных пакетов операционной системы:
Поддерживает форматы изображений Docker, OCI и Singularity.
Поддержка OpenVEX для фильтрации и дополнения результатов сканирования.
Если вы столкнулись с проблемой, сообщите нам об этом с помощью системы отслеживания проблем.
Установка
Рекомендуется
завиток -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
Варианты установки скрипта:
-b : указать каталог пользовательской установки (по умолчанию ./bin ).
-d : более подробные уровни журналирования ( -d для отладки, -dd для трассировки).
-v : проверить подпись загруженного артефакта перед установкой (требуется установка cosign )
Шоколадный
Шоколадная раздача вируса поддерживается сообществом, а не распространяется ведущей командой.
шоколадная установка grype -y
Домашнее пиво
заварной кран якорь/грип
заварить установку
МакПортс
В macOS Grype можно дополнительно установить из порта, поддерживаемого сообществом, через MacPorts:
sudo порт установить grype
Примечание . В настоящее время Grype создан только для macOS и Linux.
Из источника
См. DEVELOPING.md для получения инструкций по сборке и запуску из исходного кода.
Действия GitHub
Если вы используете действия GitHub, вы можете использовать наше действие на основе Grype для запуска сканирования уязвимостей вашего кода или образов контейнеров во время рабочих процессов CI.
Проверка артефактов
Контрольные суммы применяются ко всем артефактам, а полученный файл контрольных сумм подписывается с помощью cosign.
Для проверки подписи вам понадобится следующий инструмент:
Cosign
Шаги проверки следующие:
Загрузите нужные файлы, а также файлы checksums.txt, checksums.txt.pem и checksums.txt.sig со страницы релизов:
Проверьте подпись:
cosignverify-blob <путь к контрольной сумме.txt>
--certificate <путь к контрольным суммам.txt.pem>
--signature <путь к контрольным суммам.txt.sig>
--certificate-identity-regexp 'https://github.com/anchore/grype/.github/workflows/.+'
--certificate-oidc-issuer "https://token.actions.githubusercontent.com"
Как только подпись будет подтверждена как действительная, вы можете приступить к проверке соответствия сумм SHA256 загруженному артефакту:
sha256sum --ignore-missing -c checksums.txt
Начиная
Установите двоичный файл и убедитесь, что на вашем пути доступен grype . Чтобы выполнить поиск уязвимостей в изображении:
grype
Приведенная выше команда сканирует уязвимости, видимые в контейнере (т. е. сжатое представление изображения). Чтобы включить программное обеспечение из всех слоев образа в сканирование уязвимостей, независимо от его присутствия в конечном образе, укажите --scope all-layers :
grype --scope all-layers
Чтобы запустить grype из контейнера Docker, чтобы он мог сканировать работающий контейнер, используйте следующую команду:
docker run --rm --volume /var/run/docker.sock:/var/run/docker.sock --name Grypenchore/grype:latest $(ImageName):$(ImageTag)
Поддерживаемые источники
Grype может сканировать различные источники, помимо тех, что есть в Docker.
# scan a container image archive (from the result of `docker image save ...`, `podman save ...`, or `skopeo copy` commands)
grype path/to/image.tar
# scan a Singularity Image Format (SIF) container
grype path/to/image.sif
# scan a directory
grype dir:path/to/dir
Источники могут быть явно предоставлены схемой:
podman:yourrepo/yourimage:tag use images from the Podman daemon
docker:yourrepo/yourimage:tag use images from the Docker daemon
docker-archive:path/to/yourimage.tar use a tarball from disk for archives created from "docker save"
oci-archive:path/to/yourimage.tar use a tarball from disk for OCI archives (from Skopeo or otherwise)
oci-dir:path/to/yourimage read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)
singularity:path/to/yourimage.sif read directly from a Singularity Image Format (SIF) container on disk
dir:path/to/yourproject read directly from a path on disk (any directory)
file:path/to/yourfile read directly from a file on disk
sbom:path/to/syft.json read Syft JSON from path on disk
registry:yourrepo/yourimage:tag pull image directly from a registry (no container runtime required)
Если источник изображения не указан и не может быть обнаружен по данной ссылке, предполагается, что изображение следует извлечь из демона Docker. Если докер отсутствует, то следующей попыткой будет попытка использования демона Podman, после чего в последнюю очередь осуществляется непосредственное обращение к реестру образов.
Это поведение по умолчанию можно переопределить с помощью параметра конфигурации default-image-pull-source (более подробную информацию см. в разделе «Конфигурация»).
Используйте SBOM для еще более быстрого сканирования уязвимостей в Grype:
# Then scan for new vulnerabilities as frequently as needed
grype sbom:./sbom.json
# (You can also pipe the SBOM into Grype)
cat ./sbom.json | grype
Grype поддерживает ввод форматов Syft, SPDX и CycloneDX SBOM. Если Syft создал файлы любого из этих типов, у них должна быть соответствующая информация для правильной работы с Grype. Также с разной степенью успеха можно использовать SBOM, созданные другими инструментами. Две вещи, которые делают сопоставление Grype более успешным, — это включение информации о CPE и дистрибутиве Linux. Если SBOM не содержит никакой информации CPE, ее можно сгенерировать на основе информации о пакете, используя флаг --add-cpes-if-none . Чтобы указать дистрибутив, используйте флаг --distro : . Полный пример:
Любая версия Grype до версии 0.40.1 не поддерживается. Неподдерживаемые версии не будут получать никаких обновлений программного обеспечения или обновлений базы данных уязвимостей. Вы по-прежнему можете создавать базы данных уязвимостей для неподдерживаемых выпусков Grype, используя предыдущие выпуски vunnel для сбора исходных данных и grype-db для создания баз данных для неподдерживаемых схем.
Работа с аттестациями
Grype поддерживает сканирование SBOM как входных данных через стандартный ввод. Пользователи могут использовать cosign для проверки аттестаций с использованием SBOM в качестве содержимого для сканирования образа на наличие уязвимостей:
Уязвимость : вся информация о конкретной уязвимости, которая была напрямую сопоставлена (например, идентификатор, уровень серьезности, оценка CVSS, информация об исправлениях, ссылки для получения дополнительной информации).
Связанные уязвимости : информация об уязвимостях, которые, как выяснилось, связаны с основной обнаруженной уязвимостью. Возможно, найденная нами уязвимость представляла собой рекомендацию по безопасности GitHub, имеющую исходный CVE (в авторитетной национальной базе данных уязвимостей). В этих случаях мы перечисляем здесь уязвимости восходящего потока.
MatchDetails : в этом разделе делается попытка объяснить, что мы искали при поиске совпадения, а также какие именно сведения о пакете и уязвимости приводят к совпадению.
Артефакт : это подмножество информации, которую мы знаем о пакете (по сравнению с выводом Syft json, мы суммируем раздел метаданных). Здесь содержится информация о том, где в образе контейнера или каталоге мы нашли пакет, что это за пакет, информация о лицензии, pURL, CPE и т. д.
Исключение путей к файлам
Grype может исключать файлы и пути из сканирования внутри источника, используя выражения glob с одним или несколькими параметрами --exclude :
grype --exclude './out/**/*.json' --exclude /etc
Примечание. В случае сканирования изображений , поскольку сканируется вся файловая система, можно использовать абсолютные пути, например /etc или /usr/**/*.txt тогда как при сканировании каталогов исключаются файлы, относящиеся к указанному каталогу . Например: сканирование /usr/foo с помощью --exclude ./package.json исключит /usr/foo/package.json , а --exclude '**/package.json' исключит все файлы package.json в /usr/foo . Для сканирования каталогов необходимо начинать выражения пути с ./ , */ или **/ , все из которых будут разрешаться относительно указанного каталога сканирования . Имейте в виду, что ваша оболочка может попытаться расширить подстановочные знаки, поэтому заключайте эти параметры в одинарные кавычки, например: '**/*.json' .
Внешние источники
Grype можно настроить для включения внешних источников данных для повышения точности сопоставления уязвимостей. Эта функция в настоящее время отключена по умолчанию. Чтобы включить эту функцию, добавьте в конфигурацию grype следующее:
Укажите путь к файлу шаблона ( -t ./path/to/custom.template ).
Обработка шаблонов Grype использует те же модели данных, что и выходной формат json — поэтому, если вам интересно, какие данные доступны при создании шаблона, вы можете использовать выходные данные grype -o json в качестве справки.
Обратите внимание: шаблоны могут получать доступ к информации о системе, в которой они работают, например к переменным среды. Никогда не следует запускать ненадежные шаблоны.
В каталоге шаблонов исходного кода Grype есть несколько примеров шаблонов, которые могут служить отправной точкой для создания собственного формата вывода. Например, csv.tmpl создает отчет об уязвимостях в формате CSV (значения, разделенные запятыми):
Там же вы также можете найти шаблон для формата вывода «таблица» по умолчанию.
Grype также включает в себя широкий набор служебных функций шаблонов от sprig, помимо текста/шаблона golang по умолчанию, что позволяет пользователям настраивать вывод из Grype.
Стробирование по серьезности уязвимостей
Вы можете завершить работу Grype с ошибкой, если сообщается о каких-либо уязвимостях с указанным уровнем серьезности или выше. Это удобно при использовании Grype в сценарии или CI-конвейере. Для этого используйте флаг CLI --fail-on .
Например, вот как вы можете вызвать сбой конвейера CI, если в образе ubuntu:latest обнаружены какие-либо уязвимости с уровнем серьезности «средний» или выше:
grype ubuntu:latest --fail-on medium
Указание совпадений, которые следует игнорировать
Если вы видите ложные срабатывания отчетов Grype или любые другие совпадения с уязвимостями, которые вы просто не хотите видеть, вы можете указать Grype игнорировать совпадения, указав одно или несколько «правил игнорирования» в файле конфигурации Grype (например, ~/.grype.yaml ). Это приводит к тому, что Grype не сообщает о каких-либо совпадениях уязвимостей, соответствующих критериям, указанным в любом из ваших правил игнорирования.
Каждое правило может указывать любую комбинацию следующих критериев:
состояние исправления (допустимые значения: "fixed" , "not-fixed" , "wont-fix" или "unknown" )
имя пакета (например, "libcurl" )
версия пакета (например, "1.5.1" )
язык пакета (например, "python" ; эти значения определены здесь)
тип пакета (например, "npm" ; эти значения определены здесь)
местоположение пакета (например, "/usr/local/lib/node_modules/**" ; поддерживает шаблоны glob)
Вот пример ~/.grype.yaml , демонстрирующий ожидаемый формат правил игнорирования:
ignore: # Это полный набор поддерживаемых полей правил:
- уязвимость: CVE-2008-4318 fix-state: неизвестно # поля VEX применяются, когда Grype читает данные vex: vex-status: not_affected vex-justification: уязвимый_code_not_present пакет: имя: libcurl версия: 1.5.1 тип: npm location: "/ usr/local/lib/node_modules/**" # Мы можем создавать правила, соответствующие только идентификатору уязвимости:
- уязвимость: CVE-2014-54321# ...или просто по одному полю пакета:
- упаковка: тип: драгоценный камень
Совпадения уязвимостей будут игнорироваться, если к совпадению применяются какие-либо правила. Правило считается применимым к данному совпадению уязвимостей только в том случае, если все поля, указанные в правиле, применимы к данному совпадению уязвимостей.
Когда вы запускаете Grype с указанием правил игнорирования, с совпадениями уязвимостей, которые «игнорируются», происходит следующее:
Игнорируемые совпадения полностью скрыты от вывода Grype, за исключением случаев использования форматов вывода json или template ; однако в этих двух форматах игнорируемые совпадения удаляются из существующего поля массива matches и помещаются в новое поле массива ignoredMatches . Каждое перечисленное игнорируемое совпадение также имеет дополнительное поле, appliedIgnoreRules , которое представляет собой массив любых правил, которые заставили Grype игнорировать это совпадение уязвимости.
Игнорируемые совпадения не влияют на решение Grype о статусе выхода при использовании --fail-on . Например, если пользователь указывает --fail-on critical и все совпадения уязвимостей, найденные с «критическим» уровнем серьезности, были проигнорированы , Grype выйдет из нуля.
Примечание. Продолжайте сообщать о любых ложных срабатываниях, которые вы видите! Даже если вы можете надежно отфильтровать ложные срабатывания с помощью правил игнорирования, для сообщества Grype будет очень полезно, если у нас будет как можно больше знаний о ложных срабатываниях Grype. Это помогает нам постоянно улучшать Grype!
Показаны только «исправленные» уязвимости
Если вы хотите, чтобы Grype сообщал только об уязвимостях , для которых есть подтвержденное исправление , вы можете использовать флаг --only-fixed . (При этом в конфигурацию Grype автоматически добавляются правила игнорирования, так что незафиксированные уязвимости будут игнорироваться.)
Например, вот скан Alpine 3.10:
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY
apk-tools 2.10.6-r0 2.10.7-r0 CVE-2021-36159 Critical
libcrypto1.1 1.1.1k-r0 CVE-2021-3711 Critical
libcrypto1.1 1.1.1k-r0 CVE-2021-3712 High
libssl1.1 1.1.1k-r0 CVE-2021-3712 High
libssl1.1 1.1.1k-r0 CVE-2021-3711 Critical
...и вот тот же скан, но с добавлением флага --only-fixed :
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY
apk-tools 2.10.6-r0 2.10.7-r0 CVE-2021-36159 Critical
Если вы хотите, чтобы Grype сообщал только об уязвимостях , для которых нет подтвержденного исправления , вы можете использовать флаг --only-notfixed . В качестве альтернативы вы можете использовать флаг --ignore-states для фильтрации результатов по уязвимостям с определенными состояниями, например, wont-fix (список допустимых состояний исправлений см. в --help ). Эти флаги автоматически добавляют правила игнорирования в конфигурацию Grype, так что уязвимости, которые исправлены или не будут исправлены, будут игнорироваться.
Поддержка VEX
Grype может использовать данные VEX (обмен уязвимостями) для фильтрации ложных срабатываний или предоставления дополнительного контекста, дополняя совпадения. При сканировании образа контейнера вы можете использовать флаг --vex , чтобы указать на один или несколько документов OpenVEX.
Заявления VEX связывают продукт (образ контейнера), уязвимость и статус VEX, чтобы выразить утверждение о влиянии уязвимости. Существует четыре статуса VEX: not_affected , affected , fixed и under_investigation .
Вот пример простого документа OpenVEX. (совет: используйте vexctl для создания собственных документов).
По умолчанию Grype будет использовать любые операторы в указанных документах VEX со статусом not_affected или fixed для перемещения совпадений в набор игнорирования.
Любые совпадения, игнорируемые в результате операторов VEX, помечаются при использовании --show-suppressed :
libcrypto3 3.0.8-r3 3.0.8-r4 apk CVE-2023-1255 Medium (suppressed by VEX)
Заявления со статусом affected или under_investigation будут рассматриваться как дополняющие набор результатов только при специальном запросе с использованием переменной среды GRYPE_VEX_ADD или в файле конфигурации.
VEX игнорирует правила
Можно написать правила игнорирования, чтобы контролировать, как Grype учитывает утверждения VEX. Например, чтобы настроить Grype так, чтобы он действовал только с операторами VEX, когда обоснование vulnerable_code_not_present , вы можете написать такое правило:
Подробности смотрите в списке обоснований. Вы можете смешивать vex-status и vex-justification с другими параметрами правила игнорирования.
База данных Грипа
Когда Grype выполняет сканирование на наличие уязвимостей, он делает это, используя базу данных уязвимостей, хранящуюся в вашей локальной файловой системе и созданную путем извлечения данных из различных общедоступных источников данных об уязвимостях. К этим источникам относятся:
Alpine Linux SecDB: https://secdb.alpinelinux.org/
По умолчанию Grype автоматически управляет этой базой данных. Grype проверяет наличие новых обновлений в базе данных уязвимостей, чтобы убедиться, что при каждом сканировании используется актуальная информация об уязвимостях. Это поведение можно настроить. Дополнительную информацию см. в разделе «Управление базой данных Grype».
Как работают обновления баз данных
База данных уязвимостей Grype представляет собой файл SQLite с именем vulnerability.db . Обновления базы данных являются атомарными: вся база данных заменяется, а затем Grype обрабатывает ее как «только для чтения».
Первым шагом Grype в обновлении базы данных является обнаружение баз данных, доступных для извлечения. Grype делает это, запрашивая «файл списка» у общедоступной конечной точки:
Используя эту информацию, Grype может выбрать правильную базу данных (самую последнюю созданную базу данных с текущей версией схемы), загрузить базу данных и проверить целостность базы данных, используя указанное значение checksum .
Управление базой данных Grype
Примечание. При обычном использовании пользователям не нужно управлять базой данных Grype! Grype тайно управляет своей базой данных. Однако для пользователей, которым требуется больше контроля, Grype предоставляет возможности более явного управления базой данных.
Каталог кэша локальной базы данных
По умолчанию база данных кэшируется в локальной файловой системе в каталоге $XDG_CACHE_HOME/grype/db// . Например, в macOS база данных будет храниться в ~/Library/Caches/grype/db/3/ . (Дополнительную информацию о путях XDG см. в спецификации базового каталога XDG.)
Вы можете установить путь к каталогу кэша, используя переменную среды GRYPE_DB_CACHE_DIR . Если установка только этой переменной не работает, возможно, необходимо также установить переменную среды TMPDIR .
Устаревшие данные
Grype необходима актуальная информация об уязвимостях, чтобы обеспечить точные совпадения. По умолчанию выполнение не удастся, если локальная база данных не была создана в течение последних 5 дней. Проверку устаревания данных можно настроить с помощью переменных среды GRYPE_DB_MAX_ALLOWED_BUILT_AGE и GRYPE_DB_VALIDATE_AGE или полей max-allowed-built-age и validate-age в db . Он использует синтаксис продолжительности времени Голанга. Установите для GRYPE_DB_VALIDATE_AGE или validate-age значение false чтобы отключить проверку устаревания.
Автономные и изолированные среды
По умолчанию Grype проверяет наличие новой базы данных при каждом запуске, совершая сетевой вызов через Интернет. Вы можете указать Grype не выполнять эту проверку, установив для переменной среды GRYPE_DB_AUTO_UPDATE значение false .
Пока вы размещаете файлы Grype vulnerability.db и metadata.json в каталоге кэша ожидаемой версии схемы, Grype не требуется доступ к сети. Кроме того, вы можете получить список архивов базы данных, доступных для загрузки, с помощью команды grype db list в онлайн-среде, загрузить архив базы данных, перенести его в автономную среду и использовать grype db import для использовать данную базу данных в автономном режиме.
Если вы хотите распространять свои собственные базы данных Grype внутри компании без необходимости использовать db import вручную, вы можете использовать механизм обновления базы данных Grype. Для этого вы можете создать свой собственный файл listing.json , аналогичный общедоступному (см. пример нашего общедоступного файла listing.jsongrype db list -o raw ) и изменить URL-адрес загрузки, чтобы он указывал на внутреннюю конечную точку (например, частная корзина S3, внутренний файловый сервер и т. д.). Любая внутренняя установка Grype может автоматически получать обновления базы данных, настроив db.update-url (так же, как переменная среды GRYPE_DB_UPDATE_URL ) так, чтобы она указывала на созданный вами размещенный файл listing.json .
Команды CLI для управления базой данных
Grype предоставляет команды CLI для конкретных баз данных для пользователей, которые хотят управлять базой данных из командной строки. Вот некоторые из полезных команд:
grype db status — сообщает о текущем состоянии базы данных Grype (например, ее местоположение, дата сборки и контрольная сумма).
grype db check — посмотреть, доступны ли обновления для базы данных
grype db update — убедитесь, что последняя база данных загружена в каталог кеша (Grype по умолчанию выполняет эту операцию в начале каждого сканирования)
grype db list — загрузите файл листинга, настроенный по адресу db.update-url , и отобразите базы данных, доступные для загрузки.
grype db import — предоставить grype архив базы данных для явного использования (полезно для автономных обновлений БД)
grype db providers — предоставляет подробный список поставщиков баз данных.
Найдите полную информацию о командах базы данных Grype, запустив grype db --help .
Завершение оболочки
Grype обеспечивает завершение оболочки через свою реализацию CLI (cobra). Создайте код завершения для вашей оболочки, выполнив одну из следующих команд:
grype completion
go run ./cmd/grype completion
Это выведет сценарий оболочки в STDOUT, который затем можно будет использовать в качестве сценария завершения для Grype. Запуск одной из приведенных выше команд с флагами -h или --help предоставит инструкции о том, как это сделать для выбранной вами оболочки.
Аутентификация частного реестра
Локальные учетные данные Docker
Когда среда выполнения контейнера отсутствует, grype все равно может использовать учетные данные, настроенные в общих источниках учетных данных (например, ~/.docker/config.json ). Используя эти учетные данные, он будет извлекать изображения из частных реестров. В файле конфигурации хранятся ваши учетные данные при аутентификации в частных реестрах с помощью какой-либо команды, например docker login . Для получения дополнительной информации см. документацию go-containerregistry .
В качестве примера вы можете запустить следующую команду. В нем подробно описана конфигурация монтирования/среды, необходимая контейнеру для доступа к частному реестру:
docker run -v ./config.json:/config/config.json -e "DOCKER_CONFIG=/config" anchore/grype:latest
Учетные данные Docker в Kubernetes
В разделе ниже показан простой рабочий процесс, как смонтировать этот файл конфигурации в качестве секрета в контейнер в Kubernetes.
Создайте секрет. Значение config.json важно. Это относится к спецификации, подробно описанной здесь. Ниже этого раздела находится файл secret.yaml , который конфигурация модуля будет использовать в качестве тома. Ключ config.json важен. В конечном итоге это будет имя файла при монтировании в модуль.
Создайте свой модуль, работающий с вирусом. Env DOCKER_CONFIG важен, поскольку он сообщает, где искать файл учетных данных. В приведенном ниже примере установка DOCKER_CONFIG=/config сообщает grype, что учетные данные можно найти в /config/config.json . Вот почему мы использовали config.json в качестве ключа для нашего секрета. При монтировании в контейнеры секретный ключ используется в качестве имени файла. Раздел volumeMounts монтирует наш секрет в /config . В разделе volumes указывается имя нашего тома и используется секрет, который мы создали на первом этапе.
Теперь пользователь может запускать kubectl logs grype-private-registry-demo . В журналах должен быть показан анализ ошибок для , указанного в конфигурации модуля.
Используя приведенную выше информацию, пользователи смогут настроить доступ к частному реестру без необходимости делать это в файлах конфигурации grype или syft . Они также не будут зависеть от демона Docker (или другого программного обеспечения среды выполнения) для настройки реестра и доступа.
Конфигурация
Пути поиска конфигурации по умолчанию (см. все с grype config locations ):
.grype.yaml
.grype/config.yaml
~/.grype.yaml
/grype/config.yaml
Используйте grype config , чтобы распечатать образец файла конфигурации на стандартный вывод. Используйте grype config --load для печати текущей конфигурации после загрузки всех значений в стандартный вывод.
Вы можете указать файлы напрямую, используя флаги --config / -c , чтобы предоставить свои собственные файлы/пути конфигурации:
grype -c /path/to/config.yaml
Параметры конфигурации (примерные значения — значения по умолчанию):
# включить/отключить проверку обновлений приложения при запуске# то же, что и GRYPE_CHECK_FOR_APP_UPDATE env varcheck-for-app-update: true# позволяет пользователям указывать, какой источник изображения следует использовать для создания sbom# допустимые значения: реестр, докер, podman# то же, что и GRYPE_DEFAULT_IMAGE_PULL_SOURCE env vardefault-image-pull-source: ""# то же, что --name; установите имя анализируемой целиname: ""# при сканировании, если обнаружена серьезность, равная или выше заданной серьезности, то код возврата будет 1# по умолчанию не установлено, что пропустит эту проверку (варианты: незначительная, низкая, средняя , высокий, критический)# то же, что --fail-on ; GRYPE_FAIL_ON_SEVERITY env varfail-on-severity: ""# формат вывода отчета об уязвимостях (варианты: таблица, шаблон, json, cycledx)# при использовании шаблона в качестве типа вывода вы также должны указать значение для 'output-template- file'# то же, что и -o ; GRYPE_OUTPUT env varoutput: "table"# при использовании вывода шаблона необходимо указать путь к файлу шаблона Go# см. https://github.com/anchore/grype#using-templates для получения дополнительной информации о выводе шаблона# путь по умолчанию в файл шаблона — текущий рабочий каталог# файл-шаблона вывода: .grype/html.tmpl# запись выходного отчета в файл (по умолчанию запись в стандартный вывод)# то же, что --file; GRYPE_FILE env varfile: ""# список glob, которые нужно исключить из сканирования, например:# ignore:# - '/etc/**'# - './out/**/*.json'# то же, что -- исключать ; GRYPE_EXCLUDE env varexclude: []# включает совпадения в пакетах заголовков ядра, которые сопоставляются с вышестоящим пакетом ядра# если 'false', любые такие совпадения помечаются как ignorematch-upstream-kernel-headers: false# операционная система и/или архитектура, которые будут использоваться, когда ссылка на образы контейнеров (например, «windows/armv6» или «arm64»)# то же, что и --platform; GRYPE_PLATFORM env varplatform: ""# При использовании ввода SBOM автоматически генерировать CPE, если пакеты имеют noneadd-cpes-if-none: false# Явно укажите дистрибутив Linux, который будет использоваться в качестве :, например alpine:3.10distro:external -sources: включить: false maven: search-upstream-by-sha1: true base-url: https://repo1.maven.org/maven2db: # проверка обновлений базы данных при выполнении # то же, что и GRYPE_DB_AUTO_UPDATE env var auto-update: true # место для записи кэша базы данных уязвимостей; по умолчанию $XDG_CACHE_HOME/grype/db # то же, что и GRYPE_DB_CACHE_DIR env var cache-dir: "" # URL базы данных уязвимостей # то же, что GRYPE_DB_UPDATE_URL env var update-url: "https://toolbox-data.anchore.io/grype /databases/listing.json" # он гарантирует, что сборка базы данных не старше максимально допустимого возраста сборки # установлено значение false, чтобы отключить проверку validate-age: true # Максимально допустимый возраст для базы данных уязвимостей, # age — время с момента он был построен # Максимальный возраст по умолчанию составляет 120 часов (или пять дней) max-allowed-built-age: "120h" # Таймаут для загрузки GRYPE_DB_UPDATE_URL, чтобы узнать, нужно ли загружать базу данных # Размер этого файла ~ 156 КБ по состоянию на 2024-04 г. -17, чтобы загрузка была быстрой; при необходимости отрегулируйте тайм-аут обновления: "30s" # Тайм-аут для загрузки фактической базы данных уязвимостей # По состоянию на 17 апреля 2024 г. размер базы данных составляет ~ 156 МБ, поэтому более медленные соединения могут превышать тайм-аут по умолчанию; при необходимости отрегулируйте update-download-timeout: "120s"search: # пространство поиска для поиска пакетов (варианты: все слои, сжатые) # то же, что -s ; GRYPE_SEARCH_SCOPE env varscope: "squashed" # поиск в архивах, которые содержат индекс файла для поиска (zip) # примечание: на данный момент это применимо только к каталогизатору пакетов Java # то же, что GRYPE_PACKAGE_SEARCH_INDEXED_ARCHIVES env var indexed-archives: true # search в архивах, которые не содержат индекс файла для поиска (tar, tar.gz, tar.bz2 и т. д.) # примечание: включение этого параметра может привести к снижению производительности, поскольку все обнаруженные сжатые tar-файлы будут распакованы # примечание: на данный момент это применяется только к каталогизатору пакетов Java # то же, что и GRYPE_PACKAGE_SEARCH_UNINDEXED_ARCHIVES env var unindexed-archives: false# опции при извлечении непосредственно из реестра по схеме "registry:" -skip-tls-verify: false # использовать http вместо https при подключении к реестру # то же, что GRYPE_REGISTRY_INSECURE_USE_HTTP env var insecure-use-http: false # путь к сертификату CA (или каталогу, содержащему *.crt, *.cert, *.pem), используемый для генерации сертификата клиента # GRYPE_REGISTRY_CA_CERT env var ca-cert: "" # учетные данные для определенных реестров auth: # URL-адрес реестра (например, "docker.io", "localhost:5000" и т. д.) # GRYPE_REGISTRY_AUTH_AUTHORITY переменная окружения
- полномочия: "" # GRYPE_REGISTRY_AUTH_USERNAME env var username: "" # GRYPE_REGISTRY_AUTH_PASSWORD env var пароль: "" # примечание: токен и имя пользователя/пароль являются взаимоисключающими # GRYPE_REGISTRY_AUTH_TOKEN env var token: "" # путь к сертификату клиента, используемому для аутентификации TLS в реестр # GRYPE_REGISTRY_AUTH_TLS_CERT env var tls-cert: "" # путь к ключу клиента, используемому для аутентификации TLS в реестре # GRYPE_REGISTRY_AUTH_TLS_KEY env var tls-key: "" # - ... # обратите внимание, дополнительные учетные данные можно предоставить через только файл конфигурации (не env vars)log: # подавлять весь вывод (кроме списка уязвимостей) # то же, что и -q ; GRYPE_LOG_QUIET env var quiet: false # увеличить подробность # то же, что GRYPE_LOG_VERBOSITY env var verbosity: 0 # уровень журнала; примечание: подробное ведение журнала подавляет ETUI # то же, что и GRYPE_LOG_LEVEL env var # Использует уровни ведения журнала logrus: https://github.com/sirupsen/logrus#level-logging level: "error" # местоположение для записи файла журнала (по умолчанию нет чтобы иметь файл журнала) # то же, что и GRYPE_LOG_FILE env var file: ""match: # устанавливает приведенные ниже средства сопоставления для использования cpes при попытке найти # совпадения уязвимостей. Номер стандартного сопоставителя используется по умолчанию, когда невозможно определить основной сопоставитель. java: using-cpes: false python: using-cpes: false javascript: using-cpes: false Ruby: using-cpes: false dotnet: using-cpes: false golang: using-cpes: false # даже если сопоставление CPE отключено, сделайте исключение при сканировании «stdlib». Always-use-cpe-for-stdlib: true # разрешить использование псевдоверсий основного модуля, о которых Syft мог только «догадаться», при сопоставлении уязвимостей.allow-main-module-pseudo-version-comparison: false stock : использование-cpes: правда
Планы на будущее
В настоящее время изучаются следующие области потенциального развития:
