Pavle, proč právě Spořka?
Při mapování trhu mě velice zaujalo její pojetí agilní transformace. Kromě klasického “přeskládání” organizační struktury do tribů či squadů jsem vnímal, a pořád ještě vnímám, i obrovskou podporu a trpělivost ze strany managementu. A to jak na změnu firemní kultury, tak také na způsob samotného fungování.
Samozřejmě není vše úplně růžové. I kolem mě jsou oblasti, které je potřeba změnit. A vím, že to nebude jednoduchá cesta. Na druhou stranu v tom vidím prostor pro svou seberealizaci.
"A velmi si vážím toho, že mám ve svých nadřízených podporu a důvěru se touto cestou vydat."
Spolupráce je ve Spořce nezbytností. Můžeš nám přiblížit fungování týmů v DevSecOps kultuře?
Právě změna už zmíněné firemní kultury je z mého pohledu jedním ze základních pilířů DevSecOps transformace. V celém procesu je ale právě oblast bezpečnosti (security) ještě pořád dost podceňovaná. Abychom mohli naplňovat potřeby byznysu, je důležité ji do lidí „dostat” mnohem více.
Jak vlastně vypadá DevSecOps v rizikově řízené organizaci?
Podle mě často kolegové neberou dostatečně v potaz, že je Spořka rizikově řízená organizace. Což má samozřejmě dopady i na samotný způsob fungování v rámci DevSecOps. Standardně je totiž koncept DevOps resp. DevSecOps aplikován na firmy vyvíjející software. V rizikově řízené organizaci pak přináší navíc i jistá specifika. A právě s těmi je nutné se vypořádat. Důležitá je úzká a flexibilní vazba na „riskové útvary“, obzvláště z oblasti operačních rizik nebo compliance.
Co všechno se skrývá pod zkratkou Sec?
U nás v bance jsou to v podstatě tři základní oblasti. V první řadě je to doručení tzv. minimální úrovně bezpečnosti přímo do squadů. Příslušní členové týmu jsou zde schopni samostatně a aktivně aplikovat základní bezpečnostní požadavky do vyvíjeného a provozované produktu. Dále je to vytvoření zmiňované úzké vazby na příslušné „riskové útvary“ a delegování maxima věcí přímo na členy sqaudů. Což už je určitě docela výzva. V neposlední řadě je to pak samotné vlastnictví zbytkových rizik. Tady je za mne klíčové, aby příslušní vlastnicí produktů vnímali a vlastnili zbytková rizika, případně provedli dodatečnou mitigaci těchto rizik.
Jakou váhu má část Sec v celém balíčku DevSecOps?
Pro pochopení významu je potřeba se alespoň ve zjednodušené podobě podívat na základní fungování rizikově řízené organizace. Představme si, že se organizace skládá, ve velmi zjednodušené podobě, ze třech entit: byznys, IT delivery a risk. Jedním ze základních cílů byznysu je, ideálně v dlouhodobém horizontu, vydělávat. IT delivery se většinou snaží dodávat co nejvíce „IT trendy“ služby. No a risk zjednodušeně nastavuje a hlídá byznys i IT delivery, že služby provozují nejen v souladu s regulací, ale především s akceptovatelnou úrovni rizika.
Z toho by se tedy mohlo zdát, že nejlepší cestou při DevSecOps transformaci je zahrnout riskové útvary přímo do transformace. To ale ne vždy může být výhodné. V rámci Spořky tak byly nejprve transformovány útvary pokrývající entity byznys a IT delivery. Až následně byla, postupně dle jednotlivých potřeb, upravována vazba směrem k riskovým útvarům. Tento postup může mít jistě svá negativa, ale na druhou stranu to je tzv. risk-safe.
Když bychom si chtěli jednoduše kulturu a hodnoty DevSecOps představit. Mohl bys nám je přiblížit třeba na modelu rodiny?
Určitě. V zásadě je to velmi jednoduché.
"Bezpečnost musí být ostatním partnerem."
Nesmí představovat někoho, kdo brzdí či blokuje aktivity druhých. Právě naopak. Měla by hledat možné způsoby, jak danou situaci vyřešit a podpořit společné cíle.
