# AI‑запусканий движок оцінки ризику відповідності відкритому коду в режимі реального часу  

Підприємства все частіше створюють продукти на базі відкритих компонентів. Хоча це прискорює інновації, воно також створює рухливу ціль у вигляді ліцензійних, вразливих та регуляторних зобов’язань. Традиційні перевірки відповідності виконуються нічними пакетами або за запитом, залишаючи вікно, коли нова залежність може порушити політику до того, як хтось це помітить.  

**А що, якщо б відповідність можна було оцінювати в момент, коли залежність потрапляє у pull‑request, з оцінкою ризику, що пояснює *чому* і *як* виправити?**  

У цій статті ми розробляємо **движок оцінки ризику відповідності відкритому коду в режимі реального часу**, який поєднує дані **Software Bill of Materials (SBOM)**, **самовідновлюваний граф знань**, **графові нейронні мережі (GNN)** для структурного виведення ризику та **великі мовні моделі (LLM)** для контекстуальної інтерпретації політик. Рішення також включає **Zero‑Knowledge Proofs (ZKP)** для захисту власного коду, залишаючись при цьому здатним довести відповідність.  

> **Ключові висновки**  
> - Архітектура, що транслює оновлення SBOM у живий граф знань про відповідність.  
> - Оцінка на базі GNN, що захоплює транзитивний ризик у дереві залежностей.  
> - Політики, трансформовані LLM, які перетворюють юридичний текст у машино‑читабельні правила.  
> - Перевірка за допомогою ZKP для безпечних, аудиторських доказів відповідності.  

---  

## 1. Чому відповідність відкритому коду потребує інтелекту в реальному часі  

| Проблема | Традиційний підхід | Пробіл у реальному часі |
|-----------|----------------------|---------------|
| **Зсув ліцензій** – нова залежність вводить copyleft‑ліцензію. | Нічні сканування, ручне виправлення. | Порушення може бути злитим до виявлення. |
| **Поширення вразливостей** – CVE у транзитивній залежності. | Щотижневі бази даних вразливостей, затримка патчів. | Поверхня атаки існує під час затримки. |
| **Регуляторні обмеження** – експортний контроль, резидентність даних. | Щоквартальні огляди політик. | Бізнес‑підрозділи можуть ненавмисно порушити правила. |
| **Происхождение ланцюга постачання** – невідоме походження компонента. | Ручні перевірки походження. | Немає гарантії автентичності під час злиття. |

Оцінка в реальному часі усуває ці прогалини, **оцінюючи кожну зміну в момент інтеграції коду** та миттєво надаючи дієву оцінку ризику.  

---  

## 2. Архітектура високого рівня  

```mermaid
graph TD
    A["Developer Push (Git)"] --> B["SBOM Generator (Syft/Trivy)"]
    B --> C["Event Stream (Kafka)"]
    C --> D["Knowledge Graph Service"]
    D --> E["GNN Scoring Engine"]
    D --> F["LLM Policy Interpreter"]
    E --> G["Risk Score API"]
    F --> G
    G --> H["CI/CD Gate (GitHub Actions)"]
    H --> I["Zero‑Knowledge Proof Generator"]
    I --> J["Compliance Audit Ledger (Immutable)"]
```  

*Рисунок 1 – Конвеєр оцінки ризику відповідності відкритому коду в режимі реального часу.*  

### 2.1 Огляд компонентів  

| Компонент | Роль |
|-----------|------|
| **SBOM Generator** | Створює повний список залежностей (включаючи транзитивні зв’язки) для кожного коміту. |
| **Event Stream** | Забезпечує низьколатентну доставку оновлень SBOM до downstream‑служб. |
| **Knowledge Graph Service** | Зберігає сутності (пакети, ліцензії, CVE, регуляції) та їхні взаємозв’язки; автоматично відновлюється за допомогою Retrieval‑Augmented Generation (RAG). |
| **GNN Scoring Engine** | Навчає поширення ризику по графу, видаючи числову оцінку для кожного вузла та агреговану оцінку для коміту. |
| **LLM Policy Interpreter** | Перетворює юридичні та регуляторні тексти у правила графа (наприклад, “GPL‑3.0 не може з’являтися у SaaS‑продуктах”). |
| **Risk Score API** | Надає оцінку та пояснення CI/CD та інструментам розробника. |
| **Zero‑Knowledge Proof Generator** | Створює криптографічні докази того, що оцінка відповідає політиці, без розкриття власного коду. |
| **Compliance Audit Ledger** | Незмінний журнал (блокчейн або append‑only сховище) для аудиторів. |

