Безопасная разработка (SSDLC, DevSecOps)

DevSecOps — практика интеграции тестирования безопасности во все этапы разработки ПО. В более широком понимании под этим термином предполагается культурная и методологическая философия в сфере создания программного обеспечения, в рамках которой интегрируются практики безопасности в процедуры непрерывной разработки и доставки (DevOps).

К основным принципам DevSecOps относят: встраивание безопасности в жизненный цикл разработки программного обеспечения, автоматизация, культура сотрудничества и обмена знаниями, беспрерывная обратная связи и анализ безопасности продуктов.

Редакция CISOCLUB поговорила с экспертами, чтобы выяснить, что такое безопасная разработка и нужна ли она, какие требования предъявляют регуляторы. Мы попросили рассказать об идеальном процессе DevSecOps, инструментах, которые нужно использовать, особенностях подготовки инфраструктуры к внедрению DevSecOps. Эксперты рассказали какие СЗИ являются неотъемлемой частью безопасной разработки, а также ответили на другие вопросы.

На наши вопросы ответили:

• Денис Фокин, руководитель отдела технического консалтинга и инженерной поддержки направления ИБ компании Axoft.
• Владимир Ченцов, руководитель департамента комплексного аудита ИБ и безопасной разработки компании «Бастион».
• Александр Дроздов, инженер по РБПО и информационной безопасности Axiom JDK.
• Антон Башарин, технический директор Swordfish Security.
• Владимир Арышев, эксперт по комплексным ИБ-проектам STEP LOGIC.
• Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет».
• Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED.
• Дмитрий Смирнов, начальник отдела информационной безопасности NGENIX.
• Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар».
• Андрей Бирюков, СТО ГК InfoWatch.
• Дмитрий Дудко, заместитель генерального директора компании Spacebit.

Что такое безопасная разработка и зачем она нужна?

Денис Фокин, руководитель отдела технического консалтинга и инженерной поддержки направления ИБ компании Axoft:

Денис Фокин, руководитель отдела технического консалтинга и инженерной поддержки направления ИБ компании Axoft 📷

«Безопасная разработка – это процесс. Процесс, не сильно отличающийся от процесса обеспечения ИБ в организации и по сути являющийся его частью. И, как схожий процесс, он имеет те же базовые требования: оценка рисков, планирование, компенсация или устранение угроз. Основное отличие DevSecOps от процесса обеспечения ИБ заключается в том, что угрозы, связанные с разработкой приложений, специфичны и требуют специфичных инструментов для их устранения и/или компенсации».

Владимир Ченцов, руководитель департамента комплексного аудита ИБ и безопасной разработки компании «Бастион»:

Владимир Ченцов, руководитель департамента комплексного аудита ИБ и безопасной разработки компании «Бастион» 📷

«Безопасная разработка – это группа процессов ИБ-команд и команд-разработки, которая отвечает за обеспечение и контроль безопасности на каждом этапе жизненного цикла программного продукта. Эти процессы включают: регламентационное регулирование процессов безопасной разработки, архитектурный анализ проекта, обеспечение безопасности инфраструктуры и конечных точек, развитие и сопровождение, тестирование безопасности, анализ рисков и угроз, управление внешними отношениями, безопасное развитие и сопровождение и многие другие.

Каждому этапу присущи свои процессы, обеспечивающие безопасность различных сущностей программного продукта. Они включают в себя регламентацию процесса разработки и организационные процессы: контрольные точки, согласование, утверждение и проверки. Кроме того, это набор технологических решений, которые позволяют реализовывать автоматизированную проверку исходного кода и элементов программного продукта и отслеживать текущее состояния безопасности продукта практически в режиме реального времени».

Антон Башарин, технический директор Swordfish Security:

Антон Башарин, технический директор Swordfish Security 📷

«Суть безопасной разработки сегодня заключается во внедрении проверок ИБ в процессы разработки. Исторически так сложилось, что специалисты по информационной безопасности подключались на финальной стадии – приёмо-сдаточных испытаний (ПСИ), либо же при согласовании на выпуск релиза или при установке в ПРОМ. Почему сейчас все стало иначе?

Потому, что есть необходимость снизить риски, в том числе ИБ, и находить проблемы как можно раньше, и здесь как раз помогает подход Shift-left. А основной мотиватор – экономия ресурсов, так как исправить ошибку на начальной стадии разработки в разы дешевле, чем на стадии релиза. Например, по мнению специалистов Google, позднее исправление в 16 раз сложнее, чем раннее».

Владимир Арышев, эксперт по комплексным ИБ-проектам STEP LOGIC:

Владимир Арышев, эксперт по комплексным ИБ-проектам STEP LOGIC 📷

«Безопасная разработка (SSDLC) – это процесс создания программного обеспечения с учетом аспектов информационной безопасности с самого начала жизненного цикла разработки до завершения эксплуатации. Этот подход интегрирует методы, практики и инструменты для обеспечения защиты от угроз, выявления и устранения уязвимостей, что позволяет предотвратить атаки и сохранить конфиденциальность, целостность и доступность данных.
Использование методологии безопасной разработки позволяет:

• Выявлять и устранять уязвимости на ранних этапах, что экономит время и ресурсы. По некоторым данным, стоимости устранения уязвимости на этапе разработки и после выхода ПО в продуктив могут различаться в 1000 раз.
• Снизить риски безопасности. Проактивное внедрение мер безопасности на этапах проектирования и разработки снижает вероятность возникновения уязвимостей, что способствует обеспечению стабильности и надежности программного обеспечения.
• Соблюдать нормативные требования. В настоящий момент требования к безопасности разработки предъявляют Центральный банк России, ФСТЭК и ФСБ России (в части разработки средств криптографической защиты информации).
• Защитить репутацию компании. Успешные атаки могут не только серьезно навредить репутации компании, но и привести к финансовым потерям.
• Обеспечить доверие пользователей и клиентов. Пользователи стали чаще обращать внимание на безопасность при выборе программного обеспечения. В начале 2021 года более 17000 клиентов компании SolarWinds подверглись заражению вредоносом через разрабатываемое SolarWinds ПО Orion. После данного случая пользователи во всем мире начали относиться к ПО этого разработчика настороженно.

Все эти факторы подчеркивают важность безопасной разработки. Она не только является одним из ключевых элементов информационной безопасности, но и средством достижения конкурентных преимуществ и укрепления доверия пользователей».

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет»:

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет» 📷

«Безопасная разработка — это в целом любая разработка ПО. В широком смысле — это набор практик, связанных с разработкой ПО, которые позволяют создавать более защищенные продукты.

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

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED:

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED 📷

«Современные реалии таковы, что сейчас идет большой запрос на практическую безопасность. Компаниям уже явно недостаточно ограничиться стандартным аудитом информационной безопасности и использовать наложенные средства защиты при создании своих программных продуктов. Важно выпускать на рынок действительно безопасные приложения, чтобы уязвимости было сложнее найти и проэксплуатировать. Есть в сфере безопасной разработки подход Shift Left, на практике подтвердивший, что обнаружение и устранение уязвимостей на этапе разработки экономически гораздо целесообразнее, чем в процессе использования ПО. Также этот тренд подкрепляется тем, что безопасность является важной составной частью такой характеристики как качества продукта, а сейчас лучшие мировые практики разработки нацелены на то, чтобы выпускать максимально качественное ПО и сервисы. Поэтому вопросы безопасной разработки становятся очень актуальной темой. Ведь бизнесу не важно, по какой причине сервис недоступен пользователю, будь то хакерская атака или уязвимость в приложении, – это в любом случае недополученная выручка для компании».

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар»:

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар» 📷

«Безопасная разработка — это подход к созданию программного обеспечения, включающий в себя реализацию мер безопасности на всех этапах жизненного цикла разработки ПО. Цель безопасной разработки – обеспечение надежности, защищенности и устойчивости ПО к различным видам кибератак.

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

Андрей Бирюков, СТО ГК InfoWatch:

«Безопасная разработка – это набор мер, которые снижают вероятность возникновения уязвимостей в продукте. Разумеется, они не делают его абсолютно безопасным и не гарантируют полное отсутствие уязвимостей, но позволяют существенно снизить вероятность возникновения проблем. И одновременно с решением задач по безопасности эти меры напрямую влияют на качество продукта, не обязательно из области ИБ. Например, безопасная разработка предполагает использование статического анализатора – он помогает на ранних этапах обнаружить баги. Не обязательно эти баги потом приведут к возникновению уязвимости в коде решения, но при этом они могут влиять на качество и создавать проблемы у заказчика во время использования любого ПО. Например, если продукт падает в процессе работы, то это создает негативный клиентский опыт у пользователя любого продукта».

Дмитрий Дудко, заместитель генерального директора компании Spacebit: «Это такая разработка ИТ решений, когда исключено или минимизировано появление уязвимостей информационной безопасности».

Приведите примеры безопасной и небезопасной разработки

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар»: «Безопасная разработка представляет собой процесс, в рамках которого активно применяется методология DevSecOps, полностью автоматизировано и регламентировано внедряются меры безопасности, а также используются зрелые инструменты анализа. Благодаря этому процессу потенциальные уязвимости и НДВ находятся, обнаруживаются и оперативно исправляются на всех этапах жизненного цикла разрабатываемого ПО. Как результат, значительно снижаются риски нарушения целостности, доступности и конфиденциальности информации.

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

По словам Сергея Деева, старшего менеджера продукта МТС RED ASOC компании МТС RED», разработка считается безопасной, если в компании определили набор мер контроля защищенности приложений и точно реализовали эти меры на разных этапах разработки. В частности, если изначально была выбрана безопасная архитектура (стек технологий) приложений, выполнен статический анализ исходного кода, проверка сторонних компонентов, а также проверка законченного приложения динамическим методом на тестовой среде. После этого были проработаны проблемы, выявленные на каждом из этапов, все критичные уязвимости устранены – и на рынок выпущен более защищенный продукт.

«Небезопасным можно назвать процесс, когда разработчик, игнорируя все лучшие практики и общедоступную информацию о распространенных уязвимостях, наскоро создал продукт на основе уязвимых сторонних компонентов, на небезопасном стеке технологий и выпустил на рынок без элементарной проверки на защищенность. Если речь идет о веб-сервисе, приложение будет очень быстро скомпрометировано, а бизнес, который стремился оперативно выпустить новый сервис в продакшн и получать прибыль, вместо этого понесет репутационные потери и будет вынужден простаивать до момента решения проблем».

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет», отметил, что небезопасная разработка — это неуправляемый хаос: нет четко прописанных ролей, участники процесса не знакомы с информационной безопасностью, разграничение доступа отсутствует, какие-либо инструменты ИБ не используются.

«Безопасная разработка — полная противоположность. Все участники процесса знают свои роли, доступ настроен исходя из принципа минимальных привилегий, инструменты разработки и инструменты ИБ корректно настроены и дополняют друг друга».

Владимир Арышев, эксперт по комплексным ИБ-проектам STEP LOGIC: «Примеры безопасной разработки:

• Принцип минимальных привилегий. Реализуя данный принцип, приложение предоставляет пользователям минимально необходимый уровень прав и доступа, которые необходимы для выполнения его функций. Например, если приложению для работы не нужны административные права, то оно и не запрашивает их у пользователей.
• Использование надежных алгоритмов шифрования. Для защиты данных во время хранения и передачи информации должны использоваться криптостойкие алгоритмы.
• Проверка входных данных. Приложение должно тщательно проверять входящую информацию, чтобы исключить атаки таких классов, как, например, SQL-инъекции или межсайтовый скриптинг.
• Использование механизмов аутентификации и авторизации для контроля доступа к системе. Доступ к приложению должны иметь только аутентифицированные пользователи и выполнять только разрешенные им действия согласно их уровню доступа.

Примеры небезопасной разработки:

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

Антон Башарин, технический директор Swordfish Security: «Пример безопасной разработки: контроль компонент с открытым кодом на этапе загрузки/сборки (OSA) и последующий анализ собранных дистрибутивов (SCA). В этом случае существенно снижается риск атаки на цепочку поставок (supply chain attack), которая очень популярна сейчас в мире ИБ.

Небезопасная разработка: привлечение специалистов ИБ (пентестеров) для анализа защищенности ПО перед выпуском больших релизов (раз в квартал или год)».

Александр Дроздов, инженер по РБПО и информационной безопасности Axiom JDK:

Александр Дроздов, инженер по РБПО и информационной безопасности Axiom JDK 📷

«Безопасная разработка — это процесс, который подразумевает выполнение испытаний безопасности при разработке и сопровождении программного обеспечения. Испытания безопасности при этом становятся частью жизненного цикла ПО. Реализация промышленного процесса разработки безопасного программного обеспечения (РБПО) позволяет поддерживать безопасность систем на основе этого ПО как на этапе построения, так и на протяжении всего срока эксплуатации.

При безопасной разработке перед выпуском программного изделия определяются его поверхность атаки и функции безопасности. Затем для этих функций безопасности создаются тесты, подтверждающие состоятельность и корректность работы функций безопасности. Для кода, лежащего на поверхности атаки выполняются испытания, направленные на поиск уязвимостей и недекларированных возможностей, а для функций безопасности прогоняются тесты.

При небезопасной разработке защищенность ПО проверяется недостаточно или игнорируется. А всё внимание сфокусировано на ускорении процесса разработки и выпуска продукта. Отсутствие безопасной разработки также может быть следствием недостаточно хорошего планирования на ранних стадиях жизненного цикла программного обеспечения».

Дмитрий Дудко, заместитель генерального директора компании Spacebit, заявил, что самый наглядный пример небезопасной разработки – Интернет. Современный интернет построен на технологиях тридцатилетней давности, когда в первую очередь думали о функциональности, а не о безопасности. Сегодняшний его стек (стек протоколов TCP/IP) очень уязвим к перехвату данных, и множеству других атак.

Владимир Ченцов, руководитель департамента комплексного аудита ИБ и безопасной разработки компании «Бастион»: «Пример безопасной разработки:

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

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

Разработчики исправили все выявленные дефекты. Программный продукт был собран, после чего проверен различными способами динамического анализа, выявленные в результате ошибки также были исправлены. Итоговый компонент был размещен на инфраструктуре, удовлетворяющей требованиям безопасности и проверенной на предмет наличия дефектов и уязвимостей. Согласованный с точки зрения безопасности программный продукт был опубликован.

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

Пример небезопасной разработки:

1. Сформировалась идея программного продукта.
2. Разработчик нашел в интернете часть кода, которая может быть использована, как база для разрабатываемого продукта.
3. Адаптировал и дополнил ее.
4. Произвел сборку и опубликовал данный программный продукт».

В чем разница между DevSecOps, Cloud Native Security и Continuous Security?

Антон Башарин, технический директор Swordfish Security: «По большому счёту, все три подхода специфицируют встраивание проверок ИБ в процесс разработки ПО. При этом Continuous Security фокусируется только на встраивании проверок в CI/CD процессы. CNS смотрит на это процесс шире, но только в рамках контейнеризации. DSO в данном случае объединяет и расширяет CS и CNS в общем смысле, так как проверки ИБ нужны не только в рамках CI/CD, но и за его пределами – практики OSA и Container Security успешно применяются вне CI/CD.

И, конечно, только фокусом на контейнерах (и образах) нельзя покрыть все пакеты поставки современных систем – есть CLI модули, различные API адаптеры и т.п., которые не поставляются в виде docker образов, а значит к ним тяжело применить подход CSN».

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет»: «DevSecOps — это DevOps-методология с акцентом на информационную безопасность. Cloud Native Security — это набор методик по защите информации, которые лучше всего применимы к облакам и в целом разрабатывались именно под облака, поэтому они «native».

Continuous Security — это подход, который можно назвать «непрерывной» безопасностью, по аналогии с непрерывной разработкой и непрерывной доставкой. Технически он воплощается в интеграции инструментов ИБ в CI/CD-систему и построении процессов ИБ вокруг конвейера разработки».

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED: «Это совершенно разные понятия, каждое из них относится к определенной специализации внутри практик безопасной разработки. DevSecOps – это прежде всего автоматизация процессов безопасной разработки с минимальным влиянием на срок выпуска продукта на рынок. Это достигается за счет большей автоматизации покрытия разработки различными видами тестирования и минимизации участия непосредственно экспертов Application Security или разработчиков в разборе полученных результатов. А также за счет гибкости применения тех или иных проверок в зависимости от критичности проверяемого приложения.

Cloud Native Security – это набор понятий, требований и мер информационной безопасности, который имеет конечной целью обеспечение безопасности приложений, развернутых в облаке. Дело в том, что безопасность облачных приложений имеет определенную специфику, связанную с тем, что, как правило, к облаку предоставлен удаленный доступ через недоверенную интернет-среду. Также у облачных приложений имеется своя архитектурная специфика. Поэтому здесь важна не только безопасность самого приложения, но и среды его развертывания и исполнения, сценариев использования всего комплекса данных технологий.

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

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар»: «DevSecOps — сокращение от слов Development, Security и Operations, то есть разработка, безопасность и эксплуатация, что представляет собой практику разработки приложений, которая автоматизирует способы обеспечения безопасности и защиты на каждом этапе жизненного цикла разработки ПО: от проектирования до доставки и развертывания.

Cloud Native Security — это практика защиты приложений и инфраструктуры, созданных и развернутых с использованием облачных технологий, таких как контейнеры, микросервисы, бессерверные функции и платформы оркестрации. Подход направлен на защиту всего жизненного цикла облачных приложений, включая этапы разработки, развертывания и эксплуатации.

Continuous Security — это продолжение практики DevOps, которое интегрирует безопасность в конвейер CI/CD. Он тесно связан с концепцией DevSecOps и Shift Left Security. Смысл подхода в том, что команды разработчиков несут ответственность за безопасность кода, поэтому проблемы обнаруживаются и устраняются раньше, уже в процессе разработки. Таким образом Continuous Security ускоряет разработку, автоматизируя требования к безопасности, что в конечном итоге приводит к более качественному и безопасному продукту».

Дмитрий Дудко, заместитель генерального директора компании Spacebit: «Continuous Security (непрерывная безопасность) — это подход к обеспечению безопасности, который направлен на интеграцию методик безопасности в DevOps процессы (development, IT operations, application security).

DevSecOps – это естественное продолжение DevOps, добавляющий процессы безопасности (development, IT operations, application security, security). Т.е. фактически DevSecOps – это развитие DevOps+Continuous Security.

Cloud Native Security – это концепция подхода к защите облачных данных, приложений и инфраструктуры. Если говорить грубо — это практики DevSecOps, привязанные к облакам с соответствующей спецификой».

Денис Фокин, руководитель отдела технического консалтинга и инженерной поддержки направления ИБ компании Axoft, подчеркнул, что DevSecOps – это подход, в котором обеспечение безопасности является частью процесса разработки, но без привязки к технологиям.

«Cloud Native Security – это решения (не обязательно продукты), которые обеспечивают безопасность, учитывая специфику облачных сред и работу облачной инфраструктуры. Continuous Security – это, по сути, то же, что и процесс безопасной разработки – DevSecOps».

Владимир Ченцов, руководитель департамента комплексного аудита ИБ и безопасной разработки компании «Бастион»: «DevSecOps интегрирует практики безопасности в процессы разработки и поставки ПО (DevOps). Основной акцент сделан на автоматизации безопасности, внедрении инструментов для раннего обнаружения уязвимостей и их исправления, а также на изменении проектной культуры в отношении информационной безопасности.

Cloud Native Security относится к безопасности приложений и инфраструктуры, разработанных специально для облачных сред. Это включает в себя микросервисные архитектуры, контейнеризацию и оркестрацию. Подход ориентирован на обеспечение безопасности в средах, где приложения разворачиваются в облаке, используя масштабируемую инфраструктуру.

Continuous Security означает интеграцию безопасности в цикл непрерывной поставки ПО (CI/CD). Это включает в себя автоматизированные процессы обнаружения, анализа и реагирования на уязвимости в реальном времени. Основное внимание уделяется непрерывному мониторингу и управлению угрозами на протяжении всего жизненного цикла приложения, начиная с момента его разработки и заканчивая эксплуатацией в production-среде».

Какие требования к безопасности разработки предъявляют регуляторы?

Александр Дроздов, инженер по РБПО и информационной безопасности Axiom JDK: «Основной предпосылкой внедрения практик разработки безопасного ПО традиционно являются требования регуляторов. В России ситуация не отличается от мира в целом. ФСТЭК России фокусируется на технологической безопасности, применении лучших мировых практик и совершенствовании их в соответствии с актуальными угрозами и вызовами времени. Регуляторы определяют разные виды программного обеспечения, разные уровни доверия (можно сказать, что уровень доверия определяет уровень защищенности), разные меры защиты и разные требования к проведению испытаний по поиску уязвимостей и недекларированных возможностей, соответствующие каждому уровню доверия.

Например, для сертификации СЗИ по требованиям ФСТЭК в среду разработки и исполнения Java Axiom JDK Certified были определены следующие дополнительные функции безопасности:

• Обеспечение независимости экземпляров виртуальных машин.
• Верификация class-файлов.
• Безопасное выполнение интерпретируемого кода.
• Управление доступом.
• Контроль целостности исполняемого кода (замкнутая программная среда).
• Регистрация событий безопасности.
• Очистка памяти.

Для этих функций безопасности были созданы тесты. Прогоны тестов и испытаний безопасности проводятся в соответствии с требованиями».

Антон Башарин, технический директор Swordfish Security, указал на то, что эти требования сейчас только формируются и пока они носят разрозненный характер, так как ГОСТ по безопасной разработке ещё на стадии переработки и переосмысления.

«На практике пока мы видим, что регуляторы настаивают на отсутствии критических уязвимостей в выпускаемом, либо эксплуатируемом ПО».

Владимир Арышев, эксперт по комплексным ИБ-проектам STEP LOGIC: «В настоящий момент требования к безопасности разработки предъявляют Центральный банк России, ФСТЭК и ФСБ России (ФСБ в части разработки средств криптографической защиты информации).

Нормативные документы Центрального Банка обязывают финансовые организации проводить анализ уязвимостей прикладного ПО, которое используется в платежных и иных финансовых операциях, по требованиям к оценочному уровня доверия не ниже ОУД 4.

Основу нормативных требований к безопасной разработке ПО составляют государственный стандарты.

В 2016 году ФСТЭК России был разработан и введен государственный стандарт ГОСТ Р 56939-2016, устанавливающий общие требования к содержанию и порядку выполнения работ, связанных с созданием безопасного (защищенного) ПО и формированием (поддержанием) среды обеспечения оперативного устранения выявленных ошибок и уязвимостей. Данный стандарт предъявляет требования к процессу разработки на различных этапах жизненного цикла ПО и определяет меры, реализуемые при проектировании архитектуры программы, квалифицированном тестировании разрабатываемого ПО, а также в процессе менеджмента документации и конфигурации софта. В прошлом году «Лабораторией Касперского» была разработана новая версия стандарта, которая актуализирует требования с учетом развития ИТ, в том числе в сфере ИБ.

Кроме этого, с 1 апреля 2024 года в действие вступают два новых стандарта:

• ГОСТ Р 71206-2024 Защита информации. Разработка безопасного программного обеспечения. Безопасный компилятор языков C/C++. Общие требования, целью которого является уменьшение количества уязвимостей, внесенных инструментами компиляции при сборке программы в ее бинарный код;
• ГОСТ Р 71207-2024 Защита информации. Разработка безопасного программного обеспечения. Статистический анализ программного обеспечения. Общие требования, устанавливающий требования к методам, инструментам и специалистам, участвующим в статистическом анализе, так как его проведение является обязательным условием при оценке прикладного программного обеспечения по требованиям уровня доверия ОУД 4».

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет» подметил, что у ФСТЭК России есть ГОСТ по безопасной разработке (ГОСТ Р 56939). Также требования к безопасности разработки предъявляет ЦБ.

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED: «ФСТЭК России разработал ряд ГОСТ в рамках ТК 362 для формализации требований к применению безопасного компилятора, проверки безопасности кода статическим методом. Также при активной поддержке регулятора в ТК362 ведется разработка проекта ГОСТ по анализу сторонних компонентов, а также новой редакции ГОСТ Р 56939 для определения, какой набор мер является достаточным для подтверждения того, что рассматриваемое ПО разработано с применением процессов безопасной разработки и, действительно, является защищенным.

Сейчас активно обсуждается утверждение требований к сертификации процессов безопасной разработки, которые регулятор может представить для разработчиков сертифицированных средств защиты и отечественных операционных систем, которые он может считать доверенными. В качестве источника требований в 2024-м году будет актуален ГОСТ Р 56939-2016, а с 2025-го года – его новая редакция.

Кроме того, уже действуют требования к объектам КИИ, согласно которым эти организации должны проверять на безопасность используемые в своих информационных системах приложения. А именно, что при разработке данных приложений выполнялись требования ГОСТ по безопасной разработке. Такие требования являются обязательными, и владельцы КИИ должны отчитываться об их исполнении регулятору. Соответственно, поставщики приложений для КИИ обязаны предоставить владельцам ОКИИ подтверждение соблюдения требований ГОСТ.

Также Банк России предъявляет требования к кредитным и некредитным финансовым организациям о необходимости регулярной проверки приложений при их эксплуатации на соответствие ОУД4 или наличие сертификата ФСТЭК России. Причем эти требования распространяются не только на средства защиты информации, а на любое ПО для банковских информационных систем, в которых обрабатываются клиентские данные и производится взаимодействие с пользователями (Положения Банка России 719-П, 683-П, 757-П)».

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар» заявил, что вопрос о стандартах безопасности может быть рассмотрен с разных сторон, учитывая разнообразие требований, предъявляемых различными регуляторами. Например, банки имеют собственные требования, которые предъявляет Банк России, для ОКИИ есть иные стандарты, прописанные в приказах ФСТЭК России, у других категорий заказчиков тоже свои особенности.

«Однако, несмотря на это многообразие предъявляемых требований, существует общепризнанный стандарт безопасной разработки — ГОСТ Р 56939. Сейчас готовится его новая версия. Документ опубликован на сайте ФСТЭК России».

Дмитрий Дудко, заместитель генерального директора компании Spacebit, отметил, что на данный момент регуляторы предъявляют такие требования лишь к разработчикам средств защиты информации (СЗИ) и программному обеспечению для КИИ.

Что представляют собой подходы Shift Left и Shift Everywhere в контексте безопасности?

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар», рассказал, что концепция Shift Left подразумевает проведение анализа на самых ранних этапах жизненного цикла разработки ПО, чтобы иметь больше времени на исправление уязвимости и недочетов в безопасности. Этот подход также помогает избегать перехода уязвимостей и недостатков в безопасности на последующие этапы жизненного цикла программного обеспечения.

«Подход Shift Everywhere (или Shift Smart) включает в себя интеграцию тестирования на всех этапах процесса разработки, что помогает создать целостную связь между предложениями, экспериментами и эксплуатацией. Это концепция, при которой проверки проводятся каждый раз при внесении изменений в артефакты (код, инфраструктуру и т.д.), независимо от этапа жизненного цикла ПО».

Андрей Бирюков, СТО ГК InfoWatch: «По сути, Shift Left и Shift Everywhere – это синонимы. Есть жизненный цикл продукта в виде графика, и чем позже мы найдем баг, тем больше он сдвигается на графике вправо – то есть в сторону момента, когда продукт уже ушел к заказчику и он начал им пользоваться. Подход Shift Left подразумевает стремление команды сдвинуть решение любой проблемы максимально влево, к старту разработки – потому что чем раньше мы ее решим, тем дешевле нам это обойдется. Если проблема нашлась уже на этапе использования продукта у клиента, решение проблемы будет очень дорогим – это отзыв релиза, устранение проблемы, накатка исправленной версии и так далее. В случае с ПО для защиты информации это особенно критично: обнаруживать вероятные уязвимости важно на этапе создания архитектуры, а не в тот момент, когда клиента взломали.

Понятие Shift Everywhere более широкое и появилось несколько позже. Подход Shift Everywhere предлагает решать вообще любые вопросы с продуктом как можно раньше и ближе к моменту старта разработки: и безопасность, и UX, и все остальное. «Давайте делать сразу хорошо и не делать плохо» — сложно с таким тезисом не согласиться».

Денис Фокин, руководитель отдела технического консалтинга и инженерной поддержки направления ИБ компании Axoft, заметил, что подход Shift Left постулирует, что чем раньше (с точки зрения разработки) будет выявлена и устранена угроза ИБ, тем меньше это потребует затрат (финансовых или временных).

«Часто данное утверждение трактуют так, что защита на ранних этапах является достаточным условием обеспечения безопасности разработки приложений. Подход Shift Everywhere, по сути, уточняет, что защищенным должен быть весь процесс с учетом используемых технологий».

Владимир Ченцов, руководитель департамента комплексного аудита ИБ и безопасной разработки компании «Бастион»: «Shift Left представляет собой стратегию, при которой акцент в обеспечении безопасности переносится на более ранние этапы разработки ПО. Вместо того, чтобы рассматривать безопасность как отдельный этап, который происходит после завершения разработки, Shift Left подразумевает внедрение безопасности с самого начала процесса разработки.

Shift Everywhere расширяет концепцию Shift Left, предлагая интеграцию безопасности не только в разработку, но и в другие области жизненного цикла приложения, включая тестирование, развертывание и эксплуатацию.

В целом, как Shift Left, так и Shift Everywhere направлены на повышение эффективности и проактивности в обеспечении безопасности, уменьшение рисков и обеспечение безопасности ПО на всех этапах его жизненного цикла».

Александр Дроздов, инженер по РБПО и информационной безопасности Axiom JDK: «Shift Left – это подход, при котором проверки безопасности внедряются так рано и так часто, как это возможно.

Подход «Shift Everywhere» фокусируется на Shift Left, мониторинге «вправо» по жизненному циклу, информировании руководства о рисках – «вверх» и согласовании с разработчиками – исполнителями — «вниз» метрик. Все это делается для минимизации рисков».

Антон Башарин, технический директор Swordfish Security, уверен, что суть этих подходов можно перефразировать в Fail Fast – если есть проблема, то надо её найти как можно раньше. Отсюда и пошла тенденция смещения или внедрения проверок и тестов как можно раньше, Shift Left – левее по оси времени.

«Shift Everywhere как раз является более обширным подходом, который говорит не просто о смещении влево, а о том, что проверки ИБ надо проводить на каждом этапе. И это оправдано, так как за время разработки может пройти информация об уязвимости в используемом компоненте с открытым кодом. Критерии проверки могут быть выстроены каскадом, чтобы на начальных стадиях использовать слабые критерии (и тем самым упростить разработку и доработку основного функционала). А далее можно и нужно усиливать требования, «закручивая гайки», так сказать».

Владимир Арышев, эксперт по комплексным ИБ-проектам STEP LOGIC: «Подходы Shift Left и Shift Everywhere в контексте безопасной разработки представляют собой стратегии, направленные на повышение уровня безопасности в процессе разработки и эксплуатации информационных систем.

При использовании Shift Left фокус на обеспечение ИБ делается на ранних этапах жизненного цикла разработки, начиная с проектирования и создания кода. Основная идея состоит в том, чтобы интегрировать меры безопасности на самых ранних этапах разработки, когда изменения могут быть внесены с меньшими затратами и усилиями. Shift Left включает в себя:

• обучение разработчиков в области создания безопасного кода и предоставление инструментов для анализа кода на наличие уязвимостей;
• автоматизацию тестирования безопасности и внедрение практик DevSecOps для непрерывной интеграции безопасности в цикл разработки;
• применение методов безопасной архитектуры и проектирования, к примеру, принципов защиты данных и аутентификации.

Подход Shift Everywhere подразумевает защиту и контроль доступа к данным и приложениям вне зависимости от того, где они развернуты: в облаке, на периметре сети или мобильных устройствах. Он включает в себя:

• использование концепции нулевого доверия (Zero Trust) для аутентификации и авторизации пользователей и устройств в любой среде;
• реализацию микросервисной архитектуры и контейнеризации для обеспечения изоляции и безопасности каждого компонента приложения;
• обнаружение и реагирование на инциденты в реальном времени в различных средах, включая облачные, локальные и гибридные инфраструктуры;
• использование автоматизации и оркестрации для централизованного управления безопасностью в различных средах.

Оба подхода направлены на предотвращение угроз и уязвимостей, улучшение видимости и реагирования на инциденты, а также на создание защищенной среды, где безопасность встроена в каждый этап процесса разработки и эксплуатации».

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет»: «Shift Left — это подход к смещению безопасности в левую сторону процесса разработки, т. е. в самое его начало. Цена устранения дефекта в программном продукте значительно растет при движении от самого старта разработки к релизу продукта. Это справедливо и для дефектов ИБ, поэтому чем раньше они будут устранены, тем выгоднее будет разработка.

