Ζαΐντ Αλ Χαμανί, Διευθύνων Σύμβουλος και Ιδρυτής της Boost Security – Σειρά Συνεντεύξεων

Ζαΐντ Αλ Χαμανί, Διευθύνων Σύμβουλος και Ιδρυτής της Boost Security, είναι ένας ηγέτης στον κυβερνοχώρο και τον DevSecOps με πάνω από δύο δεκαετίες εμπειρίας στη δημιουργία και ανάπτυξη παγκόσμιων τεχνολογικών επιχειρήσεων. Από την ίδρυση της Boost Security το 2020, επικεντρώθηκε στη moderneποίηση του τρόπου με τον οποίο οι οργανισμοί ασφαλίζουν την ανάπτυξη λογισμικού, αξιοποιώντας προηγούμενους ρόλους, συμπεριλαμβανομένου του Αντιπροέδρου για την Ασφάλεια Εφαρμογών στο Trend Micro και του Συνιδρυτή/Διευθύνοντος Συμβούλου της IMMUNIO. Νωρίτερα, κατέλαβε υψηλές ηγετικές θέσεις στην Canonical, ηγώντας προϊόντων, μηχανικής και παγκόσμιων πρωτοβουλιών υποστήριξης, και στη SITA, όπου διαχειρίστηκε μεγάλης κλίμακας, κρίσιμες για την αποστολή επιχειρησιακές λειτουργίες. Η καριέρα του αντανακλά ένα ισχυρό ρεκόρ στην κατασκευή ομάδων, την βελτίωση συστημάτων και την προώθηση σύγχρονων πρακτικών ασφαλείας.

Boost Security είναι μια εταιρεία κυβερνοασφάλειας που επικεντρώνεται στην ασφάλεια της σύγχρονης αλυσίδας εφοδιασμού λογισμικού μέσω μιας πλατφόρμας DevSecOps που προορίζεται για τους développers. Η τεχνολογία της ενσωματώνεται απευθείας στις CI/CD πipelines για να ανιχνεύει, να προτεραιοποιεί και να επιλύει αυτόματα τις ευπαθής θέσεις, μειώνοντας το χειροκίνητο φόρτο εργασίας ενώ διατηρεί την ταχύτητα ανάπτυξης. Ενώνοντας την ασφάλεια εφαρμογών και αλυσίδας εφοδιασμού σε ένα ενιαίο σύστημα, η πλατφόρμα παρέχει πλήρη ορατότητα σε κώδικα, εξαρτήσεις και υποδομή, βοηθώντας τις οργανώσεις να ενισχύσουν την ανθεκτικότητα σε σύνθετα, cloud-φιλικά περιβάλλοντα.

Πρόσφατα οδηγήσατε την ασφάλεια εφαρμογών στο Trend Micro και συνίδρυσα την IMMUNIO. Τι σας οδήγησε να ιδρύσετε την Boost Security, και ποια κενή θέση στην αγορά ήτανε ιδιαίτερα τοποθετημένη για να αναγνωρίσετε νωρίς;

Η IMMUN.IO ήταν μια από τις πρώτες εταιρείες RASP που ιδρύθηκαν – και η εμπειρία μας μέχρι εκείνο το σημείο ήταν ότι οι WAF ως τεχνολογία ασφαλείας runtime ήταν αδύνατο να διατηρηθούν και δεν ήταν πολύ αποτελεσματικές. Οραματιζόμασταν einen τρόπο όπου οι WAF θα αντικατασταθούν με μια πιο ακριβή, πιο εύκολη στη διατήρηση λύση – ενstrumentοντας την εφαρμογή.

Αυτό ήταν το 2012, το DevOps ήταν ακόμη στην αρχή, οι περισσότερες ομάδες δεν ήταν Agile, και το Kubernetes δεν ήταν ακόμη μια πραγματικότητα.

Το Trend Micro απέκτησε την IMMUN.IO το 2017. Μέχρι εκείνη την ώρα, υπήρχαν πολλές περισσότερες πρακτικές DevOps: CI/CD πipelines, Agile μεθόδους ανάπτυξης, γρηγορότερες ιταλικές και κυκλικές κυκλοφορίες, cloud, κ.λπ. Οι ομάδες ανάπτυξης λογισμικού ήταν καλύτερες στο να κατασκευάζουν λογισμικό και να το αποστέλλουν γρηγορότερα. Η ασφάλεια ήταν ακόμη κατεστραμμένη, όμως:

