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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Η ασφάλεια πρέπει να βρίσκεται εκεί όπου λειτουργεί ο πράκτορας: στον υπολογιστή του προγραμματιστή, μέσα στο πλαίσιο της προτροπής και στις συνδέσεις του πράκτορα με διακομιστές MCP και εξωτερικά μοντέλα. Όταν ο κώδικας φτάσει στη διοχέτευση, η ευκαιρία να τον διαμορφώσετε έχει ήδη χαθεί. Ο πράκτορας έχει ήδη αντλήσει την εξάρτηση και το μοντέλο έχει ήδη δει το διαπιστευτήριο. Μετακινήστε τους ελέγχους νωρίτερα, εκεί όπου πραγματοποιείται πραγματικά η εργασία.Η ασφάλεια πρέπει να ζει όπου ο πράκτορας λειτουργεί: στο μηχάνημα του προγραμματιστή, μέσα στο πλαίσιο της πρότασης, στις συνδέσεις του πράκτορα με τους servers MCP και εξωτερικούς μοντέλους. Μέχρι την στιγμή που ο κώδικας φτάσει στην πιπελίνα, έχετε ήδη χάσει την ευκαιρία να το διαμορφώσετε. Ο πράκτορας đã bereits pulled την εξάρτηση. Το μοντέλο đã saw την πιστοποίηση. Μετακινήστε τους ελέγχους ροής, όπου πραγματικά γίνεται η δουλειά.

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

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

Ένας πράκτορας κωδικοποίησης διαβάζει το filesystem σας, σκουπίζει environment variables για πλαίσιο, fetches εξαρτήσεις από δημόσιους καταλόγους, ανοίγει εξωτερικές συνδέσεις με προμηθευτές μοντέλων και servers MCP, και εκτελεί εντολές shell. Κάθε μια από αυτές τις ενέργειες χρειαζόταν έναν άνθρωπο στο βρόχο. Τώρα συμβαίνουν σε χιλιοστά του δευτερολέπτου, με τις ίδιες προϋποθέσεις όπως ο προγραμματιστή που ξεκίνησε τον πράκτορα.

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

Η Boost περιγράφει το laptop του προγραμματιστή ως το νέο επίπεδο ελέγχου. Ποια κίνδυνοι υπάρχουν στο τελικό σημείο που οι ομάδες ασφαλείας παραβλέπουν τώρα;

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

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

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

Είστε ομιλητής για την “παράδοση του πλαίσιο”, όπου οι πράκτορες AI μπορούν να έχουν πρόσβαση σε τοπικά αρχεία, environment variables και ρυθμίσεις. Πόσο διαδεδομένο είναι το ρίσκο της διαρροής ευαίσθητων δεδομένων μέσω των προτάσεων, και γιατί είναι τόσο δύσκολο να ανιχνευθεί;

Διαδεδομένο αρκετό ώστε να το αντιμετωπίζουμε ως την προεπιλεγμένη κατάσταση οποιουδήποτε μη διαχειριζόμενου περιβάλλοντος προγραμματιστή. Κάθε πράκτορας κωδικοποίησης που έχουμε ελέγξει τραβά τοπικό πλαίσιο επιθετικά. Διαβάζουν dotfiles, environment variables, πρόσφατα αρχεία, μερικές φορές ολόκληρες δέντρα καταλόγων, και στέλνουν αυτόν τον πλαίσιο σε ένα απομακρυσμένο μοντέλο. Τα εργαλεία είναι σχεδιασμένα να λειτουργούν με αυτόν τον τρόπο. Η επιθετική λήψη του πλαίσιο είναι αυτό που τα κάνει χρήσιμα.

Το πρόβλημα ανίχνευσης αρχίζει επειδή η κυκλοφορία από μια διαρροή φαίνεται identικά με την κανονική χρήση του προϊόντος. Είναι TLS στο api.openai.com ή api.anthropic.com. Έρχεται από μια εγκεκριμένη επιχειρηματική εφαρμογή. Το τυπικό DLP βλέπει έναν προγραμματιστή που χρησιμοποιεί το εργαλείο AI που η εταιρεία αγόρασε πρόσφατα. Δεν βλέπει ότι μια από τις συμβολοσειρές σε αυτήν την πρόταση είναι ένα κλειδί AWS που ο πράκτορας έπιασε από ένα half-ξεχασμένο .env αρχείο σε ένα αδελφικό κατάλογο.

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

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

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

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

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

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

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

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

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

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

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

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

Τι είναι τα πιο κρίσιμα βήματα που πρέπει να κάνουν οι οργανισμοί σήμερα για να διασφαλίσουν ότι τα περιβάλλοντα ανάπτυξής τους παραμένουν ασφαλή τα επόμενα χρόνια;

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

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

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

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