Руководство по переосмыслению риск-менеджмента в современной разработке программного обеспечения для IT-директоров.

Шон Маккарти — вице‑президент и главный архитектор отдела глобальной архитектуры, рисков и управления в Manulife.

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

«Сегодня регулирующие органы уже не довольствуются только фреймворками, документацией и проверкой достоверности аудита. Они требуют реальных доказательств, включая комплексное тестирование и управление программами комплаенса, которые должны быть интегрированы в повседневные операционные процессы.» — 2025 Banking Regulatory Outlook, Deloitte

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

Основные тезисы: 

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

• Успешная трансформация требует перехода от образа мышления «охранника» к образу мышления «доверенного советника»

• Успех зависит от соблюдения четырех ключевых принципов: совместной работы, автоматизации, наглядности и предотвращения

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

• Культурная трансформация и развитие потенциала столь же важны, как и технический контроль

Ожидаемые преимущества:

• Сокращение задержек при поставке программного обеспечения, связанных с безопасностью

• Снижение числа уязвимостей и инцидентов после релиза

• Снижение затрат на устранение последствий за счет раннего выявления проблем

• Повышение соответствия нормативным требованиям и готовности к аудиту

• Более тесное сотрудничество между командами безопасности и разработчиков

• Более надежная система безопасности с минимальными трудностями при поставке

I. Современные задачи безопасности: Риски в Стране чудес 

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

Традиционный подход не оправдывает ожиданий

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

Цена обеспечения безопасности на поздних стадиях

Организации, которые придерживаются традиционных подходов к безопасности, сталкиваются с рядом проблем:

• Дорогостоящая доработка и задержка релиза

• Враждебные отношения между подразделениями безопасности и разработки

• Растущий долг безопасности

• Повышенная уязвимость к угрозам

• Растущие операционные риски

• Проблемы с соблюдением требований и контроль со стороны регулирующих органов

II. Эволюция риск-менеджмента

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

От охранника до градостроителя:

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

III. “Что”: Стратегический подход к безопасности  

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

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

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

Основные области, требующие внимания:

• Соответствие между возможностями обеспечения безопасности и готовностью бизнеса к риску

• Переход от контрольных точек к системному обеспечению безопасности

• Фреймворки для измерения эффективности безопасности

• Требования к культурной трансформации

• Модели эффективного межкомандного сотрудничества

• Методы определения приоритетов инвестиций в безопасность

• Автоматизированный комплаенс‑мониторинг

• Стратегии обеспечения безопасности инноваций

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

IV. “Как”: Создание безопасных цифровых продуктов 

1. Безопасность в анализе требований

Начало диалога: «Как нам сделать так, чтобы безопасность учитывалась с самого начала?»

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

2. Безопасность в анализе проектных решений

Начало диалога: «Как мы выявляем и устраняем риски безопасности в нашей архитектуре?»

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

3. Безопасность при сборке и тестировании

Начало диалога: «Как нам обеспечить безопасность кода до того, как он будет запущен в продакшене?»

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

4. Безопасность на производстве  

Начало диалога: «Как нам обеспечить безопасность, когда системы находятся в активном использовании?»

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

V. Измерение успеха: Метрики безопасности 

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

Опережающие индикаторы (профилактические) 

• проектов, которые завершили разработку моделей угроз до начала разработки

• разработчиков, прошедших обучение по вопросам безопасности

• Результаты сканирования кода, количество выявленных уязвимостей на 1000 строк кода

• Учет требований безопасности в пользовательских историях

• Показатели проверки безопасности архитектуры

• Оценки рисков сторонних компонентов

Операционные индикаторы (в процессе) 

• Среднее время, необходимое для исправления результатов проверки безопасности

• Коэффициент сокращения технического долга безопасности

• Скорость прохождения автоматизированных тестов безопасности

• Охват сканирования уязвимостей

• Показатели прохождения/неудачи контроля безопасности

• Соответствие стандарту написания безопасного кода

Запаздывающие индикаторы (результаты) 

• Инциденты производственной безопасности в разбивке по степени серьезности

• Результаты проверки безопасности, полученные после релиза

• Статус соответствия требованиям аудита

• Процент приложений с актуальными пенетрационными тестами

• Средний возраст уязвимости в разбивке по степени серьезности

• Задержки релиза, связанные с безопасностью

VI. Практическое руководство по внедрению: С головой в кроличью нору  

Этап 1: Закладываем фундамент (1-3 месяца) 

Подобно Алисе, которая пыталась понять правила Страны чудес, начните с определения основных показателей безопасности:

• Оценка зрелости системы безопасности в командах разработчиков

• Отображение рисков текущего состояния и анализ пробелов

• Определение модели управления безопасностью

• Создание первоначальное системы показателей

• Определение пилотной группы и определение приоритетов

• Реализация быстрой победы

Этап 2: Запуск трансформации (3-6 месяцев)

Подобно путешествию Алисы в Страну чудес, начните свою трансформационную экспедицию с нескольких ключевых шагов:

• Внедрение программы, направленной на повышение осведомленности разработчиков о безопасности.

• Автоматизированная интеграция инструментов безопасности в процессы CI/CD.

• Создание программы ответственных по вопросам безопасности среди сотрудников

• Разработка рекомендаций по написанию безопасного кода

• Внедрение процесса моделирования угроз

• Сбор начальных показателей и настройка базового уровня безопасности

Этап 3: Масштабирование и оптимизация (6-12 месяцев)