• Οι σαρώσεις είναι πολύ αργές ή τα αποτελέσματα φτάνουν πολύ αργά
• Τα αποτελέσματα είναι πολύ σύνθετα για τους développers να τα ενεργοποιήσουν
• Υπάρχει γενικά μια μη αποδεκτή ποσοστό ψευδών θετικών
• Πολύ νέοι τύποι τεχνουργημάτων δεν σαρώνονται: κώδικας υποδομής, containers, APIs, για παράδειγμα

Η παραγωγή λογισμικού γρήγορα ήταν πιο εύκολη. Η παραγωγή ασφαλούς λογισμικού γρήγορα ήταν ακόμη δύσκολη.

Αυτό ήταν το αρχικό πρόβλημα που προσπαθήσαμε να λύσουμε. Να κάνουμε το DevSecOps να λειτουργεί στον πραγματικό κόσμο· μπορείτε να πάρει μια ομάδα ανάπτυξης λογισμικού να προσθέσει ασφάλεια στην SDLC, με ταχύτητα που να ταιριάζει με τα νέα πρότυπα ταχύτητας; Μπορείτε να κάνετε την κάλυψη ευρεία – όπου μια πλατφόρμα είναι όλο που χρειάζεστε; Μπορείτε να το κάνετε così ώστε οι développers, όχι μόνο να υιοθετήσουν την τεχνολογία, αλλά και να την αγκαλιάσουν και να δουν τα οφέλη; Μπορείτε να το κάνετε να κλιμακωθεί così ώστε να μην χρειάζεστε στρατούς επαγγελματιών ασφαλείας για να τηρήσετε το ποσό του κώδικα που γράφεται…

Βοήθησα τις εταιρείες να εντάξουν την ασφάλεια στην SDLC κατά την εποχή DevOps. Αυτό ήταν πηγαίνοντας από 1 σε 10. Τώρα βρισκόμαστε στην εποχή της κωδικοποίησης με πράκτορες – όπου οι πράκτορες γράφουν ένα τεράστιο ποσό κώδικα – αλλά είναι ουσιαστικά το ίδιο πρόβλημα – ταχύτητα και όγκος κώδικα πήγαν από 10 σε 100· και στοχεύουμε να συνεχίσουμε την ίδια πορεία.

Έχετε υποστηρίξει ότι ο κύκλος ζωής ανάπτυξης λογισμικού (SDLC) έχει μετατοπιστεί ουσιαστικά ροής. Ποια ήταν η στιγμή που συνειδητοποιήσατε ότι οι παραδοσιακές προσεγγίσεις DevSecOps δεν ήταν πλέον επαρκείς;

Ήταν το να παρακολουθήσετε πώς οι επιτιθέμενοι eigentlich εισέρχονται. Συνεχώς βλέπαμε το ίδιο μοτίβο: μια εκτεθειμένη ροή εργασιών GitHub που κανείς δεν είχε αναθεωρήσει από τότε που το αποθετήριο είχε forked, ένα token με πρόσβαση παραγωγής cloud ενσωματωμένο σε μια ρύθμιση config, μια έγκυρη εργασία CI που είχε καταληφθεί για να αναπτύξει φορτία επιτιθέμενου. Αυτά έγιναν γνωστά ως “ζωντανοί επιτιθέμενοι” επιθέσεις, επειδή ο αντίπαλος χρησιμοποιεί την αυτοματοποίηση σας εναντίον σας, με τα διαπιστευτήρια που η ομάδα ασφαλείας σας είχε ήδη εγκρίνει.

Το στάκ DevSecOps που είχαμε κατασκευάσει πάνω από μια δεκαετία δεν είχε απάντηση γι’ αυτό. Οι σαρώσεις SAST σαρώνουν τον πηγή εφαρμογής. Οι σαρώσεις SCA σαρώνουν τις εξαρτήσεις εφαρμογής. Και οι δύο υποθέτουν ότι η πipeline που τις τρέχει είναι αξιόπιστη. Εν τω μεταξύ, η πipeline herself είναι ένα αρχείο YAML με εντολές shell, πρόσβαση δικτύου και ευαίσθητα διαπιστευτήρια, και σχεδόν κανείς δεν την αναθεωρεί.

