
リスク管理、コンプライアンス、監査のためのGRCプラットフォーム。200以上のフレームワーク、自動コントロールマッピング、脆弱性管理、インシデント対応ワークフローを備えています。
プロジェクトにスターを付けて🌟、リリース通知を受け取り、コミュニティの成長を支援しましょう!
intuitem.com
·
SaaS 無料トライアル
·
ロードマップ
·
ドキュメント
·
言語
·
Discord
·
フレームワーク

CISO Assistant は、サイバーセキュリティ管理と GRC(ガバナンス、リスク、コンプライアンス)プラクティスに新たな視点をもたらします:

私たちのビジョンは、サイバーセキュリティ管理のための ワンストップショップ を創り、簡素化 と 相互運用性 を通じて GRC を近代化することです。
サイバーセキュリティおよび IT プロフェッショナルと協働する実務家として、私たちは同じ課題に直面してきました:ツールの断片化、データの重複、直感的で統合されたソリューションの欠如。CISO Assistant はそうした教訓から生まれ、実用的 で 常識的 な原則に基づくコミュニティを築いています。
私たちはユーザーや顧客からの意見を取り入れながら常に進化しています。タコのように 🐙、CISO Assistant は新たな腕を伸ばし続け、サイバーセキュリティチームに明確さ、自動化、生産性をもたらし、データの入力と出力の手間を軽減します。
[!TIP] 最も簡単に始める方法は、こちらで利用可能なクラウドインスタンスの無料トライアルです。
あるいは、ワークステーションまたはサーバーに Docker と Docker-compose がインストールされている場合:
リポジトリをクローンします:```sh git clone --single-branch -b main https://github.com/intuitem/ciso-assistant-community.git
スタータースクリプトを実行します```sh
./docker-compose.sh # Linux/MacOS
./docker-compose.ps1 # Windows
セルフホスティングのその他のインストールオプションをお探しの場合は、config builder と docs をご確認ください。
[!NOTE] docker-compose スクリプトは、ほとんどの標準的なハードウェアアーキテクチャをサポートするビルド済み Docker イメージを使用します。 Windows をお使いの場合は、WSL2 対応の Docker Desktop がインストールされていることを確認し、PowerShell スクリプトを実行してください。お客様に代わって Docker Desktop にフィードされます。
docker compose ファイルは、セットアップに合わせて追加のパラメータ(例:メーラー設定)を渡すように調整できます。
[!WARNING] イメージのプラットフォームがホストプラットフォームと一致しないという警告やエラーが発生した場合は、詳細を添えて issue を立ててください。すぐに対応します。また、お使いのアーキテクチャ向けにビルドするには、代わりに
docker-compose-build.shを使用することもできます(以下を参照)。
[!CAUTION]
mainブランチのコードは、開発中のマージ先であり、破壊的な変更が含まれる可能性があるため、本番環境で直接使用しないでください。安定版にはtagsを使用するか、ビルド済みイメージを使用してください。

コンプライアンスとフレームワーク
リスク管理
サードパーティリスク
運用と修復
レポートと分析
コラボレーションと生産性
自動化と統合
セキュリティとアクセス
プライバシー
プログラム管理
プラットフォーム
今後の機能はロードマップに掲載されています。
CISO Assistant は、サイバーセキュリティ、クラウド、データ/AI を専門とする企業 Intuitem によって開発・保守されています。
以下は、再利用性を促進する分離(デカップリング)の概念を説明するための、CISO Assistant の構成要素の抜粋です:

詳細については、データモデルのドキュメントをご確認ください。
CISO Assistant の中心にあるのは 分離の原則 であり、これにより強力なユースケースと大幅な時間短縮が可能になります:
以下は 分離 の原則とその利点を示す図です:
https://github.com/user-attachments/assets/87bd4497-5cc2-4221-aeff-396f6b6ebe62

オンラインドキュメントは https://intuitem.gitbook.io/ciso-assistant をご確認ください。
詳細はこちらをご覧ください:AI エンジン
[!NOTE]
*が付いたフレームワークは、ライセンスにより直接使用が禁止されているため、最新の Excel シートを各社の Web サイトから取得するという追加の手動ステップが必要です。Excel シートはライブラリとして直接読み込むことができます。
使用されているドメイン固有言語と独自の定義方法については、library と tools をご確認ください。
Indonesia PDP 🇮🇩
OWASP SAMM
COBAC R-2024/01
ICO Data protection self-assessment 🇬🇧
ASD ISM 🇦🇺
その他多数:Discord でお問い合わせください。オープンスタンダードであれば、無償で 対応いたします 😉
ライブラリは、フレームワーク、脅威カタログ、参照管理策のセット、あるいはカスタムリスクマトリクスを表すことができます。
ライブラリは Excel ファイルから直接 読み込めるようになりました。事前に手動で YAML に変換する必要はありません。Excel ファイルがアップロードされると、変換は内部的に処理されます。
tools ディレクトリとその専用 README をご覧ください。Excel 形式のライブラリソースファイルの想定フォーマットについて説明しています。excel サブディレクトリには、既存のライブラリのソースとして使用されている XLSX ファイルの例が含まれており、独自のライブラリを作成するためのテンプレートとして使用できます。
Excel ファイルからライブラリを読み込むには、Governance → Library ページに移動し、Load をクリックして Excel ソースファイルを選択します。検証エラーや解析エラーはインポートプロセス中に報告されます。
Excel ファイルを直接読み込むこともできますが、外部の Python スクリプトを使用してライブラリソースファイルを YAML に変換することも可能です:
convert_library_v2.py は、シンプルな Excel ファイルからライブラリを生成するのに役立ちます。アイテムが想定されたフォーマットで構造化されたら、スクリプトを実行して対応する YAML ファイルを生成します。tools ディレクトリには、特定のフレームワーク(例えば CIS や CCM Controls)用の専用コンバータも含まれています。フレームワーク間のマッピングの作成を容易にするために、prepare_mapping_v2.py ツールを使用できます。これは、YAML 形式の 2 つの既存のフレームワークライブラリに基づいて Excel ファイルを生成します。マッピングを記入した後、生成された Excel ファイルは以下のことができます:
convert_library_v2.py を使用して YAML に変換する。オープンな Discord コミュニティに参加して、チームや他の GRC エキスパートと交流しましょう。
最も迅速かつ簡単に始める方法は、こちらで利用可能なクラウドインスタンスの無料トライアルです。
CISO Assistant をローカルで簡単に実行するには、Docker compose を使用できます。
最新バージョンの docker(>= 27.0)があることを確認してください。
2. ビルド済みイメージ用の docker-compose スクリプトを起動します:```sh
./docker-compose.sh # Linux/MacOS
./docker-compose.ps1 # Windows
あるいは、特定のアーキテクチャ用の Docker イメージをビルドするには、このバリアントを使用できます:```sh ./docker-compose-build.sh # Linux/MacOS ./docker-compose-build.ps1 # Windows
スーパーユーザーのメールアドレスとパスワードを求められたら入力してください。
その後、Webブラウザで [https://localhost:8443/](https://localhost:8443/) にアクセスすると CISO Assistant に到達できます。
以降の実行では、直接「docker compose up」を使用してください。
## 開発用に CISO Assistant をセットアップする
> [!WARNING]
>
> ### Windows ユーザー向けの重要な注意事項
>
> **Windows** で開発するユーザーにとって最も確実に動作するソリューションは、[WSL2](https://apps.microsoft.com/detail/9p9tqf7mrm4r) 上にインストールされた [Ubuntu](https://apps.microsoft.com/detail/9pdxgncfsczv) を使用することです(Docker は不要です)。
>
> 現在では、WSL2 も Docker も使わずに Windows 上でネイティブに CISO Assistant を実行・開発することも可能ですが、いくつかの追加手順が必要です。
> Windows 上でのネイティブ実行はまだ**実験的フェーズ**にあり、自分が何をしているか確信が持てない場合や、開発を通じて安定性を確保したい場合は**使用しないでください**。
> とはいえ、Windows ユーザーの開発体験を向上させるための提案をぜひお聞かせください。Issue/PR を気軽に作成してください!
### 要件
- Python 3.14+
- pip 25.3+
- uv 0.9+
- node 24+
- npm 10.2+
- pnpm 10.30+
- yaml-cpp (`brew install yaml-cpp libyaml` または `apt install libyaml-cpp-dev`)
<details>
<summary>[EXPERIMENTAL] WSL2 なしで Windows 上で開発する場合の追加要件</summary>
WSL2 なしでプロジェクトを開発したい場合は、[MSYS2](https://www.msys2.org/) をインストールし、`MSYS2 UCRT64` のバイナリを[システム PATH 環境変数](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_environment_variables?view=powershell-7.6#set-environment-variables-in-the-system-control-panel)に追加し(通常、バイナリは `C:\msys64\ucrt64\bin` にあります)、その後 `MSYS2 UCRT64` を使用して `pacman` 経由で以下の依存関係をインストールする必要があります。```sh
pacman -S mingw-w64-ucrt-x86_64-file mingw-w64-ucrt-x86_64-pango
依存関係をインストールした後、以下の2つのシステム環境変数も追加する必要があります:```conf
MAGIC=Full path to the magic.mgc file (usually C:\msys64\ucrt64\share\misc\magic.mgc)
WEASYPRINT_DLL_DIRECTORIES=Same path as your MSYS2 UCRT64 binaries
Windows のデフォルトエンコーディングは `UTF-8` ではなく `cp1252` であるため、絵文字などの `UTF-8` 文字を出力する特定の Python スクリプトは、場合によっては(例えばライブラリのインポート時などに)バックエンドのクラッシュや誤動作を引き起こす可能性があります。
このプロジェクトでこの問題を回避するには、次の 2 つのユーザー環境変数を追加して `UTF-8` エンコーディングを強制してください:```conf
PYTHONUTF8=1
PYTHONIOENCODING=utf-8:replace
[!NOTE]
既知の問題
- Windows 上の
libmagicライブラリ(MIME 検出)は、Excel ファイル(.xlsx)の最初の2048ビットを読み取って認識しようとすると、Excel ライブラリをインポートする際にほとんどの場合application/octet-streamを返します(バックエンドは警告メッセージ[warning ] Invalid MIME typeを表示します)。これはbackend/library/views.py:StoredLibraryViewSet.upload_libraryのフォールバックメソッドのおかげで、Excel ファイルのインポートを妨げるものではありません。
2. 親フォルダにファイル(例: ../myvars)を作成し、以下のコードをコピーして変更したうえで `"<XXX>"` をあなたのプライベートな値に置き換えて、環境変数をそのファイル内に保存します。このファイルを git リポジトリにコミットしないよう注意してください。
**必須変数**
バックエンドのすべての変数には便利なデフォルト値があります。
**推奨変数**```sh
export DJANGO_DEBUG=True
# Default url is set to http://localhost:5173 but you can change it, e.g. to use https with a caddy proxy
export CISO_ASSISTANT_URL=https://localhost:8443
# Setup a development mailer with Mailpit for example
export EMAIL_HOST_USER=''
export EMAIL_HOST_PASSWORD=''
export [email protected]
export EMAIL_HOST=localhost
export EMAIL_PORT=1025
export EMAIL_USE_TLS=True # true for STARTTLS
export EMAIL_USE_SSL=False # true for SMTPS
その他の変数```sh
export POSTGRES_NAME=ciso-assistant export POSTGRES_USER=ciso-assistantuser export POSTGRES_PASSWORD= export POSTGRES_PASSWORD_FILE= # alternative way to specify password export DB_HOST=localhost export DB_PORT=5432 # optional, default value is 5432
export USE_S3=True export AWS_STORAGE_BUCKET_NAME= export AWS_S3_REGION_NAME= # optional, e.g., us-east-1
export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY= export AWS_S3_ENDPOINT_URL= # required for S3-compatible services (e.g., MinIO)
export EMAIL_HOST_RESCUE= export EMAIL_PORT_RESCUE=587 export EMAIL_HOST_USER_RESCUE= export EMAIL_HOST_PASSWORD_RESCUE= export EMAIL_USE_TLS_RESCUE=True export EMAIL_USE_SSL_RESCUE=False
export CISO_SUPERUSER_EMAIL=
export DJANGO_SECRET_KEY=...
export ENABLE_SANDBOX=True # optional, default value is True in production enfironments (DJANGO_DEBUG=False) and False in development environments (DJANGO_DEBUG=True).
export LOG_LEVEL=INFO # optional, default value is INFO. Available options: DEBUG, INFO, WARNING, ERROR, CRITICAL export LOG_FORMAT=plain # optional, default value is plain. Available options: json, plain
export AUTH_TOKEN_TTL=3600 # optional, default value is 3600 seconds (60 minutes). It defines the time to live of the authentication token export AUTH_TOKEN_AUTO_REFRESH=True # optional, default value is True. It defines if the token TTL should be refreshed automatically after each request authenticated with the token export AUTH_TOKEN_AUTO_REFRESH_TTL=36000 # optional, default value is 36000 seconds (10 hours). It defines the time to live of the authentication token after auto refresh. You can disable it by setting it to 0.
<details>
<summary>[EXPERIMENTAL] WSL2 なしで Windows 上で開発するためのその他の変数</summary>
設定できるのは PostgreSQL のカスタム変数のみです。
詳細については、[`tools/.windows/README.md`](https://github.com/intuitem/ciso-assistant-community/blob/main/tools/.windows/README.md) に記載されているヘルパースクリプトを参照してください。
</details>
3. uv をインストールする
手順については uv のウェブサイトを参照してください: <https://docs.astral.sh/uv/getting-started/installation/>
4. backend に移動し、必要な依存関係をインストールします。```sh
cd backend
uv sync
6. Postgresをセットアップする場合:
- Postgresに入るには、以下のいずれかのコマンドを実行します:
- `psql as superadmin`
- `sudo su postgres`
- `psql`
- データベース「ciso-assistant」を作成します
- `create database ciso-assistant;`
- ユーザー「ciso-assistantuser」を作成し、アクセス権を付与します
- `create user ciso-assistantuser with password '<POSTGRES_PASSWORD>';`
- `grant all privileges on database ciso-assistant to ciso-assistantuser;`
<details>
<summary>[EXPERIMENTAL] WindowsでPostgreSQLをセットアップする</summary>
詳細については、[`tools/.windows/README.md`](https://github.com/intuitem/ciso-assistant-community/blob/main/tools/.windows/README.md)のドキュメントを参照してください。
</details>
7. s3バケットをセットアップする場合:
- s3プロバイダーを選択するか、以下のコマンドでminiOを使ってs3機能を試してください:
- `docker run -p 9000:9000 -p 9001:9001 -e "MINIO_ROOT_USER=XXX" -e "MINIO_ROOT_PASSWORD=XXX" quay.io/minio/minio server /data --console-address ":9001"`
- これで<http://localhost:9001>でバケットを確認できます
- docker runの環境変数に入力した認証情報でログインしてください
- バックエンドディレクトリで、S3に関するすべての環境変数をエクスポートします
- 推奨変数の上記リストを参照してください
8. マイグレーションを適用します。```sh
uv run python manage.py migrate
詳細については、tools/.windows/README.md のドキュメントを参照してください。
メーラーと CISO_SUPERUSER_EMAIL 変数を設定している場合、初回起動時に自動的に作成されるため、
createsuperuserで Django スーパーユーザーを作成する必要はありません。パスワードを設定するためのリンクが記載されたメールが届きます。```sh uv run python manage.py createsuperuser
<details>
<summary>[実験的] WSL2なしでWindows上にDjangoスーパーユーザーを作成する</summary>
詳細については、[`tools/.windows/README.md`](https://github.com/intuitem/ciso-assistant-community/blob/main/tools/.windows/README.md)のドキュメントを参照してください。
</details>
10. 開発サーバーを実行します。```sh
uv run python manage.py runserver
Django の開発サーバーを Windows 上でネイティブに実行すると、SvelteKit SSR がサーバーの小さなデフォルト listen backlog を超えるほどの同時 API 接続を開くことがあります。これにより、フロントエンドで断続的に ECONNREFUSED / TypeError: fetch failed エラーが発生する可能性があります。
ネイティブ Windows 開発環境のセットアップには、tools/.windows/README.md に記載されているヘルパースクリプトを使用してください。
python manage.py run_huey -w 2 -k process または同等のコマンドを実行します。MAIL_DEBUG を使用すると、メールがコンソールに出力されるためデバッグが容易になります2. 依存関係をインストールする```bash
npm install -g pnpm
pnpm install
4. フロントエンドに <http://localhost:5173> でアクセスします
> [!NOTE]
> このセットアップでは Safari は正しく動作しません。セキュア Cookie には https が必要だからです。最も簡単な解決策は Chrome または Firefox を使用することです。別の方法として caddy プロキシを使用する方法もあります。詳細については、frontend ディレクトリの [readme ファイル](https://github.com/intuitem/ciso-assistant-community/blob/main/frontend/README.md) を参照してください。
5. 環境変数
フロントエンドのすべての変数には便利なデフォルト値があります。
フロントエンドを別のホストに移動する場合は、次の変数を設定する必要があります: `PUBLIC_BACKEND_API_URL`。そのデフォルト値は <http://localhost:8000/api> です。
`PUBLIC_BACKEND_API_EXPOSED_URL` は SSO を正しく機能させるために必要です。これはブラウザから見た API の URL を指します。これはバックエンドの `CISO_ASSISTANT_URL` と "/api" を連結した値と等しくなる必要があります。
"pnpm run dev" ではなく "node server" を起動する場合、ORIGIN 変数をバックエンドの `CISO_ASSISTANT_URL` と同じ値(例: <http://localhost:3000>)に設定する必要があります。
### マイグレーションの管理
マイグレーションはバージョン管理によって追跡されます。<https://docs.djangoproject.com/en/4.2/topics/migrations/#version-control>
製品の最初のバージョンでは、クリーンなマイグレーションから始めることを推奨します。
注: 既存のマイグレーションをクリーンにするには、次のように入力します:```sh
find . -path "*/migrations/*.py" -not -name "__init__.py" -delete
find . -path "*/migrations/*.pyc" -delete
変更後(またはクリーン後)は、マイグレーションファイルを再生成する必要があります:```sh uv run python manage.py makemigrations uv run python manage.py migrate
これらのマイグレーションファイルはバージョン管理で追跡する必要があります。
### テストスイート
バックエンドで API テストを実行するには、バックエンドフォルダのシェルで `uv run pytest` と入力するだけです。
フロントエンドで機能テストを実行するには、次の操作を行います:
- フロントエンドフォルダで、次のコマンドを実行します:```shell
tests/e2e-tests.sh
テストハーネスの目的は、あらゆるリグレッションを防ぐことです。つまり、バックエンドとフロントエンドの両方で、すべてのテストが成功しなければなりません。
export DJANGO_DEBUG=True を設定してください。<backend_endpoint>/api/schema/swagger/ でアクセス可能になります。
例: http://127.0.0.1:8000/api/schema/swagger/。Swagger 経由、または直接 HTTP 呼び出しで API を操作するには:
Authorization: Token <token>⚠️ 注意: Bearer ではなく、Token を使用してください。
PAT は MFA を尊重します。PAT は認証済みセッションから発行されるため、MFA で保護されたアカウントは保護されたままです。インタラクティブ/ブラウザフローの場合、認証は標準のログイン(MFA が有効な場合はそれを強制します)を経由します。
docker-compose.yml は、フロントエンドの前に Caddy プロキシを配置した、テスト用の重要な構成を示しています。これは完全な API を公開するため、本番環境にはまだ推奨されません。
本番環境では、config builder を使用して、より堅牢でカスタマイズされた docker-compose.yml ファイルを生成できますが、いくつかのハードニング手順は依然として必要です。
本番環境には以下の推奨事項が適用されます:
DJANGO_DEBUG=False を設定してください。/api/iam/sso/redirect//api/accounts/saml/0/acs//api/accounts/saml/0/acs/finish//api/accounts/oidc/openid_connect/login/callback//api/accounts/saml/0/sls/(SAML シングルログアウトが有効な場合のみ)[!NOTE] フロントエンドはホストを自動的に推測できないため、ORIGIN 変数、または
HOST_HEADERとPROTOCOL_HEADER変数のいずれかを設定する必要があります。この厄介な問題については sveltekit のドキュメント を参照してください。このアプローチは「pnpm run dev」では機能しないことに注意してください。ただし、本番環境では心配する必要はありません。
[!NOTE] Caddy は SNI ヘッダーを受け取る必要があります。したがって、パブリック URL(
CISO_ASSISTANT_URLで宣言されたもの)には、IP アドレスではなく FQDN を使用する必要があります。ホストが IP アドレスの場合、ブラウザは SNI を送信しないためです。これもまた厄介な問題です!
[!NOTE] docker-compose テンプレートファイルは、バックエンド、huey、フロントエンドを非 root モードで起動するようになりました。古い docker-compose.yml ファイルを使用している場合は、更新することをお勧めします。コンテナは root モードと非 root モードの両方と互換性があります。
docker-compose.yml は、イメージ内で利用可能な非 root ユーザー 1001:1001 に依存するようになりました。古いデプロイでは root ユーザーを使用していますが、これは依然としてサポートされています。非 root に移行するには、ホストで以下の手順を実行してください:
参照は en.json です。カバレッジ = 各ロケールファイルに存在する参照キーの割合。毎日自動更新 — 詳細な内訳は ダッシュボード で確認できます。
セキュリティのベストプラクティスに従うよう細心の注意を払っています。問題があれば [email protected] まで報告してください。
このリポジトリには、AGPL v3 の下でリリースされている CISO Assistant のオープンソース版(Community Edition)のソースコードと、intuitem Commercial Software License の下でリリースされている CISO Assistant の商用版(Pro および Enterprise Editions)の両方が含まれています。このモノリポジトリ方式は、シンプルさのために採用されています。
最上位の「enterprise」ディレクトリ内のすべてのファイルは、intuitem Commercial Software License の下でリリースされています。
最上位の「enterprise」ディレクトリ外のすべてのファイルは、AGPLv3 の下でリリースされています。
詳細は LICENSE.md を参照してください。商用版の詳細については、[email protected] までお問い合わせください。
特に記載がない限り、すべてのファイルは © intuitem です。