# Mesterséges Intelligencia által vezérelt valós idejű nyílt forráskódú megfelelőségi kockázati pontozó motor  

A vállalatok egyre gyakrabban építenek termékeket nyílt forráskódú komponensekre. Bár ez felgyorsítja az innovációt, egyúttal egy folyamatosan változó licenc‑, sebezhetőség‑ és szabályozási megfelelőségi kötelezettséglistát is hoz magával. A hagyományos megfelelőségi ellenőrzések éjszakánként vagy igény szerint futnak, így egy új függőség bevezetése közben előfordulhat, hogy a szabályzatot megsérti, mielőtt bárki észrevenné.  

**Mi lenne, ha a megfelelőséget már a függőség egy pull‑request‑be kerülésekor értékelhetnénk, egy olyan kockázati pontszámmal, amely megmagyarázza *miért* és *hogyan* kell javítani?**  

Ebben a cikkben egy **valós‑időben működő nyílt forráskódú megfelelőségi kockázati pontozó motort** tervezünk, amely egyesíti a **Software Bill of Materials (SBOM)** adatokat, egy **önjavító tudásgráfot**, **gráf neurális hálókat (GNN‑ek)** a strukturális kockázat‑inferencia érdekében, valamint **nagy nyelvi modelleket (LLM‑ek)** a kontextuális szabályértelmezéshez. A megoldás továbbá **null‑ismeret‑bizonyítékokat (ZKP‑k)** használ a tulajdonosi kód védelmére, miközben a megfelelőséget bizonyítja.  

> **Főbb tanulságok**  
> - Architektúra, amely az SBOM‑frissítéseket egy élő megfelelőségi tudásgráfba streameli.  
> - GNN‑alapú pontozás, amely a függőségi fákon keresztül terjeszti a transzitiv kockázatot.  
> - LLM‑vezérelt szabályfordítás, amely a jogi szöveget gép‑olvasható szabályokká alakítja.  
> - ZKP‑alapú ellenőrzés a biztonságos, auditálható megfelelőségi bizonyítékokért.  

---  

## 1. Miért van szükség valós‑időben működő nyílt forráskódú megfelelőségre  

| Kihívás | Hagyományos megközelítés | Valós‑időbeli rés |  
|-----------|----------------------|---------------|  
| **Licenc‑elcsúszás** – egy új függőség copyleft licencet hoz be. | Éjszakai vizsgálatok, manuális javítás. | A szabálysértés még a detektálás előtt beolvasztódik. |  
| **Sebezhetőség‑terjedés** – CVE egy transzitiv függőségben. | Heti sebezhetőségi adatbázisok, késleltetett javítás. | A támadási felület a késleltetés alatt létezik. |  
| **Szabályozási korlátozások** – exportkontroll, adat‑tartózkodás. | Negyedéves szabályzat‑áttekintés. | Az üzleti egységek véletlenül megszeghetik a szabályokat. |  
| **Ellátási lánc eredetiség** – ismeretlen komponens‑forrás. | Manuális eredetiség‑ellenőrzés. | Nincs garancia a hitelességre a merge időpontjában. |  

A valós‑időben történő pontozás megszünteti ezeket a hézagokat, **minden változást a kódintegráció pontján értékel**, és azonnal cselekvőképes kockázati pontszámot ad.  

---  

## 2. Magas szintű architektúra  

```mermaid
graph TD
    A["Fejlesztői push (Git)"] --> B["SBOM generátor (Syft/Trivy)"]
    B --> C["Esemény‑stream (Kafka)"]
    C --> D["Tudásgráf szolgáltatás"]
    D --> E["GNN pontozó motor"]
    D --> F["LLM szabály‑értelmező"]
    E --> G["Kockázati pontszám API"]
    F --> G
    G --> H["CI/CD kapu (GitHub Actions)"]
    H --> I["Null‑ismeret‑bizonyíték generátor"]
    I --> J["Megfelelőségi audit‑könyvtár (immutábilis)"]
```  

*Ábra 1 – Valós‑időben működő nyílt forráskódú megfelelőségi kockázati pontozó csővezeték.*  

### 2.1 Az egyes komponensek áttekintése  

| Komponens | Szerep |
|-----------|--------|
| **SBOM generátor** | Minden commithez teljes függőségi listát (beleértve a transzitiv éleket) állít elő. |
| **Esemény‑stream** | Alacsony késleltetésű szállítást biztosít az SBOM‑frissítéseknek a downstream szolgáltatások felé. |
| **Tudásgráf szolgáltatás** | Entitásokat (csomagok, licencek, CVE‑k, szabályozások) és kapcsolataikat tárolja; automatikusan gyógyul a Retrieval‑Augmented Generation (RAG) segítségével. |
| **GNN pontozó motor** | A gráfban a kockázat terjedését tanulja, numerikus pontszámot adva minden csomópontra és egy aggregált értéket a commithez. |
| **LLM szabály‑értelmező** | A jogi és szabályozási szövegeket gráf‑szabályokká alakítja (pl. „GPL‑3.0 nem jelenhet meg SaaS termékekben”). |
| **Kockázati pontszám API** | A pontszámot és magyarázatot CI/CD‑nek és fejlesztői eszközöknek teszi elérhetővé. |
| **Null‑ismeret‑bizonyíték generátor** | Kriptográfiai bizonyítékot hoz létre arról, hogy a pontszám megfelel a szabályzatnak anélkül, hogy a tulajdonosi kódot felfedné. |
| **Megfelelőségi audit‑könyvtár** | Immutable napló (blockchain vagy csak‑hozzáadható tároló) az auditorok számára. |

