W najnowszym odcinku rozmawiamy z Łukaszem Jagielskim z XTB o praktycznym wdrażaniu DevSecOps i budowaniu programu Security Champions w polskim FinTechu. To rozmowa, która pokazuje, jak świadomie podejść do transformacji bezpieczeństwa. Trzy kluczowe wątki, które poruszamy:

1. Budowanie programu Security Champions od zera. Jak XTB przeszło od braku dedykowanego bezpiecznika do dojrzałego programu Security Champions, inspirując się sukcesami BNP Paribas i dostosowując rozwiązania do własnych potrzeb.
2. DevSecOps bez zaburzania flow deweloperów. Praktyczne podejście do wdrażania narzędzi SAST, DAST i SCA w sposób, który wspiera, a nie blokuje zespoły wytwórcze. Plus konkretne wskazówki dotyczące priorytetyzacji i zarządzania podatnościami.
3. Mierzenie sukcesu i budowanie kultury bezpieczeństwa. Jak mierzyć efektywność programu Security Champions, dlaczego czas do wyprowadzenia podatności to jedna z kluczowych metryk, oraz jak budować długoterminową kulturę bezpieczeństwa w organizacji.

Łukasz Jagielski szczerze dzieli się zarówno sukcesami, jak i wyzwaniami, przed którymi stanął XTB, oferując konkretne rady dla każdego, kto myśli o podobnej transformacji w swojej firmie.

Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.

Transkrypcja

🚨 W całości wywiadu robimy referencje do programu szkoleniowego ABC DevSecOps, który jest dostępny zarówno w wersji stacjonarnej jak i kursu online. Dowiedz się więcej →

Andrzej: Dzień dobry, proszę państwa. Dzisiaj gościmy was z trochę nietypowego miejsca. Nietypowego dla nas, chociaż dla naszego gościa w zasadzie można powiedzieć, to my tutaj jesteśmy gośćmi. Miejsce jest typowe, chociaż Łukaszu, powiedziałeś nam jeszcze w kuluarach, że pierwszy raz jesteś w studio.

Łukasz: Tak, to prawda.

Andrzej: No właśnie, w studio jakiej firmy. Łukasz, przedstaw się chociaż pomimo tego, że logotypy to są rozpoznawane, bo ja was wszędzie widzę na mieście.

Łukasz: To prawda, to prawda. Jestem engineering team liderem w zespole bezpieczeństwa w firmie XTB. Jeżeli chodzi o XTB, no to jak sami już wspomnieliście, jesteśmy coraz bardziej znani. Reklamy w całej Warszawie już praktycznie są widoczne. czy te cyfrowe, czy też te papierowe. Firma inwestycyjna, mamy własną aplikację, w której możemy w wszelaki sposób sprzedawać, kupować różne instrumenty finansowe.

Andrzej: I ja się pochwalę, to tak, między nami, słuchaczami, że nawet korzystam z usług waszej firmy, mam coś tam kupione, więc jestem klientem i mam, jak to powiedziałby Nikola Stalep, skin in the game, więc bardzo mi również zależy na tym, żeby wasza aplikacja i wasze systemy były bezpieczne, żeby moje papierk.

Łukasz: wartościow.

Andrzej: lub niewartościowe, co zależy, które, były bezpieczne. Łukaszu, Ja faktycznie zauważyłem, że na mieście jest was całkiem sporo. Powiedz mi, bo to pytanie tak naprawdę wyszło mi na samym początku. Nie jestem przekonany, czy znam odpowiedź. Coś mi tam świta w głowie, ale nie jestem pewien. XTB to jest polska firma z polskimi korzeniami. Czy… No właśnie.

Łukasz: Polska firma z HQ tutaj właśnie w Polsce.

Krzysiek: To jest zaskakujące, bo ja byłem przekonany jak jechałem do Warszawy dzisiaj na tą naszą rozmowę, że XTB nie jest polską firmą. przez te gwiazdy, które macie na reklamach.

Andrzej: Tak, robicie to dobrze, robicie to dobrze, ewidentnie wyglądacie jakbyście byli zachodnim fintechem.

Łukasz: To ukłon do oczywiście naszego marketingu, rzeczywiście Nawet to oczekiwanie na nowego ambasadora, która jest co jakiś czas powiedzmy u nas w XTB, to też jest oczekiwaniem dla pracowników, kto zostanie nowy ogłoszony, kto będzie nas również promował, więc to jest fajna rzecz i rzeczywiście to są same gwiazdy, bardzo rozpoznawalne.

Andrzej: Tak, ale przechodząc do głównego meritum dzisiejszego odcinka, tematu, dla którego się tutaj w ogóle zebraliśmy, żeby porozmawiać, Łukasz, Ty jesteś bezpiecznikiem, już to powiedziałeś. W kuluarach powiedziałeś mi również, że w zasadzie byłeś pierwszym bezpiecznikiem w XTB, na co ja odpowiedziałem, że w takim wypadku budowałeś bezpieczeństwo w XTB, stawiałeś te pierwsze cegiełki. Czy możesz nam przybliżyć tych pierwszych kilka lat w XTB pod kątem bezpieczeństwa. Oczywiście bez szczegółów, taki ogólny big picture od tego, Jak mniej więcej startowaliście. Gdzie jesteście teraz. No i gdzie chcecie być w przyszłości, niedalekiej.

Łukasz: Jasne. Wiesz co, muszę na pewno wspomnieć, że to budowanie bezpieczeństwa to nie tylko odbywało się przeze mnie. Nie było tak, że jeżeli nie było bezpiecznika, to nie było tego bezpieczeństwa w firmie tak naprawdę, tylko po prostu ta odpowiedzialność bezpieczeństwa była rozłożona po prostu na inne zespoły. No i tak naprawdę dalej tak jest, no bo gdzieś tam skalowalność tego zespołu bezpieczeństwa nigdy nie będzie taka, jaką byśmy chcieli w zasadzie. No i tak uważam, że bezpieczeństwo wszyscy budujemy w firmie. Od osób, które zajmują się marketingiem, po legal, po zespół, cały IT. Tak naprawdę odpowiedzialność nie może być rzucana tylko na konkretny zespół i to jest koniec. Natomiast jeżeli chodzi o tą genezę całą, to rzeczywiście na początku było trudno wprowadzić to całe bezpieczeństwo i generalnie taką kulturę bezpieczeństwa. Ja gdzieś tam w przyszłości wywodzę się z takiego bezpieczeństwa, które gdzieś tam było ukryte, takie, wiecie, bardzo mocno to są ci z bezpieczeństwa, uważajcie na nich, tak. Jak oni coś powiedzą, to koniec, nie. Albo, no generalnie taka…

Krzysiek: Policja spałkana.

Łukasz: No dokładnie, dokładnie. Natomiast, no ja chciałem z trochę innego podejścia wyjść, czyli być takim frontem, jeżeli chodzi o bezpieczeństwo, do osób, które są w firmie, tak. Żeby miały łatwy dostęp. do tego bezpieczeństwa, do tej wiedzy, jeżeli chodzi o bezpieczeństwo. Jeżeli robiliśmy na przykład kampanie phishingowe w pewnym momencie, na jakimś etapie, to też nie było tak, że ktoś musiał się czuć pokrzywdzony, że wyląduje na jakimś dywaniku, że coś złego zrobił. To raczej było budowanie od zupełnie innej strony, czyli okej, zrobiłeś źle, ale tutaj masz kroki bardzo skondensowane oczywiście. jak nie popełnić tego błędu drugi raz. I tak naprawdę później zbieraliśmy jakieś różne statystyki osób, które na przykład w ogóle nie popełniają błędów, albo ktoś popełnił błąd, a potem już wcale nie popełniał takiego błędu. Jakby to były takie małe rzeczy, które pokazywały, szczególnie na początku mi, że to bezpieczeństwo się podnosi, jeżeli chodzi o poziom.

Andrzej: Czyli, bo mi od razu w głowie się rzuca coś takiego, że budowaliście bezpieczeństwo generalnie z taką głową, z jakimś pewnym planem, z jakąś strategią i celem na to, żeby faktycznie podnosić, a nie tylko, żeby po prostu móc powiedzieć, że jest bezpiecznie.

Łukasz: Wiesz co, no to był benefit tego, że to było budowane od początku. To nie było tak, że ja właśnie przyszedłem do jakiegoś zespołu, czy do jakichś utartych schematów, że tak powiem, tylko Oczywiście firma była nastawiona na zmianę i gotowa szczególnie, więc jakieś takie pomysły, które ja podpowiadałem, czy gdzieś leżały w backlogu tak zwanym, no to wreszcie mogły zostać uruchomione. Ja wreszcie mogłem poprowadzić pewne inicjatywy, więc małymi na początku krokami, później coraz większe robiliśmy, jeżeli chodzi właśnie o bezpieczeństwo.

Andrzej: No właśnie i tutaj zakładam, że startując, nie startowaliście przykładowo od mocnego wgryzania się, wbudowywania bezpieczeństwa w proces. Przykładowo wytwórczy. I ja tutaj oczywiście mocno Zawężam temat, bo ja doskonale zdaję sobie sprawę, że jak wytwarzamy oprogramowanie, to i tak dbamy o bezpieczeństwo, jeśli budujemy po prostu dobre oprogramowanie. Ale możemy to robić wprost, pewnych rzeczy niekoniecznie startujemy z nimi od samego początku, bo po prostu nie zawsze jest sens. XTB musiało i tak w pewnym wymiarze to dbać. mocno robić, bo jesteście fintechem. Fintechy są do tego zobowiązane. I samo to, jaki kaliber ludzi zatrudniacie, no niejako implikuje, że pewne rzeczy są zaopiekowane. Zatrudniam inżyniera dobrego, to ja wiem, że on będzie budował dobry most. Nie muszę się tym martwić. Ale jak zaczynaliście budować samobezpieczeństwo i rozbudowywać je na organizacje, to zakładam, że pewne rzeczy zaczynały się gdzieś tam rozlewać. I czy możesz mi powiedzieć, jakich ludzi, bo wiem, że teraz zespół bezpieczników masz trochę większy. Jakich ludzi zaczynaliście szukać na początku, jakich potem, no jakich teraz szukacie.