Όταν αυτό γίνεται ο δρόμος της ελάχιστης αντίστασης, μπορείτε να αποστείλετε καθαρό κώδικα και ακόμη να δώσετε στους επιτιθέμενους το cloud σας.

Πώς πρέπει οι επιχειρήσεις να ξανασκέφτουν τον SDLC σε ένα κόσμο όπου οι πράκτορες AI παράγουν κώδικα συνεχώς αντί να γράφουν οι développers βήμα προς βήμα;

Όλοι πρέπει να σταματήσουν να σκέφτονται τον SDLC ως μια σειρά ελέγχων. Οι πράκτορες AI έχουν συρρικνώσει το χρόνο μεταξύ “κάποιος έγραψε αυτό” και “αυτό είναι στην παραγωγή” από εβδομάδες σε λεπτά. Το παλιό μοντέλο υποθέτει einen ανθρώπινο ρυθμό μεταξύ κώδικα αναθεώρησης, SAST, SCA και ανάπτυξης, αλλά είμαστε πέρα από αυτό τώρα.

Η ασφάλεια πρέπει να ζήσει όπου ο πράκτορας λειτουργεί: στο μηχάνημα του développer, μέσα στο контекστ του prompt, στις συνδέσεις του πράκτορα με τους servers MCP και εξωτερικούς μοντέλους. Μέχρι τη στιγμή που ο κώδικας φτάσει στην πipeline, έχετε ήδη χάσει την ευκαιρία να το διαμορφώσετε. Ο πράκτορας έχει ήδη τραβήξει την εξάρτηση. Το μοντέλο έχει ήδη δει το διαπιστευτήριο. Μεταφέρετε τους ελέγχους ροής, όπου πραγματικά συμβαίνει η δουλειά.

Πολυάριθμες οργανώσεις ακόμη αντιμετωπίζουν τα εργαλεία κωδικοποίησης AI ως απλές στρώσεις παραγωγικότητας. Γιατί πιστεύετε ότι αντιπροσωπεύουν μια εντελώς νέα επιφάνεια επίθεσης αντί για μια απλή επέκταση των υφιστάμενων ροών εργασιών;

Η αντιμετώπιση eines εργαλείου κωδικοποίησης AI ως στρώματος παραγωγικότητας είναι σαν να αντιμετωπίζετε έναν νεαρό développer με πρόσβαση root ως στρώμα παραγωγικότητας. Η ετικέτα είναι τεχνικά ακριβής, αλλά δεν σας δίνει κανένα χρήσιμο πλαίσιο για να σκεφτείτε τι μπορεί να πάει λάθος.

Ένας πράκτορας κωδικοποίησης διαβάζει το σύστημα αρχείων σας, σκουπίζει τις μεταβλητές περιβάλλοντος για контекστ, ανακτά εξαρτήσεις από δημόσιους καταλόγους, ανοίγει εξερχόμενες συνδέσεις σε προμηθευτές μοντέλων και servers MCP, και εκτελεί εντολές shell. Κάθε μία από αυτές τις ενέργειες χρησιμοποιούσε να απαιτεί έναν άνθρωπο στο βρόχο. Τώρα συμβαίνουν σε χιλιοστά του δευτερολέπτου, με τα ίδια προνόμια που είχε ο développer που εκκίνησε τον πράκτορα.

Αυτή η συρρίκνωση συνδυάζει τα όρια εμπιστοσύνης που ήταν ξεχωριστά: την εξουσία του développer, τι μπορεί να ανακαλέσει ένα εξωτερικό εργαλείο, και τι μπορεί να εκτελέσει ο αξιόπιστος κώδικας. Αυτό δημιουργεί νέες ευκαιρίες για επιτιθέμενους και τυφλά σημεία που οι υπερασπιστές δεν μπορούν ούτε να δουν, πολύ λιγότερο να υπερασπιστούν.

Η Boost περιγράφει το laptop του développer ως το νέο επίπεδο ελέγχου. Ποια рисκ υπάρχουν στο τελικό σημείο που οι ομάδες ασφαλείας目前 παραβλέπουν;

