Translated ['src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-

src/pentesting-ci-cd/gitblit-security/README.md

@@ -0,0 +1,21 @@
+# Gitblit Sigurnost
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Šta je Gitblit
+
+Gitblit je samohostovani Git server napisan u Javi. Može da radi kao standalone JAR ili u servlet kontejnerima i sadrži ugrađenu SSH uslugu (Apache MINA SSHD) za Git preko SSH.
+
+## Teme
+
+- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#ref}}
+gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
+{{#endref}}
+
+## Reference
+
+- [Gitblit project](https://gitblit.com/)
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md

@@ -0,0 +1,107 @@
+# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Sažetak
+
+CVE-2024-28080 je bypass autentifikacije u ugrađenoj SSH usluzi Gitblit-a zbog netačnog rukovanja stanjem sesije prilikom integracije sa Apache MINA SSHD. Ako korisnički nalog ima registrovan bar jedan SSH public key, napadač koji zna username i bilo koji od tog korisnikovih public keys može se autentifikovati bez privatnog ključa i bez lozinke.
+
+- Pogođeno: Gitblit < 1.10.0 (uočeno na 1.9.3)
+- Ispravljeno: 1.10.0
+- Zahtevi za eksploataciju:
+- Git over SSH omogućen na instanci
+- Žrtvin nalog ima registrovan bar jedan SSH public key u Gitblit-u
+- Napadač zna žrtvino username i jedan od njihovih public keys (često otkrivljivo, npr. https://github.com/<username>.keys)
+
+## Uzrok (state leaks between SSH methods)
+
+U RFC 4252, public‑key authentication ide u dve faze: server prvo proverava da li je ponuđeni public key prihvatljiv za dati username, i tek nakon challenge/response sa signature autentifikuje korisnika. U MINA SSHD, PublickeyAuthenticator se poziva dvaput: pri prihvatanju ključa (još bez signature) i kasnije nakon što klijent vrati signature.
+
+Gitblit-ov PublickeyAuthenticator je mutirao kontekst sesije pri prvom, pre‑signature pozivu vezujući autentifikovani UserModel za sesiju i vraćajući true ("key acceptable"). Kada se autentifikacija kasnije prebacila na password, PasswordAuthenticator je verovao tom izmenjenom stanju sesije i prečicom vratio uspeh, vraćajući true bez validacije password-a. Kao rezultat, bilo koja password (uključujući praznu) je bila prihvaćena nakon prethodnog public‑key "acceptance" za istog korisnika.
+
+High‑level flawed flow:
+
+1) Client nudi username + public key (još bez signature)  
+2) Server prepoznaje ključ kao pripadajući korisniku i prerano prikači user u sesiju, vraćajući true ("acceptable")  
+3) Client ne može da potpiše (nema private key), pa autentifikacija pada na password  
+4) Password auth vidi da user već postoji u sesiji i bezuslovno vraća success
+
+## Koraci za eksploataciju
+
+- Sakupite žrtvino username i jedan od njihovih public keys:
+  - GitHub izlaže public keys na https://github.com/<username>.keys
+  - Javne servere često izlažu authorized_keys
+- Konfigurišite OpenSSH da prezentuje samo public half tako da generisanje signature zakaže, prisiljavajući fallback na password dok i dalje pokreće public‑key acceptance put na serveru.
+
+Example SSH client config (no private key available):
+```sshconfig
+# ~/.ssh/config
+Host gitblit-target
+HostName <host-or-ip>
+User <victim-username>
+PubkeyAuthentication yes
+PreferredAuthentications publickey,password
+IdentitiesOnly yes
+IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
+```
+Povežite se i na promptu za lozinku pritisnite Enter (ili unesite bilo koji tekst):
+```bash
+ssh gitblit-target
+# or Git over SSH
+GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
+```
+Autentifikacija uspeva zato što je ranija public‑key faza izmenila sesiju i postavila je na autentifikovanog korisnika, a password auth pogrešno veruje tom stanju.
+
+Napomena: Ako je ControlMaster multiplexing omogućen u vašoj SSH konfiguraciji, naknadne Git komande mogu ponovo koristiti autentifikovanu konekciju, čime se povećava uticaj.
+
+## Impact
+
+- Full impersonation of any Gitblit user with at least one registered SSH public key
+- Read/write access to repositories per victim’s permissions (source exfiltration, unauthorized pushes, supply‑chain risks)
+- Potential administrative impact if targeting an admin user
+- Pure network exploit; no brute force or private key required
+
+## Detection ideas
+
+- Pregledajte SSH logove za sekvence gde pokušaj publickey bude praćen uspešnom password autentifikacijom sa praznim ili vrlo kratkim password‑om
+- Tražite tokove: publickey method koja nudi unsupported/mismatched key material praćena neposrednim uspehom password metode za isto korisničko ime
+
+## Mitigations
+
+- Upgrade to Gitblit v1.10.0+
+- Dok se ne izvrši nadogradnja:
+- Disable Git over SSH on Gitblit, or
+- Ograničite mrežni pristup SSH servisu, i
+- Monitor for suspicious patterns described above
+- Rotate affected user credentials if compromise is suspected
+
+## Opšte: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+
+Pattern: Ako serverov public‑key authenticator mutira korisničko/sesijsko stanje tokom pre‑signature "key acceptable" faze i drugi authenticators (npr. password) veruju tom stanju, možete zaobići autentifikaciju na sledeći način:
+
+- Presenting a legitimate public key for the target user (no private key)
+- Forcing the client to fail signing so the server falls back to password
+- Supplying any password while the password authenticator short‑circuits on leaked state
+
+Praktični saveti:
+
+- Public key harvesting at scale: pull public keys from common sources such as https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
+- Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password
+- MINA SSHD integration pitfalls:
+- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature
+- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method
+
+Povezane protokolarne/dizajnerske beleške i literatura:
+- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
+- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
+
+## References
+
+- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
+- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)
+- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/)
+- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html)
+- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252)
+
+
+{{#include ../../banners/hacktricks-training.md}}

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

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Metodologija
+# Pentesting CI/CD Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,99 +6,102 @@
 
 ## VCS
 
-VCS označava **Sistem Kontrole Verzija**, ovaj sistem omogućava programerima da **upravljaju svojim izvorni kodom**. Najčešći je **git** i obično ćete naći kompanije koje ga koriste na jednoj od sledećih **platformi**:
+VCS znači **Version Control System**, ovi sistemi omogućavaju developerima da **upravljaju svojim source code-om**. Najčešći je **git** i obično ćete kompanije pronaći da ga koriste na jednoj od sledećih **platformi**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
-- Cloud provajderi (oni nude svoje VCS platforme)
+- Gitblit
+- Cloud providers (oni nude svoje VCS platforme)
+
 
 ## CI/CD Pipelines
 
-CI/CD pipelines omogućavaju programerima da **automatizuju izvršavanje koda** za različite svrhe, uključujući izgradnju, testiranje i implementaciju aplikacija. Ovi automatizovani radni tokovi se **pokreću specifičnim akcijama**, kao što su push-ovi koda, pull zahtevi ili zakazani zadaci. Korisni su za pojednostavljenje procesa od razvoja do produkcije.
+CI/CD pipelines omogućavaju developerima da **automatizuju izvršavanje koda** u razne svrhe, uključujući build, testiranje i deploy aplikacija. Ovi automatizovani workflow-ovi se **okidaju određenim akcijama**, kao što su code pushes, pull requests, ili zakazani zadaci. Korisni su za pojednostavljenje procesa od razvoja do production-a.
 
-Međutim, ovi sistemi moraju biti **izvršeni negde** i obično sa **privilegovanim akreditivima za implementaciju koda ili pristup osetljivim informacijama**.
+Međutim, ovi sistemi moraju biti **izvedeni negde** i obično koriste **privileged credentials da bi deploy-ovali kod ili pristupili osetljivim informacijama**.
 
-## VCS Pentesting Metodologija
+## VCS Pentesting Methodology
 
 > [!NOTE]
-> Čak i ako neke VCS platforme omogućavaju kreiranje pipelines, u ovoj sekciji ćemo analizirati samo potencijalne napade na kontrolu izvornog koda.
+> Čak i ako neke VCS platforme dozvoljavaju kreiranje pipelines, za ovu sekciju ćemo analizirati samo potencijalne napade na kontrolu source code-a.
 
-Platforme koje sadrže izvorni kod vašeg projekta sadrže osetljive informacije i ljudi moraju biti veoma oprezni sa dozvolama dodeljenim unutar ove platforme. Ovo su neki uobičajeni problemi na VCS platformama koje napadači mogu zloupotrebiti:
+Platforme koje sadrže source code vašeg projekta sadrže osetljive informacije i ljudi moraju biti veoma pažljivi sa permissions koje se dodeljuju unutar te platforme. Ovo su neki uobičajeni problemi na VCS platformama koje napadač može zloupotrebiti:
 
-- **Leaking**: Ako vaš kod sadrži curenja u commit-ima i napadač može pristupiti repozitorijumu (jer je javan ili jer ima pristup), mogao bi otkriti curenja.
-- **Pristup**: Ako napadač može **pristupiti nalogu unutar VCS platforme**, mogao bi dobiti **veću vidljivost i dozvole**.
-- **Registracija**: Neke platforme će samo omogućiti spoljnim korisnicima da kreiraju nalog.
-- **SSO**: Neke platforme neće dozvoliti korisnicima da se registruju, ali će omogućiti svakome da pristupi sa važećim SSO (tako da napadač može koristiti svoj github nalog da uđe, na primer).
-- **Akreditivi**: Korisničko ime+Lozinka, lični tokeni, ssh ključevi, Oauth tokeni, kolačići... postoji nekoliko vrsta tokena koje korisnik može ukrasti da bi na neki način pristupio repozitorijumu.
-- **Webhook-ovi**: VCS platforme omogućavaju generisanje webhook-ova. Ako nisu **zaštićeni** nevidljivim tajnama, **napadač bi mogao da ih zloupotrebi**.
-- Ako nema tajne, napadač bi mogao zloupotrebiti webhook treće strane
-- Ako je tajna u URL-u, isto se dešava i napadač takođe ima tajnu
-- **Kompromitovanje koda:** Ako zlonameran akter ima neku vrstu **write** pristupa nad repozitorijumima, mogao bi pokušati da **ubaci zlonamerni kod**. Da bi bio uspešan, možda će morati da **obiđe zaštite grana**. Ove akcije se mogu izvesti sa različitim ciljevima na umu:
-- Kompromitovati glavnu granu da bi **kompromitovao produkciju**.
-- Kompromitovati glavnu (ili druge grane) da bi **kompromitovao mašine programera** (jer obično izvršavaju testove, terraform ili druge stvari unutar repozitorijuma na svojim mašinama).
-- **Kompromitovati pipeline** (proverite sledeću sekciju)
+- **Leaks**: Ako vaš code sadrži leaks u commit-ovima i napadač može pristupiti repo-u (jer je javno ili zato što on ima pristup), on može otkriti leaks.
+- **Access**: Ako napadač može **pristupiti account-u unutar VCS platforme** mogao bi steći **veću vidljivost i permissions**.
+- **Register**: Neke platforme će jednostavno dozvoliti eksternim korisnicima da kreiraju account.
+- **SSO**: Neke platforme neće dozvoliti korisnicima registraciju, ali će dozvoliti bilo kome da se prijavi sa validnim SSO (tako napadač može koristiti svoj github account da se, na primer, prijavi).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... postoji više vrsta tokena koje korisnik može ukrasti da bi nekako pristupio repo-u.
+- **Webhooks**: VCS platforme omogućavaju generisanje webhooks. Ako nisu **zaštićeni** sa non-visible secrets, **napadač ih može zloupotrebiti**.
+- Ako nema secret-a, napadač može zloupotrebiti webhook treće strane platforme
+- Ako je secret u URL-u, isto se dešava i napadač takođe dobija secret
+- **Code compromise:** Ako maliciozni akter ima neku vrstu **write** pristupa nad repos-ima, mogao bi pokušati **inject-maliciozni kod**. Da bi bio uspešan možda će morati **zaobići branch protections**. Ove akcije mogu biti izvršene sa različitim ciljevima:
+  - Kompromitovati main branch da bi **kompromitovao production**.
+  - Kompromitovati main (ili druge branch-e) da bi **kompromitovao developere na njihovim mašinama** (jer oni obično izvršavaju testove, terraform ili druge stvari iz repo-a na svojim mašinama).
+- **Compromise the pipeline** (pogledati sledeću sekciju)
 
-## Pipelines Pentesting Metodologija
+## Pipelines Pentesting Methodology
 
-Najčešći način da se definiše pipeline je korišćenjem **CI konfiguracione datoteke koja se hostuje u repozitorijumu** koji pipeline gradi. Ova datoteka opisuje redosled izvršenih poslova, uslove koji utiču na tok i postavke okruženja za izgradnju.\
-Ove datoteke obično imaju dosledno ime i format, na primer — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), i YAML datoteke GitHub Actions smeštene pod .github/workflows. Kada se pokrene, posao pipeline-a **povlači kod** iz odabranog izvora (npr. commit / grana), i **izvršava komande navedene u CI konfiguracionoj datoteci** protiv tog koda.
+Najčešći način da se definiše pipeline je korišćenjem **CI configuration file-a hostovanog u repository-ju** koji pipeline gradi. Ovaj fajl opisuje redosled izvršenih job-ova, uslove koji utiču na flow, i podešavanja build environment-a.\
+Ovi fajlovi obično imaju konzistentno ime i format, na primer — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), i GitHub Actions YAML fajlovi pod .github/workflows. Kada se okine, pipeline job **povlači code** iz izabranog source-a (npr. commit / branch), i **izvršava komande navedene u CI configuration file-u** nad tim kodom.
 
