W tym odcinku podcastu gościmy Klarę Trzcińską, QA Experta w Pentakompie i liderkę zespołu testów technicznych, specjalizującą się w testach pozafunkcjonalnych i automatyzacji. Klara opowiada o swojej ścieżce kariery – od testera QA do specjalisty ds. bezpieczeństwa, podkreślając, że był to naturalny proces wynikający z potrzeb biznesowych i jej osobistej inicjatywy. Dowiesz się, jak testerzy QA mogą przejść do ról w cyberbezpieczeństwie, wykorzystując swoje umiejętności programistyczne i poznając specyfikę bezpieczeństwa, w tym wytyczne OWASP.
Automatyzacja Bezpieczeństwa i Rozwój Kompetencji:
- Praktyczne „Quick Winy” w Automatyzacji Bezpieczeństwa CI/CD: Klara dzieli się swoimi sprawdzonymi metodami w automatyzacji bezpieczeństwa w potokach CI/CD, wskazując na użycie narzędzi takich jak SonarCube (do jakości kodu i wstępnego skanowania podatności), Snyk lub Trivy (do analizy zależności i bezpieczeństwa obrazów Docker) oraz OWASP ZAP/Burp Suite do testów dynamicznych.
- Znaczenie Proaktywnej Postawy i Samorozwoju: Podkreślona zostaje waga proaktywnego podejścia, chęci do ciągłej nauki oraz wykorzystywania dostępnych zasobów edukacyjnych, takich jak platformy TryHackMe i Hack The Box, do zdobywania praktycznego doświadczenia w cyberbezpieczeństwie.
- Rola Zespołu Testów Technicznych we Wspieraniu Deweloperów: Rozmawiamy również o kluczowej roli zespołu testów technicznych, który wspiera deweloperów w integracji narzędzi bezpieczeństwa i interpretacji wyników testów, co przyczynia się do efektywnego wdrażania DevSecOps.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Krzysztof: Witamy. W ramach Warszawskiej Dni Informatyki jest z nami Klara Trzcińska, QA Expert w Pentakompie. No i właśnie, Klara, ja tu widzę bardzo bogate doświadczenie, ale nie chciałbym niczego pominąć, więc może dla naszych słuchaczy, gdybyś mogła się pokrótce przedstawić i opowiedzieć, co obecnie robisz.
Klara: Jasne, także dzięki w ogóle za zaproszenie. I jeśli chodzi o moje obecne doświadczenie, no to teraz mam przyjemność bycia takim liderem zespołu, który ja bym nazwała zespołem testów technicznych. My się specjalizujemy właśnie w testach, bym powiedziała, że pozafunkcjonalnych plus automatyzacji testów i łączymy, w zespole mamy w tym momencie 20 osób. Łączymy te kompetencje takie techniczne właśnie nastawione na weryfikację poza funkcjonalną oprogramowania, czyli tutaj mam na myśli właśnie bezpieczeństwo, wydajność, dostępność, to są takie chyba główne trzy obszary. Poza tym trochę automatyzacji testów, no bo też wykorzystujemy te swoje umiejętności techniczne w zespole, że jako, że robimy to bezpieczeństwo, wydajność, to większość z nas, chyba nawet wszyscy mamy dosyć duże doświadczenie też takie programistyczne od tej strony kóła testów, czy gdzieś tam jeszcze ze studiów. No i tą wiedzę wykorzystujemy też po prostu w automatyzacji, czyli jesteśmy takim zespołem, który można tutaj poprosić o wsparcie, czy to wewnętrznie w firmie, czy na zewnątrz. Nasi klienci mogą nas właśnie poprosić o takie wsparcie. we wszelkiego rodzaju pracach, które mogą być też problematyczne np. dla testerów wewnątrz zespołów, które wytwarzają oprogramowanie, no bo mogą wymagać.
Krzysztof: Taki model shared service, tak?
Klara: Tak, i tutaj właśnie i wewnętrznie i na zewnątrz i też trochę się dzielimy kompetencyjnie, bo to też nie jest tak, że te 20 osób wszyscy są super ekspertami, od wszystkiego, bo tak się raczej nie da. Siłą rzeczy każdy się trochę specjalizuje w swoim obszarze, także tutaj bezpieczeństwo jest takim silnym obszarem, z którego mamy chyba większość prac i tutaj mamy też sporo osób, które właśnie się w tym specjalizuje.
Krzysztof: Powiedz mi Klara, bo wyłapałem, że wspomniałaś o automatyzacji testów. My tu mówimy o automatyzacji testów w kontekście funkcjonalnym, czy tych aspektów niefunkcjonalnych?
Klara: I takim, i takim, ale też pomagamy w tym aspekcie funkcjonalnym. To jest taki mały dodatek jakby ten funkcjonalny poza tym obszarem pozafunkcjonalnym właśnie u nas.
Krzysztof: Okej. Wiesz co, mam takie pytanie. Przez ostatnie kilka lat widzimy taki trend przechodzenia właśnie ludzi, którzy są związani z szeroko rozumianą jakością, testerką, czy właśnie bycia QA’em do bezpieczeństwa. I jak to wygląda właśnie z twojej strony? Zresztą widzisz, że jednak to rozgraniczenie jest nadal twarde i tej tranzycji nie ma aż tak widocznej.
Andrzej: Ja tutaj jeszcze dodam dla słuchaczy, że Klara ma bogate doświadczenie właśnie od tej strony, bo też szkoli ludzi, więc niejako jej spojrzenie jest dość szerokie na ogólny rynek. Więc tak, jak to wygląda z twojej strony?
Klara: Może zacznę od tego, że ja właśnie przeszłam taką ścieżkę i przeszłam ją bardzo szybko, bo tak naprawdę jak się pojawiłam, jak dołączyłam do zespołu i byłam po prostu testerem, no to już się pojawiła potrzeba, że w sumie to klienci nas pytają, to my mamy wymagania odnośnie tego bezpieczeństwa, nie do końca wiemy jak to sprawdzać, no i w sumie jakby automatycznie Bardzo szybko weszłam w ten obszar tak naprawdę od podstaw, od dowiadywania się z jakichś pierwszych dokumentów o WASP-u, szukania w internecie jakie mamy narzędzia, od takiego na początku prostego puszczania automatów do po prostu później do czytywania, chodzenia na szkolenie i jakby rozwijania tych kompetencji. No więc u mnie to tak wyglądało, po prostu pojawiła się taka potrzeba. To było już ileś lat temu, więc wtedy wydaje mi się, że dopiero to tak naprawdę startowało, że gdzieś tam klienci dopytywali o to bezpieczeństwo, czy to jest na pewno weryfikowane, testowane. Teraz to już jest standard, więc te usługi z zakresu bezpieczeństwa się zamawia i raczej wszyscy klienci tego pilnują, żeby taka weryfikacja była wykonywana. Testerzy u mnie w zespole i generalnie osoby, które są w zespole na pewno też duża część chce się rozwijać w tym bezpieczeństwie, bo to jest taki temat ciekawy i on jest też odbierany jako taka ciekawsza forma testów, może mniej taka monotonna i ja bym się chyba z tym zgodziła, że jednak częściej zmieniamy system, bo jednak gdzieś tam te testy trwają krócej niż taka wytwarzanie systemu, gdzie możemy przez ileś lat nawet w takim większych systemach testować jeden system i gdzieś tam te przyrosty. Więc to myślę, że jest motywacja dla osób, żeby pójść do bezpieczeństwa. Też jest dużo do nauki, bo tak naprawdę można ciągle poszerzać, rozwijać tych technologii, tych zmian jest naprawdę bardzo dużo. Oczywiście w testowaniu też, ale już w takim testowaniu manualnym to już mniej, bo weryfikujemy pod kątem tego czy ten system nam działa, więc to się może znudzić. Jak automatyzujemy to oczywiście są też zmiany, ale zazwyczaj automatyzujemy w jakimś jednym narzędziu, jednym języku, więc tutaj myślę, że taka chęć rozwoju może być motywatorem do chęci przejścia do tego bezpieczeństwa, że tutaj naprawdę nie będziemy się nudzić.
Andrzej: No ja właśnie chciałbym o to dopytać, chciałbym tutaj zrobić taki lekki zoom in, bo ja też wiem, bo patrzę na Twojego Linkedina i gdzieś się tam migasz mi na Linkedinie i nie zauważyłem Cię wczoraj, ale już kilka lat temu, że o coś tam jest, ktoś taki jest. Jak to u Ciebie, wiesz nie musisz wchodzić w super szczegóły, ale jak to u Ciebie wyglądało takie nabywanie tej wiedzy związanej z bezpieczeństwem, bo z tego co ja zrozumiałem do tej pory, to w zasadzie wyszło to trochę tak od Ciebie. No ja wiem, że pojawiła się potrzeba biznesowa etc., ale zakładam, że poświęcałaś też swój własny, prywatny czas na wchodzenie w to. I tu się nie mylę, tak?
Klara: Oczywiście, szczególnie na początku trzeba było, no bo gdzieś tam w zadaniach, w pracy, no to nie ma aż tak dobrze, przynajmniej tutaj u mnie aż tak dobrze nie było, że byłby ten czas tylko na naukę, więc trzeba było zrobić te testy, trzeba było zrobić to, co było do zrobienia, więc na pewno gdzieś tam trochę w weekendy, czy gdzieś tam po godzinach trzeba było doczytać. Poza tym szkolenia, no też plusem było to, że już miałam te systemy do testów, więc jeśli chciałam je gdzieś tam weryfikować pod kątem bezpieczeństwa, no to to też mogłam uwzględnić się przy tych pracach w ramach testów. No i to było takie, takie już od razu wejście w praktykę, więc Nie było to takie suche czytanie teorii i robienie na jakichś owaspowych juice shopach, webgoatach i tak dalej, gdzie jest jednak łatwiej znaleźć błędy niż w rzeczywistej aplikacji. Ale odpowiadając na pytanie, myślę, że bez takiego poświęcenia własnego czasu to się nie da. Będzie długo.
Krzysztof: Ja muszę się tutaj wtrącić i powiedzieć, że 100% zgody z Klarą, bo ja też przechodziłem tą ścieżkę z QA właśnie w kierunku bezpieczeństwa i pamiętam do dziś, że najbardziej satysfakcjonującym momentem było to, kiedy mogłem na realnej aplikacji do której miałem zgodę na produkcyjnej aplikacji znajdować błędy bezpieczeństwa i to było naprawdę fajne. To był cool i to jest, myślę, taki zapalnik, który mnie pociągnął dalej w tej mojej ścieżce.
Andrzej: Ja też powiem, że kojarzę jak Krzysiek zaczynał znajdować błędy na swoich produkcyjnych aplikacjach i te dyskusje, które wtedy leciały na Slacku. Krzysiek ewidentnie przeszedł tą drogą. Natomiast to co ja chciałbym uwypuklić to ta praca własna, bo ja też wskakiwałem w to bezpieczeństwo i też tutaj pełna zgoda, No trzeba się wykazać gdzieś tam własną inicjatywą i trochę poszperać, ale jest to jak najbardziej doable. Da się to zrobić, tylko trzeba mieć tam ciekawość, a testowanie już realnych aplikacji, też się zgadzam, jest zupełnie co innego niż aplikacje testowe. Jest satysfakcja ze znalezienia czegoś.
Klara: Ja bym też powiedziała, że nie można się bać nowych rzeczy, no bo też jak wchodzimy w taką aplikację, którą powiedzmy testujemy funkcjonalnie, no to trzeba mieć takie nastawienie, że tak, ja mogę też w niej znaleźć błędy bezpieczeństwa, mnie nikt nie musi prowadzić za rękę i mi mówić co, gdzie ja mam klikać, po prostu otworzę sobie jakieś materiały, doczytam i spróbuję to znaleźć. Bo też wydaje mi się, że sporo takich zmian w karierze, czy jakichś takich przejść, to wynika właśnie z własnej inicjatywy, że nie możemy gdzieś tam czekać, że nas ktoś poprowadzi za rękę, kierownik powie, że w sumie to ja widzę w tobie pentestera, zacznij pentesty, tylko to jednak musi wyjść z własnej inicjatywy, no i wtedy myślę, że też będzie takim potwierdzeniem, że to faktycznie może być to, co nam się spodoba, no bo z jakiegoś powodu w to wchodzimy, chcemy na to poświęcić czas.
Andrzej: Dokładnie tak. Warto gdzieś tam polować swoje, nie tyle pasy zainteresowania, ale jeżeli coś nas tak lekko zainteresuje, to dobrze jest wykonać ten kolejny krok, nawet mały i zobaczyć, czy może nie będzie gdzieś to dalej prowadziło. Ja na przykład teraz zacząłem biegać i dalej nie lubię biegać, ale może się to zmieni za dwa miesiące, zobaczymy. Jak się nie zmieni, to przestanę biegać.
Krzysztof: Tak, ja chciałem tutaj dopowiedzieć do tego, że to jest taka sytuacja win-win, wiecie. Z jednej strony zyskuje biznes i z jednej strony zyskuje ta osoba, która chce w to bezpieczeństwo skoczyć. Biznes ma zapewniony pewien mały kawałek na samym początku tej weryfikacji w kontekście bezpieczeństwa, tych podstawowych pewnie aspektów i problemów, które można znaleźć, a my zyskujemy nową ścieżkę, którą jesteśmy w stanie wskoczyć.
Klara: I też ktoś nas jest w stanie zauważyć, bo może nasz przełożony gdzieś tam nie wiedzieć, że nas to interesuje. Też nie zawsze. Patrząc teraz po sobie, po tych 20 osobach, które są w zespole, bardziej siłą rzeczy zwrócę uwagę, jak ktoś mi pokazuje, że go to interesuje, gdzie właśnie wychodzi z tą inicjatywą, a niekoniecznie będę pamiętać na przykład wszystkie rozmowy kadrowe i wszystkie jakieś tam elementy, które były wpisane w formularzu. Także to też myślę, że trzeba pokazywać na zewnątrz, że chcemy w to iść.
Andrzej: Tak, być proaktywnym. Natomiast ja wrócę jeszcze do twojej pierwszej odpowiedzi, gdzie wspomniałaś o automatyzacji, wspomniałaś o testach, To ja chciałbym się podpytać, bo to, o czym mówiłaś, to trochę zabrzmiało dla mnie, jakby się to już może nie było w pełni, ale gdzieś już zahaczało o pewną rolę inżyniera bezpieczeństwa. Bo jeżeli wy gdzieś pomagacie budować, na przykład budowywać automatyzację, to już trochę przechodzicie nie tylko z roli testera, ale już takiego inżyniera bezpieczeństwa, który pomaga coś wdrożyć. I tu się mylę, nie mylę? Jak ty to widzisz?
Klara: Trochę tak. Zależy tak naprawdę wszystko od projektów i od takich rzeczy w sumie podstawowych, jak możliwości gdzieś tam tego projektu, finanse i wielkość. Także najwięcej mimo wszystko mamy takich zleceń na po prostu wykonanie jakiegoś fragmentu pracy, jakichś pentestów i wskazania błędów. Tego jest najwięcej. To też nie kosztuje jakoś bardzo dużo, więc Może to jest jeden właśnie z powodów. W większych projektach, szczególnie w systemach, gdzie wytwarzamy cały system, no to oczywiście możliwości są większe, no i też potrzeby są inne, no bo tutaj myślę, że nie wystarczy zrobienie takich pojedynczych pentestów i warto to bezpieczeństwo na jak najwcześniejszym poziomie uwzględniać, na jak najwcześniejszym etapie wytwarzania. I to może nawet wyjść taniej, no bo gdzieś tam jak mamy tą znaną krzywą, która nam pokazuje, że jak znajdziemy błąd na samym początku, to w sumie będzie taniej niż jak znajdziemy na samym końcu. To chcemy jakby w tą stronę iść i w niektórych systemach, w niektórych projektach jesteśmy takim bardziej wsparciem, że mówimy jakie są narzędzia, które można podpiąć np. pod ciągłą integrację. Jak są problemy no to możemy wspomóc w takim podpinaniu, no bo gdzieś tam już parę razy widzieliśmy narzędzie. Najczęściej to się kończy na tym, że po prostu takiego programistę czy admina po prostu naprowadzamy na konkretne narzędzia. On już sobie jest w stanie sam znaleźć co jest. Te narzędzia są podpinane pod ciągłą integrację. Zespół już jako zespół gdzieś tam weryfikuje, przegląda te wyniki, analizuje, czy tam wiadomo wyników będzie dużo jeśli chodzi o jakieś na przykład podatności dla jakichś wykorzystywanych komponentów, bo tego zawsze jest dużo. Więc my ewentualnie jako później takie wsparcie, czy jakieś na przykład próby później wykorzystania podatności, co w przypadku znając podatności nie jest takie proste, ale gdzieś tam powiedzmy takie próby, czy takie wsparcie przy ocenie tych wyników, no i wcześniej naprowadzenie w ogóle na tą potrzebę i takie ewentualne wsparcie w konfiguracji.
Krzysztof: Ok, czyli jako zespół też integrujecie w CI’u narzędzia w kontekście właśnie bezpieczeństwa.
Klara: Wspólnie z zespołami wytwórczymi. Wtedy bardziej właśnie jako takie wsparcie.
Krzysztof: A Twoim zdaniem narzędzie, które przynosi największy zysk versus jesteśmy go w stanie relatywnie szybko wdrożyć?
Andrzej: Doszczególnię pytanie. Załóżmy taki hipotetyczny przypadek, że wchodzisz do projektu, nikt nam nie dba o bezpieczeństwo, ale nagle pomyśleli, że fajnie byłoby jednak zadbać. jaką pierwszą praktykę według ciebie, jaką ty byś zaproponowała, jaką byś wdrożyła. Oczywiście tu nie ma dobrych, złych odpowiedzi, bo wszystko ma swoje plusy i minusy, ale jakbyś miała wybrać jakąś jedną, to którą ty byś wybrała?
Klara: Jak nie mamy czasu na manualne testy, ja bym poszła w automaty i poszłabym w analizę kodu, jakiegoś sonara, bym podpięła od samego początku, podpięłabym weryfikację bibliotek, czyli tam na przykład SNYKA, dependency, czeka, I skanery, jeśli gdzieś tam manualnie nie testujemy to, no i środowisko Nesus, OpenVaz, no tutaj w zależności czy tam chcemy kupować, czy nie chcemy kupować do testów aplikacji. Czy bym podpinała taki skaner? Może bardziej bym jeszcze spróbowała gdzieś tam podpytać, czy testerzy nie chcieliby na przykład wykonywać takich prostych testów bezpieczeństwa.
Andrzej: Mam kolejne pytanie. Jeśli by chcieli wykonywać takie proste testy bezpieczeństwa, to jak mogą je wykonać? Czy są jakieś narzędzia, których mogliby użyć do wykonania tych prostych na określonym poziomie testów bezpieczeństwa?
Klara: Jak ja bym miała doradzić jakieś proste testy bezpieczeństwa, to zapoznanie z BERP-em, z podstawami. Weryfikacje jakichś nagłówków. To są bardzo proste rzeczy, to od razu widać, ale mają znaczenie i jest to też dobra praktyka.
Andrzej: Klara złamała się teraz moje serce. BERP, nie ZAP.
Klara: No ja bardziej Berpa. Wolę, jest jakoś wygodniejszy.
Andrzej: Oczywiście, ja też wolę Berpa. Jest wygodniejszy, ma lepsze UI, ale niestety kosztuje pieniążki i jest droższy niż kiedyś.
Krzysztof: Tak, jest droższy i z roku na rok jest coraz gorszy. Jak trzeba zapłacić tą fakturę, to też mi łamie serce. Ale wchodzimy tutaj w temat tego, że zobaczcie, powiedziałaś o nagłówkach, powiedziałaś o berpie, czyli analiza dynamiczna w kontekście wyłapywania tych prostych błędów, niskowiszących owoców, może być pierwszym krokiem dla kogoś, kto nie ma totalnie nic.
Andrzej: Tutaj leading the witness, bo ja zawsze jestem zdania, że jeżeli mam taki goły projekt, to pierwsze co bym zrobił to analiza dynamiczna. bo da się bardzo szybko wdrożyć. Mamy bardzo szybko wyniki. Oczywiście dobrze, jeżeli ktoś jest w stanie je zweryfikować. Ale nawet jeżeli nie, to deweloper też sobie da radę. I te narzędzia też często gęsto nie są super drogie. No bo BERP może tani nie jest, ale jest tańszy niż konkurencja. A są też darmowe odpowiedniki BERPA.
Klara: No tak, czyli na przykład właśnie ZAPA i właśnie bo tutaj jeszcze wspomniałam o tych nagłówkach, no oczywiście nie tylko nagłówki. Możemy będąc testerem gdzieś tam sami sobie doczytać o tych podatnościach z TOP10. Myślę, że można w miarę szybko je opanować i spróbować właśnie z wykorzystaniem tych narzędzi typu lokalnego proxy, czyli tam BERPA, ZAPA taką weryfikację wykonywać. A jak na to nie mamy czasu, no to jednak bym puściła ten automat. Czy w BERPie mamy licencję, czy właśnie w ZAPie. Będzie problem z false positive’ami, no ale to jest też sposób na naukę, bo zobaczymy co nam wychodzi, będzie trzeba doczytać, co to są za podatności, spróbować je na przykład wykonać, no i może się okaże, że tam nie wiem, ten SQL injection co nam wskazał, to w rzeczywistości był jakiś zbyt długi czas odpowiedzi po prostu naszej strony, ale to już nam jakby da taką faktycznie potrzebę do czytania sobie na przykład o tym.
Andrzej: Mi się bardzo podoba, jak cały czas wspominasz o tym doczytaniu, czyli po prostu o proaktywnej postawie, że to wszystko testowanie, w ogóle computer science. to nie jest rocket science. Wystarczy być po prostu zainteresowanym tematem i doczytywać. Wiedza jest dostępna w internecie, może być trochę rozsiana po różnych punktach, ale jeśli ktoś ma ten drive, ma ten curiosity, to może sobie doczytać i po prostu z czasem się nauczy.
Klara: Oczywiście, no są szkolenia, one są w razie czego takie bardziej poukładane i wtedy ta wiedza jest zebrana. Też taniej, jakieś szkolenia w internecie, jakieś kursy, no ale wszystko jest, czy to GPT, czy po prostu internet, to naprawdę jest się z czego uczyć i jest coraz łatwiej pozyskiwać tę wiedzę.
Krzysztof: Tak, jak mówisz właśnie, szkolenia pozwalają nas przeprowadzić przez pewną ścieżkę i płacimy tak naprawdę wtedy za to, że ta ścieżka jest ułożona. A wiedza jest tak naprawdę, jest darmowa, jest wszędzie.
Andrzej: Dokładnie.
Krzysztof: To nie jest rocket science.
Andrzej: To nie jest rocket science i nie trzeba być geniuszem, żeby się tego wszystkiego nauczyć, no ale trzeba mieć, nazwijmy to, ciekawość względem tego, czego się uczymy. Dobrze, no ja się wystrzelałem z pytań.
Krzysztof: Ja był też pusty magazynek, także…
Andrzej: Dziękujemy. Mam nadzieję do zobaczenia i usłyszenia w przyszłości.
Klara: Dzięki do zobaczenia.