# Silnik Oceny Ryzyka Zgodności Open Source w Czasie Rzeczywistym z Wykorzystaniem AI  

Przedsiębiorstwa coraz częściej budują produkty na bazie komponentów open‑source. Choć przyspiesza to innowacje, wprowadza także zmienny zestaw wymogów licencyjnych, podatności i regulacji. Tradycyjne kontrole zgodności uruchamiane są nocą lub na żądanie, pozostawiając okno, w którym nowo wprowadzona zależność może naruszyć politykę, zanim ktoś to zauważy.  

**A co jeśli zgodność mogłaby być oceniana w momencie, gdy zależność pojawi się w pull request, z wynikiem ryzyka, który wyjaśnia *dlaczego* i *jak* naprawić problem?**  

W tym artykule projektujemy **silnik oceny ryzyka zgodności open‑source w czasie rzeczywistym**, który łączy dane **Software Bill of Materials (SBOM)**, **samonaprawiający się graf wiedzy**, **sieci neuronowe grafowe (GNN)** do wnioskowania strukturalnego ryzyka oraz **duże modele językowe (LLM)** do kontekstowej interpretacji polityk. Rozwiązanie zawiera także **dowody zerowej wiedzy (Zero‑Knowledge Proofs, ZKP)**, aby chronić własny kod przy jednoczesnym udowodnieniu zgodności.  

> **Kluczowe wnioski**  
> - Architektura strumieniująca aktualizacje SBOM do żywego grafu wiedzy o zgodności.  
> - Ocena oparta na GNN, która uwzględnia ryzyko tranzytywne w drzewach zależności.  
> - Tłumaczenie polityk przez LLM, które zamienia tekst prawny na reguły czytelne dla maszyn.  
> - Weryfikacja przy użyciu ZKP, zapewniająca bezpieczne i audytowalne dowody zgodności.  

---  

## 1. Dlaczego Zgodność Open‑Source Wymaga Inteligencji w Czasie Rzeczywistym  

| Wyzwanie | Tradycyjne podejście | Luka w czasie rzeczywistym |
|-----------|----------------------|---------------------------|
| **Dryf licencji** – nowa zależność wprowadza licencję copyleft. | Skany nocne, ręczna naprawa. | Naruszenie może zostać scalone przed wykryciem. |
| **Rozprzestrzenianie się podatności** – CVE w zależności tranzytywnej. | Cotygodniowe bazy podatności, opóźnione łatanie. | Powierzchnia ataku istnieje w czasie opóźnienia. |
| **Ograniczenia regulacyjne** – kontrola eksportu, rezydencja danych. | Kwartalne przeglądy polityk. | Jednostki biznesowe mogą nieświadomie naruszyć przepisy. |
| **Pochodzenie łańcucha dostaw** – nieznane pochodzenie komponentu. | Ręczne kontrole pochodzenia. | Brak gwarancji autentyczności w momencie scalania. |

Ocena w czasie rzeczywistym eliminuje te luki, **oceniając każdą zmianę w momencie integracji kodu** i dostarczając natychmiastowy, akcyjny wynik ryzyka.  

---  

## 2. Architektura wysokiego poziomu  

```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)"]
```  

*Rysunek 1 – Rzeczywisty pipeline oceny ryzyka zgodności open‑source.*  

### 2.1 Przegląd komponentów  

| Komponent | Rola |
|-----------|------|
| **Generator SBOM** | Tworzy pełną listę zależności (w tym tranzytywne krawędzie) dla każdego commitu. |
| **Strumień zdarzeń** | Gwarantuje niskie opóźnienie dostarczania aktualizacji SBOM do usług downstream. |
| **Usługa grafu wiedzy** | Przechowuje encje (pakiety, licencje, CVE, regulacje) i ich relacje; samonaprawia się dzięki Retrieval‑Augmented Generation (RAG). |
| **Silnik oceny GNN** | Uczy się propagacji ryzyka w grafie, zwracając numeryczny wynik dla każdego węzła oraz agregat dla commitu. |
| **Interpreter polityk LLM** | Przekształca teksty prawne i regulacyjne w reguły grafowe (np. „GPL‑3.0 nie może pojawić się w produktach SaaS”). |
| **API wyniku ryzyka** | Udostępnia wynik i wyjaśnienie CI/CD oraz narzędziom deweloperskim. |
| **Generator dowodów ZKP** | Tworzy kryptograficzne dowody, że wynik spełnia politykę bez ujawniania własnego kodu. |
| **Rejestr audytu zgodności** | Niezmienny log (blockchain lub magazyn append‑only) dla audytorów. |

---  

## 3. Pobieranie danych – od kodu do grafu  