Shift Everywhere — это развитие подхода Shift Left, которое выражается в том, что ИБ должна присутствовать во всём, везде и сразу. Ошибочно фокусироваться только на левой части производственного цикла, ведь справа тоже полно работы — безопасная доставка ПО, его деплой, безопасность инфраструктуры, Patch Management и т. п. Безопасность должна быть целостной».

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED: «Все начиналось с осознания необходимости проверять приложения на наличие уязвимостей заранее, до того, как они попадают в эксплуатацию. Эта целесообразность и породила подход Shift Left, когда безопасность реализуется на самых ранних этапах жизненного цикла ПО. Такой подход является обоснованием экономических инвестиций в безопасную разработку.

Однако практики и техники злоумышленников постоянно совершенствуются, появляется информация о новых уязвимостях не только в конкретных приложениях, но и в среде эксплуатации ПО, в различных сторонних компонентах.

Поэтому мировым трендом сейчас является переход от подхода Shift Left к подходам Shift Everywhere, когда ведется непрерывный мониторинг, обнаружение и устранение уязвимостей на всех этапах жизненного цикла приложения (включая Continuous Security), от этапов разработки и до стадии исполнения. Этот подход включает в себя и область Cloud Native Security за счет обеспечения облачной и серверной безопасности. Оба подхода важны – каждый из них зародился на определенной стадии развития мировых практик безопасной разработки».

Как должен выглядеть идеальный процесс DevSecOps и какие инструменты для этого нужны?

Андрей Бирюков, СТО ГК InfoWatch: «DevSecOps – это набор инструментальных средств, направленных на реализацию практик безопасной разработки. В него входит много инструментов, которые имеют отношение не только к безопасности решения как таковой. Например, должен быть конвейер сборки Continuous Integration, всевозможные автотесты и анализаторы, встроенные в этот конвейер, статические и динамические анализаторы, фаззинг-тестирование и так далее.

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

Владимир Ченцов, руководитель департамента комплексного аудита ИБ и безопасной разработки компании «Бастион»: «Идеальный процесс DevSecOps должен включать в себя процессы анализа безопасности на всех этапах жизненного цикла разработки: от идеи, когда только формируется понимание, что из себя будет представляют программный продукт, до обеспечения безопасности и мониторинга уже реализованного проекта.

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

Один из наиболее важных процессов с точки зрения проактивного подхода к обеспечению безопасности при разработке – обучение. Обучение также значительно упрощает внедрение и реализацию концепции DevSecOps. Кроме того, оно позволяет улучшить процесс коммуникации команд разработки и обеспечения безопасности из-за того, что обе команды лучше понимают значимость и важность процессов безопасности при разработке.

Одна из основных целей концепции DevSecOps – недопущение возможности передачи уязвимого и непроверенного артефакта разработки в продуктивную среду. Идеальный процесс подразумевает полную реализацию действий, направленных на недопущение данной вероятности. Наличие точек контроля и отсутствие альтернативных каналов передачи кода и других артефактов влияет на следующие этапы жизненного цикла безопасной разработки.

С точки зрения технологических инструментов, реализующих безопасности в данном процессе — это следующие классы решений: SAST, DAST, OSA/SCA, Vulnerability Management, Container Security, CNAPP, MAST».

Александр Дроздов, инженер по РБПО и информационной безопасности Axiom JDK, уверен, что практики безопасной разработки — неотъемлемая часть инженерной культуры в мировых ИТ-гигантах, поскольку они занимаются промышленным производством ПО. Этот опыт переняли разработчики российской среды исполнения Java Axiom JDK. Инженеры имеют более 25 лет опыта работы на улучшением Java, в том числе в центрах разработки Oracle и Sun. И сегодня команда входит в число лидеров РБПО в России.

«На технологиях Java работает подавляющее большинство критически важных государственных, банковских и промышленных систем. И ключевая идея российского дистрибутива Java заключается в создании надежного продукта в концепции Security by Design с высоким уровнем доверия потребителя, вниманием к к процессам тестирования и качеству при каждом обновлении. Внедрение РБПО помогает достичь этой цели и сократить расходы на процессы, необходимые для поддержания качества продукта.

Чтобы правильно организовать процессы безопасной разработки, рекомендуем 6 шагов:

1. Убедить руководство: заручиться поддержкой и бюджетом.
2. Получить и проработать требования к продукту для сертификации.
3. Сформировать команду для поддержания промышленного РБПО-процесса.
4. Выбрать актуальные инструменты.
5. Выстроить процесс по реализации требований.
6. Обмениваться опытом в сообществе РБПО для постоянного совершенствования».

Антон Башарин, технический директор Swordfish Security, подметил, что идеальный процесс должен включать как инструментальные проверки (SAST, SCA, OSA, DAST, MAST, CS), так и отслеживание процессных изменений (контроль критериев качества, внедрение проверок на всех этапах разработки). Ну и контроль используемого ПО в ПРОМ среде (WAF, CS, SOC и т.д.), безусловно. И главное, весь процесс должен максимально автоматизирован. Идеально – если до ПРОМ изменения будут долетать без участия человека (ИБ инженера, Security Champion)».

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED: «Процесс DevSecOps делится на две составляющие.

Первая – это обеспечение процесса выпуска безопасного приложения с применением ряда инструментальных контролей на разных этапах разработки ПО. К таким обязательным контролям можно отнести статический анализ кода (применение решений класса SAST), динамический анализ ПО (применение DAST) и композиционный анализ (применение SCA/OSA). Также важным является анализ архитектуры безопасности ПО. Об этой составляющей я уже рассказал выше, когда приводил пример безопасной разработки.

Вторая важная составляющая – это обеспечение безопасности самой среды разработки и работы команд разработки, аналитиков и всех вовлеченных в этот процесс экспертов. Обеспечение безопасной среды разработки необходимо, чтобы в ней вместе с разрабатываемым легитимным кодом не появился вредоносный, потом не мог попасть вместе с обновлением ПО заказчику. А также чтобы не допустить утечек исходных кодов приложений и другой конфиденциальной информации или нарушения работоспособности сборочной инфраструктуры приложения, что может существенно повлиять на сроки выпуска ПО».

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар»: «Обычно стандартный процесс разработки приложения состоит из пяти этапов: 1) формирование требований к системе и проектирование, 2) разработка, 3) тестирование, 4) внедрение и 5) эксплуатация и сопровождение. При этом на каждом из этапов можно внедрить инструменты безопасности.

Чаще всего в качестве основных инструментов для контроля безопасности приложений внедряют SAST, DAST и SCA. Мы рекомендуем начинать с интеграции SAST и SCA – это те инструменты, которые нужны в первую очередь. В нашем решении Solar appScreener доступны все эти виды анализа кода из одного интерфейса, а также SCS — анализ безопасности цепочек поставок.

Лучший подход – это комбинирование нескольких видов анализа кода, чтобы охватить все этапы разработки ПО, вовремя выявить уязвимости на каждом из них и не пропустить уязвимости и ошибки в коде дальше.

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

Еще один важный нюанс – это налаженное взаимодействие команд при построении процессов безопасной разработки. Обычно это как минимум разработчики и команда офицеров безопасности, а иногда могут добавляться и другие департаменты, например, отдел системных аналитиков и DevOps. Очень важна слаженная работа и активное взаимодействие всех команд».

С чего начать процесс внедрения DevSecOps?

Владимир Арышев, эксперт по комплексным ИБ-проектам STEP LOGIC: «По опыту работы с заказчиками, наиболее важно при внедрении DevSecOps выстроить диалог безопасников с разработчиками. Первые должны четко представлять нюансы реализации технологий DevOps в компании, а вторые – понимать, что происходит и зачем пытаются влиять на их код.

После достижения понимания между подразделениями необходимо провести аудит процесса разработки и определить подходящие инструменты DevSecOps и места для их установки. К примеру, сотрудники отдела безопасности директивно решают проверять разрабатываемый код на наличие уязвимостей. Анализ кода выполняется перед переводом ПО в продуктив. После каждой проверки на разработчиков «высыпается» огромный список уязвимостей, без устранения которых запуск приложения не согласовывается. Таким образом, из раза в раз список на доработку разрастается, а выход в продуктив откладывается.

Разработкой ПО часто занимается не одна, а несколько команд, каждая со своим уровнем развития, навыками и менталитетом. В начале внедрения технологий DevSecOps лучше выбирать команду с более высоким уровнем зрелости, которая готова совместно работать над повышением безопасности кода. Но, даже имея дело с опытной командой, не нужно внедрять сразу все возможные инструменты. Стоит начать с наиболее понятного разработчикам решения, например, класса SCA, предназначенного для проверки применяемых в разработке библиотек. В дальнейшем успешный опыт внедрения можно распространить на другие команды».

По мнению Антона Башарина, технического директора Swordfish Security, лучше всего, конечно, начать с аудита текущих процессов в команде или компании. И уже на его основе определять самые проблемные места в применяемых процессах. По сути, нужно выделить те 20% изменений, которые дадут 80% успеха. Чаще всего начинают с контроля зависимостей, так как это одна из наиболее эффективных практик сегодня. Либо же берутся за анализ кода (SAST), поскольку он достаточно понятен и известен.

Александр Дроздов, инженер по РБПО и информационной безопасности Axiom JDK: «Внедрение промышленного процесса РБПО начинается с определения бюджета и убеждения руководства в его необходимости. Хотя идеально, когда инициатива исходит от руководства, часто это не так. Одним из аргументов могут быть огромные убытки при обнаружении уязвимостей после выпуска продукта в промышленную эксплуатацию. Например, расходы на исправление бага после релиза могут быть в разы выше, чем на этапе разработки. Эксперты из LLVM Project посчитали, что если стоимость исправления бага на этапе разработки около 25$, то после релиза она может быть порядка 16 000$, то есть 640 раз выше.

При проработке плана действий необходимо учесть особенности РБПО-процесса в парадигме ФСТЭК России:

• Выявление уязвимостей и недекларированных возможностей, статический и динамический анализ составляющих решение компонент, в первую очередь, в отношении поверхности атаки.
• Опора на технологическую и методологическую поддержку ИСП РАН, который является одним из шести отечественных центров анализа искусственного интеллекта, созданных в 2021 году под эгидой правительства РФ. Он сконцентрирован на анализе безопасности технологий искусственного интеллекта. В числе его сотрудников – все пять российских ревьюверов gcc-компилятора.
• Активное взаимодействие с сообществом – привлечение участников сообщества к развитию методик и требований разработки и анализа СЗИ, создание информационных ресурсов для обучения компаний».

Владимир Ченцов, руководитель департамента комплексного аудита ИБ и безопасной разработки компании «Бастион»: «На наш взгляд, для малого и среднего бизнеса процесс внедрения DevSecOps стоит начать с технологических решений по анализу самого исходного кода. Выстраивание процессов — это правильный подход, но его крайне сложно оценить с точки зрения зрелости реализации. Если в компании будет минимальный набор средств для анализа исходного кода, можно будет отслеживать корректность применяемых подходов и решений.