Łukasz: Jasne. Wiesz co, no na samym początku zespół bezpieczeństwa to był jako taki kor. core security, który musi się zajmować wszystkim po trochę tak naprawdę.

Andrzej: Klasyka.

Łukasz: Więc powiedzmy, że zaczynaliśmy od takiego typowego blue teamu, który miał bardzo rozszerzone, że tak powiem, obowiązki. Lekko mówiąc. Natomiast w tym momencie jesteśmy na takim etapie, że rzeczywiście budujemy zespół red teamowy i zespół upsecowy.

Krzysiek: No właśnie, właśnie, bo rozmawiamy tutaj o wielu odcieniach tego cyberbezpieczeństwa. Powiedziałeś troszeczkę o Corpse’ku, o Blue Team’ie, o Red Team’ie, a powiedz mi jak w ogóle to się stało Łukaszu, że XTB zdecydowało się pójść w tą stronę DevSecOps’ową automatyzacji bezpieczeństwa w procesie wytwórczym.

Łukasz: Jasne. Generalnie jeżeli chodzi o DevSecOps to To nie była jakaś taka terminologia nieznana mi. Gdzieś obserwowałem, tak. Powiedzmy, że… Bo ja nie jestem z wykształcenia deweloperem. Development to tylko na studiach w moim przypadku. Natomiast, wiecie, no gdzieś tam swoje łapy bezpieczeństwa też chciałem wepchnąć. I oczywiście gdzieś widziałem, tak, narzędzia, jakie są dostępne, gdzieś tutaj, jeżeli chodzi o potok CICD i naszego team leadera od tego właśnie potoku, zaczepiałem, że ej, tutaj możemy takie narzędzia, a tu jest to. I było okej, tylko że to było niestety troszeczkę na dalszy plan wtedy właśnie spychane, głównie ze względu na moce przerobowe, tak. No to wiadomo, oczywista rzecz, natomiast coraz bardziej byliśmy i nadal jesteśmy większą firmą, więc pojawiły się możliwości, żeby te zespoły rozszerzyć i jeżeli chodzi o potok CACD, ale również o bezpieczeństwo. To mi pozwoliło, że tak powiem, wepchnąć się tam, to jest jedna rzecz, a druga rzecz, no to regulacje, tak. Teraz DORA. od tego roku, jeżeli chodzi o instytucje finansowe, ona co prawda wprost nie mówi o narzędziach SASTowych, DESTowyc. itd.. ale mówi wprost o testowaniu bezpieczeństwa, o podatnościach, o tym żebyśmy Wiedzieli na jakim etapie jest organizacja i czy wie organizacja co ma, jakie podatności, tak.

Andrzej: No oni tam sprytnie podchodzą, nie powiedzą dokładnie co, ale potem jak czegoś nie spełnisz, to a, tego tu nie miałeś, to prawnicy.

Łukasz: oni wiedzą co robią.

Krzysiek: Tak, a czy takie regulacje jak na przykład DORA była pewnym boosterem, jeżeli chodzi o wprowadzenie procesów związanych z DevSecOpsem w XTB.

Łukasz: Wiesz co, myślę, że na pewno, że to był jeden element, jeden z. To była kolejna amunicja do tego pistoletu, który po prostu wystrzelił. I dała kolejny argument, że powinniśmy nie zwlekać, przyśpieszyć. Mamy tutaj pomysły, mamy fajny, ambitny zespół. To czemu czekać.

Andrzej: Ale jeszcze w kuluarach powiedziałeś mi, że poza takimi, nazwijmy to, siłami zewnętrznymi, które do czegoś nas pchają, to pojawiały się również takie siły bardziej wewnętrzne, motywacja obserwacji środowiska z twojego punktu widzenia. Tutaj wspomniałeś, że BNP było pewnego rodzaju inspiracją, zasiało takie ziarenko ponad dwa lata temu na The Hack Summit, gdzie chłopaki i dziewczyny z BNP prezentowali prezentowali jak wygląda bezpieczeństwo w procesie wytwórczym w grupie BNP, tutaj konkretnie naszym polskim, lokalnym kawałku tej grupy. By the way, pozdrawiamy chłopaków i dziewczyny z BNP. Zenek, Filip, pozdrawiam. I robicie dobrą robotę, widzicie, są efekty. Natomiast u Łukaszu. BNP tutaj… była pewnego rodzaju inspiracją. Czy mógłbyś wskazać jakiś konkretny, nie wiem, czemu. Czemu się okazało, co ci się tam spodobało. To, jak oni to przedstawili. Bo też mówiliś, że inne firmy też gdzieś zaczęły to potem pokazywać i zaczęły się objawiać na twoim radarze.

Łukasz: To prawda. BNP było takim ogniwem zapalnym, tak naprawdę. Myślę, że głównie pozwoliło połączyć kropki. Mi szczególnie, bo jak już wspominałem, nie jestem deweloperem, być może takie rzeczy były już znane od początku, natomiast gdzieś ta idea, szczególnie security championów, tak, odblokowałem jakieś zwoje w mózgu, tak naprawdę, że da się to zrobić, tak, no bo ja wiedziałem o narzędziach, wiedziałem, że to trzeba wdrożyć w POTOX i ICD, pewne rzeczy, procesy trzeba pod to ułożyć. Ale kto będzie to robił, tak. No bo okej, zespół bezpieczeństwa jest powiedzmy jakiś malutki, a deweloperów cały czas przybywa, cały czas, z miesiąca na miesiąc, z miesiąca na miesiąc. I gdy usłyszałem o idei Security Championów właśnie na prezentacji BNP, no to wtedy zrozumiałem, że to jest ta droga tak naprawdę, gdzie moglibyśmy sobie wyskalować to bezpieczeństwo, jednocześnie mieć to obserwability, co się dzieje podczas tworzenia oprogramowania, no i czy jest ono bezpiecznie tworzone, bo to też nie było tak, że w XTB to oprogramowanie nie było otworzone bezpiecznie, tylko w zasadzie security nie patrzyło na to, tylko security było w ramach zespołów wytwórczych, o, na tej zasadzie.

Andrzej: Tak i zakładam było po prostu bardziej skupione na weryfikacji formalnej tego, co wychodzi, okej, to jest bezpieczne, bo to sobie przetestowaliśmy, to wiemy, że jest bezpieczne, a mniej na świadomym wbudowywaniu, co jest trudniejsze, bo tak jak powiedziałeś, trzeba mieć najpierw ludzi, którymi rękoma można to zrobić. Bezpieczników zawsze jest za mało i to jest to się nie zmieni. Developerzy, oni mają przede wszystkim budować feature’y i jeśli są dobrzy, no to te feature’y będą również dobre. i weryfikacja często, gęsto, w zasadzie w każdej organizacji jest takim pierwszym krokiem. Najpierw chcemy weryfikować, a potem dopiero przesuwamy się na lewo, ten ładny koncept shift left. I to jest klasyka w każdej organizacji. W największych organizacjach po prostu się to dzieje szybciej niż wolniej, bo mamy większe fundusze. I odnośnie funduszy i security championów, powiedz mi, czy na początku gdzieś spotkałeś się z pewnym oporem, tłumacząc to gdzieś do góry, czy nie. Czy było takie, że Łukasz faktycznie kupuje Twoją ideę, idziesz w to, masz tutaj budżet, możesz budować security championów.

Łukasz: Wiecie co. Tak naprawdę, jeżeli chodzi o świadomość tutaj naszych menadżerów, szczególnie mojego, Adama Czuchaja i Adama Dubiela, była dosyć duża, jeżeli chodzi o bezpieczeństwo. To są osoby, które wiedzą, jak bezpieczeństwo powinno być prowadzone i jak wygląda dojrzały w ogóle zespół bezpieczeństwa, więc Jeżeli chodzi o samą ideę, to nie było problemu, natomiast trzeba było dać argumenty, jak taką transformację, czy taki program np. Security Championów, jak on będzie prowadzony, jakie my mamy pomysły, bo to też nie może być tak, że No dobra, jakoś to pójdzie, tak naprawdę. Zrobimy program Security Champions, a potem pomyślimy co dalej. No nie, tak naprawdę musieliśmy mieć jakiś plan, musieliśmy mieć narzędzia, musieliśmy mieć szkolenie, a z tym właśnie na rynku też było ciężko. No i właśnie wiąże się z tym historia taka, że akurat cały czas ten temat był powiedzmy u nas na tapecie, tak. I jakoś tam pamiętam, że chyba na początku roku gdzieś była informacja od was, bo już obserwowałem was od jakiegoś czasu, że wypuszczacie takie szkolenie i wiecie, kolejna kropka połączona. Idealnie, tak. Jakby było szyte na miarę dla nas, tylko szkoda, że trochę musimy poczekać, tak. Te pół roku chyba w zasadzie. i możemy działać, możemy mieć dedykowane szkolenie dla security championów dla nas, no i dla menadżerów, więc idealnie.

