Журнал "Information Security/ Информационная безопасность" #3, 2023

Валерий Черепенников, 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. 48 • СПЕЦПРОЕКТ