Attack Surface Management με Open Source: Αξιολογήσαμε το OASM στο Εργαστήριο της Audax Cybersecurity

Στήσαμε στο απομονωμένο εργαστήριό μας το OASM, μια open-source πλατφόρμα Attack Surface Management, την τρέξαμε ενάντια σε έναν καλοήθη στόχο που ελέγχουμε πλήρως, και καταγράφουμε με στοιχεία τι πραγματικά κάνει — και, κυρίως, πού σταματά η αυτοματοποιημένη χαρτογράφηση της επιφάνειας επίθεσης και πού αρχίζει το συνεχές, ανθρωποκεντρικό Continuous Threat Exposure Management.

Εισαγωγή

TL;DR (EN): A hands-on lab evaluation of OASM, an open-source Attack Surface Management platform with an AI layer — what it discovers, its limits, and where ASM ends and CTEM begins.

Κάθε οργανισμός σήμερα έχει μια επιφάνεια επίθεσης πολύ μεγαλύτερη από όση νομίζει. Domains που ξεχάστηκαν, subdomains που δημιουργήθηκαν για ένα project και έμειναν ζωντανά, ένας cloud server που σηκώθηκε «προσωρινά», ένα admin panel εκτεθειμένο στο διαδίκτυο, ένα πιστοποιητικό TLS που έληξε. Η εξωτερική επιφάνεια επίθεσης (external attack surface) δεν είναι στατική· αναπνέει, μεγαλώνει και αλλάζει κάθε μέρα, συχνά χωρίς να το ξέρει κανείς στην ομάδα ασφάλειας. Και ο επιτιθέμενος δεν χρειάζεται να βρει τα πάντα — του αρκεί το ένα σημείο που εσείς δεν ξέρετε ότι υπάρχει.

Εδώ ακριβώς μπαίνει η κατηγορία εργαλείων που ονομάζεται Attack Surface Management (ASM), ή, στην εξωστρεφή της εκδοχή, External Attack Surface Management (EASM). Ο στόχος είναι απλός να διατυπωθεί και δύσκολος να υλοποιηθεί συνεπώς: να ανακαλύψεις, να καταγράψεις και να παρακολουθείς συνεχώς όλα τα assets που εκθέτεις προς το διαδίκτυο, και να εντοπίζεις τις εκθέσεις (exposures) πάνω τους πριν το κάνει κάποιος άλλος. Οι εμπορικές πλατφόρμες EASM κοστίζουν συχνά δεκάδες χιλιάδες ευρώ τον χρόνο. Γι’ αυτό, όταν εμφανίζεται μια open-source πλατφόρμα Attack Surface Management που υπόσχεται να κάνει το ίδιο, αξίζει να τη δοκιμάσουμε σοβαρά.

Στην Audax Cybersecurity δεν αξιολογούμε εργαλεία διαβάζοντας το README τους. Τα στήνουμε σε απομονωμένο εργαστήριο, τα τρέχουμε ενάντια σε νόμιμους, ελεγχόμενους στόχους, διαβάζουμε τον πηγαίο κώδικα, και μετά κρίνουμε με αποδείξεις. Αυτό κάναμε με το OASM (Open Attack Surface Management). Το εγκαταστήσαμε, το τρέξαμε από άκρη σε άκρη ενάντια σε έναν καλοήθη στόχο που ελέγχουμε πλήρως, καταγράψαμε πραγματικά ευρήματα, και εντοπίσαμε τόσο τις πραγματικές του δυνατότητες όσο και το κρίσιμο σημείο όπου ένα τέτοιο εργαλείο, από μόνο του, δεν επαρκεί.

Τι είναι το OASM

Το OASM είναι μια open-source, self-hosted πλατφόρμα για τη διαχείριση της επιφάνειας επίθεσης. Με απλά λόγια: εγκαθιστάτε το στη δική σας υποδομή, του δίνετε τα domains και τις IP που σας ανήκουν, και εκείνο ανακαλύπτει τα σχετικά assets (subdomains, διευθύνσεις IP, υπηρεσίες, τεχνολογίες), τα παρακολουθεί για αλλαγές, και τα σαρώνει για ευπάθειες και λανθασμένες παραμετροποιήσεις. Όλα αυτά παρουσιάζονται μέσα από ένα καθαρό web dashboard με χώρους εργασίας (workspaces), δείκτη ρίσκου, καταγραφή θεμάτων (issues), reporting και ένα επίπεδο ερωτημάτων με τεχνητή νοημοσύνη.

Ας ξεκαθαρίσουμε πρώτα τι δεν είναι το OASM. Δεν εφευρίσκει νέες τεχνικές σάρωσης. Είναι, στην ουσία, ένας ενορχηστρωτής: ένα καλοφτιαγμένο επίπεδο που συνδέει μεταξύ τους εργαλεία τα οποία η κοινότητα του offensive security χρησιμοποιεί εδώ και χρόνια — τη σουίτα της ProjectDiscovery. Στα «σπλάχνα» του, κατανεμημένοι workers γραμμένοι σε Go εκτελούν την κλασική αλυσίδα εξωτερικής αναγνώρισης:

• subfinder για ανακάλυψη subdomains από παθητικές πηγές,
• dnsx για ανάλυση DNS εγγραφών,
• httpx για HTTP probing, ανίχνευση τεχνολογιών, τίτλων, web server και TLS,
• naabu για σάρωση θυρών,
• nuclei για σάρωση ευπαθειών με βάση χιλιάδες templates,
• και μια λειτουργία screenshot (μέσω browser automation) που αποτυπώνει οπτικά κάθε ιστότοπο.

