(S)SDLC, или Как сделать разработку безопаснее. Часть 3
Этой статьей мы завершим небольшой цикл о построении процесса безопасной разработки на основе SAST — статического анализа кода на безопасность. В первой части мы разобрали основные вопросы, возникающие при внедрении SAST в процесс разработки. Во второй части остановились на технических аспектах внедрения и разобрали несколько примеров выстраивания SSDLC на практике. В последней части расскажем об организационных моментах.
Для большинства компаний использование SAST — это новый процесс, а уязвимость — новая сущность. Уязвимость — это не баг и не функциональное требование, и нужно выстраивать процесс работы с новой сущностью. Нельзя забывать про историческое разделение безопасности и разработки, которое особенно обостряется, когда в процесс разработки нужно внедрять что-то новое. Масла в огонь подливают и технические особенности статического анализа, о которых мы говорили во второй части.
Источник: Хабрахабр
Похожие новости
- Почему «витрина достижений» информационной безопасности работает далеко не везде
- ИИ Агенты как новая киберугроза: бизнесы теряют деньги и данные, не понимая почему
- Архитектура PERA для построения промышленной сети
- Telegram Web съел 30% моего 16-ядерного процессора. Расследование странного поведения, или Призрак майнера в браузере
- Настройка межсетевого SSH-доступа в многосегментной сети Cisco и MikroTik в среде GNS3
- Рост продаж на маркетплейсах без демпинга: возможен или нет
- Vitamin.tools: Как быстро и эффективно находить сотрудников или собрать пожертвования через VK Ads: два кейса от клиента Vitamin.tools
- Лебедев Денис: Боты статистики в Telegram: что они умеют, кому подходят
- От BlueBorne до LE Secure: как Bluetooth выжил после самых громких дыр
- Ты не покупатель. Ты — герой мифа