Το μεγαλύτερο είναι το инвεντάρ. Οι περισσότερες ομάδες ασφαλείας δεν μπορούν να σας πουν ποιοι πράκτορες AI τρέχουν σε ποια laptop, ποιοι servers MCP αυτοί οι πράκτορες συνδέονται, ή ποίες επεκτάσεις IDE σαρώνουν περιεχόμενο αποθετηρίου αυτή τη στιγμή. Το EDR δεν έχει ορατότητα στο επίπεδο πράκτορα· το SIEM δεν μπορεί να δει τι κάνουν αυτοί οι πράκτορες τοπικά. Είναι ένα πρόβλημα σκιώδους IT με προνόμια εκτέλεσης κώδικα.

Κάτω από αυτό βρίσκεται το χάος διαπιστευτηρίων. Κατασκευάσαμε ένα ανοικτό εργαλείο που ονομάζεται Bagel частично για να κάνουμε αυτό συγκεκριμένο. Ένα τυπικό laptop développer διαθέτει tokens GitHub με πρόσβαση γραφής σε παραγωγικά αποθετήρια, διαπιστευτήρια cloud που μπορούν να αναπτύξουν υποδομή, tokens npm ή PyPI που μπορούν να δημοσιεύσουν σε εκατομμύρια χρήστες, και κλειδιά υπηρεσιών AI που οι επιτιθέμενοι ξαναπωλούν. Κανένα από αυτά δεν είναι σκληρό όπως ένας runner CI. Η ίδια μηχανή που διαθέτει αυτά τα διαπιστευτήρια επίσης περιηγείται στο web και εγκαθιστά τυχαίες επεκτάσεις VS Code.

Ζευγαρώστε τα δύο και έχετε την πραγματική επιφάνεια επίθεσης. Μια μη αξιόπιστη επέκταση που τρέχει με προνόμια développer σε ένα περιβάλλον γεμάτο κλειδιά cloud είναι ο υψηλότερος-κερδισμένος στόχος στην σύγχρονη επιχείρηση. Οι περισσότερες ομάδες δεν έχουν αρχίσει να το εξετάζουν.

Έχετε υπογραμμίσει την “παγίδα контекστ”, όπου οι πράκτορες AI μπορούν να προσεγγίσουν τοπικά αρχεία, μεταβλητές περιβάλλοντος και ρυθμίσεις. Πόσο διαδεδομένο είναι το ρίσκο διαρροής ευαίσθητων δεδομένων μέσω prompts, και γιατί είναι τόσο δύσκολο να ανιχνευθεί;

Διαδεδομένο αρκετά ώστε να το αντιμετωπίζουμε ως την προεπιλεγμένη κατάσταση οποιουδήποτε μη διαχειριζόμενου περιβάλλοντος développer. Κάθε πράκτορας κωδικοποίησης που έχουμε ελέγξει τραβά контекστ αγрессίβως. Διαβάζουν αρχεία dot, μεταβλητές περιβάλλοντος, πρόσφατα αρχεία, μερικές φορές ολόκληρες δέντρα καταλόγων, και αποστέλλουν αυτόν τον контекστ σε ένα απομακρυσμένο μοντέλο. Τα εργαλεία είναι σχεδιασμένα να λειτουργούν με αυτόν τον τρόπο· η αγрессίβη ανάκτηση контекστ είναι αυτό που τα κάνει χρήσιμα.

Το πρόβλημα ανίχνευσης αρχίζει επειδή η κυκλοφορία από μια διαρροή φαίνεται идентична με την κανονική χρήση προϊόντος. Είναι TLS στο api.openai.com ή api.anthropic.com. Προέρχεται από μια εγκεκριμένη εφαρμογή επιχείρησης. Το τυπικό DLP βλέπει έναν développer που χρησιμοποιεί το εργαλείο AI που η εταιρεία μόλις αγόρασε μια άδεια. Δεν βλέπει ότι μια από τις συμβολοσειρές σε αυτήν την πρόκληση είναι ένα κλειδί AWS που ο πράκτορας έπιασε από ένα ξεχασμένο αρχείο .env σε ένα αδελφικό κατάλογο.

Την πιάνετε μόνο ελέγχοντας τις προκλήσεις πριν φύγουν από το laptop, που είναι ακριβώς όπου σχεδόν κανένα στάκ ασφαλείας δεν είναι τώρα τοποθετημένο.

Μπορείτε να μας οδηγήσετε μέσα από ένα ρεαλιστικό σενάριο όπου ένας πράκτορας AI εισάγει μια ευπάθεια γρηγορότερα από ότι τα παραδοσιακά εργαλεία ασφαλείας μπορούν να την αναγνωρίσουν;

