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 Methodik
+# Pentesting CI/CD Methodologie
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,51 +6,51 @@
 
 ## VCS
 
-VCS steht für **Versionskontrollsystem**, dieses System erlaubt Entwicklern, **ihren Quellcode zu verwalten**. Das gebräuchlichste ist **git** und in Unternehmen findet man es meist auf einer der folgenden **Plattformen**:
+VCS steht für **Version Control System**, diese Systeme ermöglichen es Entwicklern, ihren **Source Code zu verwalten**. Das gängigste ist **git** und man findet Unternehmen normalerweise mit einer der folgenden **Platformen**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (they offer their own VCS platforms)
+- Cloud providers (sie bieten ihre eigenen VCS Platformen an)
 
 
 ## CI/CD Pipelines
 
-CI/CD pipelines ermöglichen es Entwicklern, die **Ausführung von Code zu automatisieren** für verschiedene Zwecke, einschließlich Build, Tests und Deployment von Anwendungen. Diese automatisierten Workflows werden durch **bestimmte Aktionen ausgelöst**, wie Code-Pushes, Pull Requests oder geplante Tasks. Sie helfen, den Prozess von der Entwicklung bis zur Produktion zu straffen.
+CI/CD Pipelines ermöglichen es Entwicklern, die **Ausführung von Code zu automatisieren** für verschiedene Zwecke, einschließlich Build, Testing und Deployment von Anwendungen. Diese automatisierten Workflows werden durch **spezifische Aktionen ausgelöst**, wie Code-Pushes, pull requests oder geplante Tasks. Sie sind nützlich, um den Prozess von development bis production zu vereinfachen.
 
-Allerdings müssen diese Systeme **irgendwo ausgeführt** werden und in der Regel mit **privilegierten Zugangsdaten, um Code zu deployen oder auf sensible Informationen zuzugreifen**.
+Allerdings müssen diese Systeme **irgendwo ausgeführt werden** und normalerweise mit **privilegierten credentials**, um Code zu deployen oder auf sensible Informationen zuzugreifen.
 
-## VCS Pentesting Methodik
+## 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.
+> Auch wenn einige VCS Platformen das Erstellen von Pipelines für diesen Abschnitt erlauben, analysieren wir hier nur mögliche Angriffe auf die Kontrolle über den Source Code.
 
-Plattformen, die den Quellcode eines Projekts enthalten, bewahren sensible Informationen, weshalb sehr sorgfältig mit den Berechtigungen innerhalb dieser Plattform umgegangen werden muss. Hier einige häufige Probleme auf VCS-Plattformen, die ein Angreifer ausnutzen könnte:
+Platformen, die den Source Code deines Projekts enthalten, enthalten sensible Informationen, und man muss sehr vorsichtig mit den innerhalb dieser Platform vergebenen permissions sein. Dies sind einige häufige Probleme über VCS Platformen hinweg, die ein Angreifer ausnutzen könnte:
 
