Безопасность — это ваша прибыль. Как управление безопасной разработкой на основе данных сокращает Time-to-Market

Безопасность — это ваша прибыль. Как управление безопасной разработкой на основе данных сокращает Time-to-Market

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

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

Таким образом, разработка безопасного программного обеспечения, или DevSecOps, — это не затраты, а инвестиции. Сделать их максимально эффективными помогает использование методов управления Data Driven и принципа Shift Left. Объясним, что это и как работает.

Зачем нужен DevSecOps бизнесу

Для начала разберёмся, как работает неэффективное управление процессами разработки и во что оно обходится бизнесу. Для этого очень хорошо подходит метрика Time-to-Market, или скорость вывода продукта на рынок — до конечного пользователя. Другими словами, чем раньше будет релиз, тем быстрее мы начнём зарабатывать. Поскольку прибыль от выведенного на рынок продукта остаётся примерно одинаковой, любые задержки разработки увеличивают затраты, что снижает рентабельность. Ошибки, выявленные на поздних этапах создания ПО, требуют больше ресурсов на исправление, поскольку при этом задействуются высокооплачиваемые специалисты: разработчики, системные архитекторы, техлиды и другие. Это особенно критично для уязвимостей информационной безопасности, поиск которых требует привлечения ИБ-инженеров или подрядчиков, что само по себе связано с крупными финансовыми вложениями. А устранение таких уязвимостей на поздних этапах значительно увеличивает трудозатраты, делая раннее их выявление и предотвращение ключевым фактором эффективности процесса.

Что означает доработка на позднем этапе? Это аврал, отвлечение ключевых специалистов от других задач и проектов, сверхурочная работа. Представьте: у вас всего два ИБ-инженера, а тестирование выявило 500 серьёзных уязвимостей. Очевидно, что они физически не смогут справиться с таким объёмом за две недели, даже если предложить им дополнительные выплаты. Привлечение ещё десяти специалистов практически нереально, так как это сверхдефицитная специальность. В результате сроки проекта неизбежно сдвинутся на неопределённое время, затраты станут неконтролируемыми, и возникнет реальный риск того, что проект в итоге окажется нерентабельным.

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

Именно поэтому важно внедрять принципы DevSecOps с акцентом на подход Shift Left. Этот подход предполагает смещение практик обеспечения безопасности влево по таймлайну проекта — с этапа приёмки на этапы разработки или даже проектирования. Это критично, поскольку именно на ранних этапах создание и обнаружение новых рисков информационной безопасности наиболее вероятно, а их устранение обходится значительно дешевле, чем на более поздних стадиях.

На ранних этапах разработки нужно внедрять сканеры, которые сразу анализируют уязвимости в исходном коде. Они же становятся фактическим барьером для попадания вредоносных элементов при использовании источников Open Source. На следующих этапах применяется уже динамический анализ. Например, сканируется API, то есть программный (API) и пользовательский (UI) интерфейс.

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

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

Для чего нужны ASPM-решения

ASPM (Application Security Posture Management) — это класс систем для управления безопасностью приложений, который помогает организациям оценивать, управлять и улучшать свою безопасность приложений на всех этапах жизненного цикла разработки. Платформа ASPM предоставляет инструменты и средства для анализа уязвимостей, контроля за соблюдением стандартов безопасности, управления инцидентами и выполнения аудитов. Основные функции ASPM-решения:

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

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

Основные стадии обработки результатов сканирования:

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

Рисунок 1. Эффективность обработки результатов сканирования ASPM-платформы AppSec.Hub

Примером такой системы является российская платформа AppSec.Hub (рис. 1). Это централизованная платформа для интеграции различных инструментов безопасности и процессов. Основные преимущества AppSec.Hub:

1. Единая точка управления. AppSec.Hub обеспечивает централизованное управление всеми инструментами безопасности, что упрощает процесс мониторинга и обеспечения безопасности приложений.
2. Интеграция инструментов. Позволяет объединять данные из различных источников и инструментов, используемых для анализа безопасности приложений, и предоставляет полную картину безопасности.
3. Аналитика и отчётность. Упрощает процесс анализа уязвимостей и генерирует отчёты, которые могут быть использованы для принятия решений и управления рисками.
4. Прозрачность и контроль на основе метрик. Предоставляет командам разработки и безопасности возможность видеть состояние безопасности всех приложений и управлять им из одного интерфейса.

Особо отмечу, что все рутинные операции автоматизируются в том числе с применением искусственного интеллекта, как, например, в нашем продукте AppSec.Hub с помощью модуля AppSec.CoPilot. Это позволяет отсеивать ложные срабатывания — как правило, это более 90% того, что выдают сканеры. Время ваших специалистов в таком случае тратится на решение действительно сложных и необходимых задач, а алгоритмы ИИ не требуют почасовой оплаты.

Принцип Shift Left и автоматизация делают методологию DevSecOps максимально эффективной. В идеале все инструменты ИБ интегрируются в среду разработки, проще говоря, на рабочий стол специалиста. В реальности проверки ИБ встраиваются в CI/CD- или DevOps-процесс, который запускается автоматически после публикации изменений разработчиком. Одновременно формируется аналитика, представление которой должно быть адаптировано под уровень получателя. Например, руководитель проекта должен видеть подробную динамику выявленных и закрытых уязвимостей. А вице-президенту по ИT или гендиректору достаточно светофора: если процессы проекта идут в «зелёной зоне», ему не нужно вмешиваться, а если попадают в «жёлтую» или вдруг включается «красный», то нужно тормозить и решать выявленные проблемы на данном этапе, а не в конце, потому что потом это обойдётся намного дороже. 

DevSecOps — это не набор определённых инструментов и правил их использования, а именно бизнес-подход.

Представим основные метрики аналитики уязвимостей в виде пирамиды по уровням принятия решений в бизнесе от инженерных команд к ценности продукта.

На её острие будет уровень топ-менеджмента (Executive). С точки зрения руководителя компании он влияет на следующие ключевые метрики: Time-to-Market (о чём мы уже говорили подробно), Digital Business Continuity & Security (защищённость и непрерывность цифрового бизнеса), Compliance (соответствие требованиям регулятора), Software Development Maturity (зрелость процесса разработки). Все эти параметры составляют общую ценность от внедрения безопасной разработки.

«Вторым слоем» пирамиды мы представляем себе управленческий уровень (Management). На нём расположены метрики, на которые влияет управленческая команда проекта. Например, менеджмент контролирует Time-to-market для определённого релиза, покрытие продуктовых команд практиками Application Security, устранение уязвимостей в программном продукте и т. д.

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

Рисунок 2. Дашборд операционных показателей ASPM-платформы AppSec.Hub

База пирамиды — уровень телеметрии (Telemetry) — это вся информация, которая поступает от сканеров из DevOps- или CI/CD-процессов, из репозиториев исходного кода и артефактов сборки. Это гигантский объём данных, с которым работает команда. Но все они нуждаются в структуре и приоритизации — без этого невозможно подняться на уровень выше. Мы собираем информацию в специально разработанном и структурированном хранилище. Интерпретация и представление данных в виде удобных и понятных диаграмм на дашбордах для разных уровней управления — это фишка AppSec.Hub. Этот продукт позволяет реализовать полноценный подход Data Driven к управлению DevSecOps-процессом, эффективность которого будет только расти по мере усиления роли и функционала AI-инструментов.

Разработка безопасного программного обеспечения является неотъемлемой частью современного бизнеса, независимо от его масштабов и сферы деятельности. Анализ ситуации на рынке показывает, что игнорирование вопросов информационной безопасности может привести к колоссальным экономическим потерям и утечкам данных, что ставит под угрозу не только бизнес, но и доверие клиентов. Применение принципов DevSecOps и Shift Left в процессах разработки закономерно приводит к снижению рисков и затрат на исправление уязвимостей. При этом ASPM-решения становятся гибкими инструментами, которые помогают организациям измерять, управлять и улучшать безопасность приложений в течение всего жизненного цикла разработки.