Εδώ είναι ένα που έχουμε δει πολλές παραλλαγές. Ο développer ζητά από τον πράκτορα να προσθέσει μια λειτουργία που χρειάζεται μια βιβλιοθήκη επανάληψης HTTP. Ο πράκτορας προτείνει ένα όνομα πακέτου. Το πακέτο είναι πιθανό να ακούγεται αλλά δεν υπάρχει στην npm. Μέσα σε μια ώρα, ένας επιτιθέμενος καταχωρεί το όνομα, το γεμίζει με λειτουργική λογική επανάληψης плюς ένα μικρό σενάριο post-εγκατάστασης που διαβάζει το ~/.aws/credentials και τα αποστέλλει σε ένα webhook. Ο πράκτορας τρέχει την εγκατάσταση npm χωρίς να ελέγξει, επειδή οι πράκτορες δεν ελέγχουν τη φήμη. Το διαπιστευτήριο έχει πάρει πριν ο développer ακόμη τρέξει τον κώδικα.

Η επίθεση herself δεν είναι τεχνικά περίπλοκη, αλλά η παραδοσιακή ασφάλεια αλυσίδας εφοδιασμού είναι χτισμένη γύρω από γνωστές ευπαθίες σε γνωστά πακέτα: CVEs, SBOMs, σάρωση αδειών. Αυτό το πλαίσιο δεν έχει τίποτα να πει για ένα πακέτο που δεν υπήρχε όταν η σάρωση έτρεξε τελευταία φορά, δημιουργήθηκε ειδικά για να ταιριάζει σε μια αλλοίωση AI, και εισάγεται πριν από οποιαδήποτε ενημέρωση feed απειλής.

Το παράθυρο από δημοσίευση σε συμβιβασμό μετράται τώρα σε λεπτά. Οτιδήποτε ελέγχει μετά είναι ελέγχει πολύ αργά.

Γίνονται οι αλλοιωμένοι εξαρτήσεις μια από τις μεγαλύτερες απειλές στην ανάπτυξη με AI, και ποια είναι τα πρακτικά βήματα που μπορούν να λάβουν οι οργανώσεις για να υπερασπιστούν εναντίον τους;

Έχουν ήδη γίνει. Οι επιτιθέμενοι παρακολουθούν ενεργά τα δημοφιλή εργαλεία AI για αλλοιώσεις και καταχωρούν τα προτεινόμενα ονόματα πακέτων μέσα σε λεπτά. Ερευνητές πριν από quelques χρόνια, όταν αυτό ξεκίνησε, το ονόμασαν slopsquatting και το όνομα έμεινε. Μόλις το όνομα εξάρτησης αλλοιωθεί αρκετά συχνά, να κάτσετε πάνω σε αυτό είναι μια παθητική επίθεση αλυσίδας εφοδιασμού με σχεδόν μηδενικό κόπο.

Τα πρακτικά αμυντικά μέτρα φαίνονται διαφορετικά από αυτά που έχουν οι περισσότερες ομάδες τώρα. Ξεκινήστε στην πρόσληψη. Μπλοκάρετε τα τυποποιημένα και νεοκαταχωρημένα πακέτα στο σημείο που τρέχει η εγκατάσταση npm ή pip, στο μηχάνημα του développer, πριν από οτιδήποτε χτυπήσει το δίσκο. Η ανίχνευση μετά θάνατον στην CI δεν βοηθά όταν ένα σενάριο post-εγκατάστασης έχει ήδη εξαπατήσει ένα διαπιστευτήριο. Τότε δώστε στον πράκτορα φράχτες για να λειτουργήσει μέσα. Εισαγάγετε τη λίστα σας με εγκεκριμένες εξαρτήσεις απευθείας στο контекστ του πράκτορα, ώστε το μοντέλο να δει τι είναι επιτρεπτό πριν γεννήσει μια πρόταση. Ζητώντας από τους développers να γράφουν “ασφαλείς προκλήσεις” δεν είναι μια στρατηγική. Αν είστε στρατηγικοί, αυτό σημαίνει ότι η ασφάλεια ορίζει τα όρια, ο πράκτορας τα κληρονομεί. Και ξεκινήστε να καταγράφετε ένα AI Bill of Materials. Οι περισσότερες ομάδες δεν μπορούν να σας πουν ποιοι πράκτορες, μοντέλα και πακέτα αγγίζουν ποια αποθετήρια. Δεν μπορείτε να υπερασπιστείτε αυτό που δεν μπορείτε να καταλογογραφήσετε.

