W podcaście „Rola bezpieczeństwa w jakości” Arnika Hryszko (QA Chapter Lead w Volvo oraz Prezeska Stowarzyszenia Jakości Systemów Informatycznych), Krzysztof i Andrzej dyskutują o integracji bezpieczeństwa cyfrowego z jakością oprogramowania. Podkreślają, że za jakość i bezpieczeństwo odpowiada cały zespół deweloperski, nie tylko specjaliści.
Kluczowe aspekty omówione w podcaście:
Koncepcja „shift left”: Przeniesienie odpowiedzialności za jakość i bezpieczeństwo na wcześniejsze etapy SDLC, aby zminimalizować koszty i ryzyko incydentów, oraz znaczenie świadomości bezpieczeństwa dla wszystkich członków zespołu.
Ewolucja podejścia do bezpieczeństwa w SDLC: Przejście od reaktywnego do proaktywnego wykrywania podatności na wczesnych etapach.
Różnice między błędami a podatnościami: Podkreślenie, że podatności to wczesne defekty wymagające zapobiegania na każdym etapie tworzenia oprogramowania.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Krzysztof: Cześć, witamy Was wszystkich. Jesteśmy na warszawskich dniach informatyki i naszym gościem jest Arnika Hryszko, QA Chapter Lead w Volvo oraz przewodnicząca Polskiego Związku… Nie!
Arnika: Stowarzyszenia Jakości Systemów Informatycznych. Prezeska SJSI Chapter Lead, tak jak wspomniałeś, plus na warszawskich dniach informatyki host dwóch ścieżek.
Krzysztof: Bardzo miło Cię gościć. Jeszcze raz dzięki, że udało się znaleźć i wygospodarować tę chwilkę czasu. Jesteśmy tutaj razem z Andrzejem. Chcielibyśmy porozmawiać o kwestii jakości i relacji jakości do bezpieczeństwa przez te najbliższe kilka minut. Zacznijmy może od takiego aspektu, jak ty Arnika. obserwujesz ten trend wchłaniania przez część testerów QA tej części właśnie obowiązków związanych z bezpieczeństwem. Widzisz ten trend czy raczej nie?
Arnika: Zacznę może od samej jakości, bo to też ważna kwestia, pomijana często przez ludzi, że jakość to nie tylko testowanie i nie tylko testerzy są odpowiedzialni. To należy podkreślić, bo to też właśnie od tego się zaczęło. Na początku jakość to tylko testerzy. Bywało tak, że nawet jeżeli do zespołu, gdzie testerów nie było, dołączał tester, jakość spada, bo się deweloperzy przestają przejmować. Więc najpierw było to, że jakość powoli stawała się w świadomości ludzi odpowiedzialnych za wszystko. Teraz powoli to samo staje się z bezpieczeństwem. Wychodziło od tego samego. Tak samo jak jakość. Bezpieczeństwo było tą… No to są ci specjaliści, tak? Tam mamy jakiś zespół, on zrobi tam skan podatności, dadzą nam wyniki, my może coś z tym zrobimy. Testerzy czy ogólnie ci związani z jakością. No jakaś tam autentykacja, autoryzacja, tak? No to chyba wystarczy, prawda? Ostatnio współpracowałam z jednym zespołem, który stwierdził, że oni testów bezpieczeństwa nie robią, bo tylko jedna osoba wydaje dostępy, to przecież nikim się nie włamie, bo ta osoba nie da komuś niewłaściwemu. Świadomość jest wciąż mała, Jeśli chodzi o bezpieczeństwo, to widzę tą samą ścieżkę co z jakością. Powoli ta świadomość rośnie, powoli odpowiedzialność rośnie. Nie tylko wyspecjalizowanych osób, tylko wszyscy zdają sobie sprawę, że muszą się tym zająć. Tak samo jak wszyscy zajęli się jakością. Jeszcze nie wszędzie, to wciąż jest droga, ale to samo z bezpieczeństwem. A jedno bez drugiego istnieć nie może, bo jak coś jest niebezpieczne, to nie będzie wysokiej jakościowo.
Andrzej: Dokładnie to. Ja lubię powtarzać taką frazę, że jak coś jest wysokiej jakości to z założenia jest bezpieczne i na odwrót jeśli jest niskiej jakości to już niekoniecznie jest bezpieczne, a może mieć też różne inne problemy typowo jakościowe. Ja tutaj chciałbym podpytać o jedną rzecz, która mnie ciekawi, za którą kiedyś byłem zrugany. Jaka jest różnica pomiędzy testerem jakości, a testerem lub inżynierem QA? Czy to jest ta sama rola, czy jednak coś jest szersze, coś jest męższe?
Arnika: Ogólnie najpierw tak. Testowanie jest częścią jakości. To jest ważne, bo niestety to jest źle postrzegane często. Ludzie te pojęcia często stosują. Wymienia np. testowanie to jakoś, jakoś to testowanie, albo uwielbiam ogłoszenie o pracy, gdzie jest tester QA.
Andrzej: Dokładnie. Za to zostałem zrugany w internetach.
Arnika: Nie. Tester, idąc stricte książkowo, bo wiadomo to się wszystko rozmywa, tak samo jak jesteście programistą, no to czasem trochę architektem, czasem trochę analitykiem, więc te obowiązki są różne. Więc jeżeli pominiemy obowiązki jakie są w firmach, bo to też każdy jest inaczej, tylko czysto książkowo, testowanie to weryfikacja i walidacja. Czyli weryfikujemy, czy coś wszystko jest zgodne z wymaganiami, walidujemy, czy jest zgodne z oczekiwaniami, koniec. Jakość jest znacznie szersza, ma znacznie więcej aspektów, no bo właśnie wchodzi jakieś bezpieczeństwo, użyteczność, znacznie, znacznie szerzej. Jeśli chcemy znowu wstrzymać się książkowo czy definicji, mamy ISO, gdzie są charakterystyki jakościowe, które nam wprost mówią, jakie aspekty składają się na jakość, między innymi bezpieczeństwo właśnie. Więc według ISO bezpieczeństwo jest częścią jakości.
Andrzej: To ja tutaj się zgadzam w stu procentach z ISO. Powiedziałbym, że jest pod zbiorem jakości, bo jakość to jest tak po prostu szeroki termin, że są z tym problemy. Tak jak właśnie ja miałem problem, że tester QA to no i tutaj mnie pojechali.
Arnika: Można powiedzieć, że tester mógłby mieć na przykład checklistę, listę kontrolną, przejdzie przez te punkty. Jakość to jest jednak większy obszar, zapewnienie jakości jako takie, chociaż są ludzie, którzy twierdzą, że nie można zapewniać jakości, czyli ten quality assurance, tylko quality assistance, czyli wspiera się jakość. To już jest debata szersza, ale to zapewnienie jakości to jest też na przykład to, jak pracujemy. Wszystkie nasze ways of working, to jak współpracujemy, jaka jest komunikacja w zespole, gdzie przechowujemy nasze rzeczy, czy mamy kontrolę wersji. Wszystkie bardzo ogromne rzeczy, a tego niekoniecznie robi tester. Tester może zrobić swoją weryfikację i walidację podstawowych charakterystyk jakościowych, ale żeby zadbać o jakość, do tego potrzebujemy całego zespołu.
Andrzej: To mam kolejne pytanie. W takim wypadku, o ile dobrze rozumiem, żeby wejść do jakości, to taka typowa ścieżka pewnie prowadzi przez rolę testerską, a potem się rozszerza ten wachlarz umiejętności.
Arnika: Najczęściej.
Andrzej: I w takim wypadku możemy również rozszerzyć te swoje umiejętności, umiejętności związane z bezpieczeństwem i być technicznie nie tyle bezpiecznikiem, no bo załóżmy, że bezpiecznik to osoba, która weszła od strony bezpieczeństwa, ale być po prostu inżynierem jakości, ale mając taką…
Arnika: Taki smaczek.
Andrzej: Smaczek, specjalizację, pewne jakieś dodatkowe umiejętności, zestaw umiejętności, które pozwalają nam na dbanie o bezpieczeństwo.
Arnika: Jak najbardziej, bo jak jesteś programistą, umiesz język programowania. Będąc testerem, dlatego jestem testerem 17 lat i mi się to nie znudziło, przez to ile to ma smaczków. Bo można robić różne rzeczy, ja poszłam bardziej w zarządzanie testowaniem, czy zarządzanie jakością, taki ogólny pogon. Ale właśnie, od testera, czyli niekoniecznie od bezpieczeństwa od razu, ale od testera można iść w pentestera, czyli będąc testerem penetracyjnym, typowo w bezpieczeństwo, można być testerem. Są nowe stanowiska. Tester charakterystyk jakościowych. Widziałam coś takiego, w firmie, która się bardzo mocno ISO trzyma, gdzie skupiają się na tym. Testowanie może iść w użyteczność, może iść gdziekolwiek, więc właśnie są te różne smaczki, ale zawsze to bezpieczeństwo też musi być brane pod uwagę. Te podstawowa autentykacja, autoryzacja to jest minimum, ale nawet kwestie uczestności związane są z bezpieczeństwem. Jak nam błędy wywalą ze wszystkimi linijkami, co tam się zadziało, to brzydko wygląda, ale też jest z drugiej strony niebezpieczne.
Andrzej: Tak, to jest podatność, która często wpada do raportu.
Arnika: Tak, więc dużo aspektów, które wydają nam się, że nie są związane z bezpieczeństwem, a które testujemy jako testerzy, zapewniacze jakości, jakkolwiek nazwiesz, tak naprawdę z bezpieczeństwem są. Więc najważniejsza moim zdaniem, przynajmniej ta pierwsza ścieżka jest świadomość, co może wpłynąć na bezpieczeństwo.
Andrzej: To ja mam tutaj jeszcze jedno małe pytanie albo może duże. Jaką różnicę widzisz pomiędzy bugiem a podatnością, błędem a podatnością? To samo na pewno nie jest. A pytam dlatego, że tak jak wspomniałeś, masz już sporo doświadczenia w jakości, w tym co robisz i dobrze mi się z tym rozmawia. Ja czuję ten fellow spirit. Ja też mam prawie 15. Już mam komercyjnego doświadczenia w cybersecurity, a hobbystycznego 20 i też sporo testowałem, ale właśnie typowo bezpieczeństwo i ja widzę pewne rozróżnienie między bugiem a podatnością, ale to zaraz powiem jak ja to widzę.
Arnika: Tu w ogóle moglibyśmy wyjść z definicji ISTQB, więc to by było jeszcze inaczej. Gdzie według definicji ISTQB, co też fajnie niektórym ludziom obrazuje, błąd to jest ludzki. Błąd równoznacznie jest z pomyłką i to jest ludzkie. Czyli zmęczona byłam, coś źle zrobiłam, czegoś zapomniałam itd. Z tego wynika usterka bądź defekt, który są w kodzie. czyli gdzieś tam się zapętla coś, gdzieś można coś prowadzić itd., co może, ale nie musi wywołać awarie, czyli już coś, co jest widoczne, coś, co nam rozwala system. To jest definicja według ISTQB. I teraz podatność. moim zdaniem w porównaniu do tego to jest właśnie ten defekt. usterka, czyli coś jest nie tak, Niekoniecznie to spowoduje nam buga tego, jak powszechnie to widzimy. Jak się mówi błąd, bug czy nawet defekt, to jest coś, co już widzimy, co już spowodowało jakiś problem. Więc to jest ten ostatni etap, a podatność moim zdaniem to jest właśnie taka usterka gdzieś tam zaszyta, która może doprowadzić do tej awarii. czyli to jest najwcześniejszy etap. Wychodziliśmy od podejścia reaktywnego, czyli coś się dzieje, więc reagujemy, coraz bardziej idziemy w kierunku proaktywnym, czyli zapobiegawczym, preventive maintenance, nie reactive maintenance, czyli właśnie chcemy zawczasu, żeby się zadziało, więc już chcemy wychwytywać te usterki, te podatności, zanim coś się stanie, a nie już jak to wyjdzie na produkcję.
Andrzej: Czyli tak zwany shift left. Dokładnie.
Krzysztof: Ja myślę, że w kontekście bugów o podatności bardzo lubię wychodzić po prostu z teorii bezpieczeństwa informacji, gdzie operujemy na triadzie CIA, czyli poufności, integralności i dostępności. I takie proste rozróżnienie dla testera, że jeżeli dealujesz tutaj z czymś, co ma jakiś wpływ na jeden z tych trzech aspektów, to jest podatność, a reszta jest po prostu bugiem mówiąc kolokwialnie.
Andrzej: to ja tutaj spróbuję trochę włożyć włożyć widelec w to i jedną rzecz chciałbym żebyście się wypowiedzieli. W takim wypadku jeżeli mamy cały proces SDLC wytwórczy oprogramowania to jak należałoby podejść? czy powinniśmy traktować podatności jakoś szczególnie względem bugów czyli jakichś defektów? czy jednak powinniśmy wszystko traktować na równi? więc nieważne czy to jest podatność czy bug To jest coś, co w kodzie powiedzmy jest i ja chcę albo nie chcę tego wyprowadzać, bo po prostu mi się spina budżet czy nie. I mam tutaj jedną uwagę, że Linus Torvalds kiedyś dość głośnie na liście mailowej porównał bezpieczników do nie będę mówił do czego, ale do małp i bardzo ich tam pojechał, właśnie mówiąc, że tak naprawdę podatności nie są ważniejsze niż bugi, chociażby dlatego, że bugów jest dużo więcej i nie zgadza się z bezpiecznikami, żeby traktować podatności szczególnie. Rząd widzi wszystko tak samo, oczywiście są pewne wyjątki, ale tak day to day work widzi jedno i drugie, jest dla niego tym samym.
Arnika: to ja to samo słyszałam o testerach, że są małpami, które klikają, więc to mamy wspólnego. Może nie od Linusa, ale jest człowiek, który, no jest sobie pan, który nazywa się Bolton, tak samo jak piosenkarz, ale jest totalnym właśnie, że jeżeli tylko się robi według list, tak, czy czegoś takiego, to właśnie jest małpą, która tylko robi czeki. Ale nie o tym. Moim zdaniem i bugom, i podatnościom powinniśmy zapobiegać. Tak jak mówiłam, to są na różnym etapie, ale z jednym i drugim trzeba pracować. Czy któreś jest ważniejsze? Nie wiem. Dbając o jakość musimy zapobiegać i pracować z jednym i drugim. Moim zdaniem jedne i drugie są równie ważne, więc trzeba jak najbardziej brać to pod uwagę. Mamy podejścia. chociażby w teorii testerskiej, jak mamy taksonomię bugów, czyli taksonomię, na podstawie których przygotowuje się do testowania, przygotowuje się nasze scenariusze testowe itd. I taksonomię można robić na podstawie istniejących bugów, czyli informacji, gdzie mamy już to, ale też podatności właśnie. I to jest coś, co ja swoich studentów też zachęcam coraz częściej, bo też u studentów uczę poza pracowaniem zawodowo. że właśnie bugi to jedno, ale podatności, tak? Znamy podatności, mamy listy przygotowywane, mamy OWASPA, wiemy co jest, pracujmy też w oparciu o to właśnie, żeby zapobiegać. Dla mnie czy jedno czy drugie, równie ważne, ale zapobiegajmy jednemu i drugiemu.
Andrzej: Bardzo mi się podoba twoja odpowiedź. 10 na 10.
Arnika: Nie ustawialiśmy wcześniej.
Andrzej: Tak, tutaj trzeba jasno zaznaczyć, że nawet nie wysłaliśmy Arnice żadnych pytań. Tak było, lecimy live.
Krzysztof: Ale to też bardzo fajnie, Arnika, to co powiedziałeś, że nie rozróżniasz tej ważności bugów versus podatności i bezpieczeństwo nie jest niczym specjalnym. Wszyscy gramy do tej samej bramki, a nie chodzi o zawody.
Arnika: Część całości, tak? Coś, co musiałam tłumaczyć deweloperom, a potem też innym, pracującym od samego początku. Bo wiecie, jak zaczynałam testować te 17 lat temu, no to bywało, że ludzie się na mnie obrażali personalnie, bo im zgłaszam bugi, bo im wytykam, że coś robią źle. Więc od początku tłumaczenie, ale mamy jeden wspólny cel, mamy dostarczyć wysokiej jakości oprogramowanie. Cel mamy wspólny, więc współpracujmy, więc nie nazywajmy się może małpami, nie priorytetyzujmy, tylko mamy rzeczy, o których możemy oprzeć, możemy się wesprzeć wzajemnie. Czy podatności, czy bugi, po prostu opierajmy na jednym i drugim, żeby dotrzeć do wspólnego celu.
Andrzej: Ja ze swojej strony dodam, bo ja tutaj wszedłem od strony bezpieczeństwa, że trochę mi zajęło zrozumieniem właśnie, że gramy do jednej bramki i ja byłem tą osobą, która ewidentnie mówiła, że każda podatność trzeba wyprowadzić, wszystko. podatności są najważniejsze, low, trzeba teraz zatrzymać produkcję, panie musi pan to wyprowadzić, ale z biegiem czasu i też może z wiekiem gdzieś tam zrozumiałem i skłaniam się ku opcji w chwili obecnej, że bugi, podatności nie ma większego znaczenia. Na koniec dnia chcemy po prostu wyprowadzać rzeczy. I idealnie robić to praktywnie, tak jak właśnie wspomniałaś. Czyli w ogóle nie dopuszczać do wprowadzenia tego, a nie potem dealować z czymś co już jest.
Arnika: Więc tu musimy bardzo mocno też uświadamiać ludzi, którzy o tym nie pamiętają, czyli analityków, czy inżynierów wymagań, czy produkcjonerów, czyli tych, którzy zbierają wymagania, bo to jest duży problem, a wiadomo, jakość zaczyna się już od samego początku, więc człowiek zbierający wymagania, pomijmy jak nazywa się jego stanowisko, pyta się, co ma robić system. Wspaniale, tak? Ale co właśnie ze wszystkimi charakterystykami, jakościowymi podatnościami i wszystkimi innymi? O tym się zapomina, bo tego się nie uczy też tych ludzi, więc to jest myślę naszym zadaniem, czyli ludzi świadomych w sensie jakości bezpieczeństwa, żeby dać im znać, że to też jest ważne, więc też dowiedzcie się o tym, jak to ma wyglądać.
Andrzej: Pełna zgoda.
Krzysztof: Tak i to bardzo fajnie się spina z tym pytaniem, które zadałem na samym początku, że faktycznie ten trend przechodzenia jakości jako również odpowiedzialności wszystkich, zarówno deweloperów, jak i testerów jest czymś, co w teorii jakości jest czymś całkowicie normalnym, prawda?
Arnika: Jest niezmiennie nieodłączne.
Andrzej: Dobrze, to tym pozytywnym akcentem możemy skończyć. Jakość, bezpieczeństwo. Bezpieczeństwo jest pod zbiorem. Jakość. Nam chodzi o to, żeby produkty były jakościowe, dobrej jakości.
Arnika: Czyli jesteśmy ziomalami między bezpieczeństwem a jakością.
Andrzej: Jesteśmy.
Krzysztof: Wielka sztama.
Andrzej: Dobrze, to dłużej Cię nie trzymamy i puszczamy Cię już, żebyś mogła czermenować swoją ścieżkę, bo trochę Cię przetrzymaliśmy, ale już puszczamy.
Arnika: Dziękuję bardzo.
Krzysztof: Dzięki wielkie.