DevSecOps Pipeline στο Linux: Πλήρης Οδηγός SAST, SCA και Secrets Scanning

Εισαγωγή: Γιατί το DevSecOps Δεν Είναι Πολυτέλεια Πια

Ας πούμε τα πράγματα με το όνομά τους: το 2026, αν δεν έχεις ενσωματώσει ελέγχους ασφαλείας στο CI/CD pipeline σου, ουσιαστικά περιμένεις να σου χτυπήσει η πόρτα κάποιο incident. Οι επιθέσεις στην αλυσίδα εφοδιασμού λογισμικού (software supply chain attacks) έχουν αυξηθεί κατακόρυφα — από κακόβουλο κώδικα σε δημοφιλείς βιβλιοθήκες μέχρι κλειδιά API που καταλήγουν σε δημόσια repositories.

Η ασφάλεια δεν μπορεί να είναι ξεχωριστό βήμα στο τέλος. Πρέπει να μπει μέσα στη διαδικασία. Αυτό ακριβώς κάνει το DevSecOps.

Σε αυτόν τον οδηγό θα στήσουμε μαζί, βήμα-βήμα, ένα ολοκληρωμένο DevSecOps pipeline σε Linux. Χρησιμοποιούμε αποκλειστικά εργαλεία ανοιχτού κώδικα: Gitleaks για ανίχνευση μυστικών, Semgrep για στατική ανάλυση (SAST), Trivy για σάρωση εξαρτήσεων και container images (SCA), και OWASP ZAP για δυναμική ανάλυση (DAST). Θα δούμε παραδείγματα τόσο σε GitHub Actions όσο και σε GitLab CI/CD.

Τι Είναι το DevSecOps (και Γιατί Δεν Φτάνει Μόνο το DevOps)

Το DevSecOps (Development + Security + Operations) σημαίνει ότι η ασφάλεια ενσωματώνεται στο ίδιο σύστημα που χτίζει, ελέγχει και αναπτύσσει το λογισμικό. Δεν πρόκειται για τριμηνιαίο audit ούτε για ένα τσεκάρισμα πριν το release — πρόκειται για αυτοματοποιημένους ελέγχους που τρέχουν με κάθε αλλαγή κώδικα.

Η βασική διαφορά με το κλασικό DevOps;

• DevOps: Developers γράφουν κώδικα → Ops τον αναπτύσσει
• DevSecOps: Developers γράφουν κώδικα → Αυτόματοι έλεγχοι ασφαλείας → Μόνο ασφαλής κώδικας αναπτύσσεται

Η αρχή "Shift Left" λέει κάτι απλό: μετέφερε τους ελέγχους ασφαλείας όσο πιο νωρίς γίνεται — ιδανικά πριν ο κώδικας φτάσει καν στο κεντρικό repository. Στην πράξη αυτό κάνει τεράστια διαφορά, γιατί ένα πρόβλημα που πιάνεται στο pre-commit κοστίζει πολύ λιγότερο από ένα πρόβλημα που ανακαλύπτεται σε production.

Αρχιτεκτονική του Pipeline

Ένα ώριμο DevSecOps pipeline ακολουθεί μια απλή λογική: γρήγοροι έλεγχοι νωρίς, αυστηροί έλεγχοι αργότερα. Ιδού η δομή που θα υλοποιήσουμε:

1. Pre-commit: Ανίχνευση μυστικών τοπικά (Gitleaks hooks)
2. Secrets Scanning: Σάρωση ολόκληρου του repository για διαρροές (Gitleaks)
3. SAST: Στατική ανάλυση κώδικα για ευπάθειες (Semgrep)
4. SCA: Σάρωση εξαρτήσεων για γνωστά CVE (Trivy filesystem)
5. Container Scanning: Σάρωση Docker images (Trivy image)
6. DAST: Δυναμική ανάλυση σε running εφαρμογή (OWASP ZAP)
7. Security Gate: Αποτυχία build αν βρεθούν κρίσιμα ευρήματα

Η σειρά δεν είναι τυχαία. Θέλεις τα πιο γρήγορα (και φθηνά) checks πρώτα, ώστε αν κάτι αποτύχει νωρίς, να μην χάνεις χρόνο στα βαρύτερα στάδια.

