W najnowszym odcinku podcastu, Maciej Markiewicz, Krzysztof i Andrzej zagłębiają się w fascynujący świat cyberbezpieczeństwa, koncentrując się na różnicach w podejściu do bezpieczeństwa IT między firmami polskimi/europejskimi a amerykańskimi gigantami. Maciej dzieli się swoimi spostrzeżeniami z pracy w amerykańskiej firmie technologicznej, podkreślając, jak w USA bezpieczeństwo jest postrzegane jako kluczowa wartość biznesowa, a nie tylko koszt, co bezpośrednio przekłada się na strategie sprzedaży i zaufanie klientów. Poruszają również kwestię niskiej świadomości zagrożeń cyfrowych i poszukują innowacyjnych metod edukacji w zakresie bezpieczeństwa, co jest szczególnie istotne w dobie dynamicznego rozwoju sztucznej inteligencji i jej wpływu na krajobraz cyberzagrożeń. Podcast omawia również rolę compliance w cyberbezpieczeństwie, zastanawiając się, czy certyfikaty takie jak ISO czy SOC2 są jedynie formalnością, czy realnie wpływają na poziom bezpieczeństwa i przewagę konkurencyjną, szczególnie dla małych i średnich przedsiębiorstw dążących do wejścia na nowe rynki.

Kluczowe tematy poruszone w tym odcinku to:

• Podejście do cyberbezpieczeństwa jako wartości dodanej dla biznesu. W Stanach Zjednoczonych ten trend jest dużo bardziej zaawansowany niż w Polsce, gdzie bezpieczeństwo wciąż często postrzegane jest wyłącznie jako koszt. Firmy amerykańskie dostrzegają, że silne bezpieczeństwo może być czynnikiem wyróżniającym i generować realne pieniądze.
• Wykorzystanie sztucznej inteligencji do automatyzacji i optymalizacji procesów bezpieczeństwa, w tym w kontekście modelowania zagrożeń. AI może pomóc w redukcji czasochłonnych zadań, takich jak analiza dokumentów compliance, ale nie zastąpi w pełni pracy inżynierów. Ważne jest, aby LLM-y były traktowane jako narzędzia wspierające produktywność operatorów, którzy nadzorują i weryfikują ich pracę.
• Perspektywy zawodowe i zarobki w branży cyberbezpieczeństwa. Zarobki w tej dziedzinie są porównywalne z inżynierami DevOps, ponieważ obie role wymagają szerokiej wiedzy i doświadczenia w wielu obszarach IT. Wysokie zapotrzebowanie na specjalistów przy jednoczesnej ich małej liczbie na rynku pracy sprzyja atrakcyjnym wynagrodzeniom.

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

Transkrypcja

Krzysiek: Dobry, dobry wieczór. Witamy, witamy Macieja, witamy Andrzeja.

Maciej: Dobry, dobry wieczór.

Krzysiek: Cieszymy się, że nie macie co robić w ten ciepły dzień, prawda. U was też jest ciepło, panowie?

Andrzej: Ciepło, gorąco. Jestem cały spocony. Po plecach mi się leje. I tak to wygląda dzisiaj, ale jestem zadowolony, bo dawno już nie było tak ciepło, a ja jestem z tych, co lubią ciepełko, jak kotek. Mogę tak leżeć i się wygrzewać na balkonie.

Krzysiek: Ciepłolubny. No pokryliśmy chyba geograficznie praktycznie całą szerokość Polski. Był Andrzej Warszawa, Jaś Szczecin, Maciej Poznań. No i właśnie Macieju, z tym Poznaniem na starcie chciałbym Ci zadać pewne pytanie, bo Ty ostatnio brałeś udział w…

Maciej: Akademii się skończyły.

Krzysiek: Ty ostatnio brałeś udział w TEDx-ie, który był organizowany bodajże przez Politechnikę w Poznaniu, dobrze mówię? Jak byś mógł powiedzieć naszym słuchaczom, widzom, o czym mówiłeś, bo wiem, że był tam jakiś, było coś mówione o cyberbezpieczeństwie.

Maciej: Tak, i tutaj was zaskoczę, mówiłem o cyberbezpieczeństwie właśnie. A tak na poważnie, wiecie co, opowiadałem o czymś, co jest dla mnie takim osobistym przemyśleniem dotyczącym niskiej świadomości dotyczącej właśnie zagrożeń związanych z rozwojem technologii. Pewnie zauważyliście, że ostatnio jakiś AI wyskakuje tam z każdej lodówki i tak dalej. No i mam taką hipotezę, nazwałbym to, że nie nadążamy z rozwojem świadomości dotyczącej zagrożeń płynących z tych nowoczesnych technologii, które się bardzo szybko rozwijają. I trochę jako branża IT i branża cyberbezpieczeństwa też sami dokładamy cegiełkę do tego, że nie rozwiązujemy tego problemu dosyć skutecznie. Przez to jakby sami pewnie jesteście świadomi tego, że wiele incydentów, głośnych afer związanych z wyciekami danych zaczyna się właśnie od… błędów ludzkich. I to jest najczęstsza przyczyna i element wspólny i coś takiego, co generuje dużo problemów. Natomiast rozwiązania dotyczące tego problemu są dosyć, no, nazwałbym to mało efektywne, nie. Bo odpowiedzią na… na phishingi są szkolenia phishingowe. Być może mieliście przyjemność brać udział w takich szkoleniach. No nie jest to najciekawsze, co jest na świecie. A jak sobie to porównamy z tym, jak ciekawe są głupie filmiki na TikToku, Reelsach i innych miejscach, no to przegrywamy podwójnie. Więc jakby cała opowieść była o tym, żeby może, żebyśmy zaczęli się wszyscy zastanawiać, jak to zrobić, żeby się uczyć skuteczniej w nowoczesny sposób tego cyberbezpieczeństwa, no bo to nie jest już coś, co jest jakimś tam, wiecie, przysłowiowym klikaniem w komputer i jakąś tajną magią, tylko to już jest taka codzienność każdego człowieka, nie. Więc warto tutaj, przynajmniej moja taka, nazwijmy to, nie wiem jak to nazwać, marzenie, jest takie, żebyśmy trochę zaczęli myśleć o tym, w inny sposób.

Krzysiek: I o tym było.

Maciej: Była moja prelekcja.

Andrzej: Maciek, ja Krzysiek, to bym też się pochwalę, nie tylko tobie Maciek. Ostatnio byłem ofiarą. Nie, dlatego, że się nie złowiłem na ten phishing, ale pierwszy raz ktoś utylizował na mnie kampanię targetowaną.

Maciej: Czyli.

Andrzej: Więc tutaj jestem w trakcie gdzieś tam sobie spisywania notatki, ale na 100% to jest kampania targetowana i to jest konkretny phishing. Zobaczymy, co tam ciekawego jest. Jak robiłem sobie skan tych IOC, które tam są, to niestety, ale VirusTotal tego nie odkrywał, ale klasycznie, wiadomo. Pierwszy element, już pierwsza skucha wysłane z jakiegoś randomowego Gmaila, a podają się za kancelarię prawną, więc ktoś próbował mnie tutaj fishować, ale konkretnie stargetowany, bo cała wiadomość była skrojona pod… Podemnie. Były tam informacje dotyczące bezpiecznego callu i naszych działań, więc ktoś musiał zadać sobie trud, żeby to znaleźć i spisać.

Maciej: Chcieli cię sprowokować ewidentnie.

Andrzej: Chcieli chyba wyciągnąć moje dane do Gmaila, bo te linki przechodzą do czegoś.

Maciej: Jakiego triku użyli? Jakieś emocje, nie wiem, napisali co A4 lepsze niż Kia Stinger, czy?

Andrzej: Nie, nie, nie. Chuj lepsza, ale… Widzicie, jakie to emocje mnie wywołuje.

Maciej: Widzę, właśnie podskoczyłeś na to, Krzysiu.

Andrzej: Tak, ja tego słyszałem.

Krzysiek: Było Maciej, Maciej, tak. Mam twojego Stingera. Trening, żeby go odzyskać.

Andrzej: Nie. To, co było tam napisane, to było w takim dużym skrócie, że zestaw pewnych reklam na Facebooku łamie jakieś tam prawa autorskie. No i był link do tego, żeby zapoznać się z dowodami, które znaleźliśmy w sprawie, tylko że cały mail był wysłany, tak jak powiedziałem, z maila na Gmailu, jeszcze takiego fejkowego, nawet wiecie, nie, imię.nazwisko gmail, tylko jakaś nazwa totalnie wyciągnięta z czterech liter. A podawanie się za agencję jakąś tam prawną z Warszawy oczywiście. Myślę, że prawnik wysyłałby to z oficjalnego kanału. To raz, a dwa i tak można sobie wsadzić takie powiadomienie na mailu, bo trzeba byłoby… no, to takie rzeczy się wysyła poleconym, bo tylko to ma moc prawną, a nie mailem. No ale…

Maciej: Widziałem podobną kampanię na Facebooku, wysyłaną przez stronę na Facebooku, która wyglądała, podszywała się jak gdyby pod support Facebooka i wysyłała Ci w powiedzeniu coś, co wyglądało jak natywny, wbudowany element w, wiecie, w Facebooku, a była to tak naprawdę strona, która udawała i wysłała podobne powiadomienie, że Twoje strony, którymi zarządzasz, łamią tam jakiś regulamin, no i dalej już wiecie, więc bardzo podobny schemat.

Andrzej: Takie kampanie to cały czas lecą, więc jak ktoś ma pewnie, to pewnie zależy od aktywności, jak ktoś ma aktywne konto na Facebooku, puszcza reklamy, to to mu wlatuje cały czas i to mi w zasadzie już wyłapuje filtr spamowy, więc to nawet nie trafia do skrzynki, ale to od tych… prawników, to akurat trafiło, więc sobie przeczytałem i przeklikałem, zobaczyłem, co tam będą chcieli ode mnie wyciągnąć, no ale cóż, nie dałem się nabrać tym razem.

Krzysiek: Czekamy w takim razie, Andrzej, na twój write-up, na twoje podsumowanie tego wszystkiego i to, do czego doszedłeś, że złapiesz tego gagatka.