-- **Leaks**: Wenn dein Code leaks in den Commits enthält und ein Angreifer auf das Repo zugreifen kann (weil es public ist oder weil er Zugriff hat), könnte er die leaks entdecken.
-- **Access**: Wenn ein Angreifer Zugang zu einem Account auf der VCS-Plattform erlangen kann, könnte er **mehr Sichtbarkeit und Berechtigungen** gewinnen.
-- **Register**: Manche Plattformen erlauben externen Nutzern einfach, ein Konto zu erstellen.
-- **SSO**: Einige Plattformen erlauben keine Registrierung, aber jeder mit einem gültigen SSO kann sich anmelden (ein Angreifer könnte z. B. sein github-Konto benutzen).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... es gibt verschiedene Tokenarten, die ein Nutzer stehlen könnte, um in gewisser Weise auf ein Repo zuzugreifen.
-- **Webhooks**: VCS-Plattformen erlauben das Erstellen von Webhooks. Wenn diese **nicht mit nicht-sichtbaren secrets geschützt** sind, könnte ein **Angreifer sie missbrauchen**.
-- Wenn kein Secret vorhanden ist, könnte ein Angreifer den Webhook der Drittanbieterplattform missbrauchen.
-- Wenn das Secret in der URL steckt, gilt dasselbe und der Angreifer hat ebenfalls das Secret.
-- **Code compromise:** Wenn ein böswilliger Akteur Schreibrechte über ein Repo hat, könnte er versuchen, **bösartigen Code zu injizieren**. Um erfolgreich zu sein, muss er möglicherweise **Branch Protections umgehen**. Diese Aktionen können mit verschiedenen Zielen durchgeführt werden:
-  - Kompromittierung des main-Branch, um die **Produktion zu kompromittieren**.
-  - Kompromittierung des main- (oder anderer) Branches, um **Entwickler-Rechner zu kompromittieren** (da diese oft Tests, terraform oder andere Dinge lokal aus dem Repo ausführen).
-- **Compromise the pipeline** (siehe nächsten Abschnitt)
+- **Leaks**: Wenn dein Code leaks in den Commits enthält und der Angreifer auf das Repo zugreifen kann (weil es öffentlich ist oder weil er Zugriff hat), könnte er die leaks entdecken.
+- **Access**: Wenn ein Angreifer **auf ein Account innerhalb der VCS Platform zugreifen** kann, könnte er **mehr Sichtbarkeit und permissions** erhalten.
+- **Register**: Einige Platformen erlauben es externen Nutzern einfach, ein Account zu erstellen.
+- **SSO**: Einige Platformen erlauben es Nutzern nicht, sich zu registrieren, erlauben aber jedem mit gültigem SSO den Zugriff (ein Angreifer könnte also zum Beispiel seinen github account nutzen, um sich einzuloggen).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... es gibt mehrere Arten von tokens, die ein Nutzer stehlen könnte, um irgendwie auf ein Repo zuzugreifen.
+- **Webhooks**: VCS Platformen erlauben das Erstellen von webhooks. Wenn diese **nicht** mit nicht sichtbaren secrets geschützt sind, kann ein **Angreifer sie ausnutzen**.
+- Wenn kein secret vorhanden ist, kann der Angreifer den webhook der third party Plattform ausnutzen
+- Wenn das secret in der URL steht, passiert dasselbe und der Angreifer hat das secret ebenfalls
+- **Code compromise:** Wenn ein böswilliger Akteur irgendeine Art von **write** access auf die repos hat, könnte er versuchen, **malicious code einzuschleusen**. Um erfolgreich zu sein, müsste er möglicherweise **branch protections umgehen**. Diese Aktionen können mit unterschiedlichen Zielen durchgeführt werden:
+- Den main branch kompromittieren, um **production zu kompromittieren**.
+- Den main (oder andere branches) kompromittieren, um **developer machines zu kompromittieren** (da sie normalerweise test, terraform oder andere Dinge innerhalb des repos auf ihren Maschinen ausführen).
+- **Die pipeline kompromittieren** (siehe nächsten Abschnitt)
 
-## Pipelines Pentesting Methodik
+## Pipelines Pentesting Methodology
 
-Die gebräuchlichste Methode, eine Pipeline zu definieren, ist die Verwendung einer **CI-Konfigurationsdatei im Repository**, das die Pipeline baut. Diese Datei beschreibt die Reihenfolge der ausgeführten Jobs, Bedingungen, die den Ablauf beeinflussen, und Einstellungen für die Build-Umgebung.\
-Diese Dateien haben typischerweise einen konsistenten Namen und ein konsistentes Format, zum Beispiel — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) und die GitHub Actions YAML-Dateien unter .github/workflows. Wenn sie ausgelöst werden, **zieht der Pipeline-Job den Code** aus der ausgewählten Quelle (z. B. Commit / Branch) und **führt die in der CI-Konfigurationsdatei angegebenen Befehle** gegen diesen Code aus.
+Der gebräuchlichste Weg, eine pipeline zu definieren, ist die Verwendung einer **CI configuration file, die im repository gehostet wird**, das die pipeline baut. Diese Datei beschreibt die Reihenfolge der ausgeführten jobs, Bedingungen, die den Ablauf beeinflussen, und build environment settings.\
+Diese Dateien haben typischerweise einen konsistenten Namen und ein konsistentes Format, zum Beispiel — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) und die GitHub Actions YAML files unterhalb von .github/workflows. Wenn die pipeline ausgelöst wird, **holt** der pipeline job den Code aus der ausgewählten Quelle (z. B. commit / branch) und **führt die in der CI configuration file angegebenen commands** gegen diesen Code aus.
 
