Уязвимости: прием сообщений и выпуск исправлений
У поддерживаемого проекта есть действующий security contact, приватный канал сообщения и процесс исправления с владельцем/сроком. Наличие SECURITY.md без работающего приема не выполняет эту норму.
Плохо
О проблемах пишите в публичные issues вместе с токенами и exploit.
Сроков ответа нет; зависимости обновятся когда-нибудь.
Закрытие issue считается исправлением, хотя release уязвим.
Хорошо
Пример структуры политики, значения назначает владелец:
Контакт/приватный канал → кто читает и кто заменяет владельца.
Support matrix → какие версии получают security fixes.
Срок первого ответа → triage → remediation deadline по риску.
Исправление → проверка → release/advisory → affected/fixed versions.
Почему это важно
Репорт и scanner finding требуют проверки применимости; они не равны доказанному exploit. При этом приватный прием не должен приводить к бессрочному отсутствию информации для пользователей. Исправление считается доставленным после доступного потребителям патча/меры, а не только после merge.
Когда применять
Для публикуемого или эксплуатируемого ПО и его поддерживаемых компонентов. Документационный проект тоже указывает контакт для значимых проблем, но ему не требуется вымышленный binary patch pipeline. Для внутреннего сервиса используйте внутренний security channel и оповещение затронутых владельцев; публичные advisory применимы к публично распространяемому продукту.
В политике укажите приватный канал, ожидаемый срок первого ответа и обновлений статуса, поддерживаемые версии/EOL, правила безопасного репорта и coordinated disclosure. Не просите реальные credentials/PII в публичных issues; repro минимален и обезличен. Прием имеет owner и резервного ответственного; не публикуйте обещанный SLA, если команда не может его выполнять.
Triage фиксирует затронутые версии/конфигурации, воспроизводимость, влияние и срочность. Проект задает пороги release-blocking и сроки исправления; учитывайте эксплуатацию и достижимость, не только численный severity. Временное исключение требует причины, компенсирующих мер, владельца и expiry. При компрометации сначала ограничьте ущерб/отзовите credentials. Патч проходит целевую регрессию, выпускается в поддерживаемые ветви, а уведомление содержит affected/fixed versions и доступную mitigation без раскрытия секретов.
Основа — выбранные OSPS 2026.08.28 VM-02.01, VM-01.01/03.01/04.01; VM-05 относится к dependency remediation уровня L3, здесь используется как ориентир политики, а не обязательная сертификация всех проектов. VEX нужен только при выбранном профиле, не для каждого простого репозитория.
Кто что делает
Человек
Назначает контакты, реальные сроки поддержки/ответа, приоритет и coordinated disclosure.
AI-агент
Подготавливает проверяемый scope и безопасный repro, связывает remediation с выпущенной версией и не публикует секреты/неподтвержденные выводы.
Как проверить у себя
-
Уполномоченный тестовый репорт через опубликованный канал → прием → назначен владелец и ответ в объявленный срок → безопасная запись без публичного payload.
-
Подтвержденная проблема в поддерживаемой и EOL версиях → triage → scope, сроки, patch/mitigation и отсутствие обещания неподдерживаемого исправления ясны → support/advisory.
-
Патч либо истекшее исключение → release decision → регрессия проверена, блокирующая проблема не пропущена молча, fixed version доступна потребителю → release evidence.
Первоисточники
История изменений на GitHubДата проверки отражает содержательную сверку. Синхронизация сайта не обновляет её автоматически.