Αρχιτεκτονικά, το OASM είναι ένα σοβαρό κομμάτι μηχανικής. Το frontend είναι React 19 (Vite, Tailwind, TanStack, shadcn/ui). Το core API είναι σε NestJS 11 με TypeORM, ουρά εργασιών BullMQ, σύστημα αυθεντικοποίησης better-auth, και ενσωμάτωση AI SDK/LangGraph. Οι workers επικοινωνούν με το API μέσω gRPC και κλιμακώνονται οριζόντια. Η αποθήκευση γίνεται σε PostgreSQL 17 με pgvector (για τα embeddings του AI επιπέδου), Redis για την ουρά, και μια S3-συμβατή αποθήκη (Rustfs) για τα artifacts. Υπάρχει ακόμη ένας MCP server (Model Context Protocol) που εκθέτει τα δεδομένα των assets σε μοντέλα τεχνητής νοημοσύνης, καθώς και ένα ενσωματωμένο chat και μια λειτουργία «Analyze» που καλεί LLM (OpenAI, Anthropic, Google) για ανάλυση ευρημάτων.

Δύο σημεία πρέπει να ειπωθούν νωρίς. Πρώτον, η άδεια χρήσης είναι GPL-3.0 — copyleft, κάτι που έχει σημασία αν σκέφτεστε να το ενσωματώσετε σε ένα κλειστό εμπορικό προϊόν. Δεύτερον, το έργο είναι προ της έκδοσης 1.0 (τη στιγμή της αξιολόγησης στη σειρά v0.6.x, με 30 releases και 857 commits από τον Ιούνιο 2025). Είναι ζωντανό και εξελίσσεται καθημερινά, αλλά είναι νέο — και αυτό φαίνεται τόσο στις δυνατότητες όσο και στις γωνίες που δεν έχουν ακόμη λειανθεί.

Γιατί έχει αξία για επαγγελματίες κυβερνοασφάλειας

Το ερώτημα δεν είναι «είναι εντυπωσιακό;» αλλά «τι πρόβλημα λύνει πρακτικά;». Και εδώ το OASM έχει πραγματική αξία σε τρία επίπεδα.

Πρώτον, ως συνεχής απογραφή της εξωτερικής επιφάνειας επίθεσης. Το μεγαλύτερο πρόβλημα ασφάλειας των περισσότερων οργανισμών δεν είναι μια εξωτική ευπάθεια· είναι το asset που δεν ξέρουν ότι υπάρχει. Ένα εργαλείο που ανακαλύπτει και παρακολουθεί αυτόματα τι εκθέτετε, και σας ειδοποιεί όταν κάτι αλλάζει, αντιμετωπίζει ακριβώς αυτό το τυφλό σημείο. Για μια εσωτερική ομάδα ασφάλειας που δεν έχει budget για εμπορική πλατφόρμα EASM, μια self-hosted open-source λύση είναι μια απολύτως λογική αφετηρία.

Δεύτερον, ως ενοποιημένη κονσόλα πάνω από εργαλεία που ήδη χρησιμοποιείτε. Πολλές ομάδες τρέχουν ήδη χειροκίνητα subfinder, httpx και nuclei μέσα από scripts. Το OASM τα ενορχηστρώνει, αποθηκεύει ιστορικό, δίνει dashboard, δείκτη ρίσκου, καταγραφή θεμάτων και reporting. Η μετάβαση από «scripts σε ένα terminal» σε «πλατφόρμα με μνήμη και διεπαφή» έχει πραγματική λειτουργική αξία.

Τρίτον, ως τροφοδότης (input) ενός ευρύτερου προγράμματος διαχείρισης έκθεσης. Και εδώ βρίσκεται η πιο ενδιαφέρουσα σύνδεση για το ελληνικό και ευρωπαϊκό κοινό. Η χαρτογράφηση της επιφάνειας επίθεσης είναι το πρώτο, απαραίτητο στάδιο ενός προγράμματος Continuous Threat Exposure Management (CTEM). Το OASM κάνει καλά αυτό το πρώτο στάδιο. Το ερώτημα — που θα απαντήσουμε αναλυτικά παρακάτω — είναι τι συμβαίνει με τα υπόλοιπα στάδια, εκείνα όπου η αξία πραγματικά κρίνεται.

Εγκατάσταση και αρχική παραμετροποίηση: αναλυτικός οδηγός βήμα-βήμα

Η εγκατάσταση γίνεται με Docker Compose και είναι, ως επί το πλείστον, εύκολη. Παρακάτω δίνουμε τα πραγματικά βήματα και τις πραγματικές εντολές που εκτελέσαμε στο εργαστήριό μας — όχι θεωρητικές οδηγίες. Μπορείτε να τις ακολουθήσετε αυτούσιες. Ισχύει ένας απαράβατος κανόνας: σαρώνετε μόνο assets που σας ανήκουν, σε απομονωμένο περιβάλλον.

Προαπαιτούμενα

• Λειτουργικό: Linux (δοκιμάστηκε σε σύγχρονο kernel). Δουλεύει και σε macOS/WSL2 με Docker Desktop.
• Docker & Docker Compose: Χρησιμοποιήσαμε Docker 29.1.3 και Compose 2.40. Το Compose πρέπει να υποστηρίζει το YAML tag !override (v2.24+).
• git για την κλωνοποίηση του αποθετηρίου.
• Πόροι: άνετα με ~4 vCPU / 8 GB RAM και μερικά GB ελεύθερου δίσκου για τις εικόνες (console, api, worker, postgres, redis, rustfs, geo-ip).
• Δίκτυο: πρόσβαση στο διαδίκτυο κατά την πρώτη εκκίνηση, καθώς ο worker κατεβάζει τα εκτελέσιμα των εργαλείων (subfinder, httpx, naabu, nuclei, dnsx) και τα templates του nuclei.

