Всем привет!

Я Юрий Сергеев, основатель и генеральный партнер Swordfish Security. В нашем блоге мы рассказываем о новых трендах в индустрии DevSecOps, о трудностях, с которыми сталкиваемся, о применяемых инструментах, а также о том, к чему готовиться в будущем.

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

Путь трансформации практик Application Security

Безопасность приложений (Application Security) сегодня стала мейнстримом. Новые проблемы в сфере ИБ (например, рост числа атак на API и цепочки поставок ПО) требуют более инновационных и эффективных решений. Непрерывное развитие рынка и его современные запросы приводят к появлению новых технологий и изменениям инструментального стека. Чтобы оценить общую картину, обратимся к отчету Gartner Hype Cycle for Application Security, 2022, который отражает актуальные тренды и текущий уровень развития существующих инструментов информационной безопасности.

Структура цикла, представленного на графике, состоит из пяти фаз:

Инновационный триггер (Innovation Trigger) — включает технологии, которые только начинают свой путь в пространстве ИБ.

Пик ожиданий (Peak of Inflated Expectations) — технологии данной фазы имеют ряд success stories, но вместе с этим на их счету есть и провалы; компании пытаются адаптировать практики под свои нужды, но до широкого распространения еще далеко.

Впадина разочарования (Trough of Disillusionment) — интерес к технологиям этой фазы уже спадает, поскольку внедрение оказывается не всегда удачным.

Путь к просветлению (Slope of Enlightenment) — на этой стадии у технологий есть много прецедентов, когда они могут быть полезны компаниям, появляются новые поколения инструментов, увеличивается спрос на них.

Плато продуктивности (Plateau of Productivity) — на этом этапе технологии имеют четко сформулированные задачи и области применения, находятся на векторе становления мейнстримом.

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

DevSecOps в текущих реалиях

Зрелость по Gartner: зрелый мейнстрим.

По определению Gartner, DevSecOps сегодня находится в фазе «Плато продуктивности». Технология уже стала зрелым мейнстримом и охватила более 50% целевой аудитории. Методология позволяет командам безопасности идти в ногу с подразделениями разработки и эксплуатации в процессе создания современных приложений. Модель обеспечивает глубокую интеграцию ИБ-инструментов в DevOps и автоматизацию всех процессов создания защищенного ПО. За счет этого DevSecOps помогает бизнесу повысить уровень безопасности продуктов и степень соответствия приложений и процессов индустриальным и регуляторным стандартам, снизить стоимость устранения уязвимостей, улучшить показатели Time-to-Market и нарастить экспертизу разработчиков.

Стремясь построить эффективный процесс безопасной разработки, компании сталкиваются с рядом сложностей:

При неправильном внедрении практик AppSec и некорректно выстроенном процессе безопасность становится антитезой DevOps, и разработчики начинают воспринимать ИБ-инструменты как средства, замедляющие их работу;
Разнообразие инструментов, используемых в современных CI/CD-пайплайнах, усложняет бесшовную интеграцию DevSecOps;
У многих разработчиков не хватает компетенций в области безопасности, поэтому они не понимают, чем может быть опасен написанный ими код, не хотят покидать CI/CD-пайплайн для проведения тестов ИБ или просмотра результатов сканирования, испытывают большие сложности, сталкиваясь с ложными срабатываниями инструментов SAST и DAST;
ИБ-решения с открытым исходным кодом могут содержать зловредный код, а также есть риск, что в один момент такие инструменты станут недоступными для российских пользователей.

Практики DevSecOps в контексте современных вызовов

SCA (Software Composition Analysis)

Зрелость по Gartner: ранний мейнстрим, достижение плато < 2 лет.

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

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

Большое количество пакетов с открытым исходным кодом, их взаимозависимостей и использованных языков программирования порождают сложную структуру. Чтобы справиться с ней, компаниям приходится комбинировать несколько решений — это усложняет реализацию анализа безопасности и затраты на этот процесс;
SCA-инструменты при выявлении вредоносного кода полагаются на публичные базы данных уязвимостей и часто обходят стороной коммерческие библиотеки ПО, которые также могут быть полезны при поиске опасных брешей;
В 2022 году библиотеки Open Source стали популярными целями для совершения атак на российские компании. Злоумышленники используют зловреды (malware, protestware), которые невозможно выявить с помощью зарубежных решений. Многие компании замораживают использование новых библиотек и компонент Open Source, что в дальнейшем может привести к отставанию в технологическом развитии.

MAST (Mobile Application Security Testing)

Зрелость по Gartner: ранний мейнстрим, достижение плато < 2–5 лет.

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

