Tlak na zrychlování inovačních cyklů je průvodním jevem současného stavu ekonomiky, globalizace a zavádění pružných modelů řízení dodavatelských řetězců. Otevřené trhy stimulují rychlý vývoj a zvyšují tlak na pružnost dodavatelů a integrátorů. Klasické pojetí bezpečnosti s požadavky na analýzy, ověřování, cyklické systematické zlepšování a kontinuální zlepšování poněkud pokulhává. Je třeba si vyčistit brýle a podívat se na řízení bezpečnosti jasněji.
Extrémního významu nabývá koncept security by desing. Bezpečnost musí být součástí nového řešení od počátku. V rychlém vývoji se to už nedohoní a „nedozdrojuje“. Každá inovace, každý proces vývoje, každá změna dodavatelských schémat nebo záměna komponenty musí mít jako svou integrální součást samostatný proces řízení bezpečnosti, odvozený od firemního standardu a politiky. Při auditech a implementacích se často setkávám s vysvětlením: „… jsme mysleli, že to pak tak nějak, až bude čas …“. Bezpečnost je ve standardním prostředí regulérní součástí systému řízení vývoje a změn. Bezpečnost není štěp, nedá se příliš dobře roubovat.
Překotný vývoj, podpořený masivní poptávkou, způsobuje ve většině oborů potřebu měnit subdodavatele, konfekční komponenty, upravovat programové vybavení za pochodu a uvolňovat verze výrobků a systémů, kterým by se jinak dostalo ještě solidní vývojové péče. Dochází k produkci slepenců komponent, řešení a služeb, které nemají stejný nebo synchronizovaný životní cyklus. V jednom výrobku tak najdeme komponenty, které již nejsou bezpečné, protože jsou těsně před koncem svého životního cyklu vedle těch, které do něj ještě pořádně nevkročily. Dochází k integraci řešení dodavatelů, jejichž jedinou předností je, že dokážou být rychlí (případně že vůbec existují). Řízení bezpečnosti integrace komponent s rozdílným životním nebo inovačním cyklem je přitom jednou z těch nejobtížnějších disciplín vůbec.
Řada společností, které jinak vcelku solidně zvládají bezpečný vývoj, zcela selhává, pokud mají řídit bezpečnost svého dodavatelského řetězce. Řízení ekonomiky nákupu velí, že věc má být přeci dodána bez vady, tedy bezpečná. Logickým opatřením je, že za bezpečnost příslušné části řešení odpovídá dodavatel. Odběratel, který má zavedeny standardy řízení kvality a bezpečnosti, se často spokojí s tím, že na straně dodavatele byl někdo dostatečně odvážný a podepsal se. Zřetězený cyklus „neřízení“ bezpečnosti pak mívá běžně čtyři nebo více pater neřízené a nedokumentované závislosti poddodávek.
Ve stejně složité situaci jako integrátoři jsou ale také výrobci komponent nebo platforem. Svoje inovační cykly musí ladit s řadou zcela rozdílných potřeb svých klientů. Realita je často taková, že jim na to nezbývá čas, síly a nemají k tomu připravené dostatečně výkonné procesy. Uvedu opět příklad z praxe z auditů nebo konzultací. Je vcelku běžné, že dodavatelé dílčích řešení nebo komponent vymění nějakou knihovnu, plugin nebo jen dodavatele živé síly (například bodyshopovou společnost), aniž by to konzultovali se svými odběrateli. Výsledkem je změna kvality (včetně bezpečnosti) komponenty, se kterou nikdo nepočítá a která se projeví až ve finálním výrobku v podobě zranitelnosti nebo nějaké „nášlapné miny“.
Velmi specifickým ringem pro střetnutí inovací a bezpečnosti je oblast agilního vývoje. Existuje jen velmi málo firem nebo vývojových týmů, které adoptovaly nějakou smysluplnou metodiku řízení bezpečnosti agilně vyvíjených nebo inovovaných řešení. Prostředí sprintů a iterací rozvážnému přístupu konzervativních bezpečnostních expertů příliš nepřeje. Jedinou cestou, jak inovovat nebo vyvíjet bezpečně agilně, je pevně definovat bezpečnostní vlastnosti každé uvolněné verze před zahájením jejího vývoje a při každé změně je revidovat. Bezpečnostní architekt, v agilních týmech často v trojjediné roli s manažerem bezpečnosti a interním auditorem (takříkajíc tři v jednom mozku), musí mít postavení seniorního a respektovaného člena týmu. Pokud tomu tak není, je v zásadě nemožné do agilního týmu bezpečnost injektovat vnější autoritou. Často detekovanou chybou je chápání bezpečnosti agilních metod pouze jako analýzy a řízení rizik ohrožujících samotný vývoj – nikoliv tedy vliv změn a zjištění na bezpečnostní vlastnosti zhotoveného řešení. Je to pochopitelné u prehistorických metod vodopádového modelu, ale jde o častou chybu také u dosud přežívajícího spirálového modelu agilního vývoje. Agilní inovační aktivity jsou často velkým zdrojem hrozeb, zejména proto, že jejich hnacím motorem bývá úspora času, nákladů a počtu seniorních pracovníků v týmu.
Za zmínku stojí ještě nejméně jeden fenomén inovací. Jedná se o chytré budovy a areály. Rozumně a bezpečně navržené procesy, provozované v bezpečnostně neřízené a takzvaně chytré budově, jsou často vystaveny významným rizikům, která jsou mimo kontrolu uživatele high-tech areálu. Jestliže není možné bezpečnost takového prostředí ovlivňovat nebo alespoň ověřovat, je nezbytné se od něj izolovat. Ne všechny inovace je totiž dobré přijmout.
Martin Uher, předseda představenstva CyberGym Europe