# AI‑задвижван двигател за оценка на риска от съответствие с отворения код в реално време  

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

**Какво ако съответствието се оценява в момента, в който зависимостта се появи в pull request, с оценка на риска, която обяснява *защо* и *как* да се отстрани?**  

В тази статия проектираме **двигател за оценка на риска от съответствие с отворения код в реално време**, който комбинира **данни от Software Bill of Materials (SBOM)**, **само‑лекуващ граф на знания**, **графови невронни мрежи (GNN)** за структурно извличане на риска и **големи езикови модели (LLM)** за контекстуална интерпретация на политиките. Решението също включва **доказателства с нулево знание (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 Генератор** | Създава пълен списък на зависимостите (включително транзитивните) за всеки комит. |
| **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 ms** на комит – достатъчно бързо за CI/CD gate.  

---  

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

Правните текстове често са двусмислени. LLM‑тът (напр. фино‑настроен GPT‑4o) извършва:  

1. **Извличане на клаузи** – Открива релевантни секции (съвместимост на лиценз, ограничения за износ).  
2. **Семантично картографиране** – Превръща естествения език в предикати за графа (`license_incompatible`, `requires_approval`).  
3. **Динамично подканване** – При нова зависимост LLM‑тът може да отговори на въпроса “Позволен ли е този лиценз за облажен SaaS продукт?” използвайки текущото състояние на графа.  

LLM‑тът също генерира **човеко‑четими обяснения**, които придружават оценката на риска, удовлетворявайки изискванията за одит.  

---  

## 7. Доказателства с нулево знание за запазване на поверителност  

Предприятията може да не желаят да разкриват пълните SBOM‑ове пред външни одитори. Чрез **zk‑SNARKs** двигателят може да докаже:  

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

без да разкрива конкретните пакети. Доказателството се прикачва към записа в неизменимия одитен журнал, позволявайки **доверено проверяване**.  

---  

## 8. Интеграция с CI/CD конвейери  

Примерен GitHub Actions workflow:  

```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 може да съдържа вътрешни имена на пакети. | Шифроване на payload‑а; използване на ZKP за генериране на доказателства. |
| **Дрифт на модела** – GNN може да остарее при нови заплахи. | Непрекъсната обучителна верига: седмични етикети от пост‑мортем анализи. |
| **Неяснота в политиките** – правни актуализации могат да бъдат погрешно интерпретирани. | Човешка проверка на правилата, генерирани от LLM, преди вмъкване в графа. |
| **Одитируемост** – необходимост от неизменни доказателства. | Append‑only журнал (напр. Hyperledger Fabric) съхранява оценка, доказателство и timestamp. |

---  

## 10. Ползи за организации  

1. **Моментална видимост на риска** – Разработчиците виждат въздействието върху съответствието по време на писане на кода.  
2. **Намалени разходи за отстраняване** – Ранното откриване избягва скъпо преработване по-късно.  
3. **Обясними решения** – Обясненията от GNN и LLM удовлетворяват регулаторите.  
4. **Мащабируемост** – Събитийно‑ориентиран дизайн поддържа хиляди микросервизи.  
5. **Първо‑пристъпно запазване на поверителност** – ZKP пази детайлите на собственическия код.  

---  

## 11. План за внедряване  

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

---  

## 12. Бъдещи направления  

- **Споделяне на знания между организации** – Федеративно обучение, без споделяне на сурови SBOM‑ове.  
- **Мултимодални доказателства** – Комбинация от анализ на код, бинарен произход и сканиране на контейнерни изображения.  
- **Адаптивна контрафактуална симулация** – Използване на reinforcement learning за предлагане на най‑малко рискови алтернативни версии.  
- **Регулаторен дигитален двойник** – Симулиране на въздействието от предстоящи законодателства върху целия софтуерен портфейл.  

---  

## 13. Заключение  

Отвореният код е жизненоважен за съвременния софтуер, но носи постоянно променящ се пейзаж на съответствие. Чрез **комбиниране на стрийминг на SBOM, само‑лекуващ граф на знания, графови невронни мрежи, LLM‑драйвнат слой за политики и доказателства с нулево знание**, предложеният двигател доставя **оценки на риска в реално време, обясними и запазващи поверителността**, директно в ръцете на разработчиците.  

Приемането на тази архитектура превръща съответствието от следващ етап в проактивен, непрекъснат щит – позволявайки на екипите да пускат продукти по‑бързо, без да излизат извън правните и сигурностните граници.  

---  

## Вижте още  

- [Software Bill of Materials (SBOM) – SPDX спецификация](https://spdx.dev)  
- [Graph Neural Networks for Risk Propagation – Stanford CS224W лекция](https://web.stanford.edu/class/cs224w/)  
- [Zero‑Knowledge Proofs в сигурен одит – ZKProof общност](https://zkproof.org)  
- [Retrieval‑Augmented Generation за автоматично лекуване на графове – arXiv:2403.01234](https://arxiv.org/abs/2403.01234)