DevSecOps. Безопасная разработка. Переход от DevOps к DevSecOps осуществляется прозрачно, без существенных проблем

DevSecOps. Безопасная разработка. Переход от DevOps к DevSecOps осуществляется прозрачно, без существенных проблем

Любые нововведения зачастую вызывают противоречивую реакцию: «Зачем? Почему? Для чего?». Можно провести множество аналогий, в том числе переход от разработки по методу Waterfall к Agile, в результате которого процесс становится более эффективным и гибким, благодаря чему результат достигается значительно быстрее.

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

ПОТРЕБНОСТЬ В ИНТЕГРАЦИИ ИБ И CI/CD

Общая концепция DevOps привела к созданию таких практик, как CI/CD (непрерывная интеграция + непрерывная поставка). Единственным узким местом оказались аспекты информационной безопасности. Взаимодействие с ИБ-специалистами только на финальном этапе вызывает определённые сложности, поскольку для устранения замечаний и уязвимостей в уже готовом продукте может потребоваться внесение значительных изменений в существующий код. Фактически при устранении выявленных недостатков и проблем в готовом продукте речь идёт о новом цикле процесса разработки, что вызывает негативное отношение со стороны разработчиков, а также может спровоцировать финансовые и репутационные потери. Поэтому возникла потребность в интеграции ИБ и CI/CD для обеспечения непрерывного и прозрачного процесса разработки и выполнения требований по части ИБ на начальных этапах разработки и проектирования решения. 

ОСНОВНЫЕ ПРОБЛЕМЫ

DevSecOps – то самое нововведение, цель которого – дополнить эффективный, продуктивный процесс CI/CD необходимыми механизмами обеспечения безопасности. Понятию уже несколько лет, но активно использовать его начали в течение последних двух. Разумеется, как и любое новшество, DevSecOps вызывает определённый скептицизм при рассмотрении. В кругах разработчиков ошибочно фигурирует мнение, что добавление механизмов обеспечения безопасности к процессу CI/CD лишь замедляет его либо стопорит совсем. Давайте разберёмся с основными проблемами, с которыми сталкиваются при внедрении DevSecOps.

1) DevSecOps = набор отдельных решений

Рисунок 1. Модель процесса DevSecOps (инструменты и методы)

Необходимо понимать, что DevSecOps – это расширение DevOps методами обеспечения кибербезопасности (Sec) применительно к процессу CI/CD. Добавление механизмов SCA, SAST, DAST/IAST и CSA к этапам CI/CD подразумевает использование определённых классов решений, как open-source, так и commercial, но сама суть DevSecOps заключается в обеспечении безопасности процесса CI/CD путём привлечения в команду ИБ-специалистов, а также повышения квалификации разработчиков в контексте компетенций по ИБ.

Для обеспечения необходимой функциональностиSecнеобходимы следующие решения:

• решения класса SCA (Software Composition Analysis), обеспечивающие проверку продукта на наличие проблемных зависимостей, такие как White Source, Black Duck, Sonatype и Snyk;
• решения класса SAST (Static Application Security Testing), обеспечивающие проверку исходного кода для выявления уязвимостей и проблемных мест, такие как Sonar Qube, Coverity, Veracode, Checkmarx;
• решения класса DAST (Dynamic Application Security Testing), обеспечивающие динамическое тестирование безопасности продукта (тестирование методом «чёрного ящика»), такие как Veracode, Acunetix, Burp Suite, Fortify Web Inspect, OWASPZAP;
• решения класса IAST (Interactive Application Security Testing), обеспечивающие интерактивное тестирование безопасности приложения, сочетая преимущества решений классов SAST и DAST и обеспечивая более высокую эффективность анализа. Мы, эксперты CTI, рекомендуем решения Seeker (Synopsys) и VeraCode;
• решения класса CSA (Container Security Analysis), которые обеспечивают анализ образов контейнеров на уязвимости и мониторинг их активности. Однозначными лидерами рынка являются решения Palo Alto Prisma Cloud и Aqua Security Cloud Native Security Platform.

2) Назначение DevSecOps, или «Зачем постоянно проверять код, влезать в этапы разработки?»

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

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

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

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

3) Процесс интеграции с CI/CD, или «Сейчас придут злые безопасники и застопорят нам процесс»

Использование инструментов Sec обеспечивает успешное завершение каждого из этапов разработки за счёт выявления потенциальных проблем и уязвимостей и их предотвращения на ранних стадиях (так называемый сдвиг безопасности влево). Обеспечение безопасности как разработки, так и конечного продукта – это непрерывный процесс, который напрямую отражён в философии Agile. Развитие технологии, методов, паттернов разработки, появление новых языков программирования, библиотек, ОС – всё это сказывается как на самом процессе разработки, так и на процессе обеспечения безопасности. И процесс, и конечный продукт становятся сложнее, что создаёт определённые проблемы при анализе кода и продукта в контексте безопасности.

Как и в любом ИТ-процессе, набор средств, утилит, решений – это только полдела. Анализ исходного кода, дизайн-проекта, готового продукта автоматизированными средствами не обеспечивает 100%-й защищённости. Нюансы композиции, архитектуры, компонентов могут быть решены только профессиональным анализом со стороны профильных специалистов в области информационной безопасности (например, AppSec-инженеров) при условии полноценного погружения в проект, начиная с самых ранних этапов. Этот момент возможен только при проактивной, совместной работе всех участников проекта, при которой заранее определены зоны ответственности, обязанности и регламент взаимодействия между участниками.

Таким образом, грамотное построение процесса взаимодействия Sec и DevOps-команд при внедрении практик DevSecOps является одним из самых важных моментов во всей методологии. Обеспечение безопасности не должно вызывать нарушения в процессе CI/CD или конфликтные ситуации между участниками. Специалисты Gartner в публикации «12 Things to Get Right for Successful DevSecOps» (публикация G00450792 от 19.12.2019) дали ряд рекомендаций, как этого достигнуть:

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

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