Security to temat, który większość devów odkłada na potem. Do pierwszego incydentu. Potem jest za późno na spokojne wdrożenie — jest tryb gaszenia pożaru, post-mortem i klient, który pyta dlaczego jego dane wyciekły. Ten artykuł to praktyczny przewodnik, który możesz wdrożyć już dziś — od analizy statycznej, przez skanowanie zależności, aż po CI/CD pipeline, który sam pilnuje bezpieczeństwa.
Dlaczego security ląduje na końcu listy
To nie jest kwestia złej woli. Security nie daje natychmiastowego feedbacku — nie widzisz efektów tak jak przy nowej funkcji. Nie ma sprintu pod tytułem "dodaj bezpieczeństwo". W efekcie każdy zakłada, że ktoś inny się tym zajął.
Problem jest systemowy: większość zespołów wdraża security reaktywnie. Audyt bezpieczeństwa ląduje w backlogu razem z innymi "nice-to-have" dopóki coś nie pójdzie nie tak. A kiedy pójdzie — koszty są nieporównywalnie wyższe niż gdyby to było wbudowane od początku.
Dobra wiadomość: tooling jest dziś na tyle dojrzały, że można zautomatyzować 80% roboty. Bez dedykowanego security engineera, bez tygodnia pracy.
Krok 1: Statyczna analiza kodu (SAST)
Statyczna analiza to pierwszy filtr — skanujesz kod zanim jeszcze uruchomisz aplikację. Narzędzia analizują AST (Abstract Syntax Tree) i szukają wzorców znanych podatności.
SonarQube — open-source, możesz hostować lokalnie. Znajdzie injection, hardcoded credentials, unused variables które mogą być wektorem ataku. Integruje się z GitHub/GitLab w 15 minut.
ESLint z pluginami security — jeśli piszesz w Node.js/TypeScript, eslint-plugin-security i eslint-plugin-no-unsanitized łapią typowe błędy jak eval(), innerHTML, path traversal.
CodeQL (GitHub) — darmowe dla open-source, płatne dla prywatnych repo. Semantyczna analiza, która rozumie przepływ danych. Wykrywa podatności których prostsze narzędzia nie widzą.
Zasada: SAST w pre-commit hook + w pipeline CI. Deweloper dostaje feedback przed push, pipeline blokuje merge przy krytycznych znaleziskach.
Krok 2: Skanowanie zależności (SCA)
Twój kod może być czysty — ale biblioteki, których używasz, już niekoniecznie. Każdy projekt Node.js/Python ma setki transitive dependencies. To ogromna powierzchnia ataku.
Trivy (Aqua Security) — skanuje obrazy Docker, systemy plików, repozytoria. Wykrywa CVE w OS packages i bibliotekach aplikacji. Integruje się z CI jak każde inne narzędzie CLI.
Snyk — ma darmowy tier dla indywidualnych devów. Skanuje package.json/requirements.txt/Gemfile i sugeruje poprawki. Potrafi automatycznie tworzyć PRy z fix.
npm audit / pip-audit — wbudowane w ekosystem, zero konfiguracji. Uruchom w pipeline i ustaw threshold na --audit-level=high.
Ważne: nie ignoruj alertów. Ustaw politykę: critical/high blokuje deploy, medium/low → ticket do naprawy w następnym sprincie.
Krok 3: OWASP Top 10 — praktyczne przykłady
OWASP Top 10 to lista najczęstszych podatności webowych. Znajomość jej to minimum dla każdego dewelopera. Trzy, które widzę najczęściej w code review:
Injection (SQL, NoSQL, Command) — wciąż #1. ORM nie jest gwarancją bezpieczeństwa jeśli używasz raw queries. Zawsze parameterized queries, nigdy string concatenation w zapytaniach.
Broken Authentication — słabe tokeny, brak rotacji secrets, JWT bez weryfikacji sygnatury (alg: none). Używaj battle-tested bibliotek, nie pisz własnego auth.
IDOR (Insecure Direct Object Reference) — endpoint /api/orders/1234 zwraca zamówienie innego użytkownika jeśli nie sprawdzasz ownership. To partial authorization check — najczęstszy błąd w CRUD API.
- Injection → parameterized queries, ORM, input validation
- Broken Auth → mature lib (Passport, NextAuth), proper JWT config
- IDOR → zawsze weryfikuj ownership zasobu w middleware
- Sensitive Data Exposure → TLS wszędzie, szyfrowanie at-rest
- Security Misconfiguration → CIS benchmarks, hardened Docker images
- XSS → Content Security Policy, sanitizacja w React/Vue jest domyślna — nie obchodź jej
Krok 4: DAST — testuj jak atakujący
DAST (Dynamic Application Security Testing) działa na uruchomionej aplikacji. Wysyła złośliwe payloady i obserwuje reakcję. Uzupełnia SAST — bo niektóre podatności widać tylko w runtime.
OWASP ZAP — flagowe narzędzie. Może działać jako proxy podczas manualnego testowania lub w trybie full automated scan w CI. Baseline scan zajmuje ~5 minut i łapie nisko wiszące owoce.
Rekomendowane podejście: ZAP baseline scan w staging pipeline po każdym deploy. Full scan tygodniowo lub przed release.
Krok 5: AI-assisted code review
Modele AI nie zastąpią security engineera, ale są dobrym pierwszym filtrem podczas code review. Dobre promptowanie + model rozumiejący kod może złapać logiczne podatności, które narzędzia pattern-based przeoczają.
Praktyczne zastosowanie: CR checklist z security angle dla każdego PR który dotyka auth, payments, file uploads lub external API. AI przegląda diff i flaguje potencjalne problemy. Senior developer waliduje.
Uwaga: nie wklejaj sekretów ani wrażliwych danych klientów do zewnętrznych modeli. Self-hosted LLM lub enterprise tier z DPA.
Krok 6: CI/CD pipeline jako ostatnia linia obrony
Wszystko powyższe działa tylko jeśli jest egzekwowane automatycznie. Ręczne procesy są pomijane pod presją deadline'u.
Przykładowy pipeline security gate:
- Pre-commit: ESLint security + detect-secrets (brak hardcoded creds)
- PR: SonarQube scan → komentarz do PR z wynikami
- PR: npm audit / trivy → blokada merge przy severity >= high
- Staging deploy: OWASP ZAP baseline scan
- Weekly: full dependency audit + image scan
Kluczowe: pipeline musi blokować deploy przy krytycznych znaleziskach — nie tylko ostrzegać. Warning bez konsekwencji jest ignorowany.
Self-hosting jako model security
Jest jeszcze jeden wymiar security, o którym rzadko się mówi: kontrola nad infrastrukturą. Kiedy używasz SaaS CRM, dane twoich klientów siedzą na cudzych serwerach, pod cudzą polityką privacy, z cudzymi access controlami.
Self-hosting daje izolację tenantów na poziomie infrastruktury, pełną kontrolę nad dostępem do danych, audyt logs który ty kontrolujesz, compliance na twoich warunkach (GDPR, SOC2).
To właśnie filozofia za Khirby — open-source CRM, który możesz postawić w swojej infrastrukturze. Twoje dane, twoje serwery, twoje reguły.
Security checklist — TL;DR
- SAST: SonarQube lub CodeQL w pipeline CI
- ESLint security plugin w pre-commit hook
- Dependency scan: Snyk lub Trivy w CI (blokada przy high/critical)
- OWASP Top 10: code review checklist dla auth, CRUD, file upload
- DAST: ZAP baseline scan na staging
- Secrets detection: git-secrets lub detect-secrets
- TLS wszędzie, szyfrowanie at-rest dla danych wrażliwych
- Polityka: critical/high blokuje deploy, medium → ticket
Security to nie projekt, który kiedyś "skończysz". To praktyka — zestaw nawyków i automatyzacji, które robią robotę zanim jeszcze zaczniesz myśleć o atakach. Zautomatyzuj to co możesz, ustaw właściwe progi blokady, review ze świadomością OWASP Top 10. Reszta zadziała sama.
Czytaj też: