To jest 229. odcinek podcastu Porozmawiajmy o IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT SolidJobs, który to zresztą mam przyjemność współtworzyć, dyskutujemy o Software Craftsmanship, czyli o rzemiośle programisty.

Zapraszamy do słuchania i komentowania. A teraz życzymy Ci już miłego słuchania.

Odpalamy!

 

Cześć, Łukasz.

 

Cześć, Krzysztofie.

 

Witamy słuchaczy w drugim odcinku z serii podcastów o Software Craftsmanship. Dzisiaj będziemy dotykać tematu, który z pozoru może wydawać się niepowiązany z tworzeniem oprogramowania, ale okazuje się, i to ostatnie lata, mam wrażenie, pokazały to bardzo dobitnie, że bezpieczeństwo – bo tutaj o takim właśnie temacie będziemy rozmawiać – jest bardzo związane z oprogramowaniem.

Okazuje się, że im wcześniej w procesie wytwarzania oprogramowania o bezpieczeństwo zadbamy, tym po pierwsze koszty ewentualnego wpływu bezpieczeństwa na użytkowników będą po prostu mniejsze, a po drugie mamy szansę wytworzyć po prostu lepsze jakościowo oprogramowanie, stąd nasza, mam wrażenie, programistów bardzo duża odpowiedzialność właśnie również na tym aspekcie spoczywa.

I dzisiaj dotkniemy takiego tematu, który nazywaliśmy sobie Secure by Design, który jest tematem wielowarstwowym, natomiast mam wrażenie, że tutaj w ramach naszej rozmowy okaże się, że zadbanie o kilka tych aspektów, które składają się na Secure by Design jest istotne nie tylko dla jakości, ale właśnie dla bezpieczeństwa wytwarzanego oprogramowania. To co Łukasz, może parę słów o Secure by Design?

 

Tak, Secure by Design to taka filozofia projektowania oprogramowania, która kładzie nacisk właśnie na bezpieczeństwo i mówi o tym, że to bezpieczeństwo ma być takim obywatelem pierwszej klasy tutaj, czyli czymś, o czym myślimy w pierwszej kolejności i które ma w tym naszym całym procesie rozwoju oprogramowania pierwszeństwo przez wszystkimi innymi aspektami.

I tutaj też są różne takie filozoficzne podejścia właśnie by design, np. alternatywą jest Quality by Design, czyli np. takie podejście, gdzie to jakość jest tym obywatelem pierwszej klasy. One oczywiście ze sobą konkurują, ale też mogą także działać obok siebie i siebie nawzajem wspierać.

 

Synergie tworzyć, prawda?

 

Tak, różne synergie. Taką najważniejszą składową tego Secure by Design wydaje mi się takie podejście, które się nazywa Secure by Default. Tutaj jest taka drobna różnica w tym słowie Design – Default. Czyli default, domyślne jakieś ustawienia, domyślna konfiguracja systemu powinna być tą najbezpieczniejszą wersją.

I tutaj są różne też takie flavors tych by default, np. takie w tej chwili świecące, myślę, swoje złote czasy to jest Privacy by Default. To jest zasada, która bezpośrednio tutaj pochodzi z tej dyrektywy RODO i która mówi właśnie, że ta prywatność ma być tym, wokół czego budujemy nasze oprogramowanie.

Natomiast jest także tutaj takie podejście jak Quality by Design, gdzie pierwsze skrzypce powinna grać w tym całym naszym procesie jakość.

 

Myślę, że to by Design, które jest częścią składową tych nazw, jest istotne, bo to oznacza, że myślimy o tych aspektach, zanim podejmujemy się ich implementacji. Czyli myślimy o bezpieczeństwie, myślimy o jakości, myślimy o prywatności.

Powiedziałeś, że częścią składową tego podejścia Secure by Design jest Secure by Default, czyli takie założenie, że domyślna konfiguracja, domyślne ustawienia software’u są wersją najbezpieczniejszą. W praktyce bardzo często oznacza to, że te opcje, które są standardowo uruchomione, włączone, dostępne, są wersjami najbardziej okrojonymi, bo pewnie każdy, kto trochę software’u napisał, wie, że im rozleglejszy system, im więcej tego software’u jest, tym większa szansa na jakieś podatności.

Tak że w tym podejściu właśnie Secure by Default mamy włączone te opcje, które są najbardziej i przetestowane, i bezpieczne, i mogą stanowić najmniejsze zagrożenie, można powiedzieć, dla użytkownika.

 

Myślę, że takim najprostszym przykładem jest logowanie, i tutaj two-factor authentication, które powinno być uruchomione jako domyślna wartość, natomiast jedynie możemy dać użytkownikom, powiedzmy, tę możliwość, żeby z tego zrezygnować, a nie odwrotnie, czyli domyślnie samo hasło, a dajemy użytkownikom możliwość łączenia, bo to wszystko wynika po prostu z natury ludzkiej i z tego, że z natury jesteśmy wszyscy leniwi i w większości przypadków te defaultowe opcje nas zadowolą, a nie będziemy chcieli wykonać dodatkowej pracy, dodatkowego zadania, które polega na tym, żeby włączyć takie podwójne uwierzytelnienie.

 

Tak, dokładnie. Niechaj pierwszy rzuci kamień, kto nie miał na swoim routerze hasła adminadmin przez dłuższy czas tego defaultowego. Tak samo w systemach różnego typu, różnej skali właśnie te standardowe ustawienia potrafią funkcjonować dosyć długo, to jest oczywista furtka.

Przy tym punkcie chciałem zaznaczyć, że to Security by Design, czy nawet Secure by Default to są rzeczy, które wychodzą szerzej poza samo oprogramowanie, tzn. oprogramowanie jest tutaj częścią składową, ale żeby cały system mógł być w ten sposób zabezpieczony w jakimś stopniu, to musimy pomyśleć o innych aspektach. Musimy też pomyśleć o architekturze, musimy pomyśleć o infrastrukturze, o testach, o przechowywaniu tych różnych credentiali, dzielenia się secretami itd.

W związku z tym najczęściej to podejście funkcjonuje na różnych płaszczyznach. Od sieci, defaultowy na przykład Linux bez nasłuchiwania portów, dajmy na to, poprzez systemy, o których tutaj powiedziałeś, czyli niedopuszczanie pustych haseł albo brak tego domyślnego adminadmin, który funkcjonuje, po nawet sprzęt. Bo tutaj np. to, o czym mówiłem, o tych routerach i haśle adminadmin, prawda? Więc to jest szersze nieco zagadnienie, mam wrażenie.

 

Tak, to też jest ciekawe zagadnienie w kontekście sprzętu. Zauważ, że kiedyś, parę lat temu, jak kupowaliśmy router, no to właśnie domyślne hasło na nim było pewnie adminadmin albo tego typu jakieś rozwiązanie. Natomiast teraz, jak kupuję router, to mam na nim wydrukowane takie indywidualne hasło pierwszorazowe, które dla każdej sztuki tego urządzenia jest inne, i to też jest właśnie taka implementacja tej zasady Secure by Default przez producentów sprzętu sieciowego.

Zauważ, że kiedyś, parę lat temu, jak kupowaliśmy router, no to właśnie domyślne hasło na nim było pewnie adminadmin albo tego typu jakieś rozwiązanie. Natomiast teraz, jak kupuję router, to mam na nim wydrukowane takie indywidualne hasło pierwszorazowe, które dla każdej sztuki tego urządzenia jest inne, i to też jest właśnie taka implementacja tej zasady Secure by Default przez producentów sprzętu sieciowego.

 

