Всеки лидер по сигурността в банка, застрахователна компания или дружество за управление на активи е водил подобен разговор: Екипът по сигурност иска да премахне определен клас уязвимости. Инженерният екип обяснява какво би струвало да се обнови платформата, в която те съществуват. Някой изчислява разходите за регресионно тестване. Друг повдига въпроса за календара с замразяване на промените. В крайна сметка констатацията получава изключение, компенсираща мярка и дата след 18 месеца в плана за изпълнение.

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

Затова инстинктът да се придържаме към статуквото е бил разумен. Проблемът е, че този инстинкт сега се прилага към грешния проблем.

Поддържането на списък с необработени уязвимости вече не е „нормално“

В продължение на години приемането на натрупани познати уязвимости беше чест компромис, който организациите за финансови услуги правеха в името на стабилността. Уязвимостите бяха известни, но неактивни. Освен това експлоатацията изискваше умения, време, разходи и стимул. Шансът дадена известна уязвимост (CVE) в остаряло приложение да бъде използвана като оръжие срещу вас преди следващото планирано обновяване беше достатъчно малък, за да бъде просто отбелязан и подминат.

Усъвършенстваните AI модели драстично промениха тези изчисления. Системи като Mythos могат да четат код, да откриват скрити слабости и да ги свързват във верига по-бързо, отколкото хората могат да ги разследват и да инсталират корекции за сигурност. Разликата между „публично известни“ и „практически експлоатируеми“ уязвимости бързо изчезва, и това се случва точно там, където финансовите институции са трупали отложен риск: във веригата за доставка на софтуер.

За първи път в историята експлоатацията на уязвимости изпревари фишинга като основен вектор за първоначален достъп при пробиви във финансовите услуги. Освен това повече от половината доставчици на финансови услуги поддържат поне една уязвимост от висока степен на опасност (CVE). За регулирана институция компрометиран пакет означава оперативен инцидент, регулаторни разговори и загуба на доверие от страна на клиентите.

Какво означава това на практика: натрупаните уязвимости никога не са били статични, но предположенията, използвани за оправдаване на тяхното поддържане, бяха такива. Изключение, одобрено преди 18 месеца, се базира на остарял модел на заплахите.

Разликата между приложенията и веригата за доставка на софтуер

Когато екипът по сигурност каже „трябва да модернизираме“, техническите лидери чуват модернизация на приложенията: рефакториране на монолита, обновяване на средата за изпълнение, мигриране на слоя с данни и повторно тестване на всичко по веригата. Това е неколкогодишна, капиталноемка програма с участието на множество екипи и реален оперативен риск. Техническите лидери често се съпротивляват на подобна промяна — и вероятно имат право да го правят.

Но рискът, който въвеждат усъвършенстваните AI модели, не се крие основно в кода на приложението. Той се намира във веригата за доставка на софтуер под него: базови изолирани изображения с множество уязвимости, библиотеки с отворен код, изтеглени от публични регистри без доказан произход, и инструменти за компилиране, които никога не са били инвентаризирани правилно. Входният ресурс (input) за приложението е станал уязвим.

А входните ресурси могат да бъдат променени, без да се пренаписва това, което ги използва.

Актуализирането на тези входни ресурси е по-разумната „модернизация“, с която много организации за финансови услуги се сблъскват в момента. Модернизирането на вашата верига за доставка на софтуер не изисква същото ниво на инвестиции като модернизирането на вашите приложения. Можете да промените компонентите, от които изграждате, много преди да промените това, което изграждате.

Как изглежда това без миграция

Подходът на Chainguard е изграден върху защитата на компонентите, от които изграждате. Защитените, минималистични контейнерни изображения и библиотеки с отворен код се прекомпилират непрекъснато, така че предотвратимите уязвимости никога да не навлизат в средата. По-малкият брой компоненти означава по-малко елементи за сканиране, по-малко за анализ и по-малка повърхност за атака по дизайн, вместо чрез последващо отстраняване на уязвимости.

