Έλεγχος ασφαλείας στο Claude Code: οδηγός βήμα προς βήμα και αυτοματοποίηση GitHub Action το 2026

Ο συγγραφέας του πρωτότυπου υλικού περιγράφει την εμπειρία του: «Μόλις έτρεξα το security-review στο δικό μου vibe project και η ομάδα εντόπισε αρκετά πραγματικά ζητήματα μέσα σε 4 λεπτά, τα οποία έχουν ήδη διορθωθεί». Πρόκειται για την ίδια δουλειά που παλιότερα απαιτούσε μία ημέρα από εξωτερικό σύμβουλο.

Πρόσθετο υλικό για τη ρύθμιση εργαλείων βρίσκεται στην τεκμηρίωση του Ailoot.

Τι είναι το /security-review στο Claude Code;#

Η εντολή λειτουργεί σε δύο τρόπους. Τοπικά: εκτελέστε /security-review στο τερματικό και το Claude θα διαβάσει το αποθετήριο και θα δημιουργήσει μια αναφορά. Από την πλευρά του διακομιστή: η ίδια μηχανή εγκαθίσταται ως GitHub Action και σχολιάζει αυτόματα ενσωματωμένα σε κάθε Pull Request.

Σε αντίθεση με τους κλασικούς σαρωτές SAST (Snyk Code, Semgrep, SonarQube), το /security-review δεν βασίζεται σε σταθερούς κανόνες. Διαβάζει τον κώδικα όπως ένας μηχανικός που εργάζεται εκείνη τη στιγμή: ακολουθεί τη ροή δεδομένων, κατανοεί ποιο framework χρησιμοποιείτε και πού βρίσκονται τα όρια εμπιστοσύνης, και εντοπίζει ευπάθειες που δεν περιγράφονται από κάποιον κανόνα.

Αυτό δεν σημαίνει ότι το /security-review αντικαθιστά ένα εξωτερικό pentest ή τις δοκιμές σε ζωντανό περιβάλλον staging. Μπορεί να αυτοματοποιήσει μέρος του αρχικού ελέγχου κώδικα, αλλά το άρθρο δεν μετρά ποσοστό κάλυψης ελέγχου. Παρακάτω εξηγώ πώς να το εκτελέσετε σωστά και τι θα εντοπίσει το Claude στο project σας.

Πώς εκτελείτε το /security-review σε 5 βήματα;#

Βήμα 1. Ενημερώστε το Claude Code. Η εντολή λειτουργεί από την έκδοση που κυκλοφόρησε στις 20 Φεβρουαρίου 2026.

claude update

Αν εγκαταστήσατε το Claude Code μέσω npm, μπορείτε επίσης να εκτελέσετε:

npm install -g @anthropic-ai/claude-code@latest

Ελέγξτε ότι εμφανίστηκε το /security-review:

claude /help | grep security

Βήμα 2. Ανοίξτε το project και συνδεθείτε στο Claude Code.

cd ~/projects/my-vibe-project
claude

Βήμα 3. Εκτελέστε την εντολή. Μέσα στο Claude Code, απλώς πληκτρολογήστε:

/security-review

Το Claude περνά αυτόματα από 3 φάσεις ανάλυσης:

1. Έρευνα πλαισίου αποθετηρίου - διαβάζει τη δομή και εντοπίζει το stack, τις διαδρομές και τα ερωτήματα βάσης δεδομένων.
2. Συγκριτική ανάλυση - συγκρίνει την τρέχουσα κατάσταση με τυπικά μοτίβα ευπαθειών για αυτό το stack.
3. Αξιολόγηση ευπαθειών - καταγράφει κάθε υποψία μαζί με επίπεδο βεβαιότητας σε κλίμακα από 1 έως 10. Στην αναφορά περιλαμβάνονται μόνο ευρήματα με βεβαιότητα ≥ 8.

Βήμα 4. Διαβάστε την αναφορά. Η μορφή εξόδου είναι ένας πίνακας markdown. Για κάθε ζήτημα, το Claude παρέχει:

• Αρχείο και αριθμό γραμμής (για παράδειγμα, src/auth/login.ts:42)
• Σοβαρότητα (HIGH / MEDIUM / LOW)
• Κατηγορία (sql_injection, xss, auth_bypass, insecure_storage)
• Περιγραφή - τι είναι λάθος
• Σενάριο εκμετάλλευσης - πώς θα μπορούσε να το χρησιμοποιήσει ένας εισβολέας
• Σύσταση - πώς να το διορθώσετε

