Редакция журнала "Информационная безопасность", 01/09/23
Внедрение SDL (Secure Development Lifecycle) - важный этап для обеспечения безопасности в разработке ПО. Он требует сотрудничества и согласования между командой разработчиков и другими интересующими сторонами. На практике со стороны команд разработчиков часто встречается сопротивление усилиям по внедрению SDL. Своим опытом, как "разрулить" конфликтные ситуации, поделились эксперты из ведущих российских компаний.
Роман Борзов, Андрей Кузнецов, Фобос-НТ:
Ключом к улаживанию такого противоборства является повышение уровня доверия между аудиторами, разработчиками и создаваемой SDL-командой. Это достигается за счет проведения встреч с командами разработки, на которых демонстрируются примеры применения лучших практик, их польза для процесса разработки в части качества исходного кода и для компании в части безопасности итогового продукта, что в целом повышает репутацию компании на рынке.
Лука Сафонов, Синклит:
Противоборство с командой решается поддержкой руководства организации. Если принято волевое решение, деваться некуда. Естественно, у команд всегда присутствует большая доля скепсиса: трудозатраты повышаются, времени, чтобы пилить фичи, становится меньше. Но если показать реальную пользу от процесса SDL, продемонстрировать, как ошибка в коде может привести к полной компрометации в системе, подсказать разработчику, как искать проблемы и как их избегать, негатив уходит и начинается конструктивное взаимодействие.
Алексей Смирнов, CodeScoring:
У нас в команде таких вопросов не возникает, поскольку наш продукт сам является SDL-инструментом и все конструктивно воспринимают безопасность. Но в полях мы действительно видим большое количество встречных отговорок от безопасности. Самая популярная – "нужно исправлять баги от заказчика, нет времени настраивать SDL". Важно объяснить, что функциональные ошибки и ошибки безопасности – одного поля ягоды. К тому же исправление багов безопасности зачастую более увлекательная инженерная задача, чем исправление функциональности.
Сергей Груздев, Аладдин Р.Д.:
Дам сначала совет начинающим. Первым делом необходимо провести аудит актуального процесса разработки в команде, оценить его с разных сторон: уровень взаимодействия и коммуникации внутри и между командами, достаточно ли знаний и опыта для внедрения концепции безопасной разработки.
Если говорить конкретнее, нужно детально понять, насколько сложными инструментами обеспечения безопасной разработки команда владела ранее, способна овладеть сейчас и в перспективе (это относится как к разработчикам, так и к тестировщикам). При плохом уровне взаимодействия ошибки не будут исправляться.
Исходя из моего опыта могу сказать, что весь процесс организации безопасного процесса разработки занимает от А до Я около шести месяцев. Сейчас для автоматизации разработки софта и написания кода мы используем хорошо известные и проверенные временем инструменты: систему непрерывной интеграции Jenkins, собственные скрипты на Python, а также разнообразные средства тестирования безопасности, такие как Svace, AFL++, Crusher, Блесна.
Главный залог успеха в процессе "разруливания" – командоформирующие мероприятия, объединение команды, налаживание коммуникации.
Карина Нападовская, Лаборатория Касперского:
Противоборство было, есть и будет всегда! Я стараюсь подключать грамотных аудиторов, проводить встречи с регулятором для того, чтобы разработчики могли задать волнующие их вопросы и по-другому взглянули на ситуацию, увидев пользу от новых практик и инструментов. Только показав, что их труд не напрасен, можно добиться результата.
Валерий Черепенников, Nizhny Novgorod Research Center:
Могу вспомнить свой опыт разработки продукта в Intel примерно пять лет назад. Компания в директивном порядке навязывала практики SDL, и команда разработчиков изначально восприняла это в штыки: еще одна палка в колесо, как будто их без этого их мало. Но поскольку это было требованием компании, пришлось подчиниться. В результате SDL был внедрен только на уровне практик процессов и инструментов на уровне валидации. Сейчас мне кажется, что начинать надо был по-другому. Безопасность разработки сама по себе очень интересная инженерная задачка, и людей надо было попробовать этим заинтересовать. А коль скоро все они инженеры, это должно быть не так сложно.
Владимир Пономарев, Гарда Технологии:
Внедрение SDL-процесса виделось естественной заменой авральной подготовки к очередной сертификации. Противоборства не было, зато были вопросы типа "С кем все это делать?", много обсуждений, поездок на конференции, совещаний с лабораторией. В результате мы выделили команду AppSec, определились с приоритетами и внесли изменения в общий процесс разработки. Конечно, сложности были тогда и есть сейчас. Но главное, мы решили, что "без SDL дальше не получится", – и начали действовать.
Владимир Высоцкий, Solar appScreener:
Пример из жизни: в процессе внедрения SSDLC у ИБ не получалось реализовать контроль над безопасностью разрабатываемого ПО. ИТ не хотели вмешательства в свою зону ответственности и никак не помогали. Пришлось мне выступать буфером, и к концу второго этапа удалось убедить ИТ, что функции ИБ не в контроле, а в помощи при работе над общей целью.
К сожалению, противостояние ИТ и ИБ все еще встречается, и важно уже на начальном этапе учитывать этот риск. Нивелировать проблему поможет создание комфортных условий для объединения команд в решении общих задач, и тогда все будут победителями.
Валерий Богдашов, R-Vision:
Важный аспект для успешного внедрения SDL в компании – это поддерживание диалога с командами разработки. Каждая команда стремится сделать свой продукт более качественным, а безопасность является одним из показателей качества. Поэтому, выстраивая процессы SDL, не рекомендуется взаимодействовать с командами в формате указов, иначе большинство практик будет ими игнорироваться. Внедряемые инструменты и практики также должны быть удобными для работы, а результаты деятельности команд необходимо отображать в привычных для разработчиков инструментах (репозиториях, IDE, таск-трекерах и т.д).
Сергей Трандин, Базальт СПО:
Наша команда разработчиков никогда не сопротивлялась внедрению процессов безопасной разработки. Мы с самого начала органично включили SDL в процессы разработки операционных систем, проводили проверки средствами свободных программ. Правила игры по обеспечению безопасности программных продуктов меняются постепенно, эволюционно. И поскольку процесс проверки налажен, мы расширяем его постепенно и без потрясений: проводим тюнинг задач для команды разработчиков.
Дмитрий Евдокимов, Luntry:
Основной совет: делайте SDL не ради самого SDL. Четко понимайте цели и последствия ваших действий, а также то, какие конкретно проблемы вы решаете. Это позволит наиболее быстро увидеть результаты и правильно расставить приоритеты с учетом вашей специфики, а не на основании маркетинговых листовок.
Иван Панченко, Постгрес Профессиональный:
Обычный скепсис инженеров трудно преодолеть, тем более что формальная верификация кода дает много ложных срабатываний и заставляет трудиться вхолостую. Но при появлении реальных результатов мнение разработчиков постепенно меняется.
Марк Коренберг, Айдеко:
В действительности на первых этапах особого сопротивления не было, кроме, возможно, "да зачем оно вообще нужно, лишняя нагрузка". Но после обнаружения первых серьезных проблем в аспекте безопасности вопросы сами собой исчезли. Первое время было совершенно непонятно, как делать фаззинг. Но после погружения в тему стало понятно, что это не так уж и сложно, не так уж непонятно и не так уж невозможно.
Роман Карпов, Axiom JDK:
У нас такой проблемы не было, потому что инициатива внедрения SDL c момента создания программного продукта исходила от руководителей компании, и все инженеры стремятся поддерживать высокое качество и безопасность продукта – такой подход у нас в ДНК. Чтобы внедрение SDL было успешным, оно не должно рушить выстроенные процессы и становиться сверхурочной задачей для загруженной команды разработчиков. SDL необходимо преподносить как параллельный процесс, плавно интегрируемый в уже устоявшиеся процессы разработки.
Оксана Новослугина, СПб ИАЦ:
Очень важна фаза обучения и стремление к автоматизации процессов. На фазе обучения команда продуктовой безопасности работает с менеджерами, разработчиками и тестировщиками. Цель этой работы – описать всем участникам процесса базовые модели угроз для продукта и научить команду бороться с причинами их реализации – уязвимостями. Это один из самых важных этапов, так как код пишут люди и безопасность напрямую зависит от его качества. Для разработчиков в настоящий момент мы создаем отдельное адаптированное руководство. В нем описаны базовые принципы безопасной разработки, перечень возможных уязвимостей для разного типа приложений, показаны типичные примеры уязвимого кода и исправлений. Есть также информация о том, как использовать различные техники и технологии снижения вероятности эксплуатации уязвимости, так называемые Mitigations.
Сергей Деев, МТС RED:
Внедрение любого процесса начинается с аудита. Важно проанализировать, как устроены процессы безопасной разработки, и выработать рекомендации по их улучшению, опираясь на лучшие практики. Затем нужно получить от руководства компании полномочия на внесение изменений в процессы разработки, после чего переходить к внедрению: определить ответственных лиц и сформировать принципы взаимодействия между ними. При этом нужно учитывать ограничения разработки по ресурсам, требования бизнеса к срокам выпуска релизов и т.д. Внедрение практик безопасной разработки реализуется поэтапно, от общего к частному, учитывая интересы всех сторон. При таком подходе сопротивление разработчиков будет минимальным.
Сергей Сергеев, КСБ-СОФТ:
Естественно, что при внедрении новых процессов, в том числе SDL, растет нагрузка на команду разработки и появляются дополнительные издержки для компании. Это встречает сопротивление. Но в ходе внедрения SDL мы помогаем улучшать качество разработки кода, что в перспективе снимает определенную нагрузку с разработчиков и увеличивает монетизацию продукта. Начинающим компаниям рекомендую выделять внутри продуктовой команды роль Security Champion для транслирования команде разработки практик SDL.
Александр Дубинин, YADRO:
Противоборства в нашей практике не было. Есть задача постоянного совершенствования процессов разработки, причем не только в части SDL: автоматизация и улучшение процессов работы с архитектурой, документацией, прослеживаемостью требований до кода и обратно. И это у многих встречает понимание.
Полная версия круглого стола в журнале "Информационная безопасность": https://cs.groteck.com/IB_3_2023/40/
