W specjalnym odcinku czas na podsumowanie 2024. Andrzej i Krzysiek omawiają kluczowe wydarzenia i wnioski z minionego roku w świecie cyberbezpieczeństwa. Skupiają się na sukcesie pierwszej kohorty kursu „ABC DevSecOps„, gdzie blisko 60% kursantów ukończyło program i zaliczyło ćwiczenia praktyczne. To fenomenalny wynik w świecie kursów online. Podkreślają dojrzałe podejście firmy, która grupowo szkoliła swoich Security Championów, omawiając materiały i wymieniając się doświadczeniami. Takie podejście przełożyło się na synergiczny efekt i zwiększoną wartość dla organizacji w zakresie bezpieczeństwa aplikacji.
Kluczowe Aspekty DevSecOps i Strategie Bezpieczeństwa:
Podział Odpowiedzialności za Bezpieczeństwo w Procesie Wytwórczym: Krzysiek i Andrzej zgodnie twierdzą, że odpowiedzialność za bezpieczeństwo nie powinna spoczywać wyłącznie na programistach ani na klasycznych zespołach cyberbezpieczeństwa. Proponują umieszczenie zespołów Application Security lub Product Security bezpośrednio pod CTO, a nie pod CISO, aby zapewnić efektywne wdrażanie praktyk bezpieczeństwa w cyklu wytwórczym.
Ocena IAST i Inwestycje w Szkolenia Pracowników: Poruszają temat IAST (Interactive Application Security Testing), argumentując, że narzędzie to często nie jest warte swojej ceny i kosztów wdrożenia, zwłaszcza w porównaniu do efektywności SAST i DAST. Podkreślają, że znacznie lepiej jest inwestować w szkolenie pracowników, co przynosi realną wartość dodaną w podnoszeniu świadomości bezpieczeństwa w organizacji.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Andrzej: Dzień dobry, witamy, witamy po w zasadzie dość sporej przerwie. Ostatnio już słyszeliśmy, widzieliśmy, kurczę, już nawet nie pamiętam kiedy. Ale to na pewno raczej, no?
Krzysztof: No, to chyba była końcówka października. Tak, dzień dobry.
Andrzej: No właśnie, a mamy grudzień, trochę nas nie było, ale jeśli mamy być szczerzy, to byliśmy obłożeni, mieliśmy ważne gdzieś tam tematy na głowie i niestety czasowo, priorytetowo nie udało się nagrywać odcinków podcastu. W przyszłym roku postaramy się podciągnąć, ale o tym za chwilę, bo dzisiejszy odcinek jest takim odcinkiem specjalnym. Chcemy porozmawiać, co wydarzyło się w bezpiecznym kodzie w minionym roku, jaką mamy wizję tego, co ma się wydarzyć w przyszłym roku. No i może coś tam też wpadnie, jakiegoś technicznego. Na pewno dwa tematy techniczne wpadną. Takie dwie rozminki, które gdzieś tam chodziły w kilku ostatnich tygodniach za mną z okazji szkoleń, które często są upychane na koniec roku. I tam mam takie dwie… Takie dwa szersze pytania odnośnie bezpieczeństwa w procesie w twórczym do ciebie, Krzysiek. Chcę poznać twoją opinię, a potem się podzielę swoją. Natomiast robiąc najpierw ten krok wstecz, to Krzysiek, może w dwóch słowach powiedz, bo nie każdy musi kojarzyć, czemu nas nie było? Czy my byliśmy tak zajęci od tego września do, no w zasadzie do końca listopada?
Krzysztof: Tak, tak. Słuchajcie, myślę, że część z Was może być świadoma tego, co u nas się działo. Byliśmy obłożeni pierwszą kohortą kursu ABC DevSecOps, który zakończył się miesiąc temu, myślę. To było gdzieś tak miesiąc temu. Więc to może nie spędzało nam sen z powiek, ale na pewno było dosyć kosztowne czasowo. Kohorta się skończyła, grupa przeszła, mamy świetny wynik, jeżeli chodzi o ilość osób, które ukończyły kurs od deski do deski, łącznie z zaliczonym ćwiczeniem praktycznym, co dawało certyfikat ukończenia. I to z tego, co mnie pamięć nie byli, to było blisko 60 osób, więc to było więcej jak połowa wszystkich kursantów, co… w świecie kursów jest po prostu fenomenalnym wynikiem. To trzeba od razu sobie przyznać i powiedzieć szczerze.
Andrzej: Tak, tak, tak. Dokładnie. My mieliśmy chyba 110 kursantów, z czego te 60, nie jestem pewien, czy równe 60, czy tam z groszami, nie tylko skończyło, nie tylko ukończyło kurs ABCD w SecOps. ale też odrobiło wszystkie potrzebne zadania domowe, czyli wbudowało te narzędzia, które przedstawiam w pipeline, uruchomiło ten pipeline na aplikacji testowej, zwróciło wyniki. Wszystkie narzędzia, które były wymagane, gdzieś tam mapują się do typowych praktyk bezpieczeństwa, które powinny być w aktualnych procesach wytwórczych. No i biorąc pod uwagę właśnie liczebność grupy, która nie tylko ukończyła, czyli po prostu tam przeklikała materiał na platformie kursowej, ale ukończyła zadania domowe, no to jest świetny wynik. To jest świetny wynik, bo w kursach online generalnie jak jest coś koło 1 trzeciej, czyli coś koło 30% ludzi, którzy w ogóle przejdą szkolenia, czyli obejrzą materiał, już nawet nie chodzi, żeby coś przeklikało, tylko samo obejrzałem materiał, to już jest sporo. To już jest sporo, 30%. No to my mamy double dat. Zbliżamy się do około 30%. No to mnie samego, a trochę doświadczenia w kursach online mam nie tylko w tworzeniu, bo mam jeszcze ofensywne testowanie o aplikacji, ale też jako odbiorca kursów online, bo mam też… wejściówki do wielu różnych kursów online. Mnie bardzo, bardzo pozytywnie zaskoczyło taka frekwencja, no i potem oczywiście pozytywne opinie, które, Krzysiek, ja kojarzę, że ty dostawałeś nawet opinie na DM-kach na platformie.
Krzysztof: Tak, wchodziły opinie bokiem, wchodziły też opinie kanałem oficjalnym, no i jest naprawdę dobrze. Na pewno lepiej, niż bym o tym pomyślał, a Z natury jestem pesymistą.
Andrzej: Otwierdzam, że jedzie wszystko zawsze w niezbyt różowych barwach. O, to się nie udało, to tamto.
Krzysztof: Ale wyszło, ale wyszło i będziemy startować z drugą grupą. Nie wiem, czy w podobnym formacie kursu kohortowego to jest jeszcze do dogadania w ramach naszej retrospektywy po pierwszej edycji, ale na pewno druga grupa statuje wiosną. w jasną 2025.
Andrzej: Dokładnie tak. I tutaj zrobię jeszcze mały krok wstecz, bo w zasadzie powiedziałeś, że jesteś pesymistą, ale na tyle, na ile cię znam, to ja bym cię określił jako realista. Więc nie hajpujesz się za bardzo jak optymista, ale też nie jesteś takim party pooperem, który mówi, że to na pewno nie wyjdzie, tylko tak keeping it real, że to ma szansę. To gra na naszą korzyść, to tamto gra na naszą niekorzyść. Zrobimy wszystko, co w naszej mocy, żeby dowieść, ale zobaczymy.
Krzysztof: To w przykładzie mojego realizmu byłem prawie pewny, że narzędzie, które miało nam pozwolić na to, aby laboratorium działało u wszystkich tak samo, czyli Docker, spowodowało, że to działało u wszystkich inaczej.
Andrzej: Może
Krzysztof: nie u wszystkich, ale trzeba mieć ze tyłu głowy gdzieś, że faktycznie konteneryzacja nie jest łatwym tematem, a konteneryzacja na wielu platformach nie jawi się tak łatwo, jakby można było to kupić od Dockera, tak out of the box, że postawisz sobie po prostu obraz, tworzysz z niego kontener i będzie u wszystkich działać tak samo. No nie, okazało się, że nie. No oczywiście. Zapomnieliśmy, że są inne architektury procesorów, nie tylko te, które oferuje Apple w ramach swoich procesorów M z serii M, że są jeszcze procesory intelowskie i tak dalej.
Andrzej: Ale wszystko się udało rozwiązać i z tego, co kojarzę, to konkretnie w tych przypadkach, co mi się też bardzo podobało, kursanci sobie sami pomagali na platformie. Nawet z naszej strony ta pomoc była utrudniona, bo ani ty, ani ja nie mamy maszyn Windowsowych, tym bardziej na Intelach, ale inni nasi kursanci mieli i byli skorzy do pomocy i w końcu w końcu udało się te problemy rozwiązać, więc tutaj wszystko wyszło dobrze, happy end. Ja tutaj mam jedną uwagę, która mi się szczególnie spodobała w kontekście… jednej firmy, jak podchodziła do przerabiania materiałów. Na razie jeszcze nie będę mówił jakiej firmy, bo może uda się z nimi szerzej o tym porozmawiać. Natomiast tą koncepcję, jaką oni mieli, była taka, że mając wewnętrzny zespół security championów, czyli zespół zbudowany z osób w procesie wytwórczym, w procesie deweloperskim, które są które są taką pierwszą linią kontaktu w sprawach bezpieczeństwa. No i co z tego wynika? Taki zespół powinien mieć jakieś pojęcie o bezpieczeństwie, czyli trzeba go w jakimś stopniu wyszkolić. To ta firma podeszła do tego bardzo sprytnie i bardzo dobrze. Wzięła cały zespół, kupiła inwejściówki na ABCD, ale potem… nie zostawiła ich tak samopas, tak? Dobra, no to przeróbcie sobie to szkolenie i tyle. A potem przyjdźcie i zaczniecie wnosić wartość. Tutaj mogłoby się to tak nie spiąć. Niestety świat nie jest idealny. Oni podeszli do tego w ten sposób, że grupowo mieli wbite spotkania raz w tygodniu, gdzie omawiali. konkretne materiały z konkretnego tygodnia, z konkretnego modułu i omawiali je pod kątem feedbacku. Czyli po pierwsze, mieli ten driver, każda z poszczególnych osób miała ten driver, żeby przerabiać ten materiał z tygodnia na tydzień, no bo muszę go przerobić, żebym tam w piątek czy w czwartek na spotkaniu miał o czym powiedzieć, żebym w ogóle wiedział, znał kontekst. żeby nie było tak, że ja totalnie nie wiem, o co chodzi. Więc nie chodzi o to, że ja już muszę teraz rzucać wszystko i ten materiał studiować, ale na pewno chodzi o to… Miałem małe problemy techniczne, ale wracam. Na pewno chodzi o to, żebym wiedział, o co chodzi, żebym znał kontekst, żebym mógł się udzielić po prostu w dyskusji. To raz. A dwa… A dwa, no potem, żeby faktycznie jednak odrobić to zadanie domowe, no bo jak już przerobiłem sam materiał, no to już jest po prostu łatwiej przerobić zadanie domowe. Jak już obejrzałem wideo, jak już przerobiłem lekcje, to potem zrobienie tego zadania domowego, no to już jest taka formalność. No i pomijam ten główny niejako feature dla firmy, gdzie ta grupa security championów realnie wymieniając się informacjami, wprowadzając to, na czym polega, czyli feedback loops, końcem końców na pewno wyniesie sama z tego wartość. I tutaj nie chodzi mi tylko o nasze szkolenie. Mi się podoba podejście do edukacji swoich pracowników w ten sposób. I czemu mówię, że to mi się szczególnie podoba? Dlatego, że kursy, szkolenia online są problematyczne, Z tym wydaniu, że nawet jeśli firma kupi to w jakiejś grupie swoich pracowników, no to jeśli ci ludzie na koniec dnia przerabiają to w takim wydaniu single player, to gdzieś tam tracimy tą wartość, którą możemy wprowadzić do firmy. A tutaj było to zrobione w przypadku multiplayer i niejako jest to pewna symulacja tego, takiego szkolenia, jakby się ono odbywało konkretnie on-site w firmie. Więc nie chodzi o sam ABCD w Sykopsie, w ogóle po prostu podejście do jakiegokolwiek kursu online, jeśli firma już decyduje się na zakup czegoś takiego dla zestawu swoich pracowników, takie podejście, gdzie ci pracownicy mają wydzielony czas w cyklu tygodniowym, gdzie mogą sobie razem omówić ten materiał. i to trwało 5 tygodni, tyle co trwało szkolenie, więc tak naprawdę to nie jest tak, że ten koszt… czasowy będzie teraz nieskończoność. Trwało to pięć tygodni, spotykali się, omawiali i na pewno i sami, ci poszczególni ludzie, wyniosą z tego dużo wartości i jednocześnie firma wyniesie z tego dużo wartości właśnie dzięki takiemu bardziej świadomemu podejściu. Więc samo podejście mi się bardzo podobało. No i jestem pewien, że w kontekście ABCD w Sekops. tutaj na pewno mocno zaowocuje, no bo to nie jest single player game. DevSecOps, proces wytwórczy zawsze dzieje się w grupie. Jeśli jesteśmy solo graczem, to tak naprawdę rzesza problemów, które występują w DevSecOps się po prostu się nie aplikują, jeśli mamy poszczególnego jednego dewelopera, który chce wdrożyć tam 3-4 narzędzia. Jest wtedy dużo, dużo, dużo, dużo, dużo łatwiej.
Krzysztof: Tak, mi się bardzo podobało podejście tej firmy, bardzo dojrzałe podejście do edukacji swoich pracowników, swoich ludzi. To w ogóle też było tak, że te osoby były z troszeczkę różnych specjalizacji, więc tam było część osób, które były programistami, część osób było QA-ami. i bodajże część osób z tej grupy było opsami, więc mieli wiele różnych punktów widzenia na ten sam temat, na temat wbudowywania bezpieczeństwa w potok wytwórczy, mówiąc bardziej konkretnie, podążając za praktykami DevSecOps. I oni też dokonywali pewnej syntezy tej wiedzy, więc mogli sobie cherrypikować, ok, to w naszym kontekście w zasadzie ma sens. to może mniej, bo działamy na takim rynku, jesteśmy obarczeni takimi ramami regulacyjnymi, musimy robić to, a może tego nie musimy robić, więc to było bardzo, bardzo mądre i sprytne. No i jakby nie patrzeć, no to w taki sposób właśnie powinno się do tego podchodzić.
Andrzej: Dokładnie tak. I tutaj chapeau. ba przede wszystkim do ludzi u góry. Nie wiem, kto podjął tam taką decyzję, ale zakładam, że tu nie mówimy o ludziach na poziomie C-level executives, tylko raczej team leader albo zespół inżynierów, w sensie szef zespołu inżynierów lub szef zespołu bezpieczeństwa. Nie wiem, kto podjął tam taką decyzję, ale decyzja była trafą w dziesiątkę. I to pokazuje dojrzałe podejście do edukacji swojego zespołu. Bo znowu, tutaj specjalnie już mam keyworda zespołu, a nie pracowników. Bo zespół może być nawet w projekcie open source. W dalszym ciągu musimy dbać w jakiś sposób o to, żeby zespół się rozwijał, żeby szedł z duchem czasu, tak to nazwijmy, i dbał o te swoje kompetencje zarówno miękkie, jak i twarde. No tutaj konkretnie u nas mówimy o kompetencjach twardych, ale trzepoba, bardzo dojrzałe podejście do edukacji swojego zespołu i do… optymalizacji wartości, jaką się otrzymuje z nowych form edukacji, właśnie takich jak kursy. No, więc tutaj bardzo ciekawe podejście i na pewno to podejście będziemy gdzieś tam, może nie tyle forsować, ale będziemy zachęcać w kolejnych edycjach, że jeśli firma, jeśli jakaś firma kupuje więcej wejściówek, to żeby się zastanowiła nad realizowaniem tego. w podobny sposób, no bo dzięki temu na koniec dnia otrzymają więcej wartości, bo właśnie będzie ten efekt synergii. Różnią perspektyw na te same rzeczy, nie tylko różnych perspektyw, ale przede wszystkim różnych perspektyw wynikających z różnego doświadczenia ludzi, którzy biorą udział w takim szkoleniu.
Krzysztof: Staramy się to sobie podsumować w formie jakiegoś case study. Mamy nadzieję, że się uda to spisać w formie tekstowej, tak żebyście mogli zobaczyć, w jaki sposób podeszła do tego ta firma i co to była w ogóle za firma, bo to też jest ciekawy przykład pod kątem takiej kwestii czysto compliance’owo-regulacyjnej i w jakim kontekście się oni obecnie znajdują. Dobra, Andrzej, oddaję Ci mikrofon, bo wiem, co chciałeś powiedzieć. Właśnie.
Andrzej: Ale świetnie, że zawinąłeś. Tak, na pewno taka retrospecja trafi na bloga Bezpieczny Kot. Natomiast idąc dalej, bo jak już mówimy o szkoleniach, to Krzysiek, nie wiem, czy się orientujesz, ale generalnie końcówka roku to często jest taki trochę nawał pracy, również związany z szkoleniami.
Krzysztof: Chociaż…
Andrzej: Trochę szkolenia, trochę usługi. Można tutaj dać splita, nie wiem, 60-40 dla usług bez szkolenia. Natomiast to, o co ja chciałbym się zapytać albo o czym najpierw wspomnieć, to ostatnio miałem dwa takie szkolenia w zespołach. W zasadzie obydwie organizacje w rynku regulowanym, więc tutaj mają pewne rzeczy, które… do których są zobligowani. Ale moje pierwsze pytanie, bo tutaj była taka szersza dyskusja, rozkminka. Do kogo według ciebie należy bezpieczeństwo w procesie wytwórczym? Więc teraz zwróć uwagę na to bezpieczeństwo w procesie wytwórczym, czyli te wszystkie rzeczy takie jak analiza statyczna, analiza dynamiczna. tutaj będzie większy niuans. dbanie o analizę składu, o bezpieczeństwo, o higienę swoich bibliotek, których się używa. Do kogo w organizacji należy praca z tym związana, a idąc dalej, nie tylko praca na poziomie operacyjnym, kto to robi, ale też kto powinien tym niejako zarządzać według ciebie. I tutaj dam jakieś podpowiedzi, takie generalne, no zarządzać może na przykład cyberbezpieczeństwo, jeśli mamy taki dział, a w branżach regulowanych najczęściej taki dział jest, większy lub mniejszy w firmach, które są w branżach regulowanych. Możemy mieć dział, nazwijmy go szeroko inżynierii, czyli zespoły deweloperskie. Możemy mieć jakiś też administratorów, infrastrukturę, slash devopsów. Gdzie ty byś umieścił te wszystkie rzeczy związane z bezpieczeństwem w procesie wytwórczym, z tak szerzej application security, product security, gdzie byś je umieścił? Kim byś je realizował?
Krzysztof: To może powiem, gdzie bym je nie umieścił. do tego konia z urzędem temu, kto uważa, że powinni to robić programiści i zespoły wytwórcze. Chociaż utopijnie wiem, że są osoby, które namiętnie wyrażają taką opinię, że bezpieczeństwo powinno należeć do zespołów wytwórczych, do programistów. Uważam, że… że nie, przynajmniej z case’ów tych firm, z którymi współpracuję i tych klientów wiem, że to jest po prostu niemożliwe i możemy się tak oszukiwać i słodzić sobie, że będziemy przesuwać wszystko na lewo i w zasadzie to programiści staną się właścicielami bezpieczeństwa w całości, ale programiści mają trochę inne cele do zrealizowania nadane im przez biznes i Wydaje mi się, że w firmie, która dba o velocity i o częstość wydań i tego, jak będzie wydawać, może nie jak będzie, ale ile będzie wydawać, bezpieczeństwo nie leży w takiej wyłącznej odpowiedzialności zespołów wytwórczych. Więc biorąc pod uwagę to, co powiedziałeś, to, że trzeba będzie zarządzać tymi różnymi klockami, które wpinamy w potok. analiza dynamiczna, analiza statyczna, sekrety, analiza składu komponentów i rozbijające się na to jakieś proaktywne może działania w poszukiwaniu w ogóle na przykład złośliwych komponentów, nie tylko podatnych komponentów, to jednak wydaje mi się, że to będzie należeć gdzieś na… pomiędzy zespołem application security slash product security, a zespołem takim platformowym, bardziej zespołem utrzymaniowym gdzieś może w okolicach DevOpsów, ale też nie, na pewno nie w pełni na ich barkach.
Andrzej: To chwila, to pociągnę cię jeszcze za język, bo tutaj trochę tak sprytnie się wymigało się od odpowiedzi, ale… Spokojnie, ja zauważyłem to twoje sprytne wyminięcie i odpowiedzi. Jeszcze cię do ściany tutaj przyprę. I powiedz mi, powiedziałaś, no to można się w takim wypadku znajdować w jakiejś jednostce appsec slash product sec, czyli product security, application security. No dobrze, ale gdzie byś umieścił taką jednostkę? Czyli mamy kogoś, kto będzie tym zarządzał, nazwijmy sobie, że jest to zespół bezpieczeństwa aplikacji, gdzie on będzie? On będzie bliżej deweloperów? On będzie bliżej cyberbezpieczeństwa? Gdzie?
Krzysztof: Bardzo dobre pytanie. Ja ogólnie uważam, może inaczej, na początku swojej kariery, jak zacząłem w ogóle wchodzić szerzej w tematy związane z bezpieczeństwem informacji, takim ogólnym bezpieczeństwem informacji, no to układałem sobie dło w głowie w taki sposób. że zarówno zespoły Product Security czy Application Security, jak zwał, tak zwał, są pod jurysdykcją, że tak powiem, CISO, czyli Chief Information Security Officer. Ono wszystko są w pionie Departamentu Bezpieczeństwa Informacji slash Departamentu Cyberbezpieczeństwa. I dopiero po pewnym czasie zdałem sobie sprawę, że tak naprawdę Product Security czy Application Security to pomimo faktu, że gramy do jednej bramki zwanej bezpieczeństwem informacji, bo obracamy się w triadzie CIA, to tak naprawdę jesteśmy bliżej cyklu wytwórczego i podlegamy pod CTO, więc komórkę procekową czy abcekową umieściłbym właśnie w dziale technologicznym, nie w dziale bezpieczeństwa informacji.
Andrzej: Exactly. I to był core mojego pytania, bo ja się w pełni zgadzam, że nie można oddelegować bezpieczeństwa do programistów i oczekiwać od nich, że teraz będą nie tylko pisali kodzik i dostarczali feature’y, a jednocześnie będą dbać o bezpieczeństwo i będą sobie tym sami zarządzać. No to może jeszcze też tych inżynierów jakości, QA-ów, też ich wydajmy i niech programiści też sobie testują kodzik. Nie, no przecież są w stanie to zrobić, taką selenium odpadzić. Więc tutaj jasne, że nie chodzi o to, żeby sedować więcej pracy, wrzucać programiści i teraz mówić mu, że to ty masz nie tylko robić te feature’y, ale też zajmować się tym wszystkim wokół. i jeszcze to nadzorować. Bo to nie chodzi tylko, że ja będę musiał coś zrobić, wyprowadzić bibliotekę, ale w ogóle jeszcze zarządzać całym procesem. Bo mówimy tutaj o procesach, kto powinien inicjować, wdrażać, a potem utrzymywać procesy. Więc z tym się zgadzam, że programuści tutaj nie są tymi, którzy powinni to robić. Uważam też, że nie jest tym kimś cyberbezpieczeństwo. Czyli nie jest zadaniem działu cyberbezpieczeństwa, który klasycznie odpowiada za bezpieczeństwo organizacji. I pomimo tego, że mamy ten keyword cyberbezpieczeństwo, ten keyword bezpieczeństwo, który przewija się tutaj wszędzie, to jednak nie jest funkcją zespołu cyberbezpieczeństwa, który odpowiada za całość bezpieczeństwa organizacji, nadzorowanie tego, w jaki sposób wytwarzano programowanie. Bo po pierwsze, nie wszystkie firmy wytwarzają programowanie, a po drugie, to wymaga już wiedzy domenowej. I najczęściej osoba, która jest w stanie efektywnie wdrażać różnego rodzaju praktyki w proces wytwórczy, żeby to, co produkujemy, było bezpieczne, musi mieć jakiś background, jakieś zrozumienie inżynieryjne. Najczęściej, ja nie mówię, że musi być programistą, ale powinna kojarzyć, jak wygląda cały proces pracy programisty. end-to-end, od jego maszyny do kodziku na produkcji. Powinna po prostu pływać w tym temacie. Więc pomimo tego, że cyberbezpieczeństwo klasycznie zajmuje się, a może nie tylko, właśnie nie pomimo, ale dlatego, że cyberbezpieczeństwo klasycznie zajmuje się zabezpieczaniem tej fabryki, którą mamy, czyli nie bezpiecznym wytwarzaniem samochodów, ale fabryki, która wytwarza samochody, to Możemy oczywiście do nich przywrócić to zajmowanie się tym, jak wytwarzać bezpieczne samochody. Ale myślę, że każdy już w tej analogii widzi, że będzie to nieodpowiednie. Bo człowiek, który wie, jak zabezpieczyć fabrykę, nie będzie wiedział, co robić, żeby auta, które wytwarzamy w tej fabryce, były bezpieczne. To jest ktoś, kto projektuje mechanizmy, procesy związane z tym, jak tworzyć bezpieczne auta. no to z założenia musi być inżynier, który wie, jak się buduje auta, a nie ktoś, kto wie, jak zabezpieczyć fabrykę, w której budujemy auta. To są dwa zupełnie inne skillsety i pomimo, że jedno i drugie ma ten keyword bezpieczeństwo, to one są po prostu inne. One są z natury inne. Można się tutaj mylić, jest to po prostu łatwe, szczególnie dla osób, które nie mają tego szerszego spojrzenia, które najczęściej mają po prostu eksperci czy specjaliści. Więc można się tutaj pomylić, ale myślę, że teraz, jak pokazałem to na tej analogii, to jest to już trochę prostsze do zrozumienia, no bo możemy, od razu jest to takie bardziej wyczuwalne. I według mnie, tutaj z tobą się zgadzam jak najbardziej, względem na bezpieczeństwo, wdrażanie procesów, potem utrzymywanie tych procesów, doskonalenie ich, powinien odpowiadać jakiś zespół, nazwijmy go sobie Application Security, I ten zespół, jeśli mieliby się wybierać, pod kogo on powinien podchodzić, to on nie powinien podchodzić pod CISO, tylko powinien podchodzić pod CTO, a nie pod CISO. Czyli w organizacji odpowiadałby do kogoś innego, byłby pod kimś innym, byłby w innym pionie. I ten zespół jest takim trochę łącznikiem pomiędzy tym klasycznym cyberbezpieczeństwem a programistami. To jest właśnie też taki bridge, bo taka osoba… Mówi językiem programistów, ale mówi też językiem bezpieczników i tworzy to połączenie. Natomiast nie sądzę albo zrobić można, co chcemy, natomiast z praktyki wiem, że jest nieefektywne, jeśli bierzemy klasycznego bezpiecznika i każdemu teraz zabezpieczać proces wytwórczy, bo taka osoba po pierwsze nie do końca ma narzędzia, które pozwolą mu realizować ten cel, mu lub jej, a dwa, co może nawet jest ważniejsze, nie do końca będzie chciała go realizować. Bo jednak to są fundamentalnie inne rodzaje pracy. Jeśli ja się zapisałem, wszedłem do firmy jako R-tester, to ja chcę testować, a nie chcę rozmawiać z programistami o tym, jak zaimplementować Sasta lub przeglądać wyniki Sasta lub pomagać im pisać regułki. To nie jest to, na co ja się zapisałem. Być może… Ja przejdę swoim zainteresowaniem w tym kierunku, ale nie powinno się ode mnie oczekiwać, że jeśli się zapisałem jako pretester i jestem w zespole testów, moim zadaniem jest testowanie bezpieczeństwa organizacji, to, że będę podchodził z uśmiechem na ustach do teraz pracy z deweloperami, bo to jest po prostu fundamentalnie co innymi. Tak jak wziąłbym dewelopera i powiedział mu, że teraz w zasadzie… to my cię zatrudniliśmy jako dewelopera, jako programistę, tam powiedzmy Javy, będziesz backendy robił, ale wiesz co, to może teraz zaczniesz być też testerem jakości i tam zaimplementujesz testy i będziesz się wszystkim w testach opiekował. I znowu, jeśli ktoś ma takie aspiracje, żeby rozstrzymać swój skiset, to jak najbardziej tak. Ale większość programistów chce być programistami. Większość testerów bezpieczeństwa chce testować bezpieczeństwo. I jeśli będziemy wrzucać takie dodatkowo obowiązki, które brzmią podobnie, bo mają keyword bezpieczeństwa, a tak naprawdę fundamentalnie wymagają innych skillsetów, no to nie będziemy mieć efektywnego respona, że zespół też nie będzie po prostu zadowolony. I nikt nie będzie tutaj zadowolony. Ani organizacja, bo nie będzie efektów pracy, ani poszczególne osoby, które wchodzą w skład organizacji, bo… są zmuszane do robienia czegoś, czego tak naprawdę nie chcą robić i nie na to się zapisywały i na koniec dnia przepalamy hajs, a nic za bardzo z tego nie uzyskujemy. Więc tutaj widzę, że się zgadzamy.
Krzysztof: Dokładnie. Tak, ja bym chciał się tylko dodać do tego, co powiedziałeś, że Może włożę trochę kij w mrowisko, bo wiem, że sporo osób przeszło tę drogę w taki sposób, a nie w inny. Ja nie uważam, że najlepszą ścieżką, żeby stać się osobą od Application Security czy Product Security jest ścieżka wyjścia z cyberbezpieczeństwa. Wręcz odwrotnie. Uważam, że łatwiej jest nauczyć się tych umiejętności związanych z AppSeciem czy z ProdSeciem, będąc programistą. QA-em czy OPS-em, niż w drugą stronę, będąc pentesterem, który pracował od projektu do projektu, nauczyć się to, jak wygląda cykl wytwórczy, z czym mierzą się zespoły wytwórcze i potem niejako grać z nimi do jednej bramki, będąc tym ProdSec-iem czy AppSec-em na Ingenierom.
Andrzej: Oczywiście, w stu procentach. Wydaje mi się, że Steve Ballmer kiedyś powiedział taką anegdotkę, że Czy wolałby nauczyć programistę marketingu i sprzedaży, czy marketera i sprzedawcy nauczyć programowania i wolałby to pierwsze, czyli wziąć programistę i nauczyć go marketingu i sprzedaży, to byłoby łatwiejsze. A Gary McGraw, ojciec bezpieczeństwa aplikacji, autor pierwszej książki o bezpieczeństwie aplikacji jeszcze w latach dziewięćdziesiątych, współtwórca dużych firm związanych z bezpieczeństwem aplikacji. już od wielu lat jest na emeryturze, bo dosyć dobrze mu poszło z tymi firmami. Darren McGraw powiedział dokładnie to samo w odniesieniu do bezpieczeństwa, czyli dużo łatwiej jest wyszkolić programistę z tematów związanych z bezpieczeństwem i żeby rozumiał bezpieczeństwo i żeby był efektywny w implementacji, nawet w opisywaniu, w działaniu, wpływaniu w cyberbezpieczeństwie niż na odwrót, niż wziąć. bezpiecznika i uczynić go inżynierem oprogramowania. Oczywiście osoby techniczne potrafią programować, ale jest różnica pomiędzy ja programowałem sobie sam, a ja uczestniczyłem w procesie wytwórczym, gdzie współpracowałem z innymi ludźmi, gdzie musiałem trzymać się pewnych procesów produkcji. Jak działamy solo, piszemy sobie jakiś skrypcik, przeklejąc rzeczy ze stackoverflowa i łącząc to taśmą klejącą. To nie jest inżynieria oprogramowania. To jest programowanie, ale to nie jest inżynieria oprogramowania. A jednak w procesie wytwórczym, jeżeli zaczynamy pracować nad kodzikiem, który jest produkcyjny, za który ktoś płaci, żeby ten kod działał, żeby był dostępny, to wchodzą pewne wiele. Wchodzi tak wiele różnych rzeczy, które trzeba robić, że one po prostu wymagają na nas podciągnięcia naszych umiejętności jako programistów, ale jednocześnie zyskujemy pewne zrozumienie. potoku pracy i tego zrozumienia nie da się… Jest bardzo trudno nabyć się po prostu czytając o tym. Lepiej to porobić, więc ja tutaj się w pełni zgadzam. Wolałbym mieć programista i nauczyć go cyberbezpieczeństwa, niż wziąć bezpieczynka i nauczyć go programowania slash inżynierii oprogramowania. Byłoby to po prostu z mojej strony łatwiejszym zadaniem. Nie chodzi o to, że się nie da. da się, jak najbardziej, szczególnie jeśli ktoś chce. No tylko tutaj wchodzimy też, że często takie osoby też po prostu nie chcą. I wracam do tego, co powiedziałem. Jak ktoś się zapisuje, żeby być pentesterem, to chce pentestować, a nie bawić się sastami. Więc jak ktoś nie chce, no to konia można do wodopoju doprowadzić, ale to sam się musi napić wody.
Krzysztof: Ja myślę, Andrzej, że najlepszym przykładem jesteś ty sam i twoja historia i twoja kariera. i sam możesz powiedzieć, jak wyglądałoby twoje zrozumienie tematów związanych z cyklem wytwórczym, gdybyś po prostu kiedyś nie pracował jako programista.
Andrzej: I wyglądałoby dokładnie, tak. zakładam, że wyglądałoby dokładnie w ten sposób, że w dalszym ciągu, tak jak wcześniej, jak najpierw działałem jako bezpiecznik, potem działałem jako programista, potem znowu jako bezpiecznik. wyglądałoby tak jak w tej pierwszej fazie, czyli bezpieczeństwo jest najważniejsze, ja wiem najlepiej, wy to jesteście jacyś głupi, bo jak można popełniać takie śmieszne błędy, jak można takie XSS-a zrobić, albo jak można tutaj zrobić takiego buffer overflow-a, przecież to jest easy peasy, lemon squeezy, ja jestem w ogóle najlepszy i… I powinniście mnie nosić na rękach. Bo ja tutaj mam o bardzo ważną funkcję bezpieczeństwa waszego oprogramowania. Potem rzeczywistość zweryfikowała moje spojrzenie na wytwarzanie oprogramowania i zdałem sobie sprawę, że te wszystkie błędy to nie jest tak, że ktoś nie wie, tylko są inne priorytety. Innych rzeczy się wymaga od zespołu deweloperskiego. na co innego jest nacisk. Ale tak, więc tutaj w moim przypadku bardzo dużo dało mi praca jako inżynier oprogramowania. Dobrze, więc powiedzieliśmy trochę o ABCD, nawet wspomniałeś, że będziemy wracać w przyszłym roku na wiosnę. Tak, będziemy. Powinniśmy tutaj dość ważny wątek, który mi po głowie chodził od jakiegoś czasu, bo na obu tych szkoleniach, które przeprowadzałem, była o tym dyskusja. W jednej firmie była bardziej, nazwijmy to, na czasie, bo ten problem był palący i taki realny w tym konkretnym punkcie czasu, bo tam konkretnie jest nacisk na to, żeby zespół testerski… zajmował się różnymi rzeczami z APSEC-a, a nie od tego są. Nie należałoby tego od nich wymagać. W drugiej firmie ta dyskusja była mniej paląca, dlatego że te decyzje gdzieś tam dopiero będą podejmowane w przyszłości, więc łatwiej już teraz, jak mamy pewne zrozumienie, to łatwiej będzie te decyzje podjąć za pierwszym razem, żeby od razu były… dobrze podjęte. Ja mam jeszcze jedno takie szybkie pytanie, które też przez chwilę chodziły mi po głowie, potem doszedłem do wniosku XD. Mianowicie, Krzysiek, na pewno kojarzysz coś takiego jak IAST, czyli Interactive Application Security Testing. I teraz powiedz mi dwa pytania, albo jedno szersze. Czy miałeś do czynienia z jakimiś IAST-ami, to raz, a dwa, tak produkcyjnie, A dwa, to czy uważasz, że IAST ma sens, czy nie? Czy według ciebie IAST nie ma sensu?
Krzysztof: Tak, IAST. Nie, nie miałem produkcyjnie z tej strony nigdy pracować z systemami klasy IAST, ani ich wyrażać. Może z racji tego, jak bardzo enigmatyczne dla mnie są. I de facto ja… Nawet próbując dowiedzieć się coś na temat tych narzędzi, tych systemów, nie byłem w stanie znaleźć dla swojego konkretnego zastosowania. Ono nie jest jakieś szczególne, co IAST mógłby mi tak naprawdę dać więcej niż SAST, który mam w postaci scanusem grepowego. A koszty wdrożenia narzędzia klasy IAST w takiej firmie produktowej, w której ja pracuję, były po prostu olbrzymie. Wydaje mi się, bo nie wiem, bo nie robiłem tego praktycznie, że gdybym miał wdrożyć IASDA w firmie, z którą obecnie współpracuję, to byłaby to decyzja, która po prostu opiewałaby na… kilka, jak nie kilkanaście miesięcy wstrzymania pracy jednego zespołu, wyjęcia jednego zespołu, który po prostu razem ze mną implementowałby ten jazd w aplikacji, która ma być poddawana potem tym testom, a nie wiem, czy zwrot kosztów z inwestycji w moim kontekście by się po prostu opłacał.
Andrzej: Ja też nie wiem, choć się domyślam. IAST. Jeszcze dwa słowa do powiedzenia dla słuchaczy, którzy mogą nie kojarzyć, czym jest IAST. IAST to taki DAST, czyli Dynamic Application Security, Testing, analiza dynamiczna, ale na sterydach. Główna różnica jest taka, że IAST powinien być z definicji połączony w jakiś sposób z aplikacją, przez co jest z wewnętrznościami aplikacji, przez co jest w stanie obserwować od środka jej stan. przez co rozwiązujemy ten taki duży problem, który mamy w analizie dynamicznej, gdzie wysyłamy jakieś zapytanie i nie wiemy, czy aplikacja się wywróciła, czy nie. Możemy badać jej odpowiedzi, ale to, że się wywróciła aplikacja, to wcale nie oznacza, że nam zwrócił pięćsetkę, może zwrócić nam w dalszym ciągu dwusetkę. Mając jasta wdrożonego, widzielibyśmy w środku, że coś poszło nie tak, więc bylibyśmy w stanie… coś zrobić na podstawie tego. Dla zaawansowanych słuchaczy od razu rzuca się w oczy, że brzmi to jak fuzzing, taki z instrumentacją i jak najbardziej jest to po prostu fuzzing z instrumentacją w wydaniu dla web aplikacji. Więc nie jest to nic nowego pod kątem jakichś konceptów, podejść, rozwiązań niż to, co już widzieliśmy wcześniej w bezpieczeństwie, tylko jest to zaaplikowane do web aplikacji. I teraz problem, jaki ja widzę z iastami, to raz, że wdrażanie iastów jest kosztowne i nie chodzi mi o sam koszt narzędzia, tylko o koszt wdrożenia tego, no bo to spięcie kosztuje. Trzeba spiąć narzędzie z danym systemem i im więcej mamy systemów, im więcej mamy aplikacji, tym więcej musimy, tym więcej mamy wpinania. To raz. A dwa, wynik, jaki z tego wyciągamy, można poddawać pod wątpliwość. Ostatnio wróciłem na LinkedIn takiego posta, gdzie wyjąłem screenshota i tam osoba, która opisywała IAS, napisała, że IAS można znaleźć między innymi takie rzeczy jak… kluczyki zaszyfrowane, dodane w kodzie, że można znaleźć niebezpieczne połączenia SSL-TLS lub można pomóc znajdywać problemy z obsługą wejścia. I dla mnie to było takie wielkie xdddddddd, bo wszystko to da się rozwiązywać i powinno się rozwiązywać z SASTem czy DASTem. Więc od razu wróca się pytanie, to jaką wartość dodaną dodaje mi to konkretne narzędzie IAS? jeśli mam już wdrożonego sasta i dasta. Czyli nie to, czy coś mi da, bo dodawania różnych rzeczy, nie tylko do naszych projektów, ale w ogóle do życia, cokolwiek dodajemy, nie powinniśmy rozpatrywać tylko na poziomie tego, czy ja będę miał z tego jakiś plus, tylko jest kolejne pytanie, jak konkretnie ten plus wpisuje się we wszystkie inne plusy, które dostarczają mi inne rzeczy. I czy nie jest tak, że nie mogę tego zastąpić czymś innym? Być może nie będę miał tam jednej czy dwóch wpisów z tej listy tych plusów, które dostanę, ale overall się z tym pogodzę, bo okej, to dla mnie nie jest warte kosztu, jaki będę musiał ponieść z wdrożeniem jakiegoś procesu. I tutaj z IAS-em jest dokładnie ten problem. Nie jest tak, że IAS nie może znaleźć podatności, których SAST czy DAST nie byłby w stanie znaleźć. Może. Tylko pytanie nie jest, czy jest w stanie, tylko jak bardzo prawdopodobne jest, że znajdzie i ile tych podatności, na których mi zależy, czyli krytycznych, będzie znajdywał w cyklu tygodniowym, miesięcznym, kwartalnym, rocznym. I czy na koniec dnia koszt, który poniosę wdrożenia takiego narzędzia, będzie mniejszy niż to, co uda mi się na nim ugrać. I niestety, ale… Można powiedzieć tylko znowu, nie wiem, choć się domyślam, i z mojego praktycznego punktu widzenia i też znajomości tego, jak działa DAS, jak działa SAS, jak działa IAS, czyli z mojej eksperckiej perspektywy, IAS jest niewarty świeczki. Można oczywiście to skontrować i powiedzieć… A według mnie, Andrzej, to akurat ma sens. Dobrze, tylko że w takim wypadku ciężar dowodu leży na tobie, a nie na mnie. Jeśli chcesz coś dodać, jeśli chcesz mi coś sprzedać, to ciężar dowodu tego, że będzie to dla mnie wartościowe, leży na tobie, nie na mnie. To nie ja mam udowadniać, że coś mi się przyda, tylko ty, jako osoba, która twierdzi, że mi się to przyda, musisz udowodnić, jak konkretnie mi się to przyda. Jednym z takich podejść mogłoby być… Przykładowo, wzięcie kilku narzędzi vendorów sastowych, wzięcie kilku narzędzi vendorów dustowych i następnie wzięcie mojego narzędzia IAST, które produkuje jako vendor, albo chce sprzedawać i porównanie wyników. I porównanie wyników, wzięcie jakiejś ogólnodostępnej aplikacji, takie OASP, Jusco, spięcie jej i pokazaniu czarno na białym, czarno na białym, jaki konkretny uzysk dodaje mi IAST względem sasta czy dusta. Tylko dziwnym trafem Wendozy tego nie robią. Nie wiem, choć się domyślam, dlaczego nie. I tutaj już możemy przestać memować, bo wiemy, dlaczego tego nie robią. Nie robią tego dlatego, że na koniec dnia nie są w stanie udowodnić wartości tego, co chcą sprzedać. Więc muszą bazować na niewiedzy, na ignorancji, na jakichś zewnętrznych czynnikach, które obligują nas do pewnych rzeczy. a nie na tym, że dają nam realną wartość. Bo nie są w stanie udowodnić, bo gdyby byli i gdyby ta wartość naprawdę była krytyczna, to by się tym chwalili na lewo i prawo. Chwaliliby się tym na lewo i prawo, gdyby znajdowali, Bóg wie jakie problemy, których nie są w stanie znaleźć zastym czy zastym. Jeżeli się tym nie chwalą, to robią to dlatego, że wyszło im, oni te testy na pewno przeprowadzili, wyszło im, że w zasadzie to się nie opłaca robić. Ale skoro już poświęciliśmy te… trzy lata na dewelopowanie tego narzędzia i jazd, no to uruchomimy linię sprzedażową i będziemy spróbować sprzedawać ten nasz snake oil do różnych firm. I spoko, jeśli firma ma dużo pieniędzy, ma budżet na kupowanie zabawy, które się do niczego nie przydają, to można sobie kupić. To nie ma problemu. Ja nie chcę nikomu mówić, co ma robić ze swoimi pieniędzmi. Natomiast z mojego doświadczenia, a trochę już firm w Polsce widziałem, i od strony szkoleniowej, i od strony doradczej, doradztwa. Z mojego doświadczenia firmy, które działają w Polsce, nie są w pozycji, że mają wielkie budżety i mogą sobie wydawać i kupować zabawki, jakie chcą. Więc na naszym środowisku, na naszym poletku może jednak należałoby zainwestować te pieniądze w jakiś inny obszar. Przykładowo wyszkolenie swoich pracowników. Tutaj zapraszamy do… kursu ABCD w Sekops, tam pokażemy jak wdrażać Sabsta czy Dasta, ale o abstrahując z tym żartem, który akurat mi tutaj wpadł, to nie taki żart, ale taka zabawna wstawka. Natomiast wydać te pieniądze gdzieś, gdzie naprawdę będziemy mieć jakąś wartość dodaną, którą możemy zmierzyć i szkolenie ludzi jest taką wartością dodaną, która… Tutaj trudno zaprzeczyć. Im nasi ludzie więcej wiedzą, tym wszystko, co robią, będzie lepszej jakości. Więc lepiej te pieniądze spuścić w ten kawałek, niż kupować narzędzia, które są tylko po to, żeby tak naprawdę je sprzedać z perspektywy sprzedawcy. One w naszym obrazku nic nie zmienią. Natomiast jakaś firma, jakiś vendor na pewno będzie, na pewno się ucieszy, bo te narzędzia tanie nie są. To są narzędzia, które są należne do tych zdecydowanie najdroższych na rynku. Więc czy IAST zdecydowane nie w życiu bym nie polecał, nie rekomendował żadnej organizacji wdrażania IASTa? Jeśli ktoś coś takiego rekomenduje, to uważam, że jest to malpractice? I tak jak lekarz pewnych rzeczy nie powinien rekomendować, tak samo jak konsultant do spraw bezpieczeństwa w procesie wytwórczym nie powinien rekomendować jasna i nie widzę edge case’ów, gdzie miałoby to sens. Jedynym edge case’em, który jestem w stanie sobie wyobrazić, to mamy jakąś regulację, która nas zmusza, no ale to wtedy to nie jest rekomendacja, tylko musimy spełnić regulację, więc to nie jest… powinieneś to zrobić, bo tylko musisz to zrobić, bo cię tam regulacja do tego obieguje, więc jako rekomendacja nie widzę. uważam, że byłby to malpractice. Coś do dodania, Krzysiek, żeby zakończyć temat iastów?
Krzysztof: Tak, bo można sobie pomyśleć abstrakcyjnie o takiej sytuacji, w której mamy klienta, który wymaga na nas tego typu praktyk i jest on w stanie nam zapłacić, tak olbrzymią i bajońską sumę pieniędzy, że będzie nam się to spinało, więc biznesowo jak najbardziej okej, ale z punktu widzenia takiego praktycznego podejścia do tego, w jaki sposób podchodzi się do AppSecu czy ProSecu, to nie, totalnie nie.
Andrzej: Dokładnie tak. Jeśli ktoś nam sponsoruje, to spoko. Tutaj dodam, że może być tak, że… I to częściej jest przypadek w Polsce, gdzie jesteśmy częścią większej grupy międzynarodowej. Jeśli grupa nam zasponsoruje, grupa najczęściej operuje w dużych pieniądzach, ale w innych walutach. Jeśli grupa nam zasponsoruje, to spoko. Jeśli mamy czas na wdrożenie, jeśli kupią na to, to jasne. Ale to wtedy cel biznesowy jest inny niż wyłapywanie tych problemów. Jest inny cel biznesowy.
Krzysztof: Aczkolwiek chciałem powiedzieć, że jeżeli ktoś, kto nas słucha, ma inne zdanie i chciałby się nim podzielić, to zapraszamy, bo jesteśmy bardzo chętni na dyskusję w tym temacie, bo być może coś nam umyka w tym obrazie, czego nie wiemy, a chętnie się dowiemy. Także śmiało piszcie, jeżeli ktoś miałby taki case, którym chciałby się podzielić, gdzie jest w jego… praktycznym doświadczeniu znalazły zastosowanie.
Andrzej: Oczywiście, tutaj zawsze jesteśmy otwarci do dyskusji, szczególnie merytorycznej i jak najbardziej zawsze istnieje możliwość zmiany zdania. Tylko ta zmiana zdania raczej jest czymś, co następuje po jakichś dowodach, po argumentach. a nie tylko po takiej wolnej rozmowie, że a, to mi jas, nie, według mnie jest okej. Jak będą argumenty, może być tak dokładnie, jak powiedziałeś, że coś nam po prostu umyka. Jest jakieś spojrzenie, gdzie IAST jak najbardziej mógłby mieć sens. Nie możemy tego wykluczyć. Może też w cyfłości będzie miał większy sens. Na chwilę obecną Według mnie nie ma. We will see. No i bardzo chętnie usłyszymy opinie naszych słuchaczy, bo wiemy, że mamy równie słuchaczy w tym sensie, że i bezpieczników, i programistów, i inżynierów na wyższym poziomie, nawet na C-level od technology, więc generalnie mamy dość duży, szeroki przekrój słuchaczy. Krzysiek, dobra. Nie jestem pewien, czy już nam minęła godzinka, ale naprawdę zbliżamy się do godziny nagrania. Będziemy parkować to nagranie. Czy jest coś, co chciałbyś przekazać na sam koniec słuchaczom? Weź też pod uwagę, kiedy ten odcinek się ukaże.
Krzysztof: Tak, ja bym chciał wam… Co ja chciałem wam przekazać? Chciałem wam przekazać, że nadchodzą święta, jakkolwiek nie będziecie ich obchodzić, jakkolwiek je obchodzicie, obchodziliście, to chciałem wam życzyć spokojnego, zdrowego i wesołego czasu i bezpiecznego, hi hi, wszystkiego dobrego w nowym roku. i słyszymy się w styczniu, pewnie słyszymy się w styczniu, może usłyszymy się w lutym, może usłyszymy się szybciej, kto wie. My pozostajemy dostępni, macie nasze sociale, jesteśmy na Discordzie Bezpiecznego Kodu, do którego serdecznie zapraszamy. Link jest w opisie, więc tam będziecie mogli z nami podyskutować, jeżeli będziecie mieli okazję. Sekcja komentarzy jak zwykle również jest dostępna i obserwujcie nas. nas, bo w przyszłym roku nadchodzi dywersyfikacja kierunków tym, czym z wami się dzielimy, czyli naszą wiedzą. To już nie będzie tylko i wyłącznie podcast, a będzie również kilka innych mediów, również w innym języku, ale tutaj nie zdradzam tajemnic. I mediów, które na pewno będzie warto obserwować. Także jeszcze raz wesołych, spokojnych i zdrowych świąt.
Andrzej: Ode mnie trochę krócej, ale generalnie bardzo podobny mesedż. Zbliżają się święta, zbliża się nowy rok. Więc życzę wesołych świąt, szczęśliwego nowego roku. Mam jeszcze chwilę, ale tak będziecie to odsłuchiwać, to powinna być jeszcze chwila przed nowym rokiem. Usiądźcie, spiszcie sobie nowe cele. Ja coś takiego robię co roku na przyszły rok. Nie chodzi o to, żeby wszystko osiągnąć. Chodzi o to, żeby mieć jakiś kierunek. Spiszcie sobie nowe cele. My takie cele oczywiście też spisujemy w bezpiecznym kodzie. To, co Krzysiek powiedział, będą pewne nowe, większe, mniejsze inicjatywy w przyszłym roku. I co? Mam nadzieję, że ten rok był dla was rokiem udanym. Dla nas Krzysiek sądzę, że był udanym. Były plusy, były minusy. ale przynajmniej jeśli mówimy o tym obszarze, nazwijmy to kariery, to tutaj były w zasadzie przynajmniej z mojego punktu widzenia same plusy. Jest rok dodatni. I co? Życzę i sobie, i wam takiego roku dodatniego przyszłego. No i słyszymy się najpewniej w styczniu. lub najpóźniej w lutym, ale raczej usłyszymy się w styczniu. Dzięki za uwagę i do usłyszenia i złapania gdzieś w internetach, być może na naszym Discordzie, być może na LinkedInie czy jakichś innych kanałach.
Krzysztof: Trzymajcie się. Dokładnie. Trzymajcie się. Hej.