Привет, Хабр! Меня зовут Нияз Кашапов, я AppSec Lead в Купере. Недавно я рассказывал на ecom.tech Information Security meetup, как выстраивается процесс написания безопасного кода и разбора срабатываний статических анализаторов. Эта статья — изложение моего выступления с дополнительными комментариями. Я опишу подход, к которому мы пришли, и открою секрет, как мотивировать разработчиков смотреть свой код на безопасность.

Всем привет. Меня зовут Нияз Кашапов, я AppSec Lead в СберМаркете. Улучшаю процессы безопасной разработки уже более 5 лет. Начинал карьеру в финтехе, где занимался безопасностью кода, фич и бизнес-процессов в онлайн-банкинге. А сейчас продолжаю начатое в одном из самых быстрорастущих игроков на рынке e-com.

Думаю, у многих в практике встречалась уязвимость, которую просто так не пофиксить — ведь она заложена глубоко внутри разрабатываемого решения, обвешана кучей зависимостей и требует полного ребилда самого решения. Чаще всего такие уязвимости остаются в проде навсегда и удерживаются от «падения» множеством костылей. Возникает резонный вопрос: «Как они возникли?» Чаще всего ответ — «Так исторически сложилось», а истоки проблемы давно забыты. Боролься с таким лучше превентивно, а как это сделать — попробую рассказать в этой статье.

Поговорим о том, как избегать ситуаций, когда уязвимость заложена на уровне архитектуры или бизнес-процесса и её исправление может стоить множество человеко-часов. Разберемся, когда фича становится багом и как прорабатывать архитектуру сервисов, не создавая дыры безопасности.

Статья про создание inhouse-решения для обнаружения и предотвращения мошеннических операций проводимых в интернет-банкинге одного маленького, но очень гордого банка в Татарстане. Из статьи узнаете о том зачем и кому нужен антифрод, почему внутренняя разработка оказалась дешевле покупки готового решения и к чему приводят пара строчек кода перед новым годом.