# AI poháněný engine pro hodnocení rizika souladu s open source v reálném čase  

Podniky stále častěji staví produkty na open‑source komponentách. To urychluje inovace, ale zároveň přináší neustále se měnící požadavky na licence, zranitelnosti a regulatorní soulad. Tradiční kontroly souladu probíhají v noci nebo na vyžádání, což zanechává okno, během kterého může nově zavedená závislost porušit politiku dříve, než si to někdo všimne.  

**Co kdyby se soulad mohl vyhodnotit v okamžiku, kdy se závislost objeví v pull requestu, a skóre rizika by zároveň vysvětlovalo *proč* a *jak* provést nápravu?**  

V tomto článku navrhujeme **engine pro hodnocení rizika souladu s open source v reálném čase**, který kombinuje data **Software Bill of Materials (SBOM)**, **samouzdravující se znalostní graf**, **grafové neuronové sítě (GNN)** pro inferenci strukturovaného rizika a **velké jazykové modely (LLM)** pro kontextovou interpretaci politik. Řešení také zahrnuje **Zero‑Knowledge Proofs (ZKP)**, aby chránilo proprietární kód a zároveň dokazovalo soulad.  

> **Klíčové poznatky**  
> - Architektura, která streamuje aktualizace SBOM do živého znalostního grafu.  
> - Scoring založený na GNN, který zachycuje transitivní riziko napříč stromem závislostí.  
> - Překlad politik pomocí LLM, který převádí právní text na strojově čitelné pravidla.  
> - Ověřování pomocí ZKP pro bezpečný, auditovatelný důkaz souladu.  

---  

## 1. Proč soulad s open‑source vyžaduje inteligenci v reálném čase  

| Výzva | Tradiční přístup | Mezera v reálném čase |
|-----------|----------------------|---------------|
| **Posun licence** – nová závislost zavádí copyleft licenci. | Noční skenování, ruční náprava. | Porušení může být sloučeno před detekcí. |
| **Propagace zranitelnosti** – CVE v transitivní závislosti. | Týdenní databáze zranitelností, zpožděné opravy. | Útočný povrch existuje během prodlevy. |
| **Regulační omezení** – exportní kontroly, umístění dat. | Čtvrtletní revize politik. | Obchodní jednotky mohou neúmyslně porušit předpisy. |
| **Původ v dodavatelském řetězci** – neznámý původ komponenty. | Manuální kontroly původu. | Žádná záruka pravosti v okamžiku sloučení. |

Scoring v reálném čase eliminuje tyto mezery tím, že **vyhodnocuje každou změnu v okamžiku integrace kódu** a okamžitě poskytuje akční skóre rizika.  

---  

## 2. Vysoká úroveň architektury  

```mermaid
graph TD
    A["Push vývojáře (Git)"] --> B["Generátor SBOM (Syft/Trivy)"]
    B --> C["Event Stream (Kafka)"]
    C --> D["Služba znalostního grafu"]
    D --> E["Engine pro scoring GNN"]
    D --> F["Interpretátor politik LLM"]
    E --> G["Risk Score API"]
    F --> G
    G --> H["CI/CD Gate (GitHub Actions)"]
    H --> I["Generátor Zero‑Knowledge Proof"]
    I --> J["Auditní ledger souladu (neměnný)"]
```  

*Obrázek 1 – Pipeline pro hodnocení rizika souladu s open source v reálném čase.*  

### 2.1 Přehled komponent  

| Komponenta | Role |
|-----------|------|
| **Generátor SBOM** | Produkuje kompletní seznam závislostí (včetně transitivních hran) pro každý commit. |
| **Event Stream** | Zajišťuje nízkolatenční doručení aktualizací SBOM do downstream služeb. |
| **Služba znalostního grafu** | Ukládá entity (balíčky, licence, CVE, regulace) a vztahy; automaticky se uzdravuje pomocí Retrieval‑Augmented Generation (RAG). |
| **Engine pro scoring GNN** | Učí se šíření rizika napříč grafem a vrací číselné skóre pro každý uzel i agregované skóre pro commit. |
| **Interpretátor politik LLM** | Převádí právní a regulatorní texty na pravidla grafu (např. “GPL‑3.0 nesmí být použita v SaaS produktech”). |
| **Risk Score API** | Exponuje skóre a vysvětlení CI/CD a vývojářským nástrojům. |
| **Generátor Zero‑Knowledge Proof** | Vytváří kryptografické důkazy, že skóre splňuje politiku, aniž by odhalovalo proprietární kód. |
| **Auditní ledger souladu** | Neměnný log (blockchain nebo append‑only úložiště) pro auditory. |

---  

## 3. Ingestování dat – od kódu ke grafu  

1. **Extrahování SBOM** – Nástroje jako *Syft* nebo *Trivy* běží jako pre‑commit hook a generují dokument CycloneDX nebo SPDX.  
2. **Normalizace** – Převod identifikátorů balíčků do kanonické podoby (purl).  
3. **Obohacení** – Dotazování externích zdrojů (NVD, OSV, SPDX License List, seznamy exportních kontrol) a připojení atributů (závažnost, typ licence, jurisdikce).  
4. **Streamování** – Publikování obohaceného SBOM jako JSON události do Kafka témat `sbom.raw` a `sbom.enriched`.  

Ingestní pipeline je **idempotentní**; opětovné zpracování stejného commitu vede ke stejnému stavu grafu, což je klíčové pro reprodukovatelné audity.  

---  

## 4. Konstrukce znalostního grafu a automatické opravy  

Schéma grafu zahrnuje:  

- **Uzel Balíček** (název, verze, purl).  
- **Uzel Licence** (SPDX identifikátor, matice kompatibility).  
- **Uzel Zranitelnost** (CVE, CVSS, verze opravy).  
- **Uzel Regulace** (např. GDPR Art. 32, US Export Control).  
- **Typy hran**: `DEPENDS_ON`, `HAS_LICENSE`, `HAS_VULNERABILITY`, `SUBJECT_TO`.  

### 4.1 Automatické opravy pomocí Retrieval‑Augmented Generation  

Když je publikována nová regulace, systém:  

1. Načte surový text pomocí LLM‑augmentovaného web‑crawleru.  
2. Vygeneruje pravidla grafu (např. `IF package.license = "GPL-3.0" AND product.type = "SaaS" THEN risk += 0.8`).  
3. Vloží nebo aktualizuje uzly/hrany automaticky, čímž zajistí, že graf zůstane aktuální bez manuálních migrací.  

---  

## 5. Hodnocení v reálném čase pomocí grafových neuronových sítí  

### 5.1 Návrh modelu  

- **Vstup**: Sub‑graf kořenící se v změněném balíčku, obohacený o vlastnosti uzlů (váha licence, skóre CVSS, regulační příznak).  
- **Architektura**: **Graph Convolutional Network (GCN)** následovaný **Readout** vrstvou, která agreguje embeddingy uzlů do vektoru úrovně commitu.  
- **Výstup**:  
  - **Risk Score** ∈ [0, 1] (vyšší = rizikovější).  
  - **Vysvětlovací vektor** ukazující přispívající faktory (licence, CVE, jurisdikce).  

### 5.2 Tréninková data  

- Historické události sloučení označené podle následných zjištění souladu.  
- Syntetické kontrafaktuální příklady generované LLM (např. “Co kdyby tento balíček používal MIT místo GPL?”).  

### 5.3 Latence inferencí  

Inference GCN běží v GPU‑akcelerované mikro‑službě a dodává skóre **<200 ms** na commit, což splňuje požadavky CI/CD gate.  

---  

## 6. Interpretace kontextových politik pomocí LLM  

Právní texty jsou často nejednoznačné. LLM (např. jemně doladěný GPT‑4o) provádí:  

1. **Extrahování klauzulí** – Identifikuje relevantní sekce (kompatibilita licencí, exportní omezení).  
2. **Sémantické mapování** – Převádí přirozený jazyk na predikáty grafu (`license_incompatible`, `requires_approval`).  
3. **Dynamické dotazování** – Když se objeví nová závislost, LLM může odpovědět “Je tato licence povolena pro cloud‑hostovaný SaaS produkt?” s využitím aktuálního kontextu grafu.  

LLM také generuje **lidsky čitelné vysvětlení**, které doprovází skóre rizika a splňuje požadavky auditorů.  

---  

## 7. Zero‑Knowledge důkazy pro soukromí zachovávající audity  

Podniky nemusí zveřejňovat kompletní SBOM externím auditorům. Využitím **zk‑SNARKs** může engine dokázat:  

- *„Skóre rizika je ≤ 0.3 a všechna pravidla politik jsou splněna.“*  

bez odhalení podkladového seznamu balíčků. Důkaz je připojen k záznamu v neměnném auditním ledgeru, což umožňuje **důvěryhodné ověření**.  

---  

## 8. Integrace s CI/CD pipeline  

Typický workflow v 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
```  

Pipeline **selže rychle**, čímž zabrání sloučení nesouladného kódu a poskytne vývojářům okamžitou cestu k nápravě.  

---  

## 9. Bezpečnost, správa a audit  

| Obava | Řešení |
|---------|------------|
| **Únik dat** – SBOM může obsahovat interní názvy balíčků. | Šifrovat SBOM payload; použít ZKP pro generování důkazů. |
| **Posun modelu** – GNN může zastarat, jak se objevují nové hrozby. | Kontinuální smyčka učení: týdenní ingestování zpětných vazeb z auditů. |
| **Nejednoznačnost politik** – Právní aktualizace mohou být špatně interpretovány. | Lidská kontrola LLM‑generovaných pravidel před jejich vložením do grafu. |
| **Auditovatelnost** – Potřeba neměnných důkazů. | Append‑only ledger (např. Hyperledger Fabric) ukládá skóre, důkaz a časové razítko. |

---  

## 10. Výhody pro organizace  

1. **Okamžitá viditelnost rizika** – Vývojáři vidí dopad souladu během psaní kódu.  
2. **Snížené náklady na nápravu** – Včasná detekce zabraňuje drahému přepracování později.  
3. **Vysvětlitelné rozhodnutí** – Kombinace GNN a LLM poskytuje vysvětlení, které uspokojí regulátory.  
4. **Škálovatelnost napříč repozitáři** – Event‑driven design podporuje tisíce mikro‑služeb.  
5. **Soukromí‑první přístup** – ZKPs udržují důvěrné detaily proprietárních komponent skryté.  

---  

## 11. Implementační plán  

| Fáze | Milníky |
|-------|------------|
| **0 – Základy** | Nastavení generátoru SBOM, Kafka a Neo4j znalostního grafu. |
| **1 – Základní scoring** | Nasazení jednoduchého pravidlového engine (licence + CVE). |
| **2 – Prototyp GNN** | Trénink GCN na historických sloučeních, integrace s API. |
| **3 – Vrstva politik LLM** | Doladění LLM na regulatorní korpus, přidání generování pravidel. |
| **4 – Integrace ZKP** | Implementace zk‑SNARK generátoru pro ověření skóre. |
| **5 – Vnoření do CI/CD** | Přidání bran GitHub Actions / GitLab CI, monitorování false positive. |
| **6 – Kontinuální učení** | Automatizace zpětné smyčky z auditních zjištění do GNN. |

---  

## 12. Budoucí směry  

- **Sdílení znalostí napříč organizacemi** – Federované učení mezi firmami ke zlepšení modelů rizika bez sdílení surových SBOM.  
- **Multimodální důkazy** – Kombinace analýzy kódu s provenance binárních souborů a skenováním kontejnerových obrazů.  
- **Adaptivní kontrafaktuální simulace** – Použití reinforcement learning k návrhu *nejméně rizikové* alternativní verze závislosti.  
- **Digitální dvojče regulací** – Simulace dopadu nadcházející legislativy na celé portfolio softwaru.  

---  

## 13. Závěr  

Open‑source komponenty jsou životní silou moderního softwaru, ale zároveň přinášejí neustále se měnící prostředí souladu. Spojením **streamování SBOM, samouzdravujícího se znalostního grafu, grafových neuronových sítí, LLM‑překladu politik a zero‑knowledge důkazů** tento engine poskytuje **reálné, vysvětlitelné a soukromí‑chránící skóre rizika** přímo ve vývojářských nástrojích.  

Přijetím této architektury se soulad transformuje z úzkého úzkého úseku do proaktivní, kontinuální ochrany – umožňující týmům vydávat rychleji a zároveň zůstávat pevně v mezích právních a bezpečnostních požadavků.  

---  

## Viz také  
- [Open Source 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)