Βήμα 1: Ανίχνευση Μυστικών με Gitleaks

Γιατί η Σάρωση Μυστικών Είναι Κρίσιμη

Τα hardcoded μυστικά (API keys, passwords, tokens) είναι μία από τις πιο συχνές αιτίες παραβίασης — και ειλικρινά, μία από τις πιο αποφεύξιμες. Μόλις ένα μυστικό μπει στο git history, παραμένει εκεί ακόμα κι αν διαγράψεις το commit. Γι' αυτό η πρόληψη μετράει πολύ περισσότερο από τη θεραπεία.

Εγκατάσταση και Τοπική Χρήση

# Εγκατάσταση Gitleaks σε Linux
sudo apt-get install -y gitleaks
# Ή μέσω Go
go install github.com/gitleaks/gitleaks/v8@latest

# Σάρωση ολόκληρου του repository
gitleaks detect --source . --verbose

# Σάρωση μόνο των τελευταίων αλλαγών
gitleaks detect --source . --log-opts="HEAD~5..HEAD"

Pre-commit Hook

Για πραγματικό "shift left", ρυθμίζουμε ένα pre-commit hook ώστε ο έλεγχος να γίνεται πριν κάθε commit. Αυτό είναι, κατά τη γνώμη μου, το πιο σημαντικό βήμα — πιάνει τα λάθη πριν καν γίνουν push:

# Εγκατάσταση pre-commit
pip install pre-commit

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.22.0
    hooks:
      - id: gitleaks

# Ενεργοποίηση
pre-commit install

GitHub Actions Integration

# .github/workflows/devsecops.yml
name: DevSecOps Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  secrets-scan:
    name: "Σάρωση Μυστικών"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Απαιτείται πλήρες history

      - name: Gitleaks Scan
        uses: gitleaks/[email protected]
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Προσοχή: Η παράμετρος fetch-depth: 0 είναι κρίσιμη. Χωρίς αυτήν, το Gitleaks δεν βλέπει το πλήρες git history και μπορεί να χάσει μυστικά που κρύβονται σε παλαιότερα commits.

Διαχείριση False Positives

Θα έχεις false positives — αυτό είναι αναπόφευκτο. Αντί να απενεργοποιείς κανόνες, φτιάξε ένα αρχείο .gitleaksignore:

# .gitleaksignore
# Παράδειγμα test API key (δεν είναι πραγματικό)
b0e4f3c2d1a5e6f7:tests/fixtures/test_config.json:generic-api-key

Βήμα 2: Στατική Ανάλυση Κώδικα (SAST) με Semgrep

Τι Ανιχνεύει το SAST

Η στατική ανάλυση εξετάζει τον πηγαίο κώδικα χωρίς να τον εκτελεί. Αναζητά ευπάθειες όπως SQL injection, XSS, command injection, ανασφαλή χρήση κρυπτογραφίας, αλλά και ύποπτα patterns που ίσως δεν είναι bugs ακόμα, αλλά σίγουρα θα γίνουν.

Γιατί Semgrep;

Έχω δοκιμάσει αρκετά SAST εργαλεία, και το Semgrep ξεχωρίζει για τρεις λόγους:

• Ταχύτητα — σαρώνει χιλιάδες αρχεία σε δευτερόλεπτα
• Υποστήριξη 30+ γλωσσών (Python, JavaScript, Go, Java, C, κ.λπ.)
• Προσαρμόσιμοι κανόνες — γράφεις κανόνες σε YAML που μοιάζουν με τον κώδικα που ψάχνεις (αυτό μειώνει δραστικά το learning curve)

Φυσικά, έρχεται με ενσωματωμένα rulesets για OWASP Top 10, οπότε δεν χρειάζεται να ξεκινήσεις από το μηδέν.

Εγκατάσταση και Χρήση

# Εγκατάσταση
pip install semgrep

# Σάρωση με τους κανόνες OWASP Top 10
semgrep scan --config p/owasp-top-ten .

# Σάρωση με πολλαπλά rulesets
semgrep scan --config p/security-audit --config p/secrets .

# Σάρωση με αυστηρή λειτουργία (αποτυγχάνει σε ευρήματα)
semgrep scan --config p/owasp-top-ten --error --severity ERROR .

Προσαρμοσμένος Κανόνας Semgrep