Βήμα 5. Ζητήστε να εφαρμοστούν διορθώσεις. Έπειτα, μπορείτε να συνεργαστείτε μαζί του όπως με έναν συνηθισμένο agent:

«Εφάρμοσε τις διορθώσεις σοβαρότητας HIGH από την αναφορά, μία κάθε φορά, μαζί με περιγραφή PR.»

Το Claude θα ανοίξει κάθε αρχείο και θα προτείνει μια αλλαγή· εσείς την επιβεβαιώνετε. Σε ένα πραγματικό project, έκλεισα 5 ευρήματα σε 40 λεπτά, αντί για τις 3 ώρες που είχα υπολογίσει.

Ποιες ευπάθειες εντοπίζει το /security-review;#

Η πλήρης λίστα όσων περιλαμβάνονται στην ανάλυση από προεπιλογή περιγράφεται στην επίσημη τεκμηρίωση της Anthropic:

Επιπλέον, η εντολή καλύπτει κατηγορίες που οι αυτοματοποιημένοι σαρωτές σπάνια καλύπτουν:

• Command injection - εκτέλεση εισόδου χρήστη σε shell (child_process.exec(userInput))
• Path traversal - φόρτωση αρχείου μέσω ../../etc/passwd
• XXE - XML με εξωτερικές οντότητες
• Template injection - SSTI σε Jinja/Handlebars/EJS
• NoSQL injection - τελεστές $ne, $gt σε ερωτήματα MongoDB
• Κακή χρήση κρυπτογραφίας - χρήση MD5, λειτουργίας ECB ή στατικού IV

Το Claude αποδίδει σοβαρότητα σε κάθε εύρημα. Η κλίμακα είναι απλή:

• HIGH - απομακρυσμένη εκμετάλλευση χωρίς αυθεντικοποίηση, διαρροή δεδομένων που επηρεάζει όλους τους χρήστες
• MEDIUM - εκμετάλλευση με πρόσθετες προϋποθέσεις (απαιτείται συνεδρία / συγκεκριμένη είσοδος)
• LOW - πιθανό διάνυσμα, όχι κρίσιμο τώρα, αλλά αξίζει να διορθωθεί

Χρήσιμο να γνωρίζετε: στην τυπική ρύθμιση, το Claude δεν αναφέρει DoS, περιορισμό ρυθμού, εξάντληση μνήμης, ανοικτές ανακατευθύνσεις χωρίς αποδεδειγμένο αντίκτυπο, regex injection / ReDoS ή πλαστογράφηση αρχείων καταγραφής. Αυτό είναι σκόπιμο, ώστε να μη βομβαρδίζεστε με θόρυβο. Αν αυτές οι κατηγορίες έχουν σημασία, επεκτείνετε τους κανόνες (δείτε την ενότητα για το φιλτράρισμα ψευδώς θετικών παρακάτω).

Πώς ρυθμίζετε ένα GitHub Action για αυτόματο έλεγχο;#

Βήμα 1. Αποκτήστε ένα κλειδί API. Μεταβείτε στο console.anthropic.com, δημιουργήστε ένα κλειδί API και αντιγράψτε το.

Βήμα 2. Προσθέστε το κλειδί στα repository secrets. Στο GitHub: Settings → Secrets and variables → Actions → New repository secret. Ονομάστε το CLAUDE_API_KEY· η τιμή είναι το κλειδί σας.

Βήμα 3. Δημιουργήστε ένα αρχείο workflow. Αποθηκεύστε το ως .github/workflows/security.yml:

name: Security Review

permissions:
  pull-requests: write
  contents: read

on:
  pull_request:

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}
          fetch-depth: 2

      - uses: anthropics/claude-code-security-review@main
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

Βήμα 4. Συγχωνεύστε τον κλάδο στο main. Το action θα ξεκινήσει αυτόματα με το επόμενο PR.

Τι κάνει το action:

• Εκτελείται σε κάθε ανοιχτό Pull Request ή συγχρονισμό του.
• Λαμβάνει τη διαφορά μεταξύ του κλάδου PR και του main.
• Εκτελεί την ίδια μηχανή με το τοπικό /security-review.
• Δημοσιεύει ενσωματωμένα σχόλια απευθείας στις γραμμές κώδικα όπου υπάρχει υποψία.
• Αντιγράφει ολόκληρη την αναφορά στο Job Summary.

