Как стать автором
Обновить

Баланс между скоростью разработки, UX и безопасностью: погружение в трилемму современного IT

Уровень сложностиПростой
Время на прочтение36 мин
Количество просмотров1K
Всего голосов 4: ↑4 и ↓0+4
Комментарии4

Комментарии 4

Проблема в том что каждый участник процесса как "в поле каждый суслик агроном".... :-)
Безопасник - "перестраховывается" не понимая (или не желая понимать) особенности технологии построения прикладного продукта и его отдельных компонентов. Это проще чем изучать особенности отдельных уязвимостей кучи "отдельных кирпичей" построенного системно-прикладного ПО и определения наиболее вероятных атак на него.
Разработчик/архитектор - "плюет" на безопасность ради "модной" архитектуры и/или фреймворка. Тем более и не хочет "заморачиваться" с потенциальными уязвимостями используемыми им компонентами и возможным потенциальным ростом прикладной нагрузки. А вот "поиграться в новое" - это его выбор.
Дизайнер - скорее будет строить модный и "красивый" (по его личному мнению) UX, хорошо если хотя бы при этом хоть что-то знает про эргономику и безопасность....
Product owner - скорее всего "пришел" из разработки, и в первую очередь "на ее стороне". Отсюда и принимаемые им решения.
Бизнес - знать ничего не хочет кроме "чем быстрее - тем лучше" и "чем меньше затрат - тем лучше".
"Специалист подобен флюсу, полнота его одностороння." ©

Спасибо за такую детальную статью с компетентным разбором вопроса. Чувствуется долгая работа над наболевшим вопросом.

Статья интересная и многое раскладывает по полочкам. Плюс собрано множество фреймворков методологий, за это автору отдельное спасибо!

Но где-то с середины статьи идет сильный перекос в ИБ и SSDLC и централизация ценности безопасности продукта с упрощением остальных ролей и функциональности. В этом плане хотелось бы больше деталей и примеров: как это все живет на практике у вас в компании со стороны продуктовых команд.

Статья хорошая, но зачем смешивать вопросы, которые решаются отдельно и независимо?

1:

Задача UX – найти "usable security": интегрировать защиту так, чтобы она была эффективной, но минимально заметной и обременительной.

SSO - ни паролей ни капча, или yubikey. все? можно UI вычеркивать?

2: разработчик фичь - каким боком в безопасность? каждая фича должна быть как-то специально обернута в безопасность? это, плохой подход. безопасность делается прозрачно и однообразно, и обычно на новые фичи не влияет.

3: Вы говорите о про безопасность во время выхода нового продукта на рынок, или фичи в существующем продукте? Приведенные примеры показывают факапы больших бизнесов, топ манагеры, которых долго плевали на безопасность, чем и поплатились. Как это относится к выводу, например, стартапом нового продукта на рынок?

Итого - если продакты и манагеры клали на безопасность, зачем вы обвиняете девелоперов?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации