Chainguard предложила финсектору модернизировать цепочку поставки ПО
Chainguard предложила банкам, страховым и управляющим компаниям начать модернизацию не с переписывания приложений, а с цепочки поставки ПО: базовых контейнерных образов, библиотек с открытым исходным кодом и средств сборки. В статье компании утверждается, что эксплуатация уязвимостей впервые стала главным вектором первоначального доступа при инцидентах в финансовом секторе, опередив фишинг, а более половины поставщиков отрасли имеют хотя бы одну CVE высокой критичности.
Почему старый подход к отложенным исправлениям меняется
Финансовые организации традиционно осторожны с обновлениями. У них накоплена многолетняя инфраструктура, действуют требования регулирования, а простой систем, обеспечивающих расчёты и платежи, может быть неприемлем. Поэтому обновление зависимостей, смена базового образа или миграция нередко требуют регрессионного тестирования, согласований и попадают в календарь заморозки изменений.
В таком режиме известная уязвимость могла получить исключение, компенсирующий контроль и отложенный срок исправления. Chainguard считает, что предпосылки этого решения изменились: frontier-модели, включая упомянутую Mythos, способны читать код, находить скрытые слабости и объединять их в цепочки быстрее, чем команды успевают исследовать и исправлять проблемы.
Компания делает вывод, что разрыв между публично известной и практически эксплуатируемой уязвимостью сокращается. Особенно это касается компонентов под приложением: уязвимых базовых образов, библиотек из публичных реестров без подтверждённого происхождения и неинвентаризированных инструментов сборки.
Модернизация без немедленной миграции приложений
Под модернизацией приложений обычно понимают рефакторинг монолита, обновление среды выполнения, перенос слоя данных и повторное тестирование зависимых систем. Это многолетняя и дорогостоящая программа с операционными рисками. Chainguard предлагает отделить её от задачи обновления того, из чего создаётся приложение.
Подход компании строится на минимальных усиленных контейнерных образах и библиотеках с открытым исходным кодом, которые непрерывно пересобираются. По её описанию, меньшее число компонентов должно уменьшить объём сканирования, триажа и поверхность атаки. Для программ, которые пока нельзя обновить, Chainguard заявляет о бэкпортировании исправлений безопасности в используемые организациями версии языковых сред и фреймворков.
Это позволяет сохранять совместимость, не меняя график миграции. Одновременно артефакты сопровождаются подписанными Software Bills of Materials, или SBOM, и проверяемой информацией о происхождении. Такие сведения помогают отвечать на вопросы аудита о том, что именно запущено, откуда компонент получен и как он поддерживается.
Роль платформенной команды
Крупные финансовые организации часто поддерживают внутренние программы golden image для сотен команд разработки. Chainguard предлагает платформенным командам заменить исходные артефакты на усиленные, затем один раз распространить их через уже используемые реестры и конвейеры. В этой модели исправление наследуется приложениями, а не требует от каждой команды отдельно исследовать и пересобирать базовые образы.
Для бизнеса практический вывод состоит в том, что работу с цепочкой поставки можно начать ограниченно: с одной платформенной команды и нескольких образов. Это не отменяет планов по модернизации приложений, но позволяет снизить зависимость от постоянного ручного разбора CVE и улучшить контроль над происхождением компонентов до завершения крупных миграций.