Security / DevOps

DevSecOps

Security nie jest bramką na końcu release — jest wbudowane w każdy commit, każdy PR i każdy deploy. Shift Left Security to jedyna skuteczna obrona w świecie gdzie ataki są ciągłe a luki kosztują miliony.

Shift Left Security

Filozofia

SAST/DAST/SCA

Typy testów

6 warstw

Etapy pipeline

A01 Broken Access

OWASP Top 10

DevSecOps Pipeline — 6 warstw security

Security jest zintegrowane na każdym etapie — od przed-commit przez CI/CD aż po monitoring produkcji.

Pre-commit

detect-secrets, gitleaks, hadolint

Secrets detection, Dockerfile lint

PR / Build

Semgrep, CodeQL, Trivy, Snyk

SAST, Container scan, SCA

Staging Deploy

OWASP ZAP, Nuclei

DAST, API security testing

Production

Falco, Tetragon, CSPM

Runtime security, Cloud posture

IaC Scanning

Checkov, Terrascan, tfsec

Terraform/K8s misconfiguration

Secrets Mgmt

HashiCorp Vault, External Secrets

Dynamic secrets, rotation

OWASP Top 10 — najważniejsze zagrożenia

OWASP Top 10 to lista najkrytyczniejszych podatności webowych. Każdy developer powinien je znać i rozumieć jak zapobiegać.

A01

Broken Access Control

Brak właściwego sprawdzania uprawnień. Najczęstszy problem 2021-2023.

A02

Cryptographic Failures

Słaba kryptografia, przesyłanie danych w plaintext, weak keys.

A03

Injection

SQL Injection, LDAP Injection, Command Injection przez untrusted input.

A04

Insecure Design

Brak threat modeling i security requirements w fazie design.

A05

Security Misconfiguration

Default credentials, open S3 buckets, verbose error messages.

A06

Vulnerable Components

Outdated libraries z CVE. Log4Shell jako przykład katastrofalny.

Często zadawane pytania

Co to jest DevSecOps i czym różni się od DevOps?

DevSecOps to rozszerzenie filozofii DevOps które integruje Security (Sec) na każdym etapie cyklu życia oprogramowania — od design przez development, testing, deployment aż po production monitoring. Hasło: 'Shift Left Security' — przesuń security na lewo (wcześniej w SDLC), zamiast sprawdzać na końcu przed release. DevOps vs. DevSecOps: DevOps focus: szybkość dostarczania, automation, collaboration Dev+Ops. DevSecOps dodaje: Security jako wspólna odpowiedzialność całego zespołu (nie tylko dedykowany security team). Security tools wbudowane w CI/CD pipeline. Developer self-service security checks. Dlaczego DevSecOps jest ważny: koszt naprawy błędu bezpieczeństwa rośnie wykładniczo — w fazie design: $100, w fazie dev: $1000, w fazie test: $10,000, w produkcji: $100,000+. Tradycyjny model: dev team buduje feature → security audit na końcu → security team odrzuca → dev team naprawia → opóźnienie release o tygodnie. DevSecOps model: security checks zautomatyzowane w CI/CD → problemy wykrywane w ciągu minut od push. Kluczowe narzędzia: SAST (Static Application Security Testing), DAST (Dynamic AST), SCA (Software Composition Analysis), Container scanning, Secrets detection.

SAST, DAST i SCA — jak działają i jakie narzędzia wybrać?

Typy Security Testing: SAST (Static Application Security Testing): analizuje kod źródłowy bez uruchamiania aplikacji. Wykrywa: SQL injection patterns, XSS, insecure deserialization, hardcoded secrets, insecure crypto. Narzędzia: Semgrep (open-source, szybki, konfigurowalne reguły), CodeQL (GitHub, powerful), SonarQube, Checkmarx, Veracode. Integracja: w CI pipeline na każdy PR. DAST (Dynamic Application Security Testing): testuje działającą aplikację z zewnątrz (jak atakujący). Wykrywa: injection vulnerabilities, authentication issues, exposed endpoints, CORS misconfigurations. Narzędzia: OWASP ZAP (open-source), Burp Suite (komercyjne, industry standard), Nikto. Integracja: w CI/CD po deploy na staging environment. SCA (Software Composition Analysis): analizuje dependencies/biblioteki pod kątem znanych CVE. Wykrywa: vulnerable dependencies (log4j typ). Narzędzia: Snyk (komercyjne, developer-friendly), Trivy (open-source, Aqua Security), OWASP Dependency-Check, Grype. Integracja: w CI pipeline przy każdym update dependencies. Container Security Scanning: skanuje Docker images pod kątem vulnerabilities w OS packages i aplikacjach. Narzędzia: Trivy, Grype, Snyk Container, Twistlock/Prisma Cloud. Integracja: w CI/CD przed push do registry i w registry (continuous scanning).