Σημαντικές λεπτομέρειες στα permissions:

• pull-requests: write - για τη δημοσίευση ενσωματωμένων σχολίων.
• contents: read - για την ανάγνωση του κώδικα. Χωρίς write. Το action δεν τροποποιεί τον κώδικα· μόνο αναφέρει ευρήματα.

Αυτό το σύνολο αρκεί για ένα ιδιωτικό αποθετήριο. Για δημόσιο αποθετήριο, μπορείτε επιπλέον να ορίσετε actions: read αν χρησιμοποιείτε επαναχρησιμοποιήσιμα workflows.

Πώς φιλτράρετε τα ψευδώς θετικά και αλλάζετε την ευαισθησία;#

Πλήρης πίνακας εισόδων του GitHub Action (πηγή: README του αποθετηρίου):

Παράδειγμα ρύθμισης φιλτραρίσματος ψευδώς θετικών. Δημιουργήστε το αρχείο .claude/security/false-positives.md:

# Κανόνες φιλτραρίσματος ψευδώς θετικών για το project μας

- Κάθε `dangerouslySetInnerHTML` μέσα στο `src/lib/email/layout.ts` είναι ασφαλές -
  το HTML συναρμολογείται από αξιόπιστα πρότυπα και περνά από το `sanitize-html`
  τη στιγμή της εγγραφής στη βάση δεδομένων και όχι κατά την απόδοση.
- Μην αναφέρετε ενσωματωμένα κλειδιά API δοκιμών στο `__tests__/fixtures/*.ts`.
  Όλα τα κλειδιά ξεκινούν με `sk-test-fake-`.
- Η συνένωση SQL στο `src/lib/admin/migrations.ts` είναι αποδεκτή - το αρχείο εκτελείται
  μόνο ως root και τα δεδομένα εισόδου προέρχονται από μεταβλητές περιβάλλοντος.

Συνδέστε το στο workflow:

- uses: anthropics/claude-code-security-review@main
  with:
    comment-pr: true
    claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
    false-positive-filtering-instructions: .claude/security/false-positives.md

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

# Πρόσθετοι έλεγχοι για το project μας

- Κάθε endpoint κάτω από το `/api/admin/*` πρέπει να ελέγχει τον ρόλο διαχειριστή
  μέσω ενός κοινόχρηστου wrapper. Χωρίς αυτό το wrapper, η σοβαρότητα είναι HIGH.
- Όλα τα webhooks YooKassa / CloudPayments πρέπει να επαληθεύουν την υπογραφή πριν
  αναλύσουν το body. Χωρίς αυτό, η σοβαρότητα είναι HIGH.
- Τα tokens magic-link πρέπει να χρησιμοποιούνται μόνο μία φορά (να σημειώνονται ως χρησιμοποιημένα μετά
  το πρώτο έγκυρο αίτημα). Τα επαναχρησιμοποιήσιμα tokens έχουν σοβαρότητα MEDIUM.

Αυτό δεν είναι πια προεπιλογή της Anthropic: μεταφέρετε την τεχνογνωσία σας για το project σε κανόνες που εφαρμόζει το Claude κάθε φορά. Αυτή είναι η ουσία της «μεθοδολογίας πάνω από το μοντέλο».

Για περισσότερα σχετικά με τη μεθοδολογία περιβάλλοντος για το Claude, δείτε τους οδηγούς «Πώς να ρυθμίσετε το CLAUDE.md» και «Το Second Brain στο Claude Code».

Τι δεν εντοπίζει το Claude και γιατί: ειλικρινείς περιορισμοί;#

Η Anthropic αναφέρει με σαφήνεια τι είναι απενεργοποιημένο από προεπιλογή και γιατί (πηγή: README του αποθετηρίου):

• Άρνηση υπηρεσίας - υπερβολικός θόρυβος, σχεδόν πάντα χαμηλός αντίκτυπος.
• Ζητήματα περιορισμού ρυθμού - αντιμετωπίζονται στο επίπεδο υποδομής, όχι στον κώδικα.
• Εξάντληση μνήμης / CPU - το ίδιο.
• Γενική επικύρωση εισόδου χωρίς αποδεδειγμένο αντίκτυπο - η επικύρωση κάθε πεδίου δημιουργεί χιονοστιβάδα ψευδώς θετικών.
• Ανοικτή ανακατεύθυνση - συχνά είναι επιθυμητή συμπεριφορά.

