From 11abf8adf2a63920c4bbb2e975d21a3d79e013fa Mon Sep 17 00:00:00 2001 From: Translator Date: Sun, 31 Aug 2025 08:23:30 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/gitblit-security/README.md', 'src/pent --- .../gitblit-security/README.md | 21 ++++ ...embedded-ssh-auth-bypass-cve-2024-28080.md | 107 ++++++++++++++++++ .../pentesting-ci-cd-methodology.md | 103 +++++++++-------- 3 files changed, 181 insertions(+), 50 deletions(-) create mode 100644 src/pentesting-ci-cd/gitblit-security/README.md create mode 100644 src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md diff --git a/src/pentesting-ci-cd/gitblit-security/README.md b/src/pentesting-ci-cd/gitblit-security/README.md new file mode 100644 index 000000000..ab3121bf2 --- /dev/null +++ b/src/pentesting-ci-cd/gitblit-security/README.md @@ -0,0 +1,21 @@ +# Gitblit セキュリティ + +{{#include ../../banners/hacktricks-training.md}} + +## Gitblit とは + +GitblitはJavaで書かれた自己ホスト型のGitサーバーです。スタンドアロンのJARとして実行するか、サーブレットコンテナ内で動作させることができ、Git over SSH用の組み込みSSHサービス（Apache MINA SSHD）を同梱しています。 + +## トピック + +- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080) + +{{#ref}} +gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md +{{#endref}} + +## 参考 + +- [Gitblit project](https://gitblit.com/) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md new file mode 100644 index 000000000..a4d90c225 --- /dev/null +++ b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md @@ -0,0 +1,107 @@ +# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080) + +{{#include ../../banners/hacktricks-training.md}} + +## 概要 + +CVE-2024-28080 は、Apache MINA SSHD と統合する際のセッション状態ハンドリングの誤りに起因する、Gitblit の組み込み SSH サービスにおける認証バイパスです。ユーザーアカウントに少なくとも 1 つの SSH public key が登録されている場合、攻撃者が該当ユーザーの username とその public key のいずれかを知っていれば、private key や password なしで認証できます。 + +- 影響を受けるバージョン: Gitblit < 1.10.0 (1.9.3 で確認) +- 修正バージョン: 1.10.0 +- 悪用に必要な条件: + - インスタンスで Git over SSH が有効になっていること + - 被害者アカウントに少なくとも 1 つの SSH public key が Gitblit に登録されていること + - 攻撃者が被害者の username とその public key のいずれかを知っていること（公開されていることが多い、例: https://github.com/.keys） + +## 根本原因 (state leaks between SSH methods) + +RFC 4252 によれば、public‑key authentication は 2 段階で進行します: サーバは最初に提示された public key が username に対して受け入れ可能かをチェックし、クライアントが署名で応答した後にユーザーを認証します。MINA SSHD では、PublickeyAuthenticator が 2 回呼ばれます: key acceptance（まだ署名なし）時と、クライアントが署名を返した後です。 + +Gitblit の PublickeyAuthenticator は、署名前の最初の呼び出しでセッションコンテキストを変更し、UserModel をセッションにバインドして true（"key acceptable"）を返していました。後に認証が password にフォールバックした際、PasswordAuthenticator はその変更されたセッション状態を信頼して処理をスキップし、password の検証なしに true を返しました。その結果、同じユーザーに対して public‑key の "acceptance" が先に起きていれば、任意の password（空も含む）が受け入れられてしまいました。 + +高レベルの欠陥の流れ: + +1) クライアントが username + public key を提示（まだ署名なし） +2) サーバがその key がユーザーに属すると認識し、ユーザーをセッションに早期に紐付けして true（"acceptable"）を返す +3) クライアントは署名できない（private key がない）ため、認証は password にフォールバックする +4) PasswordAuthenticator はセッションに既にユーザーが存在するのを検出し、無条件に成功を返す + +## ステップごとの悪用 + +- 被害者の username とその public key の 1 つを収集する: + - GitHub は公開鍵を https://github.com/.keys で公開している + - 公開サーバはしばしば authorized_keys を公開している +- OpenSSH を設定して public half のみを提示するようにし、署名生成を失敗させることで password へのフォールバックを強制しつつ、サーバ側では public‑key acceptance パスをトリガーさせる + +Example SSH client config (no private key available): +```sshconfig +# ~/.ssh/config +Host gitblit-target +HostName +User +PubkeyAuthentication yes +PreferredAuthentications publickey,password +IdentitiesOnly yes +IdentityFile ~/.ssh/victim.pub # public half only (no private key present) +``` +接続し、パスワードプロンプトで Enter キーを押してください（または任意の文字列を入力してください）: +```bash +ssh gitblit-target +# or Git over SSH +GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://@/ +``` +認証が成功するのは、前段の public‑key フェーズがセッションを認証済みユーザーに変更（mutated）してしまい、password auth がその状態を誤って信頼するためです。 + +Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact. + +## Impact + +- 少なくとも1つの登録された SSH public key を持つ任意の Gitblit ユーザーの完全ななりすまし +- 被害者の権限に応じたリポジトリへの読み書きアクセス（source exfiltration、unauthorized pushes、supply‑chain risks） +- admin ユーザーを狙った場合、管理者権限に対する影響の可能性 +- 純粋なネットワーク脆弱性；brute force も private key も不要 + +## Detection ideas + +- SSH ログを確認し、publickey 試行の後に空または非常に短いパスワードでの成功した password authentication が続くようなシーケンスを探す +- フローを探す: publickey method がサポート外／不一致のキー素材を提示した後、同じユーザー名に対して即座に password が成功する流れ + +## Mitigations + +- Upgrade to Gitblit v1.10.0+ +- Until upgraded: +- Disable Git over SSH on Gitblit, or +- Restrict network access to the SSH service, and +- Monitor for suspicious patterns described above +- Rotate affected user credentials if compromise is suspected + +## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services) + +Pattern: If a server’s public‑key authenticator mutates user/session state during the pre‑signature "key acceptable" phase and other authenticators (e.g., password) trust that state, you can bypass authentication by: + +- 対象ユーザーの正当な public key を提示する（private key は不要） +- クライアントに署名を失敗させてサーバが password にフォールバックするようにする +- password authenticator が leaked state によりショートサーキットする間に任意の password を供給する + +Practical tips: + +- Public key harvesting at scale: pull public keys from common sources such as https://github.com/.keys, organizational directories, team pages, leaked authorized_keys +- Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password +- MINA SSHD integration pitfalls: +- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature +- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method + +Related protocol/design notes and literature: +- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process) +- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior + +## References + +- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/) +- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0) +- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/) +- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html) +- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252) + + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 2ac1cbd0d..8ad1f60eb 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -1,4 +1,4 @@ -# Pentesting CI/CD Methodology +# Pentesting CI/CD 方法論 {{#include ../banners/hacktricks-training.md}} @@ -6,99 +6,102 @@ ## VCS -VCSは**Version Control System**の略で、このシステムは開発者が**ソースコードを管理する**ことを可能にします。最も一般的なものは**git**で、企業は通常以下の**プラットフォーム**のいずれかで使用しています： +VCS は **Version Control System** の略で、このシステムは開発者が **ソースコードを管理** することを可能にします。最も一般的なのは **git** で、企業は通常次のような **platforms** のいずれかで利用しています: - Github - Gitlab - Bitbucket - Gitea -- クラウドプロバイダー（独自のVCSプラットフォームを提供） +- Gitblit +- Cloud providers (they offer their own VCS platforms) + ## CI/CD Pipelines -CI/CDパイプラインは、開発者が**コードの実行を自動化する**ことを可能にし、アプリケーションのビルド、テスト、デプロイなどのさまざまな目的に使用されます。これらの自動化されたワークフローは、コードのプッシュ、プルリクエスト、またはスケジュールされたタスクなどの**特定のアクションによってトリガーされます**。これにより、開発から本番環境へのプロセスが効率化されます。 +CI/CD pipelines は、ビルド、テスト、デプロイなどの目的でコードの実行を **自動化** することを可能にします。これらの自動化されたワークフローは、コードの push、pull request、スケジュールされたタスクなど、特定のアクションによって **トリガー** されます。開発から本番への流れを効率化するのに有用です。 -ただし、これらのシステムは**どこかで実行される必要があり**、通常は**コードをデプロイしたり、機密情報にアクセスするための特権的な資格情報が必要です**。 +ただし、これらのシステムはどこかで **実行される必要があり**、通常はコードをデプロイしたり機密情報にアクセスしたりするための **特権付き資格情報** が必要になります。 -## VCS Pentesting Methodology +## VCS Pentesting 方法論 > [!NOTE] -> 一部のVCSプラットフォームがパイプラインを作成することを許可している場合でも、このセクションではソースコードの制御に対する潜在的な攻撃のみを分析します。 +> 一部の VCS platforms がパイプラインを作成できる場合でも、このセクションではソースコードの制御に対する潜在的な攻撃のみを分析します。 -プロジェクトのソースコードを含むプラットフォームは機密情報を含んでおり、人々はこのプラットフォーム内で付与された権限に非常に注意する必要があります。攻撃者が悪用できるVCSプラットフォーム全体での一般的な問題は以下の通りです： +プロジェクトのソースコードを含むプラットフォームには機密情報が含まれるため、プラットフォーム内で付与される権限には細心の注意が必要です。以下は攻撃者が悪用し得る VCS platforms に共通する問題点です: -- **Leaks**: コードにコミット内の漏洩が含まれており、攻撃者がリポジトリにアクセスできる場合（公開されているか、アクセス権を持っている場合）、漏洩を発見する可能性があります。 -- **Access**: 攻撃者が**VCSプラットフォーム内のアカウントにアクセスできる場合**、**より多くの可視性と権限を得ることができます**。 -- **Register**: 一部のプラットフォームでは、外部ユーザーがアカウントを作成することを許可します。 -- **SSO**: 一部のプラットフォームではユーザーの登録を許可しませんが、有効なSSOでアクセスすることは許可します（例えば、攻撃者が自分のgithubアカウントを使用して入ることができます）。 -- **Credentials**: ユーザー名+パスワード、個人トークン、sshキー、Oauthトークン、クッキー... ユーザーがリポジトリにアクセスするために盗むことができるトークンの種類はさまざまです。 -- **Webhooks**: VCSプラットフォームはウェブフックを生成することを許可します。これらが**見えない秘密で保護されていない場合、攻撃者がそれを悪用する可能性があります**。 -- 秘密が設定されていない場合、攻撃者はサードパーティプラットフォームのウェブフックを悪用する可能性があります。 -- 秘密がURLに含まれている場合も同様で、攻撃者は秘密を持っています。 -- **Code compromise:** 悪意のある行為者がリポジトリに対して**書き込み**アクセスを持っている場合、**悪意のあるコードを注入しようとする可能性があります**。成功するためには、**ブランチ保護を回避する**必要があるかもしれません。これらの行動は、さまざまな目的を持って実行される可能性があります： -- メインブランチを妥協して**本番環境を妥協する**。 -- メイン（または他のブランチ）を妥協して**開発者のマシンを妥協する**（彼らは通常、テスト、terraform、または他の作業を自分のマシン内のリポジトリで実行します）。 -- **パイプラインを妥協する**（次のセクションを確認）。 +- **Leaks**: コードのコミットに leaks が含まれていて、攻撃者がリポジトリにアクセスできる（公開リポジトリであるかアクセス権を持つ場合）と、その leaks を発見する可能性があります。 +- **Access**: 攻撃者が **VCS platform 内のアカウントにアクセスできる**場合、より多くの可視性と権限を得ることができます。 +- **Register**: 一部のプラットフォームでは外部ユーザがアカウントを作成できます。 +- **SSO**: 一部のプラットフォームはユーザ登録を許可しないが、有効な SSO であれば誰でもアクセスできる（例えば攻撃者が自分の github アカウントを使って入ることができる）。 +- **Credentials**: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies... ユーザがリポジトリにアクセスするために盗めるトークンの種類は複数あります。 +- **Webhooks**: VCS platforms は webhooks を生成できます。これらが非公開の secrets で保護されていない場合、攻撃者が悪用する可能性があります。 +- 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:** 悪意ある主体がリポジトリに対して何らかの **write** アクセスを持っている場合、**悪意あるコードを注入** しようとする可能性があります。成功するためには **branch protections をバイパス** する必要があることがあります。これらの行為は、目的に応じてさまざまな影響をもたらします: + - メインブランチを改ざんして **compromise production**。 + - メイン（または他の）ブランチを改ざんして **compromise developers machines**（開発者は通常テスト、terraform、その他をリポジトリ内から自身のマシンで実行するため）。 + - **Compromise the pipeline**（次のセクションを参照） -## Pipelines Pentesting Methodology +## Pipelines Pentesting 方法論 -パイプラインを定義する最も一般的な方法は、パイプラインがビルドする**リポジトリにホストされたCI構成ファイルを使用する**ことです。このファイルは、実行されるジョブの順序、フローに影響を与える条件、およびビルド環境の設定を記述します。\ -これらのファイルは通常、一貫した名前と形式を持ち、例えば — Jenkinsfile（Jenkins）、.gitlab-ci.yml（GitLab）、.circleci/config.yml（CircleCI）、および.github/workflowsの下にあるGitHub Actions YAMLファイルです。トリガーされると、パイプラインジョブは**選択されたソースからコードをプルし**、そのコードに対して**CI構成ファイルに指定されたコマンドを実行します**。 +パイプラインを定義する最も一般的な方法は、パイプラインが構築するリポジトリにホストされた **CI configuration file** を使用することです。このファイルは実行されるジョブの順序、フローに影響する条件、ビルド環境の設定を記述します。\ +これらのファイルは通常一貫した名前と形式を持ちます。例えば — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)、および .github/workflows 配下の GitHub Actions の YAML ファイルなどです。トリガーされると、パイプラインジョブは選択されたソース（例: commit / branch）から **コードを pull** し、CI configuration file に指定されたコマンドをそのコードに対して **実行** します。 -したがって、攻撃者の最終的な目標は、何らかの方法で**これらの構成ファイル**または**それらが実行するコマンドを妥協する**ことです。 +したがって、攻撃者の最終的な目的はこれらの設定ファイルを何らかの方法で **compromise** するか、それらが実行する **コマンドを改変** することになります。 ### PPE - Poisoned Pipeline Execution -Poisoned Pipeline Execution（PPE）パスは、SCMリポジトリ内の権限を悪用してCIパイプラインを操作し、有害なコマンドを実行します。必要な権限を持つユーザーは、CI構成ファイルやパイプラインジョブで使用される他のファイルを変更して悪意のあるコマンドを含めることができます。これにより、CIパイプラインが「汚染」され、これらの悪意のあるコマンドが実行されます。 +Poisoned Pipeline Execution (PPE) パスは、SCM リポジトリの権限を悪用して CI パイプラインを操作し、有害なコマンドを実行させる攻撃手法です。必要な権限を持つユーザは CI 設定ファイルやパイプラインジョブで使用される他のファイルを変更して悪意あるコマンドを含めることができます。これにより CI パイプラインが「汚染」され、これらの悪意あるコマンドが実行されます。 -悪意のある行為者がPPE攻撃を成功させるためには、以下のことができる必要があります： +攻撃者が PPE 攻撃を成功させるには、次のことが必要です: -- **VCSプラットフォームへの書き込みアクセスを持つ**必要があります。通常、パイプラインはプッシュまたはプルリクエストが行われたときにトリガーされます。（アクセスを得る方法の概要についてはVCSペンテスティング方法論を確認してください）。 -- 時には**外部PRが「書き込みアクセス」としてカウントされる**ことに注意してください。 -- 書き込み権限があっても、**CI構成ファイルや構成が依存している他のファイルを変更できることを確認する必要があります**。 -- そのためには、**ブランチ保護を回避する**必要があるかもしれません。 +- **write access to the VCS platform** を持っていること。通常、パイプラインは push や pull request が行われたときにトリガーされます。（アクセスを得る方法の概要は VCS pentesting methodology を参照してください） +- 場合によっては **external PR が "write access" と見なされる**ことがある点に注意してください。 +- たとえ write 権限があっても、CI config ファイルやその設定が依存している他のファイルを **実際に変更できる**ことを確認する必要があります。 +- そのために、**branch protections をバイパス** できる必要がある場合があります。 -PPEには3つのフレーバーがあります： +PPE には 3 つのバリエーションがあります: -- **D-PPE**: **Direct PPE**攻撃は、行為者が**実行されるCI構成**ファイルを**変更する**ときに発生します。 -- **I-DDE**: **Indirect PPE**攻撃は、行為者が**実行されるCI構成ファイルが依存している**ファイル（makeファイルやterraform構成など）を**変更する**ときに発生します。 -- **Public PPEまたは3PE**: 場合によっては、パイプラインは**リポジトリに書き込みアクセスを持たないユーザーによってトリガーされる**ことがあります（彼らは組織の一部でない可能性もあります）なぜなら、彼らはPRを送信できるからです。 -- **3PE Command Injection**: 通常、CI/CDパイプラインは**PRに関する情報を持つ環境変数を設定します**。その値が攻撃者によって制御でき（PRのタイトルのように）、**危険な場所で使用される**場合（**shコマンドを実行する**など）、攻撃者は**そこにコマンドを注入する**可能性があります。 +- **D-PPE**: Direct PPE。攻撃者が実行される CI 設定ファイル自体を **直接変更** する場合。 +- **I-DDE**: Indirect PPE。攻撃者がCI設定ファイルが依存している **ファイル（makefile や terraform 設定など）を変更** する場合。 +- **Public PPE or 3PE**: 場合によっては、リポジトリに対する write アクセスがないユーザ（組織のメンバーでないユーザ）が PR を送ることでパイプラインが **トリガーされる**ことがあります。 +- **3PE Command Injection**: 通常、CI/CD パイプラインは PR に関する情報を含む環境変数を **設定** します。もしその値が攻撃者により制御可能（例: PR のタイトル）で、かつ **危険な場所**（例: sh commands を実行する箇所）で **使用される**場合、攻撃者はその中にコマンドを **注入** できる可能性があります。 ### Exploitation Benefits -パイプラインを汚染する3つのフレーバーを知ることで、攻撃者が成功した悪用の後に得られるものを確認しましょう： +PPE の 3 種類を理解した上で、攻撃が成功した場合に攻撃者が得られるものを見ていきます: -- **Secrets**: 前述のように、パイプラインはそのジョブに**特権**を必要とします（コードを取得し、ビルドし、デプロイする...）これらの特権は通常**秘密に付与されます**。これらの秘密は通常、**環境変数やシステム内のファイルを介してアクセス可能です**。したがって、攻撃者は常にできるだけ多くの秘密を流出させようとします。 -- パイプラインプラットフォームによっては、攻撃者が**構成内で秘密を指定する必要がある**場合があります。これは、攻撃者がCI構成パイプラインを変更できない場合（例えば**I-PPE**）、そのパイプラインが持つ秘密のみを**流出させることができる**ことを意味します。 -- **Computation**: コードはどこかで実行され、実行される場所によっては、攻撃者がさらにピボットできる可能性があります。 -- **On-Premises**: パイプラインがオンプレミスで実行される場合、攻撃者は**より多くのリソースにアクセスできる内部ネットワークに到達する可能性があります**。 -- **Cloud**: 攻撃者は**クラウド内の他のマシンにアクセスする**ことができるだけでなく、**IAMロール/サービスアカウントのトークンを流出させて**、**クラウド内でさらにアクセスを得る**ことができます。 -- **Platforms machine**: 時には、ジョブが**パイプラインプラットフォームのマシン内で実行される**ことがあり、通常は**他のアクセスがない**クラウド内にあります。 -- **Select it:** 時には、**パイプラインプラットフォームが複数のマシンを構成している**ことがあり、CI構成ファイルを**変更できれば、悪意のあるコードを実行したい場所を指定できます**。この状況では、攻撃者はおそらく各可能なマシンでリバースシェルを実行して、さらに悪用しようとします。 -- **Compromise production**: パイプライン内にいて、最終バージョンがそこからビルドされてデプロイされる場合、**本番環境で実行されるコードを妥協する**ことができます。 +- **Secrets**: 前述の通り、パイプラインのジョブはコードの取得、ビルド、デプロイなどのために **特権** を必要とし、これらの特権は通常 **secrets** によって付与されます。これらの secrets は **env variables やシステム内のファイル** を通じてアクセス可能であることが多いため、攻撃者は可能な限り多くの secrets を持ち出そうとします。 +- パイプラインプラットフォームによっては、攻撃者が CI 設定を変更できない場合（例: I-PPE）、攻撃者は **そのパイプラインが持つ secrets のみ** を持ち出すことしかできない場合があります。 +- **Computation**: コードはどこかで実行されるため、実行場所によっては攻撃者がさらなるピボットを行える可能性があります。 +- **On-Premises**: パイプラインがオンプレで実行されている場合、攻撃者は内部ネットワーク内でより多くのリソースにアクセスできる立場になる可能性があります。 +- **Cloud**: 攻撃者はクラウド内の他のマシンにアクセスできるだけでなく、IAM ロールやサービスアカウントのトークンを持ち出してクラウド内でさらに権限を拡大する可能性があります。 +- **Platforms machine**: ジョブがパイプラインプラットフォームのマシン内で実行される場合、これらは通常クラウド上で他のリソースにアクセスしないように設定されていることもあります。 +- **Select it:** パイプラインプラットフォームが複数の実行マシンを用意している場合、CI 設定ファイルを変更できれば悪意あるコードをどのマシンで実行するか **指定できる**ことがあります。この場合、攻撃者は各マシンにリバースシェルを張ってさらに侵害を試みることが考えられます。 +- **Compromise production**: パイプライン内に侵入し、そのパイプラインから最終版がビルド・デプロイされる場合、本番環境で実行されるコードを改ざんすることができます。 -## More relevant info +## さらに関連情報 ### Tools & CIS Benchmark -- [**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)に基づいています。監査は、コードのタイミングからデプロイのタイミングまでのリスクを明らかにするSDLCプロセス全体に焦点を当てています。 +- [**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) に基づいてセキュリティ準拠をチェックするオープンソースツールです。監査は SDLC 全体に焦点を当て、コード段階からデプロイ段階までのリスクを明らかにします。 ### Top 10 CI/CD Security Risk -Ciderによるトップ10のCI/CDリスクに関する興味深い記事を確認してください：[**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Cider による CI/CD の上位 10 リスクに関する興味深い記事を確認してください: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- 各プラットフォームでローカルに実行できるものには、テストするために構成できるようにローカルで起動する方法が記載されています。 -- Gitea + Jenkinsラボ：[https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) +- ローカルで実行できる各プラットフォームごとに、ローカルでの起動方法が記載されているので、自分で設定してテストできます +- 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**は、インフラストラクチャコードの静的コード分析ツールです。 +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** は 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) + {{#include ../banners/hacktricks-training.md}}