# Διατήρηση των εξαρτήσεων ενημερωμένων: Composer, npm και πρόσθετα

> Πακέτα Composer, modules npm και πρόσθετα CMS ενημερωμένα: διαδικασία συντήρησης με ρυθμό, αρμοδιότητα, δοκιμές και σχέδιο για περιπτώσεις χωρίς patch.

Πηγή: https://phpsos.de/el/blog/abhaengigkeiten-aktuell-halten/  
Ημερομηνία: 25/10/2026  
Πάροχος: PHP SOS, Επείγουσα βοήθεια PHP και ασφάλεια διακομιστών. Άμεση βοήθεια μέσω WhatsApp: https://wa.me/491736494914?text=%CE%93%CE%B5%CE%B9%CE%B1%20%CF%83%CE%B1%CF%82%2C%20PHP%20SOS%2C%20%CF%87%CF%81%CE%B5%CE%B9%CE%B1%CE%B6%CF%8C%CE%BC%CE%B1%CF%83%CF%84%CE%B5%20%CE%B2%CE%BF%CE%AE%CE%B8%CE%B5%CE%B9%CE%B1%20%CE%BC%CE%B5%20%CF%84%CE%BF%CE%BD%20%CE%B4%CE%B9%CE%B1%CE%BA%CE%BF%CE%BC%CE%B9%CF%83%CF%84%CE%AE%20PHP%20%CE%BC%CE%B1%CF%82.%20%CE%95%CF%84%CE%B1%CE%B9%CF%81%CE%B5%CE%AF%CE%B1%3A%20%E2%80%A6%20%CE%99%CF%83%CF%84%CF%8C%CF%84%CE%BF%CF%80%CE%BF%CF%82%3A%20%E2%80%A6

**Εν ολίγοις:** Όποιος θέλει να ενημερώνει εξαρτήσεις, χρειάζεται μια διαδικασία για τρεις κόσμους πακέτων: πακέτα Composer στον κώδικα PHP, modules npm στο build του frontend και πρόσθετα ή θέματα στο CMS. Σε αυτήν ανήκουν ένας σταθερός ρυθμός, ένα υπεύθυνο πρόσωπο, δοκιμές πριν από την ανάπτυξη και ένα σχέδιο για πακέτα χωρίς ενημέρωση. Απέναντι στο PHP2Shell αυτό δεν βοηθά, γιατί η ευπάθεια βρίσκεται στην ίδια την PHP, βοηθά όμως απέναντι στις πολλές ευπάθειες σε ξένο κώδικα.

## Τρεις κόσμοι πακέτων, ένα τυφλό σημείο

Την εβδομάδα μετά τις 21/10/2026 όλα περιστρέφονταν γύρω από τον διερμηνέα PHP. Πολλές ομάδες διαπίστωσαν τότε ότι δεν γνωρίζουν με ακρίβεια τις εκδόσεις των δικών τους δομικών στοιχείων. Ο ιστότοπος λειτουργεί, το πρακτορείο τον φροντίζει, το πρόσθετο ειδοποιεί μόνο του όταν υπάρχει κάτι νέο: με αυτές ή παρόμοιες παραδοχές ζουν όλοι, μέχρι να ελέγξει κάποιος.

Ένα τυπικό έργο PHP αποτελείται σήμερα από σαφώς περισσότερο ξένο παρά δικό του κώδικα. Το OWASP Top 10 αναφέρει τα ευάλωτα και παρωχημένα στοιχεία ως ξεχωριστή κατηγορία κινδύνου. Το πρόβλημα σπάνια είναι το εργαλείο που λείπει, αλλά η ρουτίνα που λείπει: οι ενημερώσεις γίνονται όταν κάποιος έχει χρόνο και οι ειδοποιήσεις ασφαλείας καταλήγουν σε ένα γραμματοκιβώτιο που κανείς δεν διαβάζει.

## Ποιες εξαρτήσεις ενημερώνετε πού;

Κάθε κόσμος πακέτων έχει δικά του εργαλεία και δικές του παγίδες. Η παρακάτω επισκόπηση βοηθά να μη χαθεί τίποτα.

| Κόσμος πακέτων | Εμφάνιση αποθέματος | Έλεγχος ευπαθειών | Τυπική παγίδα |
|---|---|---|---|
| Composer (βιβλιοθήκες PHP) | `composer show` | `composer audit` | έμμεσα πακέτα που κανείς δεν γνωρίζει |
| npm (build του frontend) | `npm ls` | `npm audit` | Μια ενημέρωση χωρίς νέο build δεν φτάνει ποτέ στον διακομιστή |
| Πρόσθετα και θέματα CMS | Διεπαφή διαχείρισης ή CLI | υποδείξεις κατασκευαστών, υπηρεσίες ασφαλείας | εγκαταλελειμμένα πρόσθετα, πρόσθετα επί πληρωμή χωρίς κανάλι ενημερώσεων |
| PHP και επεκτάσεις | Διαχείριση πακέτων | Security tracker της διανομής | η έκδοση που εμφανίζεται λέει λίγα για backports |