1. **Ekstrakcja SBOM** – Narzędzia takie jak *Syft* lub *Trivy* uruchamiane są jako pre‑commit hook, emitując dokument CycloneDX lub SPDX.  
2. **Normalizacja** – Konwersja identyfikatorów pakietów do kanonicznej formy (purl).  
3. **Wzbogacenie** – Zapytania do źródeł zewnętrznych (NVD, OSV, SPDX License List, listy kontroli eksportu) i dołączanie atrybutów (waga, typ licencji, jurysdykcja).  
4. **Strumieniowanie** – Publikacja wzbogaconego SBOM jako zdarzenia JSON do tematów Kafka `sbom.raw` i `sbom.enriched`.  

Pipeline pobierania jest **idempotentny**; ponowne przetworzenie tego samego commitu daje ten sam stan grafu, co jest kluczowe dla powtarzalnych audytów.  

---  

## 4. Budowa grafu wiedzy i samonaprawa  

Schemat grafu obejmuje:  

- **Węzły Pakiet** (nazwa, wersja, purl).  
- **Węzły Licencja** (identyfikator SPDX, macierz kompatybilności).  
- **Węzły Podatność** (CVE, CVSS, wersja naprawcza).  
- **Węzły Regulacja** (np. GDPR Art. 32, US Export Control).  
- **Typy krawędzi**: `DEPENDS_ON`, `HAS_LICENSE`, `HAS_VULNERABILITY`, `SUBJECT_TO`.  

### 4.1 Samonaprawa przy użyciu Retrieval‑Augmented Generation  

Gdy opublikowana zostanie nowa regulacja, system:  

1. Pobiera surowy tekst za pomocą LLM‑wzbogaconego web‑crawlera.  
2. Generuje reguły grafowe (np. `IF package.license = "GPL-3.0" AND product.type = "SaaS" THEN risk += 0.8`).  
3. Wstawia lub aktualizuje węzły/krawędzie automatycznie, zapewniając aktualność grafu bez ręcznych migracji.  

---  

## 5. Ocena w czasie rzeczywistym przy użyciu sieci neuronowych grafowych  

### 5.1 Projekt modelu  

- **Wejście**: Podgraf zakorzeniony w zmienionym pakiecie, wzbogacony o cechy węzłów (waga licencji, wynik CVSS, flaga regulacyjna).  
- **Architektura**: **Graph Convolutional Network (GCN)** z warstwą **Readout**, która agreguje osadzenia węzłów do wektora poziomu commitu.  
- **Wyjście**:  
  - **Wynik ryzyka** ∈ [0, 1] (wyższy = bardziej ryzykowny).  
  - **Wektor wyjaśniający** wskazujący czynniki przyczyniające się (licencja, CVE, jurysdykcja).  

### 5.2 Dane treningowe  

- Historyczne zdarzenia scalania oznaczone wynikami po‑mortem dotyczącymi zgodności.  
- Syntetyczne przykłady kontrfaktyczne generowane przez LLM (np. „Co by było, gdyby ten pakiet używał licencji MIT zamiast GPL?”).  

### 5.3 Latencja inferencji  

Inferencja GCN działa w mikro‑serwisie przyspieszonym GPU, dostarczając wyniki w **<200 ms** na commit, co spełnia wymagania bramek CI/CD.  

---  

## 6. Interpretacja polityk kontekstowych przy użyciu LLM  

Teksty prawne są często niejednoznaczne. LLM (np. dostrojony GPT‑4o) wykonuje:  

1. **Ekstrakcję klauzul** – Identyfikuje istotne sekcje (kompatybilność licencji, ograniczenia eksportowe).  
2. **Mapowanie semantyczne** – Konwertuje język naturalny na predykaty grafowe (`license_incompatible`, `requires_approval`).  
3. **Dynamiczne promptowanie** – Gdy pojawi się nowa zależność, LLM może odpowiedzieć „Czy ta licencja jest dozwolona dla produktu SaaS hostowanego w chmurze?” wykorzystując bieżący kontekst grafu.  

LLM generuje także **wyjaśnienia w języku naturalnym**, które towarzyszą wynikowi ryzyka, spełniając wymogi audytowe.  

---  

## 7. Dowody zerowej wiedzy dla prywatnych audytów  

Przedsiębiorstwa mogą nie chcieć udostępniać pełnych SBOM‑ów zewnętrznym audytorom. Dzięki **zk‑SNARKs** silnik może udowodnić:  

- *„Wynik ryzyka jest ≤ 0.3 i wszystkie reguły polityki są spełnione.”*  

bez ujawniania szczegółowej listy pakietów. Dowód jest dołączany do niezmiennego wpisu w rejestrze audytu, umożliwiając **weryfikację bez zaufania**.  

---  

## 8. Integracja z pipeline’ami CI/CD  