Если говорить простыми словами: появится инструмент для оценки применяемых решений. Проанализировали продукт, нашли дефекты, исправили, измерили время реализации проекта. Применили процесс, снова проанализировали продукт, сравнили показали, определили эффективности применяемого процесса.

Параллельно формируется регламентация для проверки соблюдения всего процесса.

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

Дмитрий Дудко, заместитель генерального директора компании Spacebit, подчеркнул, что внедрить DevSecOps невозможно без тщательной подготовки и планирования. Именно на этапе планирования должен быть заложен базис будущих процессов, определены роли и точки контроля.

«После этого вам потребуется огромная воля, чтобы перестроить уже устоявшиеся подходы к новой концепции».

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар»: «Чтобы начать процесс внедрения DevSecOps, необходимо определить наиболее важные проекты с точки зрения безопасности и определить критерии для выбора таких проектов. Начинать лучше с внедрения инструментов Secret Scanning, SAST и SCA/OSA на заранее определенных критически важных проектах.

Если рассматриваем комплексное внедрение, также следует рассмотреть ASOC (ASPM) решения для автоматизации общего количества инструментов уже с ранних этапов.

Очень важно правильно организовать процесс, потому что DevSecOps — это именно процесс. Нельзя ожидать, что получится по щелчку пальцев начать делать максимально безопасное ПО. Поэтому основное внимание стоит уделить именно процессу и людям. Также важно понимать, на каких этапах запускаются проверки, как исправляются уязвимости, как принимаются решения по смягчению уязвимостей, и кто именно отвечает за эти микропроцессы в рамках общего DevSecOps процесса.

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

Дмитрий Смирнов, начальник отдела информационной безопасности NGENIX:

Дмитрий Смирнов, начальник отдела информационной безопасности NGENIX 📷

«Начать внедрение DevSecOps следует с нескольких шагов:

Шаг №1 — определите, нужен ли вам DevSecOps.

Каждая компания должна сама ответить на этот вопрос, проанализировав потребности безопасности. DevSecOps полезен для тех организаций, у которых уже внедрены практики DevOps и к ним хочется добавить приставку Sec, то есть безопасность сборки, настройки и развертывания ПО. Если же ничего нет, то практики DevOps первоначально нужнее.

Шаг №2 — проведите аудит инфраструктуры и процессов разработки, выявите уязвимости и угрозы.

Хорошо отлаженные практики DevOps помогут четко определить пайплайны, которые используются в компании. Если не получается, вернитесь к шагу №1 🙂

Определите активы, которые нужно защищать, например для Ops пайплайна (управление инфраструктурой) — это могут быть файлы конфигураций (IaC), реестр артефактов или контейнеры, а для Dev пайплайна (создание и развертывание софта) — исходный код, зависимости, образы.

Для каждого актива определяются актуальные угрозы, которые закрываются (минимизируются) тем или иным средством защиты/анализа. Все инструменты уже описаны во многих источниках и «нагуглить» их не проблема: линтеры, анализаторы кода, анализ секретов, композиционный анализ и другие.

Шаг №3 — изучите, какие есть инструменты на рынке и какие актуальны для вас.

Изучите инструменты и технологии, которые помогут интегрировать безопасность в процессы DevOps. Определите, каким путем проводить внедрение: с помощью интеграторов или своими силами, опенсорсные инструменты или проприетарные, нужна ли интеграция с существующими системами. Исходя из этого выберите подходящие для ваших желаний и инфраструктуры инструменты. Можно изучить подборку инструментов для DevSecOps на русском.

Шаг №4 — выберите конкретную практику, с которой проще и понятнее будет начать внедрение.

Разработайте план по внедрению DevSecOps, учитывая выделенные ресурсы, сроки и цели. Внедряйте DevSecOps по частям, начиная с самых простых практик. Мы двигались от простого к сложному:

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

В целом, при внедрении DevSecOps нужно планировать каждый шаг, чтобы не сломать то, что уже работает. Если у вас применяется DevOps-практика CI/CD, важно реализовать автоматизированные инструменты для контроля безопасности кода и других активов в рамках CI/CD пайплайна. И главное — процесс мониторинга и обработки событий, который генерирует эти инструменты. Ручное добавление новой практики в большое количество проектов требует много времени и усилий, поэтому важно продумать эффективный и масштабируемый подход».

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED: «Он всегда начинается с аудита, с понимания того, на каком этапе зрелости находится разработка ПО в компании. Аудит можно провести собственными силами специалистов службы информационной безопасности, чтобы подготовить аналитическую записку для руководства. Либо, при наличии бюджета, можно привлечь стороннюю аудиторскую компанию: ее независимая оценка, возможно, будет иметь больший вес для руководства. После завершения аудита станет понятно состояние дел в разработке, будут подсвечены очевидные риски, которые могут быть реализованы, если меры безопасной разработки не будут приняты.

В любом случае, для запуска процесса внедрения DevSecOps необходимо заручиться поддержкой руководства, и результаты аудита позволят представить необходимые аргументы. Хорошим обоснованием для руководства в пользу необходимости внедрения практик DevSecOps также являются примеры известных успешных атак на веб- сервисы и продукты компаний-конкурентов или организаций из смежной отрасли. Понимание реальной картины в вопросах информационной безопасности первыми лицами – очень важно для стабильной работы отечественных организаций в наше время».

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет»: «Лучше всего начинать этот процесс с обследования или аудита. Прежде чем куда-то двигаться, нужно понять, где вы находитесь. Для этого есть несколько разных стандартов. Могу посоветовать начать, например, с самопроверки по DevSecOps Assessment Framework (DAF). Этот фреймворк написан на русском языке и в целом учитывает реалии российского ИТ.

Когда вы выясните, насколько вы выполняете практики DevSecOps, сможете понять, что развивать в первую очередь».

Как DevSecOps влияет на сложившиеся процессы разработки?

Дмитрий Дудко, заместитель генерального директора компании Spacebit: «По моему стойкому убеждению, DevSecOps необходимо использовать как базис разработки либо же не пытаться внедрять вовсе, поскольку использование и внедрение лишь части процессов неэффективно и трудозатратно. В таком случае придется надстраивать множество «костылей» на входе процесса для поддержания его функционирования, однако и в этом случае результат от реализации будет неполным».

Владимир Ченцов, руководитель департамента комплексного аудита ИБ и безопасной разработки компании «Бастион», убежден, что при правильной реализации DevSecOps уровень влияния на процесс разработки минимальный. Однако наиболее частым негативным последствием на первых этапах внедрения процессов является увеличение BackLog и, как следствие, увеличение общего времени разработки. Но это только на первых этапах, когда процесс внедрен на зрелом уровне – время разработки существенно уменьшается из-за того, что дефекты и недостатки выявляются сразу на этапе разработки и не требуют оперативного устранения, когда программный комплекс уже эксплуатируются.

Антон Башарин, технический директор Swordfish Security, заявил, что всё зависит от стратегии внедрения. Если выбрали агрессивный подход, то разработка может даже остановиться, так как надо будет сначала решить все найденные проблемы ИБ, а потом уже заниматься развитием функциональных возможностей. Плавный подход предполагает постепенное внедрение практик и сканеров, а также поступательное усиление контроля, в зависимости от зрелости команды разработки. Все эти аспекты обычно выявляются во время аудита, и расписываются в стратегии внедрения процесса безопасной разработки (DevSecOps).

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет»: «При встраивании безопасности в сложившиеся процессы разработки всегда случается просадка по срокам. Поначалу задержки будут происходить на всех этапах — от разработки требований до релиза.

Но затем, по прошествии времени, после того как команды ИБ и команды разработки сработаются, начнут говорить на одном языке и поставят процесс безопасной разработки на рельсы, качество разрабатываемого кода значительно вырастет, а расходы на устранение дефектов снизятся».

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED: «DevSecOps – это набор инструментальных и экспертных контролей, которые дополняют основные процессы разработки. Они добавляют в разработку этапы, которые изначально в процессе создания ПО отсутствовали. Их гармоничное встраивание в существующие процессы – коллективная задача, которая стоит перед экспертами, внедряющими DevSecOps, командами разработки и владельцами продуктов, заинтересованных в выпуске новых версий. Внедрение DevSecOps может влиять на уменьшение количества дефектов в коде. Повысится качество кода, как следствие приложения станут более стабильными. Что, в том числе, может сказаться на улучшении пользовательского опыта клиентов.

При этом есть вероятность того, что усложнение процесса разработки ПО за счет внедрения дополнительных инструментальных контролей, особенно в первые недели после выстраивания практик DevSecOps, повысит нагрузку на разработчиков и экспертов ИБ, задействованных при оценке выявленных уязвимостей. Придется обрабатывать большое количество данных об уязвимостях и дефектах, так как нужно будет отсеять большое количество ложноположительных срабатываний, и фокусироваться на критических уязвимостях, применимых в разрабатываемом приложении.

На начальном этапе к этому надо быть готовыми. Однако постепенно ситуация выровняется и перестанет влиять на выпуск новых версий серьезным образом, так как количество выявляемых новых уязвимостей, станет значительно меньше».

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар», указал, что многое зависит от текущих процессов разработки и их зрелости. Если процессы уже регламентированы и автоматизированы, то внедрение DevSecOps в целом становится вопросом технической реализации и организационного взаимодействия. Однако в процессах, где нет автоматизации, например, сборки проектов, это может быть более сложной задачей. При таких сценариях мы рекомендуем создавать процессы и автоматизацию практически с нуля.

«В целом, ответ — скорее положительно. Уменьшаются риски ИБ, настраивается автоматизация и улучшается структура процесса разработки».

Как подготовить инфраструктуру к внедрению DevSecOps?

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар», заявил, что в первую очередь следует сосредоточиться на процессах. Важно четко определить, на каких этапах разработки какие инструменты используются. Далее уже технически оценивать, что нужно для функционирования данных инструментов в вашей инфраструктуре».

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED: «DevSecOps призвана автоматизировать проверки безопасной разработки в компании. Если сама инфраструктура разработки в компании не автоматизирована, отсутствую CI/CD процессы, нет системы контроля версий, ни о каком построении процесса безопасной разработки говорить не приходится.

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

Про автоматизацию процесса разработки безопасного ПО можно говорить только в случае, если сама разработка в компании уже автоматизирована и находится на достаточном уровне зрелости. Нужно начать прежде всего в этого».

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет»: «DevSecOps-инструментам требуется готовый DevOps-ландшафт.

Если он уже выстроен, то остается определиться с набором инструментов, которые будут использоваться для выполнения процессов DSO, затем изучить их требования к инфраструктуре и отыскать свободные вычислительные ресурсы.

Но бывает так, что при внедрении инструментов DevSecOps в инфраструктуре не выстроен DevOps-процесс: не используется Kubernetes (а вместо него применяются хаотично установленные Docker-хосты), нет репозиториев для хранения образов контейнеров, не настроены пайплайны в CI/CD-системе. В такой инфраструктуре будет сложно что-либо внедрить.

