Az állami szoftverfejlesztés Magyarországon régóta ugyanabban a rossz körben forog. A fejlesztést külső szállító végzi, zárt forráskóddal, rögzített licencfeltételekkel. A karbantartás és a hibajavítás is a szállítóhoz kötött, az árakat nem lehet ellenőrizni, a kódba nem lehet belelátni. Ha a szállító emeli az árat, kilép a piacról vagy csődbe megy, az intézmény kiszolgáltatott. Nem azért, mert rosszul választott szállítót, hanem mert a piacon eddig nem volt más modell.
Közben Magyarországon több tízezer képzett fejlesztő, tesztelő, UX-tervező és kiberbiztonsági szakember dolgozik, akik közül sokan szívesen segítenének az ország digitális működésében, csak nincs rá csatorna. Az állam a piacon vesz kódot, amelybe aztán senki nem láthat bele, pedig ennek a kódnak egy része biztonsági szempontból nem érzékeny. Egy ügyfélszolgálati portál frontendkódjánál, a belső adminisztratív eszközöknél vagy a dokumentációs felületeknél a nyilvánosság nem veszély. A „many eyes" elv szerint ezek épp biztonságosabbak lennének, ha a szakmai közösség átnézhetné őket.
Innen indul a KözKód ötlete.
Miben más, mint a GitHub?
A KözKód nem nyilvános kódtárhely. A nyílt forráskód itt nem azt jelenti, hogy bárki kódot tolhat be a magyar állam rendszereibe, hanem éppen azt, hogy ez csak szigorú szabályok szerint lehetséges.
A platform az Ügyfélkapu+/DÁP azonosításra épül, minden hozzájáruló a valódi nevével, azonosítva dolgozik. Ebben különbözik leginkább a GitHubtól, ahol névtelen vagy álnevű felhasználó is commitolhat bármibe. Itt minden commit visszavezethető egy valódi, Ügyfélkapun belépett emberhez. Új regisztráció nem kell, az azonosítást a meglévő állami rendszer, a KAÜ (Központi Azonosítási Ügynök) végzi. Ez gyors, nem terheli a felhasználót, és az államnak sem kell hozzá új rendszert építenie.
Az első belépéskor a hozzájáruló aláírja a Hozzájárulói Megállapodást (CLA), amely rendezi a szerzői jogi és felelősségi kérdéseket, aztán kiválasztja a profilját: fejlesztő, tesztelő, dokumentáló, fordító, biztonsági kutató, vagy ezek közül több. Ezután minden nyilvánosan megnyitott projektet olvashat, és pull requestet nyújthat be hozzájuk.
Mit lehet megnyitni, és mit nem?
A 2024. évi LXIX. törvény, a kiberbiztonsági törvény három biztonsági osztályt különböztet meg: alap, jelentős és magas. A KözKódban csak az alap osztályba sorolt rendszereket lehet megnyitni, és nagyon szigorú feltételekkel a jelentős osztályú rendszerek bizonyos, nem érzékeny moduljait. A magas osztályú rendszereket semmilyen körülmények között nem.
Az alap osztályba tartoznak például a belső adminisztratív eszközök, a dokumentációs portálok, a nyilvános tájékoztató felületek és az e-learning rendszerek. Ezeket teljes egészükben meg lehet nyitni, ha nincs bennük titkosítási kulcs, jelszó, hozzáférési token, IP-cím, üzemeltetési konfiguráció, és mintaként sem tartalmaznak személyes adatot. A megnyitás előtt mindig az intézmény információbiztonsági felelőse (IBF) és a Nemzeti Kiberbiztonsági Intézet (NKI) közösen megvizsgálja, mi nyitható meg. Erről formális határozat születik, amely rögzíti a hatókört, a kizárt komponensek listáját és a felülvizsgálat gyakoriságát.
A jelentős osztálynál az IBF és a minisztérium képviselője közösen dönti el, mely modulok nyithatók meg. Ezek általában UI-komponensek, frontend, dokumentáció és közös könyvtárak. A magas osztályba a kritikus infrastruktúra, a NIS2 hatálya alá tartozó rendszerek, az adónyilvántartás és az egészségügyi adatok tartoznak. Ezen a határon nem lehet alkudni, a rendszer erre épül.
A megnyitott komponensek ezek alatt a licencek alatt jelenhetnek meg: EUPL 1.2 (ez az ajánlott, az EU saját közigazgatási nyílt licence), MIT vagy Apache 2.0.
A szereplők
A platformot a digitalizációért felelős minisztérium vagy az általa kijelölt szerv (IdomSoft, NISZ, DÁP Ügynökség) üzemelteti. Ők tartják fenn a kódtárhelyet, a CI/CD rendszert és az azonosítási integrációt.
Az IdomSoft ebben nem a nulláról indul. Az Állami Alkalmazás-fejlesztési Keretrendszer (ÁAFK) már ma is így működik a szervezetek felé: egységes fejlesztési infrastruktúrát, közös komponenskönyvtárat és ellenőrzött kiadási folyamatot ad az állami szoftverprojekteknek. A KözKód ennek a kiterjesztése: ugyanezt a megközelítést nyitja meg az ellenőrzött feltételekkel dolgozó civil fejlesztők felé. Nem párhuzamos rendszer lenne, hanem a meglévő infrastruktúra közösségi része.
Azt, hogy mi kerül fel a platformra, a forrást megnyitó intézmények (minisztériumok, önkormányzatok, állami tulajdonú társaságok) döntik el. A döntést csak a minisztérium jóváhagyásával és az NKI kötelező véleménye alapján hozhatják meg, amelyre az NKI-nek 15 napja van.
A karbantartókat az intézmény jelöli ki. Lehetnek belső munkatársak vagy szerződéses szállítók képviselői, és ők fogadják be a pull requesteket. A négy szem elve kötelező: minden változtatást legalább két karbantartónak jóvá kell hagynia.
A hozzájárulók az Ügyfélkapun belépett, azonosított fejlesztők, tesztelők, technikai írók, UX-tervezők és biztonsági kutatók, vagyis mindenki, akinek van hozzá szakértelme és ideje, hogy elvállaljon egy-egy feladatot.
A hozzájárulás folyamata
A folyamat ugyanaz, amit a fejlesztő egy vállalati GitHubon megszokott. A hozzájáruló kiválaszt egy nyitott feladatot, vagy maga javasol egyet, és a karbantartó hozzárendeli. A hozzájáruló a saját forkjában dolgozik, aztán pull requestet nyit. Ekkor lefutnak az automatikus ellenőrzések: szintaktikai ellenőrzés (linting), egységtesztek, biztonsági szkennelés (SAST) és licencellenőrzés. Ha ezek átmennek, két ember átnézi a kódot. Ha befogadják, a kód a fő ágba kerül, és a hozzájárulás megjelenik a felhasználó profiljában.
Az intézmény bármikor szüneteltetheti vagy visszavonhatja a megnyitást. Ez is a biztonságos működést szolgálja.
Miért csinálná bárki? Az elismerési rendszer
A hozzájárulók közvetlenül nem kapnak pénzt. Ez szándékos, mert a fizetés megváltoztatná a motivációt és a jogi viszonyokat is. Az elismerésnek viszont kézzelfogható haszna van.
Minden befogadott hozzájárulás pontot ér, a típusától és a nehézségétől függően. A pontok három külön számlán gyűlnek: fejlesztési pont (befogadott kód), minőségi pont (hibajelentés, tesztelés, biztonsági hiba felfedezése) és közösségi pont (dokumentáció, fordítás, mentorálás). A pontok alapján a hozzájáruló szinteket ér el (Bronz → Ezüst → Arany → Platina → KözKód Nagykövet), és ezek a nyilvános profilján látszanak.
Bizonyos szintek elérése után a hozzájáruló hivatalos, az állam által kiállított, digitálisan aláírt tanúsítványt kap. Ebben szerepel a hozzájárulás típusa és időszaka, az érintett projektek, az intézmények neve és egy hitelesítő link. A tanúsítványra hivatkozni lehet a LinkedInen, az önéletrajzban és közbeszerzési pályázatokban. Ha ma valaki öt évig karbantartja egy állami rendszer felhasználói felületét, ezt semmilyen módon nem tudja hitelesen igazolni szakmai referenciaként. A KözKód-tanúsítvány ezt oldaná meg.
Emellett lenne éves KözKód Gála a kiemelkedő hozzájárulóknak, lehetőség szakmai panelekbe és tanácsadó testületekbe kerülni, bug bounty program a biztonsági hibák felfedezőinek (pénzdíjjal, külön költségvetésből), és egyes esetekben felkérés szerződéses munkára, összeférhetetlenségi szabályokkal.
A technikai alap
A platform önállóan, magyar szervereken, állami felügyelet alatt fut. Az alapja egy megerősített biztonságú, saját üzemeltetésű Gitea, Forgejo vagy GitLab Community Edition, vagyis az a nyílt forráskódú kódtárhely, amelyik a döntés pillanatában a legjobb egyensúlyt adja a felügyelhetőség, a karbantarthatóság és a funkciók között.
Az alap platformra épülnek a saját modulok: KAÜ-integráció az Ügyfélkapu+ / DÁP belépéshez, CLA-modul, pontrendszer és tanúsítványmodul. Az automatikus pipeline kötelező: titkok keresése (gitleaks, trufflehog), függőségaudit (OWASP Dependency-Check), SAST (Semgrep, SonarQube), licencellenőrzés (FOSSA, Scancode). Az auditnapló minden hozzáférést, commitot és review-t WORM tárolóban rögzít, ahol utólag nem módosítható.
Fontos, hogy a platform maga is nyílt forráskódú projekt legyen, és a saját kódja is rajta legyen. Így a közösség javíthatja és ellenőrizheti azt a rendszert is, amelyen dolgozik.
A kockázatok
A legkomolyabb kockázat az ellátási lánc elleni (supply chain) támadás, amikor egy hozzájáruló szándékosan sebezhető kódot próbál bejuttatni. Ez ellen több réteg véd: a kötelező négy szem elve, az automatikus SAST és függőségaudit, az NKI szúrópróbaszerű ellenőrzése és a hozzájárulók előtörténetének figyelése. Tévedhetetlen egyik sem. A modell csak azért működhet, mert szigorúan korlátozott, mely rendszereket lehet megnyitni: egy alap osztályú belső adminisztrációs eszközbe bevitt sebezhetőség sokkal kisebb baj, mint egy érzékeny ügyintézési rendszerbe bevitt.
A legvalószínűbb kockázat talán az, hogy nem lesz elég karbantartó. Ha az intézménynek nincs embere a beérkező pull requestek átnézésére, a közösség elhal. Ezért a megnyitás csak akkor engedélyezhető, ha az intézmény igazolja, hogy van karbantartói kapacitása, és jó lenne egy központi karbantartói csapat is, ahová az intézmények embert delegálhatnak.
A GDPR-t is kezelni kell, mert a hozzájárulók azonosítása személyes adat. A megoldás adattakarékos: nyilvánosan csak álnév jelenik meg, a valódi azonosítót kizárólag a platform üzemeltetője kezeli, jogszabályi alapon. A szellemi tulajdon kérdéseit a kötelező CLA és a DCO (Developer Certificate of Origin) rendezi: minden commit alá van írva, így a szerzőség nem vitatható.
A politikai instabilitás valós kockázat: egy modellben, amely csak egy kormányzati ciklusig él, senki nem fog megbízni. Ezért törvényben kell rögzíteni, széles parlamenti és szakmai egyetértéssel, és EUPL-alapon csatlakozni kell az EU közigazgatási nyílt forráskódú kezdeményezéseihez, amelyek révén a modell Brüsszelben is látható és védhető lesz.
Az ütemterv
Az ütemterv három szakaszból áll. Az első hat hónapban ki kell dolgozni a jogszabályi hátteret (végrehajtási rendeletet vagy önálló kormányrendeletet), ki kell jelölni az intézményi szerepköröket, és meg kell írni a műszaki specifikációt, a CLA-t és az etikai kódexet.
A 6. és a 18. hónap között zárt körű pilot fut. Két-három önként jelentkező intézmény (például egy minisztérium, egy nagyváros önkormányzata és egy állami hivatal) megnyit egy-egy alap osztályú projektet. A hozzájárulók köre szűk, meghívásos, kb. 100–200 fő. Az eredményeket mérjük, és ezek alapján finomítunk.
A 18. hónaptól minden Ügyfélkapu+/DÁP felhasználó regisztrálhat. Élesedik a tanúsítvány- és a pontrendszer, elindul a bug bounty program, óvatosan megnyílnak a jelentős osztályú komponensek, és a platform csatlakozik az EU közigazgatási nyílt forráskódú kezdeményezéseihez.
Zárszó
A KözKód minden eleme létezik már: az Ügyfélkapu és a Gitea/Forgejo működik, az ellátási lánc auditálására vannak eszközök, az EUPL bevált licenc. Technikailag tehát megvalósítható. Az a kérdés, van-e hozzá politikai akarat, és vállalják-e az intézmények.
Ha igen, Magyarország az elsők között lehet az EU-ban, ahol az „ellenőrzött állami nyílt forráskód" ténylegesen, működő infrastruktúraként megvalósul. A civil szakmai közösség régóta vár ilyesmire, az államnak haszna lenne belőle, és uniós szinten is feltűnne.
A modell sikere azon múlik, hogy sikerül-e kellően óvatos, a kockázatokból kiinduló jogi keretet alkotni, kiállnak-e mellette az intézmények vezetői, és elhiszi-e a szakmai közösség, hogy a munkájával valóban hat az állam működésére.
Weboldal és kód
A KözKód saját weboldala: kozkod.hu. A weboldal és a kiszolgáló-infrastruktúra kódja nyílt, GitHubon olvasható: kozkod_webpage és kozkod_infra.