Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…

Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka oczywiście na Patoarchitekci.io lub w opisie. Wygooglacie, wybingacie, coś tam jeszcze innego zrobicie, ogarniecie ogólnie rzecz biorąc. Dobrze, Łukasz się śmieje, bardzo, bardzo miło Cię widzieć.

Łukasz Kałużny: Tak, bo patrzę na linki, o których dzisiaj będziemy rozmawiać. Oskar mi mówił, że trochę dawał mi taki personalny feedback, że trochę nudno, bo przeskakujemy ciągle pomiędzy Generative AI i Kubernetesem i widzę, że bingo jest już złapane w dzisiejszych linkach.

Szymon Warda: Wiesz co, jest, no dobra, niech będzie. To co, zaczynamy?

Łukasz Kałużny: Wiesz co, ja zacznę w takim razie od, jak to było? To jest określenie, z którym w ogóle wcześniej się nie spotkałem. Czyli te całe użycie AI agentów, asystentów do kodowania. Niektórzy nazywają vibe codingiem, że wiesz, siedzisz sobie i takie flow type’owania i za Ciebie ktoś odwala tą robotę. Ale nie o tym, tylko o dowcipie, który widać po kodzie, który jest wypluwany jak osoba, która nie ma pojęcia czym tak naprawdę jest kodowanie mówi, że coś wytworzyła w jeden wieczór, zbudowała SAS-a. Więc jest sobie tutaj gościu chwalący się, że zbudował tam SAS-a i w ogóle zaczyna na nim zarabiać. Po czym, na szczęście tweet nie został zabrany: guys, I am under attack. Więc ludzie zaczęli mu, jak to określił, że zaczynają się dziać randomowe rzeczy, klucze od API są wymaksowane, ludzie omijają mechanizm subskrypcji i tworzy się randomowa kupa w bazie.

Szymon Warda: Łukasz, też widziałem ten link, nie mogłem znaleźć linka do tego i to jest jeden z moich linków, których nie wkleiłem, ale chciałem o nim porozmawiać. Tak że no te same artykuły czytamy, że tak powiem.

Łukasz Kałużny: Trudno nie.

Szymon Warda: Znaczy wpis jest przegenialny, bo ogólnie on się skarży i na końcu pisze, że: I am not a technical person. I to pokazuje, skoro on widzi właśnie tylko ten mały ułamek, to pomyślcie o tym, ile on nie widzi. Nie widzi całego SQL injection, nie widzi wyciągania danych, nie widzi różnych rzeczy, bezpieczeństwa, itd. Tego będzie dużo.

Łukasz Kałużny: Czy po co mamy wewnętrzne i zewnętrzne ID, które pokazujemy ludziom pomiędzy tymi.

Szymon Warda: Tak.

Łukasz Kałużny: Jest tego masa.

Szymon Warda: Tego jest masa, ale to pokazuje mi jedno: spokojnie, nie mamy się czego bać, AI nas nie zastąpi. Jest taka ilość wiedzy, którą trzeba zrobić, żeby zbudować system, do którego my się przyzwyczailiśmy, takich dobrych praktyk, spokojnie, naprawdę nie będziemy zastąpieni absolutnie w żadnym wymiarze.

Łukasz Kałużny: Ja za to nie mogę znaleźć jednej rzeczy do wklejenia, ale najlepszy komentarz z tego wszystkiego był: cybersecurity będzie jeszcze bardziej opłacalne niż wcześniej.

Szymon Warda: Oj tak, raczej te wszystkie apki, które powstały w weekend, dwa weekendy, w miesiąc za pomocą AI-a, to będzie kopalnia danych dla ludzi od wyciągania tego.

Łukasz Kałużny: Czy wiesz, jeszcze rozumiem internalowa apka w firmie, która nie jest wystawiona do internetu.

Szymon Warda: Tak.

Łukasz Kałużny: Tak, to jest spoko.

Szymon Warda: Chociaż wiesz co, ta apka może nagle dać uprawnienia do tego, żeby np. szeregowy pracownik zobaczył dane finansowe. Więc też bywa różnie.

Łukasz Kałużny: Tak, z tym bywa różnie, ale jest to… Inaczej, brzmi zabawnie, o tak, jak sobie na to popatrzysz. Kurde, inaczej, sam płacę teraz za Cursora, używam, jest spoko, o tak. Nawet robiłem teraz porównanie z tym w GitHub Copilot z AI agentem. Wyniki są podobne, ale szybkość i dojście do tego, Cursor ma troszkę lepiej dopracowane prompty swojego agenta pod spodem po prostu, w przeciwieństwie do GitHuba. I to jest spoko rzecz. Tylko ja będę zawsze powtarzał: masz super juniora i tańszego nie znajdziesz.

Szymon Warda: I to jest tyle. I nie wyuczysz go na coś więcej.

Łukasz Kałużny: Tak.

Szymon Warda: Bo to jest bardzo ważne. Dobra.

Łukasz Kałużny: Dobra.

Szymon Warda: A teraz ja mam artykuł, który trochę podsumowuje i wkłada w metryki to, o czym właśnie Ty powiedziałeś: how AI is reshaping software engineering: key takeaways from DeveloperWeek 2025, no nie. Tam jest kilka takich ciekawych spostrzeżeń. Pierwsze: if an AI assistant understands the codebase, documentation and pass conversations, it doesn’t need to get the perfect answer - it just needs to get you started. I to jest bardzo prawdziwe, bo ja często widzę ludzi, którzy po prostu zamykają się i nie mogą ruszyć, nie mogą pierwszego kroku wykonać i to faktycznie do tego AI się nadaje świetnie, coś zrobi i potem ładnie modyfikujemy. Słuszne spostrzeżenie. Tam jest taki fajny tekst też o tym, że doświadczenie ludzkie jest ważne. Tą samą dyskusje mieliśmy przy okazji ORM-ów, gdzie pisaliśmy, że tak, developerzy nie umieją pisać, pisać SQL-i. Tak, nie umieją, i co z tego? 99% zapytań to są CRUD-y, jakieś proste SQL-ki. One nie wymagają dużej wiedzy. Skupmy się na tym, [niesłyszalne 00:05:48] daje nam możliwość, że skupiamy się na tych, które wymagają uwagi.

Łukasz Kałużny: Tak, mi się podoba następny punkt, czyli właśnie, że ludzka ekspertyza jest ciągle krytycznym elementem łańcucha.

Szymon Warda: Tak, ale idziemy dalej. Tam jest takich parę fajnych cytatów: AI is an amplifier, not a replacement. Engineers who learn how to use and validate AI’s output will have the most significant advantage. Znane i rzeczywiste, ale faktycznie, tak to będzie wyglądało, to właśnie o czym ty mówisz. Modyfikujemy wynik tego, co napisał nam Junior: embrace experimentation. Teams that adopt and refine AI tools will outpace those that resist the change. Leaders must encourage a culture of curiosity and continuous learning. To trochę brzmi jak taki trochę element sprzedażowy, bym powiedział, że tak, popróbujmy wszyscy, a może będzie, może zapomnicie, że za to płacicie. Ale w tym artykule są metryki do mierzenia, czy zespoły faktycznie używają i czy jest tego wartość. I one są naprawdę dobre. Pierwsze: repeated usage - czy developerzy korzystają? Accepted tab completions - czy faktycznie korzystają z podpowiedzi i używają tego, co tam AI wypluł? I na koniec ostatnia, trzecia: developer sentiment - czy polecają innym? I według mnie to są trzy naprawdę świetne metryki do mierzenia tego, czy cały AI, Copiloty, jakkolwiek to nazwiemy, są używane w firmie.

Łukasz Kałużny: Tylko inaczej…

Szymon Warda: Trzeba więcej… Wystarczy.

Łukasz Kałużny: Tylko że produkty nie wystawiają Ci tego w sposób zbiorczy niestety.

Szymon Warda: Też się zgadza.

Łukasz Kałużny: Raczej dwa pierwsze, bo developer sentiment to jest to, o czym mówimy, że ankiety i bez tego nie przeskoczysz, bez ankiet na temat developer experience. Tylko, inaczej, z drugiej strony, czy Ty będziesz mierzył Szymon, jak ja popatrzę na ankiety, developer experience? Trafiałem do tego, że te ankiety powinny być krótkie, więc pytania na temat toolingów w firmie, raczej interesuje Cię przekrojowo na temat toolingu w firmie, a nie konkretnego produktu, który używacie.

