Сканеры уязвимостей@Enterprise

Следуя правильной причинно-следственной логике, прежде чем выбирать инструмент решения, следует понять задачу. Очевидно, сканер уязвимостей нужен для поиска уязвимостей, чтобы их потом латать и так, постепенно, улучшать свои ИТ-системы в предположении, что минимизация уязвимостей == повышение безопасности, наверно, это так и есть. 
Ранее, мы разбирались с уязвимостями (кому лень читать, можно послушать), в совокупности с предположением, что в компании не разрабатывается ПО, с необходимостью сканера не все понятно. 
Вообще, аудит мне подтверждает две вещи: что я делаю правильные вещи, и что я делаю эти вещи правильно. Второе - это аудит соответствия. Первое - пентест, этакая Зарница,  в идеале, может, даже и без оповещения, что мы в состоянии игры. Как я не раз отмечал, в большом интерпрайзе управляемость - один из важнейших моментов, а следовательно, обычно, есть централизованные системы управления элементами ИТ-комплекса, типа SCCM, выполняющих любые виды инвентаризации. Чем вам такая инвентаризация не аудит соответствия? Сейчас уже у любого производителя есть руководство по безопасной настройке, так называемые hardening-гайды, - аудит соответствия такому гайду легко автоматизировать, да и многие производители имеют автоматизированные инструменты, которые проверят соответствие (некоторые потом даже предложат и исправить) - совсем нетрудно дергать такие проверялки при инвентаризации. В общем, очевидно, уязвимости конфигурации средствами инвентаризации легко закрываются. 
Но закрываются и ошибки разработчиков, поскольку уязвимости коммерческого ПО решаются для интерпрайза единственным образом - установкой патчей. Если я имею дело с 0-day, то такие риски компенсируются другими "эшелонами" моей безопасности: сегментацией, "навесными" средствами с разными модными технологиями, типа "virtual patch", контролем доступа, постоянным мониторингом и пр. К тому же, если производитель нормальный (я рекомендую, и от души желаю, работать только с нормальными производителями), скорее всего он выпустит какие-нибудь рекомендации, что нам всем делать, пока он не выпустил патч. Производитель, в софте которого вы нашли уязвимость, а затем безрезультатно закидываете его enhancements request-ами с требованиями исправить проблему, - не достоин называться "нормальным", поэтому неразумно держать сканер исключительно для таких случаев.
Перейдем к пентестам. Здесь мы пытаемся удостоверитья, что мы делаем правильные вещи. Безусловно, здесь уже нужна автоматизация... Но, в случае уязвимости конфигурации - эксплуатация тривиальна, как правило, можно и не пробовать, а в случае уязвимости ПО - вопрос эксплуатируемости, обычно, исследован вендором, и этому исследованию можно и нужно верить, а проверять экплуатируемость сканером - ну разве что только из спортивного интереса - насколько хорошо производитель сканера реализовал эксплоит. Более того, исследовать вопрос насколько правильные вещи я делаю, мне едва ли нужно часто. А раз так, то, наврено, эффективнее нанять профессиональную команду, где натренированные практики будут использовать десятки инструментов, чем я-любитель буду в автоматизированном режиме использовать один, имеющейся у меня сканер.
Прниципиальная вещь: сканер не находит неизвестные уязвимости и вряд ли найдет больше, чем известно "нормальному" производителю исследуемого ПО.

Любопытно, что даже если я разрабатываю ПО, мне тоже едва ли подходит off-the-shelf сканер, - значительно эффективнее будет работать моя продуктовая безопасность, которая знает мои продукты лучше производителя сканера и имеет специализованные инструменты, адаптированные под мою продукцию, понимает, что дейстительно критично и поэтому может правильно расставлять приоритеты.

Подводя итог всему написанному, хочется все-таки понять, когда же мне нужен сканер:
0. У меня огромный разнородный ИТ-комплекс, поэтому мне невозможно детально разбираться с каждым, используемым у меня производителем (заниматься харденинком его решений), мне проще запустить комбайн, который на приемлемом уровне решит проблему (ну или хотя бы сделает что-то, что лучше, чем ничего).
1. Я не знаю свою инфраструктуру. Отсканировал - получил какое-то представление (почти п.0, но с условием необходимости быстрых результатов при отсутствии времени).
2. У меня нет систем управления ИТ-инфраструктурой, поэтому я это компенсирую сканером, реализовав следующий процесс управления ИТ-инфраструктурой: отсканировал --> нашел узявимости --> устранил --> отсканировал --> ...
2,5. У меня плохие отношения с ИТ, поэтому я не могу использовать их системы управления ИТ-инфраструкурой и должен обязательно иметь свою штуку.
3. У меня стандартные системы, чтобы в сканере под них были сигнаруты\профили.
4. Я не хочу разбираться с безопасной настройкой каждой из используемых у меня систем, мне удобнее иметь комбайн, который все мои ошибки конфигурации (в целом, отсутствующий патч тоже можно считать уязвимостью конфигурации) найдет мне в виде уязвимостей (тоже почти п.0, но при отсутствии объективной невозможности разобраться с рекомендациями производителей, я просто лентяй).
5. Меня вынудил комплайнс, требующий от меня наличия сканера, или инструмента управления уязвимостями, или еще чего подобного.
6. У меня есть желание поразвлечься - посмотреть эксплуатируемость стандартных уязвимостей (== доступных в сигнатурах\проверках сканера)
7. Я хочу\должен кому-то что-то продемонстрировать или доказать, сделать вау-эффект, или эффективность моей работы характеризуется количетсвом найденных уязвимостей.
8. Сканер - это мой инструмент situational awareness (что-то около п.1) - фундаментальное требование для эффективной работы SOC.

На практике мы, конечно же, имеем комбинацию перечисленного + что-то уникальное, до чего я даже не догадываюсь.