AI з відкритим кодом у defense-tech: що важливо знати розробникам

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Всім привіт! Мене звати Юлія Вергун, я — ІТ-юрист з 10-річним досвідом роботи в міжнародних стартапах. Як General Counsel я неодноразово брала участь в підготовці стартапу до залучення інвестицій та участі в міжнародних тендерах (які ми успішно вигравали в США і отримували контракти з цілими дістріктами).

Залучення інвестицій, тендери, екзіт — це етапи, на яких потрібно багато чого розповісти зацікавленій стороні про технічний аспект продукту. Для сфери defense tech — це чутливе питання, оскільки є багато опенсорсу, опенсорного АІ та перетин з cybersecurity, де застосовуються схожі підходи щодо безпеки. І це все потрібно показати так, щоб захотіли працювати саме з вашим продуктом, вважаючи його прозорим та «безпечним».

Ця стаття буде корисна інженерам, які працюють у сфері дефенс-теху і прагнуть зробити свій продукт конкуретним на глобальному рівні, враховуючи нові вимоги до безпеки відкритого AI, які тільки починають формуватись.

Інтро

За попередньою оцінкою Центру стратегічних і міжнародних досліджень (CSIS), опенсорсне програмне забезпечення використовується у 96% цивільних і військових програмних системах США. Не секрет, що всі технологічні компанії значною мірою покладаються на програмне забезпечення з відкритим кодом для створення своїх пропрієтарних продуктів.

Зростання кількості оборонних технологічних стартапів через глобальні безпекові виклики у світі ставить їх між традиційними стартапами з добре протореним шляхом (Build-Sale-Scale) і суворо регульованими постачальниками для оборонних організацій.

Безумовно, стартапам на early stage чи навіть Series A не потрібно вкладати всі свої ресурси в менеджмент ризиків безпеки опенсорсу чи відкритого AI, зокрема у своїх продуктах. Однак інженери повинні бути готові відповісти на прості запитання (собі, стейкхолдерам і клієнтам з державних замовлень) про рівень безпеки опенсорсу, який вони використовують, і про джерела походження трейнінг сетів для навчання ШІ. А також надати відповідну документацію, якщо буде потрібно.

База

Опенсорсний АІ є наступним рівнем технологій відкритого програмного забезпечення, які традиційно використовуються компаніями на різних етапах розробки. Інструменти, підходи та методи для опенсорсу добре розроблені, вивчені та не викликають суперечок. Але все змінюється, коли в гру вступають відкриті моделі (open foundation models) подвійного використання.

Як і в загальному випадку зі звичайним опенсорсом, основна архітектура відкритих моделей є публічно доступно і може бути досліджена, змінена і застосована для різних цілей (залежно від типу ліцензії) кінцевими користувачами — фізичними особами або компаніями.

Параметри (weights) відкритих моделей, навчальні дані та inference-код можна налаштовувати й адаптувати під власні програмні продукти, при цьому відкритість дозволяє іншим учасникам інтегрувати та підтримувати їх, знижуючи всі типи витрат. Суцільний win-win.

Недавній випадок із Llama посилив усі можливі занепокоєння щодо існуючих механізмів запобігання несанкціонованому використанню відкритого АI. Після першого витоку параметрів моделей Llama в лютому 2023 року та подальшого використання адаптованого Llama 13B LLM шістьма китайськими дослідниками для створення ChatBIT (АІ-інструменту, призначеного для покращення збирання розвідувальної інформації), у Meta вирішили, що настав час оприлюднити параметри моделей, а не лише inference-код. Іншими словами — заохочувати демократії до активного використання відкритої моделі Llama у дозволений спосіб, тоді як вона вже використовується іншими не дуже демократичними субʼєктами багатьма іншими способами.