Jak wbudować security w CI/CD pipeline?

Security w CI/CD — DevSecOps Pipeline: Faza 1 — Pre-commit: pre-commit hooks uruchamiają lokalnie. Secrets detection (detect-secrets, git-secrets). Basic linting security. Narzędzia: pre-commit framework, gitleaks. Faza 2 — Build / PR Check: SAST scan (Semgrep, CodeQL) — wykryje bugs na poziomie kodu. SCA scan — sprawdź dependencies. Secrets scan w kodzie (TruffleHog, Gitleaks w CI). Lint Dockerfile (Hadolint). Faza 3 — Container Build: Container image scan (Trivy, Grype). SBOM generowanie (Syft). Sign image (cosign, Sigstore). Faza 4 — Deploy to Staging: DAST scan (OWASP ZAP API scan lub full scan). Penetration testing automation. Faza 5 — Production: Runtime security (Falco — eBPF-based). Continuous vulnerability monitoring. CSPM (Cloud Security Posture Management): sprawdzaj misconfiguracje cloud (open S3 buckets, public security groups). Infrastructure as Code scanning: Terrascan, Checkov, tfsec — skanuj Terraform/CloudFormation przed apply. Policy as Code: OPA (Open Policy Agent) — definiuj security policies jako kod. Gatekeeper — wymuszaj policies w Kubernetes. Admission Controllers — blokuj deploymenty które naruszają security policies.

Secrets Management w DevSecOps — jak unikać hardcoded secrets?

Secrets Management: Problem: developer hardcoduje API key w kodzie → push do GitHub → skanery lub atakujący wykrywają → kompromitacja. Skala problemu: GitGuardian raportuje setki tysięcy secretów eksponowanych na GitHub miesięcznie. Najczęstsze błędy: secrets w .env commitowanych, secrets w Docker images, secrets w CI/CD logs, secrets w Kubernetes ConfigMaps (zamiast Secrets). Rozwiązania: Secrets Detection (prewencja): pre-commit hooks: detect-secrets, gitleaks. CI/CD: TruffleHog (historyczne skanowanie git history), Gitleaks. GitHub Secret Scanning — automatyczne wykrywanie secrets w repo GitHub. Secrets Management (właściwe przechowywanie): HashiCorp Vault — enterprise grade, dynamic secrets, lease/revoke. AWS Secrets Manager — managed, native AWS, rotation. GCP Secret Manager / Azure Key Vault — odpowiedniki cloud-native. Kubernetes: External Secrets Operator — sync z Vault/AWS/GCP. NEVER store secrets in: Git repo (nawet private), Docker images (nawet layers), Environment variables w Kubernetes (używaj Secrets object). Best practices: Rotate secrets regularly. Use dynamic secrets (Vault generates per-request). Principle of least privilege — app dostaje tylko to czego potrzebuje. Secret zero problem: jak aplikacja dostanie dostęp do Vault? IRSA (AWS), Workload Identity (GCP), Kubernetes Service Account Token.

Security Champion program — jak budować kulturę bezpieczeństwa?

Security Champion Program: Dlaczego konieczne: jeden security engineer nie może sprawdzić wszystkich PR w szybko rosnącej firmie. Security Champions to deweloperzy w każdym teamie którzy mają zainteresowanie i podstawową wiedzę z security. Security Champions model: Jeden Security Champion per team (5-10% czasu na security). Regular meetups Security Champions (co 2 tygodnie). Security Champions są mostem między security team a dev teams. Szkolenie i certyfikacja: OWASP Top 10 — fundamentalne dla każdego developera. SANS SEC522 / GWAPT — dla Security Champions. Bug Bounty — wewnętrzne lub zewnętrzne (HackerOne, Bugcrowd). Security Gamification: CTF (Capture The Flag) wewnętrzne competitions. Secure coding challenges. Security KPIs: Mean Time to Remediate (MTTR) per severity (P0: 24h, P1: 7 dni, P2: 30 dni). Vulnerability backlog trend. % pipeline runs z security scans. False positive rate (zbyt wiele false positives = developerzy ignorują alerty). Blameless Security Culture: gdy zostanie znaleziony vuln — focus na fix i process improvement, nie blame. Threat Modeling: regularne threat modeling dla nowych features (STRIDE framework, Attack Trees). Zaangażowanie security wcześnie w design phase.

Czytaj dalej