-Daher ist das ultimative Ziel des Angreifers, auf irgendeine Weise **diese Konfigurationsdateien zu kompromittieren** oder die **Befehle, die sie ausführen**.
+Daher ist das ultimative Ziel des Angreifers, irgendwie **diese configuration files zu kompromittieren** oder die **commands, die sie ausführen**.
 
 > [!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:
+> Manche gehosteten builder lassen contributor den Docker build context und den Dockerfile path wählen. Wenn der context vom Angreifer kontrolliert wird, kann er ihn außerhalb des repos setzen (z. B. ".."), um Host-Dateien während des builds einzulesen und secrets zu exfiltrieren. Siehe:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,57 +58,78 @@ Daher ist das ultimative Ziel des Angreifers, auf irgendeine Weise **diese Konfi
 
 ### PPE - Poisoned Pipeline Execution
 
-Der Poisoned Pipeline Execution (PPE)-Pfad nutzt Berechtigungen in einem SCM-Repository aus, um eine CI-Pipeline zu manipulieren und schädliche Befehle auszuführen. Benutzer mit den notwendigen Rechten können CI-Konfigurationsdateien oder andere Dateien, die vom Pipeline-Job verwendet werden, so ändern, dass sie bösartige Befehle enthalten. Dies "vergiftet" die CI-Pipeline und führt zur Ausführung dieser bösartigen Befehle.
+Der Poisoned Pipeline Execution (PPE)-Pfad nutzt permissions in einem SCM repository aus, um eine CI pipeline zu manipulieren und schädliche commands auszuführen. Nutzer mit den nötigen permissions können CI configuration files oder andere von der pipeline job verwendete files ändern, um malicious commands einzufügen. Das "vergiftet" die CI pipeline und führt zur Ausführung dieser malicious commands.
 
-Damit ein böswilliger Akteur einen PPE-Angriff erfolgreich durchführen kann, muss er:
+Damit ein böswilliger Akteur bei einem PPE-Angriff erfolgreich ist, muss er in der Lage sein:
 
-- Schreibzugriff auf die VCS-Plattform haben, da Pipelines in der Regel ausgelöst werden, wenn ein Push oder ein Pull Request durchgeführt wird. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Wege, Zugriff zu bekommen).
-- Beachte, dass manchmal ein externer PR als "Schreibzugriff" gilt.
-- Selbst wenn er Schreibberechtigungen hat, muss er sicherstellen, dass er die CI-Konfigurationsdatei oder andere Dateien, auf die die Konfiguration angewiesen ist, **ändern kann**.
-- Dafür muss er möglicherweise Branch Protections umgehen.
+- **write access zur VCS Platform** zu haben, da pipelines normalerweise ausgelöst werden, wenn ein push oder ein pull request ausgeführt wird. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Wege, Zugriff zu erhalten).
+- Beachte, dass manchmal ein **external PR als "write access" zählt**.
+- Selbst wenn er write permissions hat, muss er sicherstellen, dass er die CI config file oder andere files, auf die die config angewiesen ist, **ändern** kann.
+- Dafür muss er möglicherweise **branch protections umgehen**.
 
 Es gibt 3 PPE-Varianten:
 
-- **D-PPE**: Ein **Direct PPE**-Angriff findet statt, wenn der Akteur die **CI-Konfigurationsdatei direkt verändert**, die ausgeführt werden soll.
-- **I-DDE**: Ein **Indirect PPE**-Angriff tritt auf, wenn der Akteur eine **Datei verändert, auf die die CI-Konfigurationsdatei angewiesen ist** (z. B. ein Makefile oder eine Terraform-Konfiguration).
-- **Public PPE or 3PE**: In einigen Fällen können Pipelines **von Nutzern ausgelöst werden, die keinen Schreibzugriff auf das Repo haben** (und möglicherweise nicht einmal Teil der Organisation sind), weil sie einen PR senden können.
-- **3PE Command Injection**: Üblicherweise setzen CI/CD-Pipelines **Umgebungsvariablen** mit **Informationen über den PR**. Wenn dieser Wert vom Angreifer kontrollierbar ist (z. B. der Titel des PR) und an einer **gefährlichen Stelle** verwendet wird (z. B. beim Ausführen von **sh-Befehlen**), könnte ein Angreifer **Befehle dort injizieren**.
+- **D-PPE**: Ein **Direct PPE** Angriff tritt auf, wenn der Akteur die CI config file **ändert**, die ausgeführt werden soll.
+- **I-DDE**: Ein **Indirect PPE** Angriff tritt auf, wenn der Akteur eine **file** **ändert**, auf die sich die ausgeführte CI config file **verlässt** (wie eine make file oder eine terraform config).
+- **Public PPE or 3PE**: In einigen Fällen können die pipelines von Nutzern **ausgelöst werden, die kein write access im repo haben** (und die möglicherweise nicht einmal Teil der org sind), weil sie einen PR senden können.
+- **3PE Command Injection**: Normalerweise setzen CI/CD pipelines **environment variables** mit **Informationen über den PR**. Wenn dieser Wert von einem Angreifer kontrolliert werden kann (wie der Titel des PR) und an einer **gefährlichen Stelle** **verwendet** wird (wie beim Ausführen von **sh commands**), kann ein Angreifer dort **commands einschleusen**.
 
 ### Exploitation Benefits
 
-Wenn man die 3 Varianten kennt, schauen wir, was ein Angreifer nach einer erfolgreichen Kompromittierung erreichen könnte:
+Wenn man die 3 Varianten kennt, eine pipeline zu vergiften, schauen wir uns an, was ein Angreifer nach erfolgreicher Exploitation erhalten könnte:
 
-- **Secrets**: Wie zuvor erwähnt, benötigen Pipelines **Privilegien** für ihre Jobs (Code abrufen, bauen, deployen ...) und diese Privilegien werden üblicherweise in **secrets** hinterlegt. Diese secrets sind oft über **env-Variablen oder Dateien im System** zugänglich. Daher wird ein Angreifer immer versuchen, möglichst viele secrets zu exfiltrieren.
-- Je nach Pipeline-Plattform muss der Angreifer **die secrets in der Konfiguration angeben**. Das bedeutet, wenn der Angreifer die CI-Konfiguration nicht modifizieren kann (z. B. I-PPE), könnte er **nur die secrets exfiltrieren, die der Pipeline bereits zur Verfügung stehen**.
-- **Computation**: Der Code wird irgendwo ausgeführt; je nachdem, wo, kann ein Angreifer weiter pivotieren.
-- **On-Premises**: Wenn die Pipelines On-Premises laufen, könnte ein Angreifer in ein **internes Netzwerk** gelangen und Zugriff auf weitere Ressourcen erhalten.
-- **Cloud**: Der Angreifer könnte **andere Maschinen in der Cloud** erreichen, aber auch IAM-Rollen/Service-Account-Token exfiltrieren, um **weiteren Zugang in der Cloud** zu erhalten.
-- **Plattformmaschinen**: Manchmal werden Jobs innerhalb der **Pipeline-Plattform-Maschinen** ausgeführt, die in der Regel in einer Cloud liegen und **keinen weiteren Zugriff** bieten.
-- **Select it:** Manchmal hat die **Pipeline-Plattform mehrere Maschinen konfiguriert**, und wenn du die CI-Konfigurationsdatei ändern kannst, kannst du **angeben, wo du den bösartigen Code ausführen möchtest**. In diesem Fall wird ein Angreifer wahrscheinlich auf jeder möglichen Maschine eine Reverse-Shell starten, um weitere Exploits zu versuchen.
-- **Compromise production**: Wenn du dich in der Pipeline befindest und die finale Version von dort gebaut und deployed wird, könntest du **den Code kompromittieren, der später in Produktion läuft**.
+- **Secrets**: Wie zuvor erwähnt, benötigen pipelines **privileges** für ihre jobs (den Code abrufen, bauen, deployen ...) und diese privileges werden normalerweise in **secrets** vergeben. Diese secrets sind üblicherweise über **env variables oder files im System** zugänglich. Daher wird ein Angreifer immer versuchen, möglichst viele secrets zu exfiltrieren.
+- Abhängig von der pipeline platform muss der Angreifer **möglicherweise die secrets in der config angeben**. Das bedeutet, dass der Angreifer, falls er die CI configuration pipeline nicht ändern kann (**I-PPE** zum Beispiel), **nur die secrets exfiltrieren kann, die diese pipeline besitzt**.
+- **Computation**: Der Code wird irgendwo ausgeführt; je nachdem, wo er ausgeführt wird, könnte ein Angreifer weiter pivotieren.
+- **On-Premises**: Wenn die pipelines on premises ausgeführt werden, könnte ein Angreifer in einem **internen network mit Zugriff auf weitere resources** landen.
+- **Cloud**: Der Angreifer könnte auf **andere Maschinen in der Cloud** zugreifen, aber auch IAM roles/service accounts **tokens** von dort exfiltrieren, um **weiteren Zugriff innerhalb der Cloud** zu erhalten.
+- **Platforms machine**: Manchmal werden die jobs innerhalb der **machines der pipelines platform** ausgeführt, die sich normalerweise in einer Cloud mit **keinem weiteren access** befinden.
+- **Select it:** Manchmal hat die **pipelines platform mehrere machines konfiguriert** und wenn du die CI configuration file **ändern** kannst, kannst du **angeben, wo der bösartige Code ausgeführt werden soll**. In dieser Situation wird ein Angreifer wahrscheinlich auf jeder möglichen machine eine reverse shell starten, um zu versuchen, sie weiter auszunutzen.
+- **Compromise production**: Wenn du in der pipeline bist und die finale Version von dort gebaut und deployt wird, könntest du **den Code kompromittieren, der schließlich in production läuft**.
 
-## Mehr relevante Informationen
+### Dependency & Registry Supply-Chain Abuse
+
+Das Kompromittieren einer CI/CD pipeline oder das Stehlen von credentials daraus kann einem Angreifer ermöglichen, von **pipeline execution** zu **ecosystem-wide code execution** überzugehen, indem er dependencies oder release tooling mit Backdoors versieht:
+
+- **Install-time code execution via package hooks**: veröffentliche eine package version, die `preinstall`, `postinstall`, `prepare` oder ähnliche hooks hinzufügt, sodass der payload automatisch auf developer workstations und CI runners während der dependency installation ausgeführt wird.
+- **Secondary execution paths**: selbst wenn targets mit `--ignore-scripts` installieren, kann ein bösartiges package dennoch einen **common CLI name** im `bin`-Feld registrieren, sodass der vom Angreifer kontrollierte wrapper in `PATH` verlinkt wird und später ausgeführt wird, wenn der command verwendet wird.
+- **Runtime bootstrapping**: ein kleiner installer kann während der installation eine zweite runtime oder toolchain herunterladen (zum Beispiel Bun oder einen gepackten interpreter) und dann den main payload damit starten, wodurch lokale dependency requirements umgangen werden.
+- **Credential harvesting from build environments**: sobald code innerhalb von CI läuft, überprüfe environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs und lokale tooling wie `gh auth token`. In GitHub Actions solltest du auch nach runner-spezifischen secrets und artifacts suchen.
+- **Workflow injection with stolen GitHub tokens**: ein token mit **`repo` + `workflow`** permissions reicht aus, um einen branch zu erstellen, eine bösartige file innerhalb von `.github/workflows/` zu committen, sie auszulösen, die erzeugten artifacts/logs zu sammeln und dann den temporären branch/workflow run zu löschen, um Spuren zu reduzieren.
+- **Wormable registry propagation**: gestohlene npm tokens sollten auf **publish** permissions und darauf geprüft werden, ob sie 2FA umgehen. Falls ja, enumerate writable packages, lade ihre tarballs herunter, injiziere einen loader wie `setup.mjs`, setze `preinstall`, um ihn auszuführen, erhöhe die patch version und veröffentliche erneut. Dadurch wird aus einem CI compromise eine nachgelagerte Auto-Ausführung in anderen Umgebungen.
+
+#### Praktische Checks während einer assessment
+
+- Prüfe release automation auf package-manager hooks, die zu `package.json` hinzugefügt wurden, unerwartete `bin`-Einträge oder Versionssprünge, die nur das release artifact ändern.
+- Prüfe, ob CI langfristige registry credentials in Klartextdateien wie `~/.npmrc` speichert statt kurzlebiges OIDC oder trusted publishing zu verwenden.
+- Verifiziere, ob GitHub tokens, die in CI verfügbar sind, workflow files schreiben oder branches/tags erstellen können.
+- Wenn ein kompromittiertes package vermutet wird, untersuche das veröffentlichte tarball und nicht nur das Git repository, weil der bösartige loader/runtime nur im veröffentlichten artifact existieren kann.
+- Suche in CI nach unerwarteter package-manager execution wie `npm install` statt `npm ci`, unerwarteten Bun downloads/execution oder neuen workflow artifacts, die aus transienten branches erzeugt wurden.
+
+## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zur Überprüfung deiner Software-Lieferkette auf Sicherheitskonformität basierend auf einem neuen [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Das Audit konzentriert sich auf den gesamten SDLC-Prozess und kann Risiken vom Code bis zum Deployment aufdecken.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zur Prüfung deines Software supply chain stack auf security compliance basierend auf einem neuen [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Das Auditing konzentriert sich auf den gesamten SDLC-Prozess, wobei Risiken von code time bis deploy time sichtbar werden können.
 
 ### Top 10 CI/CD Security Risk
 
-Sieh dir diesen interessanten Artikel über die Top-10 CI/CD-Risiken laut Cider an: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Sieh dir diesen interessanten Artikel über die Top 10 CI/CD risks gemäß Cider an: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Für jede Plattform, die du lokal betreiben kannst, findest du Anleitungen, wie du sie lokal startest, damit du sie nach Belieben konfigurieren und testen kannst.
+- Auf jeder platform, die du lokal ausführen kannst, findest du Hinweise, wie du sie lokal startest, damit du sie so konfigurieren kannst, wie du es zum Testen möchtest
 - 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** ist ein Static-Code-Analyse-Tool für Infrastructure-as-Code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ist ein static code analysis tool für 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}}