Andrzej: Do tego jeszcze może zaraz przejdziemy, ale mi się podoba to co powiedziałeś, że tego programu security championów A to jest ważne. Nie można tak sobie podejść do tego YOLO. No po prostu chcemy zrobić. Kogoś tam wybierzemy i jakoś to będzie.

Krzysiek: Jakoś się uda.

Andrzej: Tak, no się nie uda. Trzeba zaplanować tą ścieżkę. Trzeba zaplanować też ścieżkę edukacji. I ja to mówię z doświadczenia, bo miałem przyjemność, nie przyjemność, okazję. Miałem okazję gdzieś być w organizacji, gdzie były przebieżki z security championami. No i jeśli nie ma się jasnej drogi, jak chcemy ich rozwinąć, w ogóle aktywizować i trochę i tak weźmiemy z łapanki, to to po prostu się na koniec dnia nie uda. Więc być może nawet niepotrzebnie przepalimy pewne zasoby, no bo inicjatywa ruszy, zostanie koło, machina zacznie działać. a na koniec dnia nie wyciągniemy z niej wartości. Wy podeszliście do tego z głową i jeszcze przed startem mieliście jakąś ideę, jak należy do tego podejść. Potem zaczęliście ją realizować. To mi się bardzo podoba. I jeszcze zrobię małe nawiązanie do BNP. Mam nadzieję, że z całej tej rozmowy wyjdzie trochę taka taki peptok, taka inspiracja właśnie dla innych, jak to może wyglądać w innej organizacji, może nawet mniejszych niż XTB, żebyście to wy byli pewnym wzorem do tego, jak można podejść do wbudowywania, do budowania bezpieczeństwa w procesie wytwórczym, ale nie tylko, nawet szerzej w organizacji, tak jak dla was pewnym wzorem albo tym punktem zapalnym była prezentacja BNP, więc dzielenie się wiedzą jest tutaj super ważne.

Krzysiek: Tak, dzielenie wiedzą jest super ważne Łukaszu i powiedziałeś o tym buy in od managementu, o tym świadomym managemencie, o tym jasnym planie, który trzeba było przedstawić, a ja odbiję piłeczkę i przedstawię to troszeczkę z innej perspektywy, bo chciałbym się zapytać o inną perspektywę, bo buy in od managementu to jest jedno, a jak zdobyłeś ten buy in. od deweloperów, od tych ludzi, którzy mieli zostać tymi security championami, czy byłeś jak taki Scrum Master Oskarek, który przychodzi i mówi dobra, chodź teraz na daily, porozmawiamy sobie o tym. Czy, właśnie, jak to było. Czy oni łaknęli tej wiedzy, czy musiałeś ich troszeczkę do tego namawiać.

Łukasz: Geneza była tego taka, że przez to, że już jakiś czas pracuję w XTB, już przez ten czas zgłaszały się do mnie pewne osoby, jeżeli chodzi o podatności, że ej Łukasz, przeczytałem ciekawy artykuł, może coś nam zagraża, czy mógłbyś sprawdzić. Albo to były osoby, które chciały zapytać, czy mogą coś przetestować. Więc jakby zacząłem budować sobie taką pulę osób, tak naprawdę zainteresowanych tym bezpieczeństwem. I właśnie tak jak już mówiłem, te kropki się wszystkie połączyły, jak usłyszałem o idei Security Champions. I tak naprawdę, gdy zapytałem tych osób, czy chciałyby w takim pilotażowym programie wystąpić, będzie można więcej się dowiedzieć o bezpieczeństwie, będzie kupa roboty i uścisk ręki prezesa i tylko tyle możemy zaoferować na początek, ale oczywiście również wiedza, no to bez zawahania, tak, zgodzili się na to i co bardzo fajne, to już były takie osoby, których nie trzeba było zachęcać do pracy. To były osoby, które same się wykazywały inicjatywą, same chciały zmienić, jeżeli chodzi o XTB i bezpieczeństwo, chciały uczestniczyć w całej tej transformacji, jeżeli tak mogę powiedzieć. Więc jeżeli potem zaczęliśmy mieć jakieś statusowe spotkania, omawialiśmy jak to może wyglądać, tutaj będziemy mieli szkolenie, OWAS mówi tak, tu jakieś inne materiały tak naprawdę, spotkaliśmy się regularnie i dyskutowaliśmy. I powiem wam szczerze, że ja nie sądziłem, że Tyle fajnych pomysłów może wyniknąć z takich dyskusji i że te osoby w organizacji nie były dotąd widoczne. Bo wiadomo, każdy miał swoje obowiązki w ramach tego, czy to testerzy, czy to deweloperzy. Natomiast dla mnie jako bezpiecznika to oni zaczęli błyszczeć wtedy.

Krzysiek: Ja taki mały follow up do tego zadam, bo powiedziałeś testerzy, deweloperzy. Czy jest jeszcze jakaś rola, która uczestniczyła w tym programie Security Champion, oprócz typowego programisty i inżyniera QA.

Łukasz: DevOps, sysadmin. Wiesz co, nie. Na razie testerzy i deweloperzy, natomiast już mam sygnały, że nawet ktoś z zespołu legala chciałby być Security Championem. DevOps oczywiście też, więc… Pomyślimy jak to rozwiązać, bo to jest rzeczywiście też ciekawe.

Andrzej: To teraz mam pytanie, bo powiedziałeś, że w zasadzie podchodząc do No nazwijmy to tak ładnie, transformacji DevSecOps. Nie bójmy się tego. Do transformacji DevSecOps, do budowania programu Security Championów. I też wspomniałeś właśnie o ważnej kwestii tego, że ci ludzie najczęściej mają inne obowiązki, no bo są zatrudnieni do wykonywania konkretnej roli, przykładowo testera czy programisty. Czy mógłbyś powiedzieć, Czy mogłyś mi powiedzieć, w jaki sposób podeszliście do wygospodarowania czasu dla tych osób właśnie w przestrzeni security. No bo niestety, ale czas w gumy nie jest, nie da się go rozszerzyć. Czy było to w jakiś sposób sformalizowane. Bo wspomniałeś na przykład spotkania, że mieliście jakieś spotkania etc. To wszystko zabiera czas. Czy przykładowo, powiedzieliście sobie od samego początku, że dobra, no to teraz 15-20% czasu poświęcamy na security. Jak do tego podeszliście. Jak rozwiązaliście ten problem. Bo jestem pewien, że każdy kto chciałby wystartować z taką inicjatywą, no to będzie jedno z pierwszych pytań.

Łukasz: To jest bardzo duże wyzwanie. Szczególnie przy tym, że każdy zespół pracuje inaczej. I każdy różnie może tym czasem rozdysponować. Próbowaliśmy różnych rzeczy. Na początku poprzez jakieś cele kwartalne, poprzez zadeklarowanie w wysokom menadżmencie jakąś stałą propozycję np. 10%. Natomiast to nie jest też tak, że my powiemy 10% i to wiecie, tak jest od strzała egzekwowane, tylko niestety trochę trzeba tego też pilnować. Czy rzeczywiście np. OK, gdzieś tam menadżer wysokiego stopnia zgodził się na coś takiego, ale czy tym lider pozwala rzeczywiście ten czas wykorzystać na to security, czy dopiero pozwala, wiecie, na koniec miesiąca, czy kwartału, tak. No to niestety jest taka rzecz, którą trzeba pilnować i w miarę spróbować dostosować. Więc mogę odpowiedzieć, że 10%, natomiast to nie jest jakaś stała wartość, którą utrzymujemy. Cały czas rozmawiamy, czy nie zwiększyć, czy może jakoś to zoptymalizować w jakiś sposób, bo też na początku to były spotkania, dużo rozmów, dużo ustalenia, później POC narzędzi różnych, szkolenia i tak dalej, to kwestia czasu jest bardzo trudna do rozdzielenia.

Andrzej: Ale możemy tutaj stanąć na tym, że jakaś część czasu została gdzieś zakomunikowana. Jasno. I do menadżmentu i niżej. No i też jest to monitorowane, było to cały czas monitorowane pod kątem usprawnień, optymalizacji. Więc tak naprawdę odpowiedź trochę taka konsultancka to zależy.

Łukasz: To prawda, to prawda. Generalnie też przez to, że teraz ten program tak naprawdę działa. No ja też zdałem sobie sprawę, że jakby wystartować, to dopiero się zaczyna cała zabawa, żeby utrzymać cały program. Ja to wtedy dopiero zrozumiałem, chociaż wydawało mi się na początku drogi, wiecie, że żeby zacząć to jest ciężko. I tak naprawdę zdałem też sobie sprawę, że Security championi to jest taki rodzaj społeczeństwa czy grupy osób, które też trzeba stale stymulować, pokazywać im różne rzeczy. I ja jako team leader obecnego zespołu, coraz ciężej było mi to tak naprawdę robić i dlatego właśnie pomysł, żeby stworzyć zespół APSEC-owy, który między innymi też by stymulował i działał, współpracował z security championami.

Krzysiek: Powiedzieli, że jest ci ciężko, że było ci ciężko stymulować. Jakie Łukaszu mimo wszystko, jakich technik, jakich rzeczy próbowałeś, aby dorzucać do pieca i żeby ten żar, żeby ten ogień w tych security championach nie zgasł. Jakie to były aktywności, gdybyś mógł podać jakieś przykłady.

