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