Przejdź do głównej zawartości

Automatyzacja testów penetracyjnych i monitoringu logów dla aplikacji webowej

· 7 min aby przeczytać
Przemysław Majdak
Przemysław Majdak
Full-Stack Developer, Automation Engineer & Web Security Specialist

Niniejszy raport przedstawia kompletną, zautomatyzowaną architekturę służącą do:

  • wykonywania testów penetracyjnych typu SAST, DAST i IAST,
  • ciągłego skanowania logów w celu wczesnego wykrywania ataków i anomalii,
  • integracji obu procesów z pipeline’em CI/CD, tak aby bezpieczeństwo aplikacji było kontrolowane przy każdym commicie i wdrożeniu.

Już we wstępie warto podkreślić dwie główne korzyści omawianego rozwiązania: skrócenie czasu wykrycia podatności do minut zamiast tygodni 12 oraz radykalne ograniczenie kosztów reagowania dzięki automatycznym akcjom typu “block & alert” 3.

1. Fundamenty strategii DevSecOps​

1.1 Model „shift-left”​

Przesunięcie testów bezpieczeństwa na wczesne etapy SDLC eliminuje ponad 75% podatności jeszcze przed produkcją 2. Kluczowe fazy obejmują:

  1. Kodowanie – skan zależności i tajnych kluczy (SCA/Secret Detection).
  2. Budowanie – SAST i skan kontenerów.
  3. Testy QA – DAST, fuzzing, testy infrastruktury jako kodu.
  4. Eksploatacja – ciągłe testy regresyjne, korelacja logów, aktywna reakcja.

1.2 Ramy referencyjne​

Rekomendowany zestaw standardów to: OWASP ASVS do testów aplikacyjnych 4, MITRE ATT&CK do modelowania zagrożeń oraz CIS Controls w warstwie logowania 5.

2. Zautomatyzowane testy penetracyjne​

2.1 Static Application Security Testing (SAST)​

  • Semgrep/Gitleaks – skany regułowe w czasie kompilacji wychwytują błędy kryptografii i wycieki sekretów 6.
  • OWASP Dependency-Check/Safety – CVE w bibliotekach blokują build przy CVSS ≥ 7 7.

2.2 Dynamic Application Security Testing (DAST)​

  • OWASP ZAP AF – plik YAML opisuje pełny crawl i aktywny skan; można go uruchomić w kontenerze “zap2docker-stable” z poziomu GitHub Actions 89.
  • Nuclei – ultraszybki skaner szablonów YAML; w pipeline CI można wymusić zatrzymanie wdrożenia przy trafieniu krytycznym 1011.
  • Burp Suite CLI – dla testów logiki biznesowej; rozszerzenia BCheck/Burp Bounty automatyzują testy pasywne i aktywne 12.

2.3 Interaktywne testy (IAST)​

Dodatkowa warstwa agentów (np. Contrast IAST) podłącza się w czasie testów E2E i oznacza luki, których nie wychwytuje sam DAST.

2.4 Testy infrastruktury i kontenerów​

  • Trivy/Clair – analiza obrazów Docker, K8s manifests, Helm Charts 7.
  • tfsec/Checkov – scanning Terraform, CloudFormation, Pulumi pod kątem błędów konfiguracji 13.

2.5 Orkiestracja pipeline​

Przykładowy plik .gitlab-ci.yml lub GitHub Workflow powinien zawierać etapy sast, sca, container-scan, dast i iac-scan, z zasadą fail-fast dla poziomów wysokich i krytycznych 714.

3. Automatyczne skanowanie i korelacja logów​

3.1 Wymagania regulacyjne​

Logi muszą zapewniać nienaruszalność (WORM), sygnaturę czasu i możliwość korelacji z danymi z testów 15.

3.2 Architektura ELK + Wazuh​

Połączenie Filebeat → Logstash → Elasticsearch zapewnia skalowalny transport i parsowanie logów (Grok, dissect) 1617. Nad nim warstwa Wazuh pełni funkcję HIDS, FIM, SIEM i modułu Active Response 183.

Przepływ:

  1. Agenci Filebeat wysyłają JSON z aplikacji oraz system-audit.
  2. Logstash wzbogaca zdarzenia o GeoIP, identyfikatory CVE i tagi środowiskowe 1719.
  3. Elasticsearch utrzymuje indeksy security-logs-* z retencją 90 dni 16.
  4. Wazuh Manager analizuje strumień zdarzeń w czasie rzeczywistym, łącząc je z własnymi regułami (np. brute-force, SQLi, LFI) 20.
  5. Active Response wyzwala akcje takie jak host-deny lub firewall-drop dla IP o wysokiej reputacji ryzyka 3.