Przykładowy 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
```  

Pipeline **zatrzymuje się natychmiast**, zapobiegając scaleniu niezgodnego kodu i dostarcza deweloperom natychmiastową ścieżkę naprawczą.  

---  

## 9. Bezpieczeństwo, zarządzanie i audyt  

| Obawa | Środek zaradczy |
|-------|-----------------|
| **Wycieki danych** – SBOM może zawierać wewnętrzne nazwy pakietów. | Szyfrowanie ładunku SBOM; użycie ZKP przy generowaniu dowodów. |
| **Dryf modelu** – GNN może stać się przestarzały w miarę pojawiania się nowych zagrożeń. | Ciągła pętla uczenia: cotygodniowe wprowadzanie etykiet po‑mortem. |
| **Niejednoznaczność polityk** – Aktualizacje prawne mogą być źle zinterpretowane. | Przegląd człowieka nad regułami generowanymi przez LLM przed ich wstawieniem do grafu. |
| **Audytowalność** – Konieczność niezmiennych dowodów. | Rejestr append‑only (np. Hyperledger Fabric) przechowuje wynik, dowód i znacznik czasu. |

---  

## 10. Korzyści dla organizacji  

1. **Natychmiastowa widoczność ryzyka** – Deweloperzy widzą wpływ zgodności w czasie kodowania.  
2. **Obniżone koszty napraw** – Wczesne wykrycie unika kosztownego refaktoryzowania później.  
3. **Decyzje wyjaśnialne** – Wyjaśnienia GNN i LLM spełniają wymogi regulatorów.  
4. **Skalowalność** – Projekt oparty na zdarzeniach obsługuje tysiące mikro‑serwisów.  
5. **Priorytet prywatności** – ZKPs chronią poufne szczegóły komponentów.  

---  

## 11. Plan wdrożenia  

| Faza | Kamienie milowe |
|------|-----------------|
| **0 – Fundamenty** | Konfiguracja generowania SBOM, Kafka i grafu Neo4j. |
| **1 – Podstawowa ocena** | Uruchomienie prostego silnika opartego na regułach (licencja + CVE). |
| **2 – Prototyp GNN** | Trening GCN na historycznych scalaniach, integracja z API. |
| **3 – Warstwa polityk LLM** | Dostosowanie LLM do korpusów regulacyjnych, generowanie reguł. |
| **4 – Integracja ZKP** | Implementacja generatora dowodów zk‑SNARK dla weryfikacji wyniku. |
| **5 – Osadzenie w CI/CD** | Dodanie bramek GitHub Actions / GitLab CI, monitorowanie fałszywych alarmów. |
| **6 – Ciągłe uczenie** | Automatyzacja pętli sprzężenia zwrotnego z wynikami audytów. |

---  

## 12. Kierunki rozwoju  

- **Współdzielenie wiedzy między organizacjami** – Uczenie federacyjne, które poprawia modele ryzyka bez udostępniania surowych SBOM‑ów.  
- **Dowody multimodalne** – Połączenie analizy kodu, pochodzenia binariów i skanowania obrazów kontenerów.  
- **Adaptacyjne symulacje kontrfaktyczne** – Wykorzystanie uczenia ze wzmocnieniem do sugerowania *najmniej ryzykownej* alternatywnej wersji zależności.  
- **Cyfrowy bliźniak regulacyjny** – Symulacja wpływu nadchodzących przepisów na cały portfel oprogramowania.  

---  

## 13. Podsumowanie  

Komponenty open‑source są krwią współczesnego oprogramowania, ale jednocześnie wprowadzają nieustannie zmieniający się krajobraz wymogów zgodności. Dzięki **połączeniu strumieniowania SBOM, samonaprawiającego się grafu wiedzy, sieci neuronowych grafowych, tłumaczenia polityk przez LLM oraz dowodów zerowej wiedzy**, proponowany silnik dostarcza **wyniki ryzyka w czasie rzeczywistym, wyjaśnialne i chroniące prywatność**, dostępne od razu w rękach dewelopera.  

Przyjęcie tej architektury przekształca zgodność z wąskim wąskim gardłem w proaktywny, ciągły strażnik – umożliwiając zespołom produktowym szybsze wypuszczanie oprogramowania przy jednoczesnym pozostaniu w granicach prawnych i bezpieczeństwa.  

---  

## Zobacz także  
- [Open Source Software Bill of Materials (SBOM) – Specyfikacja SPDX](https://spdx.dev)  
- [Sieci neuronowe grafowe dla propagacji ryzyka – wykład Stanford CS224W](https://web.stanford.edu/class/cs224w/)  
- [Dowody zerowej wiedzy w bezpiecznym audycie – społeczność ZKProof](https://zkproof.org)  
- [Retrieval‑Augmented Generation dla automatycznej naprawy grafu wiedzy – arXiv:2403.01234](https://arxiv.org/abs/2403.01234)