ABC DevSecOps – recenzja kursu

Kiedy po raz pierwszy usłyszałam o kursie ABC DevSecOps pomyślałam sobie: „nie, to zupełnie nie moja bajka”. A jednak zaryzykowałam – i pozytywnie się zaskoczyłam.

Na co dzień zajmuję się programowaniem w takich projektach, w których najbardziej zaawansowany pipeline to podpięcie repozytorium do rozwiązania typu Netlify, Render, albo zrobienie builda w Microsoft Azure. Nie jestem DevOpsem, nie mam ambicji, by nim być, Dockera się uczę a Jenkins to dla mnie technologia z kosmosu.

Myślałam, że to nie jest kurs dla mnie. Miałam jednak już okazję poznać na wylot kurs OTWA od Andrzeja Dyjaka i pomyślałam sobie, że w sumie mogę spróbować i z ABC DevSecOps. Kiedy więc na urlopie dostałam maila z informacją o możliwości zapisu na pierwszą edycję kursu, pod wpływem urlopowego optymizmu, jednak się zapisałam. Tym bardziej, że urlop pojawił się po pierwszym większym projekcie w którym był potok CI/CD z prawdziwego zdarzenia i ciekawa byłam, jak by można było go zabezpieczyć.

Urlop minął jak z bicza strzelił, temat wpadł na obrzeża pamięci. A kilka miesięcy później przyszedł mail, który wyciągnął temat z oceanu pamięci – i ruszyłam w nieznane.

Nie dla Juniora?

Pierwszy kryzys pojawił się, gdy po zalogowaniu zobaczyłam spis treści kursu. Jakieś SASTy, DASTy, analiza składu i łańcuch dostaw, tfu! Zaraza. A w tle jeszcze miga mi obrazek szczęśliwego specjalisty od Security, który nie musi sprzątać po DevOpsowym jednorożcu. Poczułam panikę i chęć natychmiastowego wymiksowania się z tego kursu, włącznie z tym, że kamera zarejestrowała na pierwszym live moje niepewne pytanie: 'ale czy junior da radę skończyć ten kurs?'.

Pierwsze zadanie o mało mnie nie zmiotło z ziemi, a komputer ledwo udźwignął pierwszy skan (16 RAM ledwo wystarczy na skan ZAP, zapamiętajcie moje słowa!). Na szczęście potem już było z górki.

Autorzy kursu dostarczyli kursantom środowisko do pracy, solidną dawkę wiedzy, a także szybko odpowiadali na pytania, tak więc mimo początkowych trudności mogłam ruszyć z działaniami, skonfigurować całe środowisko do pracy na Windows i pokonać masę drobnych przeszkód, co zaowocowało stworzeniem działającego skanu i oddaniem wszystkich wymaganych zadań.

To prekonfigurowane środowisko, mimo późniejszych drobnych kłopotów z konfiguracją (niegrzeczny WSL, niegrzeczny!) to był strzał w dziesiątkę i myślę, że oszczędził nam, uczestnikom, wiele godzin pracy nad budowaniem środowiska, a autorom wielu godzin debugowania kodu w przypadku problemów.

Mam świadomość, że gdybym miała większą wiedzę, to pewnie wycisnęłabym z kursu więcej. Natomiast ta wiedza, którą miałam, wystarczyła, by zacząć oswajać tematy, z którymi niewątpliwie w programistycznej pracy prędzej czy później się spotkam – szczególnie w kontekście budowania security w programistycznych zespołach w większych organizacjach, o czym już nie raz słyszałam rozmawiając z bardziej doświadczonymi programistami.

Kurs zrobiony z głową

To, że byłam w stanie ukończyć kurs mimo braków w wiedzy zawdzięczam nie tylko swojemu uporowi, lecz przede wszystkim temu, że Andrzej Dyjak i Krzysztof Korozej zrobili ten kurs sensownie. Tak, zaserwowali sporą dawkę wiedzy i tak, wrzucili sporo zagadnień które z mojego punktu widzenia – wciąż początkującego programisty – są zagadnieniami przynajmniej średniozaawansowanymi. Jednocześnie jednak przekazują wiedzę w sposób zrozumiały nawet dla juniora (choć nie zalecam rozpoczynania przygody z programowaniem czy bezpieczeństwem od tego kursu ; ) ).

Kolejną zaletą kursu jest to, że panowie podzielili się wiedzą praktyczną. Poza informacjami o tym, na jakim etapie tworzenia oprogramowania warto wdrożyć pewne rozwiązania, mówili również o tym, jak je wdrażać i za pomocą jakich narzędzi, uwzględniając kontekst technologiczny oraz... ludzki. W końcu bez współpracy wszystkich członków zespołu trudno jest implementować bezpieczeństwo. Opór wynikający z niezrozumienia procesów bezpieczeństwa lub tego, jak wdrażać sensownie bezpieczeństwo może wpłynąć na dewaluowanie lub ignorowanie praktyk bezpieczeństwa, a to niesie długoterminowe zagrożenie dla organizacji. Autorzy kursu i to wzięli pod uwagę, dzięki czemu kończąc kurs wiemy nie tylko, co robić, ale i jak robić, by tworzyć bezpieczniejszy kod.

Osobiście lubię kursy, które łączą wiedzę i odpowiedni mindset, który odpowiada za skuteczne implementowanie tej wiedzy. Tak więc, mimo iż siedzę w nieco innym obszarze IT, z przyjemnością kurs zrobiłam i mogę z czystym sumieniem polecać go innym.

Osobiste małe zyski

Tak jak wspominałam, gdybym była DevOpsem czy pracowała na co dzień w większym projekcie, pewnie wyciągnęłabym więcej z tego kursu. Nie zmienia to faktu, że świadomość tego, na jakich etapach tworzenia kodu warto implementować pewne „checkpointy” i dlaczego, pomogła mi zupełnie inaczej spojrzeć na moją pracę.

I choć nie działam z Jenkinsowym pipelinem, to działam z darmową wersją SemGrepa podpiętą pod wybrane repozytoria. Stworzenie dla niektórych projektów SBOM dało mi lepsze pojęcie o tym, jak istotne jest zadbanie o bezpieczeństwo na poziomie łańcucha dostaw. Po kursie sekrety nie tylko kojarzą mi się z Krzyśkiem (pun intended🤪), lecz także z tematem, w którym poza sporą dozą ostrożności potrzeba wiedzy i pomysłu, jak skutecznie poradzić sobie z wyciekiem takiego sekretu. A znajomość plusów i minusów związanych z SAST i DAST zmienia moje spojrzenie na testowanie bezpieczeństwa aplikacji.

I myślę, że po tym, jak już certyfikacyjny kurz opadł, niebawem wrócę do tej wiedzy, by jeszcze lepiej przyswoić sobie te zagadnienia. Myślę też, że gdy już trafię na bardziej zaawansowany projekt, dzięki tej wiedzy łatwiej będzie mi wdrożyć się w praktyki bezpieczeństwa i uszczęśliwić team DevSecOps: i człowieka, i jednorożca 😁!

PS: A kurs znajdziecie tu: ABC DevSecOps.