-Stoga je krajnji cilj napadača da na neki način **kompromituje te konfiguracione datoteke** ili **komande koje izvršavaju**.
+Dakle, krajnji cilj napadača je nekako **kompromitovati te configuration fajlove** ili **komande koje oni izvršavaju**.
 
-### PPE - Izvršenje Zagađenog Pipeline-a
+### PPE - Poisoned Pipeline Execution
 
-Putanja Izvršenja Zagađenog Pipeline-a (PPE) koristi dozvole u SCM repozitorijumu da manipuliše CI pipeline-om i izvršava štetne komande. Korisnici sa potrebnim dozvolama mogu modifikovati CI konfiguracione datoteke ili druge datoteke koje koristi posao pipeline-a da uključe zlonamerne komande. Ovo "zagađuje" CI pipeline, što dovodi do izvršenja ovih zlonamernih komandi.
+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.
 
-Da bi zlonameran akter bio uspešan u izvođenju PPE napada, mora biti u mogućnosti da:
+For a malicious actor to be successful performing a PPE attack he needs to be able to:
 
-- Ima **write pristup VCS platformi**, jer se obično pipelines pokreću kada se izvrši push ili pull zahtev. (Proverite VCS pentesting metodologiju za sažetak načina za dobijanje pristupa).
-- Imajte na umu da ponekad **spoljni PR računa kao "write pristup"**.
-- Čak i ako ima write dozvole, mora biti siguran da može **modifikovati CI konfiguracionu datoteku ili druge datoteke na koje se konfiguracija oslanja**.
-- Za to, možda će morati da bude u mogućnosti da **obiđe zaštite grana**.
+- Have **write access to the VCS platform**, as usually pipelines are triggered when a push or a pull request is performed. (Check the VCS pentesting methodology for a summary of ways to get access).
+- Note that sometimes an **external PR count as "write access"**.
+- Even if he has write permissions, he needs to be sure he can **modify the CI config file or other files the config is relying on**.
+- For this, he might need to be able to **bypass branch protections**.
 