Задовго до поширення АІ-моделей таке ж «несанкціоноване» використання відбувалося у сфері відкритого програмного забезпечення. Усі памʼятають про вразливість Log4Shell у 2021 році (Log4j — фреймворк для логінів, розроблений Apache Software Foundation), який надав зловмисникам повний контроль над пристроями, які працювали на незапатчених версіях Log4j. Проте ніхто не знає, скільки ще випадків зловмисного використання open-source софту не було виявлено та усунуто, а також скільки прихованих «сюрпризів» вбудовано в пропрієтарне програмне забезпечення, яке ми використовуємо.

Публічні дискусії

Зростаюче використання open-source AI моделей у сфері кібербезпеки та оборонних технологій породжує нові публічні дискусії. У 2023–2024 роках державні установи та агентства США опублікували численні документи та запити на отримання інформації щодо використання відкритого програмного забезпечення і open AI моделей у військовій сфері та кібербезпеці.

Загальний консенсус у спільноті полягає в тому, що «зловмисники отримають доступ до інструментів незалежно від того, чи є вони відкритими», а переваги відкритого програмного забезпечення для безпеки переважають потенційну шкоду, яку можуть завдати такі зловмисники.

Водночас провідні органи влади США з найбільшими військовими бюджетами продовжують активно збирати відгуки від спільноти та бізнесу: які ризики несе open AI, чи перевищують вони переваги використання опенсорсного софту та open AI, як їх мінімізувати та інтегрувати open-source рішення в національну оборонну систему.

Відкрите програмне забезпечення і штучний інтелект зокрема, широко використовуються в оборонній екосистемі США. У своєму попередньому звіті CSIS наводить як приклади армійські смартфони, військові кораблі та супутники раннього виявлення ракетних пусків, які працюють на операційних системах, створених на основі Linux, а винищувачі F-16 з підтримкою штучного інтелекту використовують відкриті оркестраційні фреймворки, такі як Kubernetes.

Для державних оборонних структур критично важливо мати повний доступ до параметрів АІ моделей та архітектури програмного забезпечення. У тому ж звіті CSIS наводить показовий випадок: Міністерство оборони США (DOD) у рамках програми Future Long-Range Assault Aircraft із майбутнім бюджетом майже 70 мільярдів доларів відхилило пропозицію контрактора на 3,6 мільярда дешевшу, оскільки вона не відповідала вимогам Modular Open System Approach (MOSA). Натомість перевагу віддали постачальнику, який надав повний доступ до пакетів технічної документації (TDP) літака, які були необхідними для обслуговування.

З огляду на це, компанії в сфері дефенстеху повинні будувати свою архітектуру програмного забезпечення з повною та точною документацією by design. Хто зна, коли стартапу доведеться подавати заявку на контракт з Міністерством оборони США?

Три документи від оборонних агентств США, які стануть в пригоді розробникам дефенс теху:

1. CISA Open Source Software Security Roadmap

Cybersecurity and Infrastructure Security Agency (CISA) в їхній Open Source Software Security Roadmap від вересня 2023 року визначає як один із ризиків безпеки відкритого програмного забезпечення зловмисне втручання в компоненти з відкритим кодом, що призводять до подальших компрометацій. CISA наводить реальні приклади, такі як вбудовування криптомайнерів у пакети відкритого програмного забезпечення, модифікація вихідного коду за допомогою protestware, яке видаляє файли користувача, та використання typosquatting attacks, що користуються помилками розробників.

Висновки для дефенстех-розробників:

• Навіть CISA прагне зрозуміти, де «знаходяться найбільш важливі компоненти для федерального уряду та критичної інфраструктури».
• CISA визначить open-source бібліотеки, які найчастіше використовуються для підтримки критичних функцій у федеральному уряді та критичній інфраструктурі.
• Цей фреймворк допоможе визначити різні категорії open-source компонентів, зокрема шкідливих компонентів (які федеральний уряд повинен припинити використовувати), або добре підтримуваних (які уряд може продовжувати використовувати).

І дефенстех-розробники повинні бути першими, хто дізнається про те, що CISA зʼясувала.

2. The Summary of the 2023 Open-Source Software Security Request for Information Report (RFI)

[Поки я працювала над статтею, указ Президента Байдена про безпеку АІ був відкликаний новою адміністрацією і Summary Report негайно видалений із сайту Білого Дому. Тому тут доведеться повірити мені на слово.]

В оригінальному Request for Information on Open-Source Software Security: Areas of Long-Term Focus and Prioritization від 10 серпня, 2023 Офіс Національного Кібердиректора США (ONCD) для реалізації указу Президента Байдена про безпеку АІ визначив чотири важливі напрямки в розділі «Secure Open-Source Software Foundations»:

• Сприяння впровадженню memory-safe мов програмування.
• Зменшення цілих класів вразливостей.
• Зміцнення software supply chain.
• Освіта інженерів.

9 серпня 2024 року ONCD опублікував Summary Report щодо цього Request for Information. Однак навіть важливіше, що запитав ONCD у початковому запиті, аніж відповіді, оскільки саме це запитуватимуть в оборонних технологічних стартапів на кожному етапі (фандрейзинг, тендери, екзіт).

Респонденти надали 107 публічних повідомлень, які доступні для громадськості (ви можете шукати відповідь вашої улюбленої компанії, тут, наприклад, відповідь GitHub).

Висновки для дефенстех-розробників:

• Респонденти рекомендували стандартизувати SBOMs (Software Bill of Materials, приклад із репозиторію npm).
• Вони відзначили, що цього можна досягти, надавши державним агенціям SBOM інструменти управління атестаціями (attestation management tools), які забезпечують високий рівень інтеграції з базами даних вразливостей.
• Респонденти зазначили, що краще використовувати інструменти, які створюють SBOM під час процесу розробки, оскільки тоді інструменти зазвичай мають доступ до більш детальної та точної інформації, ніж та, яка доступна в результаті аналізу артефакту.

3. Request for Comment from the National Telecommunications and Information Administration (NTIA)

Президент Байден своїм розпорядженням про «Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence» від 30 жовтня 2023 року (яке вже скасоване Президентом Трампом, проте все одно варте аналізу) змусив Національне управління телекомунікацій та інформації США (NTIA) надіслати бізнесам та громадськості запит про коментарі щодо цих питань.

Як і два попередні запити на інформацію, запит від NTIA також спрямований на отримання фідбеку індустрії щодо опенсорсного AI. NTIA стверджує, що нещодавня поява великих загальнодоступних моделей від Google, Meta, Stability AI, Mistral, Allen Institute for AI та Eleuthera AI «сприяла формуванню екосистеми ще більш „відкритих“ передових АІ-моделей, дозволяючи розробникам та іншим зацікавленим сторонам налаштовувати моделі, використовуючи загальнодоступні обчислювальні ресурси».

Підтверджуючи добре відомі спостереження про те, що ризик негативного втручання у відкриті АІ-моделі може бути зменшений завдяки їхній широкій доступності, агентство прагне діяти на випередження і розв’язувати проблеми open AI, що тільки виникають (або принаймні намагатися це зробити).

Висновки для дефенстех-розробників (трохи довші, ніж у попередніх розділах, але варто ознайомитись):

• NTIA запитує думку спільноти щодо того, коли (якщо взагалі) суб’єктам, які деплоять АІ, слід повідомляти користувачам або широкій громадськості, що вони використовують відкриті АІ-моделі з широкодоступними параметрами (weights) або без них.
• NTIA ставить наступне запитання: якою має бути роль хостинг-сервісів (наприклад, HuggingFace, GitHub, etc) у тому, щоб зберігати моделі подвійного використання з відкритими параметрами більш чи менше доступними? Чи повинні такі хостинг-сервіси розміщувати моделі, які не відповідають певним стандартам безпеки? Хто повинен визначати ці стандарти? Це схоже на концепцію safe harbor для онлайн сервіс-провайдерів в DMCA, однак у мільйон разів складніше на практиці.
• NTIA запитує, які ліцензії є найбільш перспективними для надання широкого доступу до параметрів відкритих моделей. Які компроміси пов’язані з кожною з цих ліцензій?
• NTIA досліджує, чи існують занепокоєння щодо потенційних перешкод для взаємодії, що виникають через різні несумісні «відкриті» ліцензії, наприклад, ліцензії з суперечливими вимогами, застосовані до компонентів АІ. Чи буде корисною стандартизація умов ліцензій спеціально для параметрів АІ-моделей? Чи існують конкретні приклади, які можуть бути корисними?

