В предыдущей статье мы ознакомились с безопасностью в Waterfall проектах, продолжаем рассматривать дальше.
Было ясно, что нужна лучшая методология, которая могла бы включить безопасность в процессы разработки, но был ли Agile создан для решения проблемы безопасности? Не обязательно так.
Agile стал решением линейно-основанных недостатков методология Waterfall. В 2001 году группа влиятельных лиц решила
переосмыслить разработку программного обеспечения и в результате был сформирован Agile Манифест.
Весь смысл Agile заключался в создании Agile (реагировать на изменить) среду, которая не воспроизводит полностью линейную, негибкую, конвейерную методологию waterfall. Самое важная характеристика Agile методологий позволила разработчикам стать более гибким в изменениях в течение всего процесса, на основе итерационных (повторяющихся)
действий. Сотрудничество между кросс-функциональными командами было высоко подчеркнуто в Agile методологии, так как она дала людям возможность принимать командные решения и приспосабливаться к постоянному тестированию и изменению требований к каждой интеграции.
Появление Software Security Sandwich
Удалено: В методологиях Wterfall и Agile есть много связанных с безопасностью действий на этапе формирования бизнес-требований и технического проектирования. Тестирования безопасности программного обеспечения перед выпуском в продашн. Эти два этапа проверки на безопасность программного обеспечения, привели к появлению так называемой
Удалено: сэндвич безопасности. Хотя Agile был широко принят и используется командами разработчиков по всему
Удалено: миру, это все еще не эффективное решение безопасности программного обеспечения, которое существовало в Waterfall. Software Security Sandwich все еще существует, потому что организации не интегрировали безопасность на всех этапах разработки программного обеспечения. Agile, безусловно, помогает решить переходный характер сегодняшних бизнес-циклов, но он все еще не ставит безопасность в приоритете.