Επαληθεύστε τι μπαίνει στην έκδοση

Ρωτήστε αν η εξάρτηση χρειάζεται

Ένας agent μπορεί να προτείνει ένα πακέτο που φαίνεται να λύνει το πρόβλημα. Η σύσταση είναι πρόταση, όχι απόδειξη ότι το πακέτο υπάρχει ή είναι κατάλληλο. Επαληθεύστε το ακριβές registry, τον εκδότη, το όνομα πακέτου και την έκδοση πριν από την εγκατάσταση.

Για μια πλασματική εξαγωγή CSV, το runtime μπορεί ήδη να παρέχει την απαιτούμενη συμπεριφορά. Ένα νέο πακέτο μπορεί και πάλι να είναι κατάλληλο, αλλά προσθέτει συντήρηση και διαδρομές εκτέλεσης. Συγκρίνετε την προσπάθεια υλοποίησης με τις διαρκείς ευθύνες της εξάρτησης.

Εξετάστε την άδεια χρήσης και το υποστηριζόμενο runtime. Ελέγξτε τη δραστηριότητα συντήρησης και τις σχετικές ανακοινώσεις ασφάλειας. Ένα γνωστό όνομα μπορεί να αναφέρεται σε διαφορετικό πακέτο σε άλλο registry. Μια επιτυχής εγκατάσταση δείχνει μόνο ότι η εγκατάσταση ολοκληρώθηκε.

Εξετάστε τη συμπεριφορά εγκατάστασης και build

Οι εξαρτήσεις μπορούν να εκτελούν κώδικα κατά την εγκατάσταση ή το build. Περιορίστε τα διαπιστευτήρια και την πρόσβαση δικτύου σε αυτά τα περιβάλλοντα. Μην εκθέτετε μυστικά παραγωγής σε εργασία που επεξεργάζεται μη έμπιστο pull request.

Χρησιμοποιήστε lockfile που έχει αποθηκευτεί σε commit, όπου το οικοσύστημα το υποστηρίζει. Απαιτήστε το build να τηρεί αυτό το αρχείο. Εξετάστε τις αλλαγές του lockfile μαζί με την αλλαγή πηγαίου κώδικα, συμπεριλαμβανομένων μη αναμενόμενων μεταβατικών εξαρτήσεων. Το κλείδωμα εκδόσεων βελτιώνει την αναπαραγωγιμότητα, αλλά δεν κάνει μια ευάλωτη έκδοση ασφαλή.

Το SSDF του NIST καλύπτει την προστασία λογισμικού και τις πρακτικές ανάπτυξης σε όλο τον κύκλο ζωής. Χρησιμοποιήστε αυτή την ευρύτερη οπτική όταν σχεδιάζετε το περιβάλλον build. Διαβάστε το πλαίσιο.

Διακρίνετε την απογραφή από την προέλευση

Ένα software bill of materials, ή SBOM, καταγράφει τα συστατικά του λογισμικού. Σας βοηθά να εντοπίσετε τις επηρεαζόμενες εκδόσεις όταν ένα συστατικό δημιουργεί ανησυχία. Δεν αποδεικνύει ανεξάρτητα ότι τα συστατικά είναι ασφαλή.

Η προέλευση, ή provenance, αφορά το πώς παρήχθη ένα artifact. Το SLSA ορίζει μια μορφή provenance για πληροφορίες σχετικά με το build και τις εισόδους του. Η επαλήθευση πρέπει να συνδέει αυτές τις πληροφορίες με έναν έμπιστο παραγωγό και το artifact που σκοπεύετε να χρησιμοποιήσετε. Ένα αρχείο με όνομα «provenance» δεν αρκεί. SLSA provenance.

Για την υπηρεσία εξαγωγής, καταγράψτε μια αλυσίδα που μπορείτε να εξετάσετε:

1. Το ανασκοπημένο commit προσδιορίζει τον αποδεκτό πηγαίο κώδικα.
2. Το build προσδιορίζει τις εισόδους και το περιβάλλον εκτέλεσής του.
3. Το artifact έχει σταθερό κρυπτογραφικό αποτύπωμα.
4. Οι έλεγχοι προσδιορίζουν το artifact ή τον πηγαίο κώδικα που εξέτασαν.
5. Το deployment καταγράφει το artifact που τοποθετήθηκε στο περιβάλλον-στόχο.

Αποφύγετε διαφορετικό rebuild μετά την έγκριση χωρίς καθορισμένη διαδικασία επαλήθευσης. Ένα μεταβλητό tag όπως το latest μπορεί αργότερα να αναφέρεται σε διαφορετικό image.

Αποφασίστε τι σημαίνει ένα εύρημα

Ένα εύρημα ευπάθειας χρειάζεται πλαίσιο: την επηρεαζόμενη έκδοση, τη συμπεριφορά που μπορεί να εκτελεστεί, την έκθεση, τη διαθέσιμη διόρθωση και τη συνέπεια. Καταγράψτε τα αποδεικτικά στοιχεία πίσω από κάθε προσωρινή εξαίρεση. Ορίστε υπεύθυνο, λήξη και έναυσμα επανεξέτασης.

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

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

Συνεχίστε με τη συνεχή διαχείριση ευπαθειών για να συνδέσετε τις επαναλαμβανόμενες σαρώσεις με επαληθευμένες διορθώσεις στην παραγωγή.