Andrzej: Może to ten, pan Jarek, pozdrawiamy. Jarek ma ciekawsze rzeczy do roboty. Projektowanie architektur mikroserwisowych, bo są bezpieczniejsze niż monolity. Tak czy siak. Maciej, tematem naszego odcinka jest jak się robi cyberbezpieczeństwo w wielkich korpos za oceanu. Powiedz nam coś o tym. Ja będę miał konkretne pytania do pewnych aspektów, ale tak najpierw możesz zarysować temat i nie chodzi mi o to, żebyś rzucał co jest lepsze, a co gorsze, chociaż troszeczkę możesz. Znasz… krajobraz nasz lokalny, nasz lokalny w Polsce. Powiedz mi, gdzie to cyberbezpieczeństwo stoi lepiej. Jednak za oceanem, czy u nas. Czy może jest podobnie i wcale takich dużych różnic nie ma. Może one są minimalne. Jak ty to widzisz. Bo trochę już w tym startupie, no nie startupie, w firmie siedzisz. Już trochę widziałeś.

Maciej: Tak, więc odpowiadając na twoje pytanie, jak się robi w USA w korpo, to nie wiem, bo jestem w Polsce i nie pracuję dla korpo. A tak serio o tym, żeby doprecyzować. Oczywiście, jak pewnie zauważyliście, lubię zacząć jakimś takim żarcikiem, ale żeby tak doprecyzować, to rozumiem, że tutaj pijecie do Ignite’a, w którym pracuję od półtora roku, o ile dobrze liczę, i różnic tak naprawdę pomiędzy wielkością firmy i tym, czy jest ona ze Stanów, czy z Polski jest bardzo wiele. Podejrzewam, że te różnice w kulturze organizacyjnej, w tym jak to wszystko jest zbudowane, będą się przejawiały na bardzo wielu poziomach. To jest myślę, że w miarę oczywista myśl. Jeżeli mielibyśmy tutaj mówić… jakie są różnice pomiędzy Polską a Stanami, to to jest moje subiektywne zdanie, ale mam wrażenie, że firmy działające w Polsce czy w Europie mają dużo, jeszcze nie mają takiej dojrzałości do zrozumienia zależności pomiędzy biznesem a bezpieczeństwem, że jednak w Stanach ten trend postrzegania cyberbezpieczeństwa jako wartość dodaną do biznesu, coś, co może generować i przekładać się na realne pieniądze czy oczekiwania klientów, jest dużo bardziej zaawansowany niż tutaj w Polsce. I to jest taka podstawowa różnica, którą bym zauważył. Jeżeli chodzi o Europę, ten trend dotarł, ale jeszcze… nie jest bardzo zaawansowany, głównie przyszedł on, nazwijmy to, z tą migracją firm ze Stanów, która się wydarzyła gdzieś tam po pandemii, te nowsze praktyki, czy nowszy sposób postrzegania cyberbezpieczeństwa się wraz z tym tutaj pojawił. Ale jeżeli chodzi o Europę, to widać, chociażby obserwując, nie wiem, oferty pracy, czy struktury tego, jak firmy działają, jakie rzeczy publikują, jak mówią o cyberbezpieczeństwie, to widać, że to postrzeganie jest troszeczkę inne. A jeżeli zejdziemy zupełnie na polskie podwórko, no to tutaj sytuacja znów zmienia się diametralnie. Inaczej jest oczywiście w większych firmach. Inaczej w mniejszych, inaczej tych, które znów przyszły tu ze Stanów i mają oddziały w Stanach, a inaczej w takich typowo lokalnych firmach, ale ta różnica przynajmniej z moich obserwacji wynika, że jest bardzo zauważalna. Więc to jest taki podstawowy element, który bym tutaj wyróżnił.

Andrzej: I rozumiem, tak bym wnioskował z tego, co powiedziałeś, że raczej na plus dla firm zachodnich, a na minus dla naszych. Tu oczywiście w kontekście po prostu wagi, jaka jest przypisywana cyberbezpieczeństwu. I z moich obserwacji też ja tutaj to podzielam. Już nawet nie chcę wchodzić jak bardzo, ale generalnie… To, co powiedziałeś, to mnie mocno tutaj ugodziło troszkę w serduszko, że u nas jednak się nie patrzy na cyberbezpieczeństwo jako wartość dodaną, u nas się patrzy na nie tylko jako koszt. I tutaj śmiem nawet postawić taką hipotezę, że akurat to w każdej organizacji, nieważne czy ona jest duża, czy ona jest mała, wyjątkiem są tylko te, które mają tak naprawdę realny management za oceanem. No ale wtedy to trudno mówić, że ta firma jest… polska. Jeśli ona tu ma po prostu hub inżynierów i to jest tylko jedna funkcja, która jest techniczna, no to nie jest firma polska. Ale jeśli mamy polskie całe branże z innymi oddziałami etc., to u nas na security patrzy się wyłącznie jako koszt, jeśli mówimy o biznesie, bo oczywiście ludzie z IT mogą mówić, że nie, cyberbezpieczeństwo jest też plusem, nie ma znaczenia, co mówimy sobie w IT i jako inżynierowie, znaczy nie ma tylko jak na to patrzy na koniec dnia biznes, bo to on wykłada na to kasę, a biznes patrzy na to u nas jako koszt, który musi po prostu ponieść i nie widzi za bardzo z tego realnego zwrotu, przynajmniej na chwilę jeszcze obecną. Może to się zmieni, ale na chwilę jeszcze tego nie widzę. Co chciałeś dodać, Maciek? Co byś dodał?

Maciej: No wiadomo, oczywiście operujemy tutaj na jakichś pewnych uogólnieniach, więc nie chcę, żeby to zabrzmiało tak, że to jest zupełnie zero-jedynkowe, nie. Bo to zależy od konkretnych sytuacji, konkretnych zespołów i ludzi, którzy pracują w tych zespołach. Ale też mam takie przemyślenie, że wiele zależy od tego też… Jak my jako bezpiecznicy mówimy o tym cyberbezpieczeństwie, bo możemy to przedstawiać i operować na strachu i to zawsze będzie sprowadzało się do kosztu, który jak się zmaterializuje, to będzie miał jakiś tutaj negatywny wpływ. I dojdziemy do tego punktu, o którym powiedziałeś, że znów… Znów cyberbezpieczeństwo jest tylko kosztem, natomiast możemy też sami troszeczkę wpływać i próbować przynajmniej modyfikować tę narrację i rozmawiać z biznesem, tłumaczyć ten inny punkt widzenia i pokazywać to, gdzie faktycznie możemy, nie wiem, zaoszczędzić, gdzie możemy wygenerować jakąś wartość, gdzie możemy marketingowo próbować sprzedawać pewne koncepty cyberbezpieczeństwa jako wyróżnik na tle innych firm. Tego mi brakuje, tego elementu, żeby ten trend, który się gdzieś tam, ja to nazywam oczywiście w uproszczeniu trendem, ale gdzieś te dobre praktyki się na tym opierały.

Krzysiek: No właśnie Maciej, bo powiedziałeś, że bezpieczeństwo w Stanach, przynajmniej tak zrozumiałem, może nie powiedziałeś tak, że bezpieczeństwo w Stanach, w firmie Stanów Zjednoczonych może wspierać w sprzedaży. Powiedz mi, jakie obszary widzisz, które obszary w bezpieczeństwie mogą być takim biznes enablerem, nie? Bo na przykład z mojej perspektywy, gdzie ja pracuję w relatywnie małym startupie, faktycznie dostrzegam na pewnych polach, że w szczególności w kontaktach z klientami ze Stanów Zjednoczonych to bezpieczeństwo sprzedaje. A jak to wygląda u Ciebie?

Maciej: Ja tu mam trochę taki bias, bo jeżeli chodzi o Ignite’a, my sprzedajemy rozwiązania do bezpiecznej wymiany plików poprzez chmurę i całą platformę do analizy tego, jak pliki w organizacjach są wymieniane i te narzędzia są targetowane dla wielkich korporacji, więc dla nich, z tego punktu widzenia, dla nich ten czynnik bezpieczeństwa, prywatności i tak dalej jest super ważny, więc jest o tyle łatwiej, że jest ten security jako biznes enabler jest częścią core’ową całego biznesu. Jest o tyle łatwiej budować całą narrację i dogadywać się, bo możesz bezpośrednio połączyć te rzeczy z tym, czego oczekują klienci, o co pytają, jakie są oczekiwania, jakie są trendy na rynku i gdzie to się może, gdzie to się wpisuje, taka strategia budowania bezpiecznych produktów i jak one się łączą ze sprzedażą wprost, więc tu mam trochę taki bias jakby z tego punktu widzenia, bo to oczywiście nigdy nie będzie… znów tak zero-jedynkowo działało, bo będziesz miał mniejsze firmy, które nie będą widziały w tym tak wprost, albo ciężko będzie połączyć sprzedaż innych jakby usług albo celowanych do użytkowników końcowych z tym bezpieczeństwem. Raczej będzie to o tyle trudne do sprzedaży, że będziesz, że użytkownikom końcowym, takim nazwijmy to zwykłych, przeciętnych użytkowników będzie interesowało to, że ich dane są bezpieczne. Co to znaczy? No to już jest… wszystko, nie. Tak, military-grade encryption. Zgadza się, to jest dokładnie to. No tutaj akurat podejrzewam, że wiem, do jakiego komunikatora możesz tutaj się odnosić, bo była taka jedna bardzo znana komunikator. I polskich, o ile dobrze pamiętam.

Andrzej: Polski, polski, oni mieli bardzo dużo wkładu, ale głównie na marketing.

Maciej: Ale to ciekawe. Bardzo dobrze udało im się łączyć elementy bezpieczeństwa z marketingiem, w sensie to był ich chyba główny core marketingowy, co mi się później trochę okazało, że nie do końca to military grade encryption, to tam jest, ale to już inna bajka.

Krzysiek: Mniejsza o to, uważam, że się sprzedało.

Andrzej: No, czy się sprzedało. Wiecie, ja bym do tego Military Grade jeszcze dołożył, jakby ta architektura była mikroserwisowa, bo wtedy jest bezpieczniejsza, bo jak macie kilka baz danych, to trudniej się włamać niż do jednej. I na przykład jak macie trzy, to w zasadzie trzy razy trudniej co najmniej się włamać do tych trzech baz niż do tej jednej.

Krzysiek: Jak macie trzy bazy, to twoja powierzchnia ataku jest trzy razy mniejsza niż jak masz jedną bazę, więc tak działa matematyka.

Andrzej: Easy, easy. Tak czy siak, pozdrawiamy pana Jarka, specjalistę, ekspertę od cyberbezpieczeństwa. Wracając do meritum. Maciek. I odnośnie tych firm lokalnych, bo ja się jeszcze jednej rzeczy jeszcze przyczepię, albo może nie przyczepię, tylko zrobię takie podwójne kliknięcie, double click. I ja chciałbym się dopytać, jak z twojego doświadczenia… wygląda taki mashup bezpieczeństwa w dwóch rodzajach firm. I tutaj nie wiem, czy będziesz znał odpowiedź, wydaje mi się, że trochę firm widziałeś w Polsce, działając szczególnie gdzieś tam w poprzedniej, w NetGuru. Jak wygląda, jak mogłoby wyglądać podejście do bezpieczeństwa i przekładanie bezpieczeństwa właśnie na sprzedaż feature’ów w firmach większych, takich powiedzmy dużych, i versus firmy małej. Teraz to, co mam na myśli, to taka rozkminka, która ostatnio mi wpadła do głowy, że w zasadzie ci duzi gracze najczęściej grają w bezpieczeństwo w takim wydaniu compliance driven. Oni robią bezpieczeństwo, bo muszą być z czymś wyrównani. A z kolei to ci mali gracze najczęściej potrzebują bezpieczeństwa jako… value proposition do sprzedaży. I to szczególnie gracze, którzy sprzedają do B2B, do jakichś enterprise’ów, a nie do klientów B2C. No i oni wtedy mają to jako value proposition, no bo mówią, że dbamy o bezpieczeństwo, mamy tam ISO czy tam SOC2 i dzięki temu wy jako enterprise możecie od nas kupić. Natomiast nie widzę tej odwrotności, że ci mali za bardzo nie będą się tak… a przez to też grają w bezpieczeństwo z compliancem, ale compliance tam jest tylko takim dodatkiem po to, żeby coś sprzedać. Natomiast u tych dużych ten compliance nie jest o tyle, żeby coś sprzedać, tylko dlatego, żeby raczej uniknąć ewentualnych problemów z byciem niewyrównanym, ale i w jednym i w drugim tak naprawdę ten compliance odgrywa dużą rolę. I teraz czy się ze mną zgadzasz, czy nie, czy może jeszcze faktycznie jest jakaś dodatkowa, nie wiem, wartość, która tam wchodzi. Bo ten compliance, on mi nie chce wyjść z głowy, bo jak tylko to zobaczyłem, to teraz nie jest… W zasadzie wszędzie chodzi tylko compliance, tylko nazwijmy to z takiej innej strony patrzenie na sam compliance.

Maciej: I tak, i nie. W sensie to odpowiedź na twoje pytanie, czy się z tym zgadzam. Generalnie… Zależy to od tego, z jaką firmą masz do czynienia. Powiedziałbym, że jeżeli weźmiesz pod uwagę compliance i małą firmę, to im stosunkowo łatwiej jest zdobyć ten compliance niż certyfikując procesy w dużym przedsiębiorstwie. I to jest dla nich akurat bardzo łatwy taki… value proposition, jak to ładnie nazwałeś, że jeżeli zdobędą jakieś tam, nie wiem, ISO czy coś takiego, mała firma, mały startup, to im się otwierają drzwi do kolejnego sektora, do kolejnej branży i tak dalej, bo oni przychodzą, już nie przegrywają z tymi trochę większymi, które chcą podkopać, bo są na tym samym poziomie. Ten compliance, takie standardy, czy SOC2, czy ISO, one wyrównują jakby, wiesz, z punktu widzenia wielkiej korporacji, której chcesz sprzedać usługę. Ta firma i ta mają ten sam standard, więc są tak samo zgodni, jakby trafiasz na ich listę kontraktorów i możesz z nimi negocjować, możesz wejść w deal. I to jest stosunkowo łatwe do zdobycia, im mniejsza firma, tym łatwiejsza jest to do zdobycia, bo złożoność procesów w takich firmach… jest bardzo mała i łatwiej jest zmieniać, nagiąć, nagiąć. Może to jest złe słowo, bo ja nie chcę, żeby to negatywnie brzmiało, ale dostosować albo proces do compliance, albo interpretację regulacji compliance’owych do tego, jak ty to przetwarzasz u siebie. Dużo łatwiej jest to poukładać i tak bym na to patrzył. Z kolei w dużych firmach ten compliance jest jakby must have’em i musisz go zrobić, jeżeli chcesz współpracować z innymi. Jak już przejdziesz przez jedną compliance’ową regulację i zdobędziesz ten certyfikat, to łatwiej jest Ci zdobyć kolejny, dostosować, bo już masz podbudowę. W gruncie rzeczy wiele z tych standardów regulacji bazuje na tych samych standardach NIST-owych. Więc tak naprawdę dostosowanie tych procesów, jeżeli masz je gotowe na to, jest stosunkowo łatwe, ale musimy też wiedzieć, że wiąże się z dużo większym kosztem niż w takim przypadku małych firm. Więc powiedziałbym, że to jest bardzo zależne od tego, co chcesz osiągnąć i uważałbym, że ten compliance stał się trochę takim osobnym produktem cyberbezpieczeństwa, że możesz sobie kupić, upraszczając trochę to, masz przepustkę do kolejnego rynku i do innego typu klientów i na tym zwyczajnie zarabiać. Czy to się przekłada faktycznie na bezpieczeństwo? No to już zależy od tego, co się dzieje w środku. Bardzo często niekoniecznie, tak bym to powiedział, zależy to od tego, czy kupujesz, czy robisz ten compliance jako firma po to, żeby mieć klientów, czy chcesz faktycznie zabezpieczyć te procesy. Bo to, czy to zrobisz efektywnie, czy zrobisz to tylko po to, żeby odhaczyć checkboxy, to jest inna sprawa. Więc ja jestem zwolennikiem takiego podejścia, że jeżeli budujesz security i bezpieczeństwo w danej organizacji, to buduj je niezależnie od tego, co compliance od Ciebie oczekuje. On powinien być taką wskazówką, ale compliance jest jakby osobną gałęzią, która służy do czegoś innego. Ty możesz jedynie dostosować swoją strategię, dostosować kontrolki do tego, co jest standardem na rynku. Niekoniecznie robić to tylko, żeby za wszelką cenę dostosować się do tych standardów, bo one są często przestarzałe i nie uwzględniają wielu czynników, jak chociażby CI/CD, czy to, że możesz nie wiedzieć… jaką masz gaśnicę w swojej serwerowni, w piwnicy, nie.

Andrzej: Tak jak tutaj.

Maciej: No i czy wyłapałeś ten subtelny follow-up, Krzysiek?

Krzysiek: Tak. Maciej, gdybym ja wiedział to wszystko, o czym teraz mówisz, to moje życie byłoby dużo łatwiejsze, zwłaszcza, że jestem w trakcie SOC2 drugiego Type 2 i… Naprawdę, faktycznie. Gdybyśmy zaczęli te pięć lat wcześniej, to może nasze życie w Tidio byłoby dużo, dużo prostsze.

Maciej: Zgadza się, ale tu wchodzi jeszcze jedna taka powierzchnia, jeżeli o to chodzi, że najczęściej takie małe firmy nie mają dużego budżetu, żeby kupić bezpieczeństwo i dostosować, więc one chcą minimalizować koszty, więc dużo łatwiej jest im powiedzieć, ok, zróbmy tylko te najbardziej bazowe rzeczy SOC2, ISO, zaimplementujmy sobie te procesy i jedziemy, a potem jakoś to będzie, no bo jeżeli chcemy to zrobić tak jak należy, czyli zacząć od budowania bezpiecznych procesów, produktów, hardeningu całej naszej infrastruktury, no to to wymaga dużych kosztów. I ten punkt w czasie, w którym ty będziesz spełniał wymogi, bo najpierw sobie zbudujesz to bezpieczeństwo, jest dużo dalej, nie. I dużo bardziej kosztowne to jest. Natomiast te niektóre jakby firmy we wczesnych fazach, takich jak to tutaj już padło, startupowych, bardzo często im zależy na tym, żeby być szybko konkurencyjnymi na rynku. I na to idzie główny effort. Takie rzeczy jak cyberbezpieczeństwo spychane jest, jest suwane na dalszy plan i nawet jeżeli oni mają chęci, żeby to robić, to bardzo często w toku projektu, kiedy nawet zaakceptowaliśmy koszty związane z hardeningiem, czegoś z implementacją funkcji związanych z cyberbezpieczeństwem w twoim nowym startupie SaaSowym, pada decyzja, ok, musimy zoptymalizować koszty, bo te trzy feature’y teraz AI-a muszą przejść na wyższy priorytet. No i taki startup podejmuje trudną decyzję, że musi zrezygnować z czegoś. No i najłatwiej zrezygnować z cyberbezpieczeństwa, które jest gdzieś tam doklejone, jest kosztem i nie… nie ma tego bezpośredniego połączenia między tym a pieniędzmi, więc jeżeli znów wracałem sobie do twojego, Andrzej, poprzedniego pytania, jeżeli szukamy gdzieś tutaj analogii, no to ten czynnik, że masz z jednej strony dużą organizację średniej wielkości czy dużej wielkości jakichś korporacji, jakby przekłada się na to, że masz dużo stabilniejszy model finansowania, masz już… budżety, możesz tymi budżetami jakoś zarządzać. W startupach bardzo często jest to albo mały budżet, albo brak budżetu i trzeba tak naprawdę kombinować. I niestety, pracując przez lata w firmie usługowej, która budowała tak naprawdę startupy dla klientów zewnętrznych, widziałem ten schemat powtarzający się wielokrotnie, że dokładnie tak to działa, że masz bardzo ograniczony budżet, musi być szybki time to market i to jest najważniejszy czynnik. A to, czy ty później spełnisz te wymagania, czy nie spełnisz, co z tego, że będziesz spełniał wymagania HIPAA, bo budujesz startup na danych medycznych w Stanach Zjednoczonych, jak nie wiadomo, czy ten startup będzie miał jakichkolwiek klientów. Na razie to jest ty, twoja żona, trzech kuzynów i brat żony. To na tym niestety nie zarobisz, mimo najszerszych chęci. Bardzo często mnie to frustrowało jako bezpiecznika, że oni okej nie rozumieją, ale w pewnym momencie uświadomiłem sobie, że no… niestety, ale to się wiąże z kosztami, czy chcemy, czy nie. Nawet jak będziemy się bardzo starać, żeby zapakować cyberbezpieczeństwo w biznes value, to dalej te koszty muszą być poniesione. To nie jest coś, co odkleimy. Więc trzeba być sprytnym.

Andrzej: Tak, ja bym tutaj lekko odwrócił kota ogonem po już tych swoich kilku latach prowadzenia biznesu. Powiedziałbym, że to właśnie ta druga strona świetnie rozumie biznes i doskonale zdaje sobie sprawę, że żeby zarobić na tych wszystkich bezpieczników i na to, żeby było bezpiecznie, no to najpierw trzeba mieć klientów i robić hajs, a dopiero potem można myśleć o tym, żeby to było robione w sposób bezpieczny i według sztuki, bo zaczynając od myślenia, żeby to było bezpieczne, no nie mając klientów, dość szybko przestaniemy cokolwiek robić, żeby się szukać nowej pracy. Niestety, ale tak wygląda szara rzeczywistość, ale Maciek, bo ja mam jeszcze tutaj dodatkowe pytanie, chcę jeszcze zrobić mały double click, ale do innej kwestii, mianowicie, jeśli już mamy robić to bezpieczeństwo, to kim, kim mamy je robić. Kim mam je robić, bo bezpieczników to tak w sumie… ajaj. No i nic.

Krzysiek: Ajajaj.

Maciej: Słyszałem, że AI zabiera tam pracę.

Krzysiek: No to dobra, no to ile masz serwerów MCP zainstalowanych? Powiedz.

Maciej: Nie wiem, to już nie liczę, bo to się skaluje.

Andrzej: Maciek nie ma żadnych, bo Maciek jest menadżerem, on ma ludzi od tego. Maciek tylko czyta te raporty, a potem w piątek pisze zbiorcze do swojego menadżera.

Maciej: Czy możesz powtórzyć pytanie?

Andrzej: Jasne, jasne. Kim robić to bezpieczeństwo? I ja teraz piję do tego takiego problemu, który mamy w cyberbezpieczeństwie, że bezpieczników zawsze jest mało i jeśli mamy organizację, nawet w zasadzie dość taką… średnich rozmiarów na poziomie światowym, dajmy na to dużo na polski poziom, czyli tam nie wiem, ponad 50 osób, czy te 100 osób, no to bezpieczników zawsze będzie mało, a rzeczy do zabezpieczania jest całkiem dużo. To kim robić to bezpieczeństwo? Jak można ten problem rozwiązywać?

Maciej: To znów pewnie skomplikowane pytanie i zależne od tego, jakimi, nazwijmy to brzydko, zasobami dysponuje organizacja, w której się znajdujesz, nie.

Andrzej: Chodzi ci o ludzi?

Maciej: Tylko głównie o pieniądze, bo to i tak potem się przekłada na… pieniądze de facto, więc jeżeli masz pieniądze, no to masz tą wygodę i tą umiejętność, że możesz próbować pozyskać ludzi z rynku i to jest dosyć komfortowa sytuacja, mimo że tych ludzi jest bardzo mało, ale przynajmniej jesteś już w punkcie, w którym możesz ich pozyskać. Gorsza sytuacja jest wtedy, kiedy nie masz pieniędzy albo firma nie ma… nie ma, nie rozumie do końca tego, że potrzebuje ludzi do cyberbezpieczeństwa, to jest powiedziałbym mniej komfortowa sytuacja. No i skąd brać tych ludzi? No trzeba ich albo zatrudniać, albo wyszkolić, bo innej drogi bym powiedział, że nie ma, nie. I trochę tu zażartowałem z tym AI-em, żeby zastąpił nam pracę, ale w sytuacji, w której faktycznie talentu na rynku jest mało i ciężko go zdobyć, a potem jak już go masz, to ciężko jest wyszkolić, to wspomaganie się w optymalizacji niektórych obszarów jest super kluczowe w automatyzowaniu rzeczy, w automatyzowaniu i optymalizacji wszelkich procesów, które pomagają Ci zwiększyć efektywność jakby w całej organizacji, nie tylko w cyberbezpieczeństwie, jest na wagę złota. I osobiście uważam, że do tego celu AI całkiem dobrze się nada, jeżeli chodzi o to, jak zoptymalizować procesy, które zjadają czas, a może niekoniecznie generują wartość. Masz jednego bezpiecznika w firmie i on ma czytać, nie wiem, tony dokumentów compliance’owych, żeby coś z nich wyciągnąć, dwa konkretne zdania. Może niech AI ci przeczyta te dokumenty i zrobi podsumowanie. To są drobne rzeczy, ale jeżeli faktycznie masz mało, mało ludzi i nie masz jak ich pozyskać więcej i zrobić tego w ten sposób, to automatyzacja i wykorzystanie takich narzędzi jak AI, nawet biorąc pod uwagę to, że one nie są super skuteczne, super precyzyjne, to dalej zrobią część pracy, która uwolni czas innych osób, które spędziłyby dokładnie na to samo, więc pytanie jest takie, czy ten kierunek nie jest tym rozwiązaniem, które częściowo przynajmniej będzie ten problem adresować w takich realnych warunkach, i to jest coś, z czego powinniśmy korzystać dużo bardziej niż wiele firm robi to w rzeczywistości.

Krzysiek: Myślisz, Macieju, że będziemy w stanie zautomatyzować bezpieczeństwo w dużym stopniu korzystając z generatywnej sztucznej inteligencji?

Maciej: Nie. Nie. Jakby osobiście uważam, że nie, ale dalej możesz automatyzować części jakby procesów, które to robią, nie. To nie chodzi o to, że masz wstawić AI i powiedzieć, dobra, teraz zrób pentest, wypluj raport i wygeneruj tikety, bo to się nie wydarzy, zalejesz twoich deweloperów setką mało sensownych rzeczy, które nie mają żadnego… pokrycia w rzeczywistości, mają pełno błędów i nie wnoszą nic, zbudujesz tylko frustrację i tak dalej. W ten sposób tego nie zrobisz, a to by był tak, to jest bardzo często coś, co widzę, przejawia się, nie wiem, w postach na LinkedIn, że okej, teraz zastąpimy iluś inżynierów AI-em. Tak to nie zadziała, ale to, co zadziała i można spróbować robić to, to wydzielać trudne, czasochłonne części procesów, automatyzować to w sposób taki nazwijmy to tradycyjny, bez użycia LLM-ów, a tam gdzie, nie wiem, możesz przeprowadzić jakąś analizę i wygenerować jakieś podsumowanie, prosty przykład, tam LLM całkiem dobrze się sprawdzi. Znów na końcu trafi to na biurko inżyniera czy bezpiecznika, który musi zrobić ten check i sprawdzić, czy to ma sens i ręce i nogi, ale… Czas, który zaoszczędzisz w ten sposób już jest wartością dodaną dla twojego zespołu, uwolnioną. Możesz czasem robić coś innego, a ograniczyć się tylko do tego, co i tak byś robił sam, czyli double check, weryfikacja tego, co samemu zrobiłeś podczas researchu. Możemy zoptymalizować części procesów, jeżeli chodzi o całe bezpieczeństwo, no nie do końca. Wydaje mi się, że to się w najbliższej przynajmniej w przyszłości wydarzy.

Andrzej: Ja bym tutaj dodał może nie tyle uwagę, ale doprecyzowanie, czyli twierdzisz, o ile dobrze zrozumiałem, że automatyzacja i wspomaganie się LLM-ami jak najbardziej tak, ale w wydaniu sprawnego operatora, czyli musimy mieć sprawnych operatorów, ci operatorzy mogą nabyć tą sprawność. I to oni będą tutaj wnosili realną wartość, automatyzując pewne kawałki różnych procesów, które zajmują dużo czasu, a można je w jakiś sposób automatyzować. Czy w taki klasyczny, czy w wydaniu LLM-owym.

Maciej: Tu musielibyśmy się zastanowić, co ty rozumiesz przez operatorów, ale generalnie… Człowieka. Przez człowieka. Tak, no generalnie tak bym to… tak bym to ujął. Ja postrzegam narzędzia LLM-y i Gen-AI wszelkiego rodzaju jako narzędzie, które daje wsparcie do produktywności i w tym się całkiem dobrze realizują. Jakby prosty przykład, jeżeli miałbyś pisać opis jakiegoś, nie wiem… Załóżmy, że jesteś pentesterem, znajdujesz podatność i musisz przygotować na bazie tej podatności, którą zidentyfikowałeś, sensowny opis dla kogoś, kto tej podatności nie rozumie. To jakby zrobienie tej translacji z tego, co ty rozumiesz na ten temat, do tego, co ma zrozumieć odbiorca, nie jest wcale taką trywialną rzeczą, a efektywność tej komunikacji jest bardzo istotna do… punktem do tego, żeby ktoś to efektywnie rozwiązał. Więc możesz tutaj ten proces sobie zautomatyzować i wygenerować draft na podstawie wcześniejszych scenariuszy takiej komunikacji, którą wiesz, że już jest efektywna i potem tylko sprawdzić i dodać drobne poprawki. Oczywiście to jest proste zadanie, które oszczędzasz, załóżmy, nie wiem, 10-15 minut pracy. Ale jeżeli je robisz, to często jest to powtarzalny proces, to tak jak w przypadku każdej automatyzacji, skala robi tutaj duże znaczenie. Zwłaszcza jak masz jednego czy dwóch pentesterów czy inżynierów bezpieczeństwa, którzy zaraz muszą przeskoczyć na inny wątek i dla nich każde 15 minut jest istotne.

Andrzej: Exacto. Pełna zgoda.

Krzysiek: Dokładnie. Ja do tego, co Maciej powiedziałeś, dodam od siebie, że rozumiem i nie rozumiem całą masę ludzi, która teraz wyszła i próbuje troszeczkę na siłę zaprzęgnąć AI w bezpieczeństwie tam, gdzie jeszcze chyba sobie nie radzi całkiem dobrze. Podam przykład na przykład modelowanie zagrożeń. Fajnie, że… te modele są w stanie nam coś wypluć, ale jak bardzo się nie starałem w moich POC, jak bardziej nadawałem kontekst, to te modele były takie sztuczne, były takie plastikowe, były takie, że wstyd byłoby mi je pokazać komukolwiek i wyniki, które były wypluwane przez te modele zagrożeń aplikować na przykład jako, wiecie, rzeczy, które powinny zostać wzięte pod uwagę podczas developmentu.

Andrzej: Tutaj świetnie, że zahaczasz o modelowanie zagrożeń, bo dla mnie to jest ludzie, którzy tutaj proponują używanie LLM-ów do modelowania zagrożeń, nie rozumieją fundamentalnie celu tego procesu. Celem procesu modelowania zagrożeń i to, żeby to się działo w procesie wytwórczym jest to, żeby ludzie, którzy pracują nad systemami, uczyli się pewnych fundamentów bezpieczeństwa i niejako wbudowywali w swój warsztat myślenie o bezpieczeństwie, co się z czasem stanie, jeśli będą takie sesje przeprowadzać. Dokładnie tak samo jak z innymi elementami architektury, takimi jak DDD czy event stormingowymi. To nie chodzi o to, co mi wyjdzie, tylko to, co ja się nauczę. I mówię to dlatego, że gdyby celem było zrobienie samego modelu zagrożeń, to mógłbym po prostu wziąć bezpieczników, oni by mi takie modele mogli zrobić dla wszystkich funkcjonalności, które są w aplikacjach, a przecież aplikacje nie mają nieskończonego zbioru funkcjonalności i po prostu bym to miał. I tyle. I bym sobie wybierał na check-liście te funkcjonalności, z których korzystam, by mi wypluło zagrożenia i tyle. Zrobione.

Maciej: Ale tutaj bym powiedział tak, no jakby Krzysiek, ty jakby wiesz, co chcesz osiągnąć, więc wiesz, jaki twój jest cel, masz doświadczenie i robiłeś takie rzeczy i jesteś w stanie ocenić to, co zostało wygenerowane jako powiedzmy słabej jakości, nie. Ale załóżmy sobie taki przykład, że masz bardzo małą firmę i masz tam… nie wiem, przykładowo QA inżyniera, który nie ma dlatego pojęcia, jak robić modelowanie zagrożeń, usłyszał tylko na LinkedInie Andrzeja, jak opowiadał, że trzeba robić modelowanie zagrożeń i ten człowiek ma do dyspozycji LLM-a. I on nie wie, od czego zacząć, wie tylko tyle, że musisz robić modelowanie zagrożeń. Znowu, w tym kontekście, nawet jeżeli LLM mu wygeneruje kontekst, który jest słabej jakości, to dalej jest to już do niego wartość dodana, bo startuje z zupełnie innego punktu i do innego punktu jak gdyby zmierza. Więc też bym nie podchodził do tego tak zero-jedynkowo, że to zawsze będzie… przekreślony przypadek.

Andrzej: Tak, nie, nie, nie. Maciek, trzeba zrobić krok w tył i mówisz o wykorzystaniu LLM-ów niejako podczas sesji modelowania zagrożeń, jako pomoc… o zagrożeniach, co jak najbardziej jest dopuszczalne. Tym bardziej, jeśli zespół na przykład startuje z samym procesem modelowania zagrożeń, albo tak jak w twoim przypadku, jest to pojedyncza osoba, która nie jest w tym niedoświadczona. Natomiast przypadek, o którym ja mówię, który jest szerszy i on raczej dotyczy bezpieczników, to ludzi, którzy dużo mówią o modelowaniu zagrożeń, a potem robią jump do wniosku, że w zasadzie to ja mogę wykorzystać LLM-y do zbudowania modeli zagrożeń, więc w zasadzie to ja jestem w stanie zautomatyzować cały proces, więc w zasadzie to ja jestem w stanie w ogóle pominąć sesję modelowania zagrożeń, bo ja sobie je wygeneruję LLM-ami. Jedyne co będę potrzebował, to będę potrzebował opis systemu, który przyjdzie mi tam od architektów, przepuszczę przez swoją magiczną skrzynkę, będę miał model zagrożeń, który rzucę programistom. Czyli wiecie, tak jakby dokładnie te same błędy, które były powtarzane w analizie statycznej, czyli o, no to ja wystarczy, że ja sobie sam poszukam patternów, a potem wyrzucę programistom raport z analizy statycznej. A jak już wiemy, wartość z analizy statycznej płynie wtedy, kiedy inżynierowie piszący korzystają z tego narzędzia, a nie kiedy ja im rzucę raport. I tak samo jest tutaj. Więc jak najbardziej ten potok pracy, o którym ty mówisz Macieju, jak najbardziej jest na propsie, tak. Jak najbardziej można używać LLM-ów do nauki procesu etc., ale dalej ten proces musi się dziać. Natomiast stanowcze nie mówieniu o automatyzacji tworzenia modeli zagrożeń z wykorzystaniem LLM-ów, chyba że cel jest cel jest jasny i celem jest wyrównanie się z compliancem i musimy mieć model zagrożeń. To wtedy okej.

Maciej: W sensie nie zgodzę się tutaj do końca z tym, bo oczywiście w idealnym takim modelowym teoretycznej sytuacji powinno być dokładnie tak jak mówisz, że jakby celem modelowania zagrożeń jest to, żeby inżynierowie, architekci, którzy pracują nad tym, przygotowują modele zagrożeń i przechodzą cały ten proces myślowy i to ćwiczenie. To modelowanie zagrożeń tak naprawdę mogłoby się równie dobrze nie dziać na żaden formalnie w odzalany sposób, bo najważniejsze jest outcome, że te wymagania bezpieczeństwa trafiają potem do całego procesu. Ale jeżeli znów nie masz zupełnie modelowania zagrożeń, nie jesteś w stanie tego zrobić, bo nie masz ludzi, nie jesteś w stanie przygotować tych inżynierów do tego, żeby oni ten proces przechodzili, nie jesteś w stanie ich nauczyć bardzo szybko, a pracujesz na ogromnej skali w wielkiej korporacji, w której te procesy się dzieją i nie ma w ogóle tego elementu i nie masz zasobów, żeby to wdrożyć, to znowu ja widzę wartość w tym, że zrobisz taki automat i nawet jeżeli on nie będzie generował dużej wartości jakby super wartości zoptymalizowane i tak dalej, to dalej jest on takim punktem, który wrzucasz jako coś, na co musi spojrzeć inżynier i rozpocząć cały ten proces myślowy. I ty mając na przykład jednego inżyniera versus, nie wiem, pięćset, jednego inżyniera bezpieczeństwa versus pięćset deweloperów, załóżmy, czy tysiąc i nie wiem… 20-50 projektów, możesz w stanie zintegrować się z ich procesem, w zautomatyzowany sposób do ticketów dorzucać im kolejny step, czy listę, modele zagrożeń, checkboxy, cokolwiek i centralnie zażądać tym, żeby wymusić na nich ten sposób myślenia, o którym ty mówisz. Jest to w pewien sposób… obejście tego systemu, że masz małe zasoby, a musisz operować w skali, ja bym znów nie podchodził tak bardzo sceptycznie, że to nie ma totalnie sensu i trzeba to wyrzucić, bo operowanie w skali ma dużo inne rzeczy i muszą być optymalizacje, które muszą być robione, muszą być robione pod założeniem, że masz tak zwane lokalne suboptimal i musisz się godzić z tym, że generujesz… trend modele, które może nie są najlepszej jakości, najbardziej odwzorowane. Oczywiście to znowu jest taki jakiś hipotetyczny przykład i wszystko zależy od tego, do jakiej kultury organizacyjnej się projektujesz te rozwiązania, ale znów nie podchodziłbym do tego tak zero-jedynkowo, że to zupełnie nie ma sensu.

Andrzej: Znaczy to może mieć sens i compliance’owy, żeby po prostu mieć praktykę. Ja już rzucę ten wątek, ale tylko dopowiem, że to wtedy działałoby dokładnie tak jak analiza statyczna w wydaniu rzucania raportów. Te modele będą się działy, ale jeśli organizacja nie może zainwestować w zaimplementowanie tego procesu tak, jak powinien wyglądać i to samo się aplikuje do analizy statycznej, to realnie ten proces nie będzie działał, no bo trudno oczekiwać od osoby, która nie ma doświadczenia w myśleniu jak atakujący, żeby potem brała pod uwagę ten threat model, dokładnie tak samo jak trudno oczekiwać od programisty wyprowadzania problemów znalezionych w analizie statycznej w momencie, gdy nie dostaje tego feedbacku w IDE, czy w innym kawałku, który jest blisko jego pracy. I można sobie powiedzieć, że o, powinien to zrobić, ale niestety wszystkie papierki, które badały takie działanie, pokazywały, że niestety to się wtedy nie dzieje. I my już doszliśmy w analizie statycznej, że trzeba być blisko dewelopera i to samo będzie z modelowaniem zagrożeń, bo to jest identyczny proces, to jest identyczny problem, identyczny.

Maciej: Jakby dalej mnie nie przekonaliście, bo dalej możesz zrobić dokładnie to, co Pan Alicja.

Andrzej: Krzysiek chce nam przerwać.

Krzysiek: Nie, po prostu wpadł mi zajebisty pomysł na biznes, bo Maciej mówi, że można, Andrzej mówi, że nie można, a co jakbyśmy stworzyli taką wtyczkę do Jiry. Masz taska, klikasz generate threat model i na dole od razu wszystko ci na podstawie tego kontekstu z taska i twojego codebase’u generuje.

Maciej: Kontekst taska akurat może być za mały kontekst.

