Το Linux Foundation και το Εργαστήριο Επιστήμης και Καινοτομίας του Πανεπιστημίου του Harvard δημοσίευσαν πρόσφατα την έκθεση 2020 Free/ Open-Source Software Contributor Survey.
Ένα από τα βασικά συμπεράσματα της έκθεσης είναι το γεγονός ότι οι προγραμματιστές λογισμικού ελεύθερου/ ανοιχτού κώδικα συχνά έχουν μια αρκετά αρνητική προσέγγιση στην ασφάλεια. Αφιερώνουν λοιπόν πολύ λίγο χρόνο για την επίλυση ζητημάτων ασφαλείας (κατά μέσο όρο 2,27% του συνολικού τους χρόνου) και δεν εκφράζουν καμία προθυμία να επενδύσουν περισσότερο χρόνο.
Μερικά σχόλια μάλιστα στην έρευνα θα λέγαμε ότι ήταν ανησυχητικά ή το λιγότερο ενοχλητικά. Μερικά χαρακτηριστικά παραδείγματα που έκαναν εντύπωση ήταν τα παρακάτω: «Θεωρώ ότι η επιχείρηση της ασφάλειας σου “τρώει τη ψυχή” και είναι ένα ζήτημα που καλύτερα είναι αφήνεται για τους δικηγόρους και τα φρικιά των διαδικασιών. Είμαι προγραμματιστής εφαρμογών». Ένα άλλο παράδειγμα είναι: «Θεωρώ ότι η ασφάλεια είναι αρκετά βαρετό διαδικαστικό εμπόδιο».
Αν και η έκθεση εμπεριέχει τις στρατηγικές προτάσεις των συγγραφέων, παρακάτω ακολουθούν οι σκέψεις μας σχετικά με το τι σημαίνουν όλα τα παραπάνω και η συγκεκριμένη κατάσταση για την ασφάλεια των εφαρμογών και τι μπορείτε να κάνετε εσείς για αυτό.
Η ευρύτητα του θέματος
Η έκθεση επικεντρώνεται μόνο σε λογισμικό ελεύθερου/ ανοιχτού κώδικα (FOSS) ωστόσο είναι σημαντικό να εξεταστεί αν πρόκειται για ένα πρόβλημα με όσους ασχολούνται με FOSS ή πρόκειται για ένα ευρύτερο πρόβλημα, που συναντάται σε όλους τους προγραμματιστές εφαρμογών.
Με βάση την έρευνα, οι περισσότεροι προγραμματιστές FOSS (74,87%) εργάζονται με σύμβαση εργασίας πλήρους απασχόλησης και οι περισσότεροι από τους μισούς (51,65%) πληρώνονται ειδικά για την ανάπτυξη FOSS. Αυτό σημαίνει ότι το FOSS αναπτύσσεται συχνά από τους ίδιους ανθρώπους που αναπτύσσουν και εμπορικό λογισμικό. Δεν πιστεύουμε πάντως ότι οι προγραμματιστές αλλάζουν στάση ανάλογα με τον τύπο του λογισμικού, αν δηλαδή είναι δωρεάν ή εμπορικό. Επομένως, πιστεύουμε ότι αυτή η κακή στάση απέναντι στην ασφάλεια επεκτείνεται σε όλους τους προγραμματιστές.
Πιστεύουμε επίσης ότι η βασική αιτία αυτής της στάσης είναι το γεγονός ότι οι προγραμματιστές είτε δεν διδάσκονται σωστά είτε δεν διδάσκονται καθόλου. Οι περισσότεροι διαδικτυακοί πόροι που διδάσκουν προγραμματισμό παραλείπουν εντελώς το θέμα των πρακτικών ασφαλούς κωδικοποίησης. Τα βιβλία σχετικά με τις γλώσσες προγραμματισμού σπάνια αναφέρονται στην ασφαλή κωδικοποίηση. Τα σχολεία αντιμετωπίζουν επίσης συχνά την ασφάλεια ως προαιρετικό μάθημα αντί για βασικό μάθημα που πρέπει να αποτελεί προϋπόθεση για όλες τις άλλες τάξεις προγραμματισμού.
Επομένως, συμπεραίνουμε ότι τα αποτελέσματα αυτής της έρευνας ενδεχομένως ισχύουν για όλους τους προγραμματιστές λογισμικού. Αν και στην περίπτωση της ανάπτυξης εμπορικού λογισμικού ενδέχεται να έχουν προστεθεί κάποια μέτρα ασφαλείας με την παρουσία ειδικών ομάδων ασφαλείας, «η ρίζα παραμένει σάπια».
Ασφαλής ανάπτυξη; Δύσκολο
Αν και το 86,3% των ερωτηθέντων στην έρευνα εκπαιδεύτηκε στην ανάπτυξη εφαρμογών από κάποιο εκπαιδευτικό ίδρυμα ή σχολή, μόνο το 39,8% δήλωσε ότι έχει επίσημη κατάρτιση στην ανάπτυξη ασφαλούς λογισμικού. Αυτό σημαίνει ότι οι μισοί προγραμματιστές δεν διδάχθηκαν σωστά.
Ένα ακόμη σοκαριστικό συμπέρασμα προέρχεται από την απάντηση στην ακόλουθη ερώτηση: «Κατά την ανάπτυξη λογισμικού, ποιες είναι οι βασικές πηγές σας για τις βέλτιστες πρακτικές ασφάλειας;». Αποδεικνύεται λοιπόν ότι μόνο το 10,73% έμαθε για τις βέλτιστες πρακτικές από επίσημα μαθήματα και τάξεις και το 15,51% μέσω εταιρικής κατάρτισης/ εκπαίδευσης. Σχεδόν οι μισοί προγραμματιστές και developers χρησιμοποιούν διαδικτυακά άρθρα/ ιστολόγια (46,54%) και φόρουμ (50,66%) ως την κύρια πηγή πληροφόρησης σχετικά με τις βέλτιστες πρακτικές, κάτι που δείχνει πάλι την τρομερή κατάσταση της εκπαίδευσης και την έλλειψη πόρων σχετικά με την ασφαλή κωδικοποίηση. Και ενώ εμείς στην Acunetix υπερηφανευόμαστε για την κάλυψη του κενού και ως εκπαιδευτικοί (χάρη στα άρθρα μας που εξηγούν τη λειτουργία των κενών ασφαλείας ή των ευπαθειών και πως να τις αποφύγουμε) είναι προτιμότερο για τους προγραμματιστές να είχαν μάθει για τις βέλτιστες πρακτικές ασφαλούς κωδικοποίησης από πηγές περισσότερο αξιόπιστες από τα αποτελέσματα μίας μηχανής αναζήτησης.
Τέλος, τα αποτελέσματα της έρευνας αποδεικνύουν ότι το λογισμικό ελεύθερου/ ανοιχτού κώδικα συνήθως κυκλοφορεί χωρίς τους απαραίτητους ελέγχους ασφαλείας. Ενώ το 36,63% χρησιμοποιεί ένα εργαλείο SAST για σάρωση του πηγαίου κώδικα FOSS, μόνο το 15,87% χρησιμοποιεί κάποιο εργαλείο DAST για να δοκιμάσει τις εφαρμογές. H κατάσταση είναι πιθανώς καλύτερη στην περίπτωση του εμπορικού λογισμικού επειδή οι ομάδες ασφαλείας συνήθως εισάγουν SAST/ DAST σε κάποιο στάδιο του SDLC (Software Development Life Cycle).
Για ποιο λόγο αυτή η κακή στάση;
Αν οι προγραμματιστές εφαρμογών σας έχουν κακή στάση απέναντι στην ασφάλεια, αυτό δεν οφείλεται μόνο στην εκπαίδευσή τους. Μπορεί επίσης να οφείλεται και στην επιχείρηση σας, που ενδεχομένως να τους έχει κάνει να αισθάνονται ότι δεν χρειάζεται να ασχοληθούν καθόλου με την ασφάλεια.
Οι προγραμματιστές δεν αισθάνονται υπεύθυνοι για την ασφάλεια κυρίως λόγω της ύπαρξης των ειδικών ομάδων ασφαλείας. Αν το προσωπικό ασφαλείας εργάζεται σε ξεχωριστά τμήματα ή ομάδες στον οργανισμό, οι προγραμματιστές πιστεύουν ότι η ασφάλεια δεν είναι δικό τους πρόβλημα και περιμένουν από τους ερευνητές ασφαλείας να αναλάβουν δράση και να το αντιμετωπίσουν.
Οι προγραμματιστές επίσης δεν αισθάνονται υπεύθυνοι, επειδή σε έναν παραδοσιακό οργανισμό, σπάνια ζητείται να διορθώσουν τα δικά τους λάθη που σχετίζονται με την ασφάλεια. Ένας τυπικός προγραμματιστής γράφει ένα κομμάτι κώδικα, κάποιος άλλος προγραμματιστής στη συνέχεια αξιολογεί αυτό το κομμάτι κώδικα (ο οποίος συχνά είναι εξίσου ανίδεος σχετικά με την ασφάλεια) και στη συνέχεια το προσπερνάει και το ξεχνάει. Αργότερα, ένας ερευνητής ασφαλείας εντοπίζει μια ευπάθεια και δημιουργεί ένα «ticket» για να επιδιορθωθεί. Το εισιτήριο στη συνέχεια ανατίθεται στον πρώτο διαθέσιμο προγραμματιστή – συνήθως όχι σε αυτόν που εντόπισε πρώτος την ευπάθεια.
Ένας τέτοιος οργανισμός προωθεί την έλλειψη ευθύνης σχετικά με την ασφάλεια και δημιουργεί αρνητικά συναισθήματα μεταξύ των προγραμματιστών και των ομάδων ασφαλείας. Ενδεχομένως, η μία ομάδα να βλέπει την άλλη ως «εκείνη που προκαλεί τα προβλήματα» – και αυτό είναι που πρέπει να αλλάξετε πρώτα.
Ο αυτοματισμός ως λύση
Η αυτοματοποίηση της διαδικασίας ανίχνευσης και αναφοράς ευπαθειών ασφαλείας όσο το δυνατόν νωρίτερα αποτελεί τη λύση σε αυτό το πρόβλημα. Πρώτον, τα σφάλματα αναφέρονται από λογισμικό και όχι από άνθρωπο – επομένως δεν υπάρχει κάποιο άτομο που μπορεί να κατηγορήσει (ο προγραμματιστής). Δεύτερον, το σφάλμα αναφέρεται αμέσως, συνήθως μετά το πρώτο build, οπότε επειδή το build αστοχεί και αποτυγχάνει, ο προγραμματιστής οφείλει να διορθώσει το λάθος του άμεσα. Και τρίτον, κάθε φορά που ο προγραμματιστής/ developer υποχρεώνεται να διορθώσει το σφάλμα του, μαθαίνει διαρκώς περισσότερα πράγματα για την συγγραφή ασφαλούς κώδικα και πόσο σημαντικό είναι τελικά.
Το μόνο ζήτημα που απομένει είναι η εύρεση του κατάλληλου λογισμικού που μπορείτε να εμπιστευτείτε για αυτή τη δουλειά. Δυστυχώς, οι περιορισμένες δυνατότητες του λογισμικού SAST/ DAST ήταν η αιτία για πολλές αποτυχίες στο παρελθόν και δεν είναι λίγοι οι developers που δεν θέλουν να χρησιμοποιούν τα εργαλεία αυτού του τύπου (SAST ή DAST).
Τα εργαλεία SAST επισημαίνουν πιθανά προβλήματα ωστόσο αναφέρουν και αρκετά ψευδώς θετικά – το αποτέλεσμα είναι ο προγραμματιστής να αφιερώνει πολύ χρόνο στην έρευνα για κάτι που τελικά αποδεικνύεται ότι δεν αποτελεί ευπάθεια. Έτσι, οι developers παύουν να εμπιστεύονται το εργαλείο και αρχίζουν να το μισούν. Από την άλλη, τα εργαλεία DAST μπορεί να αναφέρουν μικρότερο αριθμό ψευδώς θετικών, ωστόσο πολλές φορές δεν παρέχουν αρκετές πληροφορίες στον προγραμματιστή για να βεβαιωθεί που βρίσκεται η ευπάθεια και ποιες μπορεί να είναι οι συνέπειες της.
Το Acunetix βοηθά στην επίλυση των παραπάνω προβλημάτων. Μάλιστα το πλεονέκτημα του Acunetix είναι ότι στη περίπτωση των πιο σοβαρών ευπαθειών, το Acunetix αποδεικνύει έμπρακτα την ύπαρξη της ευπάθειας. Ο προγραμματιστής για παράδειγμα, ενδέχεται να λάβει μια αναφορά ότι ο κώδικάς του εξέθεσε ευαίσθητα αρχεία από τον διακομιστή – συμπεριλαμβανομένου του περιεχομένου των ευαίσθητων αρχείων ως αποδεικτικά στοιχεία.
Συμπεράσματα
Το πιο ανησυχητικό συμπέρασμα από αυτό το άρθρο είναι ότι το μεγαλύτερο μέρος του λογισμικού ελεύθερου/ ανοιχτού κώδικα είναι εγγενώς ανασφαλές. Επομένως, αν θέλετε να αισθάνεστε ασφαλείς κατά τη χρήση του, πρέπει από μόνοι σας να πραγματοποιείτε τακτικούς ελέγχους ασφαλείας.
Ένα άλλο ανησυχητικό συμπέρασμα, είναι ότι οι άνθρωποι που κανονικά θα έπρεπε να είναι στην πρώτη γραμμή άμυνας για την ασφάλεια πληροφορικής σας, όχι μόνο δεν είναι εκπαιδευμένοι στον τομέα της ασφάλειας, αλλά έχουν και κακή στάση απέναντι της. Και αυτό είναι κάτι που δεν αλλάζει εύκολα ή γρήγορα.
Απαιτούνται λοιπόν μακροπρόθεσμες στρατηγικές λύσεις για την επίλυση αυτών των σημαντικών προβλημάτων και η εφαρμογή απλώς μίας αυτοματοποιημένης διαδικασίας δεν είναι δυνατόν να εξαφανίσει όλα τα ζητήματα δια μαγείας. Παρόλα αυτά, αν εισάγετε στις διαδικασίες σας μία αξιόπιστη αυτοματοποιημένη λύση testing όπως το Acunetix στα αρχικά στάδια του DevSecOps SDLC σας (Software Development Life Cycle) θα διασφαλίσετε ότι το λογισμικό σας είναι ασφαλές και θα διδάξετε στους προγραμματιστές σας ότι οφείλουν να αναλαμβάνουν και την ευθύνη για την ασφάλεια του κώδικα που αναπτύσσουν.
