Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md']

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Μεθοδολογία
+# Μεθοδολογία Pentesting CI/CD
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,51 +6,51 @@
 
 ## VCS
 
-VCS σημαίνει **Σύστημα Ελέγχου Εκδόσεων (Version Control System)**, αυτό το σύστημα επιτρέπει στους προγραμματιστές να **διαχειρίζονται τον πηγαίο κώδικα τους**. Ο πιο κοινός είναι **git** και συνήθως θα βρείτε εταιρείες να το χρησιμοποιούν σε μία από τις ακόλουθες **πλατφόρμες**:
+Το VCS σημαίνει **Version Control System**, αυτά τα συστήματα επιτρέπουν στους developers να **διαχειρίζονται τον source code τους**. Το πιο συνηθισμένο είναι το **git** και συνήθως θα βρείτε εταιρείες να το χρησιμοποιούν σε μία από τις ακόλουθες **platforms**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (they offer their own VCS platforms)
+- Cloud providers (προσφέρουν τις δικές τους VCS platforms)
 
 
 ## CI/CD Pipelines
 
-Τα CI/CD pipelines επιτρέπουν στους προγραμματιστές να **αυτοματοποιούν την εκτέλεση κώδικα** για διάφορους σκοπούς, συμπεριλαμβανομένου του build, των tests και της ανάπτυξης εφαρμογών. Αυτά τα αυτοματοποιημένα workflows **ενεργοποιούνται από συγκεκριμένες ενέργειες**, όπως code pushes, pull requests ή προγραμματισμένες εργασίες. Είναι χρήσιμα για να απλοποιούν τη διαδικασία από το development μέχρι το production.
+Τα CI/CD pipelines επιτρέπουν στους developers να **αυτοματοποιούν την εκτέλεση code** για διάφορους σκοπούς, συμπεριλαμβανομένων του build, του testing και του deploying applications. Αυτά τα automated workflows **ενεργοποιούνται από συγκεκριμένες ενέργειες**, όπως code pushes, pull requests ή scheduled tasks. Είναι χρήσιμα για τον εξορθολογισμό της διαδικασίας από development σε production.
 
-Ωστόσο, αυτά τα συστήματα πρέπει να **εκτελούνται κάπου** και συνήθως με **privileged credentials για να deploy-άρουν κώδικα ή να έχουν πρόσβαση σε sensitive information**.
+Ωστόσο, αυτά τα συστήματα πρέπει να **εκτελούνται κάπου** και συνήθως με **privileged credentials για να κάνουν deploy code ή να αποκτούν πρόσβαση σε sensitive information**.
 
-## VCS Pentesting Μεθοδολογία
+## VCS Pentesting Methodology
 
 > [!NOTE]
-> Ακόμα κι αν μερικές VCS πλατφόρμες επιτρέπουν τη δημιουργία pipelines, σε αυτή την ενότητα θα αναλύσουμε μόνο πιθανούς επιθέσεις στον έλεγχο του πηγαίου κώδικα.
+> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
 
-Οι πλατφόρμες που περιέχουν τον πηγαίο κώδικα του έργου σας περιέχουν ευαίσθητες πληροφορίες και πρέπει να είστε πολύ προσεκτικοί με τα permissions που δίνονται μέσα σε αυτή την πλατφόρμα. Αυτά είναι μερικά κοινά προβλήματα στις VCS πλατφόρμες που ένας attacker θα μπορούσε να εκμεταλλευτεί:
+Οι platforms που περιέχουν τον source code του project σας περιέχουν sensitive information και οι άνθρωποι πρέπει να είναι πολύ προσεκτικοί με τα permissions που δίνονται μέσα σε αυτή την platform. Αυτά είναι μερικά συνηθισμένα προβλήματα σε VCS platforms που ένας attacker θα μπορούσε να εκμεταλλευτεί:
 
-- **Leaks**: Αν ο κώδικάς σας περιέχει leaks στα commits και ο attacker μπορεί να έχει πρόσβαση στο repo (επειδή είναι public ή επειδή έχει πρόσβαση), θα μπορούσε να ανακαλύψει αυτά τα leaks.
-- **Access**: Αν ένας attacker μπορεί να **έχει πρόσβαση σε έναν λογαριασμό μέσα στην VCS platform** θα μπορούσε να αποκτήσει **μεγαλύτερη ορατότητα και permissions**.
-- **Register**: Κάποιες πλατφόρμες απλά επιτρέπουν σε εξωτερικούς χρήστες να δημιουργήσουν account.
-- **SSO**: Κάποιες πλατφόρμες δεν επιτρέπουν registration, αλλά επιτρέπουν σε οποιονδήποτε να μπει με έγκυρο SSO (οπότε ένας attacker θα μπορούσε να χρησιμοποιήσει το github account του για παράδειγμα).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... υπάρχουν διάφοροι τύποι tokens που ένας χρήστης θα μπορούσε να κλέψει για να αποκτήσει με κάποιον τρόπο πρόσβαση σε ένα repo.
-- **Webhooks**: Οι VCS πλατφόρμες επιτρέπουν τη δημιουργία webhooks. Αν δεν είναι **προστατευμένα** με μη ορατά secrets ένας **attacker θα μπορούσε να τα εκμεταλλευτεί**.
-- Αν δεν υπάρχει κάποιο secret, ο attacker θα μπορούσε να εκμεταλλευτεί το webhook της τρίτης πλατφόρμας
-- Αν το secret είναι στο URL, το ίδιο συμβαίνει και ο attacker αποκτά επίσης το secret
-- **Code compromise:** Αν ένας κακόβουλος actor έχει κάποιο είδος **write** πρόσβασης πάνω στα repos, θα μπορούσε να προσπαθήσει να **inject malicious code**. Για να έχει επιτυχία ίσως χρειαστεί να **bypass branch protections**. Αυτές οι ενέργειες μπορούν να γίνουν με διαφορετικούς στόχους στη μέση:
-  - Compromise the main branch to **compromise production**.
-  - Compromise the main (or other branches) to **compromise developers machines** (καθώς συνήθως εκτελούν tests, terraform ή άλλα πράγματα μέσα στο repo στους υπολογιστές τους).
-- **Compromise the pipeline** (check next section)
+- **Leaks**: Αν ο code σας περιέχει leaks στα commits και ο attacker μπορεί να αποκτήσει πρόσβαση στο repo (επειδή είναι public ή επειδή έχει πρόσβαση), μπορεί να ανακαλύψει τα leaks.
+- **Access**: Αν ένας attacker μπορεί να **αποκτήσει πρόσβαση σε έναν account μέσα στην VCS platform** μπορεί να αποκτήσει **περισσότερη ορατότητα και permissions**.
+- **Register**: Ορισμένες platforms θα επιτρέπουν απλώς σε external users να δημιουργήσουν έναν account.
+- **SSO**: Ορισμένες platforms δεν θα επιτρέπουν στους users να κάνουν register, αλλά θα επιτρέπουν σε οποιονδήποτε να αποκτήσει πρόσβαση με ένα valid SSO (οπότε ένας attacker θα μπορούσε να χρησιμοποιήσει για παράδειγμα τον github account του για να μπει).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... υπάρχουν αρκετοί τύποι tokens που ένας user θα μπορούσε να κλέψει για να αποκτήσει με κάποιο τρόπο πρόσβαση σε ένα repo.
+- **Webhooks**: Οι VCS platforms επιτρέπουν τη δημιουργία webhooks. Αν δεν είναι **protected** με μη ορατά secrets, ένας **attacker θα μπορούσε να τα εκμεταλλευτεί**.
+- Αν δεν υπάρχει secret, ο attacker θα μπορούσε να εκμεταλλευτεί το webhook της third party platform
+- Αν το secret βρίσκεται στο URL, συμβαίνει το ίδιο και ο attacker έχει επίσης το secret
+- **Code compromise:** Αν ένας malicious actor έχει κάποιο είδος **write** access στα repos, θα μπορούσε να προσπαθήσει να **εισάγει malicious code**. Για να είναι επιτυχής ίσως χρειαστεί να **παρακάμψει branch protections**. Αυτές οι ενέργειες μπορούν να γίνουν με διαφορετικούς στόχους στο μυαλό:
+- Compromise το main branch για να **compromise production**.
+- Compromise το main (ή άλλα branches) για να **compromise developers machines** (καθώς συνήθως εκτελούν test, terraform ή άλλα πράγματα μέσα στο repo στις μηχανές τους).
+- **Compromise the pipeline** (δείτε την επόμενη ενότητα)
 
-## Pipelines Pentesting Μεθοδολογία
+## Pipelines Pentesting Methodology
 
-Ο πιο κοινός τρόπος να οριστεί ένα pipeline είναι με τη χρήση ενός **CI configuration file που φιλοξενείται στο repository** που το pipeline θα χτίσει. Αυτό το αρχείο περιγράφει τη σειρά των jobs που θα εκτελεστούν, τις συνθήκες που επηρεάζουν τη ροή και τις ρυθμίσεις του περιβάλλοντος build.\
-Αυτά τα αρχεία συνήθως έχουν ένα σταθερό όνομα και format, για παράδειγμα — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) και τα GitHub Actions YAML αρχεία που βρίσκονται κάτω από .github/workflows. Όταν ενεργοποιηθεί, το pipeline job **τραβάει τον κώδικα** από την επιλεγμένη πηγή (π.χ. commit / branch), και **εκτελεί τις εντολές που καθορίζονται στο CI configuration file** πάνω σε αυτόν τον κώδικα.
+Ο πιο συνηθισμένος τρόπος για να οριστεί ένα pipeline είναι με τη χρήση ενός **CI configuration file hosted στο repository** που χτίζει το pipeline. Αυτό το αρχείο περιγράφει τη σειρά των jobs που εκτελούνται, τις conditions που επηρεάζουν τη ροή και τις ρυθμίσεις του build environment.\
+Αυτά τα αρχεία συνήθως έχουν σταθερό όνομα και format, για παράδειγμα — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) και τα GitHub Actions YAML files που βρίσκονται κάτω από .github/workflows. Όταν ενεργοποιηθεί, το pipeline job **pulls the code** από την επιλεγμένη πηγή (π.χ. commit / branch) και **εκτελεί τις εντολές που καθορίζονται στο CI configuration file** πάνω σε αυτό το code.
 
 Επομένως ο τελικός στόχος του attacker είναι με κάποιον τρόπο να **compromise αυτά τα configuration files** ή τις **εντολές που εκτελούν**.
 
 > [!TIP]