Εδώ γίνεται πραγματικά ενδιαφέρον. Μπορείς να γράψεις δικούς σου κανόνες για τις ανάγκες του project σου:

# .semgrep/custom-rules.yml
rules:
  - id: no-exec-user-input
    patterns:
      - pattern: os.system($INPUT)
      - pattern-not: os.system("...")
    message: "Εντοπίστηκε εκτέλεση εντολής με μη αξιόπιστη είσοδο"
    languages: [python]
    severity: ERROR
    metadata:
      cwe: "CWE-78: OS Command Injection"
      owasp: "A03:2021 Injection"

Ενσωμάτωση σε GitHub Actions

  sast-scan:
    name: "Στατική Ανάλυση (SAST)"
    runs-on: ubuntu-latest
    needs: secrets-scan
    steps:
      - uses: actions/checkout@v4

      - name: Semgrep SAST Scan
        uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/owasp-top-ten
            p/secrets
            .semgrep/custom-rules.yml
        env:
          SEMGREP_RULES: "p/security-audit p/owasp-top-ten"

Ενσωμάτωση σε GitLab CI

# .gitlab-ci.yml
sast_semgrep:
  stage: test
  image: returntocorp/semgrep:latest
  variables:
    SEMGREP_RULES: "p/security-audit p/owasp-top-ten"
  script:
    - semgrep scan --config "$SEMGREP_RULES" --sarif -o semgrep-results.sarif .
  artifacts:
    reports:
      sast: semgrep-results.sarif
    paths:
      - semgrep-results.sarif
  allow_failure: false

Βήμα 3: Σάρωση Εξαρτήσεων (SCA) με Trivy

Ο Κίνδυνος των Third-Party Εξαρτήσεων

Αυτό είναι κάτι που πολλοί υποτιμούν: οι σύγχρονες εφαρμογές εξαρτώνται από εκατοντάδες βιβλιοθήκες ανοιχτού κώδικα. Κάθε μία μπορεί να κρύβει γνωστές ευπάθειες (CVE). Η Software Composition Analysis (SCA) τις εντοπίζει αυτόματα και μπορεί να δημιουργήσει SBOM (Software Bill of Materials) — κάτι που γίνεται όλο και πιο σημαντικό για λόγους συμμόρφωσης.

Εγκατάσταση Trivy

# Εγκατάσταση σε Debian/Ubuntu
sudo apt-get install -y wget apt-transport-https gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | \
  gpg --dearmor | sudo tee /usr/share/keyrings/trivy.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb generic main" | \
  sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt-get update && sudo apt-get install -y trivy

# Σάρωση filesystem για ευπάθειες εξαρτήσεων
trivy filesystem --severity HIGH,CRITICAL .

# Δημιουργία SBOM σε CycloneDX format
trivy filesystem --format cyclonedx --output sbom.json .

Σάρωση Docker Images

# Σάρωση image με αγνόηση μη διορθωμένων ευπαθειών
trivy image --ignore-unfixed --severity HIGH,CRITICAL myapp:latest

# Σάρωση με έξοδο σε SARIF format για ενσωμάτωση σε CI
trivy image --format sarif --output trivy-image.sarif myapp:latest

GitHub Actions SCA + Container Scanning

  sca-scan:
    name: "Σάρωση Εξαρτήσεων (SCA)"
    runs-on: ubuntu-latest
    needs: secrets-scan
    steps:
      - uses: actions/checkout@v4

      - name: Trivy Filesystem Scan
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          format: 'sarif'
          output: 'trivy-fs-results.sarif'
          exit-code: '1'
          severity: 'CRITICAL,HIGH'

      - name: Upload SCA Results
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: 'trivy-fs-results.sarif'

  container-scan:
    name: "Σάρωση Container Image"
    runs-on: ubuntu-latest
    needs: [sast-scan, sca-scan]
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker Image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Trivy Image Scan
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'image'
          image-ref: 'myapp:${{ github.sha }}'
          format: 'sarif'
          output: 'trivy-image-results.sarif'
          exit-code: '1'
          ignore-unfixed: true
          severity: 'CRITICAL,HIGH'

Βήμα 4: Δυναμική Ανάλυση (DAST) με OWASP ZAP

Τι Προσφέρει το DAST

