Перейти к содержимому

Учёт и устранение уязвимостей

Трекер уязвимостей для инженеров по безопасности, владельцев сервисов и руководителя разработки. Он собирает находки сканеров в одну очередь, хранит контекст каждой уязвимости, назначает ответственного и срок устранения и сохраняет историю, которую можно показать на аудите.

Без трекера отчёты сканеров приходят на почту или в хранилище и лежат непросмотренными несколько дней. Инженеры спорят о серьёзности, потому что контекст — какой сервис затронут, доступен ли он снаружи, что за CVE — спрятан в PDF. Ответственного назначают в чате, сроки проходят незаметно, а руководство узнаёт о нарушении, когда аудит просит доказательства.

  • Сводит находки в одну очередь. Результаты разных сканеров приводятся к одной схеме и попадают в общий приоритизированный список без дублей.
  • Хранит контекст уязвимости. Серьёзность, затронутый сервис, ссылка на CVE, доступность сервиса снаружи и рекомендация по исправлению видны в карточке.
  • Назначает владельца и срок. Срок устранения рассчитывается по серьёзности, находка не двигается дальше статуса «Новая» без ответственного.
  • Эскалирует приближение срока. Тимлид получает уведомление заранее, руководитель — если срок прошёл.
  • Проверяет исправление. Уязвимость закрывается только после повторного сканирования, которое её не нашло.
  • Сканеры остаются. Snyk, Trivy, Dependabot, GitHub code scanning продолжают искать уязвимости; трекер добавляет разбор, ответственность и сроки. Если все находки приходят из одного инструмента, а его встроенных назначений и политик хватает, например в GitHub Advanced Security или DefectDojo, отдельное приложение не нужно.
  • Нормализация и дедупликация. Одна и та же уязвимость в зависимости находится разными сканерами и в каждом сервисе. Ключ дедупликации — CVE или идентификатор правила, пакет и сервис; повторное сканирование обновляет запись, а не создаёт новую. Если уязвимость больше не находится ни одним сканером, запись не удаляется, а ждёт подтверждения исправления.
  • Понижение серьёзности с обоснованием. Снизить уровень можно только с письменной причиной и согласованием руководителя. Иначе серьёзность подгоняют под удобный срок.
  • Сроки — политика компании. Например, критичная — 72 часа, высокая — 7 дней; значения задают в настройках и согласуют с ответственным за безопасность, а не выбирают на глаз.
  • Критичное — за час. Импорт идёт автоматически по расписанию или вебхуку, и дежурный по безопасности получает уведомление о критичной находке сразу, а не при следующем просмотре очереди.
  • Доступ ограничен строже обычного. Данные о незакрытых уязвимостях сами по себе чувствительны. Владелец видит находки своих сервисов, служба безопасности — все; ограничение действует на сервере, в выгрузках и уведомлениях.
  • История для аудита. Каждая смена статуса, назначение и комментарий записываются автоматически, а хронологию устранения можно выгрузить по запросу.

Промпты рассчитаны на AI-агента (Claude Code, Cursor и аналоги) в Laravel-проекте с установленным Filament 4.x. Отправляйте их по одному и проверяйте результат каждого шага.

Создай модели и миграции для учёта уязвимостей: Service (название,
владелец, доступен снаружи), Vulnerability (ключ дедупликации, CVE или
правило, пакет, сервис, источник, серьёзность, статус: новая, в работе,
исправлена, подтверждена, принят риск; владелец, срок устранения, дата
первого и последнего обнаружения), VulnerabilityEvent (уязвимость,
действие, старое и новое значение, причина, автор, время). Добавь
фабрики.
Сгенерируй Filament-ресурс для Vulnerability. В таблице покажи
серьёзность, сервис, CVE, статус, владельца и остаток времени до срока;
фильтры по серьёзности, сервису, статусу и «Срок истекает». В карточке
выведи контекст и историю событий. Запрети переход дальше «новая» без
владельца и срока.
Сделай импорт результатов сканеров по расписанию и через вебхук с проверкой
подписи: приводи находки к общей схеме и дедуплицируй по ключу. Новая
находка создаёт запись и выставляет срок по серьёзности из настроек,
повторная обновляет дату последнего обнаружения. Если исправленная
уязвимость не найдена повторным сканированием, переводи её
в «подтверждена».

Проверьте, что одинаковая находка от двух сканеров превращается в одну запись.

Добавь действие «Изменить серьёзность»: понижение требует причину
и согласование руководителя, до согласования уровень не меняется.
Сделай задачу, которая уведомляет тимлида за 24 часа до срока
и руководителя разработки после его истечения, а о критичной находке —
дежурного по безопасности сразу.

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

Настрой роли: владелец сервиса видит и меняет уязвимости своих сервисов,
служба безопасности — все, руководитель согласует понижения. Ограничение
действует в таблицах, виджетах, экспорте и уведомлениях. Добавь виджеты
открытых уязвимостей по серьёзности и доли нарушенных сроков и экспорт
хронологии устранения за период.

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