-> Κάποιοι hosted builders επιτρέπουν σε contributors να επιλέξουν το Docker build context και το Dockerfile path. Αν το context είναι υπό τον έλεγχο του attacker, μπορείτε να το ορίσετε εκτός του repo (π.χ., "..") για να εισάγετε αρχεία του host κατά τη διάρκεια του build και να εξάγετε secrets. Δείτε:
+> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,57 +58,78 @@ VCS σημαίνει **Σύστημα Ελέγχου Εκδόσεων (Version C
 
 ### PPE - Poisoned Pipeline Execution
 
-Η Poisoned Pipeline Execution (PPE) διαδρομή εκμεταλλεύεται permissions σε ένα SCM repository για να χειραγωγήσει ένα CI pipeline και να εκτελέσει κακόβουλες εντολές. Χρήστες με τα απαραίτητα permissions μπορούν να τροποποιήσουν CI configuration files ή άλλα αρχεία που χρησιμοποιεί το pipeline job για να συμπεριλάβουν κακόβουλες εντολές. Αυτό "δηλητηριάζει" το CI pipeline, οδηγώντας στην εκτέλεση αυτών των κακόβουλων εντολών.
+Το Poisoned Pipeline Execution (PPE) path εκμεταλλεύεται permissions σε ένα SCM repository για να χειραγωγήσει ένα CI pipeline και να εκτελέσει harmful commands. Users με τα απαραίτητα permissions μπορούν να τροποποιήσουν CI configuration files ή άλλα αρχεία που χρησιμοποιεί το pipeline job ώστε να περιέχουν malicious commands. Αυτό “poisons” το CI pipeline, οδηγώντας στην εκτέλεση αυτών των malicious commands.
 
-Για να έχει επιτυχία ένας malicious actor εκτελώντας μια PPE επίθεση χρειάζεται να μπορεί να:
+Για να είναι επιτυχής ένας malicious actor σε μια PPE attack χρειάζεται να μπορεί να:
 
-- Έχει **write access στο VCS platform**, καθώς συνήθως τα pipelines ενεργοποιούνται όταν γίνει push ή δημιουργηθεί pull request. (Δείτε τη VCS pentesting methodology για περίληψη των τρόπων απόκτησης πρόσβασης).
-- Σημειώστε ότι μερικές φορές ένα **external PR μετράει ως "write access"**.
-- Ακόμα κι αν έχει write permissions, πρέπει να είναι σίγουρος ότι μπορεί να **τροποποιήσει το CI config file ή άλλα αρχεία που το config βασίζεται**.
-- Για αυτό, ίσως χρειαστεί να είναι σε θέση να **bypass branch protections**.
+- Έχει **write access στο VCS platform**, καθώς συνήθως τα pipelines ενεργοποιούνται όταν γίνεται ένα push ή ένα pull request. (Δείτε τη VCS pentesting methodology για μια σύνοψη των τρόπων απόκτησης πρόσβασης).
+- Σημειώστε ότι μερικές φορές ένα **external PR count as "write access"**.
+- Ακόμη κι αν έχει write permissions, χρειάζεται να είναι βέβαιος ότι μπορεί να **τροποποιήσει το CI config file ή άλλα files στα οποία βασίζεται το config**.
+- Γι’ αυτό, ίσως χρειαστεί να μπορεί να **παρακάμψει branch protections**.
 
-Υπάρχουν 3 flavours της PPE:
+Υπάρχουν 3 PPE flavours:
 
-- **D-PPE**: Μια **Direct PPE** επίθεση συμβαίνει όταν ο actor **τροποποιεί το CI config** αρχείο που πρόκειται να εκτελεστεί.
-- **I-DDE**: Μια **Indirect PPE** επίθεση συμβαίνει όταν ο actor **τροποποιεί** ένα **αρχείο** από το οποίο το CI config αρχείο που πρόκειται να εκτελεστεί **εξαρτάται** (όπως ένα make file ή μια terraform config).
-- **Public PPE or 3PE**: Σε μερικές περιπτώσεις τα pipelines μπορούν να **ενεργοποιηθούν από χρήστες που δεν έχουν write access στο repo** (και που μπορεί να μην είναι καν μέλη της οργάνωσης) επειδή μπορούν να στείλουν ένα PR.
-- **3PE Command Injection**: Συνήθως, τα CI/CD pipelines θα **ορίζουν environment variables** με **πληροφορίες για το PR**. Αν αυτή η τιμή μπορεί να ελεγχθεί από έναν attacker (όπως ο τίτλος του PR) και **χρησιμοποιείται** σε ένα **επικίνδυνο σημείο** (όπως η εκτέλεση sh εντολών), ένας attacker μπορεί να **εγχχύσει εντολές εκεί**.
+- **D-PPE**: Μια **Direct PPE** attack συμβαίνει όταν ο actor **τροποποιεί το CI config** file που πρόκειται να εκτελεστεί.
+- **I-DDE**: Μια **Indirect PPE** attack συμβαίνει όταν ο actor **τροποποιεί** ένα **file** στο οποίο βασίζεται το CI config file που πρόκειται να εκτελεστεί **(like a make file or a terraform config)**.
+- **Public PPE or 3PE**: Σε ορισμένες περιπτώσεις τα pipelines μπορούν να **ενεργοποιηθούν από users που δεν έχουν write access στο repo** (και μπορεί να μην είναι καν μέρος του org) επειδή μπορούν να στείλουν ένα PR.
+- **3PE Command Injection**: Συνήθως, τα CI/CD pipelines θα **ορίσουν environment variables** με **information about the PR**. Αν αυτή η τιμή μπορεί να ελεγχθεί από έναν attacker (όπως ο τίτλος του PR) και **χρησιμοποιείται** σε **επικίνδυνο σημείο** (όπως η εκτέλεση **sh commands**), ένας attacker μπορεί να **εισάγει commands εκεί**.
 
 ### Exploitation Benefits
 
-Γνωρίζοντας τις 3 flavours για το poison ενός pipeline, ας δούμε τι θα μπορούσε να αποκτήσει ένας attacker μετά από μια επιτυχή εκμετάλλευση:
+Γνωρίζοντας τις 3 flavours για να poison ένα pipeline, ας δούμε τι θα μπορούσε να αποκτήσει ένας attacker μετά από επιτυχημένη exploitation:
 
-- **Secrets**: Όπως αναφέρθηκε προηγουμένως, τα pipelines απαιτούν **privileges** για τα jobs τους (retrieve the code, build it, deploy it...) και αυτά τα privileges συνήθως **παρέχονται ως secrets**. Αυτά τα secrets συνήθως είναι προσβάσιμα μέσω **env variables ή αρχείων μέσα στο σύστημα**. Επομένως ένας attacker θα προσπαθήσει πάντα να εξάγει όσο το δυνατόν περισσότερα secrets.
-- Ανάλογα με την πλατφόρμα του pipeline ο attacker **μπορεί να χρειαστεί να καθορίσει τα secrets στο config**. Αυτό σημαίνει ότι αν ο attacker δεν μπορεί να τροποποιήσει το CI configuration pipeline (**I-PPE** για παράδειγμα), θα μπορούσε **μόνο να εξάγει τα secrets που έχει εκείνο το pipeline**.
-- **Computation**: Ο κώδικας εκτελείται κάπου, ανάλογα με το πού εκτελείται ένας attacker μπορεί να μπορέσει να pivot-άρει περαιτέρω.
-- **On-Premises**: Αν τα pipelines εκτελούνται on-premises, ένας attacker μπορεί να βρεθεί σε ένα **εσωτερικό δίκτυο με πρόσβαση σε περισσότερους πόρους**.
-- **Cloud**: Ο attacker θα μπορούσε να αποκτήσει πρόσβαση **σε άλλες μηχανές στο cloud** αλλά και να **εξάγει** IAM roles/service accounts **tokens** από αυτό για να αποκτήσει **περαιτέρω πρόσβαση στο cloud**.
-- **Platforms machine**: Κάποιες φορές τα jobs θα εκτελούνται μέσα στις **μηχανές της πλατφόρμας pipelines**, οι οποίες συνήθως βρίσκονται σε ένα cloud χωρίς περαιτέρω πρόσβαση.
-- **Επιλογή εκτέλεσης:** Μερικές φορές η **πλατφόρμα pipelines θα έχει ρυθμίσει πολλές μηχανές** και αν μπορείτε να **τροποποιήσετε το CI configuration file** μπορείτε να **υποδείξετε που θέλετε να τρέξει ο κακόβουλος κώδικας**. Σε αυτή την περίπτωση, ένας attacker πιθανότατα θα τρέξει ένα reverse shell σε κάθε πιθανή μηχανή για να προσπαθήσει να την εκμεταλλευτεί περαιτέρω.
-- **Compromise production**: Αν είστε μέσα στο pipeline και η τελική έκδοση χτίζεται και deploy-άρεται από αυτό, μπορείτε να **compromise-άρετε τον κώδικα που θα τρέχει τελικά σε production**.
+- **Secrets**: Όπως αναφέρθηκε προηγουμένως, τα pipelines απαιτούν **privileges** για τα jobs τους (ανάκτηση του code, build του, deploy του...) και αυτά τα privileges συνήθως **δίνονται σε secrets**. Αυτά τα secrets είναι συνήθως προσβάσιμα μέσω **env variables ή files μέσα στο σύστημα**. Επομένως ένας attacker θα προσπαθεί πάντα να exfiltrate όσο το δυνατόν περισσότερα secrets.
+- Ανάλογα με την pipeline platform ο attacker **μπορεί να χρειάζεται να ορίσει τα secrets στο config**. Αυτό σημαίνει ότι αν ο attacker δεν μπορεί να τροποποιήσει το CI configuration pipeline (**I-PPE** για παράδειγμα), θα μπορούσε **μόνο να exfiltrate τα secrets που έχει αυτό το pipeline**.
+- **Computation**: Το code εκτελείται κάπου, ανάλογα με το πού εκτελείται ένας attacker μπορεί να μπορέσει να pivot further.
+- **On-Premises**: Αν τα pipelines εκτελούνται on premises, ένας attacker μπορεί να καταλήξει σε ένα **internal network με πρόσβαση σε περισσότερους πόρους**.
+- **Cloud**: Ο attacker θα μπορούσε να αποκτήσει πρόσβαση σε **other machines in the cloud** αλλά επίσης να **exfiltrate** IAM roles/service accounts **tokens** από αυτά για να αποκτήσει **further access inside the cloud**.
+- **Platforms machine**: Μερικές φορές τα jobs θα εκτελούνται μέσα στις **pipelines platform machines**, οι οποίες συνήθως βρίσκονται μέσα σε ένα cloud χωρίς **more access**.
+- **Select it:** Μερικές φορές η **pipelines platform θα έχει διαμορφώσει several machines** και αν μπορείτε να **τροποποιήσετε το CI configuration file** μπορείτε να **υποδείξετε πού θέλετε να τρέξει το malicious code**. Σε αυτή την περίπτωση, ένας attacker πιθανότατα θα τρέξει ένα reverse shell σε κάθε πιθανό machine για να προσπαθήσει να το εκμεταλλευτεί περαιτέρω.
+- **Compromise production**: Αν ήσασταν μέσα στο pipeline και η τελική έκδοση χτίζεται και γίνεται deploy από αυτό, θα μπορούσατε να **compromise το code που πρόκειται να καταλήξει να εκτελείται σε production**.
+
+### Dependency & Registry Supply-Chain Abuse
+
+Το να compromise ένα CI/CD pipeline ή να κλέψει credentials από αυτό μπορεί να επιτρέψει σε έναν attacker να μετακινηθεί από την **pipeline execution** σε **ecosystem-wide code execution** μέσω backdooring dependencies ή release tooling:
+
+- **Install-time code execution via package hooks**: publish μια package version που προσθέτει `preinstall`, `postinstall`, `prepare` ή παρόμοια hooks ώστε το payload να εκτελείται αυτόματα στα developer workstations και στους CI runners κατά την εγκατάσταση των dependencies.
+- **Secondary execution paths**: ακόμη κι αν οι targets εγκαθιστούν με `--ignore-scripts`, ένα malicious package μπορεί ακόμα να καταχωρίσει ένα **common CLI name** στο πεδίο `bin` ώστε το attacker-controlled wrapper να γίνει symlink στο `PATH` και να εκτελεστεί αργότερα όταν χρησιμοποιηθεί η εντολή.
+- **Runtime bootstrapping**: ένας μικρός installer μπορεί να κατεβάσει ένα δεύτερο runtime ή toolchain κατά την εγκατάσταση (για παράδειγμα Bun ή ένα packed interpreter) και μετά να εκκινήσει το main payload με αυτό, αποφεύγοντας τις τοπικές dependency requirements.
+- **Credential harvesting from build environments**: μόλις το code εκτελεστεί μέσα στο CI, ελέγξτε environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs και local tooling όπως `gh auth token`. Στο GitHub Actions, κοιτάξτε επίσης για runner-specific secrets και artifacts.
+- **Workflow injection with stolen GitHub tokens**: ένα token με **`repo` + `workflow`** permissions είναι αρκετό για να δημιουργήσει ένα branch, να κάνει commit ένα malicious file μέσα στο `.github/workflows/`, να το ενεργοποιήσει, να συλλέξει τα παραγόμενα artifacts/logs και μετά να διαγράψει το προσωρινό branch/workflow run για να μειώσει τα traces.
+- **Wormable registry propagation**: τα stolen npm tokens πρέπει να επαληθεύονται για permissions **publish** και αν παρακάμπτουν το 2FA. Αν ναι, απαριθμήστε writable packages, κατεβάστε τα tarballs τους, εισάγετε έναν loader όπως `setup.mjs`, ορίστε `preinstall` να τον εκτελεί, αυξήστε το patch version και republish. Αυτό μετατρέπει ένα CI compromise σε downstream auto-execution σε άλλα περιβάλλοντα.
+
+#### Practical checks during an assessment
+
+- Ελέγξτε το release automation για package-manager hooks που προστέθηκαν στο `package.json`, απρόσμενα `bin` entries ή version bumps που αλλάζουν μόνο το release artifact.
+- Ελέγξτε αν το CI αποθηκεύει long-lived registry credentials σε plaintext files όπως το `~/.npmrc` αντί να χρησιμοποιεί short-lived OIDC ή trusted publishing.
+- Επαληθεύστε αν GitHub tokens που είναι διαθέσιμα στο CI μπορούν να γράψουν workflow files ή να δημιουργήσουν branches/tags.
+- Αν υπάρχει υποψία για compromised package, επιθεωρήστε το published tarball και όχι μόνο το Git repository, επειδή ο malicious loader/runtime μπορεί να υπάρχει μόνο στο published artifact.
+- Αναζητήστε απρόσμενη package-manager execution μέσα στο CI όπως `npm install` αντί για `npm ci`, απρόσμενα Bun downloads/execution ή νέα workflow artifacts που δημιουργούνται από transient branches.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) είναι ένα open-source εργαλείο για auditing του software supply chain stack σας για συμμόρφωση ασφαλείας βασισμένο σε ένα νέο [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Το auditing εστιάζει στην ολόκληρη διαδικασία SDLC, όπου μπορεί να αποκαλύψει κινδύνους από το code time μέχρι το deploy time.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) είναι ένα open-source tool για auditing του software supply chain stack σας ως προς την ασφάλεια, βασισμένο σε ένα νέο [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Το auditing εστιάζει σε ολόκληρη τη διαδικασία SDLC, όπου μπορεί να αποκαλύψει risks από code time έως deploy time.
 
 ### Top 10 CI/CD Security Risk
 
-Δείτε αυτό το ενδιαφέρον άρθρο για τους top 10 CI/CD risks σύμφωνα με την Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Δείτε αυτό το ενδιαφέρον άρθρο για τα top 10 CI/CD risks σύμφωνα με την Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Σε κάθε πλατφόρμα που μπορείτε να τρέξετε τοπικά θα βρείτε οδηγίες για το πώς να την ξεκινήσετε τοπικά ώστε να τη διαμορφώσετε όπως θέλετε για να τη δοκιμάσετε
+- Σε κάθε platform που μπορείτε να τρέξετε τοπικά θα βρείτε πώς να το εκκινήσετε τοπικά ώστε να το ρυθμίσετε όπως θέλετε για να το δοκιμάσετε
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** είναι ένα static code analysis εργαλείο για infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): Το **Checkov** είναι ένα static code analysis tool για infrastructure-as-code.
 
 ## References
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
+- [The npm Threat Landscape: Attack Surface and Mitigations](https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/)
+- [Checkmarx Security Update: April 22, 2026](https://checkmarx.com/blog/checkmarx-security-update-april-22/?p=108469)
 
 
 {{#include ../banners/hacktricks-training.md}}