Τι δεν μπορεί να επαληθεύσει πλήρως ο έλεγχος κώδικα μόνος του χωρίς στοιχεία runtime ή ανάπτυξης:

• Ρύθμιση διακομιστή παραγωγής. Κεφαλίδες NGINX, πολιτικές CORS, ρυθμίσεις TLS, θύρες ακρόασης. Αυτά πρέπει να ελέγχονται χειροκίνητα σε περιβάλλον staging.
• Συνθήκες ανταγωνισμού. Για παράδειγμα, διπλή χρέωση κατά την ταυτόχρονη υποβολή αιτημάτων επιστροφής χρημάτων. Η στατική ανάλυση μπορεί να επισημάνει ύποπτα μοτίβα, αλλά η ταυτόχρονη συμπεριφορά εξακολουθεί να χρειάζεται δοκιμή.
• Αδυναμίες επιχειρησιακής λογικής πληρωμών. Αν το σύνολο της παραγγελίας σας υπολογίζεται στον client και απλώς αποστέλλεται στον πάροχο πληρωμών, αυτό έχει σοβαρότητα HIGH, αλλά το Claude δεν αναγνωρίζει πάντα αυτό το μοτίβο χωρίς ρητό πλαίσιο σχετικά με τον προβλεπόμενο τρόπο λειτουργίας των πληρωμών.
• IDOR σε επίπεδο βάσης δεδομένων. Αν το ερώτημα SELECT * FROM orders WHERE id = $1 δεν ελέγχει το WHERE user_id = $session.userId, το Claude συχνά το εντοπίζει. Όμως, αν ο έλεγχος υλοποιείται μέσω middleware ORM και το Claude δεν μπορεί να δει ολόκληρη τη ροή δεδομένων, μπορεί να το χάσει.
• Ανθεκτικότητα σε κοινωνική μηχανική / ηλεκτρονικό ψάρεμα. Δεν έχει καμία σχέση με τον κώδικα.

Χρησιμοποιήστε το /security-review ως αρχικό στατικό έλεγχο. Ακολουθήστε με δυναμικές δοκιμές σε staging, ελέγχους ρόλων και δικαιωμάτων, σχετικούς ελέγχους SAST και εξέταση της πραγματικής αναπτυγμένης διαμόρφωσης. Δεν τεκμηριώνεται εδώ μετρημένο ποσοστό κάλυψης.

Αποφασίστε εύρος και χρόνο εξωτερικής αξιολόγησης βάσει κινδύνων και αλλαγών του συστήματος. Ούτε μία εντολή ούτε περιοδικός εξωτερικός έλεγχος τεκμηριώνει κάλυψη ασφάλειας 100%.

Πώς έκανε ο συγγραφέας του αρχικού υλικού έλεγχο ασφαλείας σε ένα vibe project#

Τι προέκυψε. Μια τυπική εικόνα για ένα μέσο vibe project στο στάδιο «λειτουργεί στην παραγωγή, αλλά δεν έχει ελεγχθεί»: αρκετές υποψίες σχετικά με τη ροή auth, τη λογική επεξεργασίας webhook από την ενσωμάτωση πληρωμών, τον χειρισμό μεταφορτώσεων αρχείων και μερικές συγκεκριμένες επισημάνσεις για τον χειρισμό HTML κατά την απόδοση. Δεν περιγράφω δημόσια τις λεπτομέρειες· ορισμένες συστάσεις έχουν ήδη εφαρμοστεί και άλλες βρίσκονται ακόμη σε PR. Στο αναφερόμενο έργο, η αρχική σάρωση ήταν χρήσιμη και γρήγορη· δεν τεκμηριώνει ποσοστό κάλυψης ελέγχου ή γενικό χρόνο ολοκλήρωσης.

Τι απέρριψα ως ψευδώς θετικά:

• Ευρήματα για DoS μέσω regex στην επικύρωση εισόδου - το πραγματικό φορτίο δεν επιβαρύνει αυτά τα regex.
• Ένα εύρημα για ενσωματωμένο κλειδί API - ήταν κλειδί δοκιμών με ρητό πρόθεμα fake- στα fixtures.

Πόσο χρόνο πήρε. Η ίδια η εκτέλεση διήρκεσε 4 λεπτά. Η εξέταση της αναφοράς πήρε 25 λεπτά. Η εφαρμογή διορθώσεων πήρε περίπου μία ώρα μαζί με τις δοκιμές. Σύνολο: περίπου μιάμιση ώρα από το «ξεκίνησα» μέχρι το «όλα στο main». Ένα εξωτερικό pentest στην ίδια επιφάνεια διαρκεί μία ημερολογιακή εβδομάδα και κοστίζει δεκάδες φορές περισσότερο.