Szymon Warda: Wiesz co, dla mnie to jest tak, jeżeli organizacja wchodzi w AI i kupuje dla każdego developera, bo tak to często wyglądało, ten koszt będzie, no nazwijmy to delikatnie, niezerową, będzie zauważalny, jak chcesz, żeby korzystali z dobrych modeli. To jest fajny sposób na walidację raz na, nie wiem, kwartał, czy to realnie jest używane, czy nie jest używane i ocena po prostu czy faktycznie powinni mieć to wszyscy, czy tylko ci, którzy chcą i jak to wygląda. Fajne trzy metryki, sensowne dla mnie.

Łukasz Kałużny: Wiesz co, idę teraz, wchodzę do GitHub Enterprise’a.

Szymon Warda: No dajesz.

Łukasz Kałużny: Przejdę tylko przez MFA, poczekajcie sekundkę. Bo jestem, słuchaj Szymonie, ciekaw, czy w metrykach, które się tam znajdują, co teraz pokazują? Bo to jest akurat ciekawa rzecz, którą mnie teraz, w tym momencie, tak dosłownie, żeby kliknąć sobie na staty i zobaczyć, czy jest coś w ogóle tak wiesz, widoczne od razu. Dajcie sekundkę, membersi…

Szymon Warda: To ustalmy, to są metryki, które spokojnie dostawcy mogliby wystawiać, bo mają te metryki, albo mogliby je zbierać. To nie jest nic skomplikowanego.

Łukasz Kałużny: Okej, mam na pewno Last Active Date.

Szymon Warda: I to jest dobre.

Łukasz Kałużny: I widzę, słuchaj, mamy ten i widzę np., że są osoby, które np. u klienta właśnie nie skorzystały od kilku tygodni z Copilota.

Szymon Warda: To znaczy, że no to nie ma sensu w ogóle żadnego.

Łukasz Kałużny: Że u nich tak, właśnie tak, że to nie ma właśnie widzisz, że nie ma sensu. A zobaczę sobie, co jest w CSV jeszcze. Tak dajcie sekundkę, bo akurat zaciekawiło mnie to, o, jest nawet powiedziane jaki edytor i jaki model ostatnio został użyty, więc prawdopodobnie takie rzeczy da się wyciągnąć. No to ciekawe. Ciekawa rzecz do zbadania. Będzie ciekawa rzecz do zbadania jak to z Copilotem pożenić.

Szymon Warda: Dokładnie. Dobra, co tam Ty wyszukałeś, googlałeś, jakkolwiek to nazwiemy?

Łukasz Kałużny: Następna rzecz to Werner, bo te S-trójkowe tabele lecą sobie na [niesłyszalne 00:10:15] i jest długi, przyjemny wpis od Wernera na temat S3 i tablic w S3. Jeżeli teraz popatrzymy, to jest taki opisany wpis jak wygląda ewolucja S3 i jedną z rzeczy, którą tam podkreślają, to podkreśla, to jest znaczenie prostoty w tej usłudze, że to jest jeden z takich… Nawet jeden z nagłówków wspomina o napięciach pomiędzy zwinnością a prostotą. Bo jednak budowanie usługi API w tej skali, żeby było ciągle jak najbardziej proste, jest z perspektywy klienta bardzo trudnym elementem i jest sporo rzeczy, o których mówi, gdzie w końcu pokazuje, dochodzi do tego, że S3 tables były właśnie i wsparcie natywne dla Iceberga były właśnie takim natywnym krokiem, o który klienci pytali, o tego typu usługę.

Szymon Warda: Znaczy ustalmy, to wprowadzenie właśnie jest o funkcjonalności, o której mówiliśmy, bo to było w kontekście ostatniego Reinventa. To naprawdę jest fajny krok w dobrym kierunku, bo znacznie upraszcza to, jak systemy są budowane w AWS-ie i umożliwia naprawdę fajne rzeczy. Mniejszy ból głowy/dupy, jak kto woli. Przepraszam przedszkolaków, ale…

Łukasz Kałużny: Pupy.

Szymon Warda: Pupa, niech będzie. Tak że…

Łukasz Kałużny: Tak, Iceberg, jak sobie popatrzymy…

Szymon Warda: Stało się skomplikowane.

Łukasz Kałużny: Jak popatrzymy sobie na Iceberg, to ja też chciałbym dorzucić do tego, że jak popatrzymy słuchajcie na Iceberg, to jest to jednak w tym światku, jeżeli teraz budujemy z narzędzi open source’owych rzeczy data lake’owe właśnie np. te Dremio i inne rzeczy, które są, to jest teraz taki way-to-go podejście. Ja też dorzuciłem książkę, ponieważ nie wiem, kto mi to podsyłał tego linka, ale za co dziękujemy, jest od Aureliego za dzięki Dremio wyrzucona właśnie Apache Iceberg Definited Guide, taki prawie 350 stron książki na temat Apache Iceberga ze wszystkimi rozważaniami, jak to w ogóle ustrojstwo działa i o co w nim chodzi. W szczególności architektura.

Szymon Warda: Prawie 350 stron książki.

Łukasz Kałużny: Tak, no bo to jest kawałek jednak. Jak ktoś chce wejść, to wystarczy na początek tylko rozdział drugi, czyli architektura Apache Iceberga, która jest rozbita na właśnie te wszystkie podejścia, czym jest tabela w katalogu Icebergowym. Bo to dobrze pokazuje, w jaki sposób korzystając, to co jest zresztą opisane w artykule, te elementy, które się pojawiły, czyli strong consistency, operacje warunkowe, które pozwoliły, że tak powiem, te S3 tables zbudować na tym, co istnieje, bo to też jest. Tak, więc warto sobie przeczytać. Długi wpis, taki ogólnikowy, nie jest super techniczny, ale warty przeczytania.

Szymon Warda: Taki bardziej jeżeli chodzi o podejście. Dobra, to coś zupełnie innego, żeby nie było, że tylko AI i Kubernetes faktycznie. Mała drama, która się wydarzyła i oburzenie na Reddicie w związku z tym, że kompilator do TypeScripta jest napisany teraz w Go, a nie w Rust.

Łukasz Kałużny: Będzie pisany, jest przepisywany na Go.

Szymon Warda: Masz rację, tak. I ktoś jeszcze rzucił na Reddicie oczywiście, że: a czemu nie C Sharp? I jest fajna odpowiedź: well, you can tell that to the guy who created TypeScript and C Sharp, but he disagrees with you. Bo to ta sama przecież osoba stworzyła jedno i drugie. Ale jest fajna odpowiedź w ogóle, taka już merytoryczna. Swoją drogą mnie rozbawiło to, że w tym całym artykule jest podkreślane, że cały wywiad był na Zoom Interview, co jest przezabawne w kontekście firmy oczywiście. I tam jest fajny cytat: the lowest level language you can get to that gives us full optimise native support on all platforms, great control over data layout, the ability to leave cyclic data structures and so for. And gives you automatic memory management with a garbage collector and a great access to concurrency. Czyli ogólnie fajny artykuł, bo oni porównywali tam różne właśnie języki, jak się sprawują, do czego który się nada. I parę rzeczy tam było dość ciekawych, to co właśnie wyłapaliśmy - natywne wsparcie na wszystkich platformach, kontrola nad układem danych, garbage collection, dobre wsparcie dla współbieżności. Ale jeszcze jedna rzecz, że kompilator TypeScripta nie używa za bardzo klas, ma bardzo mało klas. A Go ma bardziej funkcje i struktury, niekoniecznie klasy. Więc to przepięcie między jednym a drugim byłoby po prostu przy OOP, czyli object-oriented programming, byłoby zbyt dużym narzutem i mentalnym i wydajnościowym. Tak że ciekawy dla wszystkich dogmatorów.

Łukasz Kałużny: Tak, jeszcze dobre było na temat Rusta, co mi się podobało, że w Golangu muszą wrzucić mniej unsafe kodu niż w Rust’cie.

Szymon Warda: Też dobre.

Łukasz Kałużny: Też było właśnie, tylko nie wiem, w którym to było podsumowaniu takim. Bo tam w tym wątku było gdzieś więcej odpowiedzi na ten temat, jak go tam przekopiemy, bo też go śledziłem. No i całość było to, że oni TypeScript względem typów, które są na Golangu, są w stanie osiągnąć dość niezłe mapowanie jeden do jednego, przy czym będą też wchodziły zmiany do języka z tego powodu.