Βήμα 1 — Κλωνοποίηση του αποθετηρίου

git clone https://github.com/oasm-platform/open-asm.git
cd open-asm

Βήμα 2 — Προετοιμασία των αρχείων περιβάλλοντος (.env)

Το OASM διαβάζει τρία ξεχωριστά αρχεία .env (core API, console, worker). Αντιγράψτε τα από τα παραδείγματα:

cp core-api/example.env core-api/.env
cp console/example.env  console/.env
cp worker/example.env   worker/.env

Προσοχή: τα προεπιλεγμένα .env περιέχουν ανασφαλείς τιμές (δείτε τη λίστα σκλήρυνσης παρακάτω). Για ένα απομονωμένο εργαστήριο είναι ανεκτές· για οτιδήποτε άλλο, αλλάξτε τις πριν την εκκίνηση.

Βήμα 3 — (Συνιστάται) Απομόνωση δικτύου με override αρχείο

Στο εργαστήριό μας θέλαμε τα πάντα δεμένα μόνο στο loopback (127.0.0.1) και να μη συγκρούονται οι θύρες με άλλα stacks. Δημιουργήσαμε ένα docker-compose.override.yml. Προσοχή σε μια λεπτομέρεια που μας κόστισε χρόνο: το Compose προσθέτει (δεν αντικαθιστά) τις λίστες ports:, οπότε χρειάζεται το tag !override για καθαρή αντικατάσταση:

# docker-compose.override.yml — δένει όλες τις θύρες στο 127.0.0.1
# και ξαναχαρτογραφεί όσες συγκρούονταν με άλλα lab stacks.
services:
  console:
    ports: !override
      - '127.0.0.1:3000:80'
  core-api:
    ports: !override
      - '127.0.0.1:6276:6276'
      - '127.0.0.1:16276:16276'
  postgres:
    ports: !override
      - '127.0.0.1:55432:5432'
  redis:
    ports: !override
      - '127.0.0.1:56379:6379'
  geo-ip:
    ports: !override
      - '127.0.0.1:4360:4360'
  rustfs:
    ports: !override
      - '127.0.0.1:59000:9000'
      - '127.0.0.1:59001:9001'

Επαλήθευση: ελέγξτε ότι το Compose «βλέπει» τις σωστές θύρες πριν σηκώσετε το stack:

docker compose config | grep -A2 published

Βήμα 4 — Λήψη των έτοιμων εικόνων και εκκίνηση του stack

Επιλέξαμε τις προ-χτισμένες εικόνες από το Docker Hub (oasm/oasm-console, oasm/oasm-api, oasm/oasm-worker) αντί να χτίσουμε τοπικά — ταχύτερο και ελαφρύτερο σε δίσκο:

docker compose pull
docker compose up -d --no-build

Αυτό σηκώνει ολόκληρο το σύστημα: κονσόλα, core API, worker, PostgreSQL (pgvector), Redis, Rustfs (S3-compatible αποθήκη) και τον Geo-IP proxy. Ένα one-shot migration container τρέχει πρώτο και εφαρμόζει τα database migrations.

Επαλήθευση (κατάσταση stack):

$ docker compose ps
NAME                 IMAGE                               STATUS                    PORTS
console              oasm/oasm-console:latest            Up 14 minutes             127.0.0.1:3000->80/tcp
geo-ip               ghcr.io/l1ttps/geoip-proxy:latest   Up 14 minutes             127.0.0.1:4360->4360/tcp
oasm-api             oasm/oasm-api:latest                Up 7 minutes (healthy)    127.0.0.1:6276->6276/tcp, 127.0.0.1:16276->16276/tcp
oasm-postgres        pgvector/pgvector:pg17              Up 14 minutes (healthy)   127.0.0.1:55432->5432/tcp
oasm-redis           redis:alpine                        Up 14 minutes (healthy)   127.0.0.1:56379->6379/tcp
oasm-rustfs          rustfs/rustfs:latest                Up 14 minutes             127.0.0.1:59000->9000/tcp, 127.0.0.1:59001->9001/tcp
repo-oasm-worker-1   oasm/oasm-worker:latest             Up 14 minutes

Επαλήθευση (API & κονσόλα):

$ curl -s http://127.0.0.1:6276/api/health
OK
$ curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000
200

Το health endpoint επιστρέφει OK και η κονσόλα απαντά με 200. Ανοίξτε τον browser στο http://localhost:3000.

Βήμα 5 — Επαλήθευση ότι ο worker κατέβασε τα εργαλεία

Με το που συνδεθεί, ο worker κατεβάζει τη σουίτα ProjectDiscovery και ενημερώνει τα templates του nuclei. Δείτε το στα logs:

$ docker logs repo-oasm-worker-1 | grep -Ei "Downloading tool|Extracted|Gocron"
[Worker.Sync]  Downloading tool: httpx_1.9.0_linux_amd64.zip
[Worker.Sync]  Downloading tool: naabu_2.6.1_linux_amd64.zip
[Worker.Sync]  Downloading tool: nuclei_3.8.0_linux_amd64.zip
[Worker.Sync]  Downloading tool: subfinder_2.14.0_linux_amd64.zip
[Worker.Init]  Running: nuclei -ut --silent
[Jobs]         Gocron poller started (Max Concurrency: 10)