Έχετε πει ότι η ασφάλεια δεν μπορεί πλέον να αρχίσει στο CI/CD. Τι μοιάζει μια σύγχρονη πipeline ασφαλείας όταν η προστασία πρέπει να αρχίσει νωρίτερα στη διαδικασία ανάπτυξης;

Αν η ασφάλεια αρχίσει στο CI/CD, έχετε παραδώσει ολόκληρη τη φάση πριν από την υποβολή σε ένα περιβάλλον που δεν ελέγχετε. Ο πράκτορας έχει ήδη πάρει τον контекστ, το διαπιστευτήριό σας μπορεί ήδη να είναι σε κάποιον άλλον’s logs. Εσείς σαρώνετε ένα πτώμα.

Μια σύγχρονη πipeline αρχίζει στο laptop. Αυτό σημαίνει να καταλογογραφείτε τους πράκτορες και τις επεκτάσεις που τρέχουν εκεί, να επικυρώνετε ποιοι servers MCP και μοντέλα είναι επιτρεπτά να μιλήσουν, να σαφηνίζετε τι φεύγει από τη μηχανή, και να μπλοκάρετε κακόβουλα πακέτα πριν εγκατασταθούν. Από εκεί, η πολιτική ακολουθεί το έργο στο IDE. Εισαγάγετε τις προδιαγραφές ασφαλείας απευθείας στο παράθυρο контекστ του πράκτορα, ώστε ο γεννημένος κώδικας να παραμείνει μέσα στα φράχτες από την πρώτη στιγμή. Η πipeline herself δεν εξαφανίζεται. Ο ρόλος της γίνεται επαλήθευση: επιβεβαιώνοντας ότι οι ελέγχοι ροής που είχαν εφαρμοστεί.

Η πipeline herself δεν εξαφανίζεται. Ο ρόλος της γίνεται επαλήθευση: επιβεβαιώνοντας ότι οι ελέγχοι ροής που είχαν εφαρμοστεί.

Καθώς οι οργανώσεις συνεχίζουν να υιοθετούν πράκτορες κωδικοποίησης AI, ποια είναι τα πιο κρίσιμα βήματα που πρέπει να κάνουν σήμερα για να διασφαλίσουν ότι τα περιβάλλοντα ανάπτυξής τους παραμένουν ασφαλή τα επόμενα χρόνια;

Το μεγαλύτερο λάθος είναι να ασφαλίζετε μόνο αυτό που υποβάλλεται. Το ενδιαφέρον ρίσκο ζει στις οκτώ ώρες πριν από μια υποβολή. Μπορεί να συμβεί δράμα στο laptop, στην πρόκληση, ή στην εγκατάσταση πακέτου. Αν τα εργαλεία σας αρχίζουν από το PR, προστατεύετε το λάθος μισό της ροής.

Στενά συνδεδεμένο: να σταματήσετε να αντιμετωπίζετε τους πράκτορες κωδικοποίησης ως λογισμικό παραγωγικότητας. Είναι μη-ανθρώπινες οντότητες με πρόσβαση shell, δικαιώματα γραφής αποθετηρίου, και εξερχόμενες συνδέσεις δικτύου. Διαχειριζόμαστε τους με τον ίδιο τρόπο που διαχειριζόμαστε οποιαδήποτε άλλη ταυτότητα με προνόμια, με ένα инвентарь, εγκεκριμένες ικανότητες, και αρχείο καταγραφής.

Η τελευταία μετατόπιση είναι πιο δύσκολο πολιτιστικά. Τα meisten τρέχοντα “εργαλεία ασφαλείας AI” επιφέρουν ευρήματα και τα στέλνουν σε ανθρώπους. Οι άνθρωποι δεν μπορούν να τριγωνίσουν με την ταχύτητα που παράγουν οι πράκτορες. Οτιδήποτε υιοθετείτε πρέπει να λύσει τα προβλήματα αυτόματα μέσα στη ροή, με ιχνηλασιμό λόγω, ή γίνεται άλλο πίνακας που κανείς δεν διαβάζει.

Ευχαριστούμε για τη μεγάλη συνέντευξη, οι αναγνώστες που επιθυμούν να μάθουν περισσότερα πρέπει να επισκεφθούν Boost Security.