Банки, страховщики и управляющие активами десятилетиями ставили стабильность выше скорости обновлений. Причина вполне материальна: накопленная инфраструктура, требования регуляторов и приложения, для которых даже один час простоя неприемлем. Системы проводят сделки, переводят деньги и обслуживают другие критические финансовые операции. Замена зависимости, базового образа или миграция способны нарушить этот механизм, поэтому минимизация изменений долго считалась нормальным способом управления риском.
Типичный спор повторяется из года в год. Служба безопасности требует устранить класс уязвимостей, инженеры перечисляют нужные обновления платформы, затем подсчитывается стоимость регрессионного тестирования. В разговоре появляется календарь заморозки изменений, после чего находке назначают исключение, компенсирующий контроль и срок исправления через 18 месяцев. У каждой стороны есть разумные доводы. Проблема в другом: старое понимание стабильности заставляет финансовую организацию сохранять уязвимости, которые попадают в системы через цепочку поставок программного обеспечения.
Раньше задолженность по исправлению CVE, то есть Common Vulnerability and Exposure, воспринималась как пассивный риск. Предполагалось, что известная, но не используемая на практике брешь требует от нападающего редких навыков, времени, денег и сильной мотивации. Передовые модели ИИ меняют этот расчёт. Системы наподобие Mythos способны читать код, находить спящие слабые места и соединять несколько дефектов в рабочую цепочку атаки быстрее, чем защитники успевают провести расследование и выпустить исправление. Промежуток между публикацией уязвимости и её практической эксплуатацией сокращается. Исключение, одобренное 18 месяцев назад, вполне может опираться на уже устаревшую модель угроз.
Для финансового сектора перемена особенно неприятна. Впервые за весь период наблюдений эксплуатация уязвимостей обошла фишинг и стала ведущим вектором первоначального доступа. Более половины поставщиков финансовых услуг имеют хотя бы одну CVE высокой серьёзности. Компрометация одного пакета может одновременно вызвать операционный инцидент, проверку или тяжёлый разговор с регулятором и потерю доверия клиентов. Задолженность по уязвимостям никогда не была неподвижной: неподвижными оставались допущения, которыми оправдывали отсрочку.
Требование «нужно модернизироваться» инженеры нередко понимают как предложение переписать монолит, обновить среду выполнения, перенести слой данных и заново проверить все зависимые системы. Такая модернизация приложения занимает несколько лет, требует участия многих команд, крупных капитальных затрат и несёт заметный операционный риск. Но значительная часть новой угрозы находится ниже бизнес-логики: в базовых образах с десятками дефектов, библиотеках с открытым исходным кодом, загруженных из публичных реестров без подтверждённого происхождения, а также в инструментах сборки, которые никто толком не инвентаризировал. Входные компоненты приложения часто можно заменить без переписывания самого приложения.
Chainguard предлагает начинать именно с этих компонентов. Компания выпускает защищённые минимальные контейнерные образы и непрерывно пересобираемые библиотеки с открытым исходным кодом. Чем меньше пакетов внутри артефакта, тем меньше объём сканирования, разбора предупреждений и поверхность атаки. Безопасность закладывается при сборке, а не добавляется после обнаружения очередной проблемы. Если немедленное обновление невозможно, исправления переносятся обратно в используемые версии языковых сред выполнения и фреймворков. Организация получает исправленный доверенный артефакт, сохраняет совместимость и не обязана ускорять общий план миграции.
У большинства крупных финансовых учреждений уже работают внутренние программы «золотых образов», которыми пользуются сотни команд разработки приложений. Самостоятельное обслуживание этих образов обходится дорого и движется медленно. Вместо переделки каждого сервиса платформенная команда может один раз получить защищённые артефакты, зеркалировать их, назначить разрешёнными строительными блоками и распространить через действующие реестры, конвейеры сборки и привычные рабочие процессы разработки. Тогда сотни команд наследуют исправление автоматически. Исследование, пересборка и сопровождение базовых образов перестают быть отдельной обязанностью каждого проекта.
Каждый такой артефакт снабжается подписанной спецификацией состава программного обеспечения, Software Bill of Materials (SBOM), и проверяемыми сведениями о происхождении. Это даёт прямые ответы на аудиторские вопросы: «Что запущено?», «Откуда оно получено?» и «Как оно сопровождается?». Подпись и проверяемое происхождение не заменяют контроль эксплуатации, зато позволяют установить состав конкретной сборки и источник каждого компонента. Службы безопасности и платформенные команды тратят меньше времени на восстановление истории пакета и больше на поддержку основных клиентских сервисов.
Сохранение прежнего порядка тоже стоит денег, хотя расходы размазаны между подразделениями и редко целиком попадают в реестр рисков. Инженеры снова и снова сортируют CVE вместо выполнения продуктовой дорожной карты. Новая кампания атак на популярный пакет запускает экстренный цикл реагирования и отнимает рабочее время у множества сотрудников. Аудиторские замечания с каждым циклом закрываются тяжелее, люди устают, согласования затягиваются. Команды заняты латанием старых систем и не успевают внедрить замену. В итоге меньше ресурсов остаётся на функции, ради которых бизнес содержит разработку: выпуск возможностей, приносящих выручку.
Модернизация цепочки поставок имеет ограниченный и обратимый масштаб: она меняет фундамент сборки, не затрагивая бизнес-логику приложения. Начать можно с одной платформенной команды и нескольких образов, не объявляя многолетнюю миграцию всего технологического хозяйства. Старые исключения следует пересмотреть, базовые образы, библиотеки, языковые среды, фреймворки и инструменты сборки перевести на минимальные непрерывно обновляемые артефакты, а подписанные SBOM и проверяемое происхождение сделать обязательными. Финансовая организация при этом сохраняет собственный график крупных обновлений. По мере распространения доверенных компонентов защита переходит от постоянного исправления унаследованных дефектов к состоянию «безопасно по умолчанию», когда большинство таких уязвимостей попросту не попадает в инфраструктуру. Подход Chainguard позволяет начать эту работу уже сегодня.
Изображение носит иллюстративный характер
Типичный спор повторяется из года в год. Служба безопасности требует устранить класс уязвимостей, инженеры перечисляют нужные обновления платформы, затем подсчитывается стоимость регрессионного тестирования. В разговоре появляется календарь заморозки изменений, после чего находке назначают исключение, компенсирующий контроль и срок исправления через 18 месяцев. У каждой стороны есть разумные доводы. Проблема в другом: старое понимание стабильности заставляет финансовую организацию сохранять уязвимости, которые попадают в системы через цепочку поставок программного обеспечения.
Раньше задолженность по исправлению CVE, то есть Common Vulnerability and Exposure, воспринималась как пассивный риск. Предполагалось, что известная, но не используемая на практике брешь требует от нападающего редких навыков, времени, денег и сильной мотивации. Передовые модели ИИ меняют этот расчёт. Системы наподобие Mythos способны читать код, находить спящие слабые места и соединять несколько дефектов в рабочую цепочку атаки быстрее, чем защитники успевают провести расследование и выпустить исправление. Промежуток между публикацией уязвимости и её практической эксплуатацией сокращается. Исключение, одобренное 18 месяцев назад, вполне может опираться на уже устаревшую модель угроз.
Для финансового сектора перемена особенно неприятна. Впервые за весь период наблюдений эксплуатация уязвимостей обошла фишинг и стала ведущим вектором первоначального доступа. Более половины поставщиков финансовых услуг имеют хотя бы одну CVE высокой серьёзности. Компрометация одного пакета может одновременно вызвать операционный инцидент, проверку или тяжёлый разговор с регулятором и потерю доверия клиентов. Задолженность по уязвимостям никогда не была неподвижной: неподвижными оставались допущения, которыми оправдывали отсрочку.
Требование «нужно модернизироваться» инженеры нередко понимают как предложение переписать монолит, обновить среду выполнения, перенести слой данных и заново проверить все зависимые системы. Такая модернизация приложения занимает несколько лет, требует участия многих команд, крупных капитальных затрат и несёт заметный операционный риск. Но значительная часть новой угрозы находится ниже бизнес-логики: в базовых образах с десятками дефектов, библиотеках с открытым исходным кодом, загруженных из публичных реестров без подтверждённого происхождения, а также в инструментах сборки, которые никто толком не инвентаризировал. Входные компоненты приложения часто можно заменить без переписывания самого приложения.
Chainguard предлагает начинать именно с этих компонентов. Компания выпускает защищённые минимальные контейнерные образы и непрерывно пересобираемые библиотеки с открытым исходным кодом. Чем меньше пакетов внутри артефакта, тем меньше объём сканирования, разбора предупреждений и поверхность атаки. Безопасность закладывается при сборке, а не добавляется после обнаружения очередной проблемы. Если немедленное обновление невозможно, исправления переносятся обратно в используемые версии языковых сред выполнения и фреймворков. Организация получает исправленный доверенный артефакт, сохраняет совместимость и не обязана ускорять общий план миграции.
У большинства крупных финансовых учреждений уже работают внутренние программы «золотых образов», которыми пользуются сотни команд разработки приложений. Самостоятельное обслуживание этих образов обходится дорого и движется медленно. Вместо переделки каждого сервиса платформенная команда может один раз получить защищённые артефакты, зеркалировать их, назначить разрешёнными строительными блоками и распространить через действующие реестры, конвейеры сборки и привычные рабочие процессы разработки. Тогда сотни команд наследуют исправление автоматически. Исследование, пересборка и сопровождение базовых образов перестают быть отдельной обязанностью каждого проекта.
Каждый такой артефакт снабжается подписанной спецификацией состава программного обеспечения, Software Bill of Materials (SBOM), и проверяемыми сведениями о происхождении. Это даёт прямые ответы на аудиторские вопросы: «Что запущено?», «Откуда оно получено?» и «Как оно сопровождается?». Подпись и проверяемое происхождение не заменяют контроль эксплуатации, зато позволяют установить состав конкретной сборки и источник каждого компонента. Службы безопасности и платформенные команды тратят меньше времени на восстановление истории пакета и больше на поддержку основных клиентских сервисов.
Сохранение прежнего порядка тоже стоит денег, хотя расходы размазаны между подразделениями и редко целиком попадают в реестр рисков. Инженеры снова и снова сортируют CVE вместо выполнения продуктовой дорожной карты. Новая кампания атак на популярный пакет запускает экстренный цикл реагирования и отнимает рабочее время у множества сотрудников. Аудиторские замечания с каждым циклом закрываются тяжелее, люди устают, согласования затягиваются. Команды заняты латанием старых систем и не успевают внедрить замену. В итоге меньше ресурсов остаётся на функции, ради которых бизнес содержит разработку: выпуск возможностей, приносящих выручку.
Модернизация цепочки поставок имеет ограниченный и обратимый масштаб: она меняет фундамент сборки, не затрагивая бизнес-логику приложения. Начать можно с одной платформенной команды и нескольких образов, не объявляя многолетнюю миграцию всего технологического хозяйства. Старые исключения следует пересмотреть, базовые образы, библиотеки, языковые среды, фреймворки и инструменты сборки перевести на минимальные непрерывно обновляемые артефакты, а подписанные SBOM и проверяемое происхождение сделать обязательными. Финансовая организация при этом сохраняет собственный график крупных обновлений. По мере распространения доверенных компонентов защита переходит от постоянного исправления унаследованных дефектов к состоянию «безопасно по умолчанию», когда большинство таких уязвимостей попросту не попадает в инфраструктуру. Подход Chainguard позволяет начать эту работу уже сегодня.