По мере продвижения вперед расширяйте список успешных практик:

• Привлечение дополнительных групп разработчиков к работе над проектами

• Реализация инициатив по улучшению, основанных на анализе показателей

• Повышение уровня автоматизации процессов безопасности

• Углубление возможностей моделирования угроз

• Программа сертификации разработчиков

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

VII. Новый образ мышления: Из Красной Королевы в Чеширского Кота

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

Трансформация руководства в сфере безопасности 

Ключевые изменения в мышлении на практике 

1. От исполнителя к инициатору  

2. От документации к автоматизации 

3. От безопасности проекта к безопасности продукта 

VIII. Смещение влево на практике: Золотой путь 

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

До разработки

Виды деятельности:

• Проверка классификации информации

• Оценка рисков третьей стороной

• Обзор безопасности архитектуры

• Дизайн аутентификации и авторизации

• Моделирование угроз

Кто: Управление информационными рисками, архитектура, продуктовые команды
Как: Локальное управление с опытом в области безопасности
Цель: Минимизировать отставание в разработке с учетом требований безопасности

В процессе разработки

Виды деятельности:

• Методы написания безопасного кода

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

• Статическое тестирование безопасности приложений

• Анализ композиции программного обеспечения

• Тайное сканирование

• Код‑ревью ориентированные на безопасность

Кто: Разработчики, ответственные за безопасность, appsec‑инженеры
Как: Автоматизированный инструментарий в конвейере CI/CD
Цель: Обнаруживать и устранять уязвимости на ранних стадиях разработки

Перед релизом

Виды деятельности:

• Динамическое тестирование безопасности приложений

• Пенетрационное тестирование

• Проверка безопасности инфраструктуры

• Комплаенс‑проверка

• Финальный обзор системы безопасности

Кто: Безопасность приложений, контроль качества, devops
Как: Автоматизированные системы безопасности с четкими путями исправления
Цель: Проверка средств контроля безопасности перед внедрением в производство

В производстве 

Виды деятельности:

• Мониторинг безопасности и оповещение

• Управление уязвимостями

• Готовность к реагированию на инциденты

• Отслеживание показателей безопасности

• Постоянное совершенствование

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

IX. Интегрированное будущее: Зрелость DevSecOps 

По мере развития вашей организации безопасность становится неотъемлемой частью процесса разработки, что в итоге приводит к созданию целостного DevSecOps‑подхода, который охватывает все аспекты работы.

Характеристики зрелости DevSecOps 

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

По мере вашего роста и развития, рекомендую обратить внимание на следующие передовые методы интеграции безопасности:

1. Безопасность инфраструктуры как кода (IaC):

   a) Политики безопасности, закодированные в виде определений инфраструктуры

   b) Автоматическая комплаенс‑проверка для облачных ресурсов

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

2. Безопасность как код

   a) Требования безопасности, определенные в машиночитаемых форматах

   b) Автоматизированное тестирование средств контроля безопасности

   c) Конфигурация безопасности с контролем версий

3. Постоянный комплаенс‑контроль

   a) Комплаенс‑дашборд в режиме реального времени

   b) Автоматизированный сбор доказательств

   c) Проверка непрерывности контроля

4. Самоорганизующиеся системы безопасности

   a)Порталы безопасности, ориентированные на разработчиков

   b) Инструменты тестирования безопасности по запросу

   c)Автоматическое руководство по обеспечению безопасности

X. Вывод: Ориентируйтесь в ландшафте рисков 

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

Видение преобразованного предприятия 

• Безопасность, которая ускоряет, а не ограничивает инновации

• Автоматизированный контроль, обеспечивающий соответствие требованиям без ручного вмешательства

• Прозрачные показатели безопасности, на основе которых принимаются решения, также основанные на оценке рисков

• Вовлеченные команды, разделяющие ответственность за безопасность

• Архитектура, предназначенная для защиты, но при этом сохраняющая гибкость

• Надежная основа безопасности, обеспечивающая постоянное соблюдение всех требований

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

Основные рекомендации для технологических лидеров 

• Начните с понимания склонности бизнеса к риску, а не только с технического контроля

• Приведите показатели безопасности в соответствие с бизнес‑результатами, чтобы получать значимую информацию

• Обеспечьте наличие платформ и шаблонов безопасности, которые упростят процесс безопасной разработки

• Измерьте, что действительно важно, связав метрики безопасности с их влиянием на бизнес

• Инвестируйте в безопасность и формируйте культуру, которая охватывает всю организацию

• Создавайте условия для безопасного развития, используя автоматические комплаенс и верификацию

• Регулярно делитесь информацией и масштабируйте успешные подходы к обеспечению безопасности

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

Призыв к действию: начинаем трансформацию 

8. Оцените текущую степень зрелости вашей интеграции в систему безопасности

9. Определите наиболее актуальные возможности для улучшения безопасности

10. Создайте альянс лидеров бизнеса, технологий и безопасности

11. Определите область с высокой отдачей для первоочередного внимания

12. Установите четкие показатели, чтобы измерить прогресс в области безопасности.

13. Активно делитесь успехами и новыми знаниями

14. Распространяйте проверенные шаблоны в масштабах всей организации

15. Не забывайте о постоянной работе над улучшением безопасности

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

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

---

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

• 14 апреля. Почему ваши оценки проекта всегда ошибочны

Больше открытых уроков по разработке и управлению — в календаре мероприятий.