Tak, często się podaje też taką sprzeczność albo taki nieco mam wrażenie negatywny wpływ tego podejścia właśnie Secure by Default na przyjazność użytkowania systemu, bo to, że my wyłączymy wiele z tych opcji standardowo, czyli damy taką bardzo odchudzoną wersję systemu na początku, może powodować właśnie to, że użytkownik musi się gdzieś tam doklikać, coś tam włączyć, jakiegoś checkboxa zaznaczyć, więc ta przyjazność dla użytkownika może być nieco zmniejszona.

Natomiast tutaj znowu wracamy do tego Secure by Design podejścia, gdzie musimy wyważyć, musimy znaleźć jakiś balans pomiędzy tym, że chcemy być przyjaźni dla użytkownika vs, że chcemy mu po prostu zapewnić bezpieczeństwo.

 

Tak, no to jest odwieczny konflikt między UX-em i tą łatwością użytkowania systemu, a ryzykiem. Tutaj zawsze oczywiście trzeba to odpowiednio wyważyć, trzeba też zwrócić uwagę, dla jakich użytkowników ten produkt budujemy, dla jakich zastosowań, jakie dane tam będziemy przetwarzać. I wtedy ten poziom ryzyka, na jaki się godzimy, może być inny. Co innego jeśli przetwarzamy dane medyczne, a co innego jeśli przetwarzamy zdjęcia kotów.

 

Tak, czyli to zależy, standardowo. Ale też nie chciałbym, żeby tutaj po naszej rozmowie powstało takie wrażenie, że to programiści są całościowo albo w większości odpowiedzialni za bezpieczeństwo systemu, czy też oprogramowania, bo to jest problem znacznie szerszy i wiele osób w różnych rolach w zespole ma na to bezpieczeństwo wpływ.

I taki myślę przykład podejścia, które ostatnio coraz częściej gdzieś wchodzi na salony, czyli DevSecOps jest tutaj bardzo zasadne, bo tutaj możemy uzyskać pewną pomoc ze strony właśnie osób w roli Security Officer albo właśnie DevOps dla programistów. Takiej pomocy, która właśnie w tym podejściu Shift-left pozwoli szybciej, sprawniej znajdować pewne luki, problemy i właśnie wyłapywać je na tym bardzo wczesnym etapie powstawania oprogramowania, kiedy nie tylko ich wyłapanie, ale też mitygacja tych problemów, ich rozwiązanie będzie po prostu najtańsze i wpływ najmniejszy.

 

Tak, ale też tutaj dochodzi kwestia automatyzacji i też tego, że rzeczywiście jeśli ktoś robi coś ręcznie, to wiadomo, że ryzyko tutaj popełnienia błędu jest dużo wyższe, niż jeśli coś zautomatyzujemy i też dużo wygodniej i częściej możemy puścić taki skaner, który tam np. kod w repozytorium przejrzy automatycznie.

 

Zgadza się. Ale nie wiem, czy się tutaj ze mną zgodzisz: mam wrażenie, że programiści najczęściej jednak mają pewne luki w wiedzy, w umiejętnościach związanych z security. To nie jest taka rzecz standardowa. To nie wchodzi, mam wrażenie, jako takie właśnie defaultowe narzędzie do tego narzędziownika programistów. W związku z tym pewnie trzeba się szkolić, poszerzać swoją wiedzę, trzeba obserwować różnego typu trendy, które się dzieją na rynku w cyberbezpieczeństwie, żeby wiedzieć po prostu, z czym mamy do czynienia, prawda?

 

Tak, to też tutaj choćby dyrektywa RODO mówi to samo, że bezpieczeństwo to nie jest coś, co można zrobić, tylko to jest proces. On cały czas trwa, cały czas trzeba dokonywać przeglądów, cały czas trzeba poszerzać swoją wiedzę, cały czas trzeba zwiększać poziom tego bezpieczeństwa, to nie jest coś, co można odhaczyć, że jest gotowe.

 

