Διακυβέρνηση ασφάλειας αγωγών CI/CD για ελέγχους του 2026
Είναι 08:17 ένα πρωινό Δευτέρας και ο CISO μιας αναπτυσσόμενης fintech λαμβάνει το μήνυμα που φοβάται κάθε επικεφαλής ασφάλειας:
«Το production build φαίνεται καθαρό, αλλά το hash του τεχνουργήματος δεν αντιστοιχεί στο commit προέλευσης.»
Μέσα σε λίγα λεπτά, η ομάδα μηχανικής επιβεβαιώνει ότι η έκδοση πέρασε τις δοκιμές μονάδας, το δελτίο διάθεσης σε παραγωγή υπάρχει και η υπηρεσία που βλέπουν οι πελάτες είναι σταθερή. Όμως ο αγωγός δείχνει διαφορετική εικόνα. Ένας αυτοφιλοξενούμενος CI runner επαναχρησιμοποιήθηκε σε διαφορετικά έργα. Ένα προσωρινό διαπιστευτήριο νέφους παρέμεινε ενεργό περισσότερο από όσο προβλεπόταν. Το μητρώο τεχνουργημάτων εμφανίζει μια υπογεγραμμένη εικόνα container, αλλά το κλειδί υπογραφής ήταν προσβάσιμο από τον ίδιο runner που εκτέλεσε μη έμπιστα build scripts.
Ο υπεύθυνος έκδοσης μπορεί να αποδείξει ότι κάτι διατέθηκε στην παραγωγή. Αυτό που ο οργανισμός δεν μπορεί να αποδείξει, τουλάχιστον όχι αρκετά γρήγορα, είναι τι δημιουργήθηκε, ποιος το ενέκρινε, αν το περιβάλλον build ήταν καθαρό και αν τα τεκμήρια θα άντεχαν σε έλεγχο ή σε διερεύνηση περιστατικού.
Αυτό δεν είναι πλέον μόνο πρόβλημα DevOps.
Το 2026, η διακυβέρνηση ασφάλειας αγωγών CI/CD βρίσκεται στη διασταύρωση της ασφάλειας εφοδιαστικής αλυσίδας λογισμικού, της επιχειρησιακής ανθεκτικότητας, της λογοδοσίας για την ιδιωτικότητα, της ασφάλειας προϊόντος και της εποπτείας κυβερνοκινδύνου σε επίπεδο διοικητικού συμβουλίου. Το NIS2 ωθεί τα όργανα διοίκησης να εγκρίνουν και να εποπτεύουν μέτρα διαχείρισης κινδύνων κυβερνοασφάλειας. Το DORA απαιτεί από τις χρηματοοικονομικές οντότητες να διαχειρίζονται κινδύνους ΤΠΕ, περιστατικά, δοκιμές και εξαρτήσεις από τρίτα μέρη. Το GDPR απαιτεί από τους υπευθύνους επεξεργασίας και τους εκτελούντες την επεξεργασία να αποδεικνύουν κατάλληλη ασφάλεια και λογοδοσία για δεδομένα προσωπικού χαρακτήρα. Η Πράξη για την Κυβερνοανθεκτικότητα αυξάνει τις προσδοκίες της αγοράς για ασφαλή προϊόντα με ψηφιακά στοιχεία, ασφαλείς ενημερώσεις και χειρισμό ευπαθειών. Το ISO/IEC 27001:2022 απαιτεί ένα ISMS που μετατρέπει την αντιμετώπιση κινδύνων σε ελεγχόμενες λειτουργίες με τεκμήρια.
Ο αγωγός έχει γίνει η διαδρομή ελέγχου της σύγχρονης εμπιστοσύνης στο λογισμικό.
Το νέο ερώτημα συμμόρφωσης: μπορείτε να αποδείξετε τι έφτασε στην παραγωγή;
Για χρόνια, τα προγράμματα DevSecOps εστίαζαν στην προσθήκη σαρωτών στους αγωγούς. Η στατική ανάλυση, οι έλεγχοι εξαρτήσεων, η σάρωση μυστικών, η σάρωση container και η επικύρωση infrastructure-as-code έγιναν συνήθεις πρακτικές. Αυτοί οι έλεγχοι εξακολουθούν να έχουν σημασία, αλλά δεν απαντούν στο ερώτημα διακυβέρνησης που θέτουν πλέον ελεγκτές, ρυθμιστικές αρχές, πελάτες και διοικητικά συμβούλια:
Μπορεί ο οργανισμός να αποδείξει ότι κάθε διάθεση σε παραγωγή προήλθε από εγκεκριμένο πηγαίο κώδικα, δημιουργήθηκε σε ελεγχόμενο περιβάλλον, παρήγαγε επαληθεύσιμο τεχνούργημα, πέρασε τις απαιτούμενες πύλες ασφάλειας, χρησιμοποίησε εγκεκριμένα διαπιστευτήρια, ακολούθησε διαχείριση αλλαγών και δημιούργησε τεκμήρια που μπορούν να διατηρηθούν;
Οι επιτιθέμενοι γνωρίζουν ότι τα συστήματα build, οι εξαρτήσεις πακέτων, τα διακριτικά προγραμματιστών, οι CI runners, η αυτοματοποίηση εκδόσεων, τα μητρώα τεχνουργημάτων και οι ρόλοι διάθεσης σε περιβάλλον νέφους είναι στόχοι υψηλής αξίας. Ένας παραβιασμένος αγωγός μπορεί να παρακάμψει τις παραδοσιακές άμυνες, επειδή χρησιμοποιεί έμπιστη αυτοματοποίηση για να προωθήσει κακόβουλο κώδικα σε έμπιστα περιβάλλοντα.
Ένα ώριμο μοντέλο διακυβέρνησης ασφάλειας αγωγών CI/CD χρειάζεται, συνεπώς, έξι πυλώνες τεκμηρίων.
| Πυλώνας τεκμηρίων | Τι αποδεικνύει | Συνήθη τεκμήρια |
|---|---|---|
| Ακεραιότητα πηγαίου κώδικα | Το τεχνούργημα που διατέθηκε στην παραγωγή προήλθε από εγκεκριμένο πηγαίο κώδικα | Commit ID, προστασία κλάδων, εγκρίσεις pull request, υπογεγραμμένα commits, αρχεία καταγραφής ελέγχου αποθετηρίου |
| Προέλευση build | Το τεχνούργημα παρήχθη από γνωστό αγωγό υπό ελεγχόμενες συνθήκες | Build ID, ταυτότητα runner, συνταγή build, manifest εξαρτήσεων, hash τεχνουργήματος, αρχείο υπογραφής |
| Σκλήρυνση runner | Το περιβάλλον εκτέλεσης δεν μπορούσε εύκολα να επαναχρησιμοποιηθεί ή να παραποιηθεί | Αρχεία καταγραφής ephemeral runner, εικόνα βασικής γραμμής, κατάσταση εφαρμογής διορθώσεων, έλεγχοι απομόνωσης, περιορισμοί δικτύου |
| Ακεραιότητα τεχνουργήματος | Το πακέτο έκδοσης δεν τροποποιήθηκε μετά το build | Υπογραφή, άθροισμα ελέγχου, αρχείο καταγραφής μητρώου, αρχείο προώθησης, πολιτική αμετάβλητων tags |
| Διακυβέρνηση διάθεσης σε παραγωγή | Η αλλαγή ήταν εξουσιοδοτημένη, δοκιμασμένη και ιχνηλάσιμη | Change request ID, τεκμήρια έγκρισης, αρχεία καταγραφής προώθησης μεταξύ περιβαλλόντων, σχέδιο επαναφοράς |
| Ετοιμότητα ψηφιακής διερεύνησης | Τα τεκμήρια μπορούν να διατηρηθούν κατά τον έλεγχο ή την απόκριση σε περιστατικά | Εξαγόμενα αρχεία καταγραφής, στιγμιότυπα οθόνης, hashes αρχείων, αρχείο αλυσίδας επιμέλειας |
Εδώ διαφοροποιείται η προσέγγιση του Clarysec από τη συμμόρφωση βάσει checklist. Αντιμετωπίζουμε την πλατφόρμα CI/CD ως διακυβερνώμενη επιχειρησιακή διαδικασία, όχι μόνο ως τεχνικό εργαλείο. Η διαδικασία αυτή πρέπει να εντάσσεται στο πεδίο εφαρμογής του ISMS, να αξιολογείται ως προς τον κίνδυνο, να ελέγχεται, να παρακολουθείται, να υπόκειται σε έλεγχο και να βελτιώνεται.
Εντάξτε το CI/CD στο ISO/IEC 27001:2022 ISMS
Το ISO/IEC 27001:2022 ξεκινά με το πλαίσιο, τα ενδιαφερόμενα μέρη και το πεδίο εφαρμογής. Οι ρήτρες 4.1 έως 4.4 απαιτούν από τους οργανισμούς να κατανοούν τα εσωτερικά και εξωτερικά ζητήματα, να καθορίζουν τις απαιτήσεις των ενδιαφερόμενων μερών, να εντοπίζουν νομικές, κανονιστικές και συμβατικές απαιτήσεις και να ορίζουν το πεδίο εφαρμογής του ISMS, λαμβάνοντας υπόψη εξαρτήσεις από άλλους οργανισμούς.
Για έναν πάροχο SaaS, μια fintech, έναν πάροχο διαχειριζόμενων υπηρεσιών (MSP), έναν προμηθευτή λογισμικού ή μια επιχείρηση σχεδιασμένη για περιβάλλον νέφους, το CI/CD βρίσκεται σχεδόν πάντα μέσα σε αυτό το πεδίο εφαρμογής, επειδή επηρεάζει άμεσα την παράδοση υπηρεσιών, τα δεδομένα πελατών, την υποδομή παραγωγής και τις συμβατικές δεσμεύσεις.
Οι ρήτρες 5.1 έως 5.3 καθιστούν την ηγεσία υπεύθυνη για το ISMS. Αυτό έχει σημασία επειδή η σύγχρονη αυτοματοποίηση εκδόσεων βρίσκεται ανάμεσα στη μηχανική ομάδα, την ασφάλεια, τις λειτουργίες νέφους, τις προμήθειες, τη συμμόρφωση και τη διαχείριση προϊόντος. Αν κανένα στέλεχος δεν έχει την κυριότητα της διάθεσης ανάληψης κινδύνου για την αυτοματοποίηση διαθέσεων σε παραγωγή, ο οργανισμός συνήθως καταλήγει με κατακερματισμένα εργαλεία και ασυνεπή τεκμήρια.
Οι ρήτρες 6.1.1 έως 6.1.3 παρέχουν τη ραχοκοκαλιά του σχεδιασμού. Ο οργανισμός πρέπει να αξιολογεί τους κινδύνους για την εμπιστευτικότητα, την ακεραιότητα και τη διαθεσιμότητα, να εντοπίζει υπευθύνους κινδύνου, να συγκρίνει τους κινδύνους με τα κριτήρια, να επιλέγει τρόπους αντιμετώπισης, να συγκρίνει τους επιλεγμένους ελέγχους με το Annex A, να παράγει Δήλωση Εφαρμοσιμότητας και να λαμβάνει έγκριση για το σχέδιο αντιμετώπισης και τον υπολειπόμενο κίνδυνο.
Μια αξιολόγηση κινδύνου CI/CD δεν πρέπει απλώς να αναφέρει «κίνδυνος εφοδιαστικής αλυσίδας λογισμικού». Πρέπει να κατονομάζει ρεαλιστικά σενάρια:
- Ένα κακόβουλο build script εξάγει κλειδιά υπογραφής από κοινόχρηστο runner.
- Ένας προγραμματιστής παρακάμπτει την προστασία κλάδων και διαθέτει σε παραγωγή μη ανασκοπημένο κώδικα.
- Μια παραβιασμένη ενέργεια τρίτου μέρους τροποποιεί ένα τεχνούργημα κατά το build.
- Ένα διαπιστευτήριο staging παρέχει πρόσβαση σε περιβάλλον παραγωγής.
- Πραγματοποιείται διάθεση σε παραγωγή χωρίς συνδεδεμένο αίτημα αλλαγής.
- Τα αρχεία καταγραφής αγωγού που απαιτούνται για την ανακατασκευή περιστατικού αντικαθίστανται μετά από επτά ημέρες.
- Περιστατικό δηλητηρίασης εξάρτησης φτάνει σε προπαραγωγή ή παραγωγή.
Στη συνέχεια, η ρήτρα 8.1 απαιτεί σχεδιασμένη και ελεγχόμενη λειτουργία των διεργασιών του ISMS, τεκμηριωμένα τεκμήρια, έλεγχο προγραμματισμένων αλλαγών, ανασκόπηση ακούσιων αλλαγών και έλεγχο εξωτερικά παρεχόμενων διεργασιών, προϊόντων ή υπηρεσιών που σχετίζονται με το ISMS. Αν ο αγωγός αλλάζει την παραγωγή, πρέπει να παράγει τεκμήρια ελεγχόμενης λειτουργίας.
Το μοντέλο ελέγχων Clarysec για ασφαλή παράδοση λογισμικού
Το Clarysec συνδέει πολιτικές, ελέγχους και ελεγκτικά τεκμήρια. Το Zenith Blueprint: Οδικός χάρτης 30 βημάτων για ελεγκτές Zenith Blueprint τοποθετεί το ασφαλές DevOps και την ασφαλή ανάπτυξη στη φάση διαχείρισης κινδύνων, Βήμα 14. Αναφέρει ότι οι οργανισμοί πρέπει να ασφαλίζουν τα εργαλεία CI/CD, να διασφαλίζουν ότι μόνο εξουσιοδοτημένο προσωπικό μπορεί να ενεργοποιεί διαθέσεις σε παραγωγή, να χρησιμοποιούν MFA για πρόσβαση στον αγωγό, να προστατεύουν την ακεραιότητα των build artifacts και να καταγράφουν και να παρακολουθούν ενέργειες CI/CD.
«Έλεγχοι αγωγού DevOps: Τα εργαλεία CI/CD πρέπει να ασφαλίζονται – μόνο εξουσιοδοτημένο προσωπικό μπορεί να ενεργοποιεί διαθέσεις σε παραγωγή· χρησιμοποιήστε MFA για πρόσβαση στον αγωγό· προστατεύστε την ακεραιότητα των build artifacts. Καταγράφετε και παρακολουθείτε τις ενέργειες CI/CD.»
Η καθοδήγηση αυτή γίνεται εφαρμόσιμη όταν μετατρέπεται σε ρήτρες πολιτικής και απαιτήσεις τεκμηρίων.
Η P24 Πολιτική Ασφαλούς Ανάπτυξης Πολιτική Ασφαλούς Ανάπτυξης αναφέρει:
«Τα build artifacts πρέπει να υπογράφονται και να είναι ιχνηλάσιμα προς τα commits προέλευσης.»
Αυτός είναι ένας από τους ισχυρότερους ελέγχους σε ένα πρόγραμμα διακυβέρνησης CI/CD. Καθορίζει στη μηχανική ομάδα ότι ένα τεχνούργημα παραγωγής πρέπει να διαθέτει επαληθεύσιμη γραμμή προέλευσης πίσω στον έλεγχο εκδόσεων πηγαίου κώδικα. Καθορίζει επίσης στους ελεγκτές τι πρέπει να δοκιμάσουν: να επιλέξουν μια έκδοση παραγωγής, να επιθεωρήσουν την υπογραφή του τεχνουργήματος, να επικυρώσουν την αναφορά commit, να ανασκοπήσουν την έγκριση pull request και να επιβεβαιώσουν το αρχείο build του αγωγού.
Η ίδια πολιτική αναφέρει:
«Όλες οι δραστηριότητες ανάπτυξης πρέπει να παρακολουθούνται μέσω εγκεκριμένων συστημάτων ελέγχου εκδόσεων με επιβεβλημένους ελέγχους πρόσβασης, ίχνη ελέγχου και προστασίες κλάδων.»
Αυτό μεταφέρει τη διακυβέρνηση προς τα ανάντη. Αν τα αποθετήρια πηγαίου κώδικα δεν προστατεύονται, η προέλευση build είναι αδύναμη. Αν οι προστασίες κλάδων μπορούν να παρακαμφθούν, ο αγωγός μπορεί να δημιουργήσει πιστά μη εγκεκριμένο κώδικα. Αν τα ίχνη ελέγχου είναι απενεργοποιημένα, η ανακατασκευή περιστατικού βασίζεται στη μνήμη και σε στιγμιότυπα οθόνης αντί σε τεκμήρια.
Για μικρότερους οργανισμούς, η Πολιτική Ασφαλούς Ανάπτυξης για ΜΜΕ Πολιτική Ασφαλούς Ανάπτυξης για ΜΜΕ περιλαμβάνει μια πρακτική ελάχιστη απαίτηση:
«Παρακολούθηση της έκδοσης κώδικα, της ημερομηνίας διάθεσης σε παραγωγή και του εγκρίνοντος»
Αυτό το απλό μητρώο διαθέσεων σε παραγωγή αποτελεί ισχυρό σημείο εκκίνησης. Πολλές μικρομεσαίες επιχειρήσεις δεν χρειάζονται βαριά διακυβέρνηση εκδόσεων από την πρώτη ημέρα, αλλά χρειάζεται να γνωρίζουν ποια έκδοση τέθηκε σε λειτουργία, πότε και ποιος την ενέκρινε.
Η πολιτική για ΜΜΕ αναφέρει επίσης:
«Η πρόσβαση σε εργαλεία ή συστήματα διάθεσης σε περιβάλλον παραγωγής πρέπει να ελέγχεται, να καταγράφεται και να ανασκοπείται περιοδικά από τον Γενικό Διευθυντή ή τον πάροχο πληροφορικής.»
Αυτό είναι το βήμα διακυβέρνησης που παραλείπουν πολλές μικρότερες ομάδες. Μια πλατφόρμα CI/CD με διαπιστευτήρια νέφους παραγωγής αποτελεί διαδρομή προνομιούχας πρόσβασης στην παραγωγή.
Τρεις περιοχές ελέγχων ISO/IEC 27002:2022 πίσω από το ασφαλές CI/CD
Το Zenith Controls: Ο οδηγός διατομεακής συμμόρφωσης Zenith Controls είναι η πυξίδα διατομεακής συμμόρφωσης του Clarysec για την αντιστοίχιση επίσημων προτύπων και πλαισίων σε πρακτικές σχέσεις ελέγχων. Για τη διακυβέρνηση ασφάλειας αγωγών CI/CD, τρεις περιοχές ελέγχων ISO/IEC 27002:2022 είναι κεντρικές.
| Έλεγχος ISO/IEC 27002:2022 | Ρόλος διακυβέρνησης CI/CD | Συναφείς έλεγχοι και τεκμήρια |
|---|---|---|
| 5.21 Διαχείριση της ασφάλειας πληροφοριών στην εφοδιαστική αλυσίδα ΤΠΕ | Διέπει πλατφόρμες CI/CD, ενέργειες τρίτων μερών, αποθετήρια πακέτων, υπηρεσίες build σε περιβάλλον νέφους, μητρώα και εξωτερική ανάπτυξη | Δέουσα επιμέλεια προμηθευτών, συμβατικές απαιτήσεις ασφάλειας, αρχεία καταγραφής παρόχων, απογραφές εξαρτήσεων |
| 8.25 Ασφαλής κύκλος ζωής ανάπτυξης | Ενσωματώνει την ασφάλεια στις απαιτήσεις, τον σχεδιασμό, την κωδικοποίηση, το build, τις δοκιμές και την έκδοση | Ασφαλής αρχιτεκτονική, ασφαλής κωδικοποίηση, δοκιμές ασφάλειας, υπογραφή τεχνουργημάτων, τεκμήρια έκδοσης |
| 8.32 Διαχείριση αλλαγών | Διασφαλίζει ότι οι διαθέσεις σε παραγωγή είναι σκόπιμες, αιτιολογημένες, εγκεκριμένες και ελέγξιμες | Change request ID, έγκριση, αρχείο καταγραφής διάθεσης σε παραγωγή, σχέδιο επαναφοράς, αρχείο επείγουσας αλλαγής |
Το Zenith Controls περιγράφει το 5.21 ως προληπτικό έλεγχο που υποστηρίζει την εμπιστευτικότητα, την ακεραιότητα και τη διαθεσιμότητα, με την ασφάλεια στις σχέσεις προμηθευτών ως βασική επιχειρησιακή ικανότητα. Αυτό ταιριάζει στο CI/CD επειδή οι σύγχρονοι αγωγοί εξαρτώνται από εξωτερικές υπηρεσίες: πλατφόρμες ελέγχου εκδόσεων πηγαίου κώδικα, hosted runners, μητρώα container, αποθετήρια πακέτων ανοικτού κώδικα, τρίτες GitHub actions, εργαλεία σάρωσης, API διάθεσης σε περιβάλλον νέφους και εξωτερικούς προγραμματιστές.
Στην αντιστοίχιση του 5.21, το Zenith Controls συνδέει την ασφάλεια εφοδιαστικής αλυσίδας ΤΠΕ με το 5.19 Ασφάλεια πληροφοριών στις σχέσεις προμηθευτών, το 5.20 Αντιμετώπιση της ασφάλειας πληροφοριών εντός συμφωνιών με προμηθευτές, το 8.27 Ασφαλής αρχιτεκτονική συστημάτων και αρχές μηχανικής, το 8.28 Ασφαλής κωδικοποίηση, το 8.29 Δοκιμές ασφάλειας στην ανάπτυξη και αποδοχή, το 5.15 έλεγχος πρόσβασης, το 5.28 Συλλογή τεκμηρίων, το 8.25 Ασφαλής κύκλος ζωής ανάπτυξης και το 8.30 Εξωτερική ανάθεση ανάπτυξης.
Για το 8.25, το Zenith Controls προσδιορίζει τον ασφαλή κύκλο ζωής ανάπτυξης ως προληπτικό έλεγχο που προστατεύει την εμπιστευτικότητα, την ακεραιότητα και τη διαθεσιμότητα. Συνδέει απαιτήσεις ασφάλειας, αρχιτεκτονική, κωδικοποίηση, δοκιμές, εξωτερική ανάπτυξη και το 8.31 Διαχωρισμός περιβαλλόντων ανάπτυξης, δοκιμών και παραγωγής.
Για το 8.32, το Zenith Controls πλαισιώνει τη διαχείριση αλλαγών ως τη γέφυρα μεταξύ ανάπτυξης και λειτουργιών. Σχετίζεται με το 8.9 Διαχείριση διαμόρφωσης, το 8.8 Διαχείριση τεχνικών ευπαθειών, τον ασφαλή SDLC και την απόκριση σε περιστατικά. Γι’ αυτό η αυτοματοποίηση διάθεσης σε παραγωγή δεν μπορεί να βρίσκεται εκτός διακυβέρνησης αλλαγών. Είναι ο μηχανισμός μέσω του οποίου πραγματοποιούνται αλλαγές στην παραγωγή.
Προέλευση build: η ιστορία έκδοσης που μπορούν να ακολουθήσουν οι ελεγκτές
Η προέλευση build είναι η ικανότητα του οργανισμού να απαντά, με τεκμήρια, από πού προήλθε ένα τεχνούργημα λογισμικού και πώς παρήχθη. Ένα ισχυρό αρχείο προέλευσης αφηγείται την ιστορία μιας έκδοσης:
- Ποιο αποθετήριο πηγαίου κώδικα και ποιο commit χρησιμοποιήθηκαν.
- Ποιος κλάδος ή tag ενεργοποίησε το build.
- Ποιο pull request, ποιος ανασκοπητής και ποια έγκριση συνδέθηκαν.
- Ποιος ορισμός αγωγού εκτελέστηκε.
- Ποιος runner εκτέλεσε την εργασία.
- Ποιες εξαρτήσεις και βασικές εικόνες χρησιμοποιήθηκαν.
- Ποιες δοκιμές και πύλες ασφάλειας εκτελέστηκαν.
- Ποιο τεχνούργημα παρήχθη.
- Ποια υπογραφή ή hash δημιουργήθηκε.
- Ποια διάθεση σε παραγωγή κατανάλωσε το τεχνούργημα.
Η P05 Πολιτική Διαχείρισης Αλλαγών Πολιτική Διαχείρισης Αλλαγών παρέχει τον σύνδεσμο διακυβέρνησης. Αναφέρει:
«Οι αλλαγές μέσω εργαλείων πρέπει και πάλι να συμμορφώνονται με την παρούσα πολιτική και να είναι ιχνηλάσιμες προς αντίστοιχο Change request ID.»
Αυτό αντιμετωπίζει το συνηθισμένο επιχείρημα ότι οι αυτοματοποιημένες διαθέσεις σε παραγωγή δεν χρειάζονται δελτία αλλαγής. Η αυτοματοποίηση δεν καταργεί τη διακυβέρνηση αλλαγών. Αλλάζει τον τρόπο με τον οποίο δημιουργούνται τα τεκμήρια.
Η ίδια πολιτική αναφέρει:
«Όλα τα αιτήματα αλλαγής, οι ανασκοπήσεις, οι εγκρίσεις και τα υποστηρικτικά τεκμήρια πρέπει να καταγράφονται στο κεντρικοποιημένο σύστημα διαχείρισης αλλαγών.»
Στην πράξη, το σύστημα διαχείρισης αλλαγών πρέπει να είναι το ευρετήριο, όχι ο χώρος απόθεσης. Το δελτίο πρέπει να παραπέμπει στο αποθετήριο πηγαίου κώδικα, στην εκτέλεση build, στην υπογραφή τεχνουργήματος, στο αρχείο καταγραφής διάθεσης σε παραγωγή και στο σχέδιο επαναφοράς. Τα αναλυτικά τεκμήρια μπορούν να παραμένουν στα εργαλεία μηχανικής, εφόσον έχουν οριστεί η διατήρηση, ο έλεγχος πρόσβασης και η δυνατότητα εξαγωγής.
| Ερώτημα ελέγχου | Τεκμήρια προς διατήρηση | Υπεύθυνος |
|---|---|---|
| Εγκρίθηκε ο πηγαίος κώδικας; | Έγκριση pull request, ρυθμίσεις προστασίας κλάδων, ταυτότητα ανασκοπητή | Επικεφαλής μηχανικής ομάδας |
| Ήταν ελεγχόμενο το build; | Build run ID, runner ID, έκδοση ορισμού αγωγού, αρχεία καταγραφής εργασιών | DevOps |
| Ήταν ιχνηλάσιμο το τεχνούργημα; | Hash τεχνουργήματος, υπογραφή, αναφορά commit προέλευσης, μεταδεδομένα μητρώου | Ομάδα πλατφόρμας |
| Εκτελέστηκαν οι πύλες ασφάλειας; | Αποτελέσματα σαρώσεων SAST, SCA, container, DAST και IaC, εγκρίσεις εξαιρέσεων | Ασφάλεια |
| Εξουσιοδοτήθηκε η διάθεση σε παραγωγή; | Change request ID, εγκρίνων, παράθυρο διάθεσης, σχέδιο επαναφοράς | Υπεύθυνος διαχείρισης αλλαγών |
| Μπορούν να διατηρηθούν τα τεκμήρια; | Εξαγόμενα αρχεία καταγραφής, στιγμιότυπα οθόνης, hashes, αρχείο αλυσίδας επιμέλειας | Ασφάλεια ή συμμόρφωση |
Σκλήρυνση runner: ο παραγνωρισμένος έλεγχος παραγωγής
Οι CI/CD runners συχνά αντιμετωπίζονται ως αναλώσιμη υποδομή, αλλά είναι περιβάλλοντα εκτέλεσης υψηλού κινδύνου. Ένας runner μπορεί να έχει πρόσβαση σε πηγαίο κώδικα, μυστικά, build caches, αποθετήρια πακέτων, κλειδιά υπογραφής, μητρώα τεχνουργημάτων και ρόλους διάθεσης σε περιβάλλον νέφους. Αν είναι μόνιμος, κοινόχρηστος, υπερπρονομιούχος ή ελλιπώς παρακολουθούμενος, γίνεται προνομιούχο σημείο πλευρικής κίνησης.
Η ασφαλής θέση διακυβέρνησης είναι απλή: οι runners που δημιουργούν ή διαθέτουν κώδικα σε παραγωγή πρέπει να σκληρύνονται όπως η υποδομή παραγωγής.
| Περιοχή σκλήρυνσης runner | Αναμενόμενος έλεγχος | Ελεγκτικά τεκμήρια |
|---|---|---|
| Απομόνωση | Χρήση ephemeral runners για ευαίσθητα builds και αποφυγή κοινής χρήσης σε όρια εμπιστοσύνης | Αρχεία καταγραφής κύκλου ζωής runner, ρυθμίσεις ομάδας runner |
| Ασφάλεια διαπιστευτηρίων | Χρήση βραχύβιων διαπιστευτηρίων και ταυτότητας φόρτου εργασίας αντί μακρόβιων μυστικών | Διαμόρφωση ταυτότητας, ρυθμίσεις λήξης διακριτικών, αρχεία καταγραφής περιοδικής αλλαγής μυστικών |
| Ελάχιστο προνόμιο | Διαχωρισμός ρόλων build, δοκιμών, υπογραφής και διάθεσης | Ορισμοί ρόλων, αναθεωρήσεις δικαιωμάτων πρόσβασης, εξαγωγές δικαιωμάτων |
| Έλεγχος δικτύου | Περιορισμός εξερχόμενης πρόσβασης και αποκλεισμός περιττής συνδεσιμότητας προς παραγωγή | Κανόνες τείχους προστασίας, εξαγωγές πολιτικών δικτύου, αρχεία καταγραφής εξερχόμενης κίνησης |
| Ακεραιότητα βασικής γραμμής | Εφαρμογή διορθώσεων σε εικόνες runner και καταγραφή εγκεκριμένων εκδόσεων | Απογραφή εικόνων, αναφορές διορθώσεων, digests εικόνων build |
| Προστασία cache | Αποτροπή επιμόλυνσης μεταξύ έργων μέσω build caches | Πολιτική cache, ρυθμίσεις απομόνωσης έργων |
| Παρακολούθηση | Καταγραφή διαχειριστικών ενεργειών, αλλαγών διαμόρφωσης και ανωμαλιών εργασιών | Αρχεία καταγραφής ελέγχου CI/CD, συμβάντα SIEM, αρχεία ειδοποιήσεων |
Η Πολιτική Δεδομένων Δοκιμών και Περιβάλλοντος Δοκιμών Πολιτική Δεδομένων Δοκιμών και Περιβάλλοντος Δοκιμών αναφέρει:
«Η ενοποίηση με αγωγούς CI/CD πρέπει να επιβάλλει τον διαχωρισμό περιβαλλόντων και διαπιστευτηρίων αυθεντικοποίησης.»
Ένας runner που μπορεί να διαθέσει σε staging και παραγωγή με το ίδιο μοντέλο διαπιστευτηρίων παραβιάζει στην ουσία τον διαχωρισμό περιβαλλόντων, ακόμη και αν η υποδομή είναι λογικά χωριστή. Το Clarysec συνήθως συνιστά ξεχωριστές ταυτότητες διάθεσης ανά περιβάλλον, ξεχωριστές πύλες έγκρισης για την παραγωγή και ρητούς ελέγχους που αποτρέπουν εργασίες χαμηλότερων περιβαλλόντων από την πρόσβαση σε μυστικά παραγωγής.
Το Zenith Blueprint, στη φάση Έλεγχοι σε εφαρμογή, Βήμα 21, το ενισχύει αυτό μέσω του διαχωρισμού περιβαλλόντων ανάπτυξης, δοκιμών και παραγωγής:
«Αν χρησιμοποιείται CI/CD, επιβεβαιώστε ότι η προώθηση διάθεσης μεταξύ περιβαλλόντων είναι ελεγχόμενη και απαιτεί ανασκόπηση ή έγκριση. Τεκμηριώστε το στη Διαδικασία Διαχείρισης Περιβαλλόντων και λάβετε στιγμιότυπα οθόνης ή εξαγωγές κονσόλας για τεκμηρίωση.»
Σε έναν πραγματικό έλεγχο, αυτό σημαίνει ότι ο ελεγκτής δεν πρέπει να δει μόνο ένα διάγραμμα. Πρέπει να δει εξαγωγές κονσόλας που δείχνουν διαπιστευτήρια ειδικά ανά περιβάλλον, προστατευμένα περιβάλλοντα διάθεσης, πύλες έγκρισης και αρχεία καταγραφής που αποδεικνύουν ότι η προώθηση ήταν ελεγχόμενη.
Τεκμήρια διάθεσης σε παραγωγή: το τεχνούργημα συμμόρφωσης που βρίσκεται σε κοινή θέα
Οι πιο ώριμες ομάδες DevSecOps δεν αντιμετωπίζουν τη συλλογή τεκμηρίων ως τριμηνιαίο αγώνα της τελευταίας στιγμής. Σχεδιάζουν αγωγούς ώστε να δημιουργούν τεκμήρια αυτόματα.
Η Πολιτική Καταγραφής και Παρακολούθησης για ΜΜΕ Πολιτική Καταγραφής και Παρακολούθησης για ΜΜΕ προσδιορίζει τα σχετικά συμβάντα καταγραφής ως εξής:
«Αρχεία καταγραφής συστήματος: αλλαγές διαμόρφωσης, διαχειριστικές ενέργειες, εγκαταστάσεις λογισμικού, δραστηριότητα εφαρμογής διορθώσεων»
Τα συστήματα CI/CD παράγουν και τις τέσσερις κατηγορίες. Οι αλλαγές διαμόρφωσης αγωγού επηρεάζουν τον τρόπο δημιουργίας του λογισμικού. Οι διαχειριστικές ενέργειες αλλάζουν ποιος μπορεί να εγκρίνει ή να διαθέσει σε παραγωγή. Οι εγκαταστάσεις λογισμικού συμβαίνουν σε εικόνες build και σε στόχους διάθεσης. Η δραστηριότητα εφαρμογής διορθώσεων μπορεί να περνά μέσα από αυτοματοποιημένες διαδικασίες έκδοσης. Τα συμβάντα αυτά πρέπει να καταγράφονται, να διατηρούνται και να ανασκοπούνται βάσει κινδύνου.
Για ετοιμότητα διερεύνησης, η P31S Πολιτική Συλλογής Τεκμηρίων και Ψηφιακής Εγκληματολογίας για ΜΜΕ Πολιτική Συλλογής Τεκμηρίων και Ψηφιακής Εγκληματολογίας για ΜΜΕ αναφέρει:
«Στιγμιότυπα οθόνης, εξαγόμενα αρχεία καταγραφής και hashes αρχείων πρέπει να αποθηκεύονται μαζί με το αρχείο αλυσίδας επιμέλειας.»
Αυτό είναι ιδιαίτερα σημαντικό μετά από υποψία παραβίασης αγωγού. Τα στιγμιότυπα οθόνης από μόνα τους είναι αδύναμα τεκμήρια. Τα αρχεία καταγραφής χωρίς hashes μπορούν να αμφισβητηθούν. Ένα αρχείο αλυσίδας επιμέλειας χωρίς αναφορές πηγής είναι ελλιπές.
Ένα τεκμηριωμένο αρχείο διάθεσης σε παραγωγή πρέπει να περιλαμβάνει τα εξής.
| Στοιχείο τεκμηρίων | Ελάχιστο περιεχόμενο | Κύρια πηγή | Αξία συμμόρφωσης |
|---|---|---|---|
| Αίτημα αλλαγής | Επιχειρησιακή ανάγκη, επίπεδο κινδύνου, έγκριση, change ID, σχέδιο επαναφοράς | JIRA, ServiceNow, Git issue | ISO 27002 8.32, DORA Article 9 |
| Αρχείο πηγαίου κώδικα | Αποθετήριο, commit, κλάδος, εγκρίσεις pull request | Git, GitHub, GitLab, Azure DevOps | ISO 27002 8.25, NIS2 Article 21 |
| Αρχείο build | Pipeline ID, runner ID, αρχεία καταγραφής build, δεδομένα εξαρτήσεων | Πλατφόρμα CI/CD | ISO 27002 8.25, τεκμήρια εφοδιαστικής αλυσίδας ΤΠΕ |
| Βεβαίωση προέλευσης build | Υπογεγραμμένο αρχείο εισόδων build, περιβάλλοντος και διαδικασίας | Εργαλείο CI/CD, ροή εργασίας με δυνατότητα SLSA | ISO 27002 5.21, υποστήριξη CRA Annex I |
| Αρχείο πύλης ασφάλειας | Αποτελέσματα σαρώσεων SAST, SCA, DAST, container και IaC | Εργαλεία ασφάλειας, αρχεία καταγραφής αγωγού | ISO 27002 8.29, DORA Article 9 |
| Αρχείο τεχνουργήματος | Hash, υπογραφή, διαδρομή μητρώου, αμετάβλητο digest | Μητρώο τεχνουργημάτων | ISO 27002 8.25, τεκμήρια ασφαλούς ενημέρωσης CRA |
| Αρχείο διάθεσης σε παραγωγή | Περιβάλλον, δρων, χρονοσήμανση, έγκριση παραγωγής | GitOps, πλατφόρμα διάθεσης | ISO 27002 8.32, DORA Article 10 |
| Αρχείο παρακολούθησης | Έλεγχοι υγείας και ανωμαλιών μετά τη διάθεση | SIEM, πλατφόρμα παρατηρησιμότητας | Προσδοκίες DORA για ανίχνευση και απόκριση |
| Διατήρηση τεκμηρίων | Εξαγόμενα αρχεία καταγραφής, στιγμιότυπα οθόνης, hashes, αρχείο επιμέλειας | Αποθετήριο τεκμηρίων | ISO 27002 5.28, διερεύνηση περιστατικού |
Αυτό το πακέτο μετατρέπει το CI/CD από σειρά τεχνικών βημάτων σε ιστορία διακυβέρνησης, ελέγχου και δέουσας επιμέλειας.
Αντιστοίχιση της διακυβέρνησης CI/CD με NIS2, DORA, GDPR και CRA
Το NIS2 εφαρμόζεται σε πολλές βασικές και σημαντικές οντότητες, συμπεριλαμβανομένων της ψηφιακής υποδομής, της διαχείρισης υπηρεσιών ΤΠΕ και των οργανισμών ψηφιακών παρόχων όπου πληρούνται τα κριτήρια. Το Article 20 είναι ιδιαίτερα συναφές, επειδή δημιουργεί καθήκοντα κυβερνοασφάλειας σε επίπεδο διοίκησης. Τα όργανα διοίκησης πρέπει να εγκρίνουν μέτρα διαχείρισης κινδύνων κυβερνοασφάλειας, να εποπτεύουν την υλοποίηση και να λαμβάνουν εκπαίδευση.
Το Article 21 παρέχει τη βασική γραμμή διαχείρισης κινδύνων. Απαιτεί κατάλληλα και αναλογικά τεχνικά, επιχειρησιακά και οργανωτικά μέτρα που καλύπτουν ανάλυση κινδύνου, πολιτικές, χειρισμό περιστατικών, επιχειρησιακή συνέχεια, ασφάλεια εφοδιαστικής αλυσίδας, ασφαλή απόκτηση, ανάπτυξη και συντήρηση, χειρισμό ευπαθειών, αξιολόγηση αποτελεσματικότητας, κυβερνοϋγιεινή, κρυπτογραφία, ασφάλεια ανθρώπινου δυναμικού, έλεγχο πρόσβασης, διαχείριση περιουσιακών στοιχείων και MFA όπου ενδείκνυται.
| Θέμα NIS2 Article 21 | Ερμηνεία διακυβέρνησης CI/CD |
|---|---|
| Ανάλυση κινδύνου και πολιτικές | Μοντελοποίηση απειλών αγωγού, πολιτική ασφαλούς ανάπτυξης, αξιολόγηση κινδύνου runner |
| Χειρισμός περιστατικών | Playbook παραβίασης αγωγού, ανάκληση τεχνουργήματος, έλεγχος επείγουσας έκδοσης |
| Επιχειρησιακή συνέχεια | Ανάκαμψη ελέγχου εκδόσεων πηγαίου κώδικα, μητρώου τεχνουργημάτων και αυτοματοποίησης διάθεσης |
| Ασφάλεια εφοδιαστικής αλυσίδας | Ενέργειες τρίτων μερών, πακέτα, εξωτερική ανάπτυξη, εξαρτήσεις μητρώου |
| Ασφαλής ανάπτυξη και συντήρηση | Ασφαλές SDLC, ανασκόπηση κώδικα, δοκιμές, χειρισμός ευπαθειών |
| Αξιολόγηση αποτελεσματικότητας | Δοκιμές ελέγχων αγωγού, δειγματοληψία ελέγχου, μετρικές και εξαιρέσεις |
| Έλεγχος πρόσβασης και MFA | Αποθετήριο, διαχείριση CI/CD, καταχώριση runner, ρόλοι διάθεσης σε παραγωγή |
| Κρυπτογραφία | Υπογραφή τεχνουργημάτων, προστασία μυστικών, διαχείριση κλειδιών |
Το Article 23 προσθέτει κλιμακωτή αναφορά σημαντικών περιστατικών, συμπεριλαμβανομένης πρώιμης προειδοποίησης εντός 24 ωρών από τη γνώση, κοινοποίησης περιστατικού εντός 72 ωρών και τελικής αναφοράς το αργότερο έναν μήνα μετά την κοινοποίηση περιστατικού. Αν μια παραβίαση CI/CD θα μπορούσε να προκαλέσει σοβαρή επιχειρησιακή διακοπή, οικονομική ζημία ή ουσιώδη βλάβη σε άλλους, η διαδικασία ταξινόμησης περιστατικών πρέπει να είναι έτοιμη πριν από το περιστατικό.
Για τις χρηματοοικονομικές οντότητες, το DORA εφαρμόζεται από τις 17 Ιανουαρίου 2025 και καλύπτει τη διαχείριση κινδύνων ΤΠΕ, την αναφορά περιστατικών, τις δοκιμές ανθεκτικότητας, την ανταλλαγή πληροφοριών, τη διαχείριση κινδύνων τρίτων παρόχων ΤΠΕ και τις συμβατικές απαιτήσεις. Το Article 5 απαιτεί εσωτερικό πλαίσιο διακυβέρνησης και ελέγχου για τον κίνδυνο ΤΠΕ, με ευθύνη του οργάνου διοίκησης. Το Article 6 απαιτεί τεκμηριωμένο πλαίσιο διαχείρισης κινδύνων ΤΠΕ ενσωματωμένο στη συνολική διαχείριση κινδύνων.
Τα Articles 8 έως 14 αντιστοιχίζονται άμεσα στη διακυβέρνηση αγωγών CI/CD. Οι χρηματοοικονομικές οντότητες πρέπει να αναγνωρίζουν και να ταξινομούν επιχειρησιακές λειτουργίες που υποστηρίζονται από ΤΠΕ, περιουσιακά στοιχεία, εξαρτήσεις, απειλές και ευπάθειες. Πρέπει να προστατεύουν τα συστήματα ΤΠΕ μέσω πολιτικών, ελέγχων πρόσβασης, ισχυρής αυθεντικοποίησης, προστασίας κρυπτογραφικών κλειδιών, ελεγχόμενης διαχείρισης αλλαγών ΤΠΕ, εφαρμογής διορθώσεων και τμηματοποίησης. Πρέπει να ανιχνεύουν ανωμαλίες, να ανταποκρίνονται, να ανακάμπτουν και να μαθαίνουν από περιστατικά.
Τα Articles 28 έως 30 είναι εξίσου σημαντικά, επειδή οι πλατφόρμες CI/CD, οι πάροχοι ελέγχου εκδόσεων πηγαίου κώδικα, τα μητρώα τεχνουργημάτων, τα συστήματα build σε περιβάλλον νέφους και οι εξωτερικοί προγραμματιστές μπορεί να αποτελούν εξαρτήσεις τρίτων παρόχων ΤΠΕ. Το DORA αναμένει δέουσα επιμέλεια, συμβατικές δικλίδες ασφαλείας, αξιολόγηση κινδύνου συγκέντρωσης, δικαιώματα ελέγχου και επιθεώρησης, εναύσματα λύσης, στρατηγικές εξόδου και ρήτρες επιπέδου υπηρεσιών.
Το GDPR προσθέτει τη διάσταση της αρχής της λογοδοσίας. Το Article 5 απαιτεί τα δεδομένα προσωπικού χαρακτήρα να υποβάλλονται σε επεξεργασία νόμιμα, δίκαια, με διαφάνεια, για καθορισμένους σκοπούς, να ελαχιστοποιούνται, να είναι ακριβή, να διατηρούνται μόνο όσο απαιτείται και να προστατεύονται από μη εξουσιοδοτημένη ή παράνομη επεξεργασία και από τυχαία απώλεια, καταστροφή ή βλάβη. Το Article 5(2) απαιτεί από τον υπεύθυνο επεξεργασίας να αποδεικνύει συμμόρφωση.
Οι αγωγοί CI/CD έχουν σημασία για το GDPR επειδή οι προγραμματιστές μπορεί να χρησιμοποιούν δεδομένα παραγωγής σε περιβάλλοντα δοκιμών, τα αρχεία καταγραφής αγωγού μπορεί να εκθέτουν δεδομένα προσωπικού χαρακτήρα ή διακριτικά, οι εκδόσεις μπορεί να αλλάζουν τη λογική επεξεργασίας και τα παραβιασμένα τεχνουργήματα μπορεί να προκαλέσουν παραβιάσεις προσωπικών δεδομένων. Όταν οι αλλαγές λογισμικού επηρεάζουν ελέγχους ιδιωτικότητας, το αρχείο αλλαγής πρέπει να αποτυπώνει τον αντίκτυπο στην ιδιωτικότητα. Όταν ένα περιστατικό αγωγού προκαλεί μη εξουσιοδοτημένη πρόσβαση σε δεδομένα προσωπικού χαρακτήρα, η αξιολόγηση παραβίασης πρέπει να συνδέεται με τον χειρισμό περιστατικών.
Οι προσδοκίες CRA προσθέτουν ασφάλεια προϊόντος και τεκμήρια ασφαλών ενημερώσεων. Για κατασκευαστές και παρόχους λογισμικού που διαθέτουν στην αγορά της ΕΕ προϊόντα με ψηφιακά στοιχεία, οι πελάτες αναμένουν όλο και περισσότερο φακέλους ασφάλειας προϊόντος, τεκμήρια χειρισμού ευπαθειών, ελέγχους ασφαλών ενημερώσεων και ακεραιότητα εκδόσεων. Η διακυβέρνηση CI/CD παρέχει μεγάλο μέρος αυτών των τεκμηρίων μέσω ιχνηλασιμότητας πηγαίου κώδικα, υπογεγραμμένων τεχνουργημάτων, αποτελεσμάτων σαρώσεων ευπαθειών, σημειώσεων έκδοσης, διορθώσεων ασφαλείας και αρχείων διανομής ενημερώσεων.
NIST CSF 2.0 και COBIT 2019: η ελεγκτική οπτική πέρα από το ISO
Το NIST CSF 2.0 παρέχει επίπεδο ενοποίησης για τη διακυβέρνηση κυβερνοασφάλειας. Το Core, τα Organizational Profiles και τα Tiers βοηθούν τους οργανισμούς να κατανοούν την τρέχουσα και τη στοχευόμενη στάση, να ιεραρχούν ενέργειες ευθυγραμμισμένες με νομικές και κανονιστικές απαιτήσεις και να επικοινωνούν τον κυβερνοκίνδυνο.
Για το CI/CD, το Clarysec συχνά δημιουργεί ένα προφίλ αγωγού παράδοσης λογισμικού. Το Current Profile αποτυπώνει πώς λειτουργούν σήμερα ο έλεγχος εκδόσεων πηγαίου κώδικα, οι runners, η υπογραφή τεχνουργημάτων και οι εγκρίσεις διάθεσης σε παραγωγή. Το Target Profile ορίζει την απαιτούμενη κατάσταση για ρυθμιζόμενες λειτουργίες. Το σχέδιο κάλυψης κενών γίνεται ο οδικός χάρτης υλοποίησης.
Η λειτουργία NIST GOVERN είναι ιδιαίτερα συναφής. Το GV.OC-03 απαιτεί να είναι κατανοητές και να διαχειρίζονται οι νομικές, κανονιστικές και συμβατικές απαιτήσεις κυβερνοασφάλειας. Το GV.RM καλύπτει τη διάθεση ανάληψης κινδύνου και την τυποποιημένη ιεράρχηση κινδύνου. Το GV.RR αναθέτει λογοδοσία ηγεσίας, ρόλους και πόρους. Το GV.PO απαιτεί πολιτικές κινδύνου κυβερνοασφάλειας να θεσπίζονται, να εφαρμόζονται, να ανασκοπούνται και να επικαιροποιούνται. Το GV.OV καλύπτει την εποπτεία και την αξιολόγηση απόδοσης.
Ένας ελεγκτής COBIT 2019 ή τύπου ISACA συχνά θα εξετάσει λιγότερο την κρυπτογραφική λεπτομέρεια της υπογραφής τεχνουργημάτων και περισσότερο τον σχεδιασμό διακυβέρνησης. Θα ρωτήσει αν έχει οριστεί ιδιοκτησία, αν η ενεργοποίηση αλλαγών ελέγχεται, αν οι υπηρεσίες τρίτων μερών διαχειρίζονται βάσει κινδύνου, αν η παρακολούθηση παράγει διασφάλιση, αν οι εξαιρέσεις εγκρίνονται και αν η διοίκηση λαμβάνει ουσιαστική αναφορά.
| Ελεγκτική οπτική | Πιθανό ερώτημα ελέγχου | Τεκμήρια που απαντούν |
|---|---|---|
| Ελεγκτής ISO/IEC 27001:2022 | Περιλαμβάνεται το CI/CD στο πεδίο εφαρμογής του ISMS, στην αξιολόγηση κινδύνου, στη Δήλωση Εφαρμοσιμότητας και στους λειτουργικούς ελέγχους; | Πεδίο εφαρμογής ISMS, μητρώο κινδύνων, αντιστοίχιση SoA, ρήτρες πολιτικής, δείγματα διαθέσεων σε παραγωγή |
| Ανασκοπητής ελέγχων ISO/IEC 27002:2022 | Έχουν υλοποιηθεί ασφαλές SDLC, διαχωρισμός περιβαλλόντων, έλεγχος πρόσβασης, διαχείριση αλλαγών και συλλογή τεκμηρίων; | Προστασίες κλάδων, διαπιστευτήρια περιβαλλόντων, εγκρίσεις, υπογραφές τεχνουργημάτων, αρχεία καταγραφής |
| Αξιολογητής NIS2 | Έχει εγκρίνει η διοίκηση αναλογικά μέτρα για ασφαλή ανάπτυξη, εφοδιαστική αλυσίδα, έλεγχο πρόσβασης, χειρισμό περιστατικών και ανθεκτικότητα; | Πρακτικά διοικητικού συμβουλίου, σχέδιο αντιμετώπισης κινδύνων, αντιστοίχιση Article 21, playbook περιστατικών, αρχεία προμηθευτών |
| Ελεγκτής DORA | Υποστηρίζει ο αγωγός διαχείριση κινδύνων ΤΠΕ, ελεγχόμενες αλλαγές, παρακολούθηση, δοκιμές, αναφορά περιστατικών και διακυβέρνηση τρίτων παρόχων ΤΠΕ; | Αποθετήριο περιουσιακών στοιχείων ΤΠΕ, αρχεία αλλαγών, αρχεία καταγραφής ανίχνευσης, ταξινόμηση περιστατικών, μητρώο παρόχων |
| Ανασκοπητής GDPR | Μπορεί ο οργανισμός να αποδείξει ασφάλεια και λογοδοσία για εκδόσεις που επηρεάζουν δεδομένα προσωπικού χαρακτήρα; | Σημειώσεις ανασκόπησης ιδιωτικότητας, έλεγχοι δεδομένων δοκιμών, αρχεία καταγραφής πρόσβασης, ροή αξιολόγησης παραβίασης |
| Αξιολογητής NIST CSF 2.0 | Ποια είναι η τρέχουσα έναντι της στοχευόμενης στάσης του αγωγού και ποιο είναι το ιεραρχημένο σχέδιο βελτίωσης; | Προφίλ CSF, ανάλυση κενών, POA&M, μετρικές, αρχεία αποδοχής κινδύνου |
| Ελεγκτής COBIT 2019 ή ISACA | Έχουν οριστεί ρόλοι, αρμοδιότητες, έλεγχοι διεργασιών, μέτρα απόδοσης και δραστηριότητες διασφάλισης; | RACI, κατάλογος υπευθύνων ελέγχων, αναφορές KPI και KRI, αποτελέσματα εσωτερικού ελέγχου, μητρώο εξαιρέσεων |
Συνήθεις αστοχίες ελέγχου CI/CD και μετρικές για το διοικητικό συμβούλιο
Τα περισσότερα ευρήματα ελέγχου CI/CD είναι προβλέψιμα. Το πρώτο είναι τα ασύνδετα τεκμήρια. Η ομάδα έχει αρχεία καταγραφής Git, αρχεία καταγραφής αγωγού και αρχεία καταγραφής διάθεσης σε παραγωγή, αλλά κανένα ενιαίο αρχείο αλλαγής δεν τα συνδέει. Το δεύτερο είναι η υπερπρονομιούχα αυτοματοποίηση, όπου μία εργασία μπορεί να διαβάζει μυστικά παραγωγής, να προωθεί τεχνουργήματα, να εγκρίνει διαθέσεις σε παραγωγή και να τροποποιεί ορισμούς αγωγού. Το τρίτο είναι οι μόνιμοι κοινόχρηστοι runners, που δημιουργούν κίνδυνο επιμόλυνσης μεταξύ έργων και δυσχεραίνουν τον προσδιορισμό του πεδίου ψηφιακής διερεύνησης μετά από παραβίαση.
Άλλες συνήθεις αστοχίες περιλαμβάνουν ανυπόγραφα ή αντικατεστημένα τεχνουργήματα, άτυπες παρακάμψεις σαρώσεων, έλλειψη ορατότητας στους προμηθευτές και διαρροή ιδιωτικότητας στα αρχεία καταγραφής. Ένας καλός αγωγός επιτρέπει εξαιρέσεις, αλλά απαιτεί έγκριση, λήξη, ιδιοκτησία κινδύνου και ανασκόπηση.
Οι επικεφαλής ασφάλειας πρέπει να αποφεύγουν την αναφορά προς το διοικητικό συμβούλιο μόνο αριθμών σαρωτών. Αντ’ αυτού, πρέπει να αναφέρουν μετρικές εμπιστοσύνης έκδοσης:
- Ποσοστό διαθέσεων σε παραγωγή που συνδέονται με εγκεκριμένα αρχεία αλλαγών.
- Ποσοστό τεχνουργημάτων παραγωγής που είναι υπογεγραμμένα και ιχνηλάσιμα προς commits προέλευσης.
- Αριθμός διαθέσεων σε παραγωγή που χρησιμοποιούν εξαιρέσεις ή επείγουσες εγκρίσεις.
- Ποσοστό προνομιούχων χρηστών CI/CD με MFA και πρόσφατη αναθεώρηση δικαιωμάτων πρόσβασης.
- Αριθμός ενεργών μακρόβιων διαπιστευτηρίων διάθεσης.
- Ποσοστό κρίσιμων υπηρεσιών που χρησιμοποιούν σκληρυμένους ή ephemeral runners.
- Μέσος χρόνος ανάκλησης ή περιοδικής αλλαγής μυστικών αγωγού μετά από περιστατικό.
- Αριθμός κρίσιμων εξαρτήσεων προμηθευτών που υποστηρίζουν την παράδοση λογισμικού.
- Ποσοστό πληρότητας τεκμηρίων για εκδόσεις που επιλέγονται δειγματοληπτικά σε έλεγχο.
Οι μετρικές αυτές υποστηρίζουν την ηγεσία, τον σχεδιασμό και τον επιχειρησιακό έλεγχο του ISO/IEC 27001:2022. Υποστηρίζουν επίσης την εποπτεία της διοίκησης κατά NIS2 Article 20 και τις προσδοκίες διακυβέρνησης του DORA.
Κάντε τον αγωγό σας ελέγξιμο πριν από το περιστατικό
Η διακυβέρνηση ασφάλειας αγωγών CI/CD το 2026 δεν αφορά την επιβράδυνση της μηχανικής ομάδας. Αφορά την καθιέρωση αξιόπιστης, ανθεκτικής και αποδείξιμης παράδοσης λογισμικού. Τα καλύτερα προγράμματα χρησιμοποιούν την αυτοματοποίηση για να επιταχύνουν τα τεκμήρια, όχι για να παρακάμπτουν τη διακυβέρνηση.
Μια πρακτική υλοποίηση Clarysec ξεκινά με τρεις ενέργειες.
- Χρησιμοποιήστε το Zenith Blueprint Zenith Blueprint για να εντάξετε το ασφαλές DevOps, την πρόσβαση σε πηγαίο κώδικα, τον διαχωρισμό περιβαλλόντων και τη διαχείριση αλλαγών στον οδικό χάρτη υλοποίησης ISO/IEC 27001:2022.
- Χρησιμοποιήστε το Zenith Controls Zenith Controls για να αντιστοιχίσετε κινδύνους CI/CD σε ασφαλές SDLC, εφοδιαστική αλυσίδα ΤΠΕ, έλεγχο πρόσβασης, διαχείριση αλλαγών, συλλογή τεκμηρίων, NIS2, DORA, GDPR, NIST CSF 2.0 και ελεγκτικές οπτικές COBIT 2019.
- Αναπτύξτε πρότυπα πολιτικών Clarysec, συμπεριλαμβανομένων των Πολιτική Ασφαλούς Ανάπτυξης, Πολιτική Διαχείρισης Αλλαγών, Πολιτική Δεδομένων Δοκιμών και Περιβάλλοντος Δοκιμών, Πολιτική Ασφαλούς Ανάπτυξης για ΜΜΕ, Πολιτική Καταγραφής και Παρακολούθησης για ΜΜΕ και Πολιτική Συλλογής Τεκμηρίων και Ψηφιακής Εγκληματολογίας για ΜΜΕ, για να ορίσετε ποιος εγκρίνει εκδόσεις, πώς ιχνηλατούνται τα τεχνουργήματα, πώς ελέγχονται οι runners και ποια τεκμήρια πρέπει να διατηρούνται.
Αν το επόμενο δείγμα ελέγχου σας ξεκινήσει με «δείξτε μας τη διαδρομή της έκδοσης παραγωγής», η ομάδα σας πρέπει να μπορεί να απαντήσει σε λεπτά, όχι σε εβδομάδες. Αυτή είναι η διαφορά μεταξύ αυτοματοποίησης DevOps και διακυβερνώμενης παράδοσης λογισμικού.
Κατεβάστε το toolkit πολιτικών Clarysec, ανασκοπήστε τον αγωγό CI/CD σας με βάση το Zenith Blueprint και το Zenith Controls, ή κλείστε μια αξιολόγηση Clarysec για να μετατρέψετε τον αγωγό σας από πηγή άγχους ελέγχου σε ακρογωνιαίο λίθο ψηφιακής ανθεκτικότητας.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
