Если вы возглавляете направление безопасности в финансовом институте или ИКТ-поставщике услуг в ЕС, Закон оцифровой операционной устойчивости (DORA) уже меняет ваш график, ваш бюджет и те вопросы, которые задает совет директоров. Он также должен изменить то, как вы подходите к своему программному обеспечению. Безопасность приложений для соответствия требованиям DORA — это не отдельный проект, который можно передать команде разработчиков. Это непрерывная дисциплина на основе доказательств, которая затрагивает каждую систему, каждую стороннюю зависимость и каждую строку кода, обеспечивающую работу ваших финансовых услуг, и она должна выдерживать постоянную проверку регуляторов.
Ниже представлен стратегический фреймворк для понимания того, чего DORA требует от вашей среды приложений, в чем большинство организаций терпят неудачу и как выстроить позицию, которая будет выдерживать критику со стороны Европейских надзорных органов и, что еще важнее, суровую реальность.
Чего DORA на самом деле требует от вашей среды приложений
Закон оцифровой операционной устойчивости вступил в полную силу в январе 2025 года, и его сфера применения шире, чем многие руководители предполагали изначально. DORA регулирует не только ваш план реагирования на инциденты или документацию по непрерывности бизнеса. Он напрямую затрагивает техническую основу создания, обслуживания и тестирования ваших приложений.
Статья 26 DORA требует, чтобы определенные финансовые организации проводили тестирование на проникновение под руководством угроз (TLPT) по меньшей мере раз в три года, охватывая критически важные или важные функции в действующих производственных системах. Статья 24 предписывает проведение регулярных оценок уязвимостей и тестирования на устойчивость с процедурами приоритизации, классификации и устранения проблем, выявляемых в ходе таких тестов. Отдельные требования к управлению уязвимостями и исправлениями прописаны в Регулятивных технических стандартах в соответствии со статьей 9(2) DORA. Регламент требует, чтобы организации поддерживали комплексные фреймворки управления ИКТ-рисками, документировали технические уязвимости и демонстрировали, что выявленные риски устраняются, а не просто фиксируются.
Европейское банковское ведомство (EBA), Европейское управление по надзору за рынком ценных бумаг (ESMA) и European Insurance and Occupational Pensions Authority (EIOPA) совместно разработали регулятивные технические стандарты (RTS), которые определяют уровень детализации, ожидаемый регуляторами. Когда надзорные органы проверяют ваш фреймворк ИКТ-рисков, они ищут свидетельства систематического процесса: вы выявили уязвимости, оценили их степень серьезности и влияние на бизнес, устранили их в заданные сроки и можете доказать это документально.
Это не безопасность приложений в традиционном понимании. Это управление рисками приложений, и здесь есть важное различие.
Разница между сканированием и управлением рисками
У большинства финансовых институтов внедрено сканирование уязвимостей. У многих оно интегрировано в CI/CD-пайплайны. Некоторые проводят квартальные тесты на проникновение. Но сканирование — это действие. Управление рисками — это программа. И в рамках DORA регуляторы оценивают программы, а не отдельные действия.
Эта разница проявляется в вопросах, которые задает проверяющий. Не просто «сканируете ли вы свои приложения?», а: Как вы определяете приоритеты того, что нужно исправить в первую очередь? Каково ваше соглашение об уровне услуг (SLA) для критических уязвимостей в производственных системах? Как вы отслеживаете скорость устранения уязвимостей во всем портфеле? Какова ваша позиция в отношении рисков стороннего ПО? Как вы гарантируете, что разработка с помощью ИИ не привносит в вашу кодовую базу новые классы уязвимостей, а если привносит, то как они устраняются?
Эти вопросы требуют ответов, которые ни один отчет сканера уязвимостей не может предоставить сам по себе. Они требуют зрелой практики управления рисками приложений: такой практики, которая непрерывно выявляет, расставляет приоритеты, устраняет и документирует риски программного обеспечения в больших масштабах, обладая структурами управления, способными доказать это регуляторам.
Veracode является мировым лидером в области управления рисками приложений, сотрудничая с некоторыми из крупнейших и наиболее регулируемых финансовых институтов мира. Разница, которую мы наблюдали раз за разом, заключается в том, что организации, рассматривающие AppSec как дисциплину управления рисками, проходят проверки регуляторов гораздо успешнее тех, кто относится к этому как к функции разработки, генерирующей отчеты сканирования.
Текущее состояние рисков программного обеспечения в финансовых услугах
Прежде чем наметить план решения, стоит честно оценить исходную точку, поскольку отраслевые данные отрезвляют.
Согласно Отчету о состоянии безопасности программного обеспечения Veracode за 2026 год, в рамках которого было проанализировано 1,6 миллиона приложений и 141 миллион уязвимостей, 60% организаций имеют критический долг по безопасности — серьезные, эксплуатируемые недоработки, которые остаются неисправными более года. Это на 20% больше по сравнению с предыдущим годом.
Вдумайтесь в это в контексте требований DORA. Регламент требует от вас демонстрации непрерывного управления ИКТ-уязвимостями. Если 60% организаций имеют критические, эксплуатируемые недоработки, которые не устраняются уже больше года, значительная часть подпадающих под DORA финансовых институтов несет регуляторную ответственность, которую они, возможно, еще не до конца осознали.
Данные об утечках усиливают это беспокойство. 2026 Verizon Data Breach Investigations Report выяснила, что эксплуатация уязвимостей ПО теперь впервые за 19-летнюю историю отчета DBIR стала вектором начального доступа №1 для утечек, на который приходится 31% всех инцидентов по сравнению с 20% в предыдущем году. Злоумышленники решительно переключились на эксплуатацию на уровне приложений. Ваш фреймворк ИКТ-рисков по DORA должен отражать эту реальность.
Проблема стороннего кода, которую DORA заставляет вас брать на себя
Одним из наиболее важных и при этом недооцениваемых аспектов DORA является подход к рискам сторонних ИКТ-поставщиков. Регламент налагает строгие требования на то, как финансовые организации управляют отношениями с критически важными ИКТ-пставщиками услуг, включая договорные обязательства в отношении безопасности, права на аудит и тестирование на устойчивость.
Но существует сопутствующий риск, который также затрагивает DORA и которому не всегда уделяется должное внимание руководства: это открытый исходный код и сторонний код, внедренный в ваши собственные приложения.
В Отчете о состоянии безопасности программного обеспечения Veracode за 2026 год обнаружено, что 66% критического долга по безопасности проистекает из стороннего кода, включая библиотеки с открытым исходным кодом. Для приложений, где компоненты с открытым исходным кодом составляют большую часть кодовой базы, это прямая зона риска по DORA. Критическая уязвимость в библиотеке с открытым исходным кодом, обрабатывающей данные транзакций, представляет собой ИКТ-риск. Ее необходимо выявлять, оценивать и устранять с той же тщательностью, что и любую другую проблему.
Анализ состава программного обеспечения (SCA) — это технический элемент контроля, который решает данную задачу. Однако непрерывный SCA, интегрированный в ваши конвейеры разработки и привязанный к вашему общему фреймворку приоритизации рисков, — это именно то, на что указывают требования DORA по непрерывному мониторингу. Точечной инвентаризации ваших зависимостей недостаточно. Вам необходимы оповещения при обнаружении новых уязвимостей в используемых библиотеках с четким рабочим процессом для оценки влияния на регулируемые функции и устранения или митигации в рамках заданных SLA.
Гипотетический сценарий, который делает это реальным
Представьте себе европейский розничный банк, использующий мобильное приложение для банкинга, которое опирается на несколько библиотек с открытым исходным кодом для аутентификации, сериализации данных и взаимодействия с API. В библиотеке сериализации обнаруживается критическая уязвимость. Инструменты SCA банка сигнализируют об этом. Но исправление требует тестирования в трех связанных службах, а команда находится в середине спринта перед дедлайном выпуска продукта. Находка откладывается до «следующего релиза».
Шесть недель спустя, во время проверки уязвимостей, предписанной DORA, надзорный представитель банка запрашивает документацию о том, как были устранены выявленные уязвимости в производственных системах. Тикет все еще открыт. Библиотека по-прежнему уязвима. Ответ «это запланировано на следующий спринт» не является удовлетворительным ответом для регулятора, проверяющего ваш подход к управлению ИКТ-рисками. Или, что еще хуже, это совсем не волнует злоумышленников, ищущих путь для эксплуатации вашей системы.
В соответствии с DORA наличие процесса, который находит уязвимости, но не демонстрирует своевременное и приоритизированное по рискам устранение, по сути ничем не отличается от отсутствия какого-либо процесса вообще.
Создание программы безопасности приложений для соответствия DORA, которая действительно работает
Вот концептуальная основа исполнительного уровня. Она призвана предоставить вам стратегическую архитектуру для руководства внедрением и ответов на вопросы, которые зададут регуляторы.
1. Определите критически важные ИКТ-системы и сопоставьте их риски на уровне приложений
Начните с регуляторной классификации. DORA требует от финансовых организаций идентифицировать свои критические и важные функции, а также поддерживающие их ИКТ-системы. Для каждой из этих систем вам необходим актуальный профиль рисков приложений: какие уязвимости существуют? Каков возраст самых старых критических находок? От каких сторонних библиотек она зависит и есть ли в них известные уязвимости?
Это упражнение по маппингу является как требованием соответствия DORA, так и основой для интеллектуальной приоритизации рисков. Вы не можете разумно расставить приоритеты устранения, не зная, какие приложения несут наибольший регуляторный и операционный риск.
2. Внедрите непрерывное тестирование в рамках жизненного цикла разработки ПО (SDLC)
Нормативные технические стандарты DORA требуют автоматизированного сканирования уязвимостей ИКТ-активов, поддерживающих критические или важные функции, по крайней мере еженедельно. Такая периодичность делает циклы тестирования раз в год не соответствующими требованиям сами по себе. Встройте непрерывное тестирование безопасности в свой жизненный цикл разработки:
- SAST в конвейере CI/CD — выявляет уязвимости по мере написания кода, до того как он попадает в продакшн
- Непрерывно работающий SCA — отслеживает риски сторонних библиотек в режиме реального времени во всех производственных средах и средах разработки
- DAST для работающих приложений — выявляет уязвимости среды выполнения и конфигурации, которые пропускает статический анализ
- TLPT (тестирование на проникновение на основе угроз) — Статья 26 DORA требует, чтобы определенные финансовые организации проводили TLPT по крайней мере раз в три года, охватывая критические или важные функции в реальных производственных системах.
Последовательность имеет значение. SAST и SCA выявляют основную часть проблем рано и с минимальными затратами. DAST и TLPT проверяют остаточный риск в продакшне. Вместе они удовлетворяют ожиданиям DORA в отношении многоуровневого тестирования на устойчивость.
3. Создайте программу устранения на основе рисков с задокументированными Соглашениями об уровне услуг (SLA)
Здесь у большинства организаций наблюдается самый большой разрыв между тем, что они делают, и тем, что DORA требует от них продемонстрировать. Задокументируйте вашу политику SLA в отношении уязвимостей: как быстро должны быть устранены критические находки в критических ИКТ-системах? Каков путь эскалации при угрозе нарушения SLA? Кто несет ответственность?
DORA требует, чтобы вы определяли и документировали собственные SLA по устранению рисков с процедурами эскалации. Отраслевой консенсус предлагает цели в 72 часа или менее (и сокращение сроков по мере того, как злоумышленники ускоряются благодаря ИИ) для критических эксплуатируемых уязвимостей в продакшне и 7–14 дней для высокой степени серьезности. Ваши конкретные SLA должны быть откалиброваны под ваш профиль рисков и критичность активов.
Отслеживайте скорость устранения и сообщайте о ней наверх. Вашему совету директоров и высшему руководству необходима прозрачность в отношении того, улучшается или ухудшается ваша программа устранения... особенно учитывая, что медианное время полного устранения уязвимостей в масштабах отрасли возросло до 43 дней.
4. Установите систему управления, связывающую AppSec с отчетностью по ИКТ-рискам
DORA требует, чтобы отчеты об управлении ИКТ-рисками доходили до руководящего органа. Это означает, что данные безопасности ваших приложений (например, уровни вашего долга по безопасности, скорость устранения и риски стороннего кода) должны поступать в вашу структуру отчетности по ИКТ-рискам в форме, с которой могут работать руководители и члены совета директоров.
Создайте панели мониторинга и отчетность, которые переводят технические данные об уязвимостях на язык бизнес-рисков: сколько критических систем имеют нерешенные проблемы высокой степени серьезности, какова тенденция и каков прогнозируемый график устранения. Это то, о чем спросят регуляторы. Создайте это до того, как они спросят.
Превращение давления регуляторов в конкурентное преимущество
DORA — это обязательное требование соответствия, но организации, которые строят по-настоящему зрелые программы управления рисками приложений, не просто ставят галочку; они выходят из этого процесса с позицией в отношении программного обеспечения, которая является принципиально более устойчивой. У них меньше инцидентов с нарушением безопасности. Они восстанавливаются быстрее. Они тратят меньше на реагирование на инциденты и устранение последствий нарушений регуляторных требований. И они могут продемонстрировать клиентам, партнерам и регуляторам, что цифровая оперативная устойчивость — это задокументированная, измеримая реальность.
Если вы хотите углубиться в то, как спроектировать эту позицию таким образом, чтобы она соответствовала требованиям DORA и была готова к аудиту, официальный документ Veracode «Стратегия AppSec на первом месте в плане соответствия» (Compliance First AppSec Strategy) рассматривает ключевые решения по дизайну программ, которые имеют наибольшее значение в рамках таких стандартов, как DORA — от периодичности тестирования до управления процессом устранения и аудиторской документации.
Юридический отказ от ответственности
Информация, представленная в этой статье, предназначена исключительно для общих информационных и образовательных целей. Она не является юридической консультацией и не должна рассматриваться как таковая. Требования по соблюдению нормативных требований и комплаенсу различаются в зависимости от организации, юрисдикции и контекста. Организациям следует проконсультироваться с квалифицированными юристами и специалистами по комплаенсу, чтобы понять свои конкретные нормативные обязательства и выполнить их. Veracode не делает никаких заявлений или гарантий относительно полноты, точности или применимости информации, содержащейся в этом посте. Нормативно-правовая база, обсуждаемая в этой статье, может изменяться; читателям следует обращаться к официальным регулирующим органам и юридическим ресурсам для получения самых актуальных требований.
.png)
