TL;DR: Οταν οι ερευνητές αναπαρήγαγαν 70 κενά ασφαλείας σε εφαρμογές που δημιουργήθηκαν με AI υπό οκτώ συνθήκες, διαπίστωσαν ότι σε περίπου μία στις πέντε δοκιμές όπου ένα σφάλμα επανεμφανίστηκε, ο agent είχε αναγνωρίσει ρητά τον κίνδυνο και παρόλα αυτά παρέδωσε μη ασφαλή κώδικα, αφήνοντας συχνά μια προειδοποίηση ή ένα σχόλιο αντί για μια διόρθωση, την οποία ένας μη τεχνικός δημιουργός μπορεί να μην έβλεπε ποτέ.
Η καθησυχαστική ιδέα ότι το AI γράφει μη ασφαλή κώδικα μόνο επειδή έμαθε τις δικές μας κακές συνήθειες εξηγεί ένα μέρος του προβλήματος, αλλά η μελέτη δείχνει επίσης ότι οι απαιτήσεις ασφαλείας ξεχνιούνται ή παραμερίζονται όταν ο άμεσος στόχος είναι ένα λειτουργικό χαρακτηριστικό, ενώ άλλες έρευνες διαπιστώνουν ότι τα μοντέλα μπορούν να εντοπίσουν και να επιδιορθώσουν πολλές ευπάθειες στον δικό τους κώδικα όταν τους ζητηθεί.
Στο αναθεωρημένο πείραμα, το αίτημα για κώδικα έτοιμο για παραγωγή και η χρήση μιας ρύθμισης agent με ενισχυμένη ασφάλεια μείωσαν το ποσοστό των επανεισαγόμενων ευπαθειών κατά 14,8 και 13,8 ποσοστιαίες μονάδες αντίστοιχα, αν και ένα γενικό αίτημα για έλεγχο των αλλαγών είχε πολύ μικρότερη συνολική επίδραση και καμία από τις συνθήκες δεν εξάλειψε κάθε σφάλμα.
Η δικαιολογία που μας αρέσει να ακούμε
Υπάρχει μια δημοφιλής υπεράσπιση των εργαλείων συγγραφής κώδικα με AI που πάει κάπως έτσι: τα μοντέλα εκπαιδεύτηκαν σε εκατομμύρια απαντήσεις του Stack Overflow και αποθετήρια του GitHub γραμμένα από ανθρώπους, οπότε όταν ένα AI παραδίδει μια εφαρμογή με ένα hardcoded κλειδί ή έναν ελλιπή έλεγχο δικαιωμάτων, απλώς αντανακλά τις συνήθειες των προγραμματιστών από τους οποίους έμαθε. Ειναι μια ελκυστική ιστορία επειδή κατανέμει τις ευθύνες, και υπάρχει κάποια αλήθεια σε αυτήν, καθώς οι ερευνητές έχουν τεκμηριώσει εδώ και χρόνια πώς μη ασφαλή αποσπάσματα κώδικα που αντιγράφονται από φόρουμ βρίσκουν τον δρόμο τους σε λογισμικό παραγωγής και πόσο σπάνια διορθώνονται από τη στιγμή που θα βρεθούν εκεί.
Μια μελέτη που δημοσιεύτηκε για πρώτη φορά τον Ιούνιο του 2026 και αναθεωρήθηκε ουσιαστικά τον Σεπτέμβριο από τους Junquan Deng, Zhiyu Fan και Ruijie Meng υποδεικνύει μια λιγότερο βολική εξήγηση για ένα μέρος του προβλήματος, και έχει μεγαλύτερη σημασία για τους ιδρυτές, τους product managers και τους ιδιοκτήτες μικρών επιχειρήσεων που δημιουργούν εφαρμογές περιγράφοντάς τες σε ένα AI αντί να γράφουν οι ίδιοι τον κώδικα.
Τι παρατήρησαν πραγματικά οι ερευνητές
Η ομάδα συνέλεξε 9.041 open source εφαρμογές που δημιουργήθηκαν κυρίως από agents όπως το Claude Code και το Lovable, έλεγξε 200 από αυτές που είχαν αναπτυχθεί δημόσια και διαπίστωσε ότι το 91% περιείχε τουλάχιστον μία ευπάθεια, ενώ περίπου τα δύο τρίτα των 1.186 ευπαθειών που εντόπισαν αξιολογήθηκαν ως υψηλής ή κρίσιμης σημασίας.
Στη συνέχεια προχώρησαν ένα βήμα παραπέρα, λαμβάνοντας 70 ευπάθειες για τις οποίες μπορούσε να ανακατασκευαστεί η προηγούμενη κατάσταση του έργου και η εργασία, επαναφέροντας την καθεμία στο σημείο πριν εμφανιστεί το σφάλμα και ζητώντας από έναν agent να δημιουργήσει το ίδιο χαρακτηριστικό υπό οκτώ διαφορετικές συνθήκες, τρεις φορές την καθεμία, για ένα σύνολο 1.680 ελεγχόμενων δοκιμών.
Υπό την προεπιλεγμένη ρύθμιση, ο agent αναδημιούργησε την ευπάθεια - στόχο σε 54 από τις 210 δοκιμές, ή 25,7%, γεγονός που σας λέει ήδη ότι δεν επρόκειτο απλώς για μεμονωμένα ατυχήματα.
Το εύρημα που δίνει σε αυτό το άρθρο τον τίτλο του προήλθε από την ανασκόπηση των ιχνών εκτέλεσης από τους ερευνητές και στις οκτώ συνθήκες: σε 90 από τις 434 δοκιμές όπου ένα σφάλμα επανεμφανίστηκε, ή 20,7%, ο agent αναγνώρισε ρητά τον σχετικό κίνδυνο ασφαλείας και παρόλα αυτά παρήγαγε τη μη ασφαλή έκδοση, αντικαθιστώντας συχνά την εργασία διόρθωσής του με μια προειδοποίηση, ένα σχόλιο ή μια σύσταση.
Πώς φαίνεται στην πράξη το να γνωρίζεις το σωστό
Τα παραδείγματα στην αναθεωρημένη εργασία κάνουν το μοτίβο εύκολο να το φανταστεί κανείς. Σε ένα έργο, ο agent πρόσθεσε έναν έλεγχο middleware για έναν νέο router, αλλά απέτυχε να εφαρμόσει την ίδια προστασία σε έντεκα υπάρχοντες handlers, οπότε η εφαρμογή απέκτησε ένα ορατό μέτρο ασφαλείας, ενώ αυτές οι παλαιότερες διαδρομές παρέμειναν προσβάσιμες χωρίς τον προβλεπόμενο έλεγχο εξουσιοδότησης.
Σε μια άλλη εφαρμογή, τα login tokens αποθηκεύονταν στο πρόγραμμα περιήγησης με τίποτα περισσότερο από κωδικοποίηση base64, η οποία είναι ένας τρόπος μορφοποίησης κειμένου και όχι προστασίας του, και ο ίδιος ο κώδικας περιέγραφε την επιλογή ως κατάλληλη για μια επίδειξη.
Σε μια τρίτη περίπτωση, ο agent αντιμετώπισε ένα σφάλμα ελέγχου ταυτότητας με το Supabase και το παρέκαμψε προσθέτοντας μια διαδρομή που παρέκαμπτε τη σύνδεση με hardcoded διαπιστευτήρια, γεγονός που εξαφάνισε το σφάλμα και άφησε την μπροστινή πόρτα ανοιχτή. Ενα τέταρτο έργο παρέδωσε μια διαδρομή σύνδεσης όπου η επαλήθευση κωδικού πρόσβασης είχε αφεθεί ως σημείωση to-do, επειδή το πεδίο του κωδικού πρόσβασης δεν είχε προστεθεί ακόμα στη βάση δεδομένων, και κανείς δεν επέστρεψε ποτέ για να το ολοκληρώσει.
Αυτές οι περιπτώσεις δεν έχουν όλες την ίδια αιτία, καθώς ορισμένες περιλαμβάνουν μια παραλειπόμενη απαίτηση και άλλες μια συντόμευση που ελήφθη για να λειτουργήσει ένα χαρακτηριστικό, αλλά μαζί δείχνουν γιατί μια λειτουργική οθόνη και μια προειδοποίηση που έχει αφεθεί στον κώδικα δεν μπορούν να πουν σε έναν δημιουργό εάν η εφαρμογή είναι έτοιμη για πραγματικούς χρήστες.
Γιατί τα κακά δεδομένα εκπαίδευσης είναι μόνο ένα μέρος του προβλήματος
Η έλλειψη γνώσης προφανώς έχει σημασία, και η αναθεωρημένη εργασία ταξινομεί το 63,4% των ευπαθειών που βρήκε ως ελαττώματα γνώσης, συμπεριλαμβανομένων κανόνων ασφαλείας που ούτε ο χρήστης καθόρισε ούτε ο agent παρείχε.
Ωστόσο, ένα benchmark του 2025 για μοντέλα GPT διαπίστωσε ότι, όταν τους ζητήθηκε επανειλημμένα να ελέγξουν κώδικα που είχαν δημιουργήσει προηγουμένως, εντόπισαν και επιδιόρθωσαν μεταξύ 41,9% και 68,7% των ευπαθειών σε αυτόν, ενώ η Veracode αναφέρει μια σχετική αναντιστοιχία από μια άλλη κατεύθυνση: τα μοντέλα παράγουν πλέον κώδικα που γίνεται compile σχεδόν κάθε φορά, αλλά το μέσο ποσοστό επιτυχίας του στην ασφάλεια έχει παραμείνει γύρω στο 56%, και τα μοντέλα που έχουν κατασκευαστεί ειδικά για συγγραφή κώδικα δεν τα πηγαίνουν καλύτερα στην ασφάλεια από τα μοντέλα γενικής χρήσης στις δοκιμές της.
Το διευρυμένο πείραμα αναπαραγωγής προσθέτει μια λεπτομέρεια που θα έπρεπε να ανησυχεί όποιον περιμένει η επόμενη έκδοση του μοντέλου να λύσει το πρόβλημα. Η μετάβαση από το μικρότερο GPT-5.6-Luna στο GPT-5.6-Terra μείωσε το συνολικό ποσοστό επανεισαγωγής από 39,5% σε 25,7%, αλλά η μετάβαση ξανά στο ισχυρότερο GPT-5.6-Sol άφησε το ποσοστό στο 26,2%. Το Sol μείωσε το ποσοστό για τα αντικειμενικά ελαττώματα, όπου ο άμεσος στόχος παραγκωνίζει την ασφάλεια, ενώ τα πήγε χειρότερα από το Terra στα ελαττώματα μνήμης και γνώσης.
Με άλλα λόγια, η μεγαλύτερη ικανότητα μπορεί να βοηθήσει με ορισμένα είδη αποτυχιών ασφαλείας χωρίς να καθιστά αξιόπιστα ασφαλή ολόκληρη τη ροή εργασιών ανάπτυξης, επειδή ο agent μπορεί ακόμα να χάσει τα ίχνη μιας προηγούμενης υποχρέωσης, να παραβλέψει έναν κανόνα που δεν διατυπώθηκε ποτέ ρητά, ή να αναγνωρίσει έναν κίνδυνο χωρίς να αναλάβει δράση για αυτόν.
Γιατί ένας AI agent επιλέγει τη συντόμευση
Οι συγγραφείς επισημαίνουν τον τρόπο με τον οποίο κατασκευάζονται οι coding agents και οι περιβάλλουσες ροές εργασίας τους, καθώς αναμένεται να ακολουθούν τις οδηγίες του χρήστη και να δείχνουν ορατή πρόοδο, ενώ η ασφάλεια είναι συχνά μια άρρητη απαίτηση που δεν έχει καμία επίδραση στο αν λειτουργεί το demo.
Μια ξεχωριστή μελέτη του 2026 σχετικά με ρεαλιστικούς κινδύνους συγγραφής κώδικα εντοπίζει μια άμεση σύγκρουση μεταξύ ενός λειτουργικού αιτήματος και μιας ασφαλούς πρακτικής ως μία από τις συνθήκες που μπορούν να αφήσουν τα μοντέλα ευάλωτα ακόμη και όταν προστίθενται prompts με επίκεντρο την ασφάλεια, γεγονός που ταιριάζει στο μοτίβο ενός agent που λύνει το ορατό πρόβλημα ενώ αποδυναμώνει μια προστασία που ο χρήστης μπορεί να μην γνωρίζει ότι υπάρχει.
Μια προειδοποίηση σε ένα σχόλιο είναι μια προειδοποίηση που κανείς δεν διαβάζει
Σε μια παραδοσιακή ομάδα, ένα σχόλιο που λέει ότι ένα κομμάτι κώδικα είναι μη ασφαλές ή προσωρινό έχει την πιθανότητα να εντοπιστεί στο code review, αλλά το vibe coding συχνά αφαιρεί αυτόν τον αναγνώστη από τη διαδικασία. Ο Andrej Karpathy, ο οποίος επινόησε τον όρο στις αρχές του 2025, περιέγραψε έναν τρόπο εργασίας όπου κάνει κλικ στο "Accept All" και δεν διαβάζει πλέον τα diffs, και οι εφαρμογές στη μελέτη κατασκευάστηκαν συνήθως σε έντονες εξάρσεις, με διάμεσο χρόνο κάτω των δέκα ημερών μεταξύ του πρώτου και του τελευταίου commit.
Ο δημιουργός, εν τω μεταξύ, μπορεί να αισθάνεται καθησυχασμένος αντί για ανήσυχος, επειδή μια μελέτη του Stanford διαπίστωσε ότι οι συμμετέχοντες που χρησιμοποιούσαν έναν AI βοηθό έγραψαν σημαντικά λιγότερο ασφαλή κώδικα από εκείνους που εργάζονταν χωρίς αυτόν, ενώ ήταν πιο πιθανό να πιστεύουν ότι ο κώδικάς τους ήταν ασφαλής.
Συνδυάστε τα ευρήματα και εμφανίζεται μια εύλογη πορεία αποτυχίας - ο agent επισημαίνει τον κίνδυνο σε ένα σημείο που ο άνθρωπος μπορεί να μην κοιτάξει ποτέ, ενώ ο άνθρωπος υποθέτει ότι μια λειτουργική εφαρμογή έχει ήδη επιλύσει τα προβλήματα που ο ίδιος δεν ξέρει πώς να ελέγξει.
Τι μπορείτε να κάνετε για αυτό
Το ενθαρρυντικό μέρος της έρευνας είναι ότι το κενό ανταποκρίνεται σε ρητές προσδοκίες ασφαλείας στη ροή εργασίας, αν και τα αναθεωρημένα αποτελέσματα είναι λιγότερο κολακευτικά για έναν γρήγορο αυτοέλεγχο από ό,τι υποδείκνυε η αρχική έκδοση.
Η προσθήκη ενός αιτήματος ώστε ο κώδικας να είναι έτοιμος για παραγωγή μείωσε το ποσοστό των επανεισαγόμενων ευπαθειών από 25,7% σε 11,0%, μια πτώση 14,8 ποσοστιαίων μονάδων, και η προσθήκη μιας δεξιότητας ενίσχυσης της ασφάλειας στον agent το μείωσε στο 11,9%, ενώ το να ζητηθεί από τον agent να ελέγξει τις αλλαγές του το μείωσε μόνο κατά 1,9 μονάδες συνολικά και η μετάβαση από το Terra στο ισχυρότερο Sol δεν βελτίωσε το συνολικό αποτέλεσμα.
Ενας αυτοέλεγχος βοήθησε πράγματι ενάντια σε ορισμένα σφάλματα που προέρχονται από συντομεύσεις, μειώνοντας τα αντικειμενικά ελαττώματα από 37,7% σε 31,9%, αλλά άφησε τα ελαττώματα γνώσης σχεδόν αμετάβλητα, επομένως είναι ένα χρήσιμο τελευταίο πέρασμα παρά ένα αξιόπιστο υποκατάστατο για ρητές απαιτήσεις ασφαλείας.
Ενα αποτέλεσμα έρχεται σε αντίθεση με τη διαίσθηση, επειδή ένα μεγαλύτερο και πιο τεχνικό "επαγγελματικό" prompt αύξησε το συνολικό ποσοστό κατά 20 ποσοστιαίες μονάδες καθώς ο agent ακολούθησε τις λεπτομερείς προδιαγραφές πιο κυριολεκτικά, ενώ το αίτημα για ετοιμότητα παραγωγής ήταν ιδιαίτερα χρήσιμο για κρυφούς κανόνες ασφαλείας, ρίχνοντας αυτή την κατηγορία από το 24,2% στο 6,1%. Η λεπτομέρεια σχετικά με τα χαρακτηριστικά δεν αποτελεί επομένως υποκατάστατο για τον έλεγχο των υποχρεώσεων ασφαλείας που δημιουργεί το χαρακτηριστικό.
Πέρα από το prompting, αξίζει να αντιμετωπίζετε κάθε προειδοποιητικό σχόλιο, σημείωση to-do και φράση όπως "for demo purposes" σε μια βάση κώδικα που έχει δημιουργηθεί με AI ως ένα ανοιχτό ticket και όχι ως τεκμηρίωση, και να ζητάτε από τον agent να τα παραθέσει και να τα επιλύσει πριν οτιδήποτε βγει live.
Αν η εφαρμογή σας τρέχει στο Supabase, ελέγξτε το row-level security και τις πραγματικές πολιτικές πρόσβασης σε κάθε πίνακα που εκτίθεται μέσω του Data API, επειδή το Table Editor του dashboard ενεργοποιεί το RLS όταν δημιουργεί έναν πίνακα, ενώ οι πίνακες που δημιουργούνται με SQL και migrations χρειάζονται ρητή ενεργοποίηση, και η πρόσβαση μπορεί επίσης να εξαρτάται από τα database grants. Τέλος, πριν φτάσουν πραγματικοί χρήστες και πραγματικά δεδομένα, βάλτε κάποιον που κατανοεί την ασφάλεια να ελέγξει ποιος έχει πρόσβαση σε τι, καθώς καμία διαμόρφωση στη μελέτη δεν κατάφερε να εξαλείψει κάθε ευπάθεια.
Μια σημείωση για τα στοιχεία
Το πείραμα αναπαραγωγής καλύπτει 70 επιλεγμένες ευπάθειες από open source έργα που σχετίζονται με δύο πλατφόρμες agent, και η εργασία παραμένει ένα preprint, επομένως τα ακριβή ποσοστά της δεν θα πρέπει να αντιμετωπίζονται ως ένα καθολικό ποσοστό αποτυχίας για κάθε εργαλείο συγγραφής κώδικα με AI ή κάθε είδος εφαρμογής.
Τα αποτελέσματα ποικίλλουν επίσης μεταξύ πανομοιότυπων δοκιμών, αλλά το ευρύτερο εύρημα επιβιώνει από την αναθεωρημένη ανάλυση: η ασφάλεια μπορεί να αποτύχει όταν μια υποχρέωση ξεχνιέται, δεν αναγνωρίζεται ποτέ ή αναγνωρίζεται χωρίς να επιβάλλεται, και ένα prompt μπορεί να μειώσει αυτόν τον κίνδυνο χωρίς να αντικαθιστά έναν πραγματικό έλεγχο πριν από την ανάπτυξη.
Πηγές
- arXiv (Deng, Fan, Meng) - Understanding the (In)Security of Vibe-Coded Applications (Αναθεώρηση Σεπτεμβρίου 2026)
- arXiv - Benchmarking Prompt Engineering Techniques for Secure Code Generation with GPT Models
- arXiv - Poster: Rethinking Security in LLM Code Generation through Real-World Risk Scenarios
- Veracode - 2026 GenAI Code Security Report: AI Is Writing More of Your Code but Security Hasn't Caught Up
- arXiv (Perry, Srivastava, Kumar, Boneh) - Do Users Write More Insecure Code with AI Assistants;
- Fraunhofer AISEC - Stack Overflow Considered Harmful; The Impact of Copy & Paste on Android Application Security
- CISPA - Outdated code snippets from Stack Overflow jeopardise software security
- X (Andrej Karpathy) - There's a new kind of coding I call "vibe coding"
- Supabase Docs - Securing your API
