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

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

@@ -6,51 +6,51 @@
 
 ## VCS
 
-VCS, **Version Control System** anlamına gelir; bu sistemler geliştiricilerin **kaynak code'larını yönetmesini** sağlar. En yaygın olanı **git**'tir ve genelde şirketlerde aşağıdaki **platformlar**dan birinde kullanılır:
+VCS, **Version Control System** anlamına gelir; bu sistemler geliştiricilerin **source code'larını yönetmesine** olanak tanır. En yaygın olanı **git**'tir ve şirketlerin bunu genellikle aşağıdaki **platformlardan** birinde kullandığını görürsünüz:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (they offer their own VCS platforms)
+- Cloud providers (kendi VCS platformlarını sunarlar)
 
 
 ## CI/CD Pipelines
 
-CI/CD pipelines geliştiricilerin uygulamaları build, test ve deploy etmek gibi amaçlar için **code yürütmeyi otomatikleştirmesini** sağlar. Bu otomatik iş akışları, code push'ları, pull request'ler veya zamanlanmış görevler gibi **belirli aksiyonlarla tetiklenir**. Geliştirmeden üretime geçiş sürecini düzene koymak için faydalıdır.
+CI/CD pipelines, geliştiricilerin uygulamaları build etmek, test etmek ve deploy etmek dahil olmak üzere çeşitli amaçlar için **code execution'ı otomatikleştirmesini** sağlar. Bu otomatik iş akışları, code push'ları, pull request'ler veya zamanlanmış görevler gibi belirli eylemler tarafından **tetiklenir**. Development'tan production'a giden süreci sadeleştirmek için faydalıdırlar.
 
-Ancak bu sistemlerin bir yerde **çalıştırılması gerekir** ve genelde **deploy yapmak veya hassas bilgilere erişmek için ayrıcalıklı credentials** ile çalışırlar.
+Ancak, bu sistemlerin **bir yerde execute edilmesi** gerekir ve genellikle code deploy etmek veya sensitive information'a erişmek için **privileged credentials** ile çalışırlar.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
+> Bazı VCS platformları bu bölüm için pipeline oluşturulmasına izin verse de, burada yalnızca source code kontrolüne yönelik potansiyel saldırıları analiz edeceğiz.
 
-Projenizin source code'unun bulunduğu platformlar hassas bilgiler içerir ve bu platform içinde verilen izinlere çok dikkat edilmelidir. Saldırganların kötüye kullanabileceği VCS platformları genelinde görülen bazı yaygın problemler şunlardır:
+Projenizin source code'unu içeren platformlar sensitive information içerir ve bu platform içinde verilen permissions konusunda insanlar çok dikkatli olmalıdır. Bunlar, attacker'ın istismar edebileceği VCS platformlarında görülen bazı yaygın sorunlardır:
 
-- **Leaks**: Eğer code'unuz commit'lerde leaks içeriyorsa ve saldırgan repoya erişebiliyorsa (çünkü repo public veya erişimi varsa) bu leaksleri keşfedebilir.
-- **Access**: Eğer bir saldırgan VCS platformu içinde bir hesaba **erişim sağlayabilirse** daha fazla görünürlük ve izin elde edebilir.
-- **Register**: Bazı platformlar dış kullanıcıların hesap oluşturmasına izin verir.
-- **SSO**: Bazı platformlar kullanıcı kaydına izin vermez, ama geçerli bir SSO ile herkesin erişmesine izin verir (örneğin bir saldırgan github hesabını kullanarak girebilir).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... kullanıcıların repoya herhangi bir şekilde erişmek için çalabileceği çeşitli token türleri vardır.
-- **Webhooks**: VCS platformları webhook oluşturulmasına izin verir. Eğer bunlar görünmeyen secret'lerle **korunmuyorsa** bir **saldırgan bunları kötüye kullanabilir**.
-- Eğer herhangi bir secret yoksa, saldırgan üçüncü taraf platformun webhook'unu kötüye kullanabilir
-- Eğer secret URL içinde ise, aynı durum geçerlidir ve saldırgan secret'a da sahip olur
-- **Code compromise:** Eğer kötü niyetli bir aktör repolarda bir tür **write** erişimine sahipse, **zararlı code** enjekte etmeye çalışabilir. Başarılı olmak için çoğunlukla **branch protections'ı bypass etmesi** gerekebilir. Bu eylemler farklı amaçlarla gerçekleştirilebilir:
-- Main branch'i ele geçirerek **production'ı compromise etmek**.
-- Main (veya diğer) branch'leri ele geçirerek **geliştiricilerin makinelerini compromise etmek** (çünkü genelde test, terraform veya repo içindeki diğer şeyleri kendi makinelerinde çalıştırırlar).
+- **Leaks**: Eğer code'unuz commits içinde leak içeriyorsa ve attacker repo'ya erişebiliyorsa (public olduğu için ya da erişimi olduğu için), leak'leri keşfedebilir.
+- **Access**: Eğer bir attacker VCS platformu içindeki bir account'a **access** edebiliyorsa, **daha fazla görünürlük ve permissions** elde edebilir.
+- **Register**: Bazı platformlar yalnızca dış kullanıcıların account oluşturmasına izin verir.
+- **SSO**: Bazı platformlar kullanıcıların register olmasına izin vermez, ancak geçerli bir SSO ile herkesin erişmesine izin verir (örneğin attacker kendi github account'unu kullanarak girebilir).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... bir repo'ya bir şekilde erişmek için user'ın çalabileceği birkaç token türü vardır.
+- **Webhooks**: VCS platformları webhook oluşturulmasına izin verir. Eğer bunlar görünmeyen secrets ile **korunmamışsa**, bir **attacker bunları abuse edebilir**.
+- Eğer secret yoksa, attacker üçüncü taraf platformun webhook'unu abuse edebilir
+- Eğer secret URL'deyse, aynı şey olur ve attacker secret'a da sahip olur
+- **Code compromise:** Eğer malicious actor repo'lar üzerinde herhangi bir **write** access'e sahipse, **malicious code inject** etmeye çalışabilir. Başarılı olmak için branch protections'ı **bypass etmesi** gerekebilir. Bu eylemler farklı hedeflerle yapılabilir:
+- Ana branch'i compromise ederek **production'u compromise etmek**.
+- Ana branch'i (veya diğer branch'leri) compromise ederek **developer makinelerini compromise etmek** (çünkü genellikle repo içindeki test, terraform veya diğer şeyleri makinelerinde çalıştırırlar).
 - **Pipeline'ı compromise etmek** (bir sonraki bölüme bakın)
 
 ## Pipelines Pentesting Methodology
 
-Pipeline tanımlamanın en yaygın yolu, pipeline'ın build ettiği repository'de barındırılan bir **CI configuration file** kullanmaktır. Bu dosya yürütülen job'ların sırasını, akışı etkileyen koşulları ve build ortamı ayarlarını açıklar.\
-Bu dosyalar genelde tutarlı bir ad ve formatta olur; örneğin — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) ve .github/workflows altındaki GitHub Actions YAML dosyaları. Tetiklendiğinde pipeline job'ı seçilen kaynaktan (ör. commit / branch) **code'u çeker** ve CI configuration file içinde belirtilen komutları bu code'a karşı **çalıştırır**.
+Pipeline tanımlamanın en yaygın yolu, pipeline'ın build ettiği repository'de barındırılan bir **CI configuration file** kullanmaktır. Bu dosya, çalıştırılan job'ların sırasını, akışı etkileyen koşulları ve build environment ayarlarını tanımlar.\
+Bu dosyalar genellikle tutarlı bir isim ve formata sahiptir; örneğin — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) ve .github/workflows altında bulunan GitHub Actions YAML dosyaları. Tetiklendiğinde, pipeline job seçilen kaynaktan code'u **çeker** (örn. commit / branch) ve o code'a karşı CI configuration file'da belirtilen command'leri **çalıştırır**.
 
-Bu yüzden saldırganın nihai amacı bir şekilde bu configuration dosyalarını ya da **çalıştırdıkları komutları** **compromise etmek**tir.
+Bu nedenle attacker'ın nihai hedefi somehow bu **configuration file'ları compromise etmek** veya bunların çalıştırdığı **command'leri** ele geçirmektir.
 
 > [!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:
+> Bazı hosted builder'lar katkıda bulunanların Docker build context ve Dockerfile path seçmesine izin verir. Eğer context attacker-controlled ise, build sırasında host dosyalarını almak ve secrets'ları exfiltrate etmek için bunu repo dışına ayarlayabilirsiniz (örn. ".."). Şuraya bakın:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,57 +58,78 @@ Bu yüzden saldırganın nihai amacı bir şekilde bu configuration dosyaların
 
 ### PPE - Poisoned Pipeline Execution
 
-Poisoned Pipeline Execution (PPE) yolu, bir SCM repository içindeki izinleri kötüye kullanarak bir CI pipeline'ını manipüle etmeyi ve zararlı komutlar çalıştırmayı hedefler. Gerekli izinlere sahip kullanıcılar CI configuration dosyalarını veya pipeline job tarafından kullanılan diğer dosyaları değiştirerek kötü amaçlı komutlar ekleyebilir. Bu durum CI pipeline'ını "poison" eder ve bu kötü amaçlı komutların çalışmasına yol açar.
+Poisoned Pipeline Execution (PPE) yolu, bir SCM repository'sindeki permissions'ı istismar ederek bir CI pipeline'ını manipüle etmeyi ve zararlı command'ler çalıştırmayı hedefler. Gerekli permissions'a sahip kullanıcılar, CI configuration file'larını veya pipeline job tarafından kullanılan diğer dosyaları malicious command'ler içerecek şekilde değiştirebilir. Bu, CI pipeline'ını "zehirler" ve bu malicious command'lerin çalışmasına yol açar.
 
-Bir saldırganın PPE saldırısında başarılı olabilmesi için:
+Bir malicious actor'ın PPE attack'te başarılı olması için şunları yapabilmesi gerekir:
 
-- VCS platformunda **write access**e sahip olması gerekir; çünkü genelde pipeline'lar bir push veya pull request gerçekleştiğinde tetiklenir. (Erişim elde etme yolları için VCS pentesting methodology bölümüne bakın).
-- Bazen bir **external PR'in "write access" sayıldığı** unutulmamalıdır.
-- Write izinleri olsa bile, CI config dosyasını veya config'in rely ettiği diğer dosyaları **değiştirebileceğinden emin olması** gerekir.
-- Bunun için branch protections'ı **bypass edebilmesi** gerekebilir.
+- Genellikle pipeline'lar bir push veya pull request yapıldığında tetiklendiği için **VCS platformunda write access** sahibi olmak. (Access elde etme yollarının özeti için VCS pentesting methodology'ye bakın).
+- Bazen **external PR'nin "write access" sayıldığını** not edin.
+- Write permissions'ı olsa bile, **CI config file'ını veya config'in dayandığı diğer dosyaları modify edebilmesi** gerekir.
+- Bunun için branch protections'ı **bypass etmesi** gerekebilir.
 
-3 PPE çeşidi vardır:
+3 PPE türü vardır:
 
-- **D-PPE**: Bir **Direct PPE** saldırısı, aktörün yürütülecek CI config dosyasını **direkt olarak değiştirdiği** durumdur.
-- **I-DDE**: Bir **Indirect PPE** saldırısı, aktörün CI config dosyasının **rely ettiği** (ör. make file veya terraform config gibi) bir **dosyayı değiştirdiği** durumdur.
-- **Public PPE or 3PE**: Bazı durumlarda pipeline'lar repo içinde write access'i olmayan kullanıcılar tarafından (ve hatta org üyesi olmayanlar tarafından) gönderilen PR'lerle **tetiklenebilir**.
-- **3PE Command Injection**: Genelde CI/CD pipeline'ları PR hakkında bilgi içeren environment variable'lar **ayarlar**. Eğer bu değer bir saldırgan tarafından kontrol edilebiliyorsa (ör. PR başlığı gibi) ve **tehlikeli bir yerde** (ör. sh komutları çalıştırılan bir yerde) **kullanılıyorsa**, saldırgan oraya **komut enjekte edebilir**.
+- **D-PPE**: **Direct PPE** attack, actor'ın çalıştırılacak olan **CI config** file'ını **modifiye etmesi** durumunda meydana gelir.
+- **I-DDE**: **Indirect PPE** attack, actor'ın çalıştırılacak olan CI config file'ının **dayandığı bir file'ı modifiye etmesi** durumunda meydana gelir (örneğin bir make file veya terraform config).
+- **Public PPE or 3PE**: Bazı durumlarda pipeline'lar, repo'da write access'i olmayan kullanıcılar tarafından (hatta org'un parçası olmasalar bile) bir PR gönderebildikleri için tetiklenebilir.
+- **3PE Command Injection**: Genellikle CI/CD pipeline'lar PR ile ilgili **information** içeren environment variables **set** eder. Eğer bu value attacker tarafından kontrol edilebiliyorsa (PR'nin title'ı gibi) ve **dangerous place**'te kullanılıyorsa (örneğin **sh commands** çalıştırmak gibi), attacker burada command'ler **inject** edebilir.
 
 ### Exploitation Benefits
 
-Bir pipeline'ı zehirlemenin 3 çeşidini bildiğimize göre, saldırganın başarılı bir exploitation sonrasında neler elde edebileceğine bakalım:
+Pipeline'ı poison etmenin 3 türünü bildiğimize göre, başarılı bir exploitation sonrası attacker'ın neler elde edebileceğine bakalım:
 
-- **Secrets**: Daha önce de bahsedildiği gibi, pipeline job'ları code'u almak, build etmek, deploy etmek vb. için **privileges** gerektirir ve bu ayrıcalıklar genelde **secrets** içinde saklanır. Bu secrets genelde **env variables** veya sistem içindeki dosyalar aracılığıyla erişilebilir. Bu nedenle bir saldırgan mümkün olduğunca çok secrets exfiltrate etmeye çalışacaktır.
-- Pipeline platformuna bağlı olarak saldırgan **secret'ları config içinde belirtmek** zorunda olabilir. Bu, eğer saldırgan CI configuration pipeline'ını değiştiremiyorsa (**I-PPE** gibi), sadece o pipeline'ın sahip olduğu secrets'ları exfiltrate edebileceği anlamına gelir.
-- **Computation**: Code bir yerde çalıştırılır; çalıştırıldığı yere bağlı olarak saldırgan daha fazla pivot yapabilir.
-- **On-Premises**: Pipeline'lar on-premises çalıştırılıyorsa, saldırgan **daha fazla kaynağa erişimi olan internal bir ağa** ulaşabilir.
-- **Cloud**: Saldırgan diğer cloud makinelerine erişebileceği gibi IAM roles/service accounts **token'larını** exfiltrate ederek cloud içinde **daha fazla erişim** elde edebilir.
-- **Platforms machine**: Bazen job'lar pipeline platform makineleri içinde çalıştırılır; genelde bunlar cloud içinde olup **başka erişime sahip değildir**.
-- **Select it:** Bazı pipeline platformlarında **çeşitli makineler yapılandırılmış** olur ve eğer CI configuration dosyasını **değiştirebiliyorsanız** kodu **nerede çalıştırmak istediğinizi** belirtebilirsiniz. Bu durumda saldırgan, her mümkün makinede reverse shell çalıştırıp onlardan daha fazla exploit denemesi yapabilir.
-- **Compromise production**: Eğer pipeline içindeyseniz ve final versiyon pipeline'dan build edilip deploy ediliyorsa, production'da çalışacak olan code'u **compromise edebilirsiniz**.
+- **Secrets**: Daha önce belirtildiği gibi, pipeline job'ları için **privileges** gerekir (code'u almak, build etmek, deploy etmek...) ve bu privileges genellikle **secrets** içinde verilir. Bu secrets'a genellikle **env variables** veya sistem içindeki dosyalar üzerinden erişilebilir. Bu nedenle attacker her zaman mümkün olduğunca çok secret exfiltrate etmeye çalışacaktır.
+- Pipeline platformuna bağlı olarak attacker'ın **secrets'ları config içinde belirtmesi gerekebilir**. Bu, attacker CI configuration pipeline'ını modify edemiyorsa (**I-PPE** örneğin), **yalnızca pipeline'ın sahip olduğu secrets'ları exfiltrate edebileceği** anlamına gelir.
+- **Computation**: Code bir yerde execute edilir; nereye execute edildiğine bağlı olarak attacker daha ileri pivot yapabilir.
+- **On-Premises**: Pipeline'lar on premises çalıştırılıyorsa, attacker **daha fazla kaynağa erişimi olan bir internal network** içinde sonlanabilir.
+- **Cloud**: Attacker **cloud içindeki diğer makinelere** erişebilir, ayrıca cloud içinde **daha fazla access elde etmek için IAM roles/service accounts token'larını exfiltrate** edebilir.
+- **Platforms machine**: Bazen job'lar **pipelines platform makineleri** içinde execute edilir; bunlar genellikle cloud içindedir ve **daha fazla access** sunmaz.
+- **Select it:** Bazen **pipelines platformu birkaç makine yapılandırmış** olur ve eğer **CI configuration file'ını modify edebiliyorsanız**, malicious code'u nerede çalıştırmak istediğinizi **belirtebilirsiniz**. Bu durumda attacker muhtemelen her olası makinede bir reverse shell çalıştırıp daha fazla exploit etmeye çalışır.
+- **Compromise production**: Eğer pipeline içindeyseniz ve final version buradan build edilip deploy ediliyorsa, production'da çalışacak code'u **compromise edebilirsiniz**.
+
+### Dependency & Registry Supply-Chain Abuse
+
+Bir CI/CD pipeline'ını compromise etmek veya ondan credentials çalmak, attacker'ın **pipeline execution**'dan **ecosystem-wide code execution**'a geçmesine, dependencies veya release tooling'i backdoor'layarak izin verebilir:
+
+- **Install-time code execution via package hooks**: `preinstall`, `postinstall`, `prepare` veya benzeri hooks ekleyen bir package version'ı publish edin; böylece payload dependency installation sırasında developer workstation'larında ve CI runner'larında otomatik olarak çalışır.
+- **Secondary execution paths**: Target'lar `--ignore-scripts` ile install etse bile, malicious bir package `bin` field'ında **yaygın bir CLI name** kaydedebilir; böylece attacker-controlled wrapper `PATH` içine symlink edilir ve command kullanıldığında daha sonra execute edilir.
+- **Runtime bootstrapping**: Küçük bir installer, installation sırasında ikinci bir runtime veya toolchain download edebilir (örneğin Bun veya packed interpreter) ve ardından ana payload'ı onunla başlatabilir; böylece local dependency gereksinimlerini önler.
+- **Credential harvesting from build environments**: Code CI içinde çalıştıktan sonra environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI config'leri ve `gh auth token` gibi local tooling'i kontrol edin. GitHub Actions'ta ayrıca runner'a özgü secrets ve artifacts'a bakın.
+- **Workflow injection with stolen GitHub tokens**: **`repo` + `workflow`** permissions'a sahip bir token, bir branch oluşturmak, `.github/workflows/` içine malicious bir dosya commit etmek, onu tetiklemek, üretilen artifacts/log'ları toplamak ve ardından izleri azaltmak için geçici branch/workflow run'ını silmek için yeterlidir.
+- **Wormable registry propagation**: Çalınan npm token'larının **publish** permissions'ı ve 2FA'yı bypass edip etmediği doğrulanmalıdır. Eğer geçerliyse, yazılabilir package'ları enumerate edin, tarball'larını indirin, `setup.mjs` gibi bir loader inject edin, çalıştırmak için `preinstall` ayarlayın, patch version'ı artırın ve yeniden publish edin. Bu, tek bir CI compromise'ını diğer ortamlarda downstream auto-execution'a dönüştürür.
+
+#### Practical checks during an assessment
+
+- `package.json` içine eklenmiş package-manager hooks, beklenmeyen `bin` entries veya yalnızca release artifact'ini değiştiren version bump'lar için release automation'ı inceleyin.
+- CI'nin uzun ömürlü registry credentials'ı kısa ömürlü OIDC veya trusted publishing yerine `~/.npmrc` gibi plaintext dosyalarda saklayıp saklamadığını kontrol edin.
+- CI içindeki GitHub token'larının workflow dosyalarını yazıp yazamadığını veya branch/tag oluşturup oluşturamadığını doğrulayın.
+- Eğer compromised bir package'tan şüpheleniliyorsa, yalnızca Git repository'yi değil, published tarball'ı da inceleyin; çünkü malicious loader/runtime yalnızca published artifact içinde bulunabilir.
+- CI içinde `npm install` yerine `npm ci`, beklenmeyen Bun download/execute işlemleri veya transient branch'lerden üretilen yeni workflow artifact'leri gibi beklenmeyen package-manager execution'ını araştırın.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) açık kaynak bir araçtır ve yeni bir [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) temelinde yazılım tedarik zinciri yığınıınızı güvenlik uyumluluğu açısından denetler. Denetim, kod zamanından deploy zamanına kadar tüm SDLC sürecine odaklanır ve riskleri ortaya çıkarabilir.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench), [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) tabanlı olarak software supply chain stack'inizin security compliance'ını denetlemek için açık kaynaklı bir tool'dur. Auditing, tüm SDLC process'ine odaklanır ve code time'dan deploy time'a kadar riskleri ortaya çıkarabilir.
 
 ### Top 10 CI/CD Security Risk
 
-Cider'a göre top 10 CI/CD risklerini anlatan ilginç makaleyi inceleyin: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Cider'a göre en önemli 10 CI/CD riskini anlatan şu ilginç makaleyi inceleyin: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Her platform için lokal olarak çalıştırılabilecek lab'larda nasıl başlatılacağı gösterilir; böylece istediğiniz gibi yapılandırıp test edebilirsiniz
+- Local olarak çalıştırabileceğiniz her platformda, nasıl local başlatılacağını bulacaksınız; böylece test etmek istediğiniz şekilde yapılandırabilirsiniz
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov**, infrastructure-as-code için statik kod analiz aracı.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov**, infrastructure-as-code için bir static code analysis tool'udur.
 
 ## 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}}