Модуль Безопасность ведет учет всех пакетов, устанавливаемых в каждом проекте, и сопоставляет их с опубликованными рекомендациями, чтобы обнаружить уязвимую версию при ее попадании в pull request, а также при появлении новой рекомендации, касающейся уже используемой версии.
Инвентарь
При каждом новом коммите в основную ветку и как минимум один раз в день Coroid считывает файлы блокировки проекта с помощью OSV-Scanner, привязанный к конкретной версии и проверяемый по его опубликованной контрольной сумме. Сканер получает только файлы зависимостей, конфигурацию, которую генерирует Coroid, без доступа к сети или учетным данным. Собственные параметры репозитория не влияют на результат. osv-scanner.toml не оказывают никакого влияния.
Раздел Безопасность → Зависимости отображает инвентарь каждого проекта: пакеты и их установленные версии, какой манифест их объявляет, какие из них уязвимы, охват каждого файла и время последнего чтения данных рекомендаций. Экспорт в формате CycloneDX позволяет скачать инвентарь в виде файла CycloneDX 1.5. В нем перечисляются только уязвимости для уже опубликованных находок. Подробнее см. Раскрытие информации.
Что полностью считывает Coroid
Охват рассчитывается по файлу блокировки, а не по всему репозиторию. В монорепозитории каждый файл блокировки — это отдельная группа со своим охватом, поэтому результаты полного файла блокировки остаются действительными даже при частичном заполнении других манифестов.
| Файл | Экосистема | Точные версии | Полные транзитивные зависимости | Охват |
|---|---|---|---|---|
package-lock.json | npm | Да | Да | Полный |
npm-shrinkwrap.json | npm | Да | Да | Полный |
pnpm-lock.yaml | npm | Да | Да | Полный |
yarn.lock | npm | Да | Да | Полный |
requirements.txt | PyPI | Да | Нет | Частичный |
go.mod | Go | Да | Нет | Частичный |
Эта таблица сформирована на основе тестовых данных, используемых в собственных тестах Coroid через сканер, поэтому она меняется только при обновлении тестов.
- Рабочие пространства npm, pnpm и Yarn: для рабочего пространства
package.jsonбез собственного файла блокировки охватывается корневым файлом блокировки. Файлpackage.jsonкоторый больше не соответствует своему файлу блокировки, считается частичным до тех пор, пока файл блокировки не будет перегенерирован. - Файлы блокировки npm должны быть версии 2 или 3. Записи pnpm и Yarn, взятые из Git, локального файла или патча, считаются частичными.
requirements.txtохватывает только версии, привязанные к==.- Другие файлы зависимостей (
package.jsonбез файла блокировки,pyproject.toml,poetry.lock,Pipfile,Cargo.lock,Gemfile.lock,pom.xml, Gradle, Composer, NuGet и другие) обнаруживаются и отображаются как частичные с указанием имени файла, чтобы проект никогда не считался полностью охваченным, если это не так.
Рекомендации
Coroid считывает рекомендации из OSV, где также размещены рекомендации GitHub, для каждой экосистемы, используемой в проектах. Каждый час система считывает новые или измененные данные с момента последнего чтения, а раз в день — все данные. Сопоставление осуществляется на основе сохраненных инвентарей, поэтому доступ к вашему репозиторию не требуется.
Цель Coroid — сопоставить 95% новых рекомендаций с каждым инвентарем в течение 60 минут после их появления в считываемых данных рекомендаций, при этом замеряется время каждого сопоставления. Система не может гарантировать время с момента первоначального раскрытия уязвимости: это зависит от времени публикации рекомендации.
Если данные рекомендаций отстают более чем на 90 минут или последнее чтение завершилось ошибкой, в разделах Обзор и Зависимости отображается сообщение «Поток рекомендаций задержан с…», и охват ни одного проекта не считается полным до устранения задержки.
При отзыве рекомендации Coroid пересчитывает, какие из оставшихся рекомендаций по-прежнему применимы к той же уязвимости. Находка закрывается как «Больше не применимо» только в том случае, если подходящих рекомендаций нет, но никогда не как «Исправлено».
В запросах на объединение
Проверка Coroid Security сканирует файлы блокировки, измененные pull request, в их исходной и новой версиях, и учитывает только уязвимые версии, появившиеся в результате изменений:
- Наблюдение: проверка проходит успешно или возвращает нейтральный результат с указанием найденных элементов.
- Принудительное применение: изменение, в котором используется версия с известной уязвимостью уровня или выше выбранного уровня серьезности (по умолчанию — высокий), не проходит проверку. Неполное покрытие файла lockfile, затронутого изменением, также приводит к сбою проверки; в сообщении указывается причина и способ повторного запуска проверки.
Та же самая проверка выполняется для собственных исправлений и функциональных pull-запросов Coroid перед их открытием. Подробнее о том, как работает эта проверка, как ее требовать и как повторно запустить, см. Разрешения GitHub и проверка Безопасности Coroid.
Уведомления
Первый полный инвентарь репозитория представляет собой скрытую базовую линию: результаты анализа отображаются в разделе Безопасность, но уведомления не отправляются. После этого при обнаружении новой критической уязвимости в зависимостях владельцам и администраторам организации отправляется одно уведомление: через систему оповещений, по электронной почте (если включена) и в Slack (если подключен). В случае публичного уведомления в системе оповещений указываются название пакета и текст уведомления; для еще не опубликованных уведомлений сообщается лишь о необходимости внимания к критической уязвимости. См. Раскрытие информации.