В product security есть удобная управленческая иллюзия.

Если сканеры не нашли критических проблем, зависимости обновлены, а пентест завершён без серьёзных замечаний, продукт хочется назвать безопасным.

Но отсутствие известных CVE означает только отсутствие известных CVE.

Оно не доказывает, что продукт нельзя использовать во вред клиенту или бизнесу.

Пользователь может не взламывать функцию, а злоупотребить ею: — массово забронировать ограниченный ресурс; — автоматизировать получение бонусов; — выгрузить данные в объёме, которого никто не ожидал; — изменить идентификатор объекта и обратиться к данным другого клиента; — комбинировать разрешённые операции для обхода ограничений; — отключить критичный контроль, оставленный опциональным.

OWASP относит unrestricted access to sensitive business flows к отдельным рискам API. Система может корректно выполнять легитимные запросы и одновременно позволять атакующему причинять экономический ущерб. (OWASP)

На мой взгляд, проблема начинается тогда, когда product security сводят к vulnerability management.

Сканеры необходимы. Но они видят не весь продукт.

Они не определяют: — какие бизнес-процессы особенно чувствительны; — где проходит граница между клиентами; — какое поведение пользователя является злоупотреблением; — какие настройки должны быть безопасными по умолчанию; — какую телеметрию должен получить клиент; — какой ущерб продукт должен ограничивать самостоятельно.

Эти решения появляются не в отчёте SAST или DAST. Они появляются в архитектуре, продуктовых требованиях и модели бизнеса.

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

Какую ценность она создаёт?

Кто имеет к ней доступ?

Как ею можно злоупотребить?

Какое предположение команды может оказаться ошибочным?

Каковы последствия?

Что предотвратит сценарий?

Что позволит его обнаружить?

Как проверить эффективность контроля?

OWASP рекомендует проводить threat modeling на этапе проектирования и обновлять его вместе с системой, а не рассматривать как разовое security-упражнение. (cheatsheetseries.owasp.org)

Зрелый product security, на мой взгляд, должен оцениваться не только через количество дефектов.

Нужно видеть: — покрытие критических функций abuse cases; — качество tenant isolation; — долю secure defaults; — доступность клиентской телеметрии; — способность ограничивать массовое злоупотребление; — скорость оценки клиентского воздействия; — устранение корневых причин повторяющихся проблем.

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

Какой штатный сценарий вашего продукта способен превратиться в атаку без эксплуатации единой CVE?