За софтуер, който все още не е готов за пълно обновяване, Chainguard пренася корекции за сигурност (backporting) към версиите, които институциите използват днес. Екип, работещ със по-стара версия на среда за изпълнение или рамка (framework), получава коригирани и доверени артефакти за тази версия. Съвместимостта се запазва, а планът за миграция следва своя собствен график.

И в двата случая екипите, използващи по-стари версии, намаляват излагането си на уязвимости.

За платформените екипи оперативната промяна е по-малка от очакваното. Повечето големи финансови институции вече поддържат вътрешна програма за одобрени базови изображения (golden images), за да стандартизират основата за стотици екипи по разработка. Поддръжката на тези изображения обаче е бавна и скъпа.

Но когато платформените екипи заменят източника на тези изображения, те огледално дублират защитените артефакти еднократно и ги разпространяват като одобрени градивни блокове чрез регистрите и конвейерите (pipelines), които екипите вече използват. В резултат на това управлението на уязвимостите се измества от това всеки екип самостоятелно да проучва и прекомпилира базови изображения към поддържането на единен доверен набор от платформения екип. Екипите по разработка получават готови корекции, вместо сами да вършат тази работа.

Освен това всеки артефакт включва подписани спецификации на софтуерните компоненти (Software Bills of Materials - SBOM) и верифицируем произход, което позволява на екипите да отговарят на чести одиторски въпроси като „Какво работи в момента?“, „Откъде е дошло?“ или „Как се поддържа?“. Отговорите на тези въпроси позволяват на платформените екипи и екипите по сигурност да се върнат към изграждането и поддръжката на основния си бизнес за своите клиенти.

Скритите разходи при липса на модернизация

Преформулирането на модернизацията по отношение на веригата за доставка на софтуер е важно, тъй като „запазването на статуквото“ никога не е било вариант с нулев риск. Това просто е бил вариантът с разходи, разпределени толкова широко, че да останат извън регистъра на рисковете.

Капацитетът на инженерния екип, изразходван в повтарящ се анализ на CVE уязвимости вместо в работа по продуктовия план, представлява реален разход. Изпълнението на спешни процедури за реагиране всеки път, когато нова кампания атакува широко използван пакет, отнема огромно количество време и ресурси. Констатациите от одити, които стават все по-рудни за отстраняване с всеки цикъл, водят до изтощение и забавят организацията. И целият процес по модернизация може да спре, ако екипът ви е твърде зает с инсталиране на корекции за сигурност, за да внедрява нови системи. Всичкото това забавяне означава, че инженерният ви екип не се фокусира върху това, за което съществува: създаване на функционалности, които генерират приходи.

За разлика от тези разходи, приемането на сигурна софтуерна основа е сравнително малка, обратима и добре дефинирана промяна. Тя засяга процеса на компилиране, а не бизнес логиката. Може да започне с един платформен екип и няколко изображения. Платформените екипи могат да подобрят софтуерната основа централизирано и да внедрят тези доверени артефакти чрез регистрите и конвейерите, които останалите екипи вече използват.

Графикът остава във вашите ръце

Най-важното нещо, което трябва да се разбере за модернизацията във финансовите организации, е че ползите за сигурността се виждат по време на самия процес, а не само когато той е напълно „приключил“. Можете значително да подобрите сигурността си, докато продължавате безопасно цялостната си модернизация, като започнете от веригата за доставка на софтуер. С течение на времето, когато все по-голяма част от инфраструктурата се изгражда върху доверени настройки по подразбиране, цялостното ви ниво на сигурност се променя от непрекъснато реагиране на уязвимости към предотвратяване на тяхното прихващане още в самото начало. Ето какво означава сигурност по подразбиране (secure-by-default) на практика.

Научете повече за това как Chainguard може да ви помогне да защитите веригата за доставка на софтуер във вашата финансова организация днес.

Забележка: Тази статия е експертно написана с принос от Мат Стед, мениджър продуктов маркетинг в Chainguard