Tagadni valóban felesleges - vitatni azért lehet.
Volt már olyan frissítés, amely sajnálatos módon a frissüléssel együtt bugot is csempészett a kódba - nem szándékosan. Az így sérülékennyé vált program korábbi változata ezzel a támadással szemben rezisztens maradt. (A nehezebben értők kedvéért: nem a frissítés ellen akarok beszélni, csak rámutatni arra, hogy az sem csodaszer és nem garancia semmire.)
A biztonság kapcsán azt is érdemes lehet megemlíteni, hogy ez nem kizárólag a programon múlik.
Sok disztró alapban bekapcsolt tűzfallal érkezik - na de ez a tűzfal a befelé forgalmat korlátozza csak! De ha egy porton eleve nincs szolgáltatás, akkor ott nincs törhető program sem! Ezen a ponton az, hogy egy icmp reject helyett nem megy vissza válasz, mert a tűzfal DROP policy érvényesül, nem nagy védelem. Ugyanakkor a törhető szolgáltatáshoz a forgalom be van engedve, hiszen ha nem lenne, a szolgáltatás se lenne nyújtható. Viszont ugyanezen tűzfal output policy ACCEPT, azaz sikeres törés után a gépről a garázda program bárhova kimehet! Sokat ér egy ilyen tűzfal... Nyilván az output ágat is illik finomítani: a szolgáltatás válasz csomagjai kimehetnek, kérhetünk névfeloldást (a reolv.conf-beli DNS-ektől), elérhetünk ntp szervereket (az ntpd.conf-ban felsoroltakat) - slussz! Innen kezdve esélytelen a kapcsolódás botvezérlőhöz, kriptovaluta bányászat se megy, stb. (Igen, ebben az esetben a program törése sikeres, de a kívánt cél elérése ennek ellenére sem sikerült.)
Emellett érdemes magát a programot is védedni - AppArmor, de pláne: SeLinux. Amikor a program nem tudja kiírni a futtatandó rossz indulatú kódot, de a mondjuk pont olyan helyre ír, ahova üzemszerűen teszi, akkor sincs joga futtatni a kódot - innen kezdve a sebezhető, sérülékeny program sem nagyon vehető rá nem kívánatos működésre...
Mivel az uptime növekedése kontra biztonsági kockázat a frissítés elmaradása témakörben sikerült egy kis kitérőt tenni, nézzük meg jobban az uptime-t:
* egy szolgáltatás frissítése, majd a frissítés érvényre juttatásához egy szolgáltatás újraindítása nincs hatással az uptime-ra,
* egy kernel frissítés már izgalmasabb téma, ám nem napjaink találmánya a kernel csere on-the-fly. Így viszont akár kernel is frissíthető úgy, hogy nem nullázódik az uptime.
Tehát egy magas uptime nem szükségszerűen indikálja a frissítések hiányát.