Поэтому главное, что нужно сделать — это хотя бы базово выстроить DevOps-процессы в компании. Если такие процессы выстроены, то значит, для них есть инструменты и инфраструктура, которую можно усилить механизмами безопасности».

Антон Башарин, технический директор Swordfish Security, подметил, что тут надо понимать стратегию внедрения, обычно в ней расписывается план (дорожная карта, roadmap) внедрения практик и сканеров. А также оценивается объем необходимых ресурсов – CPU, RAM, HDD.

Владимир Ченцов, руководитель департамента комплексного аудита ИБ и безопасной разработки компании «Бастион»: «Инвентаризация, систематизация, централизация. Определить полный стек применяемых технологий, систематизировать потребности, максимально централизовать процессы по разработке, где это возможно. Эти три процесса значительно облегчат внедрение концепции DevSecOps».

Как и зачем применять концепцию Zero Trust в разработке?

Антон Башарин, технический директор Swordfish Security:«Zero Trust – это новый термин давно известного подхода минимальных привилегий. Только теперь он применяется не к сетевой топологии, или модели разрешений внутри системы, а к приложению или процессу в целом. Zero trust – по сути, никому не доверяй. Так и строится весь процесс безопасной разработки, когда все внешние факторы подвергаются сомнению».

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет»: «Концепция Zero Trust означает отсутствие доверия по умолчанию. У нас заведомо нет доверия к пользователям или программам просто из-за того, что они находятся внутри нашего периметра. Даже внутри все должны пройти аутентификацию, а вся коммуникация, даже внутренняя, должна быть защищена.

Принципы Zero Trust применимы и к разработке. Они могут быть реализованы в следующих направлениях:

1. Принцип минимальных привилегий. Доступ только к минимально необходимому для работы набору ресурсов.
2. Контроль доступа и аутентификация.
3. Микросегментация. Разделение сети на зоны минимального размера и контроль трафика между ними.
4. Мониторинг событий. Обнаружение аномалий.

По всем этим направлениям можно усилить безопасность как окружения разработки, так и DevOps-платформы в целом».

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED: «Длительное время локальные информационные системы в большинстве случаев находились в замкнутом конуре, изолированном от внешнего мира и взаимодействующем с внешней интернет-средой лишь через ограниченное число узлов.

Так в прошлом выглядели корпоративные сети, сегменты АСУ ТП промышленных предприятий и ряд других сетей. Но сейчас в корпоративном периметре активно развиваются мобильные устройства, имеющие прямой доступ в интернет (мобильные рабочие места, особенно получившие распространение в период пандемии), все больше находится применение для IoT-устройств, подключаемых к интернету напрямую.

Как следствие, старые подходы к информационной безопасности, когда считалось, что сама по себе рабочая станция требует лишь реализации частичных мер безопасности, так как полный комплекс мер будет обеспечен за счет применение различных СЗИ на других уровнях (так называемый эшелонированный подход к обеспечению ИБ), теряет свою актуальность в ряде описанных случаев. Для таких ситуаций при обеспечении ИБ важно, чтобы само приложение или устройство были устойчивыми к действиям злоумышленников.

Именно такой подход имеется в виду под применением подхода Zero Trust. По сути, это дополнительный повышенный уровень требований безопасности при разработке и развертыванию ПО, выполнение которых позволит снизить риски использования приложения или устройства в незащищенной среде».

Дмитрий Смирнов, начальник отдела информационной безопасности NGENIX: «Концепция Zero Trust или «нулевое доверие» предполагает, что ни одному пользователю или устройству нельзя доверять, даже если они находятся внутри защищенной сети одной организации. Каждый запрос на доступ к ресурсам должен быть аутентифицирован, авторизован и защищен в соответствии с политиками безопасности.

Внедрение Zero Trust следует начать с определения конкретных этапов процесса разработки, которые уже существуют в компании: например, в рамках SDLC/SSDLC. Это поможет понять, какая информация передается на каждом этапе — от кого, к кому и как.

Далее необходимо провести инвентаризацию: определить потоки информации и выявить возможные уязвимости. Важно иметь параноидальный подход и заранее предполагать, что информация может поступать из недостоверных источников.

Затем нужно определить необходимые проверки и инструменты для реализации принципов Zero Trust. Это может быть оценка информации, источников и потребителей, выявление уязвимых мест во время передачи информации.

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

В «нулевом доверии» стоит следовать следующим принципам:

• Проводите прямую проверку. Необходимо всегда выполнять процедуру аутентификации и авторизации. Каждую попытку доступа следует считать потенциальной угрозой до тех пор, пока не будет доказано обратное, вне зависимости от источника подключения.
• Для обеспечения безопасности используйте минимально необходимые привилегии. Сужайте права пользовательского доступа и служебных учетных записей до минимума.
• Предполагайте наличие уязвимостей в системе безопасности. Уменьшайте возможности доступа к сегменту сети и атак. Применяйте шифрование и аналитику для повышения видимости, обнаружения угроз и усиления защиты.

Такая концепция — дорогое удовольствие, которое требует повышенных затрат на внедрение необходимых механизмов. Однако применение Zero Trust имеет ряд преимуществ:

1. Повышение безопасности и уменьшение поверхности атаки. Zero Trust помогает предотвратить утечки данных, атаки и другие угрозы безопасности.
2. Защита от внутренних угроз. Zero Trust позволяет обнаружить и предотвратить угрозы от доверенных пользователей и устройств, которые могут нанести ущерб системе изнутри.
3. Соблюдение регуляторных требований. Zero Trust помогает организациям соблюдать промышленные стандарты и регуляторные требования по защите пользовательских данных.
4. Улучшение общей безопасности. Zero Trust обеспечивает более гибкую, защищенную систему, что делает уровень защиты сети и данных выше.

Однако концепция Zero Trust — не замена принципов безопасности. Её нужно внедрять на протяжении всего цикла разработки, в этом плане она коррелирует с практиками DevSecOps».

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар»: «Модель Zero Trust предполагает полное отсутствие доверия к пользователям или устройствам, даже если они находятся внутри периметра конкретной организации. Согласно этой концепции, любой пользователь или устройство должны подтверждать свои данные каждый раз, когда они запрашивают доступ к какому-либо ресурсу внутри или за пределами сети.

Поскольку сегодня пользователи могут работать удаленно и получать доступ к приложениям с различных устройств, как внутри, так и вне периметра предприятия, это создает новые вызовы для служб безопасности. Старый подход «доверяй, но проверяй» больше не работает. «Никогда не доверяй, всегда проверяй» — вот основной принцип Zero Trust. Важно отметить, что Zero Trust — это концепция безопасности, а не продукт. Эта модель основана на принципе поддержания строгого контроля доступа и недоверия к кому-либо по умолчанию, даже к тем пользователям, которые уже находятся внутри сетевого периметра. Zero Trust предполагает, что традиционных границ сети не существует; сети могут быть локальными, облачными, комбинированными или гибридными, с ресурсами в любом месте, а также сотрудниками в любом месте».

Дмитрий Дудко, заместитель генерального директора компании Spacebit, заявил, что Zero Trust – модель «нулевого доверия», когда мы не доверяем никому, даже собственным пользователям. Модель подразумевает, что каждый пользователь или устройство должны подтверждать свои данные каждый раз, когда они запрашивают доступ к какому-либо ресурсу внутри или за пределами сети. Данный подход широко используется в классической информационной безопасности.

«В «Спейсбит» мы используем модель Zero Trust для создания жестких моделей разграничения доступа для минимизации утечек и компрометации учетных записей администратора или офицера информационной безопасности».

Андрей Бирюков, СТО ГК InfoWatch: «Главный принципе концепции Zero Trust – мы не можем считать ни один компонент ПО доверенным. Например, если мы включаем в него какую-то стороннюю библиотеку, то априори считаем ее опасной и должны тщательно проверить. В таком подходе есть рациональное зерно, поскольку код пишут люди, которые могут совершить ошибку, причем не обязательно злонамеренно.

С другой стороны, чрезмерно высокий уровень подозрительности также может навредить, слишком замедляя скорость разработки. Поэтому в этом вопросе каждый старается найти золотую середину между безопасностью и эффективностью процессов».

Какие меры безопасности нужны на каждом этапе цикла CI/CD?

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар»: «Вопрос очень широкий, и его ответ зависит от конкретного процесса CI/CD. В целом рекомендуется использовать инструменты SAST, DAST, SCA/OSA, Secret Scanning в рамках CI/CD процесса.

В более зрелых командах, где уже есть выстроенные процессы безопасной разработки, рекомендуем также использовать различные Quality Gates к указанным выше инструментам. Это критерии прохождения этапов проверки, которые позволяют оценить безопасность собираемого артефакта».

Дмитрий Дудко, заместитель генерального директора компании Spacebit: «CI/CD — это одна из DevOps-практик, непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD). В своей основе это принципы внесения небольших изменений в код.

Обеспечение безопасности CI/CD в «Спейсбит» это достигается двумя методами. Первый – непрерывное тестирование, в ходе которого мы с помощью автоматизированных (регрессионное тестирование, тестирование производительности и других) и ручных методов (статический и динамический анализ, фазинг-тестирование) проводим всесторонний анализ кода.

Второе направление – создание безопасной среды разработки с помощью классических методов информационной безопасности».

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED: «Все начинается с выстраивания архитектуры безопасности – с формирования требований к безопасности и используемого технологического трека таким образом, чтобы они не привнесли дополнительных проблем.

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

Второе на, что стоит обратить внимание, – это статический анализ, который важно выполнять на этапе написания кода и который позволяет оперативно выявлять все дефекты. Этот вид анализа рекомендован к применению во всем мире.

Третье, что требует участия – композиционный анализ, проверка сторонних компонентов, которые повсеместно используются при написании кода приложений. Как правило, большинство приложений в мире не пишется с нуля, используются заимствованные библиотеки кода на базе Open Source, фреймворки, компоненты стороннего кода или сервисов. Такой код обязательно надо проверять на уязвимости и НДВ.

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

Сейчас же проверка сторонних компонентов стала базовой мерой, которая рекомендована к реализации повсеместно. Четвертое, что требует внимания – это динамический анализ приложения. Часть уязвимостей, которые сложно или вообще невозможно обнаружить статическим или композиционным методами анализа, можно обнаружить лишь на стадии исполнения ПО, и данный метод позволяет это сделать. В ряде случаев, когда речь идет об особо значимых приложениях, которые, например, используются в ОКИИ или являются средствами защиты информации, необходимо применять fuzzing-тестирование.

Это метод анализа защищенности ПО, при котором приложению передаются на вход некорректные данные. Так выявляются нетипичные примеры поведения приложения, связанные с нарушением его внутренней логики, утечки памяти, способные привести к эксплуатации уязвимостей. Кроме того, важно следить за безопасностью приложения и в процессе его эксплуатации: ежедневно отслеживать уязвимости и оперативно выпускать обновления, не дожидаясь, когда будет осуществлен его взлом, о котором станет известно публично.

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

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет»: «Если кратко, то вот какие:

1. На этапе написания кода — статический анализ, обнаружение секретов.
2. На этапе сборки — анализ Dockerfiles, сканирование сторонних компонентов и поиск уязвимостей.
3. На этапе деплоя — анализ манифестов развертывания.
4. После деплоя — динамическое тестирование, мониторинг процессов, поиск аномалий и классическая инфраструктурная ИБ».

Владимир Арышев, эксперт по комплексным ИБ-проектам STEP LOGIC: «Идеальный процесс DevSecOps должен обеспечивать непрерывную безопасность на каждом этапе жизненного цикла разработки программного обеспечения, начиная с проектирования и заканчивая эксплуатацией.

Основные инструменты безопасности на стадии планирования – это система для управления требованиями информационной безопасности, которая помогает формулировать и управлять требованиями по ИБ к приложениям в зависимости от актуальных угроз, и обучение персонала навыкам безопасного кода без отрыва от рабочего процесса.

На этапе CODE и BUILD мы рекомендуем использовать композиционный анализ ПО (SCA) для проверки проекта на наличие проблемных зависимостей, статический анализ кода (SAST), позволяющий находить уязвимости в исходном коде приложения на ранних этапах жизненного цикла разработки, и поиск секретов (Secret Findings), которые могут быть «вшиты» в код.

На стадии TEST желательно провести анализ кода:

• динамический (DAST) – обнаруживает уязвимости и слабые места в запущенном приложении за счет использования методов внедрения ошибок;
• интерактивный (IAST) – позволяет отслеживать входящие запросы к приложению и соответствующее выполнение кода и ищет конкретные события, которые могут привести к уязвимости.

На этапе RELEASE и DEPLOY часто необходимо выполнить анализ уязвимостей всех компонентов образов контейнеров (Image Analysis): «базового» ПО, переменных окружения и других слоев, а также применять средства, позволяющие создать безопасную конфигурацию инфраструктуры (IaC Hardening).

При переходе к стадии OPERATE и MONITOR нужно обеспечить безопасность средств контейнеризации (Container Security) с помощью автоматической проверки конфигураций, контроля взаимодействия между контейнерами, сбора и анализа событий, поступающих от контейнеров, а также выявление и блокирование атак на веб-приложения – для этого отлично подойдет межсетевой экран уровня приложений (WAF).

Еще один очень важный и нужный инструмент – платформа для управления всеми средствами DevSecOps (ASOC), обеспечивающая оркестрацию, корреляцию и аналитику. Мы рекомендуем использовать ее на протяжении всего процесса разработки».

По словам Антона Башарина, технического директора Swordfish Security, тут однозначного ответа нет. Точнее, он есть – надо применять все доступные меры, но, будучи реалистом, приходит понимание, что абсолютно все меры избыточны в контексте данной конкретной системы или ПО. Базовый набор (но не у всех он будет работать): OSA для контроля сборки; SAST+SCA при анализе исходного кода; DAST и MAST для анализа развернутого стенда, либо проверка мобильного приложения на закладки.

Как наиболее эффективно проверять исходный код?

Александр Дроздов, инженер по РБПО и информационной безопасности Axiom JDK: «Технологии анализа программного кода и архитектуры развиваются стремительно, поэтому стоит учесть современные тренды:

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

ФСТЭК России поддерживает применение актуальных инструментов, например, таких как Svace и Natch от ИСП РАН.

Статический анализатор Svace (ИСП РАН):

Это постоянно развивающийся инновационный продукт для статического анализа, основанный на многолетних исследованиях. Он объединяет ключевые качества иностранных аналогов (Synopsis Coverity Static Analysis, Perforce Klocwork Static Code Analysis, Fortify Static Code Analyzer) с уникальным использованием открытых промышленных компиляторов в целях максимальной поддержки новых стандартов языков программирования. Svace, например, является основным статическим анализатором в компании Samsung, в которой заменил мирового лидера – Coverity.

Svace применяется в Axiom JDK для анализа C/C++-кода, а также Java-кода с учетом ранних ограничений на анализ исходных кодов, написанных на Java 17. Работа с инструментом подразумевает разметку и разбор предупреждений, выявленных в ходе сертификационных испытаний, и написание патчей к выявленным проблемам исходного кода.

Система определения ширины поверхности атаки Natch (ИСП РАН):

Инструмент для определения поверхности атаки, основанный на полносистемном эмуляторе Qemu. Он использует технологии анализа помеченных данных, интроспекции виртуальных машин и детерминированного воспроизведения. Основная функция Natch — получение поверхности атаки, то есть поиск исполняемых файлов, динамических библиотек, функций, отвечающих за обработку входных данных (файлов, сетевых пакетов) во время выполнения задачи.

Помимо технологий анализа ИСП РАН в России развиваются и другие команды. Например:

Система SCA-анализа и проверки компонент на лицензионную чистоту CodeScoring:

Отечественное решение композиционного анализа программных продуктов решает задачи инвентаризации компонентной базы продуктов, поиска уязвимостей в Open Source компонентах, анализа лицензионного ландшафта и лицензионной чистоты.

Система комплексного статического и динамического анализа кода AppScreener:

Решение для анализа кода, которое позволяет контролировать безопасность используемых систем и предотвращать утечки данных, а также выявлять и исправлять недостатки кода еще на ранних этапах разработки».

Дмитрий Дудко, заместитель генерального директора компании Spacebit, уверен, что непрерывное тестирование является наиболее лучшим подходом. Чем больше областей вы охватите вашим процессом тестирования, тем больше будете о нем знать.

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар», объяснил, что для проверки исходного кода рекомендуется использовать средства, которые позволяют полностью покрыть весь код. К таким средствам относятся SAST, Secret Scanning, и также на этом же этапе можно использовать анализ сторонних зависимостей SCA/OSA.

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED: «Прежде всего необходимо проверять исходный код с помощью статического анализа. При этом придется пройти несколько итераций, в процессе которых все ложноположительные срабатывания, часто встречающиеся при анализе исходного кода, будут отсеяны и станет понятно, где в коде присутствуют действительно критичные проблемы – реальные, а не потенциальные уязвимости.

Это требует большого вовлечения в процесс и специалистов по безопасности, и команды разработки. Тесное взаимодействие команд разработки и appsec – ключевое условие успеха, так как проблема, которая выявляется экспертом по безопасности, должна быть понятно описана для разработчиков. Важно, чтобы вопрос устранения уязвимостей решался в диалоге, а не путем выгрузки в сторону разработки огромного массива данных по найденным уязвимостям, с которыми самим разработчикам придется как-то разбираться – выяснять специфику уязвимостей, их эксплуатируемость и т.п.

Кроме того, следует применять различные методы анализа, о которых я уже подробно рассказал выше, – их сочетание дает наилучший результат выявления уязвимостей. Необходимо использовать современные средства анализа защищенности ПО с применением их автоматизации и централизованного управления, обеспечив более эффективный процесс безопасной разработки.

Также важно обеспечить корреляцию результатов различных инструментов анализа и приоритезацию найденных уязвимостей по критичности. Уже сегодня всем этим разнообразием инструментов и технологий можно управлять централизованно с помощью специализированных решений класса ASOC (Application Security Orchestration and Correlation)».

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет»: «Для проверки исходного кода на безопасность используют статические анализаторы (SAST). Они находят в коде небезопасные выражения, которые могут привести к появлению уязвимостей, и предлагают возможности для их устранения.

К сожалению, основным недостатком SAST является большое количество ложных срабатываний. Снизить их количество можно путем отключения ненужных правил анализа кода (например, отключить проверки соответствия кода стандартам автомобильной индустрии, если вы не пишете ПО для использования в бортовых компьютерах автомобилей), а также путем повышения общего качества кода с помощью линтеров. Поэтому перед попаданием в SAST код обязательно должен пройти через линтер, который выловит самые грубые ошибки».

Антон Башарин, технический директор Swordfish Security, уточнил, что как известно, нет кода – нет проблемы, но почти никогда это не работает. Лучше всего подходит анализ кода (SAST) и контроль используемых зависимостей (SCA).

Как обеспечить безопасность Open Source компонентов?

Дмитрий Смирнов, начальник отдела информационной безопасности NGENIX: «Основные угрозы безопасности, связанные с использованием open source компонентов, вызваны тем, что пользователи этих решений не могут контролировать их исходный код и изменения в нем. Необходимо оценивать потенциальные риски использования конкретного компонента. Среди этих рисков может быть наличие вредоносного кода, уязвимостей в компоненте или в его зависимостях (прямых или косвенных), а также изменение типа лицензии.

Если актуальны (а они актуальны) риски по наличию уязвимостей или зловредного кода непосредственно в open source компоненте, рекомендуем использовать статический анализатор кода. Он проверяет код программы без ее фактического выполнения и помогает выявить потенциальные ошибки, несоответствия стандартам кодирования, уязвимости безопасности и другие проблемы.

Также важно обратить внимание на прямые и косвенные зависимости open source компонента. В зависимостях по умолчанию есть риски, поэтому стоит проводить композиционный анализ —Software Composition Analysis. SCA инструменты помогают найти уязвимости в зависимостях open source компонента, включая прямые зависимости и зависимости зависимостей (косвенные). Отдельно стоит рассмотреть риски с лицензиями open source компонентов — стоит отслеживать всё, что вы используете у себя на проекте, потому что некоторые лицензии требуют от вас раскрыть код проекта. Для отслеживания типов лицензий в используемых компонентах также помогут композиционные анализаторы.

Но все же сейчас основной вызов в сфере безопасности open source компонентов — намеренное внедрение разработчиками вредоносного кода в новые версии open source решений. Этот вид угрозы становится все более сложным для выявления, потому что вредоносный код может быть хорошо скрыт. Критически важно не обновлять бездумно все компоненты, которые вы используете, а тщательно тестировать их новые версии на отдельном тестовом окружении и уже потом обновлять их в продуктивной среде».

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет»: «Прежде всего, необходим собственный репозиторий для всех Open Source компонентов, которые нужны разработчикам. Нельзя позволять приносить случайные библиотеки из интернета.

Open Source компоненты, находящиеся во внутреннем репозитории, должны регулярно сканироваться на наличие уязвимостей и периодически обновляться.

Для всего разрабатываемого ПО должен составляться SBOM (Software Bill of Materials), который содержит полный перечень всех Open Source компонентов в этом ПО».

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED, уверен, что этот вопрос решается с помощью проверок композиционным методом анализа, о котором уже он рассказал выше.

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар»: «Классическим подходом к контролю безопасности Open Source компонентов считается использование анализа состава ПО (SCA), чтобы вовремя обнаружить и защитить свое приложение от уязвимых сторонних компонентов. Но мы в ГК «Солар» используем и рекомендуем более расширенный комплексный подход. Помимо SCA он включает анализ безопасности цепочки поставок ПО (Supply Chain Security) и оценку лицензионных рисков.