---  

## 3. Введення даних – від коду до графа  

1. **Видобуток SBOM** – інструменти типу *Syft* або *Trivy* працюють як pre‑commit hook, генеруючи документ CycloneDX або SPDX.  
2. **Нормалізація** – Перетворює ідентифікатори пакетів у канонічну форму (purl).  
3. **Збагачення** – Запитує зовнішні джерела (NVD, OSV, SPDX License List, списки експортного контролю) та додає атрибути (серйозність, тип ліцензії, юрисдикція).  
4. **Трансляція** – Публікує збагачений SBOM як JSON‑подію у Kafka‑теми `sbom.raw` та `sbom.enriched`.  

Трубопровід введення даних **ідемпотентний**; повторна обробка того самого коміту дає той самий стан графа, що критично для відтворюваних аудитів.  

---  

## 4. Побудова графа знань та автоматичне відновлення  

Схема графа включає:  

- **Package**‑вузли (назва, версія, purl).  
- **License**‑вузли (SPDX‑ідентифікатор, матриця сумісності).  
- **Vulnerability**‑вузли (CVE, CVSS, версія виправлення).  
- **Regulation**‑вузли (наприклад, GDPR Art. 32, US Export Control).  
- **Типи ребер**: `DEPENDS_ON`, `HAS_LICENSE`, `HAS_VULNERABILITY`, `SUBJECT_TO`.  

### 4.1 Автоматичне відновлення за допомогою Retrieval‑Augmented Generation  

Коли публікується нова регуляція, система:  

1. Отримує сирий текст за допомогою LLM‑підсиленого веб‑краулера.  
2. Генерує правила графа (наприклад, `IF package.license = "GPL-3.0" AND product.type = "SaaS" THEN risk += 0.8`).  
3. Вставляє або оновлює вузли/ребра автоматично, забезпечуючи актуальність графа без ручних міграцій.  

---  

## 5. Оцінка в реальному часі за допомогою графових нейронних мереж  

### 5.1 Дизайн моделі  

- **Вхід**: Під‑граф, коренем якого є змінений пакет, збагачений атрибутами вузлів (вага ліцензії, CVSS, регуляторний прапорець).  
- **Архітектура**: **Graph Convolutional Network (GCN)** з наступним **Readout**‑шаром, який агрегує вбудовування вузлів у вектор рівня коміту.  
- **Вихід**:  
  - **Risk Score** ∈ [0, 1] (вище = більший ризик).  
  - **Explainability Vector**, що вказує на фактори‑вкладники (ліцензія, CVE, юрисдикція).  

### 5.2 Навчальні дані  

- Історичні події злиття, позначені результатами пост‑мортем аудиту відповідності.  
- Синтетичні контр‑фактичні приклади, згенеровані LLM (наприклад, “Що, якщо цей пакет використовував MIT замість GPL?”).  

### 5.3 Затримка інференсу  

Інференс GCN працює у мікросервісі з GPU‑прискоренням, надаючи оцінки **<200 мс** на коміт, що задовольняє вимоги CI/CD‑воріт.  

---  

## 6. LLM‑заснована контекстуальна інтерпретація політик  

Юридичні тексти часто неоднозначні. LLM (наприклад, тонко налаштований GPT‑4o) виконує:  

1. **Видобуток пунктів** – Визначає релевантні розділи (сумісність ліцензій, обмеження експорту).  
2. **Семантичне відображення** – Перетворює природну мову у предикати графа (`license_incompatible`, `requires_approval`).  
3. **Динамічне підказування** – Коли з’являється нова залежність, LLM може відповісти “Чи дозволена ця ліцензія для хмарного SaaS‑продукту?” використовуючи поточний контекст графа.  

LLM також генерує **людсько‑читабельні пояснення**, які супроводжують оцінку ризику, задовольняючи вимоги аудиту.  

---  

## 7. Докази з нульовим розголошенням для приватних аудитів  

Підприємства можуть не захотіти розкривати повні SBOM зовнішнім аудиторам. Використовуючи **zk‑SNARKs**, движок може довести:  

- *“Оцінка ризику ≤ 0.3 і всі правила політики виконані.”*  

без розкриття підлягаючих пакетів. Доказ додається до незмінного запису в журналі аудиту, забезпечуючи **довіру без довіри**.  

---  

## 8. Інтеграція з CI/CD‑конвеєрами  

Типовий workflow GitHub Actions:  