Architectural diagram showing Wazuh agents collecting and feeding data into a Wazuh server cluster.

Architectural diagram showing Wazuh agents collecting and feeding data into a Wazuh server cluster.

3.3 Alerting i SOAR light​

Rule-Engine Wazuh przypisuje poziomy 0-15; dla poziomu ≥ 7 wysyłamy powiadomienia do SIEM/Slack/Jira oraz uruchamiamy playbook SOAR (np. izolacja hosta) 213.

3.4 Wykrywanie anomalii AI/ML​

Przy wolumenie > 100 GB logów / dobę klasyczne reguły nie wystarczą. Integracja z modułem Loglizer lub ML job Elastic (Machine Learning jobs) umożliwia detekcję odchyleń bez etykiet 222324.

3.5 Przykładowe reguły bezpieczeństwa​

| Cel | Wzorzec Grok/Regex | Próg | Akcja | | :--------------- | :------------------- | :---------------------- | :--------------- | ------------------ | ------------ | | Atak brute force | Failed password | authentication failure | 5 × w 5 min | blokada IP 1 h | | Próba SQLi | (?i)(union.\*select | drop table) | 1 | izolacja kontenera | | XSS | (?i)(<script | javascript: | onerror=) | 1 | alert wysoki | | Escalacja sudo | sudo:.*COMMAND=.* | 3 × w 10 min | eskalacja do SOC |

4. Integracja testów i monitoringu​

4.1 Korelacja wyników DAST z logami​

  • Identyfikator skanu (scan-id) trafia jako nagłówek HTTP; Logstash zapisuje go w polu zap_scan_id.
  • Jeśli Wazuh wykryje exploit zbieżny z aktywnym testem, incydent oznaczany jest statusem benign_test- w ten sposób unikamy false-positive 821.

4.2 Harmonogram regresji​

Cron pipeline uruchamia pełny skan ZAP + Nuclei na środowisku staging co noc; wyniki porównywane są z poprzednim raportem w bazie PostgreSQL. Wykrycie nowej luki generuje ticket Jira automatycznie 1114.

4.3 Metryki i raportowanie​

  • Coverage – procent endpointów odwiedzonych przez crawler ZAP > 85% 25.
  • MTTD/MTTR – śr. czas wykrycia < 5 min, czas neutralizacji < 15 min dzięki Active Response 263.
  • False Positive Rate – < 2% po kalibracji reguł Grok i AI 22.

5. Wdrożenie krok-po-kroku​

  1. Sieć bezpieczeństwa – utwórz osobną podsieć Docker/K8s (np. zapnet) dla skanerów, aby nie blokowały ruchu produkcyjnego 9.
  2. Instalacja Wazuh – skrypt install_wazuh.sh z repo oficjalnego; konfiguracja klastra 1 × Master + 2 × Worker dla HA 18.
  3. Filebeat na hostach – moduły system, nginx, mysql, auditd; transport TLS na port 5044 27.
  4. Szablony Nuclei – aktualizowane codziennie przez nuclei -update-templates 10.
  5. ZAP baseline w pipeline PR; pełny skan tylko na branch main.
  6. Reguły Wazuh – import pliku custom_rules.xml, w tym reguł z pkt 3.5 20.
  7. Akcje Active Response – skrypt iptables_drop.sh oraz aws_cli isolate-instance dla workloadów w chmurze 3.

6. Najczęstsze pułapki i jak ich uniknąć​

ProblemPrzyczynaRemedium
Fala fałszywych alertów po uruchomieniu skanerówBrak whitelistingu adresów testowychWprowadź tag scanner_ip i filtruj w regułach Wazuh 3
“x509: cannot validate certificate” w FilebeatCertyfikat bez SAN IPWygeneruj cert z subjectAltName=IP lub użyj FQDN 27
Utrata spójności indeksów ESNiestandardowe pola bez template’uUżyj template dynamic security-logs-* oraz ILM policies 16
Skan DAST blokuje sesje użytkownikówZbyt agresywna polityka “Active Scan”Skonfiguruj limit maxRuleDurationInMins i włącz tryb time-boxed 8

7. Rozszerzenia i skalowanie​

  • Serverless DAST – uruchamianie ZAP w AWS Fargate na żądanie, koszty tylko za czas skanu.
  • Grafana/Loki zamiast pełnego ELK dla środowisk o mniejszym wolumenie logów 28.
  • SOAR pełny – integracja z TheHive/Cortex lub StackStorm w celu automatycznej triage i eskalacji incydentów.