Тому будьте готові одного дня надати відповіді та пояснити, як ліцензія на відкритий вихідний код у АІ-моделях взаємодіє з розробленим вами пропрієтарним продуктом.

Іншими словами, краще заздалегідь вчитися у провідних американських інституцій у сфері безпеки та впроваджувати їхні напрацювання в передові дефенстех-проєкти на основі open AI.

Заходи безпеки для розробників

Principles for Package Repository Security

У лютому 2024 року Агентство кібербезпеки та безпеки інфраструктури (CISA) спільно з Open Source Security Foundation (OpenSSF) опублікували принципи безпеки для репозиторіїв.

Вони визначають 4 рівні security maturity для репозиторіїв:

• Level 0 визначається як такий, що має дуже низький рівень безпеки.
• Level 1 — це basic security maturity, яка включає підтримку основних функцій безпеки, таких як багатофакторна аутентифікація (MFA), і дозволяє повідомляти про вразливості. Усі екосистеми менеджменту репозиторіїв мають працювати принаймні на цьому рівні.
• Level 2 — помірний рівень безпеки, який передбачає обовʼязкову мультифакторну аутентифікацію (MFA) для критичних пакетів і попередження користувачів про відомі вразливості безпеки.
• Level 3 визначається як такий, що має advanced-безпеку, яка передбачає обовʼязкову MFA для всіх розробників і підтримку створення provenance для пакетів.

Як приклад безпечнішої Аутентифікації для репозиторіїв з security Level 1, репозиторій повинен вимагати від користувачів верифікацію їхньої електронної адреси. Репозиторій також має підтримувати надійну мультифакторну аутентифікацію за допомогою, як мінімум, Time-based one-time passcode (TOTP). Зазначається, що більш слабкі форми MFA, такі як SMS, електронна пошта або MFA на основі телефонного дзвінка, не відповідатимуть вимозі цього рівня безпеки.

Для безпеки Аутентифікації на Level 2 репозиторій має виявляти покинуті домени електронної пошти, щоб запобігти відновленню домену для захоплення облікового запису. Автори припускають, що це може виглядати як пошук через WHOIS по всіх зареєстрованих доменах електронних пошт та скасування можливості відновлення облікового запису через домен електронної пошти, який було покинуто.

Репозиторії із Level 3 security мають підтримувати автентифікацію без пароля, наприклад через ключі доступу, і вимагати MFA для всіх розробників (включно зі стійкими до фішингу MFA для пакетів, які вважаються критичними, наприклад, 1% найпопулярніших пакетів за кількістю завантажень).

Такі самі пропозиції безпеки розроблені для Авторизації, General Capabilities, and CLI Tooling для всіх 4 рівнів. Наполегливо рекомендую ознайомитись з ними дефенстех-розробникам, щоб мати змогу ідентифікувати захищені та «не дуже захищені» репозиторії та їхній вплив на зберігання АІ-моделей із відкритим кодом.

Пропозиції безпеки для open-source проєктів від репозиторіїв

7 березня 2024 року CISA провела дводенний саміт із безпеки відкритого програмного забезпечення (OSS Security Summit), який об’єднав лідерів опенсорс-спільноти.

На саміті були оголошені ключові дії для посилення безпеки open-source екосистем. Хоча саміт не був спеціально присвячений безпеці open AI-моделей, ми можемо використати ці знання, щоб озброїти дефенстех-розробників, які інтегрують відкритий АІ у свої продукти.

