Что для вас SDL с точки зрения инструментов и практик?

Внедрение процессов SDL – это ответственный этап для любой организации, занимающейся разработкой приложений. Тех, кто только встает на этот путь, ожидает ряд интересных сложностей: от мотивации себя, руководителей и коллег до выбора конкретных инструментов, реализующих необходимые аспекты SDL.

Редакция журнала “Информационная безопасность" попросила экспертов, уже достигших определенных успехов в этом направлении, рассказать, что для них означает SDL, указав три пункта в порядке убывания значимости.

Сергей Груздев, Аладдин Р.Д.:

С точки зрения практики SDL – это фокус на этапе реализации, если следовать методологии Microsoft. Для обеспечения безопасности разработки на этом этапе используются статический анализ и доверенные средства разработки, практикуется отказ от небезопасных функций в коде и его перекрестная проверка.

1. На первое место по значимости можно поставить статический анализ, который представляет собой серию автоматических проверок исходного кода и экономит человеческие ресурсы во время тестирования. Кроме того, он выявляет большое количество распространенных ошибок и уязвимостей, помогает четко следовать стандартам написания кода и благотворно влияет на его качество. Легкая работа с обнаруженными ошибками на этапе написания кода позволяет ускорить процессы взаимодействия между командами, а значит, и ускорить процесс написания и последующей отладки исходного кода приложения. Статический анализ как инструмент просто интегрируется в процесс безопасной разработки.
2. На второе место можно поставить фаззинг-тестирование – многократный запуск кода на намеренно поврежденных входных данных. На практике это длительный и сложный процесс, но ошибки, которые он выявляет, практически всегда являются эксплуатируемыми, что ведет к рискам безопасности.
3. На третье место смело можно поместить регрессионное тестирование кода, когда необходимо убедиться, что внесенные изменения не повлияли негативно на существующую функциональность приложения. Автоматизация регрессионного тестирования экономит время команды, деньги, ускоряет выпуск релиза.

Именно эти три инструмента мы считаем наиболее значимыми для обеспечения SDL. Но, конечно, не стоит забывать про динамический анализ, исследование поверхности атаки и тестирование на проникновение.

Алексей Смирнов, CodeScoring:

Для меня SDL – это инструмент обеспечения качества ПО. Его задача – навести порядок в том, что мы делаем, и следить за процессами разработки/сопровождения с учетом безопасности.

1. Важно наличие практики непрерывного контроля безопасности на всех этапах разработки, от проектирования и выбора сторонних компонентов до проверки кода продукта на этапах выпуска и в процессе сопровождения.
2. Практика безопасной разработки должна работать так, чтобы процессы не были рваными или запутанными. Правильная расстановка и настройка инструментов в жизненном цикле создания ПО и эффективное выстраивание культуры коммуникаций позволяют существенно снизить накал страстей между ИТ/ИБ и идти одной дорогой.
3. Применение SDL-практик – прямой показатель зрелости разработки программного обеспечения.

Роман Борзов, Андрей Кузнецов, Фобос-НТ:

SDL – это инструменты и практики, непосредственно влияющие на качество и безопасность исходного кода программного обеспечения.

1. Композиционный анализ при проектировании ПО, анализ зависимостей приложения (OWASP Dependency-Check, CodeScoring и др.).
2. Статический и динамический анализ программного обеспечения (Svace, SonarQube, Crusher/Sydr, AFL).
3. Автоматизация модульного, регрессионного и функционального тестирования.

От зрелости SDL-процессов зависит качество конечного продукта, кустарность изготовления которого хорошо видна в противном случае.

Борис Позин, ЕС-лизинг:

1. Развитие разработанной нами в начале 2000-х гг. и использованной крупными заказчиками концепции и автоматизированной технологии обеспечения жизненного цикла ПО на новом этапе развития ПО для информационных систем различного назначения. Инструменты и практики вторичны, ведь сначала нужно определить цели и задачи проведения тех или иных работ. Если цели и задачи определены, значит, можно определить критерии качества ПО (и работ), по которым будет оцениваться эффективность или неэффективность инструментов и практик. К сожалению, в этой области сейчас успехов немного, и это на данном этапе одно из главных направлений работ. Нужно дополнить описание ЖЦ ДПО сведениями об этапности работ, объекте и предмете работ на каждом этапе, методах оценки состояния и критериях завершения и качества работ. Тогда и вопросы об инструментах и методиках (практиках) упорядочатся с позиций целесообразности их применения и достаточности уровня автоматизации. SDL, по существу, – это бизнес-процесс, который автоматизируется. Комплексно автоматизированный бизнес-процесс позволяет повысить производительность труда коллектива. Разве не это главная задача?
2. Разработать некоторый набор типовых технологических процессов для классов ПО вместе с комплексом критериев и методик и осуществить отработку комплексов инструментальных средств для поставки, обучения и внедрения в компаниях – владельцах ПО для использования при разработке, сопровождении и развитии систем. Это позволит организациям снизить эксплуатационные затраты при использовании систем.
3. Обучить в вузах и подготовить специалистов для отрасли.

Валерий Черепенников, Nizhny Novgorod Research Center:

1. Понимание инженерных основ: какие возможны уязвимости в программах и как можно их избежать.
2. Общая культура разработки программного обеспечения, которая должна быть прошита в ДНК разработчика.
3. Практики, процессы и инструменты.

Карина Нападовская, Лаборатория Касперского:

1. Четко выстроенные процессы внутри компании. Зачастую именно процесс является очень хорошим инструментом при внедрении чего угодно, в том числе безопасной разработки.
2. Контроль качества разработки перед выпуском релиза. Когда независимое подразделение проверяет реализацию всех практик в продукте и блокирует релиз в случае выявления ошибок, это стимулирует разработчиков сразу делать продукт хорошо.
3. Постоянное обучение и развитие кадров. Если штат компетентен, любые процессы можно внедрить, любыми инструментами научиться пользоваться.

Владимир Высоцкий, Solar appScreener:

1. Квалифицированные и заинтересованные в развитии специалисты.
2. Выстроенный процесс взаимодействия в команде.
3. Эффективная командная работа с любыми инструментами.

Дмитрий Евдокимов, Luntry:

1. Вовлеченность всех департаментов компании, отвечающих за приложение на всех его жизненных стадиях.
2. Процесс, охватывающий все жизненные стадии приложения, от проработки архитектуры до эксплуатации.
3. Максимальное встраивание в процесс разработки и автоматизация.

SDL – это сочетание людей и команд, процессов и инструментов.

Екатерина Вайц, МГТУ им. Н.Э. Баумана:

1. Компонентный анализ заимствованного кода (SCA).
2. Статический анализ кода.
3. Динамический анализ (фаззинг-тестирование) кода, находящегося на поверхности атаки.

Иван Панченко, Постгрес Профессиональный:

1. Возможность организации регулярного процесса поиска ошибок, которые иначе было бы трудно обнаруживать.
2. Интересные вызовы для сотрудников, наукоемкий процесс с интересными задачами.
3. Область, в которой компания может проявить себя в качестве технологического лидера.

Валерий Богдашов, R-Vision:

1. Обеспечение безопасной архитектуры разрабатываемых продуктов. Ошибки безопасности на уровне архитектуры являются самыми дорогостоящими в устранении, устранить их порой невозможно. Поэтому крайне важно предотвратить небезопасную архитектуру приложения в самом начале его разработки.
2. Обеспечение безопасной сборки продуктов. Необходимо обеспечить сборку продуктов так, чтобы в процессе разработки злоумышленники не имели возможность изменять код продукта, внедрять закладки, а также подменять используемые зависимости, которые потом могут быть проэксплуатированы ими.
3. Безопасность Open Source. При использовании Open Source необходим комплексный анализ, включая проверку юридической чистоты лицензий, выявления различных зависимоcтей, проверку на наличие уязвимостей из различных баз (например, CVE и др.), применение механизмов защиты для нейтрализации потенциальных угроз.

Лука Сафонов, Синклит:

1. SDL – это непрерывный, динамичный, живой процесс на всех этапах жизненного цикла разработки. Его нельзя просто внедрить и забыть.
2. Внедрение нужно проводить поэтапно, чтобы избежать остановки процесса самой разработки, итеративно повышая полноту и качество процесса. Этого слона нужно кушать по частям.
3. Необходимо использовать передовой инструментарий мирового уровня. Иногда это требует дополнительных затрат, но преимущества видны сразу же.

Марк Коренберг, Айдеко:

1. Анализ архитектуры и безопасности информационной системы, имплементация механизмов защиты.
2. Регулярное обновление продукта, используемых решений Open Source, устранение уязвимостей (cve/cwe).
3. Строго определенный процесс разработки со своими правилами, этапами.

Разумеется, помимо архитектурного анализа производится пентестинг, фаззинг, статический анализ компонентов, и особенно поверхности атаки. Анализ покрытия кода не только юнит-тестами, но и в рамках других технологий. Автоматизированная система сборки и тестирования продукта. Мониторинг и своевременное реагирование на появляющиеся уязвимости и новые виды атак и угроз.

Владимир Пономарев, Гарда Технологии:

О безопасности нужно думать с самого начала.

1. Анализ рисков и угроз на этапе проектирования.
2. Безопасность должна быть неотъемлемой частью процесса разработки. Для нас это DevSecOps.
3. Управление и развитие. Важно, чтобы SDL приносил пользу, но и не ограничивал. Тут как с любым делом – стоит только начать.

Роман Карпов, Axiom JDK:

1. Ответственность за результат проведенных исследований и уверенность в качестве продукта, что дает гарантии клиентам в защищенности систем на его основе на всех этапах жизненного цикла.
2. Постоянное совершенствование практик безопасной разработки.
3. Развитие опыта сотрудников в области безопасной разработки, повышение профессионализма и культуры разработки как внутри нашей инженерной команды, так и ИТ-специалистов на рынке в целом, в других ИТ-компаниях и ИТ-подразделениях заказчиков.

Сергей Деев, МТС RED:

1. Эксперты в службе ИБ и в блоке разработки, способные распознать уязвимости в ПО и сборочной инфраструктуре, приоритизировать их и принять необходимые меры к их устранению.
2. Процессы управления безопасной разработкой.
3. Инструменты, позволяющие не только выявлять уязвимости в ПО и обеспечивать безопасность сборочной инфраструктуры, но и решать эти задачи, сохраняя эффективность бизнес-процессов в компании (скорость выпуска релиза, гибкие методологии разработки и т.д.).

Сергей Сергеев, КСБ-СОФТ:

1. Культура безопасности поможет взаимодействию команд разработки и безопасности, что приведет к росту осведомленности разработчиков о правилах безопасности и улучшению защищенности продукта на ранних стадиях жизненного цикла.
2. Выстроенный процесс Vulnerability Management поможет грамотно осуществлять контроль жизненного цикла уязвимостей.
3. Композиционный анализ поможет выявлять уязвимости в заимствованных компонентах с открытым исходным кодом, используемых разработчиками при создании собственного ПО.

Сергей Трандин, Базальт СПО:

1. Интеграция средств проверки в основную инфраструктуру разработки.
2. Использование проверенных инструментов контроля.
3. Выпуск сертифицированных продуктов на основе отдельной ветки проекта "Сизиф", организованной в соответствии с требованиями безопасной разработки.

Александр Дубинин, YADRO:

1. Инженерная культура. SDL – одна из проекций инженерных принципов, позволяющих создавать качественные продукты.
2. Подтвержденная тестами надежность и стабильность продуктов.
3. Качество кода и архитектуры, поддерживаемость, возможность дальнейшего развития.

Оксана Новослугина, СПб ИАЦ:

1. Главная задача – минимизировать риски с точки зрения безопасности и улучшить качество выпускаемой продукции.
2. Максимально усложнить эксплуатацию уязвимостей.
3. Сократить сроки устранения и внесения изменений в продукт.

Полная версия круглого стола в журнале "Информационная безопасность": https://cs.groteck.com/IB_3_2023/40/