Ως εταιρεία λογισμικού, λαμβάνετε όλο και περισσότερο έναν κατάλογο ελέγχου ασφάλειας από έναν πελάτη που υπόκειται στον Νόμο περί Ασφάλειας Πληροφοριών και Επικοινωνιών. Ο ίδιος υpoχρέωση φροντίδας που υποχρεώνει τον πελάτη σας προς εσάς, σας υποχρεώνει και εσάς με τη σειρά σας: να αξιολογήσετε ποιοι από τους δικούς σας προμηθευτές έχουν επίδραση στην ασφάλεια αυτού που κτίζετε και παραδίδετε. Μια πολιτική προμηθευτών είναι ο τρόπος για να κάνετε επανάληψη αυτής της αξιολόγησης, αντί να επανασχεδιάζετε κάθε φορά ποιους στην πραγματικότητα εμπιστεύεστε.
Σύντομη απάντηση: ξεκινάτε με μια επισκόπηση ποιος βρίσκεται στη γραμμή παραγωγής σας και στο παραδιδόμενο λογισμικό σας, χωρίζετε αυτούς τους προμηθευτές κατά το ρίσκο που αποτελούν, και καθορίζετε ανά κατηγορία ποιες απαιτήσεις θέτετε και πώς το ελέγχετε. Αυτή η επισκόπηση και αυτή η κατηγοριοποίηση σχηματίζουν μαζί την πολιτική προμηθευτών.
Δύο τύποι προμηθευτών, ένα τυφλό σημείο
Στην ανάπτυξη λογισμικού, δύο αλυσίδες τρέχουν μέσα, και αυτό κάνει μια πολιτική προμηθευτών πιο περίπλοκη από ό,τι σε μια εταιρεία που αγοράζει μόνο φυσικά αγαθά.
Η πρώτη αλυσίδα είναι η γραμμή παραγωγής σας: ο διαχειριστής κωδικού πηγής, ο αγωγός CI/CD, το περιβάλλον cloud όπου δημιουργείτε, τα εργαλεία για δοκιμές και ανάπτυξη. Ένα αδύναμο σημείο εκεί επηρεάζει κατά πρώτον τις δικές σας επιχειρηματικές δραστηριότητες.
Η δεύτερη αλυσίδα είναι αυτό που καταλήγει στο προϊόν σας: βιβλιοθήκες ανοιχτού κώδικα, API τρίτων κατασκευαστών, αγορασμένα στοιχεία. Ένα αδύναμο σημείο εκεί δεν σας επηρεάζει μόνο εσάς, αλλά και κάθε πελάτη που χρησιμοποιεί το λογισμικό σας. Αυτή η διάκριση είναι ακριβώς το μέρος όπου πολλές πολιτικές προμηθευτών δεν επαρκούν: η προσοχή κατευθύνεται προς την πρώτη αλυσίδα επειδή είναι ορατή στην καθημερινή εργασία, ενώ η δεύτερη αλυσίδα συχνά γίνεται ορατή μόνο όταν κάτι πάει στραβά.
Καταγραφή: ξεκινήστε από αυτό που ήδη τρέχει
Μια πολιτική προμηθευτών δεν ξεκινά με ένα πρότυπο, αλλά με μια λίστα. Για την ανάπτυξη λογισμικού, αυτό σημαίνει τουλάχιστον: ποιες υπηρεσίες cloud χρησιμοποιείτε, ποιοι διαχειριστές πακέτων και μητρώα που ανιχνεύει η διαδικασία κατασκευής σας, ποια εξωτερικά API καλεί το προϊόν σας, και ποιες από αυτές τις κατασκευές έχουν πρόσβαση σε κώδικα, μυστικά ή δεδομένα παραγωγής.
Για κάθε προμηθευτή, το ερώτημα δεν είναι μόνο τι κάνουν, αλλά τι συμβαίνει αν αποτύχουν ή παραβιαστούν. Ένας διαχειριστής πακέτων από τον οποίο προέρχονται εκατοντάδες εξαρτήσεις ζυγίζει διαφορετικά από ένα πακέτο τιμολόγησης που λειτουργεί ανεξάρτητα από τη γραμμή παραγωγής.
Κατηγοριοποίηση ρίσκου: όχι κάθε προμηθευτής αξίζει την ίδια προσοχή
Μετά την καταγραφή ακολουθεί μια κατηγοριοποίηση, συνήθως σε δύο ή τρεις επίπεδα. Οι προμηθευτές με πρόσβαση σε κώδικα πηγής, μυστικά ή περιβάλλοντα παραγωγής απαιτούν τις πιο αυστηρές απαιτήσεις: ισχυρή ταυτοποίηση, καταγραφή, ένα σταθερό σημείο επαφής σε περίπτωση περιστατικού. Οι προμηθευτές που συμβάλλουν μόνο έμμεσα, όπως ένα εργαλείο για διαχείριση έργων, απαιτούν λιγότερα.
Η Richtlijn και ο εθνικός νόμος δεν ορίζουν μια σταθερή κατηγοριοποίηση· οι εποπτικές αρχές εξετάζουν σε αυτό εάν τα μέτρα είναι ανάλογα προς το ρίσκο. Αυτό σημαίνει ότι η κατηγοριοποίηση που επιλέγετε πρέπει να δικαιολογείται: γιατί αυτός ο προμηθευτής εμπίπτει στη βαριά κατηγορία και εκείνος όχι.
Τι ζητάτε, και τι απαντάτε ήδη οι ίδιοι
Μια πολιτική προμηθευτών δουλεύει προς δύο κατευθύνσεις. Προς τα έξω, το χρησιμοποιείτε για να θέσετε ερωτήσεις στους δικούς σας προμηθευτές: πώς αντιμετωπίζουν τις ευπάθειες, έχουν διαδικασία για τη δευτερογενή επαλήθευση, πόσο γρήγορα σας ανακοινώνουν ένα περιστατικό. Προς τα μέσα, αποτελεί τη βάση για αυτό που ξανά απαντάτε στους καταλόγους ελέγχου των πελατών σας, διότι ένας πελάτης που σας αξιολογεί θέλει συχνά να γνωρίζει αν έχετε τη δική σας αλυσίδα υπό έλεγχο.
Οι δύο πλευρές συνδέονται: μια πολιτική προμηθευτών που συντάσσετε μόνο για δικό σας λογαριασμό συνήθως δεν ταιριάζει με τις ερωτήσεις που λαμβάνετε από πελάτες. Όποιος θέσει την πολιτική από την αρχή έχοντας κατά νου αυτό που ζητά ένας αγοραστής, δεν χρειάζεται να την ξαναγράψει αργότερα.
Τεκμηρίωση: από την πολιτική στο απόδειξη
Μια πολιτική που υπάρχει μόνο σε ένα έγγραφο κειμένου είναι δύσκολο να τεκμηριωθεί τη στιγμή που ένας πελάτης ή αρχή ρύθμισης το ζητά. Πιο πρακτικό είναι ένα ζωντανό επιτόπιο: ανά προμηθευτή την κατηγορία κινδύνου, την τελευταία αξιολόγηση, το απόδειξη όπως δήλωση, πιστοποίηση ή απάντηση στη δική σας ερωτηματολόγιο, και ποιος στην οργάνωσή σας παρακολουθεί τον προμηθευτή αυτόν.
Ένα τέτοιο επιτόπιο δεν χρειάζεται να είναι μεγάλο για να είναι χρήσιμο. Για μια εταιρεία λογισμικού με μια χούφτα κρίσιμους προμηθευτές, ένας πίνακας με μερικές στήλες είναι συχνά αρκετός, υπό την προϋπόθεση ότι παραμένει ενήμερος όταν αλλάζει ένας προμηθευτής ή ένα συμβόλαιο ανανεώνεται.
Θέλετε πρώτα να μάθετε αν η οργάνωσή σας πέφτει και η ίδια κάτω από την υποχρέωση, ή μόνο μέσω των πελατών σας; κάντε τον δωρεάν έλεγχο σε λίγες ερωτήσεις και διαβάστε στη σελίδα με όλα τα θέματα πώς η αξιολόγηση προμηθευτών σχετίζεται με τις άλλες υποχρεώσεις. Περίεργο πού προέρχονται οι πληροφορίες σε αυτή την πλατφόρμα και πόσο ενήμερες είναι; Αυτό εξηγείται στη τη σελίδα που εξηγεί πώς λειτουργεί. Όποιος θέλει να μετατρέψει το επιτόπιο προμηθευτών σε ένα δοσιέ με αποδείξεις και ιδιοκτήτες, θα βρει στη σελίδα με τα σχέδια συνδρομής τι χρειάζεται γι' αυτό.