Приоритизирование Dependabot alerts с использованием метрик
Менеджеры по безопасности приложений (AppSec) часто сталкиваются с потоком Dependabot alertsуязвимостей , что затрудняет определение уязвимостей в первую очередь. Dependabot Метрики предоставляют ценные инсайты, которые помогают эффективно расставлять приоритеты оповещений и своевременно решать критические проблемы безопасности. Пользователи могут принимать обоснованные решения, фокусируя ресурсы на наиболее затронутых уязвимостях. Этот подход повышает уровень безопасности организации и упрощает управление уязвимостями.
Понимание Dependabot метрик
Dependabot Метрики предоставляют подробную информацию о уязвимостях, обнаруженных в ваших зависимостях. К ключевым метрикам относятся:
- Серьезность: указывает потенциальное влияние уязвимости (например, низкий, средний, высокий, критически важный).
- Эксплойтируемость: оценивает, насколько легко может быть использована уязвимость.
- Связь зависимостей: различает прямые и транзитивные зависимости.
- Область зависимостей: различает зависимости среды выполнения и разработки.
- Оповещения, закрытые за последние 30 дней, включая количество исправленных Dependabot, вручную отклонённых и автоматически отклонённых: отслеживает ход решения оповещений. Иллюстрирует, как GitHub Code Security можно помочь выявить уязвимости на раннем этапе.
- Таблица, показывающая общее количество открытых оповещений для каждого репозитория, а также данные о серьезности и экспоненциализации: позволяет глубже копать данные на уровне репозитория.
Дополнительные сведения об этих метриках см. в разделе Метрики для оповещений Dependabot.
Кроме того, можно указать сложные фильтры, которые являются комбинациями отдельных фильтров, доступных. Для получения дополнительной информации о фильтрах смотрите Dependabot фильтры на панели управления.
Действия по приоритету оповещений
Эти первые шаги помогут определить, что Dependabot alerts ставит вашу организацию под наибольший риск, чтобы вы могли сказать разработчикам, на какие оповещения стоит сосредоточиться для устранения проблем.
1. Настройка воронки в соответствии с потребностями вашей организации
Вы можете настроить порядок воронок по умолчанию на графе "Приоритет оповещений", чтобы убедиться, что он отражает уникальный профиль риска, бизнес-приоритеты и требования к соответствию вашей организации. См . раздел AUTOTITLE.
2. Внимание уделяется критическим и высоким уровням серьезности оповещений
Начните с выявления оповещений с наивысшей степенью с помощью severity-critical фильтров OR severity-high . Эти уязвимости представляют собой наибольший риск и часто определяются стандартами соответствия требованиям.
3. Оценка доступности и доступности эксплойтов
Определите приоритет уязвимостей, которые, скорее всего, будут использоваться в базе кода. Чтобы определить оповещения, которые, скорее всего, будут использоваться, можно использовать epss-percentage фильтр, связанный со значением (например epss-percentage:>=0.10).
Примечание.
Reachability analysis для Dependabot alerts и подлежит Публичный предварительный просмотр изменению.
Для репозиториев JavaScript, использующих репозитории npm, pnpm или Yarn и TypeScript, используйте для reachability analysis оценки того, может ли приложение вызывать уязвимые функции в своих зависимостях. Это отдельный сигнал от эксплуатируемости: путь вызова не доказывает, что злоумышленник может использовать уязвимость.
- Откройте репозиторий Dependabot alerts и отфильтруйте его
reachability:reachable,potentially-reachable. - Определите приоритеты этих оповещений вместе с серьезностью и EPSS. Чтобы узнать, как код вызывает уязвимую функцию, просмотрите доказательства пути вызова. См . раздел AUTOTITLE.
Для результатов "Доступность недоступна", используйте серьезность, EPSS, область зависимостей и связь зависимостей для определения приоритетов оповещений. Недоступный результат не означает, что уязвимая функция не может быть вызвана.
Присвойте оповещению "Неустранимо" более низкий приоритет, но не закрывайте или не закрывайте оповещение исключительно из-за его вердикта. Вердикты — это оценки на определенный момент времени и могут изменяться в виде кода или изменений рекомендаций.
4. Просмотрите область зависимостей и связь
Прямые зависимости, как правило, проще обновлять и могут оказать большее влияние на безопасность вашего приложения. По возможности рекомендуется обращаться к этим перед транзитивными зависимостями.
Фильтрация оповещений с помощью relationship:direct фильтра позволяет нам видеть уязвимости в прямых зависимостях для поддерживаемых экосистем, таких как npm.
Зависимости среды выполнения используются приложением в рабочей среде. Обновление такого рода зависимостей может устранять уязвимости безопасности, исправления ошибок и улучшения производительности, влияющие непосредственно на конечных пользователей или систем. С другой стороны, зависимости разработки используются только во время разработки, тестирования или сборки процессов. Хотя важно, проблемы в этих зависимостях обычно не влияют на работающее приложение или его пользователей.
Вы можете использовать scope:runtime или scope:development фильтры для отображения только оповещений для зависимостей среды выполнения или разработки соответственно.
5. Рассмотрим возраст оповещений
Старые оповещения могут указывать на долгосрочные риски. Регулярно просматривайте и устраняйте устаревшие оповещения, чтобы предотвратить накопление задолженности по обеспечению безопасности. Например, после установления того, что определенный репозиторий содержит больше оповещений, которым требуется приоритет, чем другие репозитории, можно:
- Щелкните имя репозитория в таблице для каждого репозитория, чтобы отобразить оповещения только для этого репозитория.
- Используйте фильтр "Старый" в раскрывающемся списке сортировки , а также другие критерии сортировки, чтобы точно настроить визуализацию на оповещения, соответствующие вашим критериям по возрасту.
6. Использование автоматизации
Используйте Dependabotавтоматические pull request-запросы для быстрого устранения уязвимостей. Интегрируйте эти обновления в конвейер CI/CD для ускорения разрешения и повышения эффективности.
Лучшие практики
- Установите соглашения об уровне обслуживания (соглашения об уровне обслуживания) для устранения уязвимостей на основе серьезности.
- Регулярно отслеживайте метрики для выявления тенденций и повторяющихся проблем.
- Совместная работа с разработчиками для обеспечения своевременного обновления и минимизации сбоев.
- Документируйте решения о предоставлении прозрачности и поддержке будущей приоритетности.