Η γραμμή «Gocron poller started» σημαίνει ότι ο worker είναι έτοιμος να παραλάβει εργασίες. Αυτή η λήψη από το διαδίκτυο είναι βολική, αλλά αποτελεί και μια επιφάνεια εφοδιαστικής αλυσίδας (supply chain) που σε αυστηρά περιβάλλοντα πρέπει να ελεγχθεί/καρφιτσωθεί.

Βήμα 6 — Δημιουργία λογαριασμού

Ο πρώτος χρήστης εγγράφεται μέσα από την κονσόλα (σύστημα better-auth, email και κωδικός). Το ίδιο γίνεται και μέσω API:

# Εγγραφή (ο κωδικός είναι placeholder εργαστηρίου — αλλάξτε τον)
curl -s -c cj -X POST http://127.0.0.1:6276/api/auth/sign-up/email \
  -H 'Content-Type: application/json' \
  -d '{"email":"[email protected]","password":"REDACTED","name":"Audax Lab"}'

Επαλήθευση: το endpoint επιστρέφει το αντικείμενο του χρήστη με "role":"user" και θέτει ένα cookie συνεδρίας.

Βήμα 7 — Χώρος εργασίας, στόχος και εκκίνηση σάρωσης

Μέσα στην κονσόλα: δημιουργείτε ένα workspace, προσθέτετε έναν στόχο (ένα δημόσιο domain ή IP που σας ανήκει) και η πλατφόρμα ενορχηστρώνει αυτόματα την αλυσίδα naabu → httpx → screenshot, ενώ η σάρωση ευπαθειών (nuclei) ενεργοποιείται ξεχωριστά. Ισοδύναμα, μέσω API:

# Δημιουργία workspace
curl -s -b cj -X POST http://127.0.0.1:6276/api/workspaces \
  -H 'Content-Type: application/json' -d '{"name":"Audax Lab"}'
# Καταχώρηση στόχου (χρήση cookie wid για το workspace scope)
curl -s -b cj -b "wid=$WSID" -X POST http://127.0.0.1:6276/api/targets/bulk \
  -H 'Content-Type: application/json' \
  -d '{"targets":[{"value":"<ASSET-ΠΟΥ-ΣΑΣ-ΑΝΗΚΕΙ>","type":"IP"}]}'
# Εκκίνηση σάρωσης ευπαθειών (nuclei) στον στόχο
curl -s -b cj -b "wid=$WSID" -X POST http://127.0.0.1:6276/api/vulnerabilities/scan \
  -H 'Content-Type: application/json' -d '{"targetId":"'$TID'"}'

Μετά την ανακάλυψη, το httpx επιστρέφει δομημένο αποτέλεσμα με τον web server και τις τεχνολογίες — π.χ. στη δική μας δοκιμή αναγνώρισε σωστά nginx/1.31.2 και «συμπέρανε» ένα σύνολο τεχνολογιών. Η σάρωση nuclei ολοκληρώθηκε σε περίπου ενάμιση λεπτό και επέστρεψε τα ευρήματα, τα οποία η κονσόλα συγκέντρωσε σε δείκτη ρίσκου. (Τα αναλυτικά αποτελέσματα και τα screenshots της κονσόλας τα βλέπουμε παρακάτω.)

Αντιμετώπιση προβλημάτων

Δύο εμπόδια που συναντήσαμε — και οι λύσεις τους:

• Το Compose «διπλασιάζει» τις θύρες. Αν βάλετε override με νέες θύρες αλλά το Compose προσπαθεί να δεσμεύσει και τις παλιές, φταίει το ότι οι λίστες ports: συγχωνεύονται αθροιστικά. Λύση: το YAML tag !override σε κάθε λίστα ports: (όπως στο Βήμα 3), ώστε να αντικαθιστά αντί να προσθέτει.
• Παροδική αποτυχία του migration σε ψυχρή εκκίνηση. Την πρώτη φορά, το oasm-migration απέτυχε με getaddrinfo EAI_AGAIN postgres — θέμα χρονισμού του embedded DNS του Docker (το migration έτρεξε πριν «σηκωθεί» πλήρως το DNS της PostgreSQL). Λύση: μία επανεκτέλεση μόλις η βάση γίνει healthy:

  docker compose up -d migration
  docker logs oasm-migration | tail

• Το OASM αρνείται τον ιδιωτικό/εργαστηριακό στόχο. Το API απορρίπτει ιδιωτικές/δεσμευμένες IP και μη δημόσια domains: "172.22.0.9" is a private/reserved IP address. Only public IP addresses are allowed. Αυτό είναι εκ σχεδιασμού — το OASM είναι εργαλείο εξωτερικής επιφάνειας επίθεσης και έτσι αποτρέπει κατά λάθος σάρωση εσωτερικών/τρίτων συστημάτων. Για να επιδείξουμε τη μηχανή ενάντια σε έναν στόχο που ελέγχουμε 100% χωρίς να αγγίξουμε κανέναν τρίτο, χαλαρώσαμε έναν και μόνο έλεγχο, αποκλειστικά στη δική μας εγκατάσταση (μια τεκμηριωμένη, τοπική τροποποίηση για benign, ιδιόκτητο asset). Είναι κίνηση αυστηρά εργαστηριακή — σε κανονική χρήση κρατάτε τον έλεγχο ενεργό και δίνετε assets που σας ανήκουν, ή χρησιμοποιείτε τη λειτουργία «internal networks» με worker εντός του εσωτερικού δικτύου.

Υποχρεωτική λίστα σκλήρυνσης πριν από κάθε χρήση πέρα από το εργαστήριο

Το OASM έρχεται με ανασφαλείς προεπιλογές χάριν ευκολίας. Πριν το εκθέσετε οπουδήποτε πέρα από το localhost, περάστε υποχρεωτικά από αυτή τη λίστα:

• ☐ Αλλάξτε όλα τα κλειδιά με τιμή change_me (OASM_CLOUD_APIKEY, WORKER_API_KEY) και τα credentials του Rustfs/Redis.
• ☐ Καταργήστε το POSTGRES_HOST_AUTH_METHOD: trust — χρησιμοποιήστε πραγματικά credentials βάσης και TLS.
• ☐ Περιορίστε το trustedOrigins: ['*'] στα πραγματικά σας origins· ενεργοποιήστε secure + sameSite στα cookies· βάλτε reverse proxy με TLS μπροστά από κονσόλα/API.
• ☐ Αντιμετωπίστε τους workers ως προνομιακούς κόμβους εκτέλεσης: ο worker εκτελεί αυθαίρετες εντολές shell μέσω gRPC (λειτουργία agent/remote-execute). Απομονώστε τους, περιστρέφετε τα κλειδιά, μην εκθέτετε ποτέ το control plane.
• ☐ Καρφιτσώστε/επαληθεύστε τα εκτελέσιμα των εργαλείων που κατεβαίνουν στο runtime (supply chain).
• ☐ Αποφασίστε συνειδητά αν τα δεδομένα των assets επιτρέπεται να περνούν από εξωτερικούς παρόχους LLM (λειτουργίες AI/MCP).
• ☐ Σαρώνετε μόνο assets για τα οποία έχετε ρητή εξουσιοδότηση.

Το εργαστηριακό περιβάλλον δοκιμών

Η φιλοσοφία μας είναι αδιαπραγμάτευτη: τίποτα δεν αγγίζει εξωτερικά ή τρίτα συστήματα, ποτέ. Στήσαμε ένα πλήρως απομονωμένο περιβάλλον:

• Host / stack: Το OASM σε ιδιωτικό Docker bridge (repo_oasm, 172.22.0.0/16), με όλες τις δημοσιευμένες θύρες δεσμευμένες αποκλειστικά στο 127.0.0.1.
• Στόχος (δικός μας, 100%): Ένα container nginx:alpine στο ίδιο ιδιωτικό δίκτυο (alias targetlab, 172.22.0.9), το οποίο σέρβιρε μια καλοήθη σελίδα με σκόπιμα, ακίνδυνα εκτεθειμένα artifacts για λόγους επίδειξης ανίχνευσης: ένα ψεύτικο .env (με placeholder, όχι πραγματικά credentials), ένα εκτεθειμένο .git/config, ένα robots.txt με «ζουμερά» paths, και ένα meta tag WordPress με ένα σχόλιο-δόλωμα phpMyAdmin. Καμία πραγματική υπηρεσία, κανένα πραγματικό δεδομένο, κανένας τρίτος.

Εδώ προέκυψε ένα από τα πιο σημαντικά ευρήματα της αξιολόγησης. Το OASM αρνείται εκ σχεδιασμού να στοχεύσει ιδιωτικές/δεσμευμένες IP και μη δημόσια domains. Όταν προσπαθήσαμε να καταχωρήσουμε τον στόχο μας, το API απάντησε: "172.22.0.9" is a private/reserved IP address. Only public IP addresses are allowed. Αυτό είναι, ταυτόχρονα, δυνατό σημείο (μειώνει τον κίνδυνο κατά λάθος σάρωσης εσωτερικών ή τρίτων συστημάτων και περιορίζει την επιφάνεια SSRF) και ο τίμιος λόγος που ένα εντελώς offline εργαστήριο δεν μπορεί να δοκιμάσει την πλατφόρμα χωρίς είτε τη λειτουργία «internal networks» (που απαιτεί worker εντός του εσωτερικού δικτύου) είτε ένα δημόσιο asset που σας ανήκει. Για να επιδείξουμε τη μηχανή ενάντια σε ένα asset που ελέγχουμε πλήρως, χωρίς ποτέ να αγγίξουμε τρίτο σύστημα, χαλαρώσαμε μόνο έναν έλεγχο, στη δική μας εγκατάσταση. Αυτό είναι μια τεκμηριωμένη, τοπική τροποποίηση για έναν καλοήθη, ιδιόκτητο στόχο — και το δηλώνουμε ρητά.

Πρακτική δοκιμή του εργαλείου

Αφού συνδεθήκαμε στην κονσόλα, δημιουργήσαμε έναν χώρο εργασίας «Audax Lab» και καταχωρήσαμε τον στόχο. Το OASM ενορχήστρωσε αυτόματα την αλυσίδα ανακάλυψης: σάρωση θυρών με naabu, HTTP probing με httpx, και λήψη screenshot της σελίδας.

Το αποτέλεσμα του httpx ήταν ακριβές και διαφωτιστικό. Αναγνώρισε σωστά τον web server ως nginx/1.31.2, διάβασε τον τίτλο της σελίδας, και «συμπέρανε» ένα σύνολο τεχνολογιών: MySQL, Nginx, PHP, WordPress 5.8. Εδώ κρύβεται ένα σημαντικό μάθημα: αυτές οι τεχνολογίες δεν υπήρχαν πραγματικά — τις συμπέρανε αποκλειστικά από το meta tag και το σχόλιο-δόλωμα που εμείς είχαμε φυτέψει. Η ανίχνευση τεχνολογιών βασίζεται σε υπογραφές, και οι υπογραφές παράγουν θόρυβο. Κρατήστε αυτό το σημείο· θα επανέλθουμε.