Такой подход позволяет обеспечить всестороннюю безопасность сторонних компонентов – он предотвращает попадание вредоносных компонентов в ПО, помогает оценить безопасность open source и снизить юридические риски из-за неправомерного использования компонентов».

Андрей Бирюков, СТО ГК InfoWatch, убежден, что самое главное – это предъявлять к компонентам open source точно такие же требования, как и к вашему собственному коду. Кроме этого, полезно проверить компоненты по открытым базам уязвимостей — для того, чтобы дополнительно снизить вероятность риска их эксплуатации. Причем актуально это абсолютно для всех разработчиков, потому что открытое ПО используются практически везде.

Дмитрий Дудко, заместитель генерального директора компании Spacebit: «После февраля 2022 года в Open Source компонентах возникли новые угрозы. Многие компоненты просто перестали работать, некоторые стали откровенно вредить или вымогать деньги при использовании на территории России.

В данный момент лучшая рекомендация — не использовать Open Source или использовать многократно проверенный код».

Антон Башарин, технический директор Swordfish Security: «Тут сложилось уже несколько практик:

• OSA – контроль периметра, или загружаемых компонент. Может быть настроено на выполнение проверок ещё в среде разработчиков ИБ: IntelliJ IDEA

• SCA – это уже можно применять несколько раз. По сути, определяется список используемых компонент, и анализирует на наличие серьёзны нарушений

• CS (Container Security) – наиболее «молодая» область. Суть: не допустить запуск контейнера без проверок, либо с сомнительными проверками».

Владимир Ченцов, руководитель департамента комплексного аудита ИБ и безопасной разработки компании «Бастион»: «Для обеспечения безопасности Open Source-компонентов нужно организовать их системную проверку перед использованием, во время использования и после применения. Не следует допускать применения подобных решений без согласования и проверки.

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

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

И наконец, продолжать анализировать и контролировать данный тип компонентов после использования, так как уязвимости могут быть выявлены уже после первичной проверки, например, на следующий день, через несколько месяцев или лет».

Какие СЗИ являются неотъемлемой частью DevSecOps?

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED: «Неотъемлемой частью DevSecOps является постоянный мониторинг безопасности инфраструктуры разработки. Как и в любой другой информационной системе, в случае с DevSecOps важно не допустить проникновения злоумышленника или вредоносного ПО в среду разработки.

Необходимо контролировать поведение пользователей, особенно привилегированных, чтобы исключить возможность реализации атак с повышением привилегий. Кроме того, необходимым является применение сетевой защиты, разделение среды разработки на разные контуры – контур разработки, тестирования и вывода в «боевую» эксплуатацию.

Также сейчас при разработке ПО активно применяются технологии контейнеризации, которые добавляют гибкости в развертывании новых версий приложений, обеспечивая удобство в доставки новых функций пользователям. Однако они же несут в себе новые риски, связанные с тем, что контейнерные среды нужно защищать сразу на нескольких уровнях. Начиная со сканирования образов, чтобы они были безопасными, защиты репозиториев, где эти образы находятся, мониторинга уже развернутых контейнеров и хостов, где они были развернуты на наличие аномалий и возможности реализации сетевых атак злоумышленниками и заканчивая контролем безопасности самой системы управления контейнерами, чтобы через нее невозможно было провести атаку».

Павел Яньков, эксперт направления DevSecOps центра информационной безопасности, «Инфосистемы Джет»: «Это СЗИ, которые работают на разных этапах жизненного цикла ПО:

1. На этапе написания кода — Static Analyzers (SAST), Secret Detection Tools.
2. На этапе сборки — Software Component Analysis Tools (SCA), сканеры уязвимостей.
3. На этапе деплоя — различные линтеры для анализа манифестов.
4. После деплоя — динамические сканеры (DAST), средства защиты контейнеров, средства управления секретами».

Антон Башарин, технический директор Swordfish Security, заметил, что, как правило, СЗИ не влияют на работу DevSecOps. Инструменты, чаще всего, используют результат работы СЗИ.

Владимир Ченцов, руководитель департамента комплексного аудита ИБ и безопасной разработки компании «Бастион» уверен, что с точки зрения технологических инструментов, реализующих безопасность в данном процессе, неотъемлемой частью DevSecOps являются следующие классы решений: SAST, DAST, OSA/SCA, Vulnerability Management, Container Security, CNAPP.

Дмитрий Дудко, заместитель генерального директора компании Spacebit: «В первую очередь — это системы статистического и динамического анализа кода. У нас данные системы используются практически везде: от идеи и планирования до тестирования и релиза. В некотором смысле это реализация подхода Shift Left, когда мы начинаем тестировать код, начиная с идеи».

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар»: выделил SAST, DAST, SCA/OSA, Secret Scanning.

Где искать специалистов по безопасной разработке?

Андрей Бирюков, СТО ГК InfoWatch: «В настоящее время таких специалистов на рынке труда достаточно мало и искать хорошего игрока на этом поле сложно. Многие из них ориентированы на подведение процесса разработки под требования государственных стандартов и сертификацию продуктов. А тех, кто подходит к безопасной разработке как к бесконечному процессу, который реально повышает качество продукта, а не как к формальности, еще меньше. Мы выбираем для себя второй вариант, и поэтому ищем таких специалистов штучно и достаточно долго, но всегда находим, когда возникает потребность».

Дмитрий Дудко, заместитель генерального директора компании Spacebit: «В первую очередь необходимо определиться, кто именно вам нужен: разработчик, обладающий навыками безопасной разработки, или специалист по информационной безопасности, который может выстроить процессы DevSecOps?

С разработчиками проще – такого специалиста можно отправить на курсы повышения квалификации, где ему расскажут о DevSecOps, процессах и метриках. Минус подхода – разработчик не станет безопасником. Уязвимости в коде – это лишь малая часть рисков ИБ, которые могут быть реализованы.

С другой стороны, для реализации DevSecOps можно взять классического информационного безопасника, отправить на обучение и получить специалиста, владеющего практиками DevSecOps. Проблема в том, что 99,99% информационных безопасников последний раз сталкивались с разработкой в институте. Вам потребуется время, пока конкретный специалист поймет все тонкости вашего процесса CI/CD, не говоря уже о том, чтобы понимать код».

Александр Дроздов, инженер по РБПО и информационной безопасности Axiom JDK: «Специалист, отвечающий за инженерный центр безопасности и внедрение РБПО, должен обладать определенным набором компетенций. Минимальный уровень Junior по SDL/DevSecOps требует базового понимания С/C++, работы с Linux, информационной безопасности, а также может включать базовые знания языка/стека технологий для конкретного проекта. Специалист уровня Security Champion должен иметь глубокое понимание C/C++, работы сетевых протоколов, механизмов работы Linux и C runtime, а также опыт работы с инструментами тестирования и анализа, включая статические анализаторы, фаззеры, отладчики, а также инструменты реверс-инжиниринга и средства пентеста.

По нашему опыту, лучший способ обеспечить нужные навыки — это обучение собственных специалистов. Учитывая сложность нашего продукта, мы предъявляем высокие требования к кадрам. Поэтому основной поток специалистов приходит к нам по рекомендациям, а затем развивается и совершенствуется в нашей инженерной команде».

Антон Башарин, технический директор Swordfish Security, заявил, что самый эффективный способ – воспитывать своих специалистов, но это длительный и трудоёмкий процесс. Если где-то пробуксовывает обучение, то тут только сманивать профессионалов с их текущего места работы.

Сергей Деев, старший менеджер продукта МТС RED ASOC компании МТС RED: «Действительно, мы наблюдаем серьезный кадровый дефицит на рынке экспертов Application Security. Он обусловлен тем, что традиционно специалистов по информационной безопасности готовят больше с прицелом на безопасность инфраструктур. А специалистов по разработке – разработчиков, архитекторов, тестировщиков и т.д. – в большей степени для развития и тестирования качества и функциональности ПО.

А безопасная разработка, по сути, находится на пересечении требований к безопасности и подходов к разработке. Поэтому нередко внутри компаний делают ставку на развитие компетенций среди своих специалистов, что является правильным подходом. Например, в этом направлении часто развивают специалистов по информационной безопасности, которым ближе всех работа с уязвимостями, особенно таким, как пентестеры.

При этом поскольку речь идет о необходимости автоматизировать практики безопасной разработки и выстроить процесс таким образом, чтобы он не влиял на скорость выпуска релизов, то зачастую задача внедрения инструментов и отслеживания результатов ложится на плечи DevOps-специалистов. Отсюда и появился термин «DevSecOps-специалист», который не просто понимает, как утроена и работает инфраструктура разработки, и умеет ее настраивать, но и может использовать и автоматизировать различные практики проверки безопасности кода, выгружать результаты анализа, которые передаются команде разработки. Кроме того, в крупных компаниях часто встречается такая важная роль, как Security Champion.

Скажем в большой компании есть эксперт по безопасной разработке, который досконально развирается в этой области, но его на всех не хватает, так как разработчиков гораздо больше. Поэтому в командах разработки выявляются наиболее инициативные, заинтересованные в развитии в этом направлении разработчики, которым в KPI помимо требований к скорости и качеству релизов добавляется проверка безопасности приложений. Они являются ближайшими соратниками ИБ-специалистов в компании, своей экспертизой решая задачу выявления уязвимостей в разрабатываемых приложениях. Они обсуждают выявленные проблемы со своими командами, тем самым разгружая редких AppSec-специалистов, и позволяют масштабировать практики безопасной разработки на всю компанию.

Чтобы успешно внедрить такую практику, нужны желание самих специалистов, поддержка со стороны руководства и налаженный процесс обучения. Для реализации последнего на российском рынке представлено много учебных программ и тренингов, организуемых и государственными регуляторами, и ключевыми вендорами средств безопасной разработки.

Проводятся профессиональные конференции на тему DevSecOps, сформировано community специалистов, в котором обсуждаются актуальные проблемы отрасли, разрабатываемые новые регуляторные документы и материалы. Все это есть, поэтому в деле выращивания кадров надо делать ставку на развитие своих специалистов и взаимодействие с community. А также активно работать с молодежью – студентами вузов, организовывать для них в рамках компаний всевозможные стажировки».

Антон Прокофьев, начальник отдела операционной поддержки Solar appScreener ГК «Солар»: «Искать на рынке, но можно столкнуться с дефицитом экспертов по application security на рынке, или растить у себя. Это могут быть выходцы из разработки, которые хотят развиваться в сфере безопасности или безопасники, уже знакомые с разработкой и безопасностью ПО.

Скорее нужен гибридный подход, особенно при стартовой реализации этого процесса, а также готовность обучать своих сотрудников».

Оригинал публикации на сайте CISOCLUB: "Безопасная разработка (SSDLC, DevSecOps)".

Смотреть публикации по категориям: Новости | Мероприятия | Статьи | Обзоры | Отчеты | Интервью | Видео | Обучение | Вакансии | Утечки | Уязвимости | Сравнения | Дайджесты | Прочее.

Подписывайтесь на нас: VK | Twitter | Rutube | Telegram | Дзен | YouTube.