Принципы безопасной разработки основываются на опыте инцидентов с уязвимостями в приложениях. То есть всегда сначала находились и эксплуатировались уязвимости, а затем разработка менялась так, чтобы избегать их появления как можно раньше (shift left). И вряд ли это изменится в будущем – VM всегда будет подсказывать, как создавать более безопасное ПО. Кроме того, есть угрозы, которые не зависят от разработчиков, например ошибки конфигурирования систем и приложений.
Современные процессы безопасной разработки надежно связаны с устранением уязвимостей и не исключают друг друга. За счет гибкой интеграции ИТ-решений и процессов ИБ можно достигнуть настоящей эффективности и создать экосистему, в которой решения будут дополнять друг друга. Поэтому актуальность применения VM не только не теряется, но глубже встраивается в DevSecOps.
Нет, так как безопасная разработка не может полностью закрыть появление новых уязвимостей в продуктах. Если была найдена новая уязвимость, а клиент не обновился на последнюю версию ПО, то необходима система, которая покажет эти уязвимости в конкретной версии продуктов. Кроме того, если относить конфигурационное несоответствие к процессу Vulnerability Management, то проверка по compliance control не закрывается безопасной разработкой.
Безопасная разработка (DevSecOps) направлена на устранение уязвимостей еще на этапе разработки ПО, однако она не является гарантом обеспечения полноценной защиты. Злоумышленники непрерывно ищут новые уязвимости в популярном и широко распространенном ПО. Поэтому необходимо обеспечивать дополнительную защиту при помощи VM-систем, которые служат для обнаружения и устранения уязвимостей, помогая службам ИБ и ИТ снизить риски по их эксплуатации до минимума. Таким образом, наряду с DevSecOps внедренный процесс VM усиливает защиту от вероятных атак, которые могут повлечь за собой потери для бизнеса.
Нет, не потеряет. Следует учитывать, что, несмотря на большую пользу РБПО, полностью исключить наличие уязвимостей в исходном коде невозможно. Часть уязвимостей может появиться уже непосредственно в процессе эксплуатации информационного ресурса. Многие приложения используют сторонние компоненты, которые не всегда удается проанализировать разработчикам программного обеспечения. Ну и самое главное, управление уязвимостями не ограничивается только разработкой кода, оно также включает в себя оценку и защиту конфигураций и других сущностей.
Продукты подобного класса никогда не потеряют своей актуальности. Человеку свойственно ошибаться, потому ошибки в ПО и ОС всегда были и будут. По мере того как сложность разрабатываемых программных продуктов растет, вероятность наличия в них уязвимостей тоже возрастает. Процесс налаживания безопасной разработки просто позволяет держать процент ошибок в допустимых пределах, но полностью не устраняет факторы их появления.
Во-первых, не все организации – разработчики, не всем нужен AppSec и DevSecOps. Во-вторых, как может потерять актуальность один из компонентов с внедрением комплекса мероприятий, направленных на повышение защиты? VM является неотъемлемой частью, а возможно даже и базой для построения последующих мероприятий по обеспечению защищенной разработки.
Мы не можем говорить о процессе безопасной разработки до тех пор, пока у нас не обновлены первичные инструменты разработки: GitLab, Nexus, Kubernetes.
Нет, не потеряет, одно не исключает другого. Работает принцип "доверяй, но проверяй". Более того, внедрение процессов безопасной разработки в условиях все возрастающей сложности и количества заимствованного (встроенного) кода и ПО не всегда приводит к уменьшению количества уязвимостей и их критичности, а скорее, является критерием качества процессов реагирования разработчиком на выявляемые ошибки и уязвимости, например насколько быстро они устраняются в обновлениях безопасности.
Пока системы пишут люди, люди будут делать ошибки. VM – это защита от таких ошибок.