Στη συνέχεια, ενεργοποιήσαμε τη σάρωση ευπαθειών. Το OASM έβαλε στην ουρά μια εργασία nuclei, ο worker την εκτέλεσε, και μετά από περίπου ένα λεπτό και σαράντα πέντε δευτερόλεπτα η σάρωση ολοκληρώθηκε με 12 ευρήματα. Το dashboard τα συγκέντρωσε σε δείκτη ρίσκου και τα κατέταξε ανά σοβαρότητα.

Τι αποτελέσματα έδωσε

Τα ευρήματα ήταν πραγματικά και, στη μεγάλη τους πλειοψηφία, σωστά. Το nuclei εντόπισε επιτυχώς:

• δύο ευρήματα HIGH για το εκτεθειμένο αρχείο .env (το «Generic Env File Disclosure» και ένα «Codeigniter .env File Discovery»),
• ένα εύρημα MEDIUM για το εκτεθειμένο .git/config,
• «HTTP Missing Security Headers» (INFO), σωστά, καθώς ο nginx έτρεχε με τις προεπιλογές,
• τα ευρήματα για το robots.txt,
• και πλήθος πληροφοριακών (INFO) ανιχνεύσεων τεχνολογιών (WAF, Wappalyzer, Metatag CMS).

Μέχρι εδώ, εξαιρετικά: η πλατφόρμα λειτούργησε από άκρη σε άκρη και βρήκε ακριβώς τις εκθέσεις που είχαμε φυτέψει. Όμως η προσεκτική ανάγνωση των 12 ευρημάτων αποκαλύπτει και την άλλη όψη. Δύο από τα ευρήματα ήταν διπλότυπα για την ίδια έκθεση (το ίδιο .env αναφέρθηκε δύο φορές, με ένα από τα δύο labels — «Codeigniter» — να είναι λανθασμένο, αφού δεν υπήρχε Codeigniter). Και ένα εύρημα, το «WordPress End-of-Life», ήταν ξεκάθαρο false-positive: προήλθε αποκλειστικά από το meta tag που εμείς φυτέψαμε· δεν υπήρχε καμία εγκατάσταση WordPress.

Αυτό δεν είναι κατηγορία εναντίον του OASM — είναι η φυσιολογική, αναμενόμενη συμπεριφορά κάθε σάρωσης βασισμένης σε templates. Είναι όμως το πιο σημαντικό πρακτικό συμπέρασμα της δοκιμής: η ακατέργαστη έξοδος ενός ASM εργαλείου είναι σήμα, όχι απόφαση. Ένα «HIGH: εκτεθειμένο .env» πρέπει κάποιος άνθρωπος να το επαληθεύσει (είναι όντως προσβάσιμο; περιέχει πραγματικά μυστικά; είναι εκμεταλλεύσιμο στο συγκεκριμένο context;). Ένα «WordPress EOL» που δεν υπάρχει πρέπει κάποιος να το απορρίψει. Χωρίς αυτό το φιλτράρισμα, μια ομάδα ασφάλειας πνίγεται σε θόρυβο και χάνει το ένα εύρημα που πραγματικά έχει σημασία.

Το επίπεδο AI, τα εργαλεία και οι κατανεμημένοι workers

Πέρα από την αλυσίδα σάρωσης, το OASM επενδύει έντονα σε δύο κατευθύνσεις που αξίζει να σχολιαστούν. Η πρώτη είναι η επεκτασιμότητα των εργαλείων: κάθε workspace διαθέτει έναν κατάλογο ενσωματωμένων εργαλείων (subfinder, httpx, naabu, nuclei, screenshot) και επιτρέπει την προσθήκη προσαρμοσμένων, με το δικό τους command template και parser. Αυτό μετατρέπει το OASM από μια κλειστή σουίτα σε ένα πλαίσιο ενορχήστρωσης πάνω στο οποίο μια ομάδα μπορεί να χτίσει.

Η δεύτερη είναι το επίπεδο τεχνητής νοημοσύνης. Το OASM εκθέτει τα δεδομένα των assets μέσω ενός MCP server σε μοντέλα LLM, διαθέτει ενσωματωμένο chat, και προσφέρει μια ενέργεια «Analyze» δίπλα σε κάθε ευπάθεια, η οποία καλεί ένα μοντέλο για να την ερμηνεύσει. Η ιδέα είναι ελκυστική — ένας αναλυτής να «ρωτά» την επιφάνεια επίθεσής του με φυσική γλώσσα. Στην πράξη, όμως, αυτή η δυνατότητα φέρνει και μια ευθύνη διακυβέρνησης: αν ενεργοποιηθεί, δεδομένα των assets σας ενδέχεται να ταξιδέψουν σε τρίτους παρόχους (OpenAI, Anthropic, Google). Για έναν οργανισμό υπό NIS2/DORA, αυτή είναι μια συνειδητή απόφαση, όχι μια προεπιλογή που την αφήνεις ενεργή χωρίς σκέψη.

Στο κομμάτι της κλιμάκωσης, η αρχιτεκτονική είναι σωστή. Οι workers εγγράφονται στο core API, στέλνουν heartbeat, και τραβούν εργασίες από μια ουρά. Μπορείτε να προσθέσετε περισσότερους workers οριζόντια, και κάθε εργασία καταγράφεται σε ένα πλήρες μητρώο με δυνατότητα επανεκτέλεσης, ακύρωσης και χρονογραμμής.

Πού σταματά το Attack Surface Management και πού αρχίζει το CTEM

Εδώ φτάνουμε στο πιο σημαντικό σημείο ολόκληρης της αξιολόγησης, και είναι στρατηγικό, όχι τεχνικό.

Το OASM απαντά σε ένα ερώτημα: «Τι εκθέτω, και ποια προφανή θέματα υπάρχουν;». Αυτό αντιστοιχεί στα στάδια της Ανακάλυψης (Discovery) και μέρους της Οριοθέτησης (Scoping) του μοντέλου CTEM της Gartner. Παράγει έναν χάρτη και ένα ρεύμα από σήματα. Και τα κάνει καλά.

