Контакты
Подписка 2025

От DevOps к DevSecOps

Дарья Орешкина, 04/09/20

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

Стоит ли уточнять, какое было тщательное обслуживание после этого…

Невольно задумываешься: только ли медицина или питание должны быть безопасными и давать требуемый результат? Какова ответственность DevOps за свой продукт? Является ли экономия бюджетов основанием для выпуска уязвимых программных продуктов?

Автор: Дарья Орешкина, директор по развитию бизнеса компании Web Control

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

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

4 ключевых ингредиента

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

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

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

Эти четыре ключевых ингредиента помогут любой компании из любой отрасли гармонично перейти от DevOps к DevSecOps.

Сдвиг задач комплайнса и безопасности на наиболее ранние этапы в конвейере разработки

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

Концепция DevSecOps предполагает включение процессов идентификации, исправления и предотвращения проблем безопасности и нарушений комплайнса на наиболее ранних этапах жизненного цикла разработки. Разработчик уже при написании кода может получать рекомендации по обеспечению его безопасности. В этом случае у команды есть возможность в штатном режиме исправлять недочеты. В идеале данные задачи должны быть автоматизированы и встроены в конвейер разработки, а перед встраиванием целесообразно провести ревизию средств тестирования безопасности продукта. Вполне возможно, что некоторые решения 10-или 15-летней давности можно заменить другими инструментами мониторинга безопасности приложений и статического анализа кода и сделать процесс проверки на безопасность более простым и точным.

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

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

Интеграция автотестирования безопасности и комплайнса в процесс непрерывной поставки

Автотестирование является наилучшей практикой для команд, принявших концепцию непрерывной доставки. Автоматизация тестирования комплайнса и безопасности с помощью инструментов статического анализа и композиции кода, таких как Fortify, SonarQube, WhiteSource, – весьма распространенный выбор для разработчиков и служб ИБ. Инструменты статического анализа дают возможность проверить, соответствует ли конкретный кусок кода требованиям безопасности и регуляторов. В подавляющем количестве проектов активно используется Open Source, поэтому инструменты автоматизации проверки компонентов с открытым исходным кодом и их зависимостей становятся незаменимы, в частности WhiteSource помогает выбрать качественные компоненты на этапе их выбора и включения в проект. Лучшей практикой становится объединение результатов всех тестов с другой информацией, относящейся к релизу ПО, – это позволяет видеть всю картину выпуска ПО целиком и всеми заинтересованными лицами.

Снимок экрана 2020-09-03 в 15.27.18В большинстве крупных компаний оценка безопасности и комплайнса не всегда может быть представлена в виде "соответствует/ не соответствует". Часто владелец продукта, менеджеры релиза, специалисты по безопасности и комплайнсу принимают решение о выпуске продукта на основе бизнес-целей, несмотря на выявленные проблемы. Немаловажный нюанс в том, что большинство из названных специалистов не настолько близки к процессу разработки, как разработчики, и, возможно, они никогда не видели результаты автотестов. Но для принятия решения им нужно иметь доступ к этим результатам и понимать, что они означают применительно как к отдельным функциям продукта, так и к релизу в целом.

Отслеживание состояний каждого шага создания продукта

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

Наглядное представление и оценка уязвимостей безопасности

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

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

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

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

Фундаментальные принципы DevSecOps

Джин Кин, консультант по стратегическим вопросам компании XebiaLabs и автор ряда книг по DevOps, сформулировал ключевые принципы DevSecOps:

  1. При проектировании необходимо учитывать самые худшие сценарии. Пользователи не всегда следуют оптимальному или ожидаемому сценарию. Нужно учитывать злонамеренные пользовательские истории и проверять возможность их реализации, моделировать ландшафт угроз и проводить симуляцию разных уровней сбоев.
  2. Тестирование безопасности на каждом этапе конвейера. Можно использовать инструменты реальной атаки типа Metasploit. Безопасность должна быть не в виде бумажного документа, а в виде кода, хранящегося в репозитории, откуда его может взять любой разработчик. В конвейер должны быть встроены SAST-, DAST-, IAST-инструменты и инструменты проверки компонентов Open Source.
  3. Тренировок AppSec недостаточно. Нет также необходимости тренировать всех разработчиков писать безопасный код. Код пишут люди, и на 10 тыс. строк кода будет определенное число ошибок, часть из них приведет к уязвимостям. Тренировками эту проблему не решить. Нужны подходящие инструменты и автоматизация.
Темы:Безопасная разработкаЖурнал "Информационная безопасность" №3, 2020

Программа мероприятий
для руководителей и специалистов
по защите информации

Посетить
Кибербезопасность
Кибербезопасность инфраструктуры, информационных систем, данных и приложений | 7 марта 2025
Регистрация на конференцию →
Статьи по той же темеСтатьи по той же теме

  • О безопасности заимствованных компонентов Open Source
    Алексей Хорошилов, руководитель Центра исследований безопасности системного программного обеспечения, ведущий научный сотрудник ФГБУН “ИСП РАН”
    Open Source стал неотъемлемой частью современного мира. Сегодня уже нет необходимости объяснять, что это такое, – с этим явлением все давно свыклись и приняли его как данность. Однако возникает другой вопрос: как эффективно и зрело работать с Open Source?
  • Автоматизация и экономика для обеспечения жизненного цикла безопасного ПО
    Борис Позин, технический директор ЗАО "ЕС-лизинг", д.т.н., профессор базовой кафедры “Информационно-аналитические системы” МИЭМ НИУ ВШЭ, главный научный сотрудник ИСП РАН
    Проблема обнаружения уязвимостей и недекларированных возможностей специалистами в жизненном цикле ПО автоматизированных систем становится все более актуальной в последние годы, особенно в связи с активизацией работ по импортозамещению, использованием свободного ПО, развитием масштабных проектов систем корпоративного уровня в различных отраслях народного хозяйства.
  • Как соответствовать требованиям ЦБ РФ при защите мобильных приложений
    Юрий Шабалин, Ведущий архитектор Swordfish Security
    Профиль защиты прикладного программного обеспечения – это методический документ Банка России, согласно которому приложения должны проходить оценку на соответствие госстандарту в специальных лабораториях.
  • 6 мифов о безопасной разработке и сертификации ПО
    Дмитрий Пономарев, технический директор ООО НТЦ “Фобос-НТ”, сотрудник ИСП РАН
    За последние пять лет система сертификации СЗИ претерпела колоссальные изменения, практически сменив свой вектор, и продолжает активно развиваться. Если вы проходили испытания до 2019 г., или даже до 2023 г., скорее всего вы будете сильно удивлены числу произошедших перемен и их объему.
  • Управление уязвимостями при разработке ОС Astra Linux
    Владимир Тележников, директор департамента научных исследований “Группы Астра”
    Управление уязвимостями играет ключевую роль в процессе разработки и эксплуатации любой операционной системы.
  • Protestware: как защитить код?
    Владимир Исабеков, ведущий инженер по информационной безопасности Swordfish Security
    Первым и важным шагом к снижению риска от вредоносного Protestware является стандартный инструментарий безопасной разработки.

Хотите сотрудничать?

Выберите вариант!

Печатное издание
Интернет-портал
ВЫСТУПИТЬ НА КОНФЕРЕНЦИЯХ
СТАТЬ АВТОРОМ
Linux
6 марта | Отечественные ИT-платформы и ПО для объектов КИИ | Онлайн
Регистрация →

More...
ТБ Форум 2025
6 марта | Отечественные ИT-платформы для объектов КИИ
Жми, чтобы участвовать

More...