Az állami szoftver-fejlesztés Magyarországon egy jól bevett, strukturálisan problémás körben forog. A fejlesztés külső szállítótól érkezik, zárt forráskóddal, fix licencfeltételekkel. A karbantartás és a hibajavítás szintén a szállítóhoz kötött — az árazás nem ellenőrizhető, a kódba nem lehet belátni. Ha a szállító dönt — emeli az árat, kilép a piacról, csődöt jelent —, az intézmény kiszolgáltatott. Nem azért, mert rossz döntés volt a szállítót választani. Hanem mert a piac eddig nem kínált más modellt.
Közben Magyarországon több tízezer képzett fejlesztő, tesztelő, UX-tervező, kiberbiztonsági szakember dolgozik, akik szívesen járulnának hozzá az ország digitális működéséhez — de nincs erre semmilyen csatorna. Az állam a piacon vesz kódot, amelybe aztán senki nem láthat bele. Holott ennek a kódnak egy része biztonsági szempontból nem érzékeny. Egy ügyfélszolgálati portál frontendkódja, belső adminisztratív eszközök, dokumentációs felületek — ezeknél a nyilvánosság nem veszély. Ellenkezőleg: a „many eyes" elv alapján ezek éppen biztonságosabbak lennének, ha a szakmai közösség auditálhatja őket.
Ez az a pont, ahol a KözKód ötlete kezdődik.
Nem a GitHub — valami más
A KözKód nem egy nyilvános kódtárhely. A nyílt forráskód itt nem azt jelenti, hogy bárki betolhat kódot a Magyar Állam rendszereibe. Pontosan az ellenkezőjéről van szó.
A platform alapja az Ügyfélkapu+/DÁP azonosítás. Minden hozzájáruló azonosított — valódi neve, valódi személyisége mögött. Ez az a pont, ahol a KözKód alapvetően más, mint a GitHub. Ott anonim vagy pszeudo-anonim felhasználó is commit-olhat bármibe. Itt minden commit visszavezethető egy valódi, Ügyfélkapun belépett személyhez. Nem új regisztráció — a már meglévő állami azonosítási infrastruktúra, a KAÜ (Központi Azonosítási Ügynök) végzi el az azonosítást. Gyors, nem terheli a felhasználót, és az állam oldalán sem kér új rendszert.
Az első belépéskor a hozzájáruló aláírja a Hozzájárulói Megállapodást (CLA), amely tisztázza a szerzői jogi és felelősségi kérdéseket, majd kiválasztja a profilját: fejlesztő, tesztelő, dokumentáló, fordító, biztonsági kutató — vagy ezek kombinációja. Ezután hozzáférést kap minden nyilvánosan megnyitott projekthez: olvasásra és pull request beadásra.
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ód kizárólag az alap osztályba sorolt rendszereket és — rendkívül szigorú feltételek mellett — a jelentős osztályba sorolt rendszerek meghatározott, nem érzékeny moduljait engedi megnyitni. A magas osztály soha, semmilyen körülmények között.
Az alap osztályba kerülhet: belső adminisztratív eszközök, dokumentációs portálok, nyilvános tájékoztató felületek, e-learning rendszerek. Ezeket teljes egészükben meg lehet nyitni — feltéve, hogy nem tartalmaznak titkosítási kulcsokat, jelszavakat, hozzáférési tokeneket, IP-címeket, üzemeltetési konfigurációkat vagy személyes adatot mintaként. A megnyitásnak minden esetben előzménye van: az intézmény információbiztonsági felelőse (IBF) és a Nemzeti Kiberbiztonsági Intézet (NKI) együtt vizsgálja meg, mi nyitható meg. Formális határozat, meghatározott hatókörrel, kizárt komponensek listájával és felülvizsgálati ciklussal.
A jelentős osztálynál az IBF és a minisztérium képviselője együtt minősíti, hogy mely modulok nyithatók meg — általában UI-komponensek, frontend, dokumentáció, közös könyvtárak. A magas osztály: kritikus infrastruktúra, NIS2 hatálya alá tartozó rendszerek, adónyilvántartás, egészségügyi adatok. Ez nem kompromisszum — ez a rendszer egyik nem-megkérdőjelezhető alapfeltétele.
A megnyitott komponensek szerzői jogi szempontból engedélyezett licencek alatt jelenhetnek meg: EUPL 1.2 (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 e téren nem indul nulláról: az Állami Alkalmazás-fejlesztési Keretrendszer (ÁAFK) már ma is ezt a logikát valósítja meg szervezetek számára — egységes fejlesztési infrastruktúrát, közös komponenskönyvtárat és kontrollált kiadási folyamatot kínál az állami szoftverprojektekhez. A KözKód ebből a szempontból az ÁAFK természetes kiterjesztése: ugyanazt a megközelítést nyitja meg az ellenőrzött körülmények között dolgozó civil fejlesztők felé is. Nem párhuzamos rendszer — hanem a meglévő infrastruktúra közösségi dimenziója.
A forrás-megnyitó intézmények — minisztériumok, önkormányzatok, állami tulajdonú társaságok — döntik el, mit tesznek fel a platformra. A megnyitás az ő döntésük, de csak a minisztérium jóváhagyásával és az NKI kötelező, 15 napos határidejű véleménye alapján hozhatják meg.
A karbantartók az adott intézmény által kijelölt személyek — lehetnek belső munkatársak, de szerződéses szállítók képviselői is. Ők fogadják be a pull requesteket. A 4-szem elv kötelező: legalább két karbantartó jóváhagyása szükséges minden egyes változtatáshoz.
A hozzájárulók az Ügyfélkapun belépett, azonosított fejlesztők, tesztelők, technikai írók, UX-tervezők, biztonsági kutatók — mindenki, akinek van szakmai kompetenciája és ideje arra, hogy egy-egy feladatot felvállaljon.
A hozzájárulás folyamata
A mechanizmus pontosan az, amit egy vállalati GitHub-ban megszokott a fejlesztő. A hozzájáruló kiválaszt egy nyitott feladatot, vagy maga javasol egyet. A karbantartó hozzárendeli. A hozzájáruló a saját fork-jában dolgozik, majd pull requestet nyit. Automatizált ellenőrzések futnak le — szintaktikai ellenőrzés (linting), egységtesztek, biztonsági szkennelés (SAST), licenc-ellenőrzés. Ha ezek átmennek, következik a 4-szem emberi review. Befogadás esetén a kód a fő ágba kerül, és a hozzájárulás a felhasználó profiljához rendelődik.
Az intézmény bármikor szüneteltetheti vagy visszavonhatja a megnyitást. Ez nem kiskapu — ez a biztonságos működés egyik garanciája.
Miért csinálná bárki — az elismerési rendszer
Pénzt közvetlenül nem fizet senki a hozzájárulóknak. Ez szándékos — a közvetlen fizetés megváltoztatná a dinamikát, a motivációt és a jogi viszonyokat is. De az elismerés nem szimbolikus.
Minden befogadott hozzájárulás pontot ér, súlyozva a típusától és nehézségétől. A pontok három dimenzióban gyűlnek: fejlesztési pont (befogadott kód), minőségi pont (hibajelentések, tesztelés, biztonsági felfedezések) és közösségi pont (dokumentáció, fordítás, mentorálás). A pontok alapján szintek: Bronz → Ezüst → Arany → Platina → KözKód Nagykövet — nyilvános profilon megjelenítve.
Meghatározott szintek elérése után a hozzájáruló hivatalos, állam által kiállított, digitálisan aláírt tanúsítványt kap. Amiben szerepel: a hozzájárulás típusa és időszaka, az érintett projektek, az intézmények neve, és egy hitelesítő link. Ezt a tanúsítványt LinkedIn-en, önéletrajzban, közbeszerzési pályázatokban lehet hivatkozni. Ha valaki öt évet tölt azzal, hogy egy állami rendszer UI-ját folyamatosan karbantartja — azt ma sehogyan nem lehet hitelesen dokumentálni szakmai referenciaként. A KözKód-tanúsítvány ezt oldaná meg.
A rendszer mellé: éves KözKód Gála kiemelkedő hozzájárulóknak, lehetőség szakmai panelekbe és tanácsadó testületekbe kerülni, bug bounty program biztonsági hibák felfedezésére — pénzbeli díjazással, külön költségvetésből —, és egyes esetekben felkérés szerződéses munkára, összeférhetetlenségi szabályok mellett.
A technikai alap
A platform önállóan, magyar szervereken, állami felügyelet alatt fut. Alapja egy hardenelt, magán-üzemeltetésű Gitea, Forgejo vagy GitLab Community Edition — a nyílt forráskódú kódtárhelyek közül az, amelyik az adott pillanatban a legjobb kompromisszumot jelenti felügyelet, karbantarthatóság és funkciókészlet között.
A speciális modulok — KAÜ-integráció az Ügyfélkapu+ / DÁP belépéshez, CLA-modul, pontrendszer és tanúsítvány-modul — az alap platformra épülnek. Az automatizált pipeline kötelező: titkok keresése (gitleaks, trufflehog), függőségaudit (OWASP Dependency-Check), SAST (Semgrep, SonarQube), licenc-ellenőrzés (FOSSA, Scancode). Az auditnapló minden hozzáférést, commitot, review-t WORM tárolóban rögzít — módosíthatatlan, tartós.
És a legfontosabb: a platform önmaga is nyílt forráskódú projektként működjön, saját kódja is a platformon hostolva. Így a közösség javíthatja és auditálhatja azt a rendszert, amelyen a közösségi hozzájárulás folyik.
A kockázatok
A legkomolyabb kockázat a supply chain támadás: egy hozzájáruló szándékosan sebezhető kódot próbál bevinni. A védekezés rétegelt — kötelező 4-szem elv, automatikus SAST és függőségaudit, NKI random ellenőrzés, hozzájárulói előtörténet figyelése. De nem tévedhetetlen. A modell kizárólag azért működhet, mert a megnyitható rendszerek köre szigorúan korlátozott — egy alap osztályú belső adminisztrációs eszközbe bevitt sebezhetőség és egy érzékeny ügyintézési rendszerbe bevitt sebezhetőség között éles különbség van.
A karbantartói kapacitáshiány talán a legvalósabb kockázat. Ha az intézménynek nincs emberórája a beérkező pull requesteket átnézni, a közösség elhal. Ezért a megnyitás engedélyezésének feltétele a karbantartói kapacitás bemutatása — és jó esetben egy központi karbantartói pool kialakítása, ahová az intézmény delegálhat.
A GDPR-megfelelés kezelendő: a hozzájárulók azonosítása személyes adat. A megoldás adattakarékos — nyilvánosan csak pszeudonim jelenik meg, a valódi azonosító kizárólag a platformüzemeltetőnél, jogszabályi alapon kezelve. A szellemi tulajdon kérdéseit a kötelező CLA és a DCO (Developer Certificate of Origin) tisztázza — minden commit aláírt, a szerzőség nem vitatható.
A politikai instabilitás reális kockázat — egy modell, amely csak egy kormányzati ciklusig él, nem épít bizalmat. A válasz: törvényi szintű rögzítés, széleskörű parlamenti és szakmai konszenzus, csatlakozás az EU-s közigazgatási nyílt forrás kezdeményezésekhez EUPL-alapon, ami Brüsszeli szinten is láthatóvá és védhetővé teszi a modellt.
Az ütemterv
Három fázis. Az első hat hónapban: jogszabályi háttér kidolgozása (végrehajtási rendelet vagy önálló kormányrendelet), intézményi szerepkörök kijelölése, műszaki specifikáció, CLA és etikai kódex megírása.
Hat és tizennyolc hónap között: pilot, zárt körben. Két-három önként jelentkező intézmény — egy minisztérium, egy nagyváros önkormányzata, egy állami hivatal — nyit meg egy-egy alap osztályú projektet. Korlátozott hozzájárulói kör, meghívás alapján, kb. 100-200 fő. Visszamérés, finomítás.
Tizennyolc hónaptól: nyitott regisztráció minden Ügyfélkapu+/DÁP felhasználó számára. Tanúsítványrendszer és pontrendszer élesítése. Bug bounty program. Jelentős osztályú komponensek óvatos megnyitása. Csatlakozás az EU-s közigazgatási nyílt forrás kezdeményezésekhez.
Zárszó
A KözKód nem utópia. Az elemek mind léteznek: az Ügyfélkapu már működik, a Gitea/Forgejo már működik, a supply chain audit eszközök már léteznek, az EUPL már egy validált licenc. A kérdés nem az, hogy lehetséges-e — hanem hogy van-e politikai akarat és intézményi elkötelezettség megcsinálni.
Ha igen, Magyarország az elsők között lehet az EU-ban, amely a „kontrollált állami nyílt forráskód" modellt valóban megvalósítja — nem szimbólumként, hanem operatív infrastruktúraként. Ez valami olyasmi, amire a civil szakmai közösség régóta vár, az állam hasznát veszi, és az EU-s szinten is látható lenne.
A modell sikere három tényezőn múlik: a kellően óvatos, kockázatorientált jogi keret megalkotásán; az intézményi vezetők elköteleződésén; és a szakmai közösség bizalmán abban, hogy hozzájárulása valódi, nem szimbolikus hatást gyakorol az állam működésére.