Ένα ολοκληρωμένο πρόγραμμα CTEM όμως αποτελείται από πέντε στάδια, και η αξία κρίνεται κυρίως στα τρία που το OASM — εξ ορισμού — δεν καλύπτει:

• Προτεραιοποίηση (Prioritization): ποιες από αυτές τις εκθέσεις έχουν σημασία στο δικό σας επιχειρησιακό και απειλητικό context; Ένα CVSS score πάνω σε ένα label του nuclei δεν είναι προτεραιότητα.
• Επαλήθευση (Validation): είναι όντως εκμεταλλεύσιμο και προσβάσιμο; Η δική μας σάρωση σήμανε ένα HIGH «.env» και ένα ανύπαρκτο «WordPress» — σήματα που ένας άνθρωπος πρέπει να αποδείξει ή να απορρίψει. Εδώ ακριβώς μπαίνει η επαλήθευση αντιπάλου (adversary validation) και το στοχευμένο penetration testing.
• Κινητοποίηση (Mobilization): διορθώθηκε, και αποδείχθηκε ότι διορθώθηκε, με κλειστό τον κύκλο και επαληθευμένη την ανίχνευση από το SOC;

Το OASM δεν κάνει τίποτα από αυτά — και ούτε το ισχυρίζεται. Είναι εξαιρετικό input σε αυτή τη διαδικασία. Το κενό ανάμεσα στο «ένας scanner σήμανε κάτι» και στο «αυτό είναι εκμεταλλεύσιμο, έχει σημασία, να η απόδειξη, και να η αποκατάσταση οδηγημένη μέχρι το τέλος» δεν γεμίζει με ένα container. Γεμίζει με ένα συνεχές, ανθρωποκεντρικό πρόγραμμα. Και για τη συμμόρφωση σε NIS2 και DORA, που απαιτούν αποδεδειγμένη ανθεκτικότητα και όχι μια εξαγωγή scanner, αυτή η διαφορά είναι το παν.

Δυνατά σημεία

• Συνεκτική, σύγχρονη αρχιτεκτονική και ένα πραγματικά καθαρό, εύχρηστο UI — καλύτερο από τα περισσότερα open-source εργαλεία ασφάλειας. Workspaces, δείκτης ρίσκου, καταγραφή θεμάτων, reporting, ζωντανές ενημερώσεις μέσω SSE.
• Στιβαρή μηχανή εξωτερικής αναγνώρισης (η αλυσίδα ProjectDiscovery), με δυνατότητα προσθήκης custom εργαλείων ανά workspace.
• Κατανεμημένοι, οριζόντια κλιμακούμενοι workers μέσω gRPC, με πλήρες μητρώο εργασιών (re-run, cancel, timeline).
• Εγκατάσταση με μία εντολή, προ-χτισμένες εικόνες, healthchecks.
• Λογικός έλεγχος ασφάλειας: η επικύρωση «μόνο δημόσιοι στόχοι» μειώνει τον κίνδυνο κατά λάθος σάρωσης.
• Προωθημένο επίπεδο AI/MCP και εμπλουτισμός Geo-IP.
• Πολύ ενεργή ανάπτυξη, CI, αυτοματοποίηση εξαρτήσεων, σάρωση με Trivy.

Περιορισμοί και αδυναμίες

• Ωριμότητα προ της 1.0 (v0.6.x) — αναμένετε αλλαγές, γωνίες που δεν έχουν λειανθεί, και ενδεχόμενες breaking changes.
• Ανασφαλείς προεπιλογές που πρέπει οπωσδήποτε να σκληρυνθούν πριν από οποιαδήποτε έκθεση πέρα από το localhost.
• Βασικό εύρος ανακάλυψης: μία παθητική σάρωση subfinder, χωρίς credentialed/authenticated scanning, χωρίς ανακάλυψη cloud/API assets, με nuclei στις προεπιλογές. Καλή κάλυψη της «εύκολης» εξωτερικής επιφάνειας, όχι υποκατάστατο βάθους.
• Σήμα, όχι κρίση: διπλότυπα, πληροφοριακός θόρυβος και false-positives (όπως είδαμε) απαιτούν ανθρώπινη διαλογή.
• Ο worker είναι, ουσιαστικά, εκτελεστής αυθαίρετων εντολών μέσω gRPC· ισχυρό και εκ σχεδιασμού, αλλά ένα control plane υψηλής αξίας που πρέπει να προστατευθεί.
• GPL-3.0 — έχει σημασία αν σκοπεύετε να το ενσωματώσετε/αναδιανείμετε σε κλειστό προϊόν.
• Τα χαρακτηριστικά AI μπορεί να στέλνουν δεδομένα assets σε τρίτους παρόχους LLM — μια απόφαση διακυβέρνησης δεδομένων.

Θέματα ασφάλειας κατά τη χρήση

Πριν χρησιμοποιήσετε το OASM πέρα από ένα απομονωμένο εργαστήριο, ένας επαγγελματίας οφείλει να:

1. Αλλάξει όλα τα προεπιλεγμένα μυστικά· να καταργήσει το POSTGRES_HOST_AUTH_METHOD: trust. 2. Μην εκθέσει ποτέ την κονσόλα/API/gRPC σε μη έμπιστα δίκτυα· να βάλει αυθεντικοποίηση πίσω από reverse proxy με TLS, να περιορίσει τα trustedOrigins, και να ενεργοποιήσει secure/sameSite cookies. 3. Αντιμετωπίσει τους workers ως προνομιακούς κόμβους εκτέλεσης — να τους απομονώσει, να περιστρέφει τα κλειδιά. 4. Καρφιτσώσει/επαληθεύσει τα εκτελέσιμα των εργαλείων για ρυθμιζόμενα περιβάλλοντα. 5. Αποφασίσει συνειδητά αν τα δεδομένα των assets επιτρέπεται να περνούν από εξωτερικούς παρόχους LLM. 6. Στοχεύει μόνο assets για τα οποία έχει ρητή εξουσιοδότηση — ο έλεγχος «μόνο δημόσιοι στόχοι» βοηθά, αλλά η εξουσιοδότηση παραμένει δική σας ευθύνη.

Πού μπορεί να χρησιμοποιηθεί επαγγελματικά

Το OASM είναι κατάλληλο για:

• Self-hosted απογραφή και παρακολούθηση της εξωτερικής επιφάνειας επίθεσης domains και IP που σας ανήκουν.
• Μια δωρεάν, ιδιωτική εναλλακτική στις εμπορικές πλατφόρμες EASM για συνεχή ορατότητα assets και τεχνολογιών.
• Τροφοδότηση (input feed) ενός ευρύτερου προγράμματος διαχείρισης έκθεσης, ενός SIEM ή ενός ticketing συστήματος.
• Εργαστήριο εκπαίδευσης πάνω στις έννοιες του ASM και στην αλυσίδα ProjectDiscovery.

Πότε δεν πρέπει να χρησιμοποιηθεί

• Ως turnkey, production-grade managed πρόγραμμα διαχείρισης έκθεσης (είναι ανακάλυψη, όχι απόφαση).
• Όταν χρειάζεστε επαληθευμένα, προτεραιοποιημένα, έτοιμα για audit ευρήματα εκτός κουτιού.
• Για credentialed/εσωτερικού βάθους ή cloud/API αξιολόγηση.
• Για ενσωμάτωση σε κλειστό εμπορικό προϊόν (GPL-3.0).
• Σε οποιαδήποτε εγκατάσταση πέρα από το localhost χωρίς σκλήρυνση των προεπιλογών.

Τελική αξιολόγηση

7 / 10 — Προτείνεται με περιορισμούς. Το OASM είναι μια πραγματικά αξιόλογη open-source πλατφόρμα εξωτερικού ASM: καθαρή, συνεκτική, ενεργά αναπτυσσόμενη, με μια αλυσίδα ανακάλυψης-και-σάρωσης που δούλεψε από άκρη σε άκρη στο εργαστήριό μας ενάντια σε έναν καλοήθη στόχο που ελέγχουμε (fingerprinting με httpx, λήψη screenshot, και 12 ευρήματα nuclei που ταίριαξαν με τις εκθέσεις που φυτέψαμε). Αντιμετωπίστε το ως εργαστηριακό/self-hosted εξοπλισμό: σκληρύνετε τις προεπιλογές, απομονώστε τους workers, σαρώστε μόνο ό,τι σας ανήκει, και — κυρίως — θυμηθείτε ότι παραδίδει έναν χάρτη και σήματα, όχι μια επαληθευμένη, προτεραιοποιημένη απόφαση έκθεσης.

Συμπέρασμα

Το πιο πολύτιμο πράγμα που μας έδειξε η δοκιμή του OASM δεν ήταν το ίδιο το εργαλείο, αλλά το όριο που κάνει ορατό. Η αυτοματοποιημένη χαρτογράφηση της επιφάνειας επίθεσης έχει γίνει προσιτή, ώριμη και, με λύσεις όπως αυτή, ακόμη και δωρεάν. Αυτό είναι θαυμάσιο — και ακριβώς γι’ αυτό η πραγματική διαφοροποίηση δεν βρίσκεται πλέον στο «να βρεις τι εκθέτεις», αλλά στο «να αποδείξεις τι από αυτά πραγματικά σε εκθέτει, να το προτεραιοποιήσεις σωστά, και να κλείσεις τον κύκλο». Ένας scanner σημαίνει· ένας operator αποδεικνύει. Το OASM σχεδιάζει τον χάρτη· η μετατροπή του χάρτη σε μειωμένο ρίσκο είναι ένα συνεχές, ανθρωποκεντρικό πρόγραμμα.

Από το εργαστήριο, στο δικό σας περιβάλλον

Δεν διαβάζουμε απλώς για εργαλεία — τα στήνουμε, τα δοκιμάζουμε και επαληθεύουμε τι πραγματικά κάνουν, όπως ακριβώς κάναμε εδώ με την επιφάνεια επίθεσης ενός στόχου που ελέγχουμε. Την ίδια αυστηρότητα την εφαρμόζουμε συνεχώς στο δικό σας περιβάλλον μέσα από το Erevos AI, την ετήσια υπηρεσία Continuous Threat Exposure Management (CTEM) της Audax Cybersecurity: ένα managed πρόγραμμα τεχνικής επαλήθευσης κυβερνοανθεκτικότητας που ενοποιεί χαρτογράφηση έκθεσης, penetration testing, adversary emulation, detection validation και τεκμηριωμένη αποκατάσταση σε έναν συνεχή κύκλο ελέγχου, απόδειξης και προτεραιοποίησης κινδύνου — με άμεση αξία για τη συμμόρφωσή σας σε NIS2 και DORA.

Human-led. Machine-scaled. Technically proven.

→ Δείτε το Erevos AI: https://www.audax.gr/erevos-ai/ → Χρειάζεστε στοχευμένο έλεγχο τώρα; Penetration testing & adversary validation από την ομάδα της Audax.