10 postów z tagiem "DevSecOps"

Ukończyłem LFD140 „GitHub for Open Standards Development" od The Linux Foundation. Kurs uczy, jak przenieść zasady grupy roboczej do repozytorium: kto zatwierdza zmianę normatywną, którą gałęzią idzie specyfikacja do ratyfikacji, gdzie zapisać sprzeciw i jak wymusić to ochroną gałęzi i CI. Ten model uważam za dobry i wart przeniesienia także poza fundacje open source. Przykładowe bramki GitHub Actions z materiałów kursu uruchomiłem jednak lokalnie, na odtworzonym checkoucie pull requesta. Z pięciu skryptów żaden nie działa poprawnie w podanej postaci. Dwie kontrole CHANGELOG przepuszczają zmianę w specyfikacji bez wpisu, dwie bramki blokują PR-y, które powinny przejść, a krok sprawdzający etykietę przechodzi zawsze. Próg „dwóch zatwierdzeń" liczy recenzje zamiast recenzentów. Poniżej opisuję, co z kursu warto wziąć, co w przykładach nie działa i jak wyglądają poprawione wersje.

„Bezpieczny vibe coding” w sensie właściwości modelu nie istnieje. Asystent kodu wykonuje polecenia z każdego tekstu, który trafi mu do kontekstu: z README, z treści issue, z dokumentacji pobranej z sieci. Nie da się mu tego wyperswadować promptem. Bezpieczny może być natomiast układ wokół asystenta: co agent widzi, do czego ma dostęp, dokąd może coś wysłać i co sprawdza kod, zanim trafi na produkcję. Ten wpis jest przewodnikiem po takim układzie: śmiertelna triada, halucynowane paczki, zasada najmniejszych uprawnień w IDE i bramki w CI/CD. Na końcu jest krótko o kursie Linux Foundation LFEL1012, po którym go spisałem.

Jako inżynier bezpieczeństwa, który zaczynał od analizy pakietów w Wiresharku i ręcznego „fuzzowania” formularzy, z pewnym sentymentem wspominam rok 2005. Wtedy bezpieczeństwo aplikacji webowych opierało się na naiwnym zaufaniu do protokołów GET i POST. Parametry w URL-u były dosłownie zaproszeniem do przejęcia bazy danych (SQLi), a brak walidacji po stronie serwera był normą, nie wyjątkiem. Królowała era monolitycznych systemów, w których jedna luka w kodzie oznaczała natychmiastowe RCE (Remote Code Execution). Zamiast podejścia Secure by Design, żyliśmy w świecie „perymetrycznej obrony”, wierząc, że firewall ochroni nas przed wszystkim.

Mam VPS z kilkoma usługami dockerowymi: WireGuard, Pi-hole, n8n, SonarQube, środowisko staging dla mojego projektu. Przez długi czas jedynym "monitoringiem" było SSH i docker ps. Postanowiłem to zmienić.

Ten wpis to kopalnia wiedzy z mojego wdrożenia — dowiesz się z niego, jak poprawnie skonfigurować cały stack i jak poradzić sobie z wyzwaniami, które mogą pojawić się w nowoczesnych środowiskach Docker (jak Ubuntu 24.04). To nie jest zwykły tutorial "kopiuj-wklej", ale praktyczny przewodnik po tym, jak sprawić, by monitoring na VPS naprawdę działał.

Jako programiści często wpadamy w pułapkę dokładania kolejnych narzędzi i skanerów do naszych pipeline'ów w CI/CD, nie zważając na to, jak mocno wydłuża to czas trwania całego procesu. Chcemy mieć zrobiony linting, przetestowany kod (zarówno jednostkowo, jak i E2E), jakość potwierdzoną przez SonarQube i wreszcie bezpieczeństwo obrazów Dockerowych za pomocą Trivy.

W automatyzacji testów samo "passing green" to tylko połowa sukcesu. Prawdziwym wyzwaniem jest visibility i redukcja czasu potrzebnego na debugowanie. W moim projekcie reads wdrożyłem zaawansowany system raportowania, który zamienia surowe logi w czytelną mapę drogową jakości. Zamiast analizować konsolę, dostajemy pełny wgląd w stan aplikacji w czasie rzeczywistym po każdym wdrożeniu.

Projekt reads ewoluuje. To już nie tylko proste narzędzie do zakładek, ale poligon doświadczalny dla nowoczesnych standardów dostarczania oprogramowania. Choć demo znajduje się obecnie w fazie koncepcyjnej (zarządzanie zakładkami i moduł logowania są w trakcie wdrażania), już teraz możesz zobaczyć, jak realizujemy podejście Automation First i Secure by Design w praktyce.

Sprawdź demo (Staging) ↗](https://reads-staging.baluarte.pl/)

Automatyzacja kontroli jakości kodu to dziś standard, ale co jeśli Twoja infrastruktura jest "zbyt" bezpieczna? W tym artykule opisuję naszą inżynieryjną przeprawę z integracją SonarQube i GitHub Actions, gdzie największym wyzwaniem okazał się... nasz własny system bezpieczeństwa.

Każda lista "must-have tools for code quality" zaczyna się tak samo. SonarQube. Branżowy standard. Quality Gates. Technical Debt. Cognitive Complexity. Sześć tysięcy wbudowanych reguł.

Średni koszt naruszenia ochrony danych wynosi obecnie ponad 4,4 miliona dolarów, a ręczne łatanie luk drastycznie obciąża budżety operacyjne organizacji. Odpowiedzią na te wyzwania jest zautomatyzowane podejście DevSecOps realizowane przez GitHub Advanced Security (GHAS), które osadza procedury ochronne bezpośrednio w cyklu życia oprogramowania (SDLC). Zastosowanie zaawansowanej automatyzacji i wczesnej analityki kodu znacząco obniża ryzyko biznesowe, uwalnia moce przerobowe inżynierów i gwarantuje wymierny, wielokrotny zwrot z poczynionych inwestycji.