Οι ψεύτικες αναφορές ασφαλείας που παράγουν AI chatbots πλημμυρίζουν τα open source projects. Πώς μοιάζουν και τι κάνουν οι προγραμματιστές γι'αυτό;
Φαντάσου να ξυπνάς ένα πρωί Δευτέρα, να ανοίγεις το email σου και να βρίσκεις επτά αναφορές ασφαλείας που σε περιμένουν. Ήρθαν μέσα σε 16 ώρες. Η καρδιά σου σφίγγεται - το project σου τρέχει σε δισεκατομμύρια συσκευές σε όλο τον κόσμο. Αφιερώνεις ολόκληρη την ημέρα σου να διαβάζεις, να αξιολογείς, να επικοινωνείς με τους reporters. Και στο τέλος; Κανένα από τα επτά δεν ήταν πραγματικό πρόβλημα.
Αυτό δεν είναι σενάριο επιστημονικής φαντασίας. Συνέβη στον Daniel Stenberg, δημιουργό του curl - του εργαλείου που χρησιμοποιείται σε περίπου 20-30 δισεκατομμύρια εγκαταστάσεις και τρέχει, κυριολεκτικά, παντού: από το iPhone σου ως τα Samsung smart TV και τα αεροπλάνα. Στο FOSDEM 2026 στις Βρυξέλλες, ο Stenberg μίλησε για το φαινόμενο που ονόμασε "AI slop reporting" — τη μαζική αποστολή πλαστών αναφορών ασφαλείας που παράγουν chatbots AI, χωρίς καμία επαλήθευση από τον άνθρωπο που τις υποβάλλει.
Το αποτέλεσμα; Το curl ανέστειλε το bug bounty πρόγραμμά του τον Φεβρουάριο του 2026 — ένα πρόγραμμα που είχε πληρώσει πάνω από 92.000 δολάρια σε 81 πραγματικά ευρήματα ασφαλείας σε έξι χρόνια. Η αιτία: η αναλογία αληθινών reports έπεσε από 1 στα 6 σε 1 στα 20–30.
Αλλά η ιστορία δεν αφορά μόνο το curl. Το ίδιο φαινόμενο έχει παρατηρηθεί στην Python, στο Mesa Project, στο Open Collective και σε δεκάδες άλλα open source projects. Και το ερώτημα που γεννάται είναι πρακτικό: πώς μοιάζει ένα AI-generated security report; Πώς μπορείς να το αναγνωρίσεις — είτε ως συντηρητής είτε ως απλός χρήστης που θέλει να καταλαβαίνει τι συμβαίνει στα tools που χρησιμοποιεί;
Γιατί κάποιος στέλνει πλαστές αναφορές ασφαλείας;
Η απάντηση είναι στρωτή: τα bug bounty προγράμματα. Το curl προσέφερε έως $10.000 για ένα critical εύρημα και $500 για ένα low-severity. Με ένα LLM chatbot, το κόστος για να παράγεις μια εντυπωσιακά "τεχνική" αναφορά είναι μηδέν. Ο χρόνος που απαιτείται; Δευτερόλεπτα.
Ο Stenberg το συγκρίνει με το spam email: αν ένα στα εκατομμύρια μηνύματα αποφέρει κάτι, αξίζει να στείλεις δύο εκατομμύρια. Εδώ, αν ένα report από τα δέκα "περάσει" και αποφέρει $500, ο "επενδυτής" με τα chatbots βγαίνει μπροστά. Το πρόβλημα είναι ότι το κόστος το πληρώνουν οι εθελοντές συντηρητές με ώρες ζωής, ενέργεια και ψυχική υγεία.
📌 Σημαντικό: Ο Stenberg τόνισε ότι το πρόβλημα δεν είναι η τεχνολογία AI. Είναι ο άνθρωπος που επιλέγει να μην επαληθεύει αυτό που του δίνει το chatbot πριν το υποβάλει. "Δεν μπορώ να φτιάξω τους ανθρώπους, ούτε καν με AI," είπε χαρακτηριστικά στο FOSDEM.
10 σημάδια ότι μια αναφορά ασφαλείας φτιάχτηκε από Chatbot
Βασισμένα στην εμπειρία του Stenberg και σε ευρύτερη έρευνα από την κοινότητα του open source, αυτά είναι τα πιο αξιόπιστα σημάδια:
1. Υπερβολικά ευγενική γλώσσα στην αρχή
Ο Stenberg το είπε αστεία αλλά ακριβώς: "Κανένας άνθρωπος δεν ξεκίνησε ποτέ ένα security report με 'I apologize, but I found a problem.'" Οι πραγματικοί ερευνητές ασφαλείας τείνουν να είναι άμεσοι — μερικές φορές και αγενείς. Ένα report που ανοίγει με εκτενείς ευχαριστίες, αναγνώριση της προσπάθειας της ομάδας και χαμηλόφωνη "επισήμανση" μοιάζει περισσότερο με AI output παρά με αυθεντική ανακάλυψη.
2. Τέλεια αγγλικά χωρίς κανένα τυπογραφικό λάθος
Οι άνθρωποι κάνουν λάθη. Ιδιαίτερα σε τεχνικά κείμενα που γράφονται σε δεύτερη γλώσσα. Ένα report χωρίς ούτε ένα typo, με άψογη σύνταξη και γραμματική καθ' όλη τη διάρκειά του, είναι ασυνήθιστο για αυθεντική ανθρώπινη γραφή, ειδικά σε ένα υποβολή στο HackerOne στις 2 το πρωί.
3. Mixed Case τίτλος "Για Να Φαίνεται Σοβαρό"
Οι τίτλοι των πλαστών reports συχνά γράφονται με κεφαλαία σε κάθε λέξη. "Critical Memory Corruption Vulnerability In HTTP/3 Stack". Μια συνήθεια που τα LLMs έχουν υιοθετήσει από τεχνικά άρθρα και CVE databases. Κανένας άνθρωπος δεν γράφει έτσι φυσικά.
4. Απίθανο μήκος, χιλιάδες λέξεις χωρίς ουσία
Παλιά, ένας maintainer παρακαλούσε τους reporters: "Μπορείτε να μου δώσετε λίγο περισσότερες λεπτομέρειες;" Τώρα το πρόβλημα είναι το αντίθετο. Ο Stenberg λέει ότι τα AI reports έχουν γίνει τόσο μακροσκελή που πλέον ζητά: "Μπορείς να μου εξηγήσεις αυτό σε 10 γραμμές ή λιγότερες;" Αν δεν το κάνει, λαμβάνει 200 ακόμη γραμμές στην επόμενη απάντηση.
5. Bullet point bonanza. Τριάδες παντού
Κάθε παράγραφος ακολουθείται από ακριβώς τρία bullet points. Μετά άλλα τρία. Και άλλα τρία. Ο Stenberg το παρατήρησε επανειλημμένα: "Ένας άνθρωπος δεν γράφει 12 παραγράφους, η καθεμία με ακριβώς τρία bullet points." Αυτό είναι AI formatting, όχι ανθρώπινη γραφή.
6. Emojis μέσα σε τεχνικά παραδείγματα κώδικα
Αν βλέπεις emojis ενσωματωμένα σε code snippets ή σε τεχνική τεκμηρίωση ασφαλείας, κάτι δεν πάει καλά. Τα LLMs έχουν εκπαιδευτεί σε τεράστια ποσότητα περιεχομένου από το ίντερνετ, συμπεριλαμβανομένων άρθρων με emojis, και μερικές φορές αυτά "διαρρέουν" σε τεχνικό κώδικα με τρόπο που κανένας έμπειρος developer δεν θα έκανε.
7. "You're absolutely right" στις follow-up απαντήσεις
Όταν ο Stenberg ρωτούσε follow-up ερώτηση, έπαιρνε πάντα κάτι σαν: "You're absolutely right. I apologize for the confusion." Κι ύστερα μια νέα, ακόμη μεγαλύτερη απάντηση που συχνά έχανε το νήμα της αρχικής συζήτησης. Οι chatbots συμφωνούν με τον συνομιλητή τους. Δεν αντιδρούν με την αυτοπεποίθηση ενός ερευνητή που γνωρίζει τι ανακάλυψε.
8. Πλαστές τεχνικές αποδείξεις (fake GDB sessions, κώδικας που δεν κάνει compile)
Αυτό είναι το πιο επικίνδυνο σημείο, γιατί είναι και το πιο δύσκολο να εντοπιστεί. Ο Stenberg περιέγραψε στο FOSDEM ένα report για ένα "HTTP/3 stream dependency cycle exploit" που ήρθε πλήρες με GDB sessions, register dumps και proof-of-concept κώδικα. Έδειχνε πολύ αληθινό. Αλλά η συνάρτηση στην οποία αναφερόταν το report δεν υπάρχει στο curl. Το GDB session ήταν εξ ολοκλήρου επινοημένο. Τα register contents ήταν λάθος. Τίποτα από αυτά δεν συνέβη ποτέ.
9. Όλα είναι "CRITICAL", ακόμη και τα ασήμαντα
Όταν υπάρχει bug bounty με $10.000 για critical ευρήματα, τι κάνει ένα AI που δεν γνωρίζει πραγματικό severity; Βάζει "CRITICAL" παντού. Ο Stenberg παρατήρησε ότι σχεδόν κάθε πλαστό report έφτανε ως critical, ακόμα και αν αφορούσε κάτι εντελώς αθώο, όπως το γεγονός ότι το Git repository του project είναι… δημοσίως ορατό στο internet (κάτι που είναι, φυσικά, απολύτως σκόπιμο).
10. Αναφορά σε χαρακτηριστικά ή εκδόσεις που δεν υπάρχουν
Τα LLMs hallucinate δηλαδή "εφευρίσκουν" πληροφορίες που φαίνονται αληθινές αλλά δεν είναι. Στα security reports αυτό εκδηλώνεται ως αναφορές σε functions που δεν υπάρχουν στον κώδικα, changelogs που δεν αντιστοιχούν στην πραγματικότητα, ή code snippets που δεν θα έκαναν compile ποτέ. Το curl security team έλαβε report με κώδικα curl_easy_setopt με λάθος signature, κώδικας που απλά δεν θα δούλευε.
Το πρόβλημα εξελίσσεται και γίνεται πιο δύσκολο να εντοπιστεί
Αν νομίζεις ότι αρκεί να ψάχνεις για τα παραπάνω σημάδια για να είσαι ασφαλής, υπάρχουν νέες εξελίξεις που περιπλέκουν τα πράγματα.
Πρώτον, τα ίδια τα AI models βελτιώνονται συνεχώς. Ο Stenberg παρατήρησε ότι τα reports του 2026 δεν μοιάζουν ακριβώς με αυτά του 2025. Τα LLMs μαθαίνουν να αποφεύγουν τα γνωστά "τελικά σημάδια". Δεύτερον, κάποιοι reporters ξεκίνησαν να επαναγράφουν τα AI outputs με το χέρι, για να αφαιρέσουν τα χαρακτηριστικά τεκμήρια AI-γραφής. Αποτέλεσμα: reports που δεν ακούγονται σαν AI, αλλά εξακολουθούν να βασίζονται σε hallucinated πληροφορίες.
Τρίτον, υπάρχει πλέον μια "νέα γενιά ηλιθιότητας", όπως την αποκάλεσε ο Stenberg. Ορισμένοι χρησιμοποιούν AI για να βρουν τι να αναφέρουν, αλλά το γράφουν μόνοι τους. Αποτέλεσμα: reports που αναφέρουν πράγματα όπως "βρήκα ότι το Git repository σου είναι δημοσίως ορατό", μια "αποκάλυψη" που για κάθε open source project είναι απολύτως σκόπιμη.
"Μεταξύ 30% και 70% των submissions που λάβαμε στα τέλη του 2025 και στις αρχές του 2026 ήταν AI-generated. Δυο χρόνια πριν, δεν υπήρχε τίποτα τέτοιο."
— Daniel Stenberg, δημιουργός του curl, FOSDEM 2026
Γιατί έχει σημασία. Πέρα από το curl
Μπορεί να αναρωτιέσαι: "Και τι με νοιάζει εμένα; Δεν συντηρώ open source software." Η απάντηση είναι απλή: χρησιμοποιείς open source software. Το curl τρέχει στο κινητό σου, στο laptop σου, στις εφαρμογές που ανοίγεις κάθε μέρα. Η Python εκτελεί εκατομμύρια web services. Το OpenSSL κρυπτογραφεί τις online συναλλαγές σου.
Όταν ένας μικρός αριθμός εθελοντών, η ομάδα ασφαλείας του curl αποτελείται από επτά άτομα, ξοδεύει τον χρόνο του να αξιολογεί εκατοντάδες πλαστά reports, αυτό έχει συνέπειες:
- Μειωμένη προσοχή στα πραγματικά προβλήματα: Ο "θόρυβος" δημιουργεί fatigue. Υπάρχει ο κίνδυνος ένα πραγματικό critical vulnerability να χαθεί ανάμεσα σε 30 πλαστά.
- Burnout: Το open source είναι ήδη ένας χώρος με υψηλά επίπεδα εξουθένωσης. Η πρόσθεση εκατοντάδων ωρών σε ανούσιο triage επιδεινώνει ένα ήδη σοβαρό πρόβλημα.
- Supply chain risks: Ο Stenberg το είπε ξεκάθαρα: αν η ποιότητα του project υποφέρει λόγω εξουθένωσης, αυτό γίνεται πρόβλημα για όλους όσους εξαρτώνται από αυτό.
Τι κάνουν τα Projects. Τι μπορείς να κάνεις εσύ
Τα open source projects δοκιμάζουν διάφορες στρατηγικές για να αντιμετωπίσουν το πρόβλημα, με διαφορετικά αποτελέσματα:
| Στρατηγική |
Αποτέλεσμα |
Μειονέκτημα |
| Checkbox "χρησιμοποίησες AI;" |
Δούλεψε 3-4 φορές |
Οι reporters απλά λένε "όχι" |
| Ban reporters |
Άμεση αντίδραση |
Νέος λογαριασμός σε λεπτά |
| Public shaming των πλαστών reports |
Κάποια αποτρεπτική επίδραση |
Επηρεάζει τους "καλούς" reporters |
| Κατάργηση bug bounty (curl) |
Αφαιρεί οικονομικό κίνητρο |
Αποθαρρύνει και νόμιμους ερευνητές |
| Raised reputation requirements |
Μειώνει new entrants |
Κλείνει πόρτες σε νέους ερευνητές |
Καμία από αυτές τις λύσεις δεν είναι τέλεια. Ο Stenberg το παρομοίασε με το spam των emails: "Έχουμε μια λύση για το spam. Δεν δουλεύει, αλλά τουλάχιστον κάτι κάναμε."
Αν εσύ θέλεις να κάνεις ένα αυθεντικό security report σε ένα open source project, η καλύτερη συμβουλή είναι:
- Επαλήθευσε ό,τι σου δίνει το AI: τρέξε τον κώδικα, δες αν η συνάρτηση υπάρχει στην πραγματικότητα.
- Γράψε σύντομα και συγκεκριμένα: αν δεν μπορείς να εξηγήσεις το πρόβλημα σε 5-10 γραμμές, πιθανώς δεν το καταλαβαίνεις.
- Χρησιμοποίησε την έκδοση που τρέχεις εσύ: μην αναφέρεις εκδόσεις που δεν έχεις δοκιμάσει.
- Δώσε reproduction steps που δουλεύουν: αν δεν μπορείς να αναπαράγεις το πρόβλημα μόνος σου, δεν είσαι έτοιμος να το αναφέρεις.
Η άλλη πλευρά: Το AI μπορεί να βρει πραγματικά Bugs
Ο Stenberg, δεν είναι κατά του AI ως τεχνολογία. Και εδώ βρίσκεται η ουσιαστική διαφορά που αξίζει να κατανοήσουμε.
Το curl χρησιμοποιεί πλέον AI-powered εργαλεία ανάλυσης κώδικα εσωτερικά. Από τότε που ξεκίνησαν, ο Stenberg έχει διορθώσει πάνω από 100 bugs που εντόπισαν αυτά τα εργαλεία, bugs που κανένα από τα παλαιότερα, παραδοσιακά εργαλεία δεν είχε βρει. Τον Σεπτέμβριο του 2025, ένας ερευνητής ασφαλείας βασισμένος στην Πολωνία, ο Joshua Rogers, χρησιμοποίησε AI scanning tools με τον σωστό τρόπο, με ανθρώπινη εμπειρία και επαλήθευση, και εντόπισε δεκάδες πραγματικά προβλήματα στο curl.
Η διαφορά μεταξύ χρήσιμης και επιβλαβούς χρήσης του AI σε security research δεν είναι στην τεχνολογία. Είναι στον έμπειρο άνθρωπο που ξέρει να αξιολογεί τα αποτελέσματα, να απορρίπτει τα false positives και να επαληθεύει ότι ένα εύρημα είναι πραγματικό πριν το υποβάλει.
🔑 Το κλειδί
Ένα AI tool που βρίσκει πιθανά προβλήματα είναι ένα σημείο εκκίνησης, όχι ένα έτοιμο security report. Ο ανθρώπινος έλεγχος, η επαλήθευση και η κατανόηση του κώδικα δεν μπορούν να παραλειφθούν, και αυτός ακριβώς ο παραλειπόμενος έλεγχος είναι που κάνει τη διαφορά ανάμεσα σε ένα χρήσιμο εύρημα και σε "AI slop".
Συμπέρασμα
Το open source ecosystem είναι η υποδομή του σύγχρονου internet, και η ασφάλειά του εξαρτάται σε μεγάλο βαθμό από εθελοντές που δουλεύουν με περιορισμένους πόρους. Η πλημμύρα πλαστών AI-generated security reports δεν είναι απλώς ένα τεχνικό αστείο. Είναι ένα πρόβλημα που μπορεί να έχει πραγματικές συνέπειες στο λογισμικό που χρησιμοποιείς καθημερινά.
Το να αναγνωρίζεις τα σημάδια ενός πλαστού report, είτε ως συντηρητής είτε ως χρήστης που παρακολουθεί τα νέα της κοινότητας, είναι μικρό αλλά σημαντικό βήμα για να καταλαβαίνεις τι πραγματικά συμβαίνει στα εργαλεία που εμπιστεύεσαι.
Και αν ποτέ θελήσεις να αναφέρεις ένα security issue σε ένα open source project, δοκίμασέ το πρώτα. Επαλήθευσέ το. Γράψ' το με τα δικά σου λόγια. Και σεβάσου τον χρόνο των ανθρώπων που κρατούν αυτά τα projects ζωντανά.
