Комментарии 4
Проблема в том что каждый участник процесса как "в поле каждый суслик агроном".... :-)
Безопасник - "перестраховывается" не понимая (или не желая понимать) особенности технологии построения прикладного продукта и его отдельных компонентов. Это проще чем изучать особенности отдельных уязвимостей кучи "отдельных кирпичей" построенного системно-прикладного ПО и определения наиболее вероятных атак на него.
Разработчик/архитектор - "плюет" на безопасность ради "модной" архитектуры и/или фреймворка. Тем более и не хочет "заморачиваться" с потенциальными уязвимостями используемыми им компонентами и возможным потенциальным ростом прикладной нагрузки. А вот "поиграться в новое" - это его выбор.
Дизайнер - скорее будет строить модный и "красивый" (по его личному мнению) UX, хорошо если хотя бы при этом хоть что-то знает про эргономику и безопасность....
Product owner - скорее всего "пришел" из разработки, и в первую очередь "на ее стороне". Отсюда и принимаемые им решения.
Бизнес - знать ничего не хочет кроме "чем быстрее - тем лучше" и "чем меньше затрат - тем лучше".
"Специалист подобен флюсу, полнота его одностороння." ©
Спасибо за такую детальную статью с компетентным разбором вопроса. Чувствуется долгая работа над наболевшим вопросом.
Статья интересная и многое раскладывает по полочкам. Плюс собрано множество фреймворков методологий, за это автору отдельное спасибо!
Но где-то с середины статьи идет сильный перекос в ИБ и SSDLC и централизация ценности безопасности продукта с упрощением остальных ролей и функциональности. В этом плане хотелось бы больше деталей и примеров: как это все живет на практике у вас в компании со стороны продуктовых команд.
Статья хорошая, но зачем смешивать вопросы, которые решаются отдельно и независимо?
1:
Задача UX – найти "usable security": интегрировать защиту так, чтобы она была эффективной, но минимально заметной и обременительной.
SSO - ни паролей ни капча, или yubikey. все? можно UI вычеркивать?
2: разработчик фичь - каким боком в безопасность? каждая фича должна быть как-то специально обернута в безопасность? это, плохой подход. безопасность делается прозрачно и однообразно, и обычно на новые фичи не влияет.
3: Вы говорите о про безопасность во время выхода нового продукта на рынок, или фичи в существующем продукте? Приведенные примеры показывают факапы больших бизнесов, топ манагеры, которых долго плевали на безопасность, чем и поплатились. Как это относится к выводу, например, стартапом нового продукта на рынок?
Итого - если продакты и манагеры клали на безопасность, зачем вы обвиняете девелоперов?
Баланс между скоростью разработки, UX и безопасностью: погружение в трилемму современного IT