Ева Беляева, Security Vision
Когда-то народы разработчиков и безопасников жили в мире, но все изменилось, когда регулятор решил прорегулировать и их процессы тоже.
1. Общий язык
Точнее, его отсутствие. Специалисты зачастую существуют в своих определенных системах координат, где приоритеты отданы разным, на первый взгляд не пересекающимся задачам. К примеру, какая задача стоит перед хорошим безопасником? Скорее всего, сертификация продукта. Перед отличным безопасником, как и перед отличным разработчиком, стоит задача выпустить качественный и безопасный продукт, но к такой ступени эволюции нужно еще перейти.
Какие же задачи стоят перед хорошей командой разработки? Вероятнее всего, создание нового функционала, которое в особо тяжелых выгорательных случаях превращается в счетчик задач тикет-системы.
Существуют различные способы мотивировать и разработчика, и безопасника. У них есть что-то общее – как, например, мотивация обрести долгожданный сертификат; но такой мотивацией занимается как правило компания. Что же до мотивации более мягкой – зачастую таким двигателем прогресса становится очень замотивированный человек «со взором горящим», готовый крушить и ломать код перед собой (иногда это расстраивает тимлидов), но в любом случае, работа эта довольно творческая.
Основные конфликты происходят как раз в том случае, когда на тропу войны выходят безопасник с конкретной задачей и разработчик с длинным хвостом бэклога, и с первого взгляда неясно, как именно им следует объединить усилия и почему задача на самом деле общая.
В частности, некоторые проблемы начинаются с подозрений: не внедрит ли разработчик вредоносный коммит, насколько хорошо лиды разбираются в безопасности коммитов и мерджей, как много библиотек используется при разработке open source? Одним прекрасным днем может оказаться, что привычные инструменты скомпрометированы, что явно подсвечивает необходимость анализа кода.
2. POC и как его готовить
Вторым камнем преткновения является предоставление доказательств как последнего оплота убеждения несогласного коллеги.
Зачастую недостаточно аргумента «вот есть цель, на пути у цели баг – баг нужно убрать». Такая логическая последовательность, хоть и достоверна, может таить в себе множество нюансов. У команды разработки на все эти случаи припасено внушительное множество контраргументов: и никогда звезды не сойдутся в нужной последовательности так, чтобы атака произошла; и никому не придет в голову таким заниматься; и даже физически злоумышленник никогда-никогда, правда-правда не доберется до исходного кода/возможности подменить файл/подставить нужное. И вообще, это легаси, а что мы сделаем?
Именно поэтому за каждым багом должен прочно обосноваться POC, если этого недостаточно – POC с примерами воспроизведения, а если и этого недостаточно – POC, полученный в ходе пентеста, повлекшего за собой неработоспособность ПО. Но если и этот аргумент не убедит разработчика, в ход идет последнее средство – искусство перевода с русского на русский – от безопасности к разработке. Если повезет, этим таинственным кунг-фу будет заниматься специально обученный человек (об этом позже), но будем честны: очень часто – не везет. Без этой магии никогда, увы, не решить проблему.
Потому что, сколь бы ни был критичен баг, сколь бы ни был он важен для сертификации продукта в целом – пока представление проблемы не будет переложено в систему координат тех, кому с этим багом возиться, дело никогда не сдвинется с мертвой точки. Правда, никто не застрахован от того, что ваш спор перейдет в новую плоскость даже после предоставления железобетонных доказательств – теперь безопаснику предстоит обосновать и отстоять критичность, а потом – сроки, а потом...
3. Анализ кода
Раз уж мы хоть и косвенно затронули зоны ответственности (и компетенции), можно поговорить о самом наболевшем: кто же все-таки должен встраивать процесс анализа кода в процесс разработки продукта? Кто будет отвечать непосредственно за реализацию? Статический анализ хорош тем, что может существовать обособленно, выдавая множество достоверных и не очень замечаний вкупе со статистикой покрытия кодовой базы. Динамический же анализ не так прост – для таких проверок требуется оставлять в самом коде «врезки», а также возможность выполнить сборку продукта именно с целю тестирования – это может быть патч, условия запуска, какой-либо другой вариант, удобный безопаснику, но практически никогда не устраивающий разработку. Почему так?
Проблем, косвенно или напрямую относящихся к этой (без иронии) непростой задаче, может быть много. Высокая загрузка или недостаток компетенций – самые распространенные из них. Однако, стоит заметить, что множество аргументов, сводящихся к «а давайте вы как-нибудь сами», рано или поздно все же приведут к тому пути, при котором методом многих или не очень проб и ошибок разработчик поймет: этот подход полезен (и удобен), в первую очередь, ему самому.
4. А что сплачивает?
Очевидно, что-то общее. Общий друг или общий враг. Что по части врага – нередки случаи выстаивания чудесных и долговечных дружеских отношений с коллегами после совместных чтений требований от регулятора. Иногда получается устроить и целый стендап, и ролевые игры – когда одна команда засчитывает требования, а вторая – пытается угадать, какой во всем этом был смысл.
Пройти огонь и воду вместе. Позвольте хотя бы одному запуску SDL хотя бы в рамках одного продукта обточить острые углы на всех камнях преткновений – и команды сами не заметят, как перебрасывание бага, словно горячей картофелины из рук в руки, перейдет к здоровому и, главное, полезно-приятному процессу поиска уязвимых мест в коде. И где там, кстати, наш долгожданный отчет по покрытию?
Увидеть первые результаты работы в целом бесценно – на словах не всегда очевидно, к чему может привести новый формат. И даже более того, в какой-то момент приходит возможность влиять на эти самые нормативные документы и на ключевые значения и настройки анализа кода – кто же упустит шанс повлиять на ФСТЭК и приблизить регулятора к реальности.
Можно ли сделать так, чтобы сразу все было хорошо? Конечно, волшебная таблетка существует и на такой случай, и даже не одна. Во-первых, никто и ничто не помешает разработчику и безопаснику сделать хорошо, если им этого действительно хочется. Когда команды изначально заинтересованы в качестве продукта, в эффективности при устранении проблем, вопроса о противостоянии даже не возникает.
В процессе взаимодействия стираются многие острые углы, потому и говорят, что для успеха application security становится полноценной частью команды, постоянно на связи и по уши в коде, готовый рваться через тернии к заветному Secure by design.
Во-вторых, если спуститься с небес на землю и представить более реальную картину, грамотно наладить взаимодействие поможет один чудесный покемон специалист – security champion. Но об этом как-нибудь в другой раз.