-Postoje 3 vrste PPE:
+There are 3 PPE flavours:
 
-- **D-PPE**: **Direktan PPE** napad se dešava kada akter **modifikuje CI konfiguraciju** datoteku koja će biti izvršena.
-- **I-DDE**: **Indirektan PPE** napad se dešava kada akter **modifikuje** **datoteku** na koju se CI konfiguraciona datoteka oslanja (kao što je make datoteka ili terraform konfiguracija).
-- **Javni PPE ili 3PE**: U nekim slučajevima, pipelines mogu biti **pokrenuti od strane korisnika koji nemaju write pristup u repozitorijumu** (i koji možda čak nisu ni deo organizacije) jer mogu poslati PR.
-- **3PE Injekcija Komandi**: Obično, CI/CD pipelines će **postaviti promenljive okruženja** sa **informacijama o PR-u**. Ako tu vrednost može kontrolisati napadač (kao što je naslov PR-a) i koristi se na **opasnom mestu** (kao što je izvršavanje **sh komandi**), napadač može **ubaciti komande tamo**.
+- **D-PPE**: A **Direct PPE** attack occurs when the actor **modifies the CI config** file that is going to be executed.
+- **I-DDE**: An **Indirect PPE** attack occurs when the actor **modifies** a **file** the CI config file that is going to be executed **relays on** (like a make file or a terraform config).
+- **Public PPE or 3PE**: In some cases the pipelines can be **triggered by users that doesn't have write access in the repo** (and that might not even be part of the org) because they can send a PR.
+- **3PE Command Injection**: Usually, CI/CD pipelines will **set environment variables** with **information about the PR**. If that value can be controlled by an attacker (like the title of the PR) and is **used** in a **dangerous place** (like executing **sh commands**), an attacker might **inject commands in there**.
 