8. Podsumowanie​

Zaproponowany stos narzędzi ZAP + Nuclei + ELK + Wazuh pozwala zbudować w pełni zautomatyzowany ekosystem DevSecOps:

  • Szybkość – każdy commit przechodzi testy bezpieczeństwa w ciągu minut, a incydenty produkcyjne są blokowane w czasie rzeczywistym.
  • Skalowalność – architektura klastrowa Wazuh i indeksy rozproszone ES obsługują tysiące EPS 1816.
  • Kompletność – łączy analizę kodu, aplikacji, infrastruktury i logów w jednym przepływie, minimalizując luki pokrycia 293031.
  • Oszczędność – rozwiązanie open-source redukuje koszty licencji, a automatyzacja ogranicza wydatki na ręczne testy i SOC 2213.

Wdrożenie opisanych komponentów zapewni Twojej aplikacji webowej ciągłą, wielowarstwową ochronę zgodną z najlepszymi praktykami OWASP i CIS, a zespołowi dev-ops pozwoli skupić się na rozwoju funkcji zamiast gaszenia pożarów.

Sequence diagram illustrating internal communication and task distribution within a Wazuh cluster, detailing interactions between various client, worker, and master components.

Sequence diagram illustrating internal communication and task distribution within a Wazuh cluster, detailing interactions between various client, worker, and master components.

⁂

Footnotes​

  1. https://www.intruder.io/blog/pentesting-tools ↩

  2. https://www.jit.io/resources/owasp-zap/how-to-automate-owasp-zap ↩ ↩2

  3. https://www.yeswehack.com/learn-bug-bounty/smart-automation-with-burp-suite ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  4. https://geekvibesnation.com/the-top-5-penetration-testing-frameworks-and-why-you-should-follow-them/ ↩

  5. https://www.gartner.com/reviews/market/penetration-testing-tools ↩

  6. https://dzone.com/articles/how-to-automate-owasp-zap ↩

  7. https://github.com/justmorpheus/burp-automation ↩ ↩2 ↩3

  8. https://docs.cobalt.io/methodologies/web-methodologies/ ↩ ↩2 ↩3

  9. https://www.reddit.com/r/AskNetsec/comments/13j9h9i/automated_penetration_testing_software/ ↩ ↩2

  10. https://www.zaproxy.org/docs/automate/automation-framework/ ↩ ↩2

  11. https://www.xplg.com/solution-it-tools-log-analysis/ ↩ ↩2

  12. https://dev.to/oliverbennet/automated-log-analysis-and-reporting-with-python-bash-and-powershell-a32 ↩

  13. https://aws.amazon.com/marketplace/pp/prodview-qa7qfot6dpzq6 ↩ ↩2

  14. https://www.exabeam.com/explainers/siem/siem-alerts-understanding-security-information-and-event-alerts/ ↩ ↩2

  15. https://logz.io/blog/log-file-parsing-tools/ ↩

  16. https://uptrace.dev/tools/log-analysis-tools ↩ ↩2 ↩3 ↩4

  17. https://www.ibm.com/think/topics/ai-for-log-analysis ↩ ↩2

  18. https://eurotux.com/2020/12/monitoring-with-elk-stack/ ↩ ↩2 ↩3

  19. https://stellarcyber.ai/learn/siem-alerts-types-and-best-practices/ ↩

  20. https://www.ittsystems.com/best-log-parsing-tools/ ↩ ↩2

  21. https://www.schellman.com/blog/cybersecurity/penetration-testing-a-cicd-pipeline ↩ ↩2

  22. https://www.opsera.io/blog/devops-security-automation-best-practices ↩ ↩2 ↩3

  23. https://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/sec_securely_operate_test_validate_pipeline.html ↩

  24. https://www.esystems.fi/en/blog/implementing-automated-security-testing-best-practices ↩

  25. https://strobes.co/blog/integrating-penetration-testing-as-a-service-ptaas-with-ci-cd-pipelines-a-practical-guide/ ↩

  26. https://www.techtarget.com/searchsecurity/tip/5-ways-to-automate-security-testing-in-DevSecOps ↩

  27. https://www.xenonstack.com/insights/devsecops-pipeline ↩ ↩2

  28. https://phoenixnap.com/blog/automated-security-testing-best-practices ↩

  29. https://portswigger.net/developers/ci-cd-security ↩

  30. https://www.testingxperts.com/blog/DevSecOps-Automating-Security-into-the-Testing-Process ↩

  31. https://www.techtarget.com/searchsecurity/tip/11-open-source-automated-penetration-testing-tools ↩