Krzysiek: Dobra, no to epika całego.

Maciej: W sensie osobiście dalej, żeby może domknąć ten temat, dalej mnie to nie przekonuje, że to nie jest idealne rozwiązanie, bo dalej operując na bardzo małych zasobach i dużej skali, możesz wygenerować dla deweloperów takie warunki, że dostarczasz im kontekst, którego oni w ogóle mogą nie wynieść do taska.

Andrzej: To powiedz mi, jakbyś to potem mierzył, skuteczność tego suboptimum lokalnego.

Maciej: Słuchaj, to zależy jak zamodelujesz proces, jakie masz założenia do tego. Jeżeli masz, jeżeli załóżmy generujesz…

Andrzej: I tu jeszcze dopowiem, że to możesz potem rozciągnąć i powiedzieć w ogóle jak mierzyć takie procesy z bezpieczeństwem, bo to akurat jest wartościowe dla każdego, ale możesz najpierw powiedzieć na konkretnym przykładzie tego.

Maciej: No jakby będzie to wymagało oczywiście mierzenia tego i… jak każdy proces powinien być audytowalny, więc musi on być zaimplementowany w taki sposób, żeby był audytowalny, więc jeżeli zrobimy to w taki sposób, ok, LLM generuje komuś jakiś threat model i nic więcej się z tym nie dzieje, no to to doprowadzi do tej sytuacji, o której Andrzej mówił moim zdaniem, bo nie będziemy w stanie sprawdzić jakiejkolwiek efektywności. Jeżeli ty… mając znów małe zasoby, będziesz w stanie przynajmniej punktowo audytować efektywność tego, na zasadzie tego, jak dobry jest ten model, co on generuje, poprawiać go w takim iteracyjnym podejściu continuous improvement, to jesteś w stanie uzyskiwać z czasem coraz większą wartość na podstawie feedbacku użytkowników, czyli w tym przypadku deweloperów. Dobrze by było, żeby ten proces, który wbudujesz to i narzędzia, w które wbudujesz, od razu dostarczyły im feedback. I dobrze by było, żeby był jak najbliżej deweloperów. Na Jirze jest to najłatwiej zbudować, może można by było to wbudować w IDE, to też jest do zrobienia, bo czemu by nie. Natomiast przechodząc do tego, o czym wspomniałeś, to jest jakby otwieramy tutaj kolejną drzwi, no bo musimy jakoś mierzyć tą efektywność, więc znów, jeżeli będziesz projektował taki przykładowy proces modelowania zagrożeń, w oparciu o LLM bazując na skali, to musisz mierzyć na wyjściu z procesu developmentu, czy te rzeczy zostały zaimplementowane. Najoptymalniejszą miarą, którą jest niestety ciężka do wdrożenia, bo to też wymaga jakby kosztów, jest mierzenie to, że masz proces z developmentu bez modelowania zagrożeń, mierzysz ile sugestii dotyczących cyberbezpieczeństwa, dotyczących, nie wiem, bezpiecznego kodowania zostało wdrożonych czy bezpiecznej architektury na końcu i sprawdzasz, czy po wdrożeniu modelowania zagrożeń ten współczynnik rośnie. Albo wprost sprawdzasz to, co wygenerowały LLM-y i testujesz na końcu procesu developmentu, czy rekomendacje, które wygenerował LLM, były zaimplementowane. I można to zrobić, oczywiście to wymaga pracy i to nie jest tak, że wrzucisz LLM-a i on rozwiązuje proces modelowania zagrożeń, to jest coś, nad czym musisz poświęcić czas, siedzieć i optymalizować cały ten proces. I to tak naprawdę dotyczy każdego problemu, chociażby wspomnianego przez Ciebie SAST-a, bo to działa tak, jak wspomniałeś, dokładnie w ten sam sposób. Jeżeli dodajesz SAST-a, to jak zmierzysz to, czy ten SAST jest efektywny? Jest to o tyle łatwiejsze, że cały proces jest bardziej deterministyczny, więc jesteś w stanie identyfikować to, kto rozwiązuje jakie podatności, nie wiem, które są oznaczone jako false positive, które nie, więc tutaj jakby cała dojrzałość tych narzędzi już jest o tyle lepsza i ten determinizm sprawia, że łatwiej jest to mierzyć, ale dalej sprowadza się to do takiego samego… końcowego efektu, że musisz zidentyfikować na końcu procesu, czy na którymś quality gate w całym procesie, jak rzeczy, które proponowane są deweloperom, są efektywne dla nich i pomocne. Więc feedback loopy, przyłożenie jakichś założeń początkowych i mierzenie ich później, to są bardzo cenne rzeczy, które pomogą nam zdefiniować efektywność. Zdefiniowanie ich i doprecyzowanie tego, co to powinno być, zależy już od konkretnej implementacji w konkretnym procesie. I jeszcze jeden czynnik do tego modelowania zagrożeń i tego typu procesów, który jest bardzo często, moim zdaniem, pomijany, to to, że nie mierzymy albo niewystarczająco dobrze mierzymy i niewystarczająco dobrze skupiamy się na aspekcie wzrostu świadomości deweloperów z tego, że oni korzystają z danych narzędzi. Jedną rzeczą jest faktyczna implementacja sugestii, które ci generuje SAST, cokolwiek innego, usuwanie findingów, a druga, taki poboczny outcome bardziej długofalowy jest taki, jak wzrasta świadomość deweloperów o tym, co jest istotne, dlaczego jest istotne i na co zwracać uwagę. Bo w takim przykładzie możemy chyba sobie łatwo wyobrazić taką sytuację, że znów wracając do tego przykładu z tym jednym QA inżynierem, że on przeprowadzając testy, przeprowadzając modelowanie zagrożeń przy użyciu AI-a, będzie widział powtarzające się patterny, bo one się tam dzieją, one się wydarzają i AI będzie podsuwał te patterny, ucząc się na wcześniejszych przykładach i możemy przyjąć, że na podstawie tego, jeżeli… będzie świadomie podchodził taki inżynier do tego modelowania zagrożeń, on się będzie uczył, jego świadomość będzie rosła, co jest trudne do zmierzenia. I analogicznie w tym przykładzie, gdzie mamy dużą korporację i w skali wdrażamy takie modelowanie zagrożeń w oparciu o AI, będziesz miał tą sytuację z tym jednym QA inżynierem zmultiplikowaną ileś razy i oni dalej będą uczyć się tego, że powtarzają się jakieś wzorce i być może kiedyś to oni będą mogli poprawiać ten proces albo powiedzieć, ok, ten AI generuje bzdury, wyłączcie mi to, ja to będę robił sam, dostosuję się do tego, co tam było, więc znów widzę w tym dużą wartość taką pracy w skali i też wartość edukacyjną, bo niestety, ale to są rzeczy, które nie są powszechne, takie rzeczy jak modelowanie zagrożeń.

Krzysiek: No to swoją drogą.

Andrzej: To tak na duży marginesie, to niepowszechne, to tak dyplomatycznie to nazwałeś.

Krzysiek: Bo my tu mówimy o automatyzacji modelowania zagrożeń, a teraz niech pierwszy kamieniem rzuci ten, który to w ogóle robi u siebie w firmie, nie.

Maciej: Ja ci rzucę kamień.

Andrzej: Wiesz, przynajmniej u nas na lokalnym rynku to zanim dojdziemy do modelowania zagrożeń, to jeszcze wiele innych praktyk musi być wdrożone. To modelowanie zagrożeń to są ważniejsze rzeczy i to nawet takie wynikające z regulacji.

Maciej: Tak, no jakby szczerze, nie spotkałem się, jakby dużo różnych regulacji, standardów bezpieczeństwa czytałem i Dobra, wyjmijmy z tego OWASP-a, bo to jest inna bajka, ale pomijając OWASP-a, nie sądzę, żeby któryś, nie znam przynajmniej, być może są, może mi tutaj podpowiecie, które regulacje mówią o tym, żeby robić modelowanie zagrożeń. Wprost jest napisane, rób modelowanie zagrożeń.

Krzysiek: Wiesz co, ciężko byłoby powiedzieć, że ktoś wprost ujmuje to tymi słowami jako modelowanie zagrożeń. To jest zawsze podszyte czymś innym i jest takie dosyć szerokie do interpretacji. Domyślcie.

Maciej: Bo ten projekt, ten całe modelowanie zagrożeń jest mega wartościowe, ale jest też mega miękkim takim procesem. On nie jest bardzo mocno sparametryzowany, jak to robić i tak dalej. A druga sprawa jest taka, że znów czytając różnego rodzaju standardy, NIST-y, inne frameworki od ISO po CMMC i inne rzeczy, mam wrażenie, że autorzy tych frameworków, tych standardów, oni dalej nie zauważyli tego, że jest coś takiego jak agile i continuous delivery, continuous integration, że oni jakby dociera, gdzieś już się pojawiają takie sugestie, że być może wiedzą, że chmura istnieje, ale że coś takiego jak continuous development istnieje, nie ma szans. Więc do punktu, zanim oni zauważą, oczywiście upraszczam znów i to jest ogólnie, ale do punktu, w którym te regulacje zauważą, że istnieje zwinny proces developmentu i tam ma być jeszcze jakieś modelowanie zagrożeń, myślę, że jeszcze trochę czasu mamy. Niestety.

Krzysiek: No tak, pełna zgoda. Pełna zgoda, Macieju. Z mojej strony takie pytanie do Ciebie zamykające nasze spotkanie, bo będziemy dobijać powoli do brzegu. Powiedz mi, bo… rozmawialiśmy teraz na temat tego, jak AI może nas wspomóc w pracy jako bezpieczeństwo firmy w budowaniu bezpieczeństwa. A jakie są twoje, jaka jest twoja wizja na to, jak AI zmieni rynek atakujących?

Maciej: O, to ciekawe pytanie, to pewnie tutaj. Bo ułatwi im tłumaczenie tych wiadomości phishingowych na różne języki.

Andrzej: To na pewno. To na pewno.

Maciej: Ciekawostka tego. A propos tego. Zauważyłem, że teraz różnego rodzaju salesi piszą do mnie po polsku, mimo że są tam, nie wiem, z Silicon Valley. Różnego rodzaju cudowne narzędzia i już piszą normalnie po polsku. Nie wiem, jak się nauczyli. I to perfekcyjnym polskim. Nawet czasami ja więcej błędów robię.

Andrzej: Ale wiesz co, ja też to zauważyłem, że na LinkedInie dostaję wiadomości od ludzi, którzy polskiego nie znają, a piszą bezbłędnie. Ciekawe jak.

Maciej: Może. Ale w sensie, jeżeli chodzi o atakujących, nie wiem, czy pomoże to im na tym etapie ułatwić, nie wiem, same ataki, ale być może i to chyba już obserwujemy. Nie czytałem żadnych raportów, więc ciężko mi się odnieść do konkretnych liczb, ale tak z moich obserwacji tych incydentów, które się dzieją, tych gdzieś tam informacji i newsów, które się gdzieś… przewijają, to to, co możemy obserwować, to też taką optymalizację pod kątem właśnie produktywności, nie. Takie drobne rzeczy typu, nie wiem, przygotowanie targetowanych kampanii i tak dalej, te rzeczy związane z, nie wiem, z jakimiś próbami deepfake’ów, czy podszywania się pod różnego rodzaju osoby, no to myślę, że… w tym kierunku bym patrzył, że to są raczej takich, nazwijmy to script kiddies, oni też będą w ten sposób próbowali to optymalizować, nie. Bo nie wiem, czy tacy zaawansowane grupy przestępcze APT będą chciały oddać w ręce AI jakiś bardzo, nazwijmy to, sophisticated attack, żeby im to spieprzył, wiecie, godzinę i lata pracy, nie.

Krzysiek: Wiesz, wiecie, pytam dlatego, że znowu zahaczamy gdzieś te kwestie marketingu i widać, jak ci bezpiecznicy teraz, którzy zawsze stali z tą pałką, mówią, nie, no teraz to już mamy totalnie przekichane, bo zobaczcie, oni mają AI, oni już nie dość, że mają komputery, to jeszcze mają AI.

Maciej: Tak, to chociażby z ostatnich dwóch tygodni to widziałem właśnie sporo takich, chyba najświeższą taką tego typu aferą, o której mówisz, jest kwestia tego, że ChatGPT może dowody osobiste generować i wszyscy teraz wpadają panikę, że ChatGPT może dowód osobisty wygenerować. Nawet ja, nie mając skilli żadnych graficznych, potrafię wygenerować dowód osobisty w jakimkolwiek narzędziu i nie jest to specjalnie trudne, więc nie wiem, ale tak. Troszeczkę, muszę przyznać, że jestem troszeczkę zmęczony tym, co się dzieje na LinkedIn, właśnie w tych kwestiach tego kolejnej afery i kolejnego super odkrycia jakiegoś niestandardowego.

Krzysiek: Niesamowitego wektora ataku, tak. Czyli…

Maciej: Z jednej strony mamy tą burzę, o, AI zabiera nam pracę, bo tutaj już zwalniają ludzi, bo zastępują AI. Podsycone to jeszcze postami niektórych CEO o tym. A z drugiej strony mamy, o, bo teraz atakujący… i coś tam się dzieje, nie. Oczywiście, że to zmieni, jakby użycie samo AI i sam rozwój tej technologii dokłada nam nowe wektory ataków i nowe problemy, tylko że tak jak i z zastosowaniami tych AI, których jeszcze nie odkryliśmy, takich cudownych, jakbyśmy chcieli, bo nie wiem, czy się ze mną zgodzicie, ale ja mam przeświadczenie, że dalej nie doszliśmy do tego, w czym to AI jest super dobra, to tak samo nie jesteśmy, nie odkryliśmy jeszcze pewnie tych zagrożeń, które gdzieś tam się będą pojawiać, bo to się rozwija równolegle, nie. Tylko łatwiej się sprzedaje i kupuje te rzeczy pozytywne niż te negatywne, nie.

Krzysiek: Otóż to, otóż to. A czy doszliśmy? Czy nam pomogło? Ja nie wiem, nie wiem, w czym mi pomogło. W generowaniu bezsensownej jakości raportów, które muszę generować.

Maciej: Ale to musiało być dłuższa, bo też nie widziałem Ciebie w stylu animowanym.

Andrzej: W stylu Studio Ghibli. To wrzuciłem kadry z polskich filmów. I ten post to był Jezus Maria. Przebił wszystko, co do tej pory tworzyłem. Co z jednej strony mnie cieszy, ale z drugiej strony trochę smuci. Więc mam mieszane uczucia co do tego faktu.

Maciej: Kurczę, ale przegapiłem to.

Andrzej: To podeślę Ci link, spokojnie. Mówisz, masz. Zaraz będziesz miał.

Krzysiek: Dobra, panowie, to co. Dobijamy do brzegu. Odpowiedzmy na te pytania, które padły na czacie.

Andrzej: Krzysiek, sprawdź jakieś pytania, bo ja tam nie widzę. O, mam, dobra. Rafał pyta. Tak, jak wygląda kwestia zatrudnienia osób mieszkających w Polsce przez firmy z US of A od strony praktycznej? Jakieś dokumenty, zezwolenie na pracę, co z kwestią różnicy czasu itp. Jak to wygląda z twojej strony, Maciek? Co trzeba było zrobić, żeby cię zatrudnili w US of A?

Maciej: Ta sytuacja jest, to pytanie jest bardzo rozległe, bo znów to zależy od konkretnej firmy, bo są firmy, które zatrudniają bezpośrednio transoceanicznie, nazwijmy to, i pracujesz bezpośrednio dla firmy w Stanach, ale są też firmy, takie jak chociażby Ignite, która ma swoją spółkę, córkę, tak to chyba możemy nazwać, w Polsce i zatrudniasz się w spółce w Polsce. I to jest dość częsty przypadek, bo dużo rzeczy ułatwia z punktu widzenia prawnego, procesowania wszystkich rzeczy i tak dalej. Więc to tak naprawdę jest zależne od… tego, jak podchodzi do tego dana firma. Więc masz opcję albo bezpośredniego zatrudnienia tam i podpisania międzynarodowych umów, albo podpisania umowy tutaj ze spółką pokrewną w Polsce czy w Europie, bo analogicznie to działa. Jeżeli chodzi o Unię Europejską, no to jeżeli jest, wiecie, w Unii Europejskiej spółka, no to podpisujecie z najbliższą, tak naprawdę i to jest o tyle wygodne, że macie te benefity wynikające z jakichś prawnych, lokalnych zobowiązań, natomiast jak pracuje się bezpośrednio, no to musicie brać poprawkę na to, że nie wszystkie procedury prawne będą aplikowały się tak samo, bo tak naprawdę wtedy podpinacie się pod prawo amerykańskie, więc tak to wygląda.

Krzysiek: Właśnie, wiesz co, bo wpadło mi takie pytanie z boku, jak właśnie mówisz o tych trans… oceanicznych relacjach. Powiedz mi, jak to wygląda, czy Polak pracujący na przykład dla takiej firmy jak Ty może uzyskać takie security, takie poświadczenie bezpieczeństwa, które umożliwia mu współpracę w jakichś kontraktach rządowych w Stanach?

Maciej: Szczerze to się nie wiem, nie orientowałem się w tej kwestii, jak to wygląda i jak zdobyć takie, więc nie odpowiem ci na to pytanie. Pewnie tak, ale jakie są wymagania, to…

Krzysiek: Bo z tego, co słyszałem, to jest dosyć może nieczęsty, ale przejawiający się wymóg, jeżeli chcesz w ogóle gdzieś tam współpracować, nie. Na tym poziomie z tymi agencjami rządowymi w Stanach, jakby to nie jest takie hop-siup, że wskakujesz, pracujesz dla nich jako kontraktor.

Andrzej: Z tego co wiem, to jeżeli nie masz obywatelstwa, to nie dostaniesz klirensa w Stanach Zjednoczonych. I to nie tylko w Stanach Zjednoczonych, to dotyczy praktycznie każdego kraju. Nie masz narodowości. I to mówimy już nawet o tym pierwszym poziomie klirensa, a on ma poziomy i tam od któregoś to nie dostaniesz nawet nie tylko jak jesteś, nie masz obywatelstwa, ale musisz mieć na przykład twoja matka albo jej matka też musi mieć obywatelstwo. Któregoś tam poziomu w dół.

Maciej: Obstawiam, nie wiem, nie będę się wypowiadał, bo nie mam dla tego pojęcia, ale obstawiałbym, że są na to też obejścia, jakby wiecie, jakby sektor rządowy w Stanach bardzo dużo opiera się na jakichś dostawcach zewnętrznych. W Polsce jest to trochę niewyobrażalne, bo tutaj za każdym razem jak się okazuje, że jakaś prywatna firma robiła coś na potrzeby rządu, to jest to afera, natomiast w Stanach jest to dosyć powszechne podejście. Zresztą Edward Snowden był takim przykładem chyba najbardziej znanym takiego podejścia, gdzie pracował dla zewnętrznego dostawcy. Ale obstawiam, że jest to w jakiś sposób do zrealizowania. Tak, jest.

Andrzej: Tam oczywiście mają zawór bezpieczeństwa. Mają dodatkowe takie, ale to nie jest klirens, to jest dostęp.

Maciej: Ju.

Andrzej: Do konkretnej tej, bo klirens daje ci do wszystkich na tym samym poziomie, a tam to nie będzie działało jak klirens, więc masz taki zawór bezpieczeństwa i on jest zrobiony dokładnie z tego powodu, że są ludzie, którzy mają tak wysoką ekspertyzę, że rząd Stanów Zjednoczonych i tak chce im, chce skorzystać z ich ekspertyzy.

Maciej: Jest to ta wiza taka najbardziej znana, nie?

Andrzej: O1A to jest dla wybitnych ekspertów w danych dziedzinach. Nie klasyczna H1D, tylko w O1A.

Krzysiek: Jaki w ogóle obeznany.

Andrzej: Kiedyś chciałem emigrować do Stanów, ale w pewnym momencie nie przeszło.

Krzysiek: Ale niestety nie dostał O1A.

Andrzej: O1A wcale nie jest tak trudno dostać, Krzysiek. Jakbyśmy napisali tą książkę, wypuścili przez No Starch Press, jeszcze pojechałbyś na trzy konferencje, to już jesteś osobą, która by się klasyfikowała pod O1A. Więc to tam nie musisz być żadnym geniuszem. Po prostu musisz mieć zrobiony social proof, który dowodzi tego, że faktycznie jesteś najwyższej klasy ekspertem w tym, co mówisz, że jesteś najwyższej klasy ekspertem.

Maciej: Przecież to nie jest takie trudne to osiągnięcie.

Krzysiek: Tak.

Maciej: Wcale nie musisz być takim ekspertem, żeby to osiągnąć.

Andrzej: To nie. A musisz być, wiesz, musisz być dobry w marketing, to naprawdę.

Krzysiek: I trendować jako ekspert.

Andrzej: Widzisz, na polskim polu to często wystarczy.

Krzysiek: To przejdźmy do drugiego pytania, zanim zabrniemy zbyt daleko. Rafał pyta, czy różne certyfikaty branżowe są często bardzo istotne lub zauważyłeś inne różnice rynkowe względem firm z PL i Unii Europejskiej.

Maciej: To pewnie zależy kogo pytasz. Jak zapytasz tych, co sprzedają certyfikaty, to powiedzą, że są bardzo istotne. Jak zapytasz tych, co rekrutują, to ci powiedzą, że… raczej nie. Taka jest moja opinia, ja nie spotkałem się z tym, żeby ktoś zadał jakieś pytanie dotyczące samego certyfikatu. Oczywiście jak w CV masz, to to fajnie wygląda, bo masz jakieś tam potwierdzenie, że ktoś już jakieś doświadczenie ma, chociaż i tak najbardziej cenną walutą jest doświadczenie komercyjne, które masz wpisane w CV, żeby pracować dla tych i dla tych firm. Te certyfikaty są takim dodatkiem. I to jest tylko moje osobiste doświadczenie. Nikt nigdy nie pytał mnie o żadne certyfikaty.

Andrzej: To z mojego doświadczenia dodam, że certyfikaty szczególnie dla organizacji ze Stanów Zjednoczonych mają większe znaczenie niż dla polskich, ale to są konkretne. I często dlatego, że tak samo jeżeli się certyfikujemy pod ISO 27001 czy SOC2, oni niejako trochę ryzykują zatrudniając Ciebie, więc jeśli masz certyfikaty jak CISSP czy nawet CEH, który u nich jest uznawany, no to dla nich to jest taki lepszy sygnał, że o, przynajmniej ma ten certyfikat.

Maciej: A w compliance’owym to się zgadza, bo to jest taki wymóg, że musisz mieć potwierdzenie tego, że osoby, które zatrudniają się od bezpieczeństwa są wykwalifikowane, przy czym de facto możesz im, jako dowód możesz im dostarczyć sam fakt tego, że słuchajcie, mamy proces rekrutacyjny, który jest przeprowadzony w taki i taki sposób i to też będzie akceptowalna forma, nie. To jest ułatwienie, no bo… wrzucasz im plik z certyfikatem i okej, decyduje.

Andrzej: Exact. Natomiast tak jak Maciek tutaj mówił, doświadczenie tutaj broni się samo i jest ważniejsze niż certyfikat.

Krzysiek: Dokładnie, dokładnie. Czyli znowu ten compliance i ten certyfikat jako dubochron.

Maciej: No wiesz, ja wychodzę z założenia, że to czego się nauczysz podczas tworzenia certyfikatu, na tego ci nikt nie zabierze. Exact.

Krzysiek: Gorzej jak zrobiłeś go po to, żeby wpisać go w pole nazwisko na LinkedInie. Dobrze, przejdźmy do trzeciego pytania. MPLBL pyta, a ja mam pytanie o kasę. O, proszę bardzo, wszyscy robimy pieniążki. To są konkretne pytania. Jak wygląda kwestia zarobków z security w porównaniu do programistów, na przykład Javy czy inżynierów DevOps?

Maciej: Dobrze.

Andrzej: Ja tutaj lekko zchallenge’uję, bo jeśli mówimy do programistów Javy, czy nowszej wersji JavaScript, to może wygląda dobrze. Ale jeśli już porównamy do inżynierów DevOps, to myślę, że dobry DevOps będzie zarabiał podobne pieniądze do dobrego bezpiecznika.

Maciej: Zgadza się. Jeżeli weźmiecie sobie pod uwagę raporty takie płacowe, to zauważycie, że te widełki, znów, to jest znów pewne uogólnienie, bo to zależne od tego… co to jest za bezpiecznik, to one się będą gdzieś bardzo mocno pokrywały, więc to się zgadza, tutaj nie jest wymyślone, to jest stan faktyczny i myślę, że tu więcej dodać, jeżeli chodzi o Javę, no to pewnie będzie podobnie, myślę, że jednak bliżej jest do tych DevOpsów, jeżeli chodzi o takie techniczne bezpieczeństwo i wygląda to całkiem dobrze w porównaniu do takich… programistycznych prac. Bierzcie pod uwagę i to jest prosty wyznacznik, że jeżeli tych ekspertów jest mało, to te zarobki po prostu rosną proporcjonalnie do tego, jak mało jest tych osób. Niestety nie zanosi się, żeby ich było więcej, tym bardziej, że i to jest ta cecha wspólna, że żeby być dobrym, nazwijmy to właśnie, DevOpsem, musisz nie tylko znać… jakąś taką działkę o nazwie DevOps, nie możesz się po prostu wyszkolić w DevOpsie, tylko jesteś lepszym DevOpsem, jeżeli znasz wiele różnych gałęzi, wiesz jak się łączą te wszystkie rzeczy, bo pracujesz na styku różnych komponentów, różnych warstw systemu, więc musisz mieć wiedzę bardzo też nie tylko specjalistyczną w zakresie DevOpsowym, ale wiedzę wokół tego i analogicznie jest w technicznym cyberbezpieczeństwie, że musisz mieć wgląd w bardzo wiele tematów i im większej działce masz doświadczenie, w większej liczbie działek masz doświadczenie, tym będziesz bardziej skutecznym bezpiecznikiem, a to z kolei znów się przekłada na wzrost wynagrodzenia, bo masz większe doświadczenie i jesteś bardziej skuteczny, więc same te czynniki warunkują to, że to są dobrze płatne prace, no i chcę wierzyć w to, że nie zmieni się to w najbliższej przyszłości, nic na to nie wskazuje, chyba, że te AI-e.

Krzysiek: Tak, Maciej. W ogóle fajną rzecz zahaczyłeś, która mi teraz bije po głowie i sobie ją zaraz zapiszę w moim cyfrowym ogrodzie, że tych DevOpsów, którzy faktycznie rozumieją, na czym DevOps polega, a nie są kolejnymi administratorami, że mają to doświadczenie w rozwoju software’u, wiedzą, jak te silosy jednak integrować, a nie tworzyć kolejny silos, który po prostu nazywa się DevOps.

Maciej: To DevOps się stało takim hasłem po prostu, no bo sama ta nazwa sugeruje, że to jest taka wiedza, czy… wiedza z zakresu różnych jak gdyby obszarów i integruje się to w jednym. Teraz my mówimy o DevOpsach, że są po prostu DevOpsami, ale założenie, o ile dobrze pamiętam, było takie, że nie ma ludzi, którzy są DevOpsami, tylko masz deweloperów, którzy mają umiejętności opsowe. Tak trochę tutaj nie poszło chyba w tym kierunku, w którym miało iść, aczkolwiek bardzo dalej jest to ceniona i potrzebna, potrzebna rola w całym systemie, jak się okazuje.

Krzysiek: Dokładnie, dokładnie tak. No to co. Dobiliśmy do brzegu. Macieju, bardzo Ci dziękujemy za te niecałe półtorej godziny bez 15 minut. Widzimy się pewnie jakoś na jakiejś konferencji, która w tym roku nadejdzie. Mamy nadzieję.

Andrzej: Przyjeżdżasz na 4Developers?

Maciej: Chyba nie. Kiedy jest?

Andrzej: To jak nie jesteś zapisany, to już nie przyjeżdżasz, bo jest tegoż, z tego maja. To nie, to będziemy się widzieć pewnie na spotkaniach rady programowej do The Hagues, ale do tego jeszcze z miesiąc.

Maciej: A to nic nie wiem też.

Andrzej: Spokojnie, dowiesz się w swoim czasie.

Krzysiek: Dobrze, to co. Życzymy Wam udanych. Udanego świętowania. Nadchodzi kilka dni wytchnienia od pracy. Także co. Wszystkiego dobrego. Jeszcze raz dzięki wielkie Maciej za spotkanie. Dzięki Andrzej.

Maciej: Soczystego jajeczka.

Krzysiek: Tak.

Maciej: Dzięki wielkie za zaproszenie.

Andrzej: I udanych prezentów na zajączka. Tylko ja słyszałem, że zajączka… Ja byłem bardzo zdziwiony, bo wiecie, czy mnie zajączek, czy nie. Nie wiecie? Nie czekamy na puentę, nic. No bo na Śląsku jest coś takiego jak zajączek i się daje prezenty na zajączka. U was też się daje czy nie?

Krzysiek: Znaczy, ja jestem oryginalnie ze Śląska, no i na zajączka też się dawało prezenty, ale myślałem, że powiesz o jakichś innych śląskich tradycjach.

Andrzej: Nie, bo ja byłem zdziwiony, jak przyjechałem do Warszawy, rozmawiałem z innymi osobami, mówię, o, zajączek, prezenty, to mi mówili, a jak to. Jakie prezenty na zajączka? Co to w ogóle jest? Jakie prezenty? Ja mówię, to normalne prezenty. A zaraz ci poczęstuję klockiem. Dobra, panowie. Kończymy i będziemy się widzieć w przyszłości w internetach, a prędzej czy później na jakiejś konferencji fizycznej. I co. Do tego czasu pozdrawiamy.

Krzysiek: Dajcie znać, co dostaliście na zajączka w komentarzach. Trzymajcie się.

Andrzej: Czyż krokodylki smakowały. Trzymajcie się. Na razie.

Maciej: Hej.

---