Łukasz: Wiesz co, no na pewno zaczęliśmy budować bazę wiedzy. Naszą taką, jeżeli chodzi o bezpieczeństwo. Była to powiedzmy taka baza, która jest bardziej publiczna dla organizacji i taka bardziej nasza, wewnętrzna dla security championów, gdzie ja i część zespołu dzieliła się ciekawymi szkoleniami, prezentacjami, artykułami, tak, no bo to zdaję sobie z tego sprawę, że jeżeli ktoś całe życie na przykład koduje, no to on niekoniecznie musi znać się na wszystkich rzeczach, wszystkich feedach, wszystkich newsletterach, tak, które Powiedzmy, ja jako człowiek security odsiałem pewne rzeczy, które są bardziej wartościowe od tych mniej. Szczególnie, że niestety teraz coraz więcej jest, tak jak powiedziałbym, mniej wartościowego materiału. Pewnie przez TikToka, Instagrama i tak dalej. Każdy gdzieś buduje własną markę. No i w tym szumie informacyjnym ciężko znaleźć coś rzeczywiście wartościowego. Więc ta baza wiedzy to była jedna z takich rzeczy. Organizowanie szkoleń to jest jakby druga kwestia, czyli tak jakby, żeby security championi cały czas mieli dostęp do tej wiedzy. Wiadomo, baza wiedzy i szkolenia to się ze sobą łączy, natomiast tu mówimy np. o płatnych szkoleniach czy jakichś konsultacjach, więc to jest kolejna kwestia. Jeżeli chodzi o spotkania nasze statusowe, to nie były tylko spotkania, na których mówimy o tym, jak dalej ciągnąć, że tak powiem, ten wózek, tylko również my jako bezpieczeństwo z moim przełożonym, bo też mówiliśmy tak, co się dzieje w firmie, jeżeli chodzi o bardziej ciekawe newsy, tak, żeby każdy mógł się wypowiedzieć na swój temat, a może coś zaproponować. tak naprawdę, my jako bezpiecznicy może myślimy jakąś utartą, powiedzmy, drogą, czy mamy jakieś pewne klapki, A deweloperzy, testerzy czy inne komórki mają tą inną perspektywę i rzeczywiście ta perspektywa potrafi dużo dać do myślenia i daje zupełnie nowe spojrzenie.

Krzysiek: Tak, Łukasz jeszcze takie mikro pytanko, bo jestem bardzo ciekawy. Zakładam, że XTB jeżeli chodzi o rozwój swego produktu pracuje w metodologiach zwinnych Agile, Scrum i tak dalej. Powiedz mi jak to wyglądało z punktu widzenia właśnie gildi czy właśnie security championów. Gdzie upychaliście te taski. Czy to był jeden globalny backlog. czy taski były dystrybuowane po zespołach z jakimiś labelkami, że to dotyczy security.

Łukasz: Wiesz co, tak naprawdę chcieliśmy scentralizować całość. Jeżeli chodzi o tę centralizację to chcielibyśmy, żeby wszystko wpadało powiedzmy, że do jednego worka, jeżeli chodzi o taski związane z security, czy jeżeli chodzi o podatności. a tak naprawdę potem nie chcieliśmy narzucać jak później to jest budowane. Każdy zespół ma jakąś swoją metodologię. Czy oni sobie rozpisują taska o danym typie zadania, czy o danym flow, to jest już w ich kwestii. My jesteśmy od tego, my i Security Champions, żeby informować o tym, że pojawia się dana rzecz, którą powinniśmy się zająć, a później cała kwestia budowania, planowania i tak dalej jest po stronie deweloperów. Więc podeszliśmy do tego tak, czy to wyjdzie nam na dobre, to zobaczymy.

Krzysiek: Okej, ale jakieś globalne visibility myliście. Chodzi mi o kwestię potem raportowania postępów pracy i nie gubienia tego przepływu pracy, tego budowania takiej rozliczalności, co faktycznie w tym programie Security Champion zostało wykonane, a co gdzieś tam może nam uciekło pomiędzy tymi spotkaniami, nie zapisane gdzieś.

Łukasz: Wiesz co, no my już przy samym wyborze narzędzi chcieliśmy skupić się na tym, żeby deweloperzy nie przełączali się pomiędzy różnymi narzędziami, tak. Czyli żeby to flow, na którym pracują, ten potok też CICE, który mają, nie był w ogóle zaburzony. to ma się dziać bezinwazyjnie, transparentnie. Jeżeli oni, powiedzmy, że dobudowują jakieś rzeczy, robią match requesty, to tam ma się pojawić informacja, że ewentualnie jest wprowadzona podatność i coś z tym trzeba zrobić, też najlepiej automatycznie, a nie żeby ktoś się logował do innego narzędzia, sprawdzał, no bo to rozbija te flow w ogóle, tak, kodowania, a tego nie chcieliśmy zaburzać.

Andrzej: Tak, tutaj taki mała, mała ciekawostka. Ostatnio robiłem analizę kilku papierków o narzędziach z analizy statycznej SAST i Facebooku w momencie, gdy sprawdzali skuteczność wyprowadzania podatności, które były alarmowane w momencie, w momencie popełnienia błędu, konkretnie do dewelopera. A drugi typ podatności był alarmowany, ale dopiero dalej w centralnym narzędziu. No tam w zasadzie, jak sobie policzyli, to te, które były alarmowane w narzędziu, zbliżały się do zera stopień wyprowadzania tych problemów. A te, które były informowane prosto do dewelopera, tam gdzie dzieje się praca i wtedy, kiedy faktycznie został ten błąd popełniony, czyli ja sobie piszę, przykładowo robię jakiegoś pusha i tam dostaję ten feedback, albo jeszcze w moim IDE, to tam mieli koło 70 paru procent skuteczności wyprowadzania tych problemów. Co jasno pokazuje, że jak trzeba informować ludzi, trzeba ich informować tam, gdzie dzieje się ich praca, a nie gdzieś obok. Natomiast ja tutaj zrobię trzy kroki do tyłu, bo to była tylko taka ciekawostka, zrobię trzy kroki do tyłu i jeszcze przyczepię się do. Przyczepię, może nie przyczepię, ale tak się złapię i dopytam odnośnie tej kwestii edukacji, bo w ogóle to, że my się dzisiaj tutaj spotkaliśmy jest wynikiem tego, że gdzieś tam uderzyłeś do Krzyśka po szkoleniu niestety nie do mnie, do Krzyśka. I napisali, Krzysiek, jest fajnie, zrobiliśmy tak, podeszliśmy w ogóle w XTB do zbudowania tego programu w ten sposób. I Krzyśk mi powiedział, i mi wtedy się zapaliła lampka, kurczę, tak, XTB zrobiło to świetnie, tak powinno się przerabiać szkolenia. Kurczę, nie tylko to nasza BCD w Sekops, w ogóle, jeśli organizacji, i teraz powiem, jak wy do tego podeszliście, bo z głową, dla mnie samo podejście było fenomenalne, No podeszliście do tego w ten sposób, a kurczę, albo co ja będę mówił. Ty mi powiedz, jak do tego podeszliście.

Łukasz: Spoko. Wiesz co, myślę, że też inni security championi w ogóle się, wydaje mi się, chwalili się, jak do tego podeszliśmy, no bo, no co, chcieliśmy wycisnąć wasze szkolenie jak gąbkę, tak naprawdę, jak najwięcej się dowiedzieć, więc to nie mogło być szkolenie, na które pójdziemy. i okej, albo pogadamy o tym, albo nie pogadamy, albo nie wiem, spotkamy się na naszym statusie i powiemy, no i jak tam było.

Krzysiek: To nie o to chodzi w przepalaniu firmowych budżetów.

Łukasz: No nie.

Andrzej: To zależy, jak chcemy być skuteczni, to nie, ale jak chcemy po prostu budżet przepalić, to jest wtedy cel.

Krzysiek: No i okej, Łukaszu, macie to szkolenie, zaczynacie tą gąbkę ściskać. Co dalej.

Łukasz: Generalnie najpierw spotkaliśmy się, żeby porozmawiać o tym właśnie, jak wycisnąć tą informację jak najbardziej. Doszliśmy do wniosku takiego, że najlepiej po każdej lekcji, powiedzmy, że z jakimś tam odstępem czasu, tak żeby każdy mógł sobie przemyśleć pewne kwestie, spotykamy się, omawiamy różne wnioski, jakie następne kroki być może musimy podjąć w naszej organizacji po tej jednej z lekcji. a tych lekcji było 4-5 tak naprawdę, więc na każde spotkanie mieliśmy, na każdą lekcję mieliśmy spotkanie, gdzie omawialiśmy dalsze kroki, zadania, jakie w ogóle wypłynęły w związku z tą lekcją, gdzie musimy coś zaadresować albo wrzucić do backlogu i co w ogóle sądzimy, tak, o danych kwestiach, które gdzieś były poruszane na właśnie takim szkoleniu. i też forma w której to omawialiśmy też nie była, że tak powiem, standardowy, że spotykamy się i rozmawiamy. Jeden z security championów utworzył board w Miro, gdzie właśnie wizualnie każdy mógł, że tak powiem, łatwiej przyswoić sobie to, o czym rozmawiamy, to, co trzeba będzie zrobić dalej. I w zasadzie co tydzień przechodziliśmy sobie przez każdy board. Każdy mógł opowiedzieć o tym, co właśnie sądzi i co z tego wynika. To wiecie, to się rozgałęziało potem, bo ktoś poruszył jakąś kwestię, to później szło dalej, dalej, dalej, więc czasami nie starczyło czasu nawet na te spotkania.

Andrzej: Mi się przede wszystkim tu podoba w całym tym koncepcie podejścia, ta współpraca, ta To co potem wynika z tej współpracy taka burza mózgów, bo jeśli założymy, że zespół Security Champions jest zbudowany z kilku ról, że to są i testerzy, i deweloperzy, w większych organizacjach wtedy od razu wpadają DevOps-i. Z Legal jeszcze nikogo nie widziałem, ale kto wie, może za niedługo powiesz, że i Legal się w to wkręci. LegalOps. I ta inna perspektywa ludzi pobudza do takiej praktywnej burzy mózgów, no bo każda z tych osób, bazując na swoim doświadczeniu, bazując na swojej roli, będzie odbierała materiał w inny sposób. I jednej się zapali lampka w tym przedziale, a drugiej w tym drugim, ale jeżeli mamy to miejsce i czas na porozmawianie, no to będziemy mieć obie lampki zapalone, a jak jeszcze sobie to gdzieś skatalogujemy, na przykład na Miro czy gdziekolwiek, ważne, żeby to było zapisane, a nie tylko w głowie, no to potem możemy zacząć faktycznie budować sobie bardzo ciekawą road mapę tego, co chcemy zrobić, ale też tego, czego na przykład nie chcemy zrobić. i mówimy, nie, tego na przykład nie chcemy robić teraz, Może to przemyślimy za pół roku albo za rok, ale na razie to odkładamy gdzieś tam do przodu. Bardzo mi się podoba. To jest takie bardzo dojrzałe podejście do budowania nie tylko bezpieczeństwa, bo to da się przenieść do innych aspektów inżynierii i oprogramowania. Bardzo, bardzo ciekawe. Tutaj pierwszy raz coś takiego widziałem.

Łukasz: Wiesz, też dopowiem tylko może dwa słowa. Było identycznie tak jak powiedziałeś i nawet to, że rzeczywiście ja się skupię załóżmy na budowaniu, na flow, na tym jak ten proces całego łatania powinien iść. A ktoś na przykład się skupi na tym, że SAST może dużo false positive’ów wyrzucać, może musimy budować reguły, czy to powinniśmy robić my, czy tylko my proponujemy, a robi zespół CI, CD, tak. To różne rzeczy rzeczywiście wynikały i to było świetne.

Krzysiek: Tak, i zobaczcie, bo to co mi się bardzo, bardzo Łukaszu podoba w waszym podejściu, to jest to, że braliście te lekcje, rozbieraliście je na czynniki pierwsze i osadzaliście je we własnym kontekście, bo umówmy się, nie wszystko to, co powiedzieliśmy w programie, należy stosować w każdym, w każdej firmie, w każdej organizacji, bo kontekst, kontekst is the king, więc to jest bardzo, bardzo dojrzałe podejście, w którym skroiliście, wzięliście ten nasz program i niejako skroiliście go jeszcze bardziej na miarę tak, żeby był szyty jak dobry, dobry garnitur.

Łukasz: Wiesz, ja myślę, że tak jest ze wszystkim, że są jakieś ogólne zasady, są jakieś fundamenty, Ale nikt na szkoleniu nie powie Ci, jak powinieneś rozwiązać dany problem. To powinno być zawsze uszyte na miarę, tak. Wy możecie powiedzieć jakąś rzecz jak najczęściej, na przykład dany problem można rozwiązać, ale to nie zawsze będzie oznaczało, że tak rozwiąże się to we własnej organizacji.

Andrzej: I to jest, wiesz, to jest dojrzałe spojrzenie. Niestety, ja gdzieś tam spotykam się często na rynku z tym, że organizacje czy zespoły, myślę, że po prostu wezmą jakaś część dobrych praktyk i tak sobie je wdrożą i będzie działać. No niestety nie, bo ta specyfika pracy jest specyficzna dla każdej organizacji, dla każdej grupy osób, która jest złożona z więcej niż kilku ludzi.

Krzysiek: Tak, dokładnie. Przychodząc dalej, Łukaszu, jak porównałbyś te dwa stany. przed wejściem w ABCD, przed tą waszą autorską, takim autorskim programem, który zbudowaliście na podstawie ABCD. Jak to wyglądało przed, a jak to już wyglądało po, kiedy przerobiliście te wszystkie bordy do końca.

Łukasz: No na początku było ciężko, tak. No bo nie mieliśmy tej wiedzy, tego coru właśnie, który w zasadzie tylko nam był potrzebny, żeby dalej to popchnąć. Więc Nie wiedzieliśmy na samym początku pewnych być może oczywistości, które dowiedzieliśmy się na szkoleniu. Natomiast teraz w obecnym czasie myślę, że jesteśmy zupełnie innymi osobami. I security championi, jak i ja również. Wiemy jak działać, co dalej robić, a wtedy to był początek. To było tworzenie w zasadzie programu. Trochę się to połączyło z wyborem również narzędzi, więc tak naprawdę wtedy trwała budowa, teraz jest takie utrzymanie, można powiedzieć tak naprawdę.

Krzysiek: Jakbyś mógł wskazać dwa. góra trzy, dwie, góra trzy rzeczy, które najbardziej utkwiły Ci w pamięci z programu, które zyskały wysoką adopcję, jeżeli chodzi o procesy. Nie musisz mówić o szczególnych narzędziach, możesz posługiwać się bardziej górnolotnymi kategoriami.

Łukasz: Jasne. Mi na pewno najbardziej zapadło w pamięć, też duża dyskusja była odnośnie całego vulnerability management. Jak to powinno wyglądać. Wiadomo, są pewne fajerwerki przy narzędziach. Wdrażajmy, niech to działa, niech wypluwa te podatności, niech je widać. No dobra, ale co dalej. Są projekty, które mogą na przykład mieć tysiąc podatności załóżmy. Jak do tego podejść. wymaga troszeczkę większej rozmowy niż po prostu wdrożenie narzędzia. Tak, więc dla mnie cała ta lekcja związana z zarządzaniem podatnościami była bardzo cenna. Nie jestem pewien, czy nawet tam nie była taka sugestia od was, że dobrze, żeby nie zaburzać tego flow, tak, żeby programiści mogli budować, tak, a nie przełączać się pomiędzy różnymi narzędziami i gdzieś tam to była też dla nas bardzo ważna sugestia. w zasadzie poszliśmy tą drogą nawet wcześniej, więc utwierdziliście nas. Druga kwestia, no to myślę, że przy każdej z lekcji, przy każdym narzędziu, tak jak zrobiliście podział, było różne podejście, czy propozycje podejść, jak podejść do na przykład skanowania SASTem, do skanowania DASTem, do SCA. I tam również wychodziły pewne niuanse, o których nie zdawaliśmy sobie sprawy. No bo dopiero te flow wchodziło. I myślę, że np. kwestia priorytetyzacji pewnych rzeczy. Te narzędzia, które skanują, nigdy nie będą idealne. Nigdy nie będą miały tego kontekstu w ogóle organizacyjnego. Znaczy wiadomo, są takie, które próbują to robić, Natomiast ciężko zastąpić człowieka w tej kwestii.

Andrzej: Ale jak to. Ja jestem pod wrażeniem, przynajmniej czytając LinkedInowych ekspertów od AI, że ludzie to się już kończą. Teraz AI wszystko będzie robić.

Łukasz: Pewnie niedługo nas to czeka, ale jeszcze wygląda to tak, że niestety trzeba było sprawdzać te priorytety. narzędzia często mówiły, że coś jest krytyczne, coś jest wysokie i musieliśmy po prostu zbijać te priorytety. To niestety nie mogło być tak zostawione, że narzędzie mówi Ci, że jest tak i tak jest. I to jest powiedzmy przekierowywane do naszego flow. następnie. Podeszliśmy do tego tak, że security championi określają tak naprawdę, czy coś rzeczywiście ma dany priorytet czy nie, a nie narzędzia. Więc to jest kolejna kwestia.

Andrzej: Czyli też aktywne utylizowanie security championów w takiej pracy, pomocy, ocenie. Problemów, które są znajdywane przez…

Łukasz: Zdecydowanie. No bo tak naprawdę nie wyobrażam sobie, żeby taki typowy, znaczy, co znaczy typowy bezpiecznik, ale generalnie osoba zajmująca się stricte, nie wiem, na przykład OS-ami, bezpieczeństwem w OS-ach, tak, czy czy np. robi kampanie phishingowe, to skąd ona ma wiedzieć, czy dana podatność w danej bibliotece zagraża nam, czy mamy jakieś funkcje włączone, które w ogóle eliminują daną podatność. Skąd ona ma to wiedzieć tak naprawdę.

Andrzej: To jest dobre pytanie, które być może powinienem zadać swoim kolegom, którzy próbują takie szary mary robić, bo ja niestety, ale spotkałem się z takimi sytuacjami właśnie, gdzie albo nie ma zespołu security championów, albo jest, ale nie jest do końca utylizowany. No i bezpiecznicy przejmują taką ocenę, ale jest dokładnie tak, jak mówisz. To po prostu nie działa, no bo skąd ta osoba ma wiedzieć. Ona jest od czegoś innego, pomimo tego, że w nazwie jest security i tu i tu.

Łukasz: Znaczy tak właśnie intuicyjnie się wydaje, że ktoś od bezpieczeństwa to powinien sprawdzać, ale no właśnie, wtedy się pojawia frustracja, no bo ten człowiek musi musi się bardzo wgryźć, tak, powiedzmy, żeby zrozumieć. On rzeczywiście do tego dojdzie, tylko to mu zajmie trochę czasu. A wydaje mi się, że security champion gdzieś już ma ten background, gdzieś już siedzi w zespołach, więc no to jest nieporównywalnie szybsze.

