CISA nyílt forráskódú biztonsági útmutatót adott ki: a különbség az ellenőrizhetőség

enlightened Ez az oldal a közösségért készül. heart Kövess minket máshol is:  Linux Mint Magyar Közösség a Mastodon-on  Telegram csatorna – csak hírek  Beszélgessünk a Telegram – Linux csevegő csoport  Hírek olvasása RSS segítségével  Linux Mint Hivatalos Magyar Közösség a Facebook-on      Linux Mint Baráti Kör a Facebook-on
wink Ha hasznosnak találod, és szeretnéd, hogy folytatódjon, támogasd a munkát Ko-fi vagy Paypal segítségével. laugh

kami911 képe

2026. július 30-án az Egyesült Államok Cybersecurity and Infrastructure Security Agency-je (CISA) kiadta az Open Source Software: Security Principles and Practices című, 31 oldalas útmutatót a szövetségi polgári ügynökségek számára. Az anyag ingyenesen elérhető, és TLP:CLEAR minősítést kapott, vagyis korlátozás nélkül terjeszthető.

A dokumentum az amerikai szövetségi ügynökségeknek szól, és két, a szövetségi kiberbiztonságról szóló elnöki rendeletben előírt kötelezettséget teljesít. Négy területet fed le: nyílt forráskódú megoldások használata, közreműködés nyílt forráskódú projektekben, nyílt forráskódú szoftver fejlesztése, valamint nyílt forráskódú mesterséges intelligencia modellek értékelése. Az alábbi megállapítások az első három területre vonatkoznak.

A dokumentum elemző része nem joghatóság-specifikus, így más országok közigazgatásai – köztük az európaiak – is hasznosnak találhatják. A kockázatkezelés nyelvén fogalmazza meg azokat az álláspontokat, amelyeket a nyílt forráskódú közösség már két évtizede képvisel.

Mit mond valójában az útmutató

A központi állítás jóval pontosabb annál, mint amit a címek sugallnak. A CISA nem azt állítja, hogy a nyílt forráskódú szoftver biztonságosabb lenne a proprietáris szoftvernél. Azt mondja ki, hogy a nyílt forráskódú szoftver „nem kockázatosabb és nem is kevésbé kockázatos, mint más szoftver”, és a különbséget máshová helyezi: nyílt forráskód esetén a szervezet közvetlenül tudja értékelni a kód minőségét és biztonságát, nem csak a gyártó ígéreteire hagyatkozik.

Ez az állítás a verifikálhatóságról szól, nem a hibaarányokról. Védhetőbb állítás, és a beszerzések szempontjából is sokkal fontosabb. Ha egy ügynökség proprietáris szoftvert vizsgál, valójában a gyártó saját termékéről szóló állításait értékeli. Ha nyílt forráskódú szoftvert vizsgál, magát a terméket értékeli.

Az útmutató a következményt is kimondja. Az egyik felsorolt előny a szövetségi ügynökségek számára a kisebb mértékű gyártófüggés: a nyílt szabványok és a módosítható kód megvédik az ügynökségeket a „proprietáris függőségi csapdáktól” – írja a CISA. Egy nemzeti kiberbiztonsági hatóság a gyártófüggést egy biztonsági dokumentumban helyezte el, nem pedig a versenypolitika területén. Ez érdemi elmozdulás abban, hogy hol lehet erről a kérdésről beszélni.

A C4 keretrendszer

Az útmutató leggyakorlatiabb része az A melléklet, amely bemutatja a C4 keretrendszert annak megítélésére, hogy egy nyílt forráskódú projekt mennyire trustre méltó. A kiindulópont az, hogy mivel a közreműködők lehetnek álnéven jelen, és nem kötelesek szállítani, a trustre nem abból ítélhető meg, hogy ki készítette a szoftvert. Abból kell megítélni, hogyan készült a szoftver – amit a nyílt forráskódú fejlesztés láthatóvá tesz, a zárt fejlesztéssel ellentétben.