---  

## 3. Adatintegráció – a kódtól a gráfig  

1. **SBOM kinyerés** – A *Syft* vagy *Trivy* eszközök pre‑commit hook‑ként futnak, és CycloneDX vagy SPDX dokumentumot állítanak elő.  
2. **Normalizálás** – A csomag‑azonosítókat kanonikus formára (purl) konvertálja.  
3. **Gazdagítás** – Külső források (NVD, OSV, SPDX licence‑lista, export‑kontroll listák) lekérdezése, és attribútumok (súlyosság, licenc‑típus, joghatóság) csatolása.  
4. **Streamelés** – A gazdagított SBOM‑t JSON eseményként publikálja a Kafka‑topic‑okra `sbom.raw` és `sbom.enriched`.  

Az integrációs csővezeték **idempotens**; ugyanazon commit újbóli feldolgozása ugyanazt a gráf‑állapotot eredményezi, ami a reprodukálható auditokhoz elengedhetetlen.  

---  

## 4. Tudásgráf felépítése és automatikus gyógyítása  

A gráf séma a következőket tartalmazza:  

- **Csomag** csomópontok (név, verzió, purl).  
- **Licenc** csomópontok (SPDX azonosító, kompatibilitási mátrix).  
- **Sebezhetőség** csomópontok (CVE, CVSS, javító verzió).  
- **Szabályozás** csomópontok (pl. GDPR Art. 32, US Export Control).  
- **Éltípusok**: `DEPENDS_ON`, `HAS_LICENSE`, `HAS_VULNERABILITY`, `SUBJECT_TO`.  

### 4.1 Automatikus gyógyítás Retrieval‑Augmented Generation‑nel  

Amikor egy új szabályozás jelenik meg, a rendszer:  

1. LLM‑kiegészített web‑crawlerrel lekéri a nyers szöveget.  
2. Gráf‑szabályokat generál (pl. `IF package.license = "GPL-3.0" AND product.type = "SaaS" THEN risk += 0.8`).  
3. Automatikusan beilleszti vagy frissíti a csomópontokat/éleket, így a gráf naprakész marad manuális migráció nélkül.  

---  

## 5. Valós‑időben történő pontozás gráf neurális hálókkal  

### 5.1 Modell felépítése  

- **Bemenet**: A megváltozott csomaghoz kapcsolódó rész‑gráf, amely node‑jellemzőkkel (licenc‑kockázati súly, CVSS‑pontszám, szabályozási jelző) van ellátva.  
- **Architektúra**: **Graph Convolutional Network (GCN)**, amelyet egy **Readout** réteg követ, aggregálva a node‑embeddingeket commit‑szintű vektorrá.  
- **Kimenet**:  
  - **Kockázati pontszám** ∈ [0, 1] (magasabb = nagyobb kockázat).  
  - **Magyarázó vektor**, amely jelzi a hozzájáruló tényezőket (licenc, CVE, joghatóság).  

### 5.2 Tanító adatok  

- Historikus merge‑események, amelyeket utólagos megfelelőségi megállapításokkal címkéztek.  
- Szintetikus kontra‑faktikus példák, amelyeket az LLM generál (pl. „Mi történik, ha ez a csomag MIT licencet használ a GPL‑3.0 helyett?”).  

### 5.3 Inference késleltetés  

A GCN inference egy GPU‑gyorsított mikroszolgáltatásban fut, **<200 ms** alatt ad vissza pontszámot egy commitra, ami megfelel a CI/CD kapuk követelményeinek.  

---  

## 6. LLM‑alapú kontextuális szabályértelmezés  

A jogi szövegek gyakran homályosak. Az LLM (pl. finomhangolt GPT‑4o) a következőket végzi:  

1. **Klausza‑kivonás** – Azonosítja a releváns szakaszokat (licenc‑kompatibilitás, export‑korlátozások).  
2. **Szemantikus leképezés** – Átalakítja a természetes nyelvet gráf‑predikátumokká (`license_incompatible`, `requires_approval`).  
3. **Dinamikus promptolás** – Amikor új függőség jelenik meg, az LLM képes megválaszolni: „Ez a licenc megengedett egy felhő‑alapú SaaS termékben?” a jelenlegi gráf‑környezet felhasználásával.  

Az LLM továbbá **ember‑olvasható magyarázatokat** generál, amelyek a kockázati pontszám mellé kerülnek, ezzel teljesítve az auditkövetelményeket.  

---  