Zgadza się. Myślę, że warto by tutaj było podać kilka takich zasad, które pozwolą słuchaczom podjąć jakieś decyzje albo przynajmniej zwrócić uwagę na pewne aspekty wytwarzanego oprogramowania, bo myślę, że od świadomości by trzeba było zacząć, jeśli przynajmniej jesteśmy świadomi potencjalnych ryzyk w bezpieczeństwie, które gdzieś są efektem naszej pracy, to łatwiej nam będzie im zapobiegać albo gdzieś je eliminować. Więc co Ty na to, żebyśmy o kilku takich podstawowych zasadach tutaj dla tej reguły powiedzieli?

 

Ogólnie taki Secure by Design składa się z czterech fundamentów. Pierwszym fundamentem jest właśnie ten Secure by Default, czyli ustawienie bezpiecznych wartości defaultowych. I jako przykład mogę podać kontroler, który domyślnie powinien wymagać tego, żeby użytkownik był uwierzytelniony. Czyli nie robimy tak, że musimy dodać np. atrybut authorize i wtedy ten kontroler będzie dopiero wymagał uwierzytelnienia, tylko musimy zrobić odwrotnie. Jeśli byśmy chcieli, żeby dany endpoint był publiczny, to wtedy musimy dodać na przykład jakiś parametr public.

Czyli odwrotnie niż domyślnie jest np. w takim ASP.Necie. Bardziej się wzorujemy na takim modelu białej listy, tak jak to jest np. przy konfiguracji firewalli. Oczywiście to wymaga pewnej naszej pracy, tak żeby odpowiednio sobie to wszystko skonfigurować, jakieś filtry porobić itd.

Kolejna zasada to zasada ograniczonego zaufania. Może podam taki przykład: jeśli chcemy otrzymać jakiś zasób, to powinniśmy użyć co najmniej dwóch niezależnych elementów, które pozwolą nam zautoryzować ten zasób. Czyli też chodzi o to, żebyśmy tutaj eliminowali takie pomyłki programistyczne, że ktoś w kodzie coś wyciągnie z repozytorium i zapomni np. jakiegoś sprawdzenia tej autoryzacji do jakichś danych.

I np. mamy taki sklep internetowy, jest tam sobie repozytorium jakichś itemów i chcemy wyciągnąć dla użytkownika zamówienia. Możemy to zrobić na dwa sposoby. Pierwszy, który pewnie większość z nas by zaimplementowała, czyli wyciągamy po ID zamówienia i wtedy użytkownikom wyświetlamy te itemy na tym zamówieniu. Natomiast inny sposób, lepszy, to usuwamy z tego repozytorium tę metodę, która pozwala wyciągnąć po ID i dodajemy nową, która wymaga zarówno tego ID zamówienia, jak też ID użytkownika, czyli teraz muszą być dwa elementy, ten użytkownik i ID zamówienia. W ten sposób jakby gwarantujemy, że nigdy nie wyciągniemy z tego repozytorium zamówienia i nie pokażemy go błędnemu użytkownikowi, bo zawsze ten ID użytkownika będzie wymagany.

Trzecia z tych podstawowych zasad to jest zasada tworzenia granic zaufania. Brzmi to dość, powiedziałbym, mądrze albo trudno, natomiast polega to na tym, żebyśmy schowali zasoby, które chcemy chronić, i na zewnątrz wystawiali tylko to, co jest rzeczywiście niezbędne. Np. mamy maszynę z IIS-em wystawioną do internetu, a już maszyna z bazą danych jest schowana w sieci lokalnej i ten IIS z tą bazą danych tylko ma dostęp jakby po tej sieci wewnętrznej, czyli ta baza danych nie ma dostępu do internetu.

I teraz bardzo podobna zasada do tej poprzedniej, już ostatnia tutaj z tych najważniejszych zasad, czyli zasada minimalizacji obszaru ataku, czyli tak jak nazwa wskazuje – minimalizujemy miejsca, z których może dojść po prostu do jakiegoś wycieku danych czy jakiegoś problemu.