Σε αντίθεση με το SAST που κοιτάζει τον κώδικα, το DAST ελέγχει την εφαρμογή ενώ τρέχει. Στέλνει κακόβουλα payloads, ελέγχει τις απαντήσεις, και εντοπίζει ευπάθειες runtime, misconfigurations, και ζητήματα που απλά δεν φαίνονται κοιτώντας μόνο τον στατικό κώδικα.

Σκέψου το έτσι: το SAST βρίσκει ότι ξέχασες να κάνεις sanitize ένα input. Το DAST επιβεβαιώνει ότι αυτή η παράλειψη όντως εκμεταλλεύεται.

OWASP ZAP στο CI/CD

  dast-scan:
    name: "Δυναμική Ανάλυση (DAST)"
    runs-on: ubuntu-latest
    needs: container-scan
    services:
      app:
        image: myapp:${{ github.sha }}
        ports:
          - 8080:8080
    steps:
      - name: OWASP ZAP Baseline Scan
        uses: zaproxy/[email protected]
        with:
          target: 'http://app:8080'
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a'

Ρύθμιση Κανόνων ZAP

Δημιούργησε ένα αρχείο κανόνων για να ελέγξεις τι θα θεωρείται σημαντικό και τι θα αγνοηθεί:

# .zap/rules.tsv
# Μορφή: ID	Ενέργεια (IGNORE, WARN, FAIL)
10011	IGNORE	# Cookie Without Secure Flag (μη σχετικό για τοπικό testing)
10015	WARN	# Incomplete or No Cache-control
90033	FAIL	# Loosely Scoped Cookie

Βήμα 5: Security Gates — Enforcement vs Monitoring

Μια Κρίσιμη Διαφορά που Πολλοί Αγνοούν

Υπάρχει μια τεράστια διαφορά μεταξύ "τρέχω το Semgrep και βλέπω τα αποτελέσματα" και "τρέχω το Semgrep και αν βρεθεί κρίσιμο εύρημα, το build αποτυγχάνει". Η πρώτη περίπτωση είναι monitoring. Η δεύτερη είναι enforcement.

Η διαφορά; Μία σημαία: --error --severity ERROR. Αλλά αυτή η σημαία είναι η διαφορά μεταξύ ενός pipeline που ξέρει τα προβλήματα και ενός pipeline που τα σταματάει.

Συνιστώμενη Πολιτική Gates

# security-policy.yml
gates:
  secrets:
    tool: gitleaks
    max_findings: 0        # ΑΠΟΤΥΧΙΑ αν βρεθεί ΟΠΟΙΟΔΗΠΟΤΕ μυστικό
    action: block_merge

  sast:
    tool: semgrep
    max_critical: 0        # ΑΠΟΤΥΧΙΑ σε critical ευρήματα
    max_high: 5            # Προειδοποίηση σε high ευρήματα
    action: block_on_critical

  sca:
    tool: trivy
    max_critical: 0        # ΑΠΟΤΥΧΙΑ σε critical CVE
    ignore_unfixed: true   # Αγνόηση ευπαθειών χωρίς fix
    action: block_merge

  dast:
    tool: owasp-zap
    max_high: 0
    action: warn_and_ticket  # Δημιουργία ticket, δεν μπλοκάρει

Σταδιακή Υιοθέτηση (Μην Τα Κάνεις Όλα Μαζί)

Εδώ θα σου δώσω μια συμβουλή από προσωπική εμπειρία: μην ενεργοποιήσεις αυστηρό enforcement σε όλα τα εργαλεία ταυτόχρονα. Θα δημιουργήσεις "alert fatigue" και οι developers θα αρχίσουν να αγνοούν τα ευρήματα — ή χειρότερα, θα βρουν τρόπους να παρακάμπτουν τους ελέγχους.

Η στρατηγική που δουλεύει:

1. Εβδομάδα 1-2: Μόνο Gitleaks σε block mode + Semgrep/Trivy σε monitoring mode
2. Εβδομάδα 3-4: Ενεργοποίηση block για critical ευρήματα Semgrep
3. Μήνας 2: Block για critical CVE μέσω Trivy
4. Μήνας 3: Προσθήκη DAST σε warn mode

Βήμα 6: Πλήρες Pipeline — Ολοκληρωμένο Παράδειγμα