Під час саміту представники п’яти репозиторіїв представили свої заходи щодо вдосконалення Principles for Package Repository Security, спрямованих на посилення безпеки всієї екосистеми відкритого програмного забезпечення.

Висновки для дефенстех-розробників:

• The Python Software Foundation працює над створенням API та повʼязаних інструментів для швидкого виявлення та попередження шкідливого софту, що дозволить PyPI (The Python Package Index) ефективніше реагувати на загрози без значного використання ресурсів.

• Вони також розширюють список постачальників для PyPI у межах ініціативи «Trusted Publishing» (опублікування без використання облікових даних), додаючи підтримку GitLab, Google Cloud і ActiveState на GitHub.

• Python-екосистема завершує розробку PEP 740 («Index support for digital attestations»), що дозволить завантажувати та поширювати підписані в цифровий спосіб атестації та метадані для їх верифікації в репозиторіях Python, таких як PyPI.

• npm вимагає від розробників проєктів із високим рівнем впливу використовувати мультифакторну аутентифікацію. Вони представили інструменти, які дозволяють розробникам автоматично генерувати package provenance та SBOM (Software Bill of Materials), що дає можливість користувачам відстежувати та верифікувати походження залежностей у відкритому програмному забезпеченні:

«The npm sbom command generates a Software Bill of Materials (SBOM) listing the dependencies for the current project. SBOMs can be generated in either SPDX or CycloneDX format.)»

Side note. Верифікація provenance для залежностей є однією з ключових функцій для забезпечення безпеки відкритих АІ-моделей. GitHub застосовує аналогічний підхід для проєктів, що базуються на npm:

«Starting today, when you build your npm projects on GitHub Actions, you can publish provenance alongside your package by including the —provenance flag. This provenance data gives consumers a verifiable way to link a package back to its source repository and the specific build instructions used to publish it (see example on npmjs.com).»

Поки розробники відкритих АІ-моделей та полісімейкери створять правила для забезпечення безпеки екосистеми, варто покладатись на загальні принципи захисту відкритого програмного забезпечення:

• Трекінг provenance-моделей.
• Перевірка SBOMs-моделей.
• Імплементація provenance та розробка SBOMs для власних продуктів, щоб бути готовими до будь-яких запитів щодо безпеки програмного забезпечення та його компонентів.

Як підсумок

Відкриті АІ-моделі широко використовуються в усіх передових галузях, і дефенс-технології не є винятком. Зараз виникають спроби як регулювання open AI, так і зворотного скасування цих спроб (як нещодавнє відкликання указу Джо Байдена щодо безпеки AI Дональдом Трампом).

Однак такі зміни в урядових політиках (незалежно від того, йдеться про США, ЄС чи країни Близького Сходу) не змінюють того, як відкриті AI-моделі повинні використовуватися та інтегруватися в оборонне програмне забезпечення.

Розробники military-tech повинні значною мірою покладатися на ранні ініціативи щодо безпеки відкритого програмного забезпечення, щоб зробити open AI більш безпечним і впроваджувати принципи безпеки by design. Вони повинні бути підготовлені та освічені в питаннях безпеки архітектури, оскільки це не лише питання комерційних відносин — урядові контракти, партнерства, екзіти, коли компанія повинна розкрити багато інформації для укладення угоди.

Набагато важливішим є те, що програмне забезпечення для дефенстех безпосередньо впливає на глобальну безпеку та має практичне застосування, найбільш поширеним є використання на реальному полі бою. І жоден засновник перспективного стартапу не захоче, щоб їхня система навігації для дронів, автоматизована турель з комп’ютерним зором чи будь-який інший безпілотний апарат, заснований на компонентах openAI-моделей, втратив контроль через зловмисне втручання.

Наприклад, через те, що розробники не перевірили рівень безпеки репозиторію, де була опублікована відкрита AI-модель. Так, це штучний приклад, але це — лише питання часу, коли реальні приклади почнуть з’являтися.