Мы хотим поделится с вами информацией по безопасности разрабатываемых приложений, начинаем цикл статей в эту тему.
На протяжении десятилетий были организованы этапы разработки программного обеспечения с использованием так называемой методологии водопада Waterfall.
Общая задача была организована в несколько этапов, которая очень напоминала сборочный конвейер, благодаря успешному производству товар постоянного качества, по самой низкой цене. Сборочная линия была очень линейной по своей природе и все, что замедляло или останавливало линия приравнивалось к потерям производства и выручки. Тем не менее, где добавить безопасность в рамках методологии Waterfall?
Традиционно команды Application Security (AppSec) работали с командами разработчиков программного обеспечения на двух этапах: технические требования, дизайн, и прямо перед тем, как программное обеспечение было запланировано к выпуску в продакшн. После того, как команда проекта собрала бизнес-требования и определили целевую архитектуру, затем их проект пошел в AppSec команде для обзора. Этот обзор обычно включает некоторые формы моделирования угрозы при обмене данными. После завершения формировался список требования по безопасности, и они добавлялись в проектный документ. Документ передавался команде разработки, которые в свою очередь работали над разработкой приложений следующие несколько месяцев (или дольше).
После того, как у команд разработчиков было рабочее приложение, которое отвечало задокументированным требованиям, и пользователи подтверждали, что это то, что им необходимо, команда проекта снова взаимодействует с командами AppSec. Работая в качестве шлюза безопасности, команды AppSec запускают различные тесты на проникновение, чтобы найти уязвимости безопасности в финальном продукте. Они формируют длинный список уязвимостей, которые должны быть исправлены до выпуска программного обеспечения в продакшн, и это останавливало конвейер разработки.
См. Рис. 1 ниже, где показано расположение шлюза безопасности в методологии Waterfall.
К сожалению, для всех участников участие AppSec команды выходит ближе к концу конвейера. Такой подход вызывает задержку, разработчикам нужно время для исправления проблем безопасности в конце проекта, безусловно, ставит под угрозу график проекта в целом.
В результате все были недовольны. Команды AppSec были недовольны, потому что выявленные проблемы безопасности, вероятно, останутся в продуктиве, так как график проекта обычно выигрывает над безопасностью. Команды разработчиков были недовольны, потому что им пришлось работать сверхурочно, исправляя многие обнаруженные проблемы безопасности.
Наконец, руководство было недовольно, потому что оказалось взаимодейтствие команды AppSec и команды разработчиков не очень эффективно. Есть, конечно, лучший способ, и дальше мы будем его рассматривать.