Λοιπόν, ας δούμε πώς δένουν όλα μαζί. Παρακάτω θα βρεις ολοκληρωμένα workflows και για τις δύο πλατφόρμες.

GitHub Actions — Πλήρες Workflow

# .github/workflows/devsecops-full.yml
name: DevSecOps Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 2 * * 0'  # Εβδομαδιαία σάρωση Κυριακή 02:00

permissions:
  contents: read
  security-events: write
  pull-requests: write

jobs:
  # Στάδιο 1: Σάρωση Μυστικών (Blocker)
  secrets-scan:
    name: "Gitleaks - Ανίχνευση Μυστικών"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/[email protected]
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  # Στάδιο 2: SAST + SCA (Παράλληλα)
  sast:
    name: "Semgrep - SAST"
    runs-on: ubuntu-latest
    needs: secrets-scan
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: p/security-audit p/owasp-top-ten
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: semgrep.sarif

  sca:
    name: "Trivy - SCA"
    runs-on: ubuntu-latest
    needs: secrets-scan
    steps:
      - uses: actions/checkout@v4
      - uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          format: 'sarif'
          output: 'trivy-results.sarif'
          exit-code: '1'
          severity: 'CRITICAL,HIGH'
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: trivy-results.sarif

  # Στάδιο 3: Container Scanning
  container-scan:
    name: "Trivy - Container Image"
    runs-on: ubuntu-latest
    needs: [sast, sca]
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t myapp:${{ github.sha }} .
      - uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'image'
          image-ref: 'myapp:${{ github.sha }}'
          exit-code: '1'
          ignore-unfixed: true
          severity: 'CRITICAL,HIGH'

  # Στάδιο 4: DAST (σε staging)
  dast:
    name: "OWASP ZAP - DAST"
    runs-on: ubuntu-latest
    needs: container-scan
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to staging
        run: docker run -d -p 8080:8080 myapp:${{ github.sha }}
      - name: Wait for app
        run: |
          for i in $(seq 1 30); do
            curl -s http://localhost:8080/health && break
            sleep 2
          done
      - uses: zaproxy/[email protected]
        with:
          target: 'http://localhost:8080'

GitLab CI — Ισοδύναμο Pipeline

# .gitlab-ci.yml
stages:
  - secrets
  - analysis
  - build
  - dast

variables:
  TRIVY_SEVERITY: "CRITICAL,HIGH"
  SEMGREP_RULES: "p/security-audit p/owasp-top-ten"

gitleaks:
  stage: secrets
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --verbose --report-format sarif --report-path gitleaks.sarif
  artifacts:
    reports:
      secret_detection: gitleaks.sarif

semgrep:
  stage: analysis
  image: returntocorp/semgrep:latest
  script:
    - semgrep scan --config "$SEMGREP_RULES" --sarif -o semgrep.sarif .
  artifacts:
    reports:
      sast: semgrep.sarif

trivy_fs:
  stage: analysis
  image: aquasec/trivy:latest
  script:
    - trivy filesystem --severity $TRIVY_SEVERITY --exit-code 1 --format sarif -o trivy-fs.sarif .
  artifacts:
    reports:
      dependency_scanning: trivy-fs.sarif

trivy_image:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t myapp:$CI_COMMIT_SHA .
    - trivy image --severity $TRIVY_SEVERITY --exit-code 1 --ignore-unfixed myapp:$CI_COMMIT_SHA

zap_dast:
  stage: dast
  image: ghcr.io/zaproxy/zaproxy:stable
  script:
    - zap-baseline.py -t "$STAGING_URL" -r zap-report.html
  artifacts:
    paths:
      - zap-report.html
  when: manual  # Εκτέλεση μόνο χειροκίνητα ή σε main branch

Βήμα 7: Διαχείριση Μυστικών στο Pipeline

Αντί για Hardcoded Μυστικά

Ένα πράγμα που αξίζει να τονιστεί: τα μυστικά δεν πρέπει ποτέ να βρίσκονται στον κώδικα. Ούτε σε environment variables που ορίζονται μέσα στο YAML. Χρησιμοποίησε τον μηχανισμό secrets του CI/CD platform σου ή (ακόμα καλύτερα) ένα εξωτερικό secret management σύστημα όπως το Vault.

