Bezpečnost IT a zejména zabezpečení dodavatelského řetězce softwaru je aktuálně velmi skloňované téma. Jedná se vlastně o evoluční krok ve světě, kde už nikdo nezpochybňuje nutnost bezpečných platforem pro běh aplikací. Naučili jsme se naše platformy pravidelně záplatovat, standardizovat a prohlubovat jejich bezpečnostní nastavení technicky i procesně a někteří i provádějí pravidelné penetrační testy a audity. Víme, že v těchto situacích je velkým benefitem otevřený software, který je dlouhodobě znám rychlou reakcí na bezpečnostní chyby a schopností jejich oprav, ať už na komunitní bázi či firmami, jako Red Hat či Google, které umí tyto opravy i tzv. “backportovat”, tedy promítnout do dlouhodobě udržovaných verzí a umožnit tím snadné využití otevřeného softwaru v podnikové sféře. Tento problém je už tedy z velké části vyřešen a ať už mluvíme o veřejném cloudu, privátním cloudu či interních platformách, na trhu jsou pro ně snadno dostupná bezpečnostní řešení. Co se ale stane, pokud v takovém prostředí provozujeme zranitelnou aplikaci, a jak to zjistíme?
Vlastně je to naprosto běžný stav a nestane nic překvapivého. Svět nás tlačí do neustálých inovací a nových produktů. Z pohledu IT musíme stále zkracovat čas uvedení produktu v život, zvyšovat dostupnost našich řešení a samozřejmě vše zajistit co nejlevněji. Tyto snahy vedou k tomu, že většina dnešních aplikací je vlastně takový slepenec různých knihoven a frameworků okořeněný trochou našich nápadů, které danou aplikaci odlišují od konkurence. Ale kolik takových knihoven a frameworků v aplikaci máme? Typicky to budou vyšší desítky až stovky, přičemž každá z nich má svůj malý team dobrovolníků či placených vývojářů, kteří ji spravují, vylepšují a udržují. Každý z těchto týmů pracuje izolovaně a používá vlastní nástroje. Někdo GitHub, jiný Gitlab apod. Co se tedy stane, pokud se v některé z těchto komponent dané aplikace objeví chyba?
Dobrá zpráva je, že chybu většinou velmi rychle odhalí tým starající se o danou knihovnu, opraví ji, vydá oznámení a následně i novou verzi. Jak se ale o chybě a nápravných opatřeních dozví podnik, který provozuje aplikaci, jež tuto knihovnu používá? Velmi často nijak a dále nevědomky provozuje aplikaci s chybou. U těch organizací, které bezpečnost IT nepodceňují, pravděpodobně dojde k odhalení chyby v knihovně za pomoci nástrojů pro bezpečnostní scany, jako SonarQube či Red Hat Quay. Po odhalení chyby byl měl následovat pokus o aktualizaci dané knihovny, ale velmi často zde IT týmy naráží na další nekompatibilní změny, které si vyžadují změny i v našich aplikacích. A těch chyb jsou pro každou aplikaci desítky měsíčně – typickou reakcí je tedy jejich ignorování, což je dlouhodobě neudržitelný stav.
Řešením tohoto problému jsou na trhu již existující dodavatelé otevřeného softwaru, kteří se vedle jejich nezpochybnitelné role u linuxových distribucí či aplikačních serverů a podobných projektů, mohou uplatnit i v roli dodavatele dlouhodobě udržovaných knihoven pro tvorbu našich aplikací. Pak by výše nastíněný scénář vypadal pro organizaci příznivěji. V situaci, kdy používám knihovnu ne přímo od komunity, ale knihovnu dlouhodobě udržovanou mým dodavatelem softwaru, byla by mi v reakci na objevení bezpečnostní chyby doručena ne nová verze knihovny způsobující další komplikace, ale verze stávající pouze doplněná o opravu problému. Aktualizace a znovu spuštění dotčené aplikace by pak byly triviálním úkonem. Že se jedná o správný směr a důležitý trend v řešení tohoto problému vidíme i u významných technologických firem, jako je Google, které v tomto dlouhodobě kopírují tradiční dodavatele otevřeného softwaru, jako je Red Hat, a přicházejí na trh s podobnými řešeními.
Avšak je zde prostor i na revizi vlastní infrastruktury a používaných platforem a na otázku „Proč mám v aplikacích tolik závislostí na různých knihovnách?“. Odpověď je jednoduchá – protože moje infrastruktura poskytuje vlastnosti pro moderní vývoj aplikací. Příkladem můžeme uvést chybu v Log4j, kterou si všichni pamatujeme z konce minulého roku a která způsobila řadě firem horké chvilky. Knihovna Log4j řeší logování v každé aplikaci a sama o sobě je velmi komplexní. Všimněte si paradoxu, že každá vaše aplikace řeší komplexně přístup k logování, přičemž to za vás může vyřešit i platforma založená na Kubernetes, jako je Red Hat OpenShift, na které danou aplikaci provozujete. Podobně jsou na tom i technologie jako Service Mesh, které na pozadí vyřeší a automatizují úlohy spojené s vyhledáváním služeb v rámci sítě, bezpečnostními TLS certifikáty a sběrem síťových metrik.
Trend je dnes jednoznačný – nedělat věci zbytečně a odlehčit vývoji. Pomoci nám mohou odpovědi na základní otázky, jako „Neimplementuji v mých aplikacích infrastrukturní požadavky, které my už umí poskytnout platforma?“, „Vím u každé mé knihovny a závislosti, proč je součástí aplikace a co mi přináší?“, „Umím sám reagovat na všechna bezpečností rizika, nebo raději nechám své lidi pracovat na důležitých věcech a obrátím se na dlouhodobě prověřené dodavatele otevřených a bezpečných řešení?“.