Η τελευταία γραμμή δεν ανήκει αυστηρά στις εξαρτήσεις της εφαρμογής, ξεχνιέται όμως συχνά στην ίδια ανάσα. Το ίδιο ισχύει για σενάρια που ενσωματώνονται απευθείας από ξένους διακομιστές, όπως βιβλιοθήκες από ένα CDN, widgets συνομιλίας ή κώδικας παρακολούθησης. Δεν εμφανίζονται σε κανένα lock αρχείο, εκτελούνται όμως στον browser των επισκεπτών σας. Συμπεριλάβετέ τα στη λίστα και ελέγξτε αν ενσωματώνονται σταθερές εκδόσεις αντί για «πάντα η νεότερη». Οι λεπτομέρειες για το `composer audit`, το lock αρχείο και την ενσωμάτωση στο build βρίσκονται στον οδηγό [Έλεγχος των εξαρτήσεων Composer για ευπάθειες](https://phpsos.de/el/ratgeber/composer-abhaengigkeiten-pruefen/). Πώς λειτουργεί εν γένει το Composer, εξηγεί το [Composer: ο διαχειριστής πακέτων για την PHP](https://phpsos.de/el/php/composer/).

## Ο κύκλος συντήρησης σε έξι βήματα

Μια βιώσιμη διαδικασία δεν χρειάζεται να είναι περίπλοκη. Αυτή η σειρά έχει αποδειχθεί αποτελεσματική:

1. **Καταγραφή αποθέματος:** Για κάθε έργο μια λίστα των άμεσων εξαρτήσεων με έκδοση, προέλευση και σκοπό. Τα lock αρχεία (`composer.lock`, `package-lock.json`) ανήκουν στο αποθετήριο.
2. **Συλλογή ειδοποιήσεων:** Τα εργαλεία ελέγχου εκτελούνται σε κάθε build και επιπλέον τακτικά στην παραδιδόμενη κατάσταση, ακόμη και χωρίς αλλαγή κώδικα.
3. **Αξιολόγηση:** Χρησιμοποιείται το επηρεαζόμενο πακέτο στην παραγωγή, είναι προσβάσιμη η επηρεαζόμενη λειτουργία, υπάρχει διορθωμένη έκδοση;
4. **Ενημέρωση και δοκιμή στο staging:** Πρώτα ενημερώσεις ασφαλείας εντός της ίδιας κύριας έκδοσης, τα άλματα σε νέες κύριες εκδόσεις ως ξεχωριστό έργο.
5. **Ανάπτυξη με δρόμο επιστροφής:** Η προηγούμενη κατάσταση παραμένει διαθέσιμη ως πακέτο ή release, αντίγραφο της βάσης δεδομένων πριν από την ενημέρωση.
6. **Τεκμηρίωση:** Τι ενημερώθηκε πότε, τι όχι συνειδητά και γιατί.

Προσέξτε εδώ τις δηλώσεις εκδόσεων στα `composer.json` και `package.json`. Πολύ στενές προδιαγραφές εμποδίζουν να εγκατασταθούν καν οι διορθώσεις ασφαλείας. Πολύ ευρείες φέρνουν αντίθετα στο έργο, χωρίς έλεγχο, νέες κύριες εκδόσεις. Έχει αποδειχθεί χρήσιμο να επιτρέπονται ενημερώσεις εντός της κύριας έκδοσης και να σχεδιάζεται συνειδητά το άλμα στην επόμενη.

Για πρόσθετα σε CMS οι διαθέσιμες ενημερώσεις εμφανίζονται συχνά και στη γραμμή εντολών, στο WordPress για παράδειγμα με το WP-CLI:

```bash
# Εμφάνιση διαθέσιμων ενημερώσεων, χωρίς να αλλάξει κάτι
wp plugin list --update=available
wp theme list --update=available
# Πακέτα frontend: παρωχημένες εκδόσεις και γνωστές ευπάθειες
npm outdated
npm audit --omit=dev
```

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

## Όταν δεν υπάρχει ενημέρωση

Δεν λύνεται κάθε ειδοποίηση με ένα κλικ. Το OWASP Cheat Sheet για τον χειρισμό ευάλωτων εξαρτήσεων διακρίνει περισσότερες περιπτώσεις, που μεταφέρονται καλά στην καθημερινότητα:

- **Διαθέσιμο patch:** εγκατάσταση στο staging, δοκιμή, ανάπτυξη. Αν κάτι χαλάσει, προσαρμόστε τον δικό σας κώδικα αντί να αφήσετε την ενημέρωση στην άκρη.
- **Patch ανακοινωμένο, αλλά δεν υπάρχει ακόμη:** εφαρμογή της προσωρινής λύσης του κατασκευαστή, απενεργοποίηση ή απομόνωση της επηρεαζόμενης λειτουργίας αν είναι δυνατό, καταγραφή της απόφασης.
- **Δεν αναμένεται patch:** αναζήτηση πακέτου αντικατάστασης ή οπισθοδρομική μεταφορά (backport) της διόρθωσης από εσάς, με δοκιμή που διακρίνει την ευπάθεια πριν και μετά το patch.

Στα πρόσθετα CMS προκύπτει συχνά και μια τέταρτη περίπτωση: το πρόσθετο έχει εγκαταλειφθεί. Τότε βοηθά μόνο η αντικατάσταση ή η αφαίρεση. Το ίδιο ισχύει για πρόσθετα από ασαφείς πηγές, για παράδειγμα «δωρεάν» αντίγραφα πρόσθετων επί πληρωμή. Δεν λαμβάνουν ενημερώσεις μέσω του επίσημου καναλιού και περιέχουν όχι σπάνια οι ίδιοι κακόβουλο κώδικα. Υποδείξεις για χειριστές WordPress συγκεντρώνει το [WordPress και PHP2Shell](https://phpsos.de/el/plattformen/wordpress/).

## Ξεκαθαρίστε την αρμοδιότητα προτού έρθει η επόμενη ειδοποίηση

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

Προγραμματίστε επιπλέον χρόνο. Μια σταθερή ημερομηνία συντήρησης τον μήνα, όπου οι εξαρτήσεις ελέγχονται και ενημερώνονται, εμποδίζει τη συσσώρευση ενημερώσεων επί χρόνια. Όσο περισσότερο καιρό δεν ενημερώνεται ένα έργο, τόσο μεγαλύτερο και επικίνδυνο γίνεται το επόμενο άλμα. Πώς εντάσσονται οι ενημερώσεις της PHP και των πακέτων σε μια συνολική διαδικασία, περιγράφει το [Διαχείριση ενημερώσεων ως διαδικασία και όχι ως πυροσβεστική](https://phpsos.de/el/blog/patch-management-prozess/).

## Πώς βοηθά συγκεκριμένα η PHP SOS;

- Καταγράφουμε όλες τις εξαρτήσεις των έργων σας από Composer, npm και CMS και επισημαίνουμε παρωχημένα, ευάλωτα και εγκαταλελειμμένα πακέτα.
- Στήνουμε αυτόματους ελέγχους και ορίζουμε ποιος αξιολογεί ποια ειδοποίηση.
- Ενημερώνουμε στο staging, δοκιμάζουμε τις σημαντικότερες διαδικασίες και αναπτύσσουμε με δρόμο επιστροφής.
- Στο πλαίσιο μιας [σύμβασης συντήρησης ασφαλείας](https://phpsos.de/el/leistungen/security-wartungsvertrag/) αναλαμβάνουμε μόνιμα τον μηνιαίο κύκλο, συμπεριλαμβανομένων των ενημερώσεων PHP.

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


## Συχνές ερωτήσεις

**Πόσο συχνά πρέπει να ενημερώνονται οι εξαρτήσεις;**  
Οι ενημερώσεις ασφαλείας το συντομότερο δυνατό μετά την αξιολόγηση, οι ρουτίνας με σταθερό ρυθμό, για παράδειγμα μηνιαία. Σημαντικότερο από την ακριβή συχνότητα είναι να έχει οριστεί η ημερομηνία και να είναι κάποιος υπεύθυνος γι' αυτήν.

**Προστατεύει ένα ενημερωμένο πρόσθετο από το PHP2Shell;**  
Όχι. Το PHP2Shell βρίσκεται στον ίδιο τον διερμηνέα PHP. Απέναντι σε αυτό βοηθά μόνο μια ενημέρωση της PHP με επανεκκίνηση όλων των διεργασιών PHP. Τα ενημερωμένα πρόσθετα και πακέτα είναι παρ' όλα αυτά σημαντικά, επειδή κλείνουν δικές τους ευπάθειες.

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

**Πρέπει το frontend με npm να ενημερώνεται και στον διακομιστή;**  
Συχνά τα πακέτα npm υπάρχουν μόνο στο build και καταλήγουν ως έτοιμα αρχεία στον διακομιστή. Μια ευπάθεια σε ένα πακέτο μπορεί παρ' όλα αυτά να βρίσκεται στη JavaScript που παραδίδεται. Μετά από μια ενημέρωση πρέπει γι' αυτό να γίνει νέο build και νέα παράδοση.

## Πηγές

- [OWASP: Vulnerable Dependency Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [Composer](https://getcomposer.org/)
- [WordPress](https://wordpress.org/)