I teraz przykład: mamy sobie aplikację webową, ale mamy też do niej panel administratora, czyli admin ma jakieś tam wyższe uprawnienia, może tam nagrzebać. I nie robimy tego w formie jednej aplikacji, tylko robimy to w formie po prostu dwóch niezależnych aplikacji i ten klient, ta właściwa aplikacja, do której mają zwykli użytkownicy dostęp, nie ma w ogóle po prostu tutaj nic do czynienia z tymi administracyjnymi elementami, a elementy administracyjne schowaliśmy w drugiej aplikacji, która może być też np. dodatkowo chroniona poprzez schowanie jej w sieci lokalnej.

Ogólnie taki Secure by Design składa się z czterech fundamentów. Pierwszym fundamentem jest właśnie ten Secure by Default, czyli ustawienie bezpiecznych wartości defaultowych. I jako przykład mogę podać kontroler, który domyślnie powinien wymagać tego, żeby użytkownik był uwierzytelniony. Czyli nie robimy tak, że musimy dodać np. atrybut authorize i wtedy ten kontroler będzie dopiero wymagał uwierzytelnienia, tylko musimy zrobić odwrotnie. Jeśli byśmy chcieli, żeby dany endpoint był publiczny, to wtedy musimy dodać na przykład jakiś parametr public.

 

Właśnie, to jest bardzo dobry przykład. Może to też być schowane za VPN-em, w związku z tym ten poziom bezpieczeństwa, poziom dostępu jest znacznie wyższy niż w przypadku takiej ogólnodostępnej aplikacji.

Ja bym tutaj pokusił kilka przykładów, bo te zasady bardzo fajnie brzmią, natomiast z mojej obserwacji, z mojej praktyki wygląda to tak, że często mamy problem z wdrożeniem właśnie tych zasad w naszą konkretną pracę, w nasze konkretne projekty.

Powiedziałeś tutaj o tym, separować panel administracyjny od aplikacji, żeby to była osobna de facto aplikacja, gdzieś tam bardziej schowana, bardziej bezpieczna. Mówiliśmy też o tym, że np. włączenie tego dwuskładnikowego uwierzytelniania albo multi FA powinno być takim podejściem by Default, a jedynie możemy je wyłączyć, prawda? Jakie jeszcze przykłady przychodzą Ci do głowy z tych projektów, które gdzieś tam realizowałeś albo obserwowałeś, które właśnie w takim podejściu Secure by Design można tutaj podać?

 

To może zdradzę tutaj parę smaczków, jeśli chodzi o projekt, który tutaj tworzymy, czyli SolidJobs. Pierwsze nasze podejście było takie, że nie chcemy mieć w ogóle haseł użytkowników w systemie. W ogóle rezygnujemy z haseł użytkowników. Dlaczego w ten sposób? Ponieważ użytkownicy po prostu z tych haseł korzystają tych samych w różnych systemach. I teraz ja wiem, że mój system jest bezpieczny, ale nie jestem w stanie tego zagwarantować, jeśli chodzi o jakieś zewnętrzne systemy. I teraz, jeśli wycieknie hasło z jakiegoś obcego systemu, to automatycznie ten atakujący mógłby spróbować tymi samymi credentialami zalogować się także u nas w systemie. W ten sposób, jeśli nie będzie tego hasła u nas, nie będzie tego problemu, eliminujemy go.

I tutaj np. stosujemy to podejście passwordlessowe, czyli za każdym razem są dwie możliwości. Jedna jest taka, że potrzebujesz swojego maila, za każdym razem na maila dostajesz jakiś token, który pozwala Ci się uwierzytelnić. Drugie podejście to jest oczywiście SSO i używanie jakichś tutaj zewnętrznych providerów, np. Google’owego. W ten sposób po prostu pomijamy w ogóle konieczność trzymania haseł u nas w systemie.