```yaml
name: Compliance Gate
on: [pull_request]

jobs:
  compliance-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Generate SBOM
        run: syft . -o json > sbom.json
      - name: Publish SBOM
        run: |
          curl -X POST -H "Content-Type: application/json" \
          -d @sbom.json http://risk‑engine.local/api/v1/sbom
      - name: Retrieve Score
        id: score
        run: |
          SCORE=$(curl -s http://risk‑engine.local/api/v1/score/${{ github.sha }})
          echo "score=$SCORE" >> $GITHUB_OUTPUT
      - name: Enforce Policy
        if: steps.score.outputs.score > 0.4
        run: |
          echo "Compliance risk too high – blocking merge."
          exit 1
```  

Конвеєр **швидко зупиняє** процес, запобігаючи злиттю некоректного коду, і одразу надає розробникам шлях до виправлення.  

---  

## 9. Безпека, управління та аудит  

| Питання | Заходи |
|---------|--------|
| **Витік даних** – SBOM може містити внутрішні назви пакетів. | Шифрування SBOM‑payload; використання ZKP для генерації доказів. |
| **Зсув моделі** – GNN може застаріти у міру появи нових загроз. | Безперервний цикл навчання: щотижневе інжекціювання пост‑мортем міток. |
| **Неоднозначність політик** – юридичні оновлення можуть бути неправильно інтерпретовані. | Перегляд людьми правил, згенерованих LLM, перед їхнім внесенням у граф. |
| **Аудиторська прозорість** – потрібні незмінні докази. | Append‑only журнал (наприклад, Hyperledger Fabric) зберігає оцінку, доказ та мітку часу. |

---  

## 10. Переваги для організацій  

1. **Миттєва видимість ризику** – Розробники бачать вплив відповідності під час кодування.  
2. **Зниження вартості виправлення** – Раннє виявлення уникає дорогих переробок пізніше.  
3. **Пояснювані рішення** – GNN та LLM пояснення задовольняють регуляторів.  
4. **Масштабованість** – Подієва архітектура підтримує тисячі мікросервісів.  
5. **Пріоритет конфіденційності** – ZKP зберігає деталі власних компонентів у таємниці.  

---  

## 11. План впровадження  

| Фаза | Ключові етапи |
|------|---------------|
| **0 – Основи** | Налаштування генерації SBOM, Kafka та Neo4j графа знань. |
| **1 – Базова оцінка** | Розгортання простого rule‑based движка (ліцензія + CVE). |
| **2 – Прототип GNN** | Навчання GCN на історичних злиттях, інтеграція з API. |
| **3 – Шар LLM‑політик** | Тонке налаштування LLM на корпусі регуляторних документів, додавання генерації правил. |
| **4 – Інтеграція ZKP** | Реалізація генерації zk‑SNARK доказів для верифікації оцінки. |
| **5 – Вбудовування CI/CD** | Додавання воріт GitHub Actions / GitLab CI, моніторинг хибнопозитивних випадків. |
| **6 – Безперервне навчання** | Автоматичний зворотний зв’язок з результатами аудитів у GNN. |

---  

## 12. Майбутні напрямки  

- **Міжкомпанійне обмін знаннями** – Федероване навчання між організаціями для покращення моделей ризику без обміну сирими SBOM.  
- **Багатомодальний доказ** – Поєднання аналізу коду, бінарної походження та сканування контейнерних образів.  
- **Адаптивне контр‑фактичне моделювання** – Використання reinforcement learning для пропозиції найменш ризикових альтернативних версій залежностей.  
- **Цифровий двійник регуляції** – Симуляція впливу майбутніх законодавчих змін на весь портфель ПЗ.  

---  

## 13. Висновок  

Компоненти відкритого коду – це життєва сила сучасного ПЗ, проте вони приносять постійно мінливий ландшафт відповідності. Поєднуючи **стрімінг SBOM**, **самовідновлюваний граф знань**, **графові нейронні мережі**, **LLM‑засновану інтерпретацію політик** та **докази з нульовим розголошенням**, запропонований движок забезпечує **реальну‑часову, пояснювану та конфіденційну оцінку ризику**, доступну безпосередньо розробникам.  

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

---  

## Дивіться також  
- [Software Bill of Materials (SBOM) – SPDX Specification](https://spdx.dev)  
- [Graph Neural Networks for Risk Propagation – Stanford CS224W Lecture](https://web.stanford.edu/class/cs224w/)  
- [Zero‑Knowledge Proofs in Secure Auditing – ZKProof Community](https://zkproof.org)  
- [Retrieval‑Augmented Generation for Knowledge Graph Auto‑Healing – arXiv:2403.01234](https://arxiv.org/abs/2403.01234)