В MAST используются те же самые методы, что и в тестировании веб-приложений (SAST, DAST, IAST). Но при их применении к мобильным приложениям анализ должен быть адаптирован для выявления уязвимостей в коде клиентского приложения. Практика MAST пока не достигла полной зрелости, поскольку мобильные платформы все еще продолжают развиваться. Еще одним вызовом является то, что в рамках менее продвинутых программ кибербезопасности организации вообще не проводят анализ защищенности мобильных приложений.

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

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

Container Security

Зрелость по Gartner: развивающаяся технология, достижение плато < 2–5 лет.

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

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

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

ASOC (Application Security Orchestration & Correlation)

Зрелость по Gartner: развивающаяся технология, достижение плато < 2–5 лет.

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

Но есть несколько сложностей, негативно влияющих на адаптацию технологии:

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

API Security Testing

Зрелость по Gartner: развивающаяся технология, достижение плато < 2–5 лет.

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

Главный недостаток, препятствующий распространению API ST, заключается в ограниченных возможностях таких инструментов. Широкое использование программных интерфейсов порождает новые проблемы и виды атак, а существующие средства анализа пока не способны в полной мере отражать все риски — вендорам необходимо модернизировать подходы к тестированию, используемые в инструментах API ST.

Securing Development Environments

Зрелость по Gartner: созревающая технология, достижение плато < 2–5 лет.

Среды разработки сегодня являются одним из ключевых векторов атак, поскольку содержат огромное количество конфиденциальной информации. Чаще всего риски возникают из-за распространения удаленного формата работы и широкого использования компонентов с открытым исходным кодом. Подходы Securing Development Environments позволят бизнесу снизить риски и улучшить соответствие требованиям регуляторов и стандартам в области ИБ.

Среди препятствий для развития технологии можно выделить:

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

Chaos Engineering

Зрелость по Gartner: развивающаяся технология, достижение плато < 5–10 лет.

Технология CE (Chaos Engineering) предусматривает подход к тестированию процессов, в рамках которого создается нестабильная среда, устраиваются внезапные сбои. С помощью подходов Chaos Engineering можно планировать, совершать и анализировать «атаки хаоса» на систему на протяжении всего жизненного цикла. Практика полезна тем, что помогает улучшить качество процессов, повысить их устойчивость, сократить частоту отказов и время устранения сбоев.

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

SBOM (Software Bill of Materials)

Зрелость по Gartner: развивающаяся технология, достижение плато < 5–10 лет.

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

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

Policy-as-a-Code

Зрелость по Gartner: созревающая технология, достижение плато < 2–5 лет.

Технология PaC (Policy-as-a-Code) предполагает подход, согласно которому политики (корпоративные правила, архитектурные стандарты, инструкции, требования и т. п.) контролируются, используются и обновляются с помощью кода в автоматизированном режиме. Инструменты PaC позволяют компаниям увеличить скорость выполнения задач, снизить риски ошибок из-за человеческого фактора, улучшить взаимодействие между сотрудниками одной команды или разных подразделений, повысить точность выполнения всех условий политик.

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

Заключение

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

ИБ-продукты, созданные на базе Open Source, не обладают необходимым уровнем надежности и киберустойчивости, поэтому сегодня наша очевидная реальность — полный переход в Zero Trust-концепцию;
Не все российские DevSecOps-решения могут покрыть Enterprise-потребности «больших» клиентов. В числе очевидных зон роста — SBOM, API Security Testing, Software Supply Chain Security, Infrastructure as Code Security, Container Security, DAST;
В рамках технологического вызова и необходимости в импортозамещении компаниям нужно мигрировать на новый DevOps-стек, а также подбирать и эксплуатировать надежные инструменты;
С учетом роста регуляторных требований (ГОСТ Р, рекомендации ФСТЭК, ТК 122, ОУД) российским компаниям также необходимо «сверять часы» с открытыми международными стандартами и фреймворками (BSIMM, OpenSAMM);
Соблюдение всех стандартов и требований в области ИБ вручную отнимает много ресурсов. Со временем «регуляторики» станет еще больше, поэтому эффективным стратегическим решением будет переход на формат Policy-as-a-Code;
Поскольку в индустрии сегодня наблюдается тотальный дефицит кадров, единственным оптимальным выходом из сложившейся ситуации является расширение компетенций сотрудников через современные подходы к обучению.

На этом все.

Всем, кто дочитал, отвечаю: да, картинку к этой статье "рисовала" midjourney.

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

DevSecOps и практики разработки защищенного ПО в контексте современных вызовов