Bezpieczne wytwarzanie oprogramowania

Bezpieczne wytwarzanie oprogramowania oznacza włączenie wymagań bezpieczeństwa, analizy ryzyka, testów i kontroli jakości do całego cyklu życia aplikacji. W praktyce warto sprawdzić, gdzie w procesie powstają wymagania, kiedy zespoły wykonują modelowanie zagrożeń, jak działają bramki bezpieczeństwa w CI/CD oraz które narzędzia SAST, DAST i SCA wspierają codzienną pracę. Przykładem jest pipeline, w którym przed wdrożeniem uruchamiają się skany kodu, kontrola zależności i weryfikacja polityk bezpieczeństwa. Ten temat przerabiamy praktycznie na szkoleniu: Bezpieczeństwo aplikacji dla deweloperów.

Modelowanie zagrożeń aplikacji to uporządkowana analiza komponentów, przepływów danych i możliwych nadużyć, która pomaga wykryć ryzyka jeszcze przed implementacją lub zmianą architektury. Najpierw warto przygotować diagramy DFD albo C4, wyznaczyć granice zaufania, zidentyfikować zasoby i interakcje, a następnie sklasyfikować zagrożenia na przykład metodą STRIDE oraz ocenić ich istotność. Przykładem jest analiza API i bazy danych, w której zespół wykrywa ryzyka spoofingu, tamperingu i nadmiernych uprawnień już na etapie projektu. Jeśli chcesz przećwiczyć to krok po kroku, zobacz: Praktyczne modelowanie zagrożeń w aplikacji.

Secure code review to przeglądy kodu ukierunkowane na wykrywanie podatności, błędów logicznych i nieprawidłowych założeń bezpieczeństwa, których nie zawsze wychwytują same skanery. Warto sprawdzić punkty wejścia do systemu, operacje na danych, mechanizmy autoryzacji, walidację wejścia, obsługę błędów oraz użycie bibliotek i konfiguracji środowiskowych. Przykładem jest analiza zmian w module logowania, gdzie recenzenci weryfikują kontrolę dostępu, odporność na injection i sposób obsługi tokenów sesyjnych. Wersję warsztatową (z konfiguracją i przykładami) znajdziesz w programie szkolenia: Analiza kodów źródłowych – Secure Code Review.

Semgrep i SpotBugs służą do statycznej analizy bezpieczeństwa kodu, ale działają w innym modelu i sprawdzają się w różnych stosach technologicznych. Przy wyborze warto porównać obsługiwane języki, łatwość pisania własnych reguł, integrację z IDE i CI/CD, poziom false positive oraz to, czy potrzebujesz analizy wzorców składniowych czy bardziej wyspecjalizowanych reguł dla Javy. Przykładem jest użycie Semgrep do wielojęzykowych repozytoriów i SpotBugs z Find Security Bugs do projektów Java rozwijanych w IntelliJ IDEA. Dokładnie ten zestaw narzędzi i workflow ćwiczymy podczas szkolenia: Wykrywanie błędów bezpieczeństwa z Semgrep.

Bezpieczeństwo API polega na ograniczaniu nadużyć w warstwie interfejsów, kontroli dostępu, walidacji danych i monitorowaniu ruchu między klientami a usługami. Należy sprawdzić autoryzację obiektową i funkcjonalną, konfigurację JWT, limity żądań, CORS, nagłówki HTTP, ekspozycję danych oraz odporność na typowe błędy z OWASP API Security Top 10. Przykładem jest endpoint zwracający dane klienta, który wymaga nie tylko poprawnego uwierzytelnienia, ale też ścisłej kontroli, czy użytkownik ma dostęp do konkretnego rekordu. To jedno z zagadnień omawianych podczas szkolenia: Bezpieczeństwo API.

Bezpieczny kod w C zgodny z MISRA C opiera się na ograniczaniu konstrukcji językowych, które zwiększają ryzyko błędów implementacyjnych, niejednoznaczności i problemów z przenośnością. W praktyce trzeba sprawdzić reguły dotyczące typów, wskaźników, inicjalizacji, skutków ubocznych, preprocesora, zarządzania pamięcią oraz sposób dokumentowania odstępstw i zgodności. Przykładem jest eliminacja niejawnych konwersji typów i niebezpiecznych operacji na wskaźnikach w kodzie dla systemów wbudowanych lub zastosowań krytycznych. Ten temat przerabiamy praktycznie na szkoleniu: Bezpieczny kod w oparciu o wytyczne MISRA C.