Krzysiek: Tak, wiecie, wydaje mi się, że ja jestem pewien, że w przypadku typowych bezpieczników mamy tutaj do czynienia z takim myśleniem binarnym, zero-jedynkowym, a jest podatność albo nie ma podatności i nie ma żadnej wartości pomiędzy 0 a 1, więc utylizacja security championów jako swego rodzaju filtra przed tym, żeby nie zarzucać tych zespołów produktowych, tych zespołów deweloperskich tym outputem z narzędzi, do automatyzacji jest bardzo istotna, no i też dla organizacji bardzo pożyteczna.

Andrzej: Kolejne pytanie, które myślę, że będzie dość odpowiedź, może być cenna dla słuchaczy. Jakie, no przyjmijmy trzy miary bezpieczeństwa, przyjęliście, albo testowaliście, albo macie przyjęte, albo w ogóle po prostu w swojej ocenie uważasz, że mogą się sprawdzić w, niech będzie w procesie DevSecOps, w transformacji DevSecOps, bo jakoś mierzyć ten sukces trzeba. I to myślę, że zdajemy sobie sprawę tutaj wszyscy trzej, że trudno jest mierzyć przez samą ilość podatności, bo to tak jak wcześniej powiedziałeś, no na koniec dnia chcemy tą podatność wyprowadzić, a nie tylko ją znaleźć, więc znalezienie jest nie jest celem, jest kamieniem milowym w dojściu do celu. Więc jak podchodzicie do miara. Przykładowo, jak wcześniej chciałeś podchodzić, a jak teraz uważasz, że powinno się podchodzić do mierzenia sukcesu tego, czy robimy dobrze, czy nie robimy dobrze i w jakim kierunku idziemy.

Łukasz: Myślę, że najłatwiejszą rzeczą to byłoby wykazanie, to łatanie, czy nawet taki triaż podatności idzie szybciej w zespołach, gdzie taki security champion jest. Tak, no bo on ma stały dostęp do wiedzy, stałą konsultację. Oczywiście, deweloperzy mogą odezwać się do zespołu bezpieczeństwa, zapytać i tak dalej, i tak dalej. Natomiast gdzieś to tak idzie, powiedzmy, o pieszale, tak, to może nie do końca wiedzą, tak, że mogą coś takiego zrobić. Natomiast łatwo jest wykazać, że tam, gdzie jest security champion, to ta praca idzie, no tak wiadomo, ma dedykowany czas na to i tak dalej, a generalnie podatności są we wszystkich zespołach, tak. Więc też nie zawsze jest tak, ja uważam, że to jest proces, tak. Security championi mogą być, wiadomo, od początku we wszystkich zespołach, ale my podeszliśmy do tego tak, że chcieliśmy, żeby to były szczególnie na pilocie, osoby bardzo zaangażowane, osoby, które będą chciały ciągnąć z nami ten dług, pomagać rozwiązywać problemy i takich osób dalej szukamy tak naprawdę. Nie chcieliśmy tak, że ogłaszamy rekrutację i mówimy, dobra, chodźcie wszyscy do nas, zapraszamy i potem właśnie zobaczymy, co dalej, tylko raczej, żeby to były osoby, które Potem, jak będę wykazywał, że ten program ma sens, to łatwiej mi to będzie udowodnić. Bo jeżeli będzie osoba, która chce być security championem, żeby mieć, nie wiem, logo security championa, badge, tak. I chwalić się gdzieś tam w kuchni, że jest security championem, a nie za bardzo dawać coś od siebie, no to to nie zadziała. i też ciężko będzie wykazać, tak. Później komuś wyżej, że na przykład w tym zespole to idzie, tak. Więc to musi być jako całość. Security championi, oni wszyscy muszą być zaangażowani i to musi działać. Nie wiem, czy będę w stanie tak wymienić właśnie trzy. To jest taka jedna główna rzecz, którą naprawdę bym się na niej skupił. I wydaje mi się, że jeżeli od początku jakby będzie skupienie wokół tego celu, to będzie to łatwo udowodnić.

Krzysiek: Czyli średni czas do wyprowadzenia podatności, tak. Mógłbym tak to ująć. No, myślę, że tak.

Andrzej: To jest taka bardzo często przyjmowana metryka, natomiast to fajnie, że uwypukliłeś jeszcze ten element, bo ja go wyłapałem wcześniej, jak o nim wspomniałeś, ale Prawdopodobnie wyłapałem go dlatego, że mam background info. Jakbym go nie miał, to mógłbym go nie wyłapać, a chodzi mi o to, że startując tym pilotem, nie było tak, że, o dobra, to teraz w każdym zespole wybieramy kogoś i nieważne, czy chce, czy nie, bierzemy, bo w każdym zespole ma być, tylko wybraliście ludzi, których, no nazwijmy to tak, z poprzedniego systemu, przodowników pracy. I oni się spisują, ale też świadomie nie chcieliście, nie chciałeś, nie chcieliście wybrać ze wszystkich. po to, żeby też móc właśnie zmierzyć jaka będzie efektowność w tych zespołach, w których jest security champion, versus w tych zespołach, w których nie ma security championa. I tak samo z mojego doświadczenia należy budować inne gdzieś praktyki związane z DevSecOps. To nie jest tak, że teraz włączamy dla wszystkich, tylko włączmy sobie punktowo, lokalnie, zacznijmy mierzyć, sprawdzać, porównywać i potem nam wyjdzie, czy opłaca się, czy może się nie opłaca, jak szybko może się opłaca, bo może będzie tak, że tyle wartości uzyskujemy, że chcemy mieć to włączyć jak najszybciej dla wszystkich.

Łukasz: To mi się bardzo podoba. To jest też tak, że nawet jak zaczynasz od takiej mniejszej grupy, to na bieżąco możecie różne rzeczy tuningować. No i w mniejszej grupie, wiadomo, to nie wygląda tak, że jest 50 osób na spotkaniu, połowa się nie odzywa, albo więcej niż połowa się nie odzywa, a jest trzech chętnych, czy ambitnych bardziej, którzy cały czas oddają głos i potem pogodzą się. no dobra, to cześć, cześć, cześć, cześć, cześć, cześć, tak. No i wyszliśmy z takiego założenia, żeby to miało jakiś sens, tak. I moglibyśmy powiedzieć, OK, mamy już wszystkich security championów, mamy program, wystartowaliśmy, lecimy, tylko że to na papierze by wyglądało, że to mamy, tak. A jeżeli powiedzieliśmy, że to jest proces, że będziemy pewne rzeczy robić iteracyjnie, będziemy na bieżąco pewne rzeczy poprawiać, no to wygląda to o wiele lepiej. Wiadomo, że to wtedy trwa, wydłuża całą kwestię, natomiast skoro to jest początek jakiś, no to to jest do opanowania wtedy. Natomiast jeżeli, tak sobie wyobrażam, złapanki się bierze tam na przykład 50 osób, i powiedzmy każdego gdzieś tam zadowolić, albo zrobić ankietę, co byście chcieli na przykład i te 50 osób pytać, no to może być ciężko. A zaczynając od małej grupy, można się do pewnych rozwiązań, czy do pewnych rzeczy łatwiej dojść, które sprawdzą się przynajmniej przy większości później.

Krzysiek: Okej, to wskaźniki sukcesów, współpracy, w korelacji z zespołami deweloperskimi. A powiedz mi, czy zauważyłeś może Łukaszu jakieś takie wskaźniki, indykatory sukcesu, współpracy z innymi organizacjami. organizacjami, to może złe słowo, innymi zespołami w organizacji, na przykład z Compliance’em. Czy ten program Security Champions przełożył się jakoś na usprawnienie właśnie pracy z legalnym Compliance’em, a może jeszcze z jakimś innym działem firmy.

Łukasz: Wiesz co, na pewno z naszym działem bezpieczeństwa. Ale wiesz co, to jest powiązane trochę, bo my mamy z kolei większy styk z Compliance’em i gdzieś to się wszystko ze sobą łączy, tak naprawdę. My też często mieliśmy Mieliśmy taki problem, że jeżeli pojawiała się dana rzecz, dany case związany z bezpieczeństwem, to czasami tak jakby nie było wiadomo do kogo się odezwać, jest różna rotacja w zespołach, powstają nowe zespoły i tak dalej. Wystarczy po prostu rzucić w społeczność, security championów. Jest taki, taki temat, nie wiemy czy do kogo uderzyć, czy to u nas w ogóle istnieje w firmie, trochę nawiązuje do podatności. i po prostu ma się odpowiedź bardzo szybko. Więc ta współpraca bezpieczeństwo a development to bardzo mocno urosła. No i właśnie tym samym również compliance i ryzyko, z którym mamy właśnie bardzo dużo do czynienia.

Andrzej: No i to jest właśnie jeden z takich głównych założeń całych inicjatyw Security Champion, że to jest satelita i rolą rolą Security Championów jest ten pierwszy punkt kontaktu z bezpieczeństwem, przez co tak naprawdę offloaduje się tą pracę samego działu bezpieczeństwa, co jak już wspomnieliśmy zawsze jest za małe, no bo bezpieczników zawsze będzie mniej niż inżynierów. No i to się sprawdza w praktyce, jak sam mówisz. Ja mam też przykłady z głowy innych organizacji, gdzie też to tak działa. Tak, tak trzeba żyć.

Łukasz: Aczkolwiek dodałbym, że to też nie jest tak, że powiedzmy wystarczy taki utarty blue team, red team i powiedzmy security championi. Naprawdę warto mieć w swoim zespole bezpieczeństwa, już mówię stricte. Osobę, która zna się na developmencie, która rozumie tak jakby założenia potoku CICD, tego co deweloperzy chcą osiągnąć. bo bardzo często są jakieś, nie chcę powiedzieć kłótnie, ale pewne sprzeczki, czy jakieś wymiany zdań, które ciężko gdzieś pogodzić, czy dojść do konsensusu. A taka osoba, która ma gdzieś ten background i powiedzmy przeszła na tą stronę bezpieczeństwa, chciała to już robić na cały etat, naprawdę robi robotę.

