W najnowszym odcinku Bezpiecznego Kodu skupiamy się na praktycznym podejściu do cyberbezpieczeństwa, analizując, jak skupić się na realnych zagrożeniach, zamiast na szumie informacyjnym. Poruszamy temat szyfrowania danych w spoczynku („Encryption at Rest”), wyjaśniając, dlaczego jego nadmierne podkreślanie może odwracać uwagę od znacznie groźniejszych podatności aplikacyjnych, takich jak SQL Injection czy RCE. Podkreślamy znaczenie priorytetyzacji ryzyka i obalamy mity dotyczące uniwersalnych rozwiązań bezpieczeństwa.
Dalej omawiamy realny wpływ ostatniej podatności PHP CGI na Windowsie (CVE-2024-4577), wskazując, że jej zastosowanie jest mocno ograniczone, a wysokie wskaźniki CVSS nie zawsze oznaczają powszechne zagrożenie. Przedstawiamy również złośliwe rozszerzenia w Visual Studio Code, które stanowią podstępne zagrożenie dla programistów. Na koniec, dla zwiększenia bezpieczeństwa potoków CI/CD, rekomendujemy „pinowanie” GitHub Actions do konkretnych commitów, co jest kluczowe dla DevOpsów i Security Engineerów. Ten odcinek to niezbędne źródło wiedzy dla wszystkich, którzy dążą do efektywnego zarządzania bezpieczeństwem w swoich projektach IT.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Andrzej: Dzień dobry, dzień dobry. Witamy w kolejnym odcinku podcastu Bezpiecznego Kodu w formacie, w którym omawiamy ciekawe rzeczy, które wpadły nam na przestrzeni ostatnich tygodni, rzeczy, które się wydarzyły w techu. Głównie skupiamy się tutaj na bezpieczeństwie, no ale bezpieczeństwo nie jako cyberbezpieczeństwo jest mocno powiązane z techem. Kolejny raz z Krzysztofem. Krzysiu powiedz, co tam u Ciebie?
Krzysztof: Cześć, witajcie, no bardzo dobrze, chociaż wstaliśmy dosyć wcześnie, może nie wcześnie, ale wstaliśmy rano w niedzielę, żeby to nagrywać. Andrzej, także docencie, albo przynajmniej dajcie łapkę w górę.
Andrzej: Tak, docencie nasz effort. Tutaj trzeba było wstać przed ósmą, no bo po ósmej już zaczynaliśmy nagrania. Jak to zwykle bywa, narzędzia potrafią zawodzić, więc tutaj też mieliśmy małe potyczki z narzędziami, ale na szczęście wszystko już zażegnane i można przychodzić do mięska, można nagrywać. Krzysiek. Mamy kilka ciekawych rzeczy, które się wydarzyły w ostatnich dniach, w ostatnich tygodniach. Ja widziałem tytuł tego, co wrzuciłeś na swój pierwszy kąsek. Przyznam się od razu, że nie miałem czasu, żeby przeczytać ten artykuł, bo nie jest krótki, jest rozbudowany. Natomiast tak szybko go przeskanowałem i wydawał się bardzo ciekawy, tym bardziej, że kojarzę autora tego artykułu. Nie będę odbierał Ci przyjemności wchodzenia tutaj w to, o czym mówię, więc przekazuję Ci pałeczkę i wchodź. Przedstaw czytelnikom, co Ci wpadło w ręce w zeszłym tygodniu.
Krzysztof: Ok, także w ręce w zeszłym tygodniu wpadł mi bardzo ciekawy artykuł autorstwa Skota Arciszewskiego. Ja Skota Arciszewskiego poznałem może nie osobiście, ale poznałem go poprzez jego bibliotekę Cypher Suite, która umożliwia zaimplementowanie szyfrowania na poziomie konkretnego pola w bazie danych z możliwością wyszukiwania, co nie jest wcale takie trwialne. No i kiedyś musiałem rozwiązać ten problem u klienta, bo musiałem im przedstawić taki proof of concept z zespołem. I właśnie wtedy w pierwszy raz spotkałem się z twórczością Skota Arciszewskiego i jak odnalazłem ten artykuł to szybko powiązałem, że jest jego autorem. Artykuł nosi nazwę Encryption at Rest. Whose threat model is it anyway? Myślę Andrzej, że tobie się bardzo spodoba, bo to jest bardzo takie realne spojrzenie na kwestie związane z cyberbezpieczeństwem. No i właśnie, szyfrowanie w spoczynku. Zastanówmy się krótko. tak naprawdę przed jakimi zagrożeniami w kontekście aplikacji webowych chronisz szyfrowanie danych w spoczynku? i załóżmy, że dotyczy to stricte środowisk chmurowych, czyli postujemy tą aplikację, całą infrastrukturę dookoła tej aplikacji, czy to na AWS, czy na GCP, czy na Azure, czy na jeszcze jakichś innych pomniejszych dostawcach chmury. Jakie jest główne zagrożenie tak naprawdę w takim, w takiej sytuacji? No można sobie w takim modelu zagrożeń wylistować zagrożenie związane z tym, że ktoś kradnie nam dysk z datacenter, no i tak naprawdę w tym momencie kończą mi się takie pomysły, które mam gdzieś z tyłu głowy, co się może stać i przed czym to szyfrowanie danych w spoczynku w chmurze mogłoby nas chronić. No chyba, że mówimy o naprawdę jakichś takich odjechanych modelach zagrożeń, w których uwzględniamy, że zagrożenie może pochodzić od np. pracowników chmury i np. w AWS-ie Zespół, który pracuje nad rozwojem feature’a w kontekście serwisu S3 dogada się z zespołem, który jest odpowiedzialny za AWS KMS, gdzie przytrzymywany jest materiał kryptograficzny, którym szyfrowany jest na przykład bucket. ale te dwa zespoły tak naprawdę pracują niejako niezależnie. Ten rozdział obowiązków jest dosyć silnie izolowany. No i jakoś znajdą się dwie osoby z tych dwóch różnych zespołów, które razem będą chciały pójść po nasze dane, co wydaje się dosyć abstrakcyjne, przynajmniej dla mnie.
Andrzej: Krzysiek, ja mam teraz pytanie, bo powiedziałeś, że jest to jedno zagrożenie, które od razu ci się rzuca na myśl, czyli sytuacja, w której ktoś kradnie dysk, kradnie generalnie storage, ale co w takim wypadku… No bo mi się rzuca pierwsze kolejne od razu, czyli ktoś się włamie do tej naszej web aplikacji, czyli typowa sytuacja. Mamy jakąś web aplikację, która jest w chmurze. Ta web aplikacja korzysta z jakiegoś storage’u, czy na file systemie, czy na bazie danych, czy w jakiejś z jakiejś usługi wewnątrz danej chmury, która jest dostarczana przez tego prowidera i dedykowana dla klientów. No i jeśli ktoś zhakuje tą aplikację, no powiedzmy, żeby nie musiał dużo tutaj myśleć, niech będzie jakaś podatność która pozwala na wykonanie zdalnego kodu i atakujący jest w stanie dostać się na web server. Niech to będzie zwykły command injection, że ja jestem w stanie mieć dostęp do, już nawet nie będzie konsoli linuxowej. No to takiego czegoś nie powinniśmy tutaj wziąć pod uwagę?
Krzysztof: W naszym modelu zagrożeń?
Andrzej: Dla tych naszych danych.
Krzysztof: Tak, jak najbardziej. I właśnie to jest całe sedno tego artykułu, że skupiamy się tak mocno na takich abstrakcyjnych zagrożeniach związanych z fizycznym wykorzystaniem, zabraniem tych dysków, tego storage’u. A totalnie zapominamy o tym, że tak naprawdę na brzegu stoi nasza aplikacja. Jeżeli w naszej aplikacji, tak jak mówisz, mamy podatność związaną z injection, czy to będzie SQL injection, czy to będzie po prostu jakiś RCE, command injection, czy nawet zwykły IDOR, to te dane i tak zostaną zwrócone do atakującego. postaci odszyfrowanej. To tutaj nie zmienia w ogóle to, że szyfrujemy dane w spoczynku, nie zmienia tego, że jesteśmy odporni na tego typu ataki, a właśnie tak Skot Arciszewski przedstawia ten problem tego, że mamy takie klapki na oczach i włączamy na ślepo to szyfrowanie danych w spoczynku, Myśląc o tym, że w zasadzie załatwia nam to problem całego bezpieczeństwa informacji albo ściąga z nas jakiś efort, który musimy zrobić w kontekście zarządzania bezpieczeństwem aplikacji. Więc tak Andrzej, no tutaj w kontekście injection, w kontekście nieopodalności w aplikacji szyfrowanie danych w spoczynku, tak jak ładnie jest pokazane tutaj na tym memie, zmienia tak naprawdę niewiele. Dlatego jeżeli szyfrujecie Wasze EBSy w kontekście np. AWS-a, które są podpięte pod Wasze instancje EC2, no to jeżeli faktycznie zależy Wam na tym szyfrowaniu danych w spoczynku, no to trzeba też pójść troszeczkę dalej i rozszerzyć ten model, jeżeli faktycznie zależy Wam na tym, żeby te dane były były bezpieczne uwzględnić aplikacje, ale powiem więcej, jeżeli chodzi o szyfrowanie danych w spoczynku, to faktycznie ma to sens w kontekście takiej ciągłej, też w kontekście ciągłej weryfikacji, no bo jeżeli stawiamy naszą infrastrukturę powiedzmy z terraforma, no to warto byłoby się upewnić, że ktoś nie stworzy takiego zasobu, który jest po prostu nieszyfrowany, czyli mówimy tutaj np. o podejściu compliance as a code, tak? Więc samo włączenie na jednym EBSie szyfrowania też nas tutaj nie zabezpiecza. Ten artykuł bardzo mi się spodobał. Możecie sobie go ekstrapolować oczywiście, jeżeli pracujecie na GCP czy na żurze na wasze, na wasze usługi, ale podoba mi się w nim to, że tutaj Scott bardzo realnie podchodzi do tego w jaki sposób powinniśmy myśleć o bezpieczeństwie, bo czasami widzimy osoby, które po prostu krzyczą, nie, musisz włączyć szyfrowanie danych w spoczynku, bo wszyscy tak robią, przecież bezpieczeństwo informacji i tak dalej. A tak naprawdę większości u takich osób zamyka to dyskusję, no dobra, ale co dalej, a co z naszym aplikacją, tak, a co jeżeli będziemy mieli IDORA i ktoś się po prostu przeiteruje, bo mamy gdzieś tam problem z kontrolą dostępu na jednym endpointie i wyciągnie dane naszych użytkowników, tak, więc tutaj Bardzo mocno skróciłem ten artykuł, on jest oczywiście dużo dłuższy, tutaj Scott mówi też o całym podejściu związanym z kryptografią, jak już faktycznie chcemy porządnie podchodzić do szyfrowania danych z poczynku, to jak to robić w kontekście tutaj stricte AWS-a, bo On z AWS pracował. Odsyłamy do tego artykułu. Bardzo polecamy, bo otwiera oczy. Mi na pewno otworzył. Ja o tym problemie już słyszałem i kiedyś czytałem na temat tego, że szyfrowanie danych w spoczynku powoduje takie troszeczkę, taką wizję bardzo wąską na ten problem, ale tutaj po raz kolejny mi otworzyło to oczy.
Andrzej: No tak, po prostu jest przedstawiany jako panaceum na wszystkie problemy, a końcem końców rozwiązuje jeden pojedynczy problem związany z bezpieczeństwem i problem, który tak naprawdę ryzyko jest dość małe, bo ryzyko, że ktoś wejdzie do serwerowni, wykradnie dysk twardy, albo że pracownicy tej serwerowni, ja nie wiem czy ktokolwiek miał okazję widzieć jak te serwerownie, szczególnie od dostawców publicznej chmury są zabezpieczone, ale to nie jest tak, że ktokolwiek może sobie tam wejść, tam są normalne ACL-ki. takie fizyczne, nie da, to nie jest taki piece of cake, musieliby być pracownicy, a ci pracownicy też na pewno są prześwietlani przez pracodawcę, Tutaj pamiętam, że Google miał kiedyś taką fajną miniserię wideo właśnie o tym jak wygląda u nich bezpieczeństwo fizyczne w GCP. Mega polecamy. Podeślamy link w referencjach. Natomiast to nie jest tak, że ktokolwiek może sobie tam wejść i ten dysk ukraść. to raz. więc nie może wejść ktokolwiek, mogą wejść tylko odpowiednie osoby i jest to pilnowane, to raz, a dwa, nawet idąc dalej, gdybyśmy mieli tych pracowników, czy to AWS-a, czy GCP, czy Azure-a, to nie jest, czyli dowolnej innej chmury, to nie jest tak, że ktokolwiek może tam zacząć pracować, ci ludzie na pewno są prześwietlani i raczej zostałoby to prędzej lub później, ale zostałoby takie wykroczenie wykryte. Przy czym, tam wspomniałeś taki keyword o krzyczących, krzyczących, krzykaczach, o krzyczących bezpiecznikach, to wiesz co, to się trochę łączy z tym, z tym moją, moją perełką, która, która mi wpadła i która, można powiedzieć, grinds my gear od, od zawsze, czyli krzyczenie bezpieczników, robienie, robienie szumu. w którym realny sygnał po prostu ginie i z mojej perspektywy wprowadza więcej problemów niż ich rozwiązuje. I tutaj mam na myśli ostatnią podatność. która została wykryta w PHP, konkretnie w PHP, które działa z PHP CGI, konkretnie w środowisku Windowsowym i jeszcze z Apache. Natomiast tego ile się nasłuchałem w ostatnich dniach, wywodów na Linkedinie, najczęściej na Linkedinie i niestety, ale od naszych polskich gwiazd, o tym jaka ta podatność jest krytyczna i że trzeba o niej napisać posta. Trudno mi się po prostu na to patrzeć. Trudno mi znaleźć odpowiednie słowo, ale nie lubię tego. Nie lubię tego dlatego, że przesłania to widok na problemy, które wprowadzają realne ryzyko do naszej organizacji. Czemu? Bo po prostu jeśli mamy pięć tysięcy krytykali, to żaden nie jest krytyczny. Z założenia, nie możemy mieć pięć tysięcy problemów, które są krytyczne. Tak samo jak nie możemy mieć na liście zadań dziesięciu zadań, które mają priorytet najwyższy. Priorytet by definition może być przypisany tylko do jednego zadania. Czemu? No bo to zadanie jest priorytetowe, więc ono musi zostać wykonane przed wszystkim innymi. Nie możemy mieć trzech zadań priorytetowych, bo wtedy nie wiemy, co mamy zrobić. To musielibyśmy priorytetyzować priorytet. I tak samo z podatnościami. Nie możemy mieć dziesięciu podatności, które są krytyczne. Zawsze jakaś będzie bardziej krytyczna i należałoby od niej zacząć. Na pewno nie będą. A jeżeli trudno jest nam określić, która jest najważniejsza, no to po prostu zróbmy wszystkie jak najszybciej, wtedy nie przejmujemy się kolejnością, ale muszą być wyprowadzone wszystkie te. Natomiast priorytetem i krytycznością raczej powinniśmy zarządzać tak, że zawsze jest tylko jeden element, który ma priorytet lub który ma krytyczność. No i jeśli mamy takie problemy właśnie jak CV2024-4577, problem związany na poziomie PHP, więc to nie jest problem, który jest w skryptach PHP, ale problem, który jest na poziomie interpretera PHP. który dotyczy bardzo małego wąsku, bardzo małego wycinka systemów, instalacji, które są ogólnie dostępne na świecie i on może być od strony technicznej bardzo ciekawy, ale pomijając to, jak bardzo ciekawy jest od strony technicznej, jeśli ten problem dotyczy tylko pewnego, wybranego, małego wycinku ogólnych systemów IT, przy czym nawet nie dotyczy wszystkich wersji tylko określonych wersji PHP, to robienie szumu wokół takiego problemu jest po prostu nie do końca na miejscu, bo robiąc taki szum, niejako możemy dokładać ludziom pracy. Podam konkretny przykład. Miałem sytuację, w której byłem w zespole bezpieczeństwa w jednej dużej organizacji i w momencie, gdy niebezpiecznik napisał o jednej podatności, to wszyscy zostali postawieni, Był ogłoszony alarm, wszyscy zostali postawieni do pionu i zespół IT odpowiedzialny za infrastrukturę musiał zacząć patchować, dlatego że jedna z osób decyzyjnych czyta niebezpiecznika i uznała, że to co mówi Piotrek, no to trzeba faktycznie tutaj wszystko zatrzymać i zaktualizować. No nie, akurat problem nie był na tyle ważny, żeby to zrobić. O ile dobrze pamiętam, około dwóch dni zajęło wyjaśnianie tego, że nie, nie trzeba wszystkie zatrzymywać, lećmy dalej, a to po prostu się zaktualizuje w normalnym cyklu patchowania, a nie w drodze wyjątku. A wszystko dlatego, że Niebezpiecznik postanowił napisać artykuł o podatności, która nie była wcale jakoś super ważna. I oczywiście na końcu, na końcu artykułu, bo po prostu to był artykuł bardziej taki sprzedażowy, patrzcie jest taka podatność, a przy okazji to tutaj można kupić szkolenie. I nie ma problemu, ja nie mam problemu z tym, żeby, żeby pisać taki content, no bo niejako on pozwala potem tworzyć i też nie chodzi mi tutaj, że niebezpiecznik, żeby naskakiwać na niebezpiecznika, bo niebezpiecznik robi świetną robotę pod kątem pod kątem awareness’u ogólnie związanego z cyberbezpieczeństwem, bardzo szerokiego. Więc tutaj Piotrek, świetna robota, jest naprawdę bardzo dobrze, jeszcze na tle konkurencji jest mega. Tylko należy czasami wziąć pod uwagę, że słowa szczególnie bardzo dużych portali związanych z cyberbezpieczeństwem są czytane przez gdzieś tam dyrektorów i jeśli trochę polecimy po bandzie i napiszemy, że coś jest bardziej krytyczne niż faktycznie jest, no to ma potem przełożenie na realny koszt, który organizacja musi ponieść. Więc jak w Spidermanie, with great power comes great responsibility. I tak samo tutaj, jeśli mamy duży kanał dystrybucyjny to powinniśmy przywiązywać większą uwagę do tego co mówimy, bo jeśli nie będziemy tego robić to generujemy realne koszty, nawet w takiej postaci, że ktoś potem musi po prostu wyjaśniać. że nie, możemy zrobić to w normalnym cyklu. I tak samo jest tutaj z tym PHP. Ja jestem pewien, że są organizacje, tak jak w przypadku niebezpiecznika, na pewno są organizacje, które musiały, musiałyby wszystko zatrzymać i wyprowadzić tą podatność ze swoich systemów IT w takim, w drodze wyjątku. Czyli nie iść tym normalnym procesem vulnerability managementu, ale zrobić to w drodze wyjątku. Natomiast najpierw należyłoby zadać pytanie czy my jesteśmy taką organizacją i to samo tutaj w PHP. czy my faktycznie mamy PHP, który jest serwowany na Windowsie, raczej nie.
Krzysztof: W trybie CGI, nie?
Andrzej: Tak, dokładnie.
Krzysztof: Jeszcze chyba trzeba mieć ustawione bardzo konkretne lokale, nie wiem czy chińskie, czy japońskie, coś tam takiego było.
Andrzej: Tak, były te lokale. Natomiast, o ile dobrze kojarzę, to oryginalni researcherzy nie wykluczyli, że to jest precondition, że to jest requirement, tylko powiedzieli, że dlatego po prostu testowali. A czy to faktycznie jest takie wymaganie, to może nie. To można sobie samemu przetestować. Do diligence. Natomiast lekcję, jaką tutaj wyciągnął po raz kolejny, a może ja ją po prostu znam, lekcją, którą chciałbym zaprezentować naszym słuchaczom, to wracamy po prostu do analizy ryzyka. I to, że jakaś podatność ma krytyczność względem CBSS 10, to wcale nie oznacza, że ta sama podatność wprowadza ryzyko dla naszej organizacji na poziomie high czy critical i że musimy teraz wszystko rzucić i zacząć tą podatność wyprowadzać. jedno z drugim jest połączone, ale nie jest połączone mocno, jest połączone luźno i raczej należałoby uwzględnić kontekst całościowy poprzez wykonanie oceny eksperckiej, a nie, a nie jedynie, że o dobra, to ta podatność ma 10 w CVSS, to teraz musimy ją wyprowadzić, pomimo tego, że nawet nas nie dotyczy, bo kurcze nie, bo nie mamy PHP na Windowsie, więc Po prostu czytając, przeglądając feed związany z Vulnerability Intelligence powinniśmy tutaj nadawać krytyczność względem kontekstu, który jest ważny dla naszej organizacji. i raczej nie powinniśmy patrzeć chłodno, zimno na to, co piszą różne portale związane z cyberbezpieczeństwem, bo w grze, w teorii gier jest coś takiego jak aligned incentives i te portale nie zawsze mają wyrównane incentywy co do naszych biznesowych. Jeśli one mają inne incentywy, a my kierujemy się tym, o czym one piszą, no to niekoniecznie wykonamy optymalną akcję, która jest optymalna dla nas jako organizacji. Więc najpierw powinniśmy patrzeć na to, co my robimy i czy faktycznie dana podatność, dany problem nas dotyczy, następnie jak mocno nas dotyczy, a dopiero potem podjąć decyzję, czy chcemy coś z tym zrobić, czy nie. I tego trochę na rynku brakuje, no a takie Takie sianie paniki niestety nie pomaga i tylko wszystkim niepotrzebnie dodaje pracy. Więc to jest taki przydługawy wywód na temat tej podatności PHP, która tak naprawdę sama z siebie nie jest tutaj ważna, ale to jest coś, co naprawdę bardzo mocno mnie mierzi. w środku, dlatego że ja po prostu wiem, ja znam to od środka, z perspektywy organizacji, ja wiem jak mocno takie sianie paniki potem jak dużo generuje pracy w zespołach związanych z cyberbezpieczeństwem. i pracy, która mogłaby być po prostu przełożona w jakieś inne obszary, które faktycznie wymagają zaopiekowania się nimi, a nie gaszenia pożarów, które tak naprawdę w zasadzie nawet nie są pożarem, tylko zapałka się zapaliła i zaraz się wypali.
Krzysztof: Tak, ja tylko dodam bardzo króciutko, że oczywiście jak wszystkie największe portale i w Polsce i na świecie napisały o tej podatności, to bardzo szybko dostałem wiadomość w projekcie, w którym pracuję, że o nie, teraz trzeba szybko sprawdzić, czy nie mamy gdzieś tej wersji PHP i w ogóle na serwerach, bo przecież zobacz, a oczywiście to było podyktowane tym, że został przeczytany tylko headline, że o nie, miliony urządzeń na świecie zaafektowane, bo PHP, a jak się wgryzło w treść artykułu i gdzieś tam drobnym maczkiem napisane, że no tak, ale tylko na Windowsie, tylko w trybie CGI i tylko jeszcze jak coś tam. No to do widzenia. Ale sama podatność bardzo ciekawa. No i oczywiście Orange Tsai, bo to bodajże on jest autorem tego znaleziska. No to Shapoba, bo po raz kolejny pokazuje szczyt swoich możliwości.
Andrzej: Nie jestem pewien czy Orange Tsai.
Krzysztof: Wydaje mi się, że tak.
Andrzej: Patrzę na, patrzę na stronę i na pewno DEFCOR i Orange Tsai pracuje w DEFCORze. Natomiast nie jest tutaj wylistowany jako, jako autor, przynajmniej jako autor artykułu, więc tutaj ręki sobie nie dam uciąć. Ale tak, na pewno DEFCOR, a DEFCOR to firma, w której Orange Tsai pracuje. A Orange Tsai to jest taki bardzo, bardzo mega ogarnięty security researcher, który Bardzo, bardzo dużo ciekawych rzeczy na przestrzeni ostatnich lat wypuszczał. Nie tylko podatności, ale też całych badań dla klas podatności, więc polecamy zaznać się z jego pracą, jeśli ktoś jest zainteresowany bezpieczeństwem aplikacji webowych.
Krzysztof: Dokładnie. Okej, no to wskakujemy w kolejny artykuł, kolejne znalezisko. Tym razem chciałbym powiedzieć o czymś, co może nie, że mnie lekko zszokowało, bo słyszałem już o tej powierzchni ataku na deweloperów, ale zaciekawiło mnie, bo Badacze bezpieczeństwa wzięli na celownik marketplace rozszerzeń, pluginów do bardzo popularnego IDE Visual Studio Code. Ja nie wiem Andrzej, z jakiego ty IDE korzystasz. Ja korzystam z Visual Studio Code. Może dlatego mnie to zaciekawiło.
Andrzej: Ja korzystam również z Visual Studio Code, natomiast tak się trochę przerzucam pomiędzy VS Code a Vimem, ale jeśli miałbym gdzieś tam prowadzić statystyki to raczej chyba więcej siedzę w VS Code.
Krzysztof: Okej. No więc jeżeli korzystasz z VS Code’a no to wiesz, że ma bardzo bogaty ekosystem rozszerzeń, które dodają wiele ciekawych funkcjonalności. Do tego idę. No i też ma dosyć bogaty marketplace związany z motywami graficznymi, które możesz sobie do tego VS Code’a zaaplikować. No i badacze postanowili się podszyć pod popularny motyw graficzny Drakula. i stworzyli rozszerzenie, rozszerzenie motyw o nazwie Darkula, więc bardzo popularna technika typo spotingowa, w której po prostu robimy to typo, żeby pomylić, pomylić ofiarę. No i BSK udostępnia taki mechanizm, który nazywa się Verified Publisher. i żeby zostać tym Verified Publisherem, no to musisz pod ten plugin, który pchasz do Marketplace’u podpiąć swoją stronę internetową i zweryfikować, że ta strona, ta domena należy do ciebie. No to na tą domenę w DNS-ie musisz wypchnąć rekord tekstowy z kodem weryfikacyjnym, który podaje ci VS Code, więc To jest cały proces tego, w jaki sposób można zostać Verified Publisherem. Z pewnego punktu widzenia to ma to sens, ale z punktu widzenia znaczenia tego słowa, verified publisher, no to odbiorca, potencjalna osoba, która może instalować takie rozszerzenie, może mieć z tyłu w głowie, okej, no to jest zaufany, to jest ktoś zaufany, to jest ktoś sprawdzony, a nie wie, że to sprawdzenie polega tak naprawdę tylko na tym, że trzeba dodać rekord w DNS-ie. Więc taka ciekawostka, w jaki sposób można zostać verified publisher w VS Code Marketplace. Fałszywe rozszerzenie, rozszerzenie. motyw Darkula robiło dosłownie to samo, co robi, co robi motyw oryginalny Dracula, no ale dodawało jeszcze kilkanaście linijek kodu, które z systemu, na którym było instalowane na hoście, zbierało kilka informacji dotyczących tego środowiska, w którym zostało zainstalowane i wysyłało request HTTP na serwer badaczy. W ten właśnie oto sposób badacze wiedzieli, że jest jakiś ruch związany z instalacją tego motywu. I tutaj fajnie wypunktowane, że wszystkie fancy toole dotyczące bezpieczeństwa typu Endpoint Detection and Response są totalnie ślepe na tego typu ataki, czyli jeżeli instalujemy sobie jakieś rozszerzenie przez VS Code, no to VS Code jest tak zbudowany by definition, by default, że on ma odczytywać jakieś pliki, on ma możliwość uruchamiania procesów potomnych, Dlatego EDR-y, cała ta śmietanka systemów dotyczących bezpieczeństwa endpointów, nie mogą zrozumieć, czy ta aktywność, którą podejmuje VS Code jest złośliwa, czy jest legitna. To jest dosyć duży problem, który został wypunktowany w tym artykule. I tak, całe badanie zakończyło się tym, że udało się zainfekować tym złośliwym, potencjalnie złośliwym rozszerzeniem motywem 1300, tak, 1300 organizacji. I w tych 1300 organizacjach znalazły się naprawdę bardzo duże firmy o dużej kapitalizacji. Także jak widać no ten problem gdzieś tutaj się odbija dosyć szerokim echem. No i na kanwie tego badania powstało już oczywiście cały tool, który nazywa się Extension Total, który ma za zadanie bronić programistów przed instalacją złośliwych rozszerzeń. Na razie stricte do VS Coda.
Andrzej: Tak, w ogóle nie słyszałem o tym ataku, nawet mi się nie przewinęło przez moje feedy, więc fajnie, że o tym wspomniałeś, sam się czegoś nauczyłem, natomiast o samym ataku Poprzez rozszerzenia do VS Code oczywiście słyszałem, bo to nie jest nic nowego, ale o tej właśnie nowej iteracji, żeby tutaj podszyć się pod FIM, jeszcze faktycznie Draculi, gdzie ten FIM jest naprawdę bardzo szeroko używany. No to jest sprytne, ale atakujący i badacze zwykle wykazują się sprytem.
Krzysztof: Tak, myślę, że tutaj warto dla naszych słuchaczy po prostu podkreślić to, że nie możemy bezgranicznie ufać temu, co instalujemy z tego typu marketplace’ów i że tam też czyhają na was zagrożenia, więc warto być ostrożnym.
Andrzej: Tak, albo tutaj głównie chodzi o to, żeby podejmować decyzje świadomie względem tego czego używamy, a nie żeby nie korzystać z VS Code. Oczywiście korzystajmy. VS Code chyba ma też taką możliwość. On tam ma już dodatkowe jakieś takie zabezpieczenia. Pamiętam, że kiedyś przykładowo nie pytał cię o to, czy w danym katalogu może wykonywać wszystko. Teraz już pyta, więc też tutaj gdzieś tam to bezpieczeństwo dla deweloperów, którzy korzystają z VS Code jest wprowadzane do tego narzędzia. Cyberbezpieczeństwo to zabawa w kotka i myszkę, więc tu coś wprowadzimy, tam ktoś coś obejdzie, znowu coś wprowadzimy, znowu ktoś coś obejdzie. i tak takie przerzucanie takiej piłeczki, no ale jednak VS Code chyba sam z siebie. Jakiś dużo ataków na przestrzeni ostatnich lat ja nie widziałem poprzez VS Code, czy kojarzysz coś takiego?
Krzysztof: samych podatności w VS Code czy ataków na jakiś ekosystem, bo na pewno z racji tego, że VS Code jest napisany w elektronie, to było bardzo kilka ciekawych podatności, które wynikały z samego elektrona, który jest, który jest, stoi, jakby jest fundamentem dla dla VS Coda, czyli wyskakiwanie z sandboxów, remote code, execution, bodajże przez importowanie workspace’ów. Było kilka na pewno takich bardzo ciekawych rzeczy, o których czytałem, bardzo mocno zaawansowanych, ale też dla samego odbiorcy ciekawych. Postaramy się podlinkować na pewno w opisie tego odcinka.
Andrzej: Dobra, Krzysiek. Od tego akurat się nie da uciec w tym tygodniu. Ja wziąłem ten temat na klatę. Może inaczej. Ja go wpisałem, że ja o nim zacznę, ale tutaj myślę, że będzie większa dyskusja. Apple Intelligence, AI. Po pierwsze, szapowa za stworzenie swojego skrótu z wykorzystaniem AI. Teraz to już nie jest Artificial Intelligence, to jest Apple Intelligence. Tutaj akurat nie było trudne to stworzenie, więc niejako nazwa firmy Plus Intelligence akurat robi nam skrót AI, ale jednak, że to że mieli, że mieli na tyle jakiejś takiej, nazwijmy to, bycia pewnym siebie, że faktycznie poszli w to i nazwali Apple Intelligence, no, czapka z głów.
Krzysztof: Ja myślę, ja myślę, że to jest taki mały pstryczek w nos dla Google’a, który podczas swojej konferencji Google I.O. nawet były takie kompilacje, w których zliczano ile razy zostało wymienione słowo AI właśnie w kontekście Artificial Intelligence. tak, więc Apple tutaj wychodzi i mówi nie, nie Artificial Intelligence, tylko Apple Intelligence.
Andrzej: No, jeśli ktoś o tym pomyślał i to jest, we need to go deeper, to tym bardziej, to tym bardziej, szefoba. No, ale dobra, no to w końcu AI nadra, nie AI właśnie, już, ja już, już mi weszli do głowy, Incepcja. Apple w końcu nadrabia zaległości związane z AI-em, z agentami, z budowaniem całego capability do swojego ekosystemu, do wszystkich w zasadzie systemów, które mają, dlatego mówię o całym ekosystemie, bo to i iOS, i iPadOS, i macOS, generalnie wszystko będzie miało budowane. te okapability związane z AI-em. No i moje pierwsze pytanie, jak się na to zapatrujesz? Ja oczywiście rozszerzę swoje komentarze, ale jak to widzisz? AI na swoim urządzeniu personalnym, tak czy nie?
Krzysztof: W zasadzie powiem szczerze, że ja jestem osobą, która nie czuje tutaj większego zagrożenia, naprawdę. Nie założę teraz foliowej czapki, która będzie mnie odcinała od reszty świata. Idę z nurtem.
Andrzej: Ja podzielam Twoje zdanie. Też już dawno do tego doszedłem, że owszem bezpieczeństwo jest ważne, prywatność jest zbiorem nachodzącym na bezpieczeństwo, również jest ważna. Ale w dzisiejszym świecie, jeśli chcemy zrobić cokolwiek, to raczej będziemy musieli pójść na ustępstwa i nie będziemy w 100% prywatni, więc nie jest tak, że możemy sobie możemy żyć w swojej bańce, ale wtedy będziemy ponosili koszt alternatywny, opportunity cost. I jeśli ten koszt zaakceptujemy to okej, ale ważne, żeby go akceptować świadomie, bo jednak niekorzystanie z pewnych, z pewnych rozwiązań, na przykład właśnie z AI, będzie nas stawiało na przegranej pozycji z ludźmi, którzy będą z tego korzystali, bo ci ludzie będą szybsi, będą zwinniejsi, będą szybciej iterować, będą szybciej iść do przodu. Więc możemy podjąć taką decyzję, ale jednocześnie będziemy musieli zaakceptować, że są inni gracze w tej grze, zwane ich życie, i oni jeśli podejmą inne decyzje, to mogą wejść na prowadzenie. i z tym AI na urządzeniach tutaj dopowiem ważną uwagę bo Apple dość dobrze podchodzi generalnie dba o i cyberbezpieczeństwo i prywatność. to jest jedny z ich killer feature i oczywiście te wszystkie funkcjonalności które można było zobaczyć na na Keynote, które, będę szczery, one nie zwaliły z nóg. To jest coś, co już wszystko znamy z chatę GPT, co znamy z Meet Journey, co znamy generalnie od już wielu miesięcy, od półtora roku z wielu różnych firm, które dostarczają rozwiązania z AI. Jedyne co to po prostu Apple integruje wszystko w jednym, w jednym zamkniętym pudełku, w jednym zamkniętym black boxie, z którego jesteśmy w stanie korzystać, wewnątrz systemu operacyjnego, z którego, który Apple dostarcza, czyli na przykład w Macoesie korzystając z poczty jesteśmy w stanie sobie zrobić samary maila. No wcześniej mogliśmy to zrobić mając odpowiedniego odpowiedni czytnik maila. powiedzmy Sparka pozwala nam coś takiego robić. No a teraz będziemy mogli to zrobić w tej poczcie Apple’owej i wiadomo te funkcjonalności związane z AI będą wchodzić do innych aplikacji. w ogóle Apple udostępnia, udostępni API, gdzie będziemy po prostu mogli korzystać z tych capabilities w różnych, w różnych zastosowaniach. Natomiast to, co, na co chciałbym zwrócić uwagę już, już na samym początku, bo po prostu przeglądając ten keynote, Myślę, że dość szybko wszystkim do głowy przyszło OK, ale to się dzieje lokalnie, czy to się dzieje globalnie w jakiejś serwerowni? Gdzie się dzieją te obliczenia? Gdzie się dzieje? to podsumowanie maili, które sobie tworzę? Czy te dane wychodzą gdzieś na zewnątrz? Czy one zostają jednak na moim urządzeniu? No bo wiadomo, jeśli zostają na urządzeniu, to jest lepiej pod kątem prywatności. ale automatycznie musimy się liczyć z tym, że te możliwości, jakie AI może nam zapewnić, są mniejsze, dlatego że ogranicza nas hardware. Niestety z AI jest tak, że trzeba mieć mocny, mocny hardware i już Apple ogłosiło, że te wszystkie funkcjonalności wbudowane w iOS-a, one będą dostępne, ale będą dostępne dopiero od iPhona wersji 15 w górę, więc będzie trzeba dokonać upgrade’u iPhona. co można powiedzieć im jest na rękę, bo sprzedaż iPhone’ów w ostatnich latach spadła, więc znowu teraz pójdzie do góry. jak tylko te funkcjonalności zostaną, będą stopniowo dodawane. Więc musimy mieć dość mocny sprzęt i tutaj żeby powiedzieć jak mocny, No to modele, modele takie najwyższej jakości, które są budowane, które są trenowane przez jakieś Facebooki. to są, to są kilkadziesiąt tysięcy układów Hastos, NVIDI, które, które taki model trenuje np. przez dwa miesiące. Więc to są nakłady finansowe jakie trzeba włożyć żeby wytrenować model. to są, to idzie w setki milionów dolarów. to nie jest tania zabawa, a tutaj mówimy o lokalnym modelu, który będzie się wykonywał na iPhonie. I Apple zastosowało kilka różnych sztuczek, jak to zrobić, żeby faktycznie, żebyśmy otrzymali wartość, która nas będzie zadowalać, czyli np. żeby to podsumowanie maila naprawdę było podsumowaniem i żeby to miało wartość, a nie było, a nie coś tam nam halucynowało i mówiło o jakichś rzeczach, które są niestworzone. Więc Apple użyło wiele różnych trików, żeby móc zrobić to na urządzeniu, ale i to jest ten ważny punkt, ale też będzie możliwość wykonywania operacji globalnie, czyli przy użyciu, Apple to chyba nazywało PCC, generalnie prywatnej chmury do właśnie wykonowanie obliczeń AI. Apple tam od zera zaprojektowało to jak ma wyglądać taka serwerownia. Ona będzie na silikonie, na CPU Apple’owskich. Ona ma zmienioną architekturę pod kątem tego jak się nawet zarządza takimi serwerami. Przykładowo w tym keynote’cie mówili, że Nie ma w ogóle dostępu zdalnego. Nie ma czegoś takiego, że ktoś będzie mógł zrobić SSH na ten serwer. Zupełnie inaczej się administruje. Więc podeszli do całego problemu jak musi wyglądać serwerownia. i jak musi wyglądać zarządzanie nawet serwerami, żeby AI, które będziemy tam aplikować, czyli te dane, które wysyłamy i które są przetwarzane, bo chodzi o te dane użytkowników, żeby one były bezpieczne i żeby użytkownik naprawdę miał wysoki poziom zaufania, że to co wysyła do naszej chmury, do chmury Apple jest naprawdę bezpieczne i nie wyleci, nie zostanie gdzieś upublicznione. Ja nie wiem, oczywiście nie zweryfikujemy tego, na ile jest to prawda, chociaż Apple w tym kino się też wspomniało, że będą udostępniali obrazy tych systemów dla zewnętrznych researcherów, którzy będą mogli szukać podatności w nich i oczywiście brać udział w Apple Back Bounty. które płaci dość sporo. jeśli tam się znajdzie krytyczne podatności w urządzeniach Apple to to są setki tysięcy dolarów. nawet miliony potrafią być więc jest to co grać. Z mojej perspektywy, ja się skłaniam oczywiście tutaj ku Twojej wizji, że nie będę zakładał teraz czapki foliowej. Oczywiście, jeśli mówimy o wykonywanych operacjach lokalnie, to nawet nie ma co się za bardzo tym przejmować, no bo to jest lokalnie, jest OK. Z tym globalnie, To o ile dobrze pamiętam będzie opt-in, będzie trzeba jasno powiedzieć, że chce się z tego korzystać, czyli by default to będzie opt-in, a nie opt-out. Więc nie trzeba się z tego wypisać tylko trzeba się do tego zapisać, żeby korzystać z tych dodatkowych capability. Co oczywiście znowu czapka z głów w stronę Apple, tak to powinno wyglądać. To powinna być świadoma decyzja użytkownika urządzenia czy systemu, żeby korzystać z takiej funkcjonalności. Ale jest jeszcze jeden mały szczegół, o którym nie wspomniałem, a który jest dość ważny. Apple weszło w kolaborację z OpenAI. I tutaj nie do końca rozumiem na jakim poziomie, i na tym filmie, który widziałem, i gdzieś na materiałach oficjalnych od Apple nie było jasno napisane, gdzie jest, a przynajmniej ja nie wyłapałem, gdzie jest jasny podział pomiędzy tym, co robimy na swoich modelach, co robimy w swoich datacenter, co robimy tam, gdzie możesz nam zaufać, bo jesteśmy Apple, a co robimy na serwerach OpenAI, gdzie niejako dokładamy jedną stronę, której też trzeba byłoby zaufać. Nie wyłapałem, na czym ta praca polega, tak na poziomie operacyjnym, czyli nie tylko, że weszliśmy z nimi w deal, tylko no dobra, ale w tym dealu to gdzie się kończy te wasze…
Krzysztof: Gdzie są granice. Dokładnie.
Andrzej: Gdzie są tutaj te granice zaufania? albo inaczej. Z czego nie, z czego, co chcę wyłączyć, żeby nie korzystać z OpenAI, ale żeby korzystać z waszego Apple Intelligence. To jest dla mnie takie pytanie. Nie wyłapałem tutaj, no ale samo to, że weszli w kolaborację z Open AI na jakimś poziomie już jest ciekawe samo z siebie. I tutaj Elon Musk się nawet do tego odniósł. Jasno napisał, tak, wbił szpilkę typowo, typowo dla Ilona, gdzie stwierdził, że jeśli Apple zintegruje się z Open AI na poziomie systemu operacyjnego, to wszystkie urządzenia Ampla zostaną zbanowane w jego firmach. Stwierdził, że jest to precedens, że jest to po prostu pogwałcenie bezpieczeństwa tak mocno nieakceptowalne z jego punktu widzenia, że po prostu tego nie zaakceptuje i prędzej zbanuje wszystkie urządzenia, nie tylko wszystkie urządzenia, ale nawet wizytorów, gości, którzy przychodzą do jego firmy, będą musieli zostawiać urządzenia w klatce Faradaya przed wejściem, bo po prostu jest to dla niego nieakceptowalne. Oczywiście, to jest typowy Elon, więc tutaj jedno mówi, drugie robi, więc nie chciałbym poświęcać za dużo czasu na to, co tam Elon powiedział i co zrobi. ale faktycznie jeśli dane będą przetwarzane i OpenAI byłby zintegrowane na poziomie systemu operacyjnego z Apple’em no to należałoby się wtedy faktycznie zastanowić nad tym faktem. Bo czy on będzie decydujący w dalszym korzystaniu z urządzeń Apple’a i systemów to nie wiem, trudno na ten moment powiedzieć. Ale na pewno to jest taki moment pauzy, gdzie trzeba byłoby się zastanowić, bo ja osobiście też nie chciałbym, żeby moje dane wylatywały do OpenAI. Z wielu różnych powodów, ale głównym powodem jest to, że niejako do Apple mam jakiegoś rodzaju zaufanie, tym bardziej, że Na zaufanie się zasługuje, w sensie trzeba sobie zasłużyć. To nie jest tak, że zaufanie jest dawane za darmo. I Apple na przestrzeni lat zarobiło na to zaufanie. Głośny przypadek terrorysty z San Bernardino, gdzie Apple pomimo tego, że służby federalne wystosowały, czyli FBI, Wystosowało jasną prośbę do FBI o odblokowanie urządzenia terrorysty wewnętrznego. Generalnie wystosowało prośbę o odblokowanie. Apple tego nie spełniła. Apple tego nie spełniła, poszło do sądu i nawet w momencie, gdy ktoś był uznany za terrorystę, to Apple się nie ugięło i wygrało ten proces. Właśnie jednym z głównych, kluczowych punktów było tam to, Dbamy o prywatność naszych użytkowników, nawet jeśli są terrorystami. To są dwa oddzielne od siebie fakty i nie możemy zrobić wyjątku, bo jeśli zrobimy jeden wyjątek, to będziemy musieli robić wyjątki od teraz do końca. Więc pewne rzeczy, pewne mosty są takie, że jak się je przejdzie, to już nie da się zawrócić. I to byłby jeden z takich mostów. Apple do tej pory tego mostu nigdy jeszcze nie przekroczyło, zawsze stawało przed. Mówiło, że prywatność naszych użytkowników jest dla nas ważniejsza, jest dla nas jednym z naszych głównych korowych zasad i tego mostu nie przekroczymy. Nawet w sytuacjach, gdzie opinia publiczna mogłaby być bardzo mocno podzielona się nie ugieli. A tutaj ten Open AI. zobaczymy. Zobaczymy jak to wyjdzie. Natomiast z samego, z samych funkcjonalności związanych z AI, no jak to samo określałeś Krzysiek, nic super ciekawego tam nie zostało zaprezentowane z perspektywy tego co każdy siedzący w AI zna z różnych firm, które dostarczają tego typu usługi. Ale jeśli mówimy o general market, jeśli mówimy o ogólnym rynku, o ogólnych odbiorcach, o typowym konsumencie, to to będzie deal breaker. To jak dla zwykłych ludzi, którzy nie są power userami, którzy z komputerów korzystają raczej nieprofesjonalnie, po prostu jako pewne narzędzie. to będzie Game Changer, jak będzie można robić wiele różnych rzeczy, które zostały zaprezentowane w locie i nie będzie to wymagało kupowania dodatkowych subskrypcji, uczenia się jakichś składni, pisania promptów, tylko po prostu. zrób mi podsumowanie wczorajszej rozmowy z moją mamą. Albo przypomnij mi, albo powiedz do Siri, Wbij mi kalendarz spotkanie z tym i z tym i kup bilety. Wiadomo, tutaj wychodzę trochę przyszłość, ale jak będzie można takie coś zrobić i to będzie mógł zrobić przeciętny użytkownik, no to wtedy zobaczymy jak ta adopcja AI wyskoczy. po prostu to the moon. Więc co trzeba zrobić? Nie wiem, może kupować te akcje Apple’a i Nvidia. To nie jest porada inwestycyjna.
Krzysztof: Jest już na górce, nie kupujcie. Teraz już kupują tylko frajerzy.
Andrzej: O, to we’ll see. Sprawdzimy to za rok.
Krzysztof: Słuchajcie, jak słyszycie już w tym podcaście, że trzeba inwestować, to nie inwestujcie. Nie wiem, kto to powiedział, ale jak słyszysz od taksówkarza, że warto jest zainwestować w krypto, to znaczy, że trzeba się z krypto już wydawać.
Andrzej: Tak, tak, tak. Klasyka.
Krzysztof: A co do prywatności związanej z Apple Intelligence, to moje krótkie przemyślenie. W większości widziałem, że najwięcej krzyczą ci, którzy potem odpalają TikToka albo robią zdjęcia swoich dzieci i wrzucają je na Instagrama. Więc tutaj takie moje przemyślenie w kontekście prywatności. Nie spotkałem się z osobą, która faktycznie bardzo rygorystycznie podchodzi do prywatności i nie robi tych rzeczy, o których mówiłem. A jednocześnie mówi nie, nie, ja w ogóle nie będę korzystał z Apple Intelligence, nie korzystam z OpenAI, nie korzystam z tamtego i tamtego, no bo po prostu to by było życie trochę ascety w dzisiejszych czasach.
Andrzej: Dokładnie. Krzysiek, dajesz swój ostatni kawałek.
Krzysztof: To będzie bardzo króciutkie. W zasadzie takie wezwanie, manifest do tego, żebyście pinowali swoje GitHub Actions, bo jest to możliwe. Można pinować do konkretnego komita konkretne action. Okazuje się, że w tym momencie tylko 2% wszystkich repozytoriów, które korzystają z GitHub Actions jako swój engine do CI CD to robi. Dlaczego w ogóle warto to robić?
Andrzej: Krzysiek, ja Ci wejdę w słowo, bo czy mógłbyś wyjaśnić czym jest pinowanie?
Krzysztof: Możemy przypiąć GitHub Actions do konkretnego komita, nie do konkretnej, do konkretnego brancza, na przykład nie do mastera, no bo wtedy jeżeli ten master się tego action zaktualizuje, bo zostanie wydana nowa wersja, no to również w naszym środowisku CICD odpali się ten nowy kod, nie ten, który konkretnie chcieliśmy, Tylko ten, który został wtedy tam zakwalifikowany.
Andrzej: Dobra.
Krzysztof: Więc możemy spinować do konkretnego komita tego, tego action. To jest bardzo proste. Wystarczy po prostu po Maupie wskazać dla danego action na jaki komit chcemy, chcemy wskazywać. No i tak jak tutaj widzicie w tym momencie ten action checkout jest spinowany do tego konkretnego komita, więc w zasadzie za każdym razem, kiedy będziemy odpalać nasz proces CI, no to będziemy mieli powtarzalny wynik dla tego action, przynajmniej powinniśmy mieć powtarzalny wynik dla tego action, no bo cały czas odpala się ten sam kod w naszym środowisku CI. No i jest to o tyle istotne, Akurat w to nie wierzę, bo to Action Checkout, ona jest pod pieczą GitHuba, no ale jeżeli ktoś by w jakiś sposób był w stanie zmodyfikować tak, albo pchnąć coś do domaina czy mastera w tym Action Checkout, no to zaafektowane by było praktycznie wszyscy, którzy korzystają z GitHub Actions w kontekście GitHuba. ale w kontekście takich mniej znanych albo rzadziej używanych actions to jest szczególnie istotne, no bo tak naprawdę nie mamy wpływu na to w jaki sposób ktoś podchodzi do bezpieczeństwa tych jakby trzeci action, który używamy w naszym procesie CI na GitHubie. No i teraz możecie sobie myśleć, ojeju, jak to zrobić, teraz muszę poszukać wszystkich tych komitów, do których chce się pinować. Twórca tego artykułu, tego manifestu mówi, że nie. jest konkretne narzędzia, ja sobie je wczoraj testowałem, Frisbee. Wystarczy podać ścieżkę do swoich workflow’ów w repozytorium i on nam ładnie wyświetli wszystkie wszystkie sza. dla naszych komitów, które chcemy, do których chcemy się przypinować. A jeżeli chcemy być up-to-date, no to przychodzi nam z pomocą Renovate, czyli bardzo popularny bot do tego, aby utrzymywać nasze zależności. Up-to-date wystawia nam sam Merge Requests czy Pool Requests. i wystarczy po prostu podpiąć sobie dodatkowy taki plugin helpers.bin.github.actions.digist. i w tym momencie również będziemy mieli aktualizowane te nasze actions w naszych plikach deklarujących CI CD. Oczywiście nie rozwiązuje to problemu tego, że jeżeli nawet spinujemy się do jakiegoś konkretnego komita w danym action, no to w tym action to, to action może wykorzystywać jakiś obraz dockerowy, który na przykład będzie referował do, do latest i z kolei w tamtym obrazie dockerowym coś zostanie złego wstrzyknięte. czy, czy dodane, ale to są już bardziej zaawansowane metody, nie całkiem abstrakcyjne, ale mimo wszystko wydaje mi się, że warto, jeżeli korzystacie z GitHub Actions w kontekście CI, ZTE, to żeby zainteresować się tym pinowaniem. To też jest jeden z wymogów bezpieczeństwa w takich standardach np. od CIS-u, supply, chain, software, security czy standardów NIST-owskich w kontekście zabezpieczenia naszych środowisk. CI, CD, o których mówiliśmy, o tych standardach, o tych publikacjach mówiliśmy w poprzednim odcinku, do którego zapraszamy.
Andrzej: Serdecznie zapraszamy do poprzedniego, nie tylko jednego, do wszystkich poprzednich odcinków. A ten ostatni to nawet nie nasza rozmowa, tylko wywiad z Piotrem Siemieniakiem, no to szczególnie zapraszamy, bo ta rozmowa to jest po prostu…
Krzysztof: Majstersztyk.
Andrzej: Majstersztyk.
Krzysztof: To, że Piotrka udało nam się załatwić do rozmowy, to Ja powiem tak, jak nie lubicie ludzi z Compliance’u, to po tej rozmowie polubicie.
Andrzej: Tak, tak. Przynajmniej takich ludzi pokroju Piotrka.
Krzysztof: Dokładnie.
Andrzej: Dobra, Krzysiek, to tyle na dzisiaj. Słyszymy się za dwa tygodnie. Mam nadzieję, że o trochę późniejszej godzinie, jeśli mamy to nagrywać w niedzielę, to Opalałbym trochę, trochę później. Nie, żebym nie wstawał, i tak wstaję rano, ale jednak, jednak ta trochę późniejsza godzina do nagrywek byłaby bardziej wskazana. No i oczywiście będziemy musieli potestować narzędzia do nagrywania, żeby nam tutaj wszystko, wszystko szło bez, bez problemów. No ale to, to gdzieś tam po naszej stronie… Do trzech razy sztuka. Tak, to drugi raz nagrywamy. Tak i drugi raz jakieś problemy wyszły, no ale te problemy to można założyć, że będą. Mamy nadzieję, że kolejnym razem już pójdzie bezproblemowo. Dobrze. Krzysiu, serdeczne dzięki za kolejną rozmowę. I co? Ciśniemy, ciśniemy, idziemy do pracy i ciśniemy.
Krzysztof: Dokładnie. Trzymajcie się, dziękujemy, że jesteście i dajcie znać w komentarzach jak nam poszło tym razem. Trzymajcie się, Andrzej. Do usłyszenia.
Andrzej: Do usłyszenia. Na razie.