A C4 négy kategóriába rendezi a bizonyítékokat:

  • Codebase – a commitok frissessége, ismert sebezhetőségek, függőségek naprakészsége.
  • Közösség – karbantartók száma, intézményi struktúra, illetve hogy a projekt valamely alapítvány keretében működik-e.
  • Magatartás – van-e sebezhetőségek bejelentésére vonatkozó szabályzat, kötelező-e a code review, a karbantartók maguk mergelik-e a saját commitjaikat, milyen a licence, van-e magatartási kódex.
  • Konfiguráció – mennyire biztonságosak az alapértelmezett beállítások, és milyen hardening-lehetőségeket támogat a szoftver.

A keretrendszert öt lépésben kell alkalmazni: mérhető kritériumok azonosítása, kockázattűrés meghatározása és a kritériumok súlyozása, megfigyelések gyűjtése (ahol lehet, automatizált eszközökkel), értékelés minden egyes kritérium mentén, majd az eredmény összevetése a kockázattűréssel.

Arra biztatjuk a közigazgatási szerveket, hogy alkalmazzák ezt a keretrendszert a LibreOffice-ra. Minden kategória megválaszolható nyilvános adatokból: folyamatos commit-történet 2010 óta, közzétett biztonsági szabályzat és bejelentési folyamat, kötelező peer review, OSI által jóváhagyott licence, dokumentált magatartási kódex, valamint egy nyilvános irányítási struktúra – a The Document Foundation, egy német Stiftung választott igazgatótanáccsal –, amely ténykérdés, nem pedig állítás.

Arra is biztatjuk a közigazgatási szerveket, hogy ugyanígy alkalmazzák a keretrendszert minden szóba jöhető megoldásra, beleértve a proprietáris szoftvereket is, és jegyezzék fel, mely kérdésekre kapnak választ, és melyekre nem.

Közreműködés és a támogatás kérdése

Az útmutató kitér egy olyan kérdésre is, amelyet a közigazgatási szervek rendszeresen feltesznek a nyílt forráskódú szoftverek bevezetésekor: ki felel a javításokért. A CISA válasza az, hogy egyetlen szereplő sem köteles ezeket biztosítani, ezért az ügynökségeknek ennek megfelelően kell tervezniük – belső munkatársak kijelölésével, külső szolgáltatók megbízásával, vagy a kettő kombinációjával. Két alapelvet javasol az upstream projektekkel való együttműködéshez: együttműködés követelés helyett, és a javítások visszajuttatása upstreamre.

Ez pontos leírása annak, hogyan működik a LibreOffice ökoszisztémája. A támogatást, a hosszú távú karbantartást és az egyedi fejlesztéseket minősített fejlesztők és minősített migrációs szakemberek biztosítják, akiknek a közreműködése visszakerül a közös codebase-be, és minden más telepítés is profitál belőle. Az útmutató helyesen állapítja meg, hogy a szervezeteknek erre tervezniük kell. Abban is igaza van, hogy az így létrejövő fejlesztések megosztottak, nem pedig captáltak.

A CISA arra is rámutat, hogy ha egy projekt gazdátlanul marad, végső esetben egy szervezet átveheti egy fork karbantartását. Ilyen lehetőség a proprietáris szoftvereknél nincs: a támogatás végét a szállító határozza meg, és semmilyen érdemi megoldást nem kínál hozzá.

Megjegyzés a hatályról

A dokumentum nem nevez meg egyetlen terméket sem. A CISA kifejezetten leszögezi, hogy nem támogat kereskedelmi szereplőket, termékeket vagy szolgáltatásokat, és az útmutatóban foglaltakat nem szabad bármely konkrét szoftver értékeléseként értelmezni. Kritériumrendszert ad a kezünkbe. Az a megállapítás, hogy a LibreOffice megfelel ezeknek, a miénk, és bárki által ellenőrizhető bizonyítékokra támaszkodik.

Az Open Source Software: Security Principles and Practices a CISA oldaláról érhető el: https://www.cisa.gov/resources-tools/resources/open-source-software-security-principles-and-practices

A CISA bejelentése: https://www.cisa.gov/news-events/news/cisa-guide-helps-federal-agencies-securely-and-effectively-use-open-source-software