Ενσωμάτωση HashiCorp Vault

# GitHub Actions - Ανάκτηση μυστικών από Vault
      - name: Import Secrets from Vault
        uses: hashicorp/vault-action@v3
        with:
          url: https://vault.example.com
          method: jwt
          role: ci-pipeline
          secrets: |
            secret/data/app/db DB_PASSWORD ;
            secret/data/app/api API_KEY

# GitLab CI - Χρήση Vault integration
variables:
  VAULT_SERVER_URL: https://vault.example.com
  VAULT_AUTH_ROLE: gitlab-ci

deploy:
  stage: deploy
  id_tokens:
    VAULT_ID_TOKEN:
      aud: https://vault.example.com
  secrets:
    DB_PASSWORD:
      vault: secret/data/app/db/password@secrets
      file: false

Βήμα 8: Παρακολούθηση και Αναφορές

Κεντρικός Πίνακας Ελέγχου

Η συγκέντρωση ευρημάτων σε ένα κεντρικό σημείο κάνει τεράστια διαφορά στη διαχείριση — ειδικά αν έχεις πολλά repositories. Δύο βασικές επιλογές:

• GitHub Security Tab: Αυτόματη ενσωμάτωση μέσω SARIF uploads. Βλέπεις όλα τα ευρήματα σε ενιαίο dashboard χωρίς extra setup
• DefectDojo: Ανοιχτού κώδικα vulnerability management platform. Ιδανικό αν χρειάζεσαι συγκέντρωση από πολλαπλά εργαλεία και πιο λεπτομερή tracking

SARIF — Το Κοινό Format

Ένα ωραίο πράγμα: όλα τα εργαλεία που χρησιμοποιούμε υποστηρίζουν SARIF (Static Analysis Results Interchange Format). Αυτό σημαίνει ότι ανεξάρτητα από το εργαλείο, τα αποτελέσματα μπορούν να ανέβουν στο GitHub Security Tab ή σε οποιοδήποτε SARIF-compatible dashboard. Μία μορφή, πολλά εργαλεία — αρκετά βολικό.

Ειδοποιήσεις σε Πραγματικό Χρόνο

# Αποστολή ειδοποίησης σε Slack αν αποτύχει security scan
  notify-failure:
    name: "Ειδοποίηση Ασφαλείας"
    runs-on: ubuntu-latest
    needs: [secrets-scan, sast, sca, container-scan]
    if: failure()
    steps:
      - name: Slack Notification
        uses: 8398a7/action-slack@v3
        with:
          status: failure
          text: "Εντοπίστηκε πρόβλημα ασφαλείας στο pipeline!"
          webhook_url: ${{ secrets.SLACK_WEBHOOK }}
          fields: repo,commit,author,action

Βέλτιστες Πρακτικές DevSecOps Pipeline (2026)

Πριν κλείσουμε, ας δούμε μερικές πρακτικές που κάνουν τη διαφορά μεταξύ ενός pipeline που απλά υπάρχει και ενός pipeline που πραγματικά προστατεύει:

• Security as Code: Οι πολιτικές ασφαλείας πρέπει να βρίσκονται σε version control, ακριβώς όπως ο κώδικας. Αν δεν μπορείς να κάνεις git blame σε έναν κανόνα ασφαλείας, κάτι δεν πάει καλά
• Εβδομαδιαίες σαρώσεις: Πέρα από κάθε commit, ρύθμισε scheduled scans (cron) για να πιάνεις νέα CVE σε ήδη υπάρχοντα κώδικα
• SBOM Generation: Δημιούργησε Software Bill of Materials σε κάθε release — γίνεται απαίτηση συμμόρφωσης σε ολοένα περισσότερους κλάδους
• Artifact Signing: Υπέγραψε τα container images με Sigstore/Cosign για επαλήθευση ακεραιότητας
• Minimum Permissions: Τα CI/CD jobs πρέπει να τρέχουν με τα ελάχιστα δικαιώματα — χρησιμοποίησε permissions: στο GitHub Actions
• Ενημέρωση εργαλείων: Ενημέρωνε τα security tools τουλάχιστον μηνιαία για τις τελευταίες vulnerability signatures
• Cache vulnerability DB: Χρησιμοποίησε caching για τη βάση ευπαθειών του Trivy — γλιτώνεις πολύ χρόνο στα scans