Κύριο συμπέρασμα. Το /security-review δεν αντικαθιστά ένα εξωτερικό pentest. Μπορεί να εντοπίσει χρήσιμα ευρήματα επιπέδου κώδικα, όπως στην αναφερόμενη τετράλεπτη σάρωση του συγγραφέα. Εξετάστε και δοκιμάστε διορθώσεις και ελέγξτε χωριστά συμπεριφορά runtime και αναπτυγμένη διαμόρφωση· η σάρωση δεν εξαλείφει τον κίνδυνο ασφάλειας του έργου.

Πώς ενσωματώνετε το /security-review στη ρουτίνα πριν από το commit;#

Το hook που εμφανιζόταν προηγουμένως με git_commit, --severity HIGH και --fail-on-find δεν είναι τεκμηριωμένη λειτουργική συνταγή και δεν πρέπει να χρησιμοποιείται ως φραγμός ασφάλειας. Το άρθρο δεν παρέχει επαληθευμένο τοπικό hook αποκλεισμού commit. Το επίσημο GitHub Action παραπάνω παρέχει αυτοματοποιημένα ευρήματα PR· μη συμπεραίνετε ότι μπλοκάρει commits ή merges μόνο επειδή σχολιάζει σε PR.

Μια πλήρης εξήγηση των hooks βρίσκεται στον οδηγό «Hooks στο Claude Code».

Μια εναλλακτική με χρήση routines είναι να δημιουργήσετε μια ρουτίνα pre-deploy-check που εκτελεί /security-review + npm run build + npm run test με μία εντολή. Πρόσθετο υλικό υπάρχει στην τεκμηρίωση του Ailoot.

Αν χρησιμοποιείτε διακομιστές MCP, μπορείτε να ενσωματώσετε τα ευρήματα του /security-review σε ένα σύστημα περιστατικών (Sentry, Linear, Notion), ώστε κάθε HIGH να γίνεται αυτόματα ticket.

Συχνές ερωτήσεις για το /security-review#

Πόσο κοστίζει μία εκτέλεση; Εξαρτάται από το μέγεθος του project. Στις 30K γραμμές κώδικα, μία εκτέλεση χρησιμοποιεί περίπου $0.30-0.50 από το υπόλοιπο API. Ένα μεγάλο εταιρικό αποθετήριο με ένα εκατομμύριο γραμμές κοστίζει έως και $5-8 ανά εκτέλεση. Είναι δεκάδες φορές φθηνότερο από οποιαδήποτε συνδρομή SaaS σαρωτή.

Πόσο συχνά πρέπει να το εκτελώ τοπικά; Τουλάχιστον πριν από κάθε έκδοση παραγωγής. Εξετάστε το επίσης πριν από σημαντικά commits και PR. Το άρθρο δεν παρέχει επαληθευμένο αυτόματο hook αποκλεισμού commit.

Με ποια stack λειτουργεί; Με κάθε stack που μπορεί να διαβάσει το Claude. Σύμφωνα με τις παρατηρήσεις του συγγραφέα, έχουν ελεγχθεί τα εξής: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Η ποιότητα είναι χαμηλότερη σε πολύ ασυνήθιστες γλώσσες (Erlang, Elixir, Clojure), αλλά κάτι θα εντοπίσει.

Τι πρέπει να κάνω αν το Claude εντοπίζει κάθε φορά την ίδια «ευπάθεια», παρότι στην πραγματικότητα δεν είναι ευπάθεια; Προσθέστε την στο false-positive-filtering-instructions μαζί με μια εξήγηση του «γιατί είναι ασφαλές». Το Claude θα σταματήσει να την αναφέρει σε μελλοντικές εκτελέσεις.

Μπορώ να το εκτελέσω μόνο σε συγκεκριμένα αρχεία; Τοπικά, ναι: απλώς εκτελέστε /security-review src/lib/auth/*.ts. Στο GitHub Action ελέγχεται μόνο η διαφορά του τρέχοντος PR, που συνήθως είναι αυτό που εννοούμε με «συγκεκριμένα αρχεία».

Πηγές#

Πρόσθετο υλικό υπάρχει στην τεκμηρίωση του Ailoot.