Andrzej: Czyli taka jednostka APSEC. To teraz pytanie podchwytliwe, bo wspomniałem, Trochę na nie odpowiedziałeś, ale pociągnę temat i chciałbym usłyszeć rozważanie, takie za i przeciw, bo ta decyzja gdzieś była podejmowana. Taka osoba od APSECU, która faktycznie rozumie, jak działa generalnie inżyniera oprogramowania, jak się wytwarza oprogramowanie, ale jednocześnie jest bezpiecznikiem, to taka osoba powinna podlegać pod dział bezpieczeństwa pod CISO, czy może taka osoba powinna podlegać pod dział inżynierów pod CTO.

Krzysiek: Odpowiedz mu ono.

Łukasz: Wiesz co. Odpowiem, że nie wiem. My podeszliśmy do tego tak, że ta osoba powinna być w bezpieczeństwie, bo ja gdzieś chciałbym mieć świadomość tego, co się dzieje. A nie wiem, czy do końca, jeżeli ta osoba by była bardziej w developmencie, czy ja bym był tak na bieżąco z różnymi rzeczami, czy mógłbym tworzyć procesy i to by była taka płynna współpraca. Wydaje mi się, że mimo wszystko ta osoba powinna być w zespole bezpieczeństwa. W developmencie są security championowie.

Andrzej: Zgadza się. Tutaj oczywiście nie ma idealnej odpowiedzi, bo można to ułożyć i w jeden i w drugi sposób. Ja się spotykałem, że było to układane w jeden i w drugi sposób. Nawet jak ja byłem taką osobą, to ja byłem w biurze architektów. Więc byłem w inżynierii pod bardziej CTO. W ogóle taki, no nie byłem bezpiecznikiem, ale było to wtedy łatwiejsze, bo ja mogłem tych bezpieczników tam wziawać tą igłę, nie. Ale z drugiej strony w większości sytuacji raczej spotkam się z taką sytuacją, o której ty mówisz, gdzie ten bezpiecznik, nawet jeżeli skupia się na bezpieczeństwie aplikacji i tworzy tą jednostkę APSEC, jedno, dwu, trzyosobową, to raczej jest w dziale bezpieczeństwa i tam sobie siedzi niż w dziale inżynierów.

Łukasz: No. Wiesz co, trochę wracamy do tego, że Wszyscy budują bezpieczeństwo w organizacji. I to też nie jest tak, że np. również mamy zespół architektów. To nie znaczy, że oni się w ogóle nie interesują bezpieczeństwem. Rozumiem, że jest ten benefit dedykowanej osoby, natomiast zawsze, jeżeli jakieś rozwiązania są wdrażane w XTB, to to bezpieczeństwo również jest zawsze brane pod uwagę. przynajmniej na razie, nie jest tak, że potrzebujemy kogoś dodatkowego w developmencie, raczej idziemy na razie w tą stronę security.

Krzysiek: No tak, tych podejść jest wiele. To jest kontekst. Tak, to wszystko zależy od kontekstu, ja np. wynosząc kontekst z małej organizacji wiem, że CTO, bo po prostu nie mamy CIS-owych forum. Okej, Łukaszu, ale przychodząc do mojego pytania, chciałbym się ciebie zapytać, jaką najważniejszą lekcję według ciebie wyciągnąłeś po przeprowadzeniu takiej transformacji, po wprowadzeniu tego programu Security Champions. Co było dla ciebie najważniejsze, co wyniosłeś ze sobą.

Łukasz: Sporo było tych rzeczy.

Andrzej: Powiedz o tych dobrych.

Łukasz: Przede wszystkim o to, że często osoby, które bardzo mocno dbają o bezpieczeństwo, na przykład w developmencie, nie za bardzo je widać. I one gdzieś tam cicho pracują, dbają o to i są takimi ambasadorami. I to niekoniecznie, wiadomo, musi być jakiś program security championów, tylko te osoby są w całej organizacji gdzieś rozsiane i gdzieś ich głos powinien być usłyszany, moim zdaniem. Kolejna rzecz, również ważna, to tak naprawdę nie wyobrażam sobie braku tej widoczności, co się dzieje w wytwarzaniu oprogramowania. I oczywiście możemy podejść trust and verify, Natomiast gdzieś to bezpieczeństwo oprócz weryfikowania powinno pewne rzeczy wskazywać, jak to powinno być robione. W waszym szkoleniu też była o tym mowa, że na początku tej całej drogi rzeczywiście możemy obserwować, zgadzać się na pewne rzeczy, które są wprowadzane w ramach kodu, rozmawiać o tym, dlaczego tak, dlaczego inaczej, a dopiero na przykład później podejść czegoś takiego, żeby blokować np. pewne wydania, czy pewne merge requesty, jeżeli np. wprowadzają krytyczne, później wysokie, to jakby trzeba właśnie uszyć na miarę organizacji, nie wszystko na hura, że lecimy, blokujemy i wszyscy będą zadowoleni, bo wtedy to program Security Championów i DevSecOps to by się bardzo szybko skończył.

Andrzej: I to mi się też podoba, że robisz ten nacisk, bo już to któryś raz nacisnąłeś, że to jest czas, że to się nie wydarzy w miesiąc, to się nie wydarzy w kwartał, to się nawet nie wydarzy dwa kwartały. To jest cała jakaś droga, jakaś transformacja, gdzie trzeba sobie z góry powiedzieć, że jeżeli chcemy przejść z punktu A do B, to to zajmie 12, 18, 24 miesiące. Będziemy robić Będziemy robić progres, ale ten progres też nie będzie super płynny, raczej będzie skokami, gdzie coraz wyżej wskakujemy i sobie przygotowujemy się na kolejny skok, ale to zajmie nam czas i też będziemy się uczyć, będziemy popełniać większe lub mniejsze błędy, będziemy potem się uczyć na tych błędach, poprawiać, a przez to na koniec tego czasu Będziemy coś uszy tego na miarę coś co działa dla nas i i faktycznie jest efektywne a nie tylko jest takie doczepione i compliance się cieszy bo jest ptaszek.

Łukasz: przypomniała mi się teraz ważna kwestia, którą też gdzieś bym zaznaczył, to żeby przyjąć sobie właśnie ten bufor na te błędy. Bo często, wiecie, jest tak, że wszystko jest, wiecie, co do dnia, będzie wtedy, będzie, wtedy skończymy POC, wtedy wdrożymy narzędzie, wtedy zrobimy security czempionów, program i tak dalej, i tak dalej. Zawsze przy planowaniu planowałbym ten bufor błędów, tak. Wiadomo, że to jest ciężkie, żeby określić, natomiast zawsze Zdarzają się fakty zawsze zdarzają się problemy i trzeba o tym pamiętać.

Andrzej: A jeżeli się nie zdarzą to będzie miłe zaskoczenie że akurat zrobiliśmy przed czasem. więc lepiej założyć bufor.

Krzysiek: Lepiej się miło zaskoczyć niż.

Andrzej: niż zdenerwować. Zdenerwować, dokładnie.

Krzysiek: A Łukasz, powiedzieliśmy o dobrych stronach, o tym, co wyniosłeś w pozytywnym znaczeniu. A gdybyś miał zacząć od nowa, gdyby miał być to taki greenfieldowy projekt, powiedzmy, że XTB dopiero powstaje, co zrobiłbyś inaczej.

Łukasz: Muszę się chwilę zastanowić.

Krzysiek: Dostajesz najlepszych security championów. Mnie i Andrzeja.

Łukasz: No to wtedy nic.

Andrzej: Jak tam im kierujesz.

Łukasz: Kurczę, wiecie co. Myślę, że od razu bym szukał dedykowanej osoby, która pomoże ten program poprowadzić. Cały czas pomoże stymulować właśnie tych security championów, bo ja byłem inicjatorem, tak jakby, całego programu. Ja na początku stymulowałem, proponowałem różne rozwiązania. Natomiast nie tylko z security championami się zajmuję. I gdzieś tam czułem, że w ramach programu w pewnym momencie to była parabola, że pewne rzeczy były bardzo mocno intensywne, później to troszeczkę spadało, spadało, później znowu było trochę intensywnie, a lepiej by ten poziom był w miarę wyrównany tak naprawdę. Jak już miałbym taką osobę o wiele wcześniej, to też bym na pewno zadeklarował bardzo jasne zasady tego, co ci security championi będą robić. Bo my rzeczywiście, jak wdrażaliśmy ten program, to my też na początku nie wiedzieliśmy. Wiedzieliśmy oczywiście przykłady z AWASPA, przykłady z różnych mentorów, że tak powiem, bezpieczeństwa, natomiast Gdzieś trzeba poważnie usiąść się nad tym zastanowić, a nie być z doskoku do takiego programu. To myślę, że to bym na pewno zmienił.

Krzysiek: Czyli osoba na full time, która limituje ten program, jest ciągle dostępna dla czempionów.

Andrzej: Tak, która po prostu opiekuje się programem. Ja tutaj z własnego doświadczenia… Dwie okejki. Zgadzam się. Trudno jest uformować, a potem prowadzić ten program, jeśli nie robimy tego na full time. Więc tutaj mega propsy.

Łukasz: Wiesz co, bo oczywiście to też nie można powiedzieć, że to nie da się zrobić. Da się, tylko pytanie, czy się chce logować na przykład po 18 jeszcze do pracy, coś jeszcze, coś jeszcze, tak, no bo… Da się to zrobić, ale nie wiem, czy to tak powinno wyglądać. Raczej, raczej dedykowana osoba, tak bym powiedział.

Krzysiek: Nie no, zdecydowanie. Robienie tego, nie chcę powiedzieć, że robiliście to po łebkach, bo wiem, że nie robiliście tego po łebkach, ale wiem, że na pewno musiałeś włożyć dużo czasu jeszcze po czasie swojej pracy, żeby dociągnąć te rzeczy, a posiadanie takiej dedykowanej osoby. jednak byłoby bardzo, bardzo, bardzo pomocne. Łukaszu, gdzie zmierzacie z tym programem. Bo powiedzieliśmy o przeszłości, powiedzieliśmy o tym, jak go budowaliście, powiedziałaś o tym, co może można by było zrobić lepiej, a zastanawiam się, jakie kolejne kroki macie w waszym arsenale pomysłów.

Andrzej: Takie, którymi możesz się podzielić.

Łukasz: Zawsze mam to na uwadze. Wiecie co, tak naprawdę wdrażanie kolejnych narzędzi. Zwiększanie powoli restrykcji, jeżeli chodzi o to, co można, co nie można. No i kolejne pomysły na to, jak bardziej angażować security championów, czy generalnie budować taką kulturę bezpieczeństwa, takie miejsce, gdzie Powiedzmy każdy z firmy może zajrzeć, czy to jest spotkanie, czy to jest jakiś konfluens, czy to jest czat. Może być wiele form na raz, gdzie każdy może wejść, zapytać, dowiedzieć się czegoś i wtedy frontem są i security czempionowie, jeżeli chodzi o development. core, taki typowy security, to jesteśmy taki typowy blue team, tak, red team, żeby to bezpieczeństwo było jak najbardziej widoczne i cały czas przy tych pracownikach, żeby to nie było tak, że to jest wiedza tajemna i myślę, że właśnie jeżeli chodzi o security czempionów, no to to jest mocna karta, żeby rozszerzyć ten obszar właśnie developmentu w tą sferę dostępności, bezpieczeństwa ogólnie.

Krzysiek: A mówiąc o przyszłości, jeżeli możesz uchylić rąbka tajemnicy, czy gdziekolwiek pojawiają się rozwiązania z zakresu gen AI, które wspomagają albo będą wspomagać taki program.

Łukasz: Pomidor.

Andrzej: Ale tutaj od razu. No bo musieliśmy geneja gdzieś tutaj wrzucić, ale Łukaszu, bo jeszcze w Kuluarach jak piliśmy sobie kawkę, kawka wypita, bardzo smaczna, bardzo dużo opcji. Można powiedzieć, że dla mnie nawet trochę za dużo, ja jestem prosty człowiek, zwykła czarna, czarna jak noc, ale Łukasz, powiedziałeś, że w zasadzie w chwili obecnej gdzieś tam trwa rekrutacja, chcecie znaleźć osobę o tabseku, więc wspominam o tym, bo kto. kto wie, może ktoś po tej rozmowie się do ciebie odezwie, ktoś ciekawy i może zawita właśnie do waszej organizacji teraz lub w przyszłości, więc powiedz dwa słowa, kogo szukasz.

Łukasz: Szukamy do zespołu APSEC inżyniera bezpieczeństwa, który między innymi będzie się zajmował prowadzeniem całego programu Security Championów, będzie dla nich takim głównym stykiem kontaktowym, jeżeli chodzi o bezpieczeństwo. Jeżeli chodzi o inne takie obowiązki, które taka osoba by się zajmowała, to myślę, że już przekieruję do ogłoszenia. Nie przygotowałem się dokładnie z całości, która tam będzie, natomiast ogłoszenie cały czas jest, więc…

Krzysiek: To my je gdzieś tutaj podlinkujemy.

Andrzej: Podlinkujemy je, natomiast ja od razu wspomnę, że to jest pozycja liderska, bo to będzie cały zespół w formie jednej osoby.

Łukasz: To znaczy, jeżeli mówimy w takim kontekście, to rzeczywiście. Natomiast to nie jest jakby stanowisko, które będzie miało menadżerskie, że tak powiem, informacje o tym. Natomiast to będzie bardzo samodzielne stanowisko, które będzie wymagało rzeczywiście umiejętności, zarządzania czasem też innych, no bo właśnie security championów, więc powiedzmy, że trochę podchodząca rzeczywiście pod taką rolę liderską.

Andrzej: Więc gdzieś tam świetny krok w karierze, jeśli ktoś planuje rozwój w bezpieczeństwie aplikacji długoterminowo, średnio długoterminowo. To prawda.

Krzysiek: I szczególnie w takiej organizacji.

Andrzej: No tutaj na pewno można zyskać bardzo cenne doświadczenie, bo biorąc pod uwagę w jakiej branży jesteście, jednak finansowej, macie bardzo dużo różnych sił, które na was oddziałują i rynkowych i compliance’owych. No i jesteście firmą technologiczną tak naprawdę. No to to jest trudno znaleźć lepsze miejsce. przynajmniej w naszej szerokości geograficznej, ewentualnie można znaleźć równie dobre.

Łukasz: To prawda, więc zapraszamy.

Krzysiek: Dobra, panowie, dobijając do brzegu, Łukaszu, czy planujecie dziś podzielić się tą historią na zewnątrz firmy. Jakieś uczestnictwo w meetupie, konferencji, podcast, poza. tym, co nagrywamy tutaj.

Andrzej: Łukaszu, od razu zapraszam na ścieżkę The Hacksami 2025. Czekamy na CFP.

Łukasz: Tak, odpowiadając najpierw na pytanie Krzyśka. Chcemy się tym dzielić, natomiast chciałbym trochę więcej powiedzieć, jak trochę już więcej zrobimy. Wiadomo, cały czas jest dużo do zrobienia, natomiast na pewno będziemy się chcieli dzielić tą wiedzą i i chcemy, żeby ta kultura bezpieczeństwa nie tylko była u nas w organizacji, ale generalnie przelać ją na inne organizacje. i myślę, że to też jest jakiś taki stymulant dla security championów. Być może jakiś security champion chciałby wystąpić w takiej prezentacji, jak wygląda jego praca, czy jak taki program był budowany, bo to nie muszą być koniecznie ja.

Andrzej: Tutaj ja od razu powiem, w ramach Rady Programowej Ścieżki Secure SDLC na THS-ie 2025, jeśli podeszecie nam ciekawy temat, to będzie akcept.

Krzysiek: Tak, na pewno ja tutaj się zgodzę w zupełności z Tołem Andrzej i z Tołem Łukasz, że takie miejsca jak konferencje, gdzie mamy okazję przedstawić nasz punkt widzenia, to jest pouczające nie tylko dla słuchających, ale również dla tych osób, które występują, bo ten feedback i ten networking, który później zdobywamy po prelekcji jest w pewnym sensie takim perpetuum mobile, które jeszcze bardziej napędza czy to security championów, czy to liderów takich jak ty, czy całe całe organizacje. Motywuje. Motywuje, dokładnie.

Andrzej: I inspiruje nie tylko samą organizację, ale też na zewnątrz, tak jak właśnie Was zainspirowało trochę BNP, więc warto się dzielić wiedzą, doświadczeniem i pokazywać innym, jak zrobiliśmy, jak można to robić. Nie chodzi o to, że trzeba zrobić dokładnie tak jak my, ale patrzcie, my zrobiliśmy to tak, fajnie wyszło, może u Was też się sprawdzi.

Łukasz: To prawda. To myślę, że to jest takie marzenie moje, żebym ja albo ktoś z mojego zespołu wystąpił na waszej ścieżce. Nie obiecuję, że to 2025, żeby nie było takich deklaracji, żebyście potem się zawiedli, ale na pewno… pojawimy się.

Krzysiek: Łukaszu, nagrywamy to 8 kwietnia. Macie jeszcze do THS-u sporo czasu. THS w październiku, więc zgadza się. Jak zaczniecie robić dzisiaj prezentację.

Andrzej: CFP otwieramy wcześniej, więc ja tam będę sprawdzał skrzynkę trzy razy na dzień.

Łukasz: Dobra.

Krzysiek: Łukaszu, tak jak powiedziałem, dobijamy do brzegu razem z Andrzejem. Bardzo ci dziękujemy za tą rozmowę. To było niezwykle pouczające i Z mojej strony fajnie było usłyszeć punkt widzenia firmy finansowej. Nie miałem w swojej karierze okazji jeszcze pracować w takiej firmie, więc naprawdę to był kawał dobrej rozmowy.

Andrzej: Ja popieram. Przede wszystkim wydaje mi się, że jest sporo wartości dla innych firm, które myślą o programie Security Champions, o budowywaniu bezpieczeństwa w proces wytwórczy, o jakiejś transformacji DevSecOps. Są kilka kroków przed wami. No i tak jak kiedyś Ty zainspirowałeś się kimś innym, tak teraz ktoś inny będzie mógł się zainspirować Tobą.

Łukasz: Myślę, że jeżeli chociaż jedna osoba się zainspiruje, to już było warto.

Andrzej: A to masz jak w banku.

Łukasz: To super.

Krzysiek: Wszystkich zainspirowanych zapraszamy do sekcji komentarzy. Podzielcie się i dajcie znać Łukaszowi czy ktoś się już zainspirował.

Andrzej: O właśnie. Zapraszamy.

Krzysiek: To co dzięki Łukasz i w takim razie do zobaczenia.

Andrzej: Do zobaczenia kiedyś w przyszłości i w internetach.

Łukasz: Dokładnie.

Andrzej: Kończymy. Zrobione.

---