Σύγκριση Εργαλείων: Πότε Χρησιμοποιείς Τι

Κατηγορία	Εργαλείο	Τι Ελέγχει	Πότε Τρέχει
Secrets	Gitleaks	API keys, passwords, tokens στον κώδικα	Pre-commit + κάθε push
SAST	Semgrep	SQL injection, XSS, command injection	Κάθε push/PR
SCA	Trivy (fs)	CVE σε dependencies	Κάθε push/PR + εβδομαδιαία
Container	Trivy (image)	CVE σε OS packages + app layers	Μετά το build
DAST	OWASP ZAP	Runtime ευπάθειες σε running app	Σε staging πριν deploy
IaC	Checkov/tfsec	Misconfiguration σε Terraform/K8s	Κάθε push/PR
Secrets Mgmt	HashiCorp Vault	Ασφαλής αποθήκευση/ανάκτηση μυστικών	Runtime

Συχνές Ερωτήσεις (FAQ)

Ποια είναι η διαφορά μεταξύ SAST και DAST;

Με απλά λόγια: το SAST διαβάζει τον κώδικά σου και βρίσκει πιθανά προβλήματα (π.χ. SQL injection), χωρίς να τρέξει τίποτα. Το DAST τρέχει την εφαρμογή σου και δοκιμάζει να την "επιτεθεί" — βρίσκει ευπάθειες runtime και misconfigurations. Τα δύο είναι συμπληρωματικά: το SAST πιάνει προβλήματα στον κώδικα, το DAST πιάνει προβλήματα στη συμπεριφορά. Χρειάζεσαι και τα δύο.

Πώς ξεκινάω DevSecOps χωρίς να επιβραδύνω τους developers;

Ξεκίνα με τρία εργαλεία σε monitoring mode: Gitleaks + Semgrep + Trivy. Άσε τα να τρέχουν χωρίς να μπλοκάρουν τα merges για 2-4 εβδομάδες. Αφού η ομάδα εξοικειωθεί και επιλύσεις τα false positives, ενεργοποίησε σταδιακά το enforcement — ξεκινώντας από τα πιο κρίσιμα (secrets → critical CVE → SAST errors). Αυτή η σταδιακή προσέγγιση δουλεύει πάντα καλύτερα από το "ενεργοποίησε τα όλα αύριο".

Χρειάζομαι DevSecOps αν χρησιμοποιώ μόνο ιδιωτικά repositories;

Σύντομη απάντηση: ναι. Τα ιδιωτικά repositories προστατεύουν μόνο από δημόσια πρόσβαση. Δεν σε σώζουν από ευπάθειες σε third-party εξαρτήσεις, insecure coding πρακτικές, misconfigurations σε Dockerfiles, ή εσωτερικές απειλές. Το pipeline σαρώνει τον κώδικα ανεξάρτητα από το αν είναι δημόσιος ή ιδιωτικός.

Πόσο κοστίζουν τα εργαλεία DevSecOps;

Μηδέν ευρώ. Σοβαρά. Όλα τα εργαλεία σε αυτόν τον οδηγό (Gitleaks, Semgrep, Trivy, OWASP ZAP) είναι ανοιχτού κώδικα και δωρεάν. Το GitHub Actions δίνει 2.000 δωρεάν λεπτά/μήνα, το GitLab Community Edition είναι επίσης δωρεάν. Το μοναδικό πραγματικό κόστος; Ο χρόνος ρύθμισης — συνήθως 1-2 ημέρες εργασίας για ένα βασικό pipeline.

Πώς διαχειρίζομαι τα false positives;

Κάθε εργαλείο έχει τον δικό του μηχανισμό εξαιρέσεων: .gitleaksignore για το Gitleaks, .trivyignore για το Trivy, // nosemgrep annotations ή .semgrepignore για το Semgrep. Ο χρυσός κανόνας: κάθε εξαίρεση πρέπει να περνά code review, να έχει σχόλιο γιατί αγνοείται, και να αναθεωρείται τακτικά. Μην κάνεις suppress χωρίς εξήγηση — ο επόμενος developer (ή ο μελλοντικός εαυτός σου) θα χρειαστεί αυτό το context.