-### Prednosti Eksploatacije
+### Exploitation Benefits
 
-Poznavanje 3 vrste za zagađenje pipeline-a, hajde da proverimo šta napadač može dobiti nakon uspešne eksploatacije:
+Knowing the 3 flavours to poison a pipeline, lets check what an attacker could obtain after a successful exploitation:
 
-- **Tajne**: Kao što je ranije pomenuto, pipelines zahtevaju **privilegije** za svoje poslove (preuzimanje koda, izgradnja, implementacija...) i te privilegije se obično **dodeljuju u tajnama**. Ove tajne su obično dostupne putem **env promenljivih ili datoteka unutar sistema**. Stoga će napadač uvek pokušati da eksfiltrira što više tajni.
-- U zavisnosti od platforme pipeline-a, napadač **može morati da specificira tajne u konfiguraciji**. To znači da ako napadač ne može da modifikuje CI konfiguracioni pipeline (**I-PPE**, na primer), može **samo eksfiltrirati tajne koje taj pipeline ima**.
-- **Računanje**: Kod se izvršava negde, u zavisnosti od toga gde se izvršava, napadač bi mogao biti u mogućnosti da se dalje preusmeri.
-- **Na Mestu**: Ako se pipelines izvršavaju na mestu, napadač bi mogao završiti u **internoj mreži sa pristupom više resursima**.
-- **Cloud**: Napadač bi mogao pristupiti **drugim mašinama u cloud-u**, ali takođe bi mogao **eksfiltrirati** IAM uloge/token-e servisnih naloga **iz njega** da bi dobio **dalji pristup unutar cloud-a**.
-- **Mašine platforme**: Ponekad će poslovi biti izvršeni unutar **mašina platforme pipelines**, koje obično su unutar cloud-a sa **nema više pristupa**.
-- **Izaberi to:** Ponekad će **platforma pipelines imati konfigurisanih nekoliko mašina** i ako možete **modifikovati CI konfiguracionu datoteku**, možete **naznačiti gde želite da izvršite zlonamerni kod**. U ovoj situaciji, napadač će verovatno pokrenuti reverznu ljusku na svakoj mogućoj mašini da pokuša da je dalje eksploatiše.
-- **Kompromitovanje produkcije**: Ako ste unutar pipeline-a i konačna verzija se gradi i implementira iz njega, mogli biste **kompromitovati kod koji će se na kraju izvršavati u produkciji**.
+- **Secrets**: Kao što je ranije pomenuto, pipelines zahtevaju **privileges** za svoje job-ove (povlačenje koda, build, deploy...) i ti privileges su obično **dodeljeni u secrets**. Ti secrets su obično dostupni preko **env variables ili fajlova unutar sistema**. Zato će napadač uvek pokušati da eksfiltrira što više secrets-a moguće.
+- U zavisnosti od pipeline platform-e napadač **može morati da specificira secrets u config-u**. To znači da ako napadač ne može da modifikuje CI configuration pipeline-a (**I-PPE** na primer), mogao bi **samo eksfiltrirati secrets koje taj pipeline ima**.
+- **Computation**: Kod se izvršava negde; u zavisnosti gde, napadač možda može da pivot-uje dalje.
+- **On-Premises**: Ako se pipelines izvršavaju on-premises, napadač može završiti u **internoj mreži sa pristupom većim resursima**.
+- **Cloud**: Napadač može pristupiti **drugim mašinama u cloud-u** ali takođe može **eksfiltrirati** IAM roles/service accounts **tokens** iz njega da dobije **dalji pristup unutar clouda**.
+- **Platforms machine**: Ponekad će job-ovi biti izvršeni unutar **pipelines platform machines**, koje obično sede u cloudu bez dodatnog pristupa.
+- **Select it:** Ponekad će **pipelines platform konfigurisan sa više mašina** i ako možete **modifikovati CI configuration file** možete **naznačiti gde želite da izvršite maliciozni kod**. U toj situaciji, napadač će verovatno pokrenuti reverse shell na svakoj mogućoj mašini da pokuša dodatnu eksploataciju.
+- **Compromise production**: Ako ste unutar pipeline-a i finalna verzija se build-uje i deploy-uje iz njega, mogli biste **kompromitovati kod koji će završiti u production-u**.
 
-## Više relevantnih informacija
+## More relevant info
 
-### Alati & CIS Benchmark
+### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) je alat otvorenog koda za reviziju vašeg softverskog lanca snabdevanja za bezbednosnu usklađenost zasnovan na novom [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Revizija se fokusira na ceo SDLC proces, gde može otkriti rizike od vremena koda do vremena implementacije.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.
 
-### Top 10 CI/CD Bezbednosnih Rizika
+### Top 10 CI/CD Security Risk
 
-Proverite ovaj zanimljiv članak o top 10 CI/CD rizicima prema Cider-u: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
-### Laboratorije
+### Labs
 
-- Na svakoj platformi koju možete pokrenuti lokalno naći ćete kako da je pokrenete lokalno tako da je možete konfigurisati kako želite da je testirate
-- Gitea + Jenkins laboratorija: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it
+- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
-### Automatski Alati
+### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** je alat za statičku analizu koda za infrastrukturu kao kod.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for infrastructure-as-code.
 
-## Reference
+## 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)
 
+
 {{#include ../banners/hacktricks-training.md}}