Szymon Warda: No niezłe. Dobra.

Łukasz Kałużny: Tak, więc zobaczymy jak to będzie. Dobra, idziemy. To jest zabawny babol, który mi się słuchaj rzucił i stwierdziłem, że takie podatności lubimy. Tutaj mało używany w naszym kraju i światku język wyrwał, czyli Ruby, wyrwał podatność w SAML-u. Sign in as anyone, tak można określić podatność. Jest ona w GitHubie cała, na blogu GitHuba jest cała opisana jak wygląda. Ale prowadziło to do tego, że biblioteka miała ciekawą podatność pozwalającą zalogować się jako ktokolwiek w systemie.

Szymon Warda: Dość niemiło bym powiedział.

Łukasz Kałużny: Tak, to taka drobna ciekawostka. Jak to wygląda? Z całości, w jaki sposób wygląda? Inaczej, ile czasu trwają takie poprawki? Bug Bounty report demonstrate the authentication bypass - 4 listopada. Fixed version of Ruby SAML was released - 12 marca.

Szymon Warda: Ok, to jest jedna rzecz. To jest to, kiedy naprawili bibliotekę. Wyobraź sobie ile jest setek tysięcy systemów…

Łukasz Kałużny: Systemów, które będą, raczej setek tysięcy… Inaczej, ile jest rzeczy wystawionych, jako że to jest SAML, rzeczy wystawionych do netu, w szczególności w SAS-ach B2B?

Szymon Warda: Od groma. Kiedyś był okres, że wszystko było budowane w Ruby. Więc jestem bardzo ciekawy ile tego za chwilę wypłynie, bo podatność jest przerażająca bym powiedział, naprawdę.

Łukasz Kałużny: Jestem ciekaw czy ktoś… Inaczej, jak była eksplorowana, bo to jest w ogóle, czy była, bo jest to ciekawe.

Szymon Warda: Dobra, to ja polecę z kolejnym. Bardzo krótki artykuł z The New Stack i niestety sponsorowany artykuł. I artykuły z New Stacka mają to do siebie z reguły, że są po prostu kijowe jak nie wiem co. Ale czemu go wrzucam? Bo on jest dobry do przeskrolowania, pierwsze tam może parę akapitów. Jest o tym jak działa Swift. Nie ten język do programowania, tylko SWIFT do przelewów międzynarodowych.

Łukasz Kałużny: Tak.

Szymon Warda: I to jest mega ciekawe, ponieważ oni po prostu działają tak, że w bankach deploy’ują klastry kubernetesowe, które działają bez dostępu do internetu. I robią deploymenty cross-bankowe właśnie korzystając z Argo CD. Więc pierwsze parę paragrafów do przejrzenia, tyle. Mnie zaciekawiło właśnie, że to właśnie śmiga na klastrach, co jest w ogóle w pełni sensowne, że deploy’ują cały klaster w banku i to działa.

Łukasz Kałużny: Ciekawe, trzeba będzie zobaczyć, czy ktoś jeszcze znajomy w tych obszarach pracuje, bo jestem ciekaw jak wygląda teraz podłączenie do SWIFT-u.

Szymon Warda: Polecę z jeszcze jednym, bo to był krótki. Blog, uwaga, z 2018 roku, cloudflare’owy, kiedy jeszcze były takie bardzo, bardzo mięsiwe. Jak tam trafiłem? To jest długa historia, nieważne. Ale opisuje to, w jaki sposób wykorzystują, podkreślam, 2018 rok, eBPF-a XDP do ochrony przed DDoS-em. Czym jest w ogóle XDP? Bo to jest fajne wyjaśnienie i on fajnie naprowadza. To jest możliwość odpalenia filtrów kodu eBPF-owego dużo wcześniej w stosie do łączenia sieciowego. Kiedy? W momencie jak driver dostaje pakiet i jeszcze nic z nim praktycznie nie zrobił. Czyli najwcześniejszy moment.

Łukasz Kałużny: Tak, to jest ten Express Data Path, sprzęt musi go jeszcze wspierać, parę innych rzeczy, bo to jest tam cała…

Szymon Warda: Ale już ruszyłeś, co to wspiera? Od Linuxa 4.8 i musi być wspierany przez drivery. I teraz to jest fajna informacja dla wszystkich, którzy mówią: o pobawimy się. Większość driverów 10 gigabitowych i więcej to już wspiera, więc na lokalnych maszynach może Wam się to nie udać, że tak powiem.

Łukasz Kałużny: Znaczy, raczej jest cała rzecz, z której sobie trzeba zdawać sprawę, że odkąd mamy tyle warstw abstrakcji, bo większość osób, która ma styczność z serwerem, to co najwyżej to będzie wirtualka na VMWare.

Szymon Warda: Tak.

Łukasz Kałużny: A tu schodzimy low level do driverka sieciowego, blisko blaszki.

Szymon Warda: Znaczy dla mnie jeszcze co tam jest ciekawego? Artykuł jest, powiedziałem, długi i mięsisty, naprawdę jest dobry. A jeszcze lepsze są artykuły, które linkują z niego. Od tego całego opisu właśnie w Calico, chyba tam jest dobry opis właśnie o XDP. Ale są też fajne artykuły, ja zawsze je bardzo lubiłem, o tym jak wygląda sprzęt, czyli blachy właśnie Cloudflare’a, jak je testują, jak je upgrade’ują, blachy intelowe i wtedy jeszcze też ARM-owe, już ARM-owe bardziej. Fajny artykuł, szczególnie do poklikania co tam od niego odchodzi, tak że polecam bardzo mocno.

Łukasz Kałużny: Jestem ciekaw tej ścieżki myślowej, której tam dotarłeś.

Szymon Warda: Długa była w odpowiedzi, tak.

Łukasz Kałużny: Dobra. I na koniec, dobra, mieliśmy już ten, bank rozbity, to wróćmy znowu do AI-a. Jest raport od Google’a na temat wykorzystania, jak popatrzymy, wykorzystania generative AI do, jak to można określić, złośliwego wykorzystania generative AI. Jeżeli tam popatrzymy, to grupy przestępcze, hakerskie, jakbyśmy teraz to nazwali, które się próżnią hakowaniem, chociaż nie lubię tego określenia w stosunku do tego…

Szymon Warda: Czy ten artykuł mówi, bo nawet nazywa to bezpośrednio: Iranian backed actors.

Łukasz Kałużny: Tak, Russia linked actors, itd., czyli jasno w tym. I jak popatrzymy są, słuchaj, 4 ten, jak to przebadali, to są 4 takie główne grupy użycia, jeżeli popatrzymy. To jest cały taki research, rozpoznawanie celów, badanie podatności, ogólne informacje techniczne.

Szymon Warda: Czyli [niesłyszalne 00:23:03].

Łukasz Kałużny: Tak, ale to jest pierwsza. Druga, która mnie nie dziwi, tworzenie treści…

Szymon Warda: Oczywiście.

Łukasz Kałużny: I personalizacja treści.

Szymon Warda: To jest wykorzystane bardzo mocno w kampaniach reklamowych w Stanach Zjednoczonych, do tego stopnia, że tam jest per chyba do kilkuset użytkowników jest tworzona treść praktycznie, bardzo duże użycie.

Łukasz Kałużny: Tutaj masz pod całe kampanie phishingowe i inne rzeczy, że możesz hyper personalizację zrobić. Potem trzecia rzecz to próba w kodowaniu PoC-ów, exploitów i innych rzeczy. No mnie nie dziwi i nie dziwi mnie to, bo to jest…

Szymon Warda: Do PoC-ów tak.

Łukasz Kałużny: Tak, żeby przygotować na bazie jakiegoś poznanego CFE przygotować PoC-a. Kurde, to tak, jest to game changer w kodowaniu, w przyśpieszeniu takiej realizacji i testowaniu. No i ostatnie, to jest trochę z generowaniem treści, ale lokalizacja treści dla różnych odbiorców.

Szymon Warda: Naprawdę, jeżeli chodzi o tłumaczenie tekstu, działa świetnie…

Łukasz Kałużny: I personalizacji.

Szymon Warda: [Niesłyszalne 00:24:05] cokolwiek innego.

Łukasz Kałużny: Tak, dlatego mówię w tym. ,I Iran jest jak tam popatrzymy, w tym, Iran linked, ten powiązanie z Iranem są największym tym. I oni właśnie tworzenie ten w tworzeniu kampanii phishingowych, generowaniu treści, badaniu podatności i innych takich rzeczy. Chiny w rozwoju skryptów i rozwiązywaniu problemów z kodem plus potem skupienie się na ruchach bocznych, czyli litera movement, eskalacji uprawnień i innych tego typu rzeczy. Korea Północna w różnych cyklach kompleksowo używała. Z Rosją, ograniczenie korzysta.

Szymon Warda: Ciekawe czemu?

Łukasz Kałużny: I teraz…

Szymon Warda: Bo [niesłyszalne 00:24:51] raczej wątpię.

Łukasz Kałużny: I w tym, jeżeli chodzi w ogóle o takie operacje informacyjne całych tych, to Iran stanowił trzy czwarte tego, co wykryli. Jeżeli chodzi w ogóle o research.

Szymon Warda: To jest dużo, bardzo dużo.

Łukasz Kałużny: Tak, dostali pierwszą pozycję w ogóle w raporcie, jak się popatrzy. A druga sprawa, że prób jblake’owania, tak jak ze swojej perspektywy, nie mają aż tak dużo, co jest ciekawe, że nie jest to jakaś znaczna… Inaczej, próby są, ale to nie jest jakaś znacząca rzecz w przeciwieństwie do tego, o czym mówi reszta raportu.

Szymon Warda: Okej, dobra, to teraz przeciągamy, no może trochę na Kubernetesa, ale nie do końca. Ja znowu eBPF-y, bo jakoś taka cała seria się wysypała, ale całkiem ciekawe użycie. Bo oczywiście wiemy, tam eBPF-y sprawdzają bardzo fajnie i sieciówka, wszystkie profilery, itd.

Łukasz Kałużny: Observability, bezpieczeństwo, jest ileś pomysłów.

Szymon Warda: Tak, dokładnie, to tu jest całkiem ciekawy artykuł: Rethinking system architecture the rise of distributed intelligence with eBPF. O co chodzi? Jak nawet duża korporacja będzie miała systemy, CIEM-y, do obserwacji co tam się na naszych maszynkach dzieje, czy ktoś coś, czegoś nie wstrzyknął, czy nie mam jakiegoś podejrzanego ruchu, czy coś się dzieje, po prostu obserwowanie. I dotychczasowo te systemy były scentralizowane i tam wszystko było wysyłane do nich, itd. A tu jest trochę nowe podejście, żeby właśnie korzystać z eBPF-ów do monitorowania tego ruchu, żeby bardziej to rozproszyć. Czemu? No właśnie jest kilka faktycznie dobrych argumentów. Po pierwsze, szybszy czas reakcji, to jest na pewno, bo w tym momencie nie musimy czekać na wysłanie, przeanalizowanie, itd., eBPF może zrobić to szybciej. Lepszy podgląd, mniejsza latencja, zmniejsza time-to-check, time-to-use, czyli talk to można powiedzieć, tak. Kolejny argument, który przytaczają, który dla mnie jest zabawny, to jest to, że zmniejsza narzut na CPU, bo pracuje w trybie kernela, nie w obszarze użytkownika, czyli userspace. I teraz uwaga, jakie są liczby, z 3,6 CPU na 0,2 i ok, to jest 17 razy szybciej, więc no nieźle. Choć no mimo wszystko to są dalej małe wartości, ale pewnie przy dużej skali i tu mówimy bardziej o dostawcach chmurowych tak naprawdę, może ten obszar, to to może się faktycznie ładnie zbierać.

Łukasz Kałużny: A czy wiesz co, i teraz tylko zobacz, że to jest ciekawa rzecz Szymon, bo ja np. pójdę w zupełnie stronę, z którą trochę się z tym nie zgodzę.

Szymon Warda: Ja też uważam, że to jest zbyt takie różowe podejście.

Łukasz Kałużny: Bo pierwsza rzecz jest taka, że idąc, miałem takiego mieć linka, którego miałem wkleić i w sumie go usunąłem, ale znowu mi pasuje, dzięki Tobie mi teraz pasuje.

Szymon Warda: Jestem wspaniały.

Łukasz Kałużny: Tak, jesteś wspaniały, tak, kocham Cię bardzo, wytrzymuję już z Tobą tyle lat.

Szymon Warda: Nawzajem.

Łukasz Kałużny: Dobra, ale technicznie o co chodzi? Wrzuciłem tutaj, jest Secure Network with Zero Trust. Są tam pryncypia. Microsoft wziął, złapał te wszystkie filary zero trustu przy budowie. I tam jest jedna rzecz, dlaczego mówię, że to jest trochę słabe to w tym? Bo zobacz, że jeżeli pójdziemy, są dwa elementy, które są trudne. Czyli w tym linku, który wkleiłem, mamy podział, tam jest siedem filarów. Czyli pierwsze to jest segmentacja sieci. Drugim są filtrowanie przeciwko znanym, nieznanym zagrożeniom. I trzecie, takie podstawowe, to jest all internal traffic is encrypted. I to są trzy takie podstawowe założenia. I teraz co za tym idzie? Jak popatrzysz na ostatni punkt, przez to, że wszystko jest zaszyfrowane, to tam ostatni punkt: discontinue legacy network security technology. Bo odkąd wszystko lata sobie po TLS-ie, to systemy typu Network Intrusion Prevention, czy inne tam IDP, właśnie IDP, IDS-y na poziomie sieci tracą w ogóle sens domyślnie. Bo zobacz, że jak wszystko lata Ci w tym, to sygnatury są bez sensu na tym poziomie filtrowanie.

Szymon Warda: Ale możesz ten ruch rozpruć mimo wszystko, no nie, korzystać z eBPF-ów.

Łukasz Kałużny: No tak, tylko zobacz teraz Szymon, i teraz powiem Ci złośliwą rzecz, w większości przypadków Ty nie chcesz, żeby dostawca cloudowy Ci w tym miejscu rozpruwał… Inaczej, to jest ta rzecz, z której też większość osób ma problem, jak się dowiaduje, że zobacz jak Cloudflare rozszywa Ci np. ruch i masz dane medyczne, to powinieneś np. z Cloudflerem, czy finansowe, to z Cloudflerem powinieneś podpisać umowę, bo rozszywa Ci ruch i jest procesorem Twoich danych.

Szymon Warda: Tak, moje podejście do tego artykułu jest takie, bo on jest bardzo futurystyczny. Pokazuje bardzo różową wersję przyszłości, że tak będziemy mogli robić, że wszystko rozproszymy, będzie zdecentralizowany, scentralizowane jest złe i w ogóle, w ogóle, w ogóle. Czyli to wychyla to wahadło w drugą stronę aż za bardzo. Według mnie eBPF-y znajdą tu jakieś zastosowanie, bo one mają sens, ta minimalna retencja, wykrywanie takich najbardziej prostackich, prostych, to będzie działało.

Łukasz Kałużny: Wiesz co, np. obserwowanie tego, co procesy robią na dysku.

Szymon Warda: Tak.

Łukasz Kałużny: To będzie ciekawe, tak, bo tego, co nie powiedzieliśmy, bo my skupiamy się przy eBPF-ach na sieciówce, a wszystko w Linuksie, co jest device’em, w teorii może być to zrobione do tego stopnia, bo oczywiście jak sobie popatrzymy na tą złą stronę zastosowań, to jak sobie weźmiemy, wpiszecie trojan horse eBPF albo ransomware eBPF, to już znajdziecie, że już takie próby są, żeby wykorzystać w tym. Tak, eBPF, a new frontier for malware. Więc zostawię linka do tego.

Szymon Warda: Tak, ogólnie rzecz biorąc czeka nas hybryda. I hybryda ma tu sens. Z reguły ten środek między dwoma wychyleniami się sprawdza. Fajne użycie. A odnośnie tego, co powiedziałeś, właśnie analiza plików, itd., no to będzie o tym w kolejnym odcinku, bo też coś fajnego się wydarzyło, ale to na kolejnego shorta, że tak powiem, za tydzień.

Łukasz Kałużny: Dobra. Zamykamy, trzymajcie się.

Szymon Warda: Heja.