У четвер компанія Capital One представила VulnHunter — інструмент безпеки на базі генеративного штучного інтелекту з відкритим кодом. Цей інструмент сканує вихідний код на наявність потенційних уразливостей, моделює шлях, яким міг би скористатися зловмисник для їх експлуатації, та пропонує цільові виправлення — і все це до того, як будь-який рядок коду потрапить у продакшн. Інструмент, розроблений всередині компанії та доступний на GitHub під ліцензією Apache 2.0, є однією з найамбітніших спроб великої фінансової установи перетворити наступальні можливості ШІ на загальнодоступний ресурс для захисту.
Цей крок знаменує собою разючий філософський поворот для компанії, яка досі асоціюється, у багатьох директорах, з інцидентом безпеки 2019 року, що призвів до витоку персональних даних приблизно 106 мільйонів осіб у Сполучених Штатах і Канаді, і зрештою коштував банку штрафу в розмірі 80 мільйонів доларів від федеральних регуляторів.
Capital One не просто випускає ще один сканер уразливостей. VulnHunter впроваджує те, що компанія називає «аналізом на випередження з позиції зловмисника» (attacker-first forward analysis) — робочий процес, у якому інструмент починає з точок входу, які використовував би реальний супротивник для доступу до системи, таких як API, мережеві повідомлення або завантаження файлів. Далі він аналізує логіку програми, щоб визначити, чи існує реальний шлях експлуатації, який може обійти наявні засоби захисту коду. Традиційні сканери зазвичай працюють у зворотному порядку: вони виявляють потенційно небезпечний шаблон у коді, а потім шукають у зворотному напрямку гіпотетичного зловмисника. Цей підхід, як широко визнають фахівці з безпеки, перевантажує команди розробників величезною кількістю хибних спрацьовувань.
VulnHunter вирішує цю проблему двома інноваціями: вбудованим «механізмом фальсифікації» (falsification engine), який намагається спростувати власні знахідки ще до того, як їх побачить розробник. Після виявлення потенційної уразливості інструментом, структурований робочий процес аналізу шукає логічні прогалини, необґрунтовані припущення та умови, які б перешкоджали успішній експлуатації. Лише ті знахідки, які механізм не зміг спростувати, потрапляють до людського аналітика. І коли це відбувається, VulnHunter надає не просто сповіщення, а повне пояснення шляху експлуатації та запропоноване виправлення коду, готове до перевірки інженерною командою.
Наразі інструмент працює на моделі Anthropic Claude Opus 4.8 в середовищі Claude Code, хоча Capital One зазначає, що його архітектура потенційно може працювати з іншими фундаментальними моделями та програмними платформами.
Витік даних 2019 року, який змінив підхід Capital One до кібербезпеки
Щоб зрозуміти, чому Capital One вирішила зробити такий вагомий інструмент відкритим, необхідно згадати про наслідки минулих інцидентів.
19 липня 2019 року Capital One повідомила, що зовнішня особа — згодом ідентифікована як колишня співробітниця Amazon Web Services на ім’я Пейдж Томпсон — отримала несанкціонований доступ до імен, адрес, даних про доходи, номерів соціального страхування та пов’язаних номерів банківських рахунків кредитних карток клієнтів та заявників. Витік, який, за даними Capital One, стався 22 та 23 березня 2019 року, було виявлено лише після того, як зовнішній дослідник з безпеки повідомив про конфігураційну уразливість через програму відповідального розкриття інформації компанії 17 липня того ж року.
Масштаб збитків був значним. Постраждало приблизно 100 мільйонів осіб у Сполучених Штатах і 6 мільйонів у Канаді. Було скомпрометовано близько 140 000 номерів соціального страхування, приблизно 80 000 номерів пов’язаних банківських рахунків та близько 1 мільйона канадських номерів соціального страхування. ФБР заарештувало Томпсон, і влада заявила, що дані, ймовірно, були відновлені без доказів шахрайства. Однак репутаційні та регуляторні втрати були величезними.
У серпні 2020 року Управління контролера грошового обігу (Office of the Comptroller of the Currency, OCC) оштрафувало Capital One на 80 мільйонів доларів, встановивши, що банк не зміг належним чином ідентифікувати та управляти ризиками під час міграції значних технологічних операцій до хмари. Як повідомляло Reuters у той час, наказ OCC посилався на недостатні засоби мережевої безпеки, неналежні заходи запобігання втраті даних та раду директорів, яка не змогла притягнути керівництво до відповідальності, коли внутрішній аудит виявив проблеми. OCC також наказало Capital One докорінно перебудувати свої операції та подати нові плани кібербезпеки на розгляд регулятора.
Цей інцидент став галузевим кейс-стаді про небезпеку швидкого впровадження нових технологій. Як повідомляв CyberScoop у липні 2019 року, керівник відділу кібербезпеки конкуруючої фінансової компанії зауважив, що витік «може бути наслідком спроб занадто багатьох нових речей та їх поспішного впровадження». Генеральний директор Capital One Річард Д. Феррбенк визнав серйозність моменту. «Хоча я вдячний, що винну особу спіймано, я глибоко шкодую про те, що сталося», — заявив Феррбенк. «Я щиро вибачаюся за зрозуміле занепокоєння, яке цей інцидент може спричинити постраждалим, і я зобов’язуюсь виправити ситуацію».
Як Capital One відновила свою репутацію в галузі безпеки завдяки інвестиціям у відкритий код
Те, що послідувало, було не відступом від технологій, а подвоєнням зусиль — з безпекою, що явно перебувала в центрі уваги.
Capital One оголосила себе компанією «спочатку відкритий код» (open-source first) у 2015 році як частину ширшої технологічної трансформації, що розпочалася понад десятиліття тому. Після витоку даних компанія прискорила свої інвестиції у безпеку ланцюжка постачання програмного забезпечення, управління відкритим кодом та захист на базі ШІ. У серпні 2022 року Capital One приєдналася до Open Source Security Foundation (OpenSSF) як преміум-член, здобувши місце в керівному органі організації. Кріс Німс, тодішній віце-президент з інженерії хмарних рішень та продуктивності, назвав цей крок природним продовженням операційної філософії компанії. «Як компанія, що суворо регулюється, ми маємо досвід управління відповідністю та управлінням, і виступаємо за стандартизацію, автоматизацію та співпрацю», — заявив Німс в оголошенні OpenSSF.
За цим публічним зобов’язанням стояла значна операційна база. Офіс програм відкритого коду Capital One, який зараз перебуває у своїй третій ітерації, керує використанням відкритого коду, внесками та побудовою спільноти по всій компанії. За даними самої компанії, вона випустила понад 25 проєктів з відкритим кодом та зробила понад 2000 внесків приблизно до 135 зовнішніх проєктів з відкритим кодом. Ці зусилля охоплюють не лише залежності коду, а й весь життєвий цикл розробки програмного забезпечення — інструменти DevSecOps, інфраструктуру та колаборативні середовища, як внутрішні, так і зовнішні, що формують спосіб створення та випуску програмного забезпечення.
Нурін Д’Соуза, директор, який очолює OSPO Capital One, публічно розповідала про філософію, що лежить в основі цієї роботи. На конференції cdCon 2022 Д’Соуза описала «загальнокорпоративну культуру з вбудованою безпекою», яка дозволяє розробникам зосереджуватися на інноваціях, а не на рутинних завданнях з обслуговування, як повідомлялося в SD Times. Статут OSPO наголошує на трьох стовпах: стандартизація процесів відкритого коду, автоматизація політик безпеки протягом усього конвеєра постачання та сталість екосистеми через внески у фонди та проєкти, від яких залежить компанія.
VulnHunter є найвагомішим продуктом цих багаторічних зусиль і найчіткішим сигналом про те, що Capital One розглядає співпрацю у сфері відкритого коду не як благодійність, а як конкурентну стратегію безпеки. Компанія стверджує, що сучасні ланцюжки постачання програмного забезпечення настільки тісно взаємопов’язані, що одна уразливість у широко використовуваному компоненті з відкритим кодом може каскадно вразити тисячі підприємств одночасно. Власні засоби захисту, якими б складними вони не були, не можуть вирішити проблему, яка є принципово спільною. Випускаючи VulnHunter під дозвільною ліцензією, Capital One запрошує глобальну спільноту дослідників безпеки до стрес-тестування, розширення та вдосконалення інструменту, фактично залучаючи краудсорсинг до власної інфраструктури захисту, одночасно зміцнюючи ширшу екосистему.
Як триетапний ШІ-двигун VulnHunter виявляє вразливий код
Для керівників інженерних відділів, які оцінюють VulnHunter, технічна архітектура є тим місцем, де амбіції інструменту набувають конкретних рис. Робочий процес розгортається у трьох окремих етапах.
На першому етапі — аналізі на випередження з позиції зловмисника — VulnHunter починає з точок, через які зовнішній супротивник міг би взаємодіяти з системою: кінцеві точки API, обробники мережевих повідомлень, інтерфейси завантаження файлів. З кожної точки входу інструмент аналізує логіку програми, відстежуючи потоки даних, трансформації та внутрішні контрольні точки безпеки, щоб визначити, чи зможе зловмисник фактично досягти небезпечного шляху виконання коду. Цей підхід імітує те, як кваліфікований спеціаліст з проникнення тестує систему, але автоматизує процес у масштабах, недосяжних для людської команди.
Другий етап — це те, де VulnHunter найбільш радикально відрізняється від традиційних сканерів. Після виявлення потенційної уразливості, механізм фальсифікації запускає структурований робочий процес аналізу, розроблений для спростування власного висновку. Він шукає припущення, які не справджуються, логічні прогалини в шляху експлуатації та умови середовища, які б перешкоджали успішній атаці. Знахідки, які не проходять цю внутрішню перевірку, відкидаються ще до того, як їх побачить розробник. Явна мета Capital One — перекласти тягар з розробників з сортування хибних тривог, що є постійною проблемою, яка підриває довіру до інструментів безпеки та уповільнює швидкість розробки.
На третьому етапі уразливості, що вижили після механізму фальсифікації, запускають робочий процес виправлення, підкріплений доказами. VulnHunter збирає підтверджуючі дані з кодової бази, моделює повний шлях експлуатації, що зберігся, пояснює дефект та конкретні можливості, які отримав би зловмисник, і генерує цільові зміни коду для інженерного огляду. Результатом є не загальна рекомендація, а конкретна, контекстно-залежна пропозиція щодо виправлення.
Capital One стверджує, що вони перевірили VulnHunter внутрішньо перед випуском, запустивши його на тисячах репозиторіїв, що охоплюють десятки бізнес-напрямків. Компанія повідомляє, що інструмент виявив та усунув уразливості зі швидкістю та ефективністю, які значно перевищили те, чого раніше досягали їхні команди шляхом ручної обробки.
Чому атаки на основі ШІ змушують банки переосмислювати традиційні методи кіберзахисту
VulnHunter з’являється в момент, коли ландшафт кібербезпеки стрімко змінюється для кожного підприємства. Оголошення Capital One викладає нагальність у чітких термінах: передові моделі ШІ «різко знизили бар’єр для зловмисників у виявленні та експлуатації уразливостей у програмному забезпеченні», а вікно, перш ніж витончені можливості ШІ-атак стануть доступними та недорогими практично для кожного супротивника, швидко скорочується.
Власні дослідники компанії з безпеки ШІ уважно відстежують ці тенденції. На конференції NeurIPS 2024 у Ванкувері команда Capital One представила дослідження та курувала список із майже 100 статей, що охоплюють безпеку LLM, стійкість до атак, атаки з обходом обмежень (jailbreak attacks) та генерацію синтетичних даних. Статті, які вони виділили, зокрема роботи з багаторагентних фреймворків захисту, автоматизованого червоного тестування (red-teaming) та класифікаторів захисних бар’єрів (guardrail classifiers), малюють картину гонки озброєнь, у якій наступальні та оборонні можливості ШІ співрозвиваються з шаленою швидкістю.
Кілька з цих дослідницьких тем безпосередньо перегукуються з архітектурою VulnHunter. Механізм фальсифікації відображає стратегії атак для захисту, досліджені в таких статтях, як «BackdoorAlign», яка продемонструвала, що вбудовування структурованого механізму безпеки в невелику кількість навчальних прикладів може відновити узгодженість безпеки моделі без зниження продуктивності. Аналіз на випередження з позиції зловмисника відображає філософію «WildTeaming», фреймворку, який збирає та аналізує реальні спроби обходу обмежень для створення більш стійких моделей. І акцент VulnHunter на мінімізації хибних спрацьовувань паралельний цілям «GuardFormer», класифікатора захисних бар’єрів, який перевершив GPT-4 за показниками безпеки, працюючи в 14 разів швидше.
Нить, що пов’язує всю цю роботу, — це переконання, що традиційна, реактивна безпека (моніторинг мереж, встановлення патчів для відомих уразливостей, реагування на інциденти після їх виникнення) більше не є достатньою, коли супротивники можуть використовувати ШІ для виявлення та експлуатації уразливостей нульового дня з машинною швидкістю. Єдиний стійкий захист, стверджує Capital One, — це знайти та виправити уразливості у власному коді до того, як їх знайдуть зловмисники.
Що досвід Capital One у хмарній безпеці розкриває про всю банківську галузь
Шлях Capital One від жертви витоку даних до учасника розробки відкритого програмного забезпечення також висвітлює ширший перегляд підходів у сфері фінансових послуг. Коли Capital One активно переходила на Amazon Web Services у середині 2010-х років, це було рідкістю серед великих банків. Більшість фінансових установ просто не довіряли третім сторонам зберігати свої найчутливіші дані. Технічний директор Capital One на той час, Роб Александр, публічно пропагував хмару як більш безпечну, ніж власні дата-центри банку — заява, яку витік 2019 року значно ускладнив.
Звіт CyberScoop того періоду відобразив напруженість у галузі. У. Патрік Опет, керуючий директор з кібербезпеки в JP Morgan Chase, описав культурний зсув у банківській сфері від пріоритету трейдерів до пріоритету розробників: «Зараз це: «Зосередьтеся на розробнику, перетворіть усе на код і автоматизуйте все». Марк Ніколсон, керівник відділу кібербезпеки Deloitte у фінансовій галузі, зазначив, що тиск на швидкість виявляв «слабкі місця в методології розробки». І сам витік даних був нагадуванням про те, що навіть коли Chase витрачав 600 мільйонів доларів щорічно на кібербезпеку, відносно прості уразливості, такі як помилка Apache Struts, що стала причиною витоку даних Equifax, могли нівелювати величезні інвестиції в захист даних.
Сім років потому галузь переважно наслідувала Capital One у переході до хмари, а виклики безпеки лише посилилися. Питання вже не в тому, чи використовувати хмарну інфраструктуру, а в тому, як захистити програмне забезпечення, що на ній працює. VulnHunter — це відповідь Capital One: замість того, щоб покладатися виключно на мережеві засоби контролю та периметральний захист, безпека переноситься безпосередньо в код, у момент його написання. Випуск з відкритим кодом також несе неявний конкурентний тиск. Якщо VulnHunter здобуде популярність серед розробників і команд безпеки, він може встановити новий стандарт того, що повинні робити корпоративні інструменти безпеки, і змусити конкуруючі банки, фінтех-компанії та хмарних провайдерів відповідати або перевищувати його можливості.
Чи виправдає VulnHunter ці амбіції, залежатиме від його прийняття, залучення спільноти та його реальної продуктивності проти все більш витончених атак на основі ШІ, для протидії яким він був розроблений. Але сам випуск розповідає історію, яка виходить далеко за межі одного інструменту чи однієї компанії. У 2019 році неправильно налаштований міжмережевий екран призвів до розкриття 100 мільйонів записів і перетворив Capital One на застережну історію про вартість поспішних дій без належної обережності. У 2026 році та сама установа робить відкритим програмне забезпечення для захисту на основі ШІ, яке вона хотіла б розробити раніше, і робить ставку на те, що найкращий спосіб захистити власний код — це допомогти всій галузі захистити свій.
Як захиститися (Порада ІТ-Блогу): Активно використовуйте двофакторну автентифікацію для всіх своїх облікових записів, особливо для фінансових. Регулярно оновлюйте операційну систему та програмне забезпечення, щоб усунути відомі уразливості, які зловмисники можуть експлуатувати.
Оригінал статті: venturebeat.com