## 7. Null‑ismeret‑bizonyítékok a magánszféra‑megőrző auditokhoz  

A vállalatok gyakran nem akarják teljes SBOM‑jaikat külső auditoroknak megmutatni. **zk‑SNARK‑ok** segítségével a motor bizonyíthatja:  

- *„A kockázati pontszám ≤ 0.3, és minden szabály teljesült.”*  

a mögöttes csomaglista felfedése nélkül. A bizonyíték az immutable audit‑könyvtár bejegyzéséhez csatolódik, lehetővé téve a **bizalom nélküli ellenőrzést**.  

---  

## 8. Integráció CI/CD csővezetékekkel  

Egy tipikus GitHub Actions munkafolyamat:  

```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
```  

A pipeline **gyorsan hibát jelez**, megakadályozva a nem‑megfelelő kód beolvasztását, és azonnali javítási útmutatást ad a fejlesztőknek.  

---  

## 9. Biztonság, kormányzás és auditálás  

| Aggály | Enyhítés |
|--------|----------|
| **Adatszivárgás** – az SBOM tartalmazhat belső csomagneveket. | SBOM‑payload titkosítása; ZKP‑k használata a bizonyítékokhoz. |
| **Modell‑elavulás** – a GNN elavulhat új fenyegetések megjelenésekor. | Folyamatos tanulási ciklus: heti utólagos címkék beépítése. |
| **Szabály‑homályosság** – jogi frissítések félreértelmezése. | Ember‑a‑hurok felülvizsgálata az LLM‑generált szabályok beillesztése előtt. |
| **Auditálhatóság** – szükség van immutable bizonyítékra. | Append‑only napló (pl. Hyperledger Fabric) tárolja a pontszámot, bizonyítékot és időbélyeget. |

---  

## 10. Előnyök a szervezetek számára  

1. **Azonnali kockázati láthatóság** – A fejlesztők már kódolás közben látják a megfelelőségi hatást.  
2. **Csökkentett javítási költség** – A korai felismerés elkerüli a későbbi, drágább újratervezéseket.  
3. **Magyarázható döntések** – A GNN‑ és LLM‑magyarázatok megfelelnek a szabályozói elvárásoknak.  
4. **Skálázható több repo‑ra** – Az esemény‑alapú tervezés több ezer mikro‑szolgáltatás támogatására képes.  
5. **Privát‑first** – A ZKP‑k megőrzik a tulajdonosi komponensek titkosságát.  

---  

## 11. Implementációs ütemterv  

| Fázis | Mérföldkövek |
|-------|--------------|
| **0 – Alapok** | SBOM generálás, Kafka, Neo4j tudásgráf beállítása. |
| **1 – Alap‑pontozás** | Egyszerű szabály‑alapú kockázati motor (licenc + CVE) telepítése. |
| **2 – GNN prototípus** | GCN tanítása historikus merge‑ekre, API‑ba integrálása. |
| **3 – LLM szabály‑réteg** | LLM finomhangolása szabályozási korpuszon, szabály‑generálás hozzáadása. |
| **4 – ZKP integráció** | zk‑SNARK bizonyíték generálás a pontszám ellenőrzéséhez. |
| **5 – CI/CD beágyazás** | GitHub Actions / GitLab CI kapuk, false‑positive monitorozás. |
| **6 – Folyamatos tanulás** | Automatikus visszacsatolás audit‑eredményekből a GNN‑be. |

---  

## 12. Jövőbeli irányok  

- **Kereszt‑szervezeti tudásmegosztás** – Federált tanulás vállalatok között a nyers SBOM‑k megosztása nélkül a kockázati modellek javításához.  
- **Multimodális bizonyíték** – Kód‑analízis kombinálása bináris eredetiséggel és konténer‑image szkenneléssel.  
- **Adaptív kontra‑faktikus szimuláció** – Reinforcement learning használata a *legkevésbé kockázatos* alternatív függőség‑verziók javaslatához.  
- **Szabályozási digitális iker** – Szimuláció, amely megmutatja a közelgő jogszabályok hatását a teljes szoftverportfólióra.  

---  

## 13. Összegzés  

A nyílt forráskódú komponensek a modern szoftverek élettartamát meghatározzák, ugyanakkor egy folyamatosan változó megfelelőségi környezetet is hoznak magukkal. A **SBOM‑streamelés, önjavító tudásgráf, gráf neurális háló, LLM‑vezérelt szabály‑fordítás és null‑ismeret‑bizonyítékok** egyesítésével a bemutatott motor **valós‑időben, magyarázhatóan és adatvédelmi szempontból is biztonságosan** képes kockázati pontszámot szolgáltatni a fejlesztői eszközök közvetlenül a kezetekben tartva.  

Ennek az architektúrának a bevezetése a megfelelőséget egy lemaradt, utólagos szűkítőből **proaktív, folyamatos védelmi réteggé** alakítja – lehetővé téve a termékcsapatok számára, hogy gyorsabban szállítsanak, miközben szilárdan a jogi és biztonsági határokon belül maradnak.  

---  

## Lásd még  

- [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)