(S)SDLC, или Как сделать разработку безопаснее. Часть 3
Этой статьей мы завершим небольшой цикл о построении процесса безопасной разработки на основе SAST — статического анализа кода на безопасность. В первой части мы разобрали основные вопросы, возникающие при внедрении SAST в процесс разработки. Во второй части остановились на технических аспектах внедрения и разобрали несколько примеров выстраивания SSDLC на практике. В последней части расскажем об организационных моментах.
Для большинства компаний использование SAST — это новый процесс, а уязвимость — новая сущность. Уязвимость — это не баг и не функциональное требование, и нужно выстраивать процесс работы с новой сущностью. Нельзя забывать про историческое разделение безопасности и разработки, которое особенно обостряется, когда в процесс разработки нужно внедрять что-то новое. Масла в огонь подливают и технические особенности статического анализа, о которых мы говорили во второй части.
Источник: Хабрахабр
Похожие новости
- Как я пилотировала Kaspersky NGFW и что из этого вышло
- Нежданные гости: F6 проанализировала первые масштабные атаки группы Kinsing на российские компании
- Миллион IP против одного GPT-5: история одной DDoS-атаки
- Опыт цифровизации службы безопасности банка. Единая IT-экосистема на базе BPMS
- Сервис DashaMail обновил функционал аннотаций в GMail
- Вредные советы по автоматизации
- Кем работать в IT в 2025: сетевой инженер в информационной безопасности
- [Перевод] Как найти исходный IP любого веб-сайта за WAF
- Приоритизация уязвимостей с EPSS в кибербезопасности
- Безопасность приложений: инструменты и практики для Java-разработчиков