Jeszcze może podam drugi ciekawy przykład, czyli też zasoby między sobą, jeśli to oczywiście jest możliwe, nie autoryzujemy za pomocą różnych sekretów, haseł, czegoś, co trzeba wymieniać, tylko staramy się np. w chmurze Azure wykorzystywać manage identity. Wiem, że w innych chmurach są podobne rozwiązania, czyli po prostu już sam Azure AD czy teraz Entra pilnuje tego, które zasoby mają do czego nawzajem dostęp. Np. aplikacja ma dostęp do bazy danych, nie po jakimś tam connection stringu, tylko właśnie dzięki temu, że ten Azure AD jest tym miejscem, które po prostu daje tę tożsamość i mówi, do czego ma dostęp.

 

Tutaj taką główną osią tej naszej serii podcastów jest Software Craftmanship i myślę, że taką dobrą praktyką tego software inżyniera jest też dbanie o to, jakie biblioteki zostały wcześniej włączone do projektu, dbanie o ich aktualizację. Tutaj oczywiście w kontekście naszego odcinka, zwłaszcza pod kątem łatek bezpieczeństwa. Zależy oczywiście od technologii, które używamy, ale są takie obszary jak np. web development, gdzie faktycznie tych zależności jest mnóstwo i dbanie o to, żeby w sposób przynajmniej jakiś tam zautomatyzowany uaktualniać, jest bardzo dobrą praktyką.

 

Tak, to jeszcze z innych przykładów. Teraz bardzo często spotykamy się z czymś takim jak aplikacja wielotenantowa, czyli jest jedna aplikacja i jest osobna, nazwijmy to, instancja dla każdego klienta. W takim przypadku można to zrobić na dwa sposoby, jeśli chodzi o kwestie bazy danych. Możemy mieć dedykowaną bazę danych dla każdego klienta, a możemy mieć jedną bazę danych i jakieś po prostu kolumny w tych tabelkach, które mówią, do kogo należą te wiersze w tabelce.

Pewnie pod względem kosztu lepiej mieć jedną bazę danych, ale pod względem bezpieczeństwa jednak ta wielobazodanowość przy tej wielotynantowości jednak jest bezpieczniejsza, a też skaluje się oczywiście to lepiej.

Teraz bardzo często spotykamy się z czymś takim jak aplikacja wielotenantowa, czyli jest jedna aplikacja i jest osobna, nazwijmy to, instancja dla każdego klienta. W takim przypadku można to zrobić na dwa sposoby, jeśli chodzi o kwestie bazy danych. Możemy mieć dedykowaną bazę danych dla każdego klienta, a możemy mieć jedną bazę danych i jakieś po prostu kolumny w tych tabelkach, które mówią, do kogo należą te wiersze w tabelce.

 

Jasne, to jest oczywiście wszystko bardzo ważne, o czym tutaj powiedziałeś. Natomiast myślę, że często zapominamy o tym, że oprócz software’u, który tworzymy, mamy też mnóstwo rzeczy, które powstają podczas korzystania z naszego software’u. I to są np. różnego typu logi zdarzeń, różne alerty, błędy, które gdzieś wysyłamy.

Myślę, że zadbanie o ten obszar w kontekście bezpieczeństwa, takim też rozumieniem compliance’owym jest istotne, żebyśmy nie tylko jednak pamiętali o zabezpieczeniu tych danych, ale również zastanawiali się, czy faktycznie wszystkie te dane, które gdzieś do naszej aplikacji wpływają, musimy niejako zewnętrznie przesyłać, pokazywać właśnie w różnego typu alertach, tag trace’ach, różnego typu logach, które tworzymy.

 

Tak i jeszcze pamiętajmy, że najsłabszym tutaj ogniwem zawsze jest człowiek i może to będzie ten moment, gdzie jakąś polecajkę tutaj książki byśmy wrzucili tradycyjnie już. Taka myślę, jeśli chodzi o filozofię podejścia w ogóle do bezpieczeństwa, książka, która mnie najbardziej otworzyła oczy, czy zrobiła taki efekt wow, to myślę, że jednak to ta Sztuka podstępu Kevina Mitnicka. Bardzo tutaj byśmy chcieli pewnie polecieć.

 

Zdecydowanie. Bardzo ciekawa lektura o tym, jak człowiek właściwie łamał ludzi, a nie hasła i systemy, jak to mówił. Zdecydowanie pokazująca, że najczęściej to człowiek jest najsłabszym elementem systemu. Ale myślę sobie, tak już zmierzając powoli w kierunku podsumowania, że to też nasza rola jako twórców tych systemów, żeby stworzyć je w ten sposób, aby człowiek nie był tym najsłabszym elementem, żeby zadbanie o bezpieczeństwo, te standardowe ustawienia, ta defaultowa konfiguracja mimo wszystko przynajmniej jakoś utrudniała problemy z bezpieczeństwem.

Dobrze, Łukasz, to co? Może kilka słów podsumowania tego, o czym dzisiaj rozmawialiśmy?

 

Tak, rozważcie w trakcie Waszej tutaj pracy, żeby ten Secure by Design wdrożyć w Wasz cykl rozwoju oprogramowania. Czyli pamiętajcie, że tu chodzi o to, żeby to bezpieczeństwo było nie tam na początku tylko, jakby może ta nazwa by sugerowała, tylko właśnie powinno być ono w całym cyklu, no choćby w code review, czy jednym z elementów np. code review jest przejrzenie tego kodu pod względem bezpieczeństwa.

Tak że pamiętajcie, że są tutaj różne inne podejścia właśnie by Default i by Design. Zobaczcie, po prostu zróbcie jakiś mały research, co w Waszym przypadku ma największy sens, bo pamiętajcie, że podejście należy wybrać w stosunku do tego, co robicie, jaki system tworzycie, dla kogo go tworzycie, jakie dane przetwarzacie. Spróbujcie stosować te defaultowe zasady bezpieczeństwa. Myślę, że tutaj fajnie je przedstawiliśmy.

 

Zdecydowanie. Myślę sobie, że powiedziałeś tutaj o tym, że możemy myśleć o quality jako tym najważniejszym elemencie, o który powinniśmy zadbać, ale bezpieczeństwo czy zadbanie o bezpieczeństwo na koniec dnia przekłada się też na to, że i jakość oprogramowania będzie wyższa, i na koniec dnia jeszcze my jako twórcy tych systemów będziemy mieli po prostu mniej problemów, mniej błędów do naprawy. Im wcześniej o to gdzieś tam zadbamy, tym szybciej nam się to zwróci.

 

Tak, pamiętajmy też, że to bezpieczeństwo to też jest część składowa tej jakości. To nie jest tak, że ta jakość to jest coś obok.

 

Zdecydowanie.

 

Tak że Krzysztofie, dziękuję Ci za dzisiejszą rozmowę. Jak myślisz, o czym możemy porozmawiać w kolejnym odcinku?

 

Tak, dzięki, Łukasz. Myślę, że spróbujemy spojrzeć na to, co wydaje się taką kompletną podstawą i co wydaje się, że każdy z programistów gdzieś tam ma opanowane i używa. Zastanowimy się, czy aby na pewno tak jest, a myślę tutaj o programowaniu obiektowym Object Oriented Programming. Spojrzymy na ten aspekt właśnie z perspektywy Software Craftmanshipu.

Super. Tak że Łukasz, wielkie dzięki jeszcze raz z mojej strony za spotkanie, za tę rozmowę. Oczywiście wszystkich słuchaczy zapraszam do przesłuchania wcześniejszego odcinka z tej serii i do całej wcześniejszej serii, gdzie mówiliśmy o narzędziach programistów.

Osoby szukające pracy zapraszamy na SolidJobs, gdzie znajdziecie oferty zawsze z widełkami wynagrodzeń i być może też będziecie zainteresowani tym, żeby tam wystawić właśnie swoje ogłoszenie, jeśli macie w tej chwili w swojej firmie, w swoim projekcie taką potrzebę.

Tak że Łukasz, wielkie dzięki z mojej strony i do usłyszenia. Cześć!

 

Dzięki, cześć.