Приведи пример дефекта с низким приоритетом и высокой критичностью

Пример дефекта с низким приоритетом и высокой критичностью

В управлении дефектами приоритет (Priority) отражает очередность исправления, а критичность (Severity) — степень влияния на систему и пользователя. Дефект с низким приоритетом означает, что его исправление может быть отложено в очереди задач, но с высокой критичностью — что при его проявлении возможны серьёзные последствия, такие как потеря данных, нарушение безопасности или критический сбой в работе системы.

Конкретный пример: Уязвимость безопасности в редко используемом функционале

Сценарий: В веб-приложении для онлайн-банкинга существует раздел «Исторические отчёты», доступный только суперадминистраторам (менее 1% пользователей) и используемый раз в квартал для генерации архивных данных. В этом разделе обнаружена SQL-инъекция, позволяющая при определённых манипуляциях получить доступ ко всей базе данных клиентов.

• Высокая критичность (Severity: Critical):

    *   Позволяет несанкционированно получить доступ к конфиденциальной информации (персональные данные, финансовые операции).
    *   Нарушает ключевые принципы **конфиденциальности** и **безопасности**.
    *   Может привести к финансовым потерям, репутационному ущербу и юридическим последствиям (например, нарушениям GDPR).

• Низкий приоритет (Priority: Low):

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

Почему возникает такой парадокс?

Данная ситуация — классический пример, когда вероятность возникновения инцидента (эксплуатации бага) крайне мала, но последствия — катастрофичны. Менеджер продукта или владелец бэклога, оценивая приоритет, руководствуется:

• Частотой использования уязвимого компонента.
• Бизнес-рисками в краткосрочной перспективе.
• Рабочей нагрузкой команды и дорожной картой релизов.

Тем временем, QA-инженер или специалист по безопасности, оценивая критичность, фокусируется на потенциальном ущербе в случае, если злоумышленник всё же найдёт способ воспользоваться уязвимостью.

Как описывается такой дефект в баг-трекере?

**Заголовок:** [Security] SQL-инъекция в модуле генерации исторических отчётов (admin/reports/archive)
**Severity:** Critical
**Priority:** Low
**Шаги для воспроизведения:**
1.  Авторизоваться под учётной записью суперадминистратора.
2.  Перейти в раздел "Исторические отчёты".
3.  В поле "Год" ввести: `1990' UNION SELECT username, password FROM users --`
4.  Нажать "Сформировать".
**Фактический результат:** В результате отчёта отображаются данные из таблицы `users`.
**Ожидаемый результат:** Входные данные должны быть санированы, запрос не должен выполнять произвольный SQL-код.
**Дополнительно:** Риск эксплуатации низок из-за ограниченного доступа к функционалу, однако уязвимость является критической с точки зрения безопасности.

Как правильно поступать команде?

Несмотря на низкий приоритет, такие дефекты нельзя игнорировать. Их необходимо:

1. Обязательно зафиксировать и держать на контроле.
2. Запланировать на исправление в одном из ближайших циклов разработки после завершения работ с более высокоприоритетными задачами.
3. Рассмотреть временные меры mitigation (например, дополнительный мониторинг логирования запросов к этому разделу или временное отключение функционала до фикса).
4. Использовать подобные кейсы для улучшения процессов безопасной разработки (Security SDLC) и проведения security-аудитов.

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