背景​

直近では、情報漏洩をはじめとするセキュリティインシデントが相次いでおり、その被害も深刻化しています。こうした状況では、個々の脆弱性を把握するだけでなく、攻撃者がその環境で実際にどこまで到達できるかを確かめることが重要です。

私たちは、より多くの組織がこの検証を自社で実施できるようにすることが、インシデントの未然防止につながると考えています。そこで、これまでの段階的な提供から切り替え、すべての組織への公開に踏み切りました。

変更内容​

これまで AIペネトレーションテスト機能は、事前に申し込みいただいたお客様へ順次ご案内していました。今回の変更により、すべての組織で事前の申し込みなしにご利用いただけます。

利用開始方法​

利用に必要な事前準備や操作方法は、ユーザーガイドをご覧ください。

▼ ユーザーガイド: ペネトレーションテスト

これらの変更は、すでに npm 向けの v1.4.0、PyPI 向けの v1.3.0 として提供していますが、2026 年 10 月 13 日（火）に v1 タグをそれぞれのバージョンに更新する予定です。

本記事では、変更内容と、必要に応じてご確認・ご対応いただきたい事項についてご案内します。

影響を受けるワークフロー​

対象となる Action は次の 2 つです。

• flatt-security/setup-takumi-guard-npm
• flatt-security/setup-takumi-guard-pypi

影響を受けるのは、Action を @v1 タグで参照しているワークフローです。

コミット SHA やバージョン番号（@v1.2.0 など）でバージョンを固定しているワークフローは、今回の変更による影響を受けません。ただし、以前のバージョンでは、Takumi Guard を経由せずに install が行われたり、bot に紐づかない匿名の install として扱われたりする場合があるため、固定しているバージョンを最新のリリースに更新することをおすすめします。

npm 向けの Action（v1.4.0）​

これまでの npm 向けの Action では、レジストリとトークンの設定を、チェックアウトしたリポジトリの直下にある .npmrc に書き込んでいました。しかし、サブディレクトリや working-directory を指定してインストールする場合、この設定が読み込まれず、Takumi Guard を経由せずにパッケージを取得する可能性がありました。

修正版では、設定をチェックアウトしたリポジトリの外にあるジョブ専用の .npmrc に書き込み、環境変数を通じてその場所をジョブ内の後続のステップに引き継ぐようにしました。これにより、どのディレクトリでインストールを実行する場合でも Takumi Guard を経由するようになり、チェックアウトしたリポジトリのファイルも変更されなくなります。

この変更に伴い、npm・pnpm・Yarn Classic をご利用の場合、以下のようなワークフローでは修正が必要となることがあります。

• Dockerfile で COPY .npmrc を使用しているワークフロー
  • docker build --secret id=npmrc,src="$NPM_CONFIG_USERCONFIG" のようにビルドシークレットとして .npmrc を渡し、Dockerfile では RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci のように使用してください。
• リポジトリの .npmrc に //npm.flatt.tech/:_authToken= の行があるワークフロー
  • リポジトリの .npmrc に設定されたトークンが Bot のトークンより優先されるため、その行を削除してください。

詳細については、v1.3.0 および v1.4.0 のリリースノートでもご案内していますので、あわせてご確認ください。

PyPI 向けの Action（v1.3.0）​

これまでの PyPI 向けの Action では、トークンを環境変数 PIP_INDEX_URL と UV_INDEX_URL にのみ設定していました。しかし、Poetry はこれらの環境変数を参照しないため、bot-id を指定していても、Poetry によるパッケージのインストールは Bot に紐づいていませんでした。

また、set-index-url: false を指定した場合でも、認証に成功すると Action がこれらの環境変数を Takumi Guard の URL で上書きしていたため、利用者自身が設定したインデックスよりも Action の設定が優先されていました。

修正版では、トークンをジョブ専用の .netrc に書き込み、環境変数 NETRC を通じて、その場所をジョブ内の後続のステップに引き継ぐようにしました。あわせて、プロジェクトの設定で Takumi Guard を指している uv のインデックスにもトークンを渡します。

この変更に伴い、以下のようなワークフローでは修正が必要となる場合があります。

• pip・uv を利用しており、set-index-url: false を指定して Action によるインデックスの設定に依存しているワークフロー
  • インデックスに https://pypi.flatt.tech/simple/ を指定してください。
• uv を利用しており、Action を actions/checkout より前に実行しているワークフロー
  • Action を actions/checkout の後に実行してください。

詳細については、v1.2.0 および v1.3.0 のリリースノートでもご案内していますので、あわせてご確認ください。

npm・PyPI 向けの Action に共通する変更​

bot-id を指定していて Bot の認証に失敗した場合、ステップが失敗するようになります。

現在は、set-registry・set-index-url が既定値の場合、認証に失敗するとエラーの注記を表示したうえで匿名モードのまま処理を続けるため、ジョブ自体は成功します。しかし、インストールは Bot に紐づかず、ダウンロード追跡や感染可能性の通知の対象にもなりません。

RubyGems・Go・Packagist 向けの Action では、すでに認証に失敗した時点でステップが失敗するようになっており、今回の更新で npm・PyPI 向けの Action も同じ挙動になります。なお、bot-id を省略した匿名モードの挙動は変わりません。

現在のワークフローで認証に失敗している場合、ジョブは匿名モードのまま成功しますが、実行結果の Annotations にエラーが表示されています。10 月 13 日以降はステップ自体が失敗するようになるため、エラーの内容をご確認のうえ、必要な修正をお願いいたします。

従来の深刻度に加えて、攻撃成立の可能性と、この 2 つから導かれる緊急度を表示します。指摘事項がどれだけ深刻かだけでなく、どれから対応すべきかもレポートから読み取れるようになります。

概要​

深刻度は「攻撃が成立したときにどの程度の被害が発生するか」を表す指標で、その攻撃が現実に成立しうるかどうかは考慮していません。そのため、通常の攻撃者には満たせない前提条件を必要とする「重大」な指摘と、誰でも再現できてしまう「重大」な指摘とが、これまでは同じものとして並んでいました。

新たに加わった攻撃成立の可能性は、この「現実に攻撃が成立するか」を「高」から「不可能」までの尺度で表します。そして緊急度は、深刻度と攻撃成立の可能性の組み合わせから決まる値です。単独で判定されるものではありませんので、どの指摘事項から修正すべきかを判断する際の指標としてご利用ください。

レポート全体の A〜E 評価も、含まれる指摘事項のうち最も高い緊急度に基づいて決まるようになりました。指摘事項一覧も緊急度の高い順に並びますので、レポートの先頭にあるものから順に対応いただけます。

なお、新しい評価基準は新規に開始された診断のレポートにのみ適用されます。過去に実行された診断で報告された指摘事項について、変更はありません。

また、レポートによっては、一部の指摘事項の攻撃成立の可能性と緊急度が「—」と表示されることがあります。これは、攻撃成立の可能性の提供開始前に開始された診断に、この基準で評価されていない指摘事項が含まれる場合があるためです。緊急度は深刻度と攻撃成立の可能性の組み合わせから決まるため、あわせて未評価となります。これらの指摘事項は一覧の末尾に並び、レポート全体の A〜E 評価にも反映されませんので、深刻度と指摘事項の内容をもとに対応をご判断ください。

▼ ユーザーガイド: 脆弱性の深刻度、攻撃成立の可能性、緊急度

クレジットカードを登録せずに、 Takumi の組織を作成するだけで毎月 3,000 分まで CI/CD ジョブのトレースログを Takumi Runner が受け付けるようになりました。トレース検索や脅威検出を含め、トレースログを活用する機能も全てご利用いただけるため、サプライチェーンインシデントの影響を無料で確認・検出できます。

概要​

今までは cicd-sensor 連携をご利用いただくにあたって、Takumi サブスクリプションと Runner の有効化が必要でした。本日からは無料枠の提供を開始するため、Takumi の組織作成のみで cicd-sensor 連携が可能になりました。

ご利用いただける機能​

トレースログの調査用の機能は全てご利用いただけます。

トレースログの可視化

Takumi Runner の画面から可視化されたトレースデータを確認できます。

トレースログの検索

Takumi Runner の画面から、集めたトレースログの内容を検索することができます。サプライチェーンインシデントが発生した期間中に実行されていた CI/CD ジョブに影響があったかを確認できます。

脅威検出

脅威検出は、サプライチェーンインシデント時に能動的にトレースログをもとに影響調査を行い、影響があった場合に通知を送る機能です。ご利用いただくとご自身での調査が不要になるため、専門知識不足やインシデントの見逃しなどが解消されます。

無料枠の利用上限を超過した場合​

無料枠では組織ごとに毎月、ジョブ実行時間の合計 3,000 分までのトレースログを受け付けます。3,000 分の上限に達すると、それ以降のトレースログの受け付けは停止されますが、CI/CD ジョブはそのまま実行されます。

3,000 分を超えてトレースログを Takumi Runner で管理したい場合は、Takumi サブスクリプションの契約と Runner の有効化が必要になります。

cicd-sensor 連携と Takumi Hosted Runner の料金体系の詳細は料金と請求をご覧ください。

利用開始方法​

無料枠のご利用の手順は以下のとおりです。

組織の作成​

https://cloud.shisho.dev/hello/takumi にアクセスしてください。

1. 新しい組織を作成を ON にし、新規登録する組織の ID を入力する
2. 新しい組織を作成を押す

組織を作成したら、次に cicd-sensor 連携をセットアップします。

cicd-sensor 連携のセットアップ​

ここでは、GitHub ホステッドランナーを利用した CI/CD ジョブのセットアップを紹介します。他の環境をご利用の場合はユーザーガイドをご覧ください。

認証情報

最初に、認証情報を扱うボットを作成します。Takumi の画面で 設定 > ボット > ボットの追加 を開き、Takumi Runner トレース送信者 を選択してボットの作成画面を開きます。

ボット作成画面では、信頼条件を設定します。名前、Organization、リポジトリを入力してください。

保存を押すと、ボットの作成は完了です。次に GitHub のワークフローを作成します。

GitHub ジョブの作成

ここでは、echo Hello をするジョブを作成します。

jobs:
  build:
    runs-on: ubuntu-latest
    environment: cicd-sensor
    permissions:
      contents: read
      id-token: write
    steps:
      - id: auth
        uses: flatt-security/shisho-cloud-action@v1
        with:
          bot-id: <Bot ID>
          export-token: true
          expires-in-minutes: 360
      - uses: cicd-sensor/cicd-sensor-action@cb0546d5707fcb68bf755006cb97817b3750996b # v0.0.39
        with:
          manager-url: https://manager.cicdsensor.cloud.shisho.dev
          manager-token: ${{ steps.auth.outputs.token }}
      - run: echo Hello

uses: flatt-security/shisho-cloud-action@v1 のステップは認証情報を取得します。uses: cicd-sensor/cicd-sensor-action のステップは cicd-sensor を利用します。

Takumi Runner の接続は manager-url: https://manager.cicdsensor.cloud.shisho.dev で設定します。

トレースログの確認​

上記ジョブを実行すると、Takumi Runner の画面から実行を確認できるようになります。画面左側のRunnerを開くと、最近のジョブに実行済みのジョブが表示されます。

ジョブをクリックすると、トレースログを確認できます。ここからは、上記でも紹介したトレースログを扱う様々な機能をご利用いただけます。

cicd-sensor 連携に関するより詳しい内容はユーザーガイドをご覧ください。

αテストで実施すること​

今回のαテストでは、公開情報を利用した資産発見と、発見した資産に対する最低限のクロールのみを行います。ログイン試行、悪性とみなされる操作、アプリケーションに対する侵襲的なテストは行いません。

ASM の実行 1 回あたり、各資産へ送信される通信はブラウザアクセス換算で約 2 回が目安です。αテスト中の実行頻度は、開発・検証の状況に応じて変動します。対象資産への影響を抑えるため、特定の組織に紐づく ASM の実行は、1 時間あたり最大 5 回を上限とします。

参加によって得られる情報​

αテストで発見した資産については、テスト終了後、可能な限り参加企業ごとに一覧データとしてご提供する予定です。発見結果は、社内で把握されていないシャドー資産の可視化、インターネット公開資産の棚卸し、今後実施する脆弱性診断やペネトレーションテストの対象範囲と優先順位の検討にご活用いただけます。

なお、αテストの開始時点では結果を Takumi の画面上で確認することはできません。また、資産の網羅的な検出を保証するものではありません。

αテストへのご参加とフィードバックは、Takumi が資産とその所有者を適切に関連付け、詳しく確認すべき資産を選定する機能の改善に役立てられます。

今後の展望​

今後は、発見したアタックサーフェスの中から Takumi の「AIペネトレーションテスト」機能で確認すべき資産を選定し、必要に応じて対象への診断を自動で実施できるように拡張していく予定です。今回のαテストでは、ペネトレーションテストは実施しません。

ASM 機能は、将来的に Takumi の有償機能として提供することを検討しています。

参加方法​

無料のαテストへの参加をご希望の方は、弊社営業担当者へご連絡いただくか、shisho-support@flatt.tech までメールでご一報ください。

メールでお申し込みいただく際は、以下の文例をご利用ください。

件名：Takumi「ASM 機能」のαテスト参加申し込み

Takumi「ASM 機能」のαテストへの参加を希望いたします。
資産発見の起点とする当社のドメインは、以下のとおりです。

・aaa.example（既知のサブドメイン：xxx.aaa.example）
・bbb.example

ご連絡の際は、貴社内で把握されている所有ドメインの一覧をお送りください。資産発見の起点として利用いたします。ご共有可能な範囲で構いませんが、最低 1 つは含めていただきますようお願い申し上げます。製品改善に向けた追加のご協力をご検討いただける場合には、それらのドメインのサブドメイン一覧もあわせてお送りいただけますと幸いです。

メリット​

これまでは、Takumi Runner で収集したトレースログはお客様がご自身で確認や調査をする必要がありました。しかし、効果的に調査するにはある程度の専門知識が必要で、対応も早急に行う必要があります。

本機能をご利用いただくと、サプライチェーンインシデントが発生した時に弊社のノウハウとシステムを活かした影響調査が迅速に行われ、影響がある場合には通知が送られます。

利用方法​

通知を受けるには設定で脅威検知通知を有効にする必要があります。

Shisho Cloud コンソールで Runner > 設定 を開き、脅威検知通知から通知先を設定してください。

メール通知 のトグルをオンにし、送信先アドレス から通知先のメールアドレスを選択してください。「保存」を押すと設定が完了です。今後のインシデントで脅威が検出された際に、通知が送信されるようになります。

また、こちらの画面からはテスト送信も行えるので、通知が正しく届くことを事前に確認できます。

本機能の詳細は、脅威検出のユーザーガイドを参照してください。

料金体系​

脅威検出機能は、 Takumi Runner の基本プラン内でご利用いただけます。従量課金制ではありません。

Takumi Runner のプランの詳細は料金と請求をご覧ください。

Takumi Runner の利用開始方法​

Takumi Runner を利用するには、Takumi サブスクリプションの契約と Runner の有効化が必要です。

1. https://cloud.shisho.dev/hello/takumi にアクセスし、サインインしてください
2. 組織を登録し、Takumi サブスクリプションを契約してください
3. 画面左のサイドバーから Runner > 設定 にアクセスしてください
4. 「有効化する」ボタンをクリックして Runner を有効化してください

有効化が完了したら、Takumi Runner のユーザーガイドに従ってセットアップを進めてください。

cicd-sensor のトレースログは本日同時にリリースした脅威検出機能にも対応しています。

背景​

Takumi Hosted Runner は、Takumi Runner の専用ランナーでジョブを実行することによって、プロセス実行・ネットワーク接続・DNS クエリ・ファイルアクセスといった eBPF トレースを収集する仕組みです。一方で、実行環境の制約や移行の手間などの理由で、 Takumi Hosted Runner に移行することが難しい場合もあります。

そこで、実行環境の移行が必要ない cicd-sensor を活用する手段の提供を開始しました。 CI/CD パイプラインに cicd-sensor を導入し、Takumi Runner の Manager のエンドポイントと認証情報を指定するだけで、トレースログを Takumi Runner に送信できるようになります。

上記アーキテクチャー図の通り、Takumi Hosted Runner では CI/CD ジョブを弊社運用の専用ランナーで実行することによってトレースログを収集します。cicd-sensor 連携は、GitHub ホステッドランナーやご自身で運用されているセルフホステッドランナーなど、今までのご利用の環境に cicd-sensor を導入してそこでトレースされたログを Takumi Runner に送信する仕組みです。

メリット​

cicd-sensor から収集したトレースログは、Takumi Hosted Runner のトレースログと同じ扱いで管理されるため、トレースログの可視化・検索や脅威検出をご利用いただけます。

トレースログの可視化

Takumi Runner の画面からは可視化されたトレースデータを確認できます。

トレースログの検索

Takumi Runner では集めたトレースログの内容を検索することができます。サプライチェーンインシデントが発生した期間中に実行されていた CI/CD ジョブに影響があったかを確認できます。

脅威検出

脅威検出は、サプライチェーンインシデント時に能動的にトレースログをもとに影響調査を行い、影響があった場合に通知を送る機能です。ご利用いただくとご自身での調査が不要になるため、専門知識不足やインシデントの見逃しなどが解消されます。

サポートされている CI/CD パイプライン​

cicd-sensor の連携は実行環境に依存しないため、基本的に cicd-sensor がサポートする CI/CD パイプラインには対応しています。本稿執筆時点では、GitHub Actions および GitLab CI/CD がサポートされています。なお、GitLab CI/CD に関しては、セルフホストの GitLab Runner（Docker executor）が対象となります。

利用方法​

cicd-sensor の連携は、以下 3 ステップで行います。

1. CI/CD ジョブに cicd-sensor を導入
2. Takumi Runner の Manager を cicd-sensor の manager-url に設定
3. cicd-sensor の manager-token に認証情報を設定

GitHub ホステッドランナー​

cicd-sensor のステップをジョブの先頭に追加し、パラメータ manager-url に Manager エンドポイントを指定します。

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: cicd-sensor/cicd-sensor-action@cb0546d5707fcb68bf755006cb97817b3750996b # v0.0.39
        with:
          manager-url: https://manager.cicdsensor.cloud.shisho.dev
          manager-token: ${{ secrets.SHISHO_CICD_SENSOR_TOKEN }}

認証（manager-token）は、Shisho Cloud のボット経由で行われます。ボットの作成など、認証の設定方法はユーザーガイドをご確認ください。

ジョブの実行が完了すると、ジョブとトレースの内容が Takumi Runner の画面に反映されます。

GitHub セルフホステッドランナー・GitLab CI/CD​

これらの環境では、cicd-sensor がランナーのホスト上で動作するため、パイプラインではなくホスト側で cicd-sensor の導入と Manager エンドポイントの設定を行います。設定方法は cicd-sensor のドキュメントをご確認ください。

Takumi Runner の Manager エンドポイントは https://manager.cicdsensor.cloud.shisho.dev です。

認証情報は、Takumi の画面で API キーを発行し、 manager-token として指定します。ボットの作成や API キーの詳細は、ユーザーガイドをご確認ください。

料金体系​

cicd-sensor 連携をご利用いただくには Takumi Runner の基本プランが必要です。

基本プラン内では、毎月ジョブ実行時間の合計 3000 分のトレースログまで受け付けます。今年2026年9月1日以降、3,000 分を超過したジョブ実行のログ受け付けには、分単位で料金が発生します。

cicd-sensor 連携の料金体系の詳細は料金体系をご覧ください。

Takumi Runner の利用開始方法​

cicd-sensor 連携も含め、Takumi Runner を利用するには、Takumi サブスクリプションの契約と Runner の有効化が必要です。

1. https://cloud.shisho.dev/hello/takumi にアクセスし、サインインしてください
2. 組織を登録し、Takumi サブスクリプションを契約してください
3. 画面左のサイドバーから Runner > 設定 にアクセスしてください
4. 「有効化する」ボタンをクリックして Runner を有効化してください

有効化が完了したら、cicd-sensor 連携のユーザーガイドに従ってセットアップを進めてください。

ソースコードと、そのコードが稼働しているアプリケーションの URL の両方を指定することで、Takumi がコードを解析して脆弱性の候補を洗い出し、稼働中のアプリケーションに対して実際に攻撃を行います。そして、再現できたものだけを指摘事項として報告します。

概要​

ホワイトボックス診断はソースコードを直接読むため、外部からの調査、すなわちブラックボックス的なアプローチでは到達し得ない脆弱性も発見することができます。一方で、発見した脆弱性の候補が実際の動作環境で再現できるかどうかは、コード上からは判定できません。また、ブラックボックス診断では、実際に動作環境で再現する脆弱性のみが報告対象となりますが、コードを読まないと発見が難しい脆弱性や公開されていない機能に潜む脆弱性を検出することは困難です。

グレーボックス診断機能は、この両者の長所を取り入れた機能です。すなわち、静的解析によって脆弱性の候補を網羅的に検出するとともに、実際に動作しているアプリケーションを対象に各候補の再現性を検証するため、網羅性と正確性を両立させることが可能です。

再現性が確認されたレポート​

グレーボックス診断のレポートに記載される指摘事項は、すべて稼働中のアプリケーションで再現を確認したものです。静的解析が挙げた候補のうち再現を確認できなかったものは、指摘事項とは異なり、レポート内の別のセクションに記録されます。よって、レポートを読むだけで実際に再現が可能である脆弱性をすぐに判別することが可能です。

また、各指摘事項には、再現に用いた手順も記載されます。開発者は同じ手順をたどって脆弱性が再現することを確認できるとともに、修正後に同じ手順を再度実行して修正の妥当性を確かめられます。

利用開始方法​

本機能は全ての「Takumi byGMO」ユーザーの皆様が、月ごとのクレジット枠内で自由にご利用いただけます。追加料金やプラン変更は必要ございません。

グローバルサイドバー内「診断」タブから「診断を作成」ボタンをクリックし、「グレーボックス診断」を選択してご利用ください。

▼ ユーザーガイド: グレーボックス診断

概要​

従来 Takumi はメールによる MFA に対応しておらず、診断を正常に行うためには MFA を毎回無効化していただく必要がありました。

今回のリリースにより、ブラックボックス診断機能とペネトレーションテスト機能において、診断中に Takumi がメールを受け取れるメールアドレスを選択いただけるようになります。

用途は MFA のワンタイムコードに限らず、マジックリンクやサインアップ時の確認メールなど、メールに依存する機能全般でご利用いただけます。

利用開始方法​

本機能は、ブラックボックス診断およびペネトレーションテストの実行画面から、すべての組織でご利用いただけます。

クレデンシャルを追加する際、アカウントのメールアドレスとして「Takumi 管理メール」を選び、新しいアドレスを発行するか、組織がすでに保有しているアドレスを選択してください。アドレスは 5 件までご登録いただけます。

アドレスの設定方法と診断対象への登録手順については、メールのワンタイムコードを用いたサインインをご覧ください。

本問題に対応したワークフローを公開しましたので、更新をお願いいたします。

背景​

AWS は 2026 年 3 月、express configuration という Aurora クラスターの作成方式を導入しました。

express configuration で作成されたクラスターは、従来の Aurora クラスターとは異なり、VPC に関連付けられない構成となっています。

マネージド検査項目「RDS インスタンスを VPC 内で運用する」（RDS.18）は、DB インスタンスが参照する DB サブネットグループから VPC への所属を判定しています。そのため、VPC に関連付けられない express configuration の Aurora クラスターは、この検査の前提から外れており、正しく判定できない状況でした。

今後、このような構成の Aurora クラスターが利用されることを想定し、検査結果の誤判定を防ぐため、本検査ワークフローの更新にご協力いただけますと幸いです。

更新の対象​

更新の対象は、以下のワークフロー内の 1 つのジョブです。

必要な対応​

最新の GraphQL クエリと Rego ポリシーを shisho-cloud-managed-workflows リポジトリの workflows/csp/aws-fsbp/rds/instance-vpc にご用意いたしましたので、置き換えをお願いいたします。

なお、参考情報ですが、「RDS インスタンスを VPC 内で運用する」（RDS.18）は、参照元となっている AWS FSBP（AWS Foundational Security Best Practices standard） の検査項目からすでに削除されています。

そのため、運用状況によっては、当該ジョブ自体を削除いただくことも選択肢の一つとなります。

お使いの管理方法に応じて、次のいずれかの方法で更新してください。なお、ワークフローの一覧にこのワークフローが存在しない場合、更新は不要です。

shishoctl で更新する場合​

shishoctl workflow export で取得したワークフロー定義をお持ちの場合は、instance-vpc ジョブに対応するファイル（Rego ポリシー・GraphQL クエリ・テスト）を最新版の内容に置き換え、shishoctl workflow apply で組織に適用してください。

コンソールで編集する場合​

ワークフロー から「Prebundle: Review AWS RDS posture (FSBP)」を開き、マニフェスト中の jobs 配下にある id: instance-vpc のジョブについて、decide ブロックの rego:（Rego ポリシー）と input 配下の schema:（GraphQL クエリ）の内容を、公開されている最新版でそれぞれ置き換えて保存してください。

他のジョブやパラメータの変更は不要です。

GitHub や GitLab のリポジトリで管理している場合​

instance-vpc ジョブに対応する 3 ファイル（Rego ポリシー・GraphQL クエリ・テスト）を最新版の内容に置き換えて、メインブランチへ push してください。

設定済みのデプロイ用 GitHub Actions ワークフローなどにより、Shisho Cloud へ自動的に反映されます。

お問い合わせ​

ご不明な点や更新作業に不安がある場合は、サポート窓口までご連絡ください。

お客様の状況に応じてサポートいたします。

あわせて、目的達成に至る経路を見つけ出す精度や、テストを安全に実施するための仕組みを強化しました。

提供対象の拡大​

AIペネトレーションテスト機能は、事前登録いただいたお客様へ段階的にご案内してきました。運用の知見が蓄積できたこと、また、テストを安全に実行するための仕組みをより強化したことをもとに、現在はご案内の範囲をさらに拡大しています。

機能の提供に当たっては、引き続き事前登録いただいたお客様へ順次ご案内していますので、ご利用を希望される場合はまず申し込みページからご登録ください。

機能の改善​

前回のご案内から、探索の精度と、テストを安全に実施するための仕組みについて、次の3点を改善しました。

• テスト用エンジンの性能改善: 偵察で得た情報から仮説を立て、脆弱性を連鎖させて次の攻撃につなげる一連の判断の精度が向上しました
• 破壊的な操作に関するポリシー: データの削除や改変のように、対象システムへ影響を及ぼしうる操作をどこまで許容するかをあらかじめ設定できるようになりました
• スコープの制御と監視の強化: 設定したスコープの外へ探索が及ばないようにするための仕組み、および、スコープ外の対象へのアクセスや危険な操作を検知する発見的統制の仕組みを強化しました

お客様の声​

ウェルスナビ株式会社 システム基盤グループ/セキュリティエンジニア 宮﨑 多朗様より、コメントをいただきました。

これまでペネトレーションテストは専門会社に依頼するとコストが高くなる傾向があり、数百万円〜の費用に加え、シナリオの相談からレポート受領まで2ヶ月以上を要することもめずらしくありません。予算の確保や社内調整、さらに診断員のスケジュール調整にも時間がかかるため、私たちとしてもフットワーク軽く回すことが難しいという課題がありました。

Takumi の AIペネトレーションテスト機能では、従来であれば100万円を超える規模を見込むようなペネトレーションテストが、今回は数千円・数時間という圧倒的なコストとスピードで完了しました。専門会社の診断員のスケジュールに左右されず、必要なタイミングで自分たちの判断ですぐに実施できる点も大きな魅力です。事業会社が抱えるセキュリティエンジニアの数は必ずしも多くない組織もあるなかで、こうした調整ごとにかかる工数を短縮してくれるため、専門的な知識を持つメンバーはシナリオの設計・調整といった本質的な部分に注力できるようになりました。手軽に回せるだけでも十分な価値ですが、机上の評価では正直「刺さらないだろう」と考えていた箇所にミスコンフィギュレーションが見つかり、実際のリスクとして検知してくれた点には驚かされました。手軽さだけでなく成果の面でもしっかり応えてくれるため、私たちとしても今後、Web 経由のペネトレーションテストを積極的に活用していきたいと考えています。

利用開始方法​

▼ ユーザーガイド: ペネトレーションテスト

Jenkins・Buildkite・CircleCI など自前で運用する CI/CD、他クラウドのワークロード ID 基盤、GitHub Enterprise Server、セルフマネージドの GitLab などから、静的な API キーなしで Bot としてサインインできます。

概要​

信頼条件とは、Bot 側に設定しておく規則で、どの OIDC ID トークンをその Bot としてのサインインの証明として受け入れるかを決めるものです。これまで信頼条件が扱える発行者 (issuer) は GitHub Actions と GitLab CI の 2 つだけで、それ以外の環境では Bot の API キーを使う必要がありました。API キーは静的なシークレットであり、保管やローテーション、ログへの混入防止といった運用が欠かせません。

新しい Custom (OIDC) の提供元を選ぶと、信頼条件を自社の issuer に対して直接設定できます。IdP がジョブごとに短命な ID トークンを発行し、Shisho Cloud がそれを信頼条件と照合したうえで、同じく短命な、その Bot に限定された認証情報と交換します。CI 側に永続的なシークレットを置く必要はありません。

利用開始方法​

Shisho Cloud コンソールで Bot の 信頼条件 タブを開き、信頼条件を追加して、提供元として Custom (OIDC) を選択してください。設定する項目は以下の 4 つです。Issuer・Subject・Audience は必須、Claims は任意です。

• Issuer - ID トークンの発行者を示す https:// の URL。ポート 443 で到達でき、/.well-known/openid-configuration に OIDC Discovery のドキュメントを公開している必要がある。
• Subject - ID トークンの sub クレームに期待する値。完全一致の値か、* が任意の文字列にマッチする式（例: repo:acme/app:*）のいずれかを指定する。* のみの式は指定できない。
• Audience - ID トークンの aud クレームが含んでいなければならない値。IdP 側で https://sts.cloud.shisho.dev を発行するよう設定することを推奨する。こうすることで、Shisho Cloud 向けに発行したトークンが他のサービスへ再利用されるのを防げる。
• Claims（任意）- トークンのトップレベルの文字列クレームに対する追加条件を、最大 10 件まで指定できる。指定方法は Subject と同じ。

信頼条件を保存したあとの CI 側の流れは、GitHub Actions や GitLab CI の場合と同じです。IdP から ID トークンを取得し、shishoctl auth signin:bot に渡してください。

設定項目の詳細や設定例、セキュリティ上の注意点は、Bot の認証ガイドのカスタム OIDC をご覧ください。

Web ブラウザによるクロールの代わりに、OpenAPI Spec や GraphQL スキーマなど、添付されたスキーマファイルをもとに診断対象のエンドポイントを洗い出します。

概要​

ブラックボックス診断は、これまで Web ブラウザによるクロールで診断対象のエンドポイントを洗い出してきました。ブラウザで操作するアプリケーションではこの方式がうまく機能しますが、画面を持たない API はクロールする対象が存在しないため、診断できませんでした。一方で、モバイルアプリのバックエンドやサービス間 API など、画面を持たない API を診断対象にしたい場面は少なくありません。

今回のリリースにより、こうした画面を持たない API を Takumi で直接診断できるようになります。診断対象の種類として API を選択すると、Takumi はクロールを行わず、添付されたスキーマファイルから診断対象となるエンドポイントを洗い出します。

利用開始方法​

本機能は、ブラックボックス診断の実行画面からすべての組織でご利用いただけます。

スキーマファイルや認証手順の設定方法については、API 診断をご覧ください。

攻撃対象と「利用者データの取得」のような具体的な目的を設定するだけで、あとは Takumi が偵察・脆弱性の発見・攻撃を自律的に繰り返します。

なお、本機能は段階的に提供を行っており、すべてのお客様にご提供しているものではございません。ご利用を希望される場合は申し込みページからご登録ください。

背景​

ホワイトボックス診断・ブラックボックス診断は、アプリケーション全体の脆弱性を機能と観点のマトリクスに沿って網羅的に検出する機能です。一方で、実際にシステムやアプリケーションの運用を進める中で「個々の脆弱性の一覧」だけでなく、「攻撃者がこの環境で本当にこの目的を達成できるのか」という問いに答えたい場面があります。単体では軽微に見える複数の脆弱性が連鎖し、結果として機密情報の窃取やシステムへの侵入に至るケースは少なくありません。

AIペネトレーションテスト機能は、この問いに答えるための機能です。網羅的な脆弱性検出ではなく、設定した特定の目的に到達できるかどうかに焦点を当て、そこへ至る攻撃パスを Takumi が自律的に探索します。人間のペネトレーションテスターと同じように、偵察で得た情報をもとに仮説を立て、脆弱性を発見、連鎖させ、得られた足がかりを次の攻撃につなげる、という一連の流れを繰り返します。

使い方​

攻撃対象と目的を設定することで実行を開始できます。目的は「利用者データの取得」「システムへの侵入」といったプリセットから選ぶだけで、あとは Takumi が偵察から攻撃までを自動で実行します。テストの過程で発見した脆弱性を単独で報告するのではなく、それらを目的達成のためにどのように活用できるかを含めて検証する点が、通常の診断との大きな違いです。

テストの実行中および完了後は、攻撃の到達点を時系列で示すタイムラインと、攻撃経路を可視化する侵入マップを確認できます。テストが完了すると、実施した操作と目的の達成結果をまとめたレポートが出力されます。目的を達成できないまま完了した場合でも、レポートを確認したうえで追加の指示を添え、前回の到達点からテストを再開させることができます。

より詳しい設定方法や利用方法については、ユーザーガイドをご覧ください。

利用開始方法​

AIペネトレーションテスト機能は現在、提供対象を段階的に拡大しています。

▼ ユーザーガイド: ペネトレーションテスト

イメージは OCI レジストリ images.flatt.tech で公開しています。

概要​

開発組織には、セキュリティ更新をこれまで以上に高い頻度で適用することが求められています。一方で、更新作業そのものを狙うソフトウェアサプライチェーン攻撃も増えています。

Takumi Images は、この運用上の緊張を下げるための機能です。一般的なランタイムイメージについて、利用者がベースイメージのパッチパイプラインを自前で構築しなくても、保守されたベースイメージへ移行できるようにします。

対応するイメージがカタログに含まれていれば、ベースイメージ内のパッケージを調査し、修正版を選定し、自分でイメージを再ビルドする代わりに、ベースイメージの参照を Takumi Images に切り替え、更新時に最新の Takumi イメージを pull して利用できます。

本機能は現在無料です。またβ期間終了後も、既に公開済の範囲のイメージは引き続き無料で提供いたします。 脆弱性対応に関するSLA、及びさらなるイメージカタログやカスタマイズ機能に関しては、今後ご案内する有償プラン内での提供となる見込みです。

利用開始​

利用中のベースイメージに対応するイメージがカタログに含まれていれば、多くの場合、移行に必要なのは Dockerfile の FROM 行の変更だけです。

- FROM node:latest
+ FROM images.flatt.tech/takumi/node:latest

移行後は、イメージを pull し直すことで、最新の再ビルド済みイメージを取得できます。

docker pull images.flatt.tech/takumi/node:latest

詳しくは Takumi Images のドキュメント を参照してください。

含まれる価値​

Takumi Images は、ベースイメージの運用を楽にするために、次の3つをまとめて提供します。

1つめは、そもそも含まれているものが少ないことです。各イメージは、メインのプログラムと、その実行に必要な最小限のライブラリを中心に構成しています。これにより、アプリケーションコードではなくベースイメージに由来するスキャナのノイズを減らしやすくなります。

2つめは、ベースイメージ側の調査負担を提供元に寄せられることです。Takumi Images に含まれるソフトウェアについては、提供元が脆弱性の影響をトリアージし、取り込む上流コードについてもマルウェアチェックを行っています。利用者が、ベースイメージ由来の検出結果や更新元の安全性を都度追い続ける負担を減らせます。

3つめは、サプライチェーンを確認するための情報です。各イメージには、以下のような検証可能な情報が付属します。

• 署名付きイメージ
• SBOM attestation
• SLSA Provenance attestation
• 提供元が評価した脆弱性情報に対する VEX attestation

これらの情報により、イメージの中身、出どころ、ベースイメージに対して報告された検出結果の現在の判断を確認できます。

今後の展望​

今後は、提供するコンテナイメージの種類をデータベース・言語ランタイム・ミドルウェアを中心にさらに拡充するとともに、コンプライアンス要件に対応したイメージバリアントの提供を予定しています。

また、CVE ID未採番の脆弱性情報の検出とナイトリービルドとしての先行取り込み、国際的なコンプライアンス要件への対応等を予定しています。

今年3月に発生した axios ソフトウェアサプライチェーン攻撃など、実例に基づいて本検索機能のご利用方法も紹介します。以下「具体例」をご確認ください。

利用方法​

Shisho Cloud コンソールで Runner > トレース検索 を開きます。

まずは期間を選択し、検索対象とするイベント種別を選択します。最後に検索内容を入力し、「検索」を押すと検索が実行されます。

検索が完了すると検索結果を確認できます。この画面から以下が可能になります。

• 一致したジョブとイベントの統計の確認
• 一致したジョブとイベントの内容を確認
• 検索結果のデータのダウンロード

検索結果は 72 時間保持されます。

詳しくは トレース検索のドキュメント をご覧ください。

具体例​

axios ソフトウェアサプライチェーンの攻撃 - ホスト接続の検索​

2026年3月に HTTP クライアントライブラリ axios の npm パッケージが侵害された攻撃がありました。この事例の詳細は 弊社のブログ からご確認いただけます。

こちらと同等の攻撃が3日前に発生したとします。弊社のブログなどから、攻撃は dangerous.example に接続すると分かったとしましょう（誤接続を防ぐため、本稿での例示には、上記ブログに記載されている実際のホスト名とは異なるホスト名を利用しています）。

この場合、Takumi Runner で実行されたジョブに影響がなかったかは、以下検索条件で確認できます。

• 対象期間 - <3日前> ~ <検索の当日>
• イベント種別 - dns_query
• ホスト名 - *dangerous.example

ホスト名には、サブドメインも一致するよう * を先頭に追加します。

検索を実行し、一致したジョブがあった場合は攻撃の影響があったと判断できます。

GitHub Actions の侵害 - ファイルアクセスの検索​

GitHub Actions が侵害され、認証情報が奪取される攻撃が本年既に何度か発生しております。詳細は 弊社のブログ に記載されております。

このようなインシデント時には、GitHub Actions ワーカーが持つ認証情報が、メモリ（/proc/<pid>/mem）から読み取られる傾向があります。

もし同様の GitHub Actions の侵害があり、自社に影響が及んだ場合、Takumi Runner では /proc/<pid>/mem のファイルにアクセスした痕跡（トレース）が残ることになります。

従って、Actions 上で類似の攻撃が発生していないかの確認には、以下検索条件が利用できます。

• 対象期間 - <攻撃発生日> ~ <検索の当日>
• イベント種別 - file_open
• ファイルパス - /proc/*/mem

<pid> は固定ではないため * を利用して検索します。

検索を実行し、一致したジョブがあった場合は攻撃の影響があったと判断できます。

概要​

これまでインストールログの確認は、パッケージを 1 つずつ検索する形でした。新しいログブラウザは、その検索機能はそのままに、組織全体の閲覧と内訳の集計を同じ画面に追加しています。「このパッケージを誰かがインストールしたか」から「このリポジトリは何を取得しているか」まで、画面を切り替えずに調査を進められます。

新しいログブラウザは、従来のパッケージ単位のログ画面を置き換えるものです。これまでのパッケージ検索は、ログブラウザの 1 つのモードとして利用できます。

利用方法​

Takumi / Shisho Cloud コンソールの Guard > ログ から利用できます。エコシステム（npm、PyPI、RubyGems など）を選び、パッケージを検索するか、最近のアクティビティを表示してください。

主な機能​

検索と閲覧を 1 つの画面で​

特定のパッケージを検索して、誰が・どのリポジトリやワークフローから・いつインストールしたかを確認できます。同じ画面から、組織全体のインストールイベントを閲覧することもできます。

リポジトリ・ワークフロー・ユーザー単位のグループ化​

フラットなイベントフィードに加えて、パッケージ・リポジトリ・ワークフロー・ユーザー単位でグループ化し、それぞれのダウンロード数とブロック数を確認できます。エンティティを選択すると、その対象だけに表示が絞り込まれます。調査を素早く絞り込むのに役立ちます。

すべてに適用される 1 つの期間設定​

24 時間・7 日間・14 日間、または最大 14 日間のカスタム範囲という 1 つの期間設定が、サマリー・イベントフィード・内訳のすべてに同時に適用されます。これにより、画面上のすべての数値が同じ期間を対象にします。ブロックされたインストールのみに絞り込むこともできます。

表示中の条件の把握と共有​

結果の上部にあるサマリーバーには、表示中のエコシステム・期間・フィルターが表示され、それぞれ個別に解除できます。表示中の条件はページの URL に反映されるため、画面に表示されている証跡をそのまま再現できるリンクをチームに共有できます。

補足​

インストールログは引き続き 14 日間 検索可能で、データは約 15 分ごとに更新されます。ログのクエリには、すべての組織で快適に利用できるよう、組織ごとのフェアユースの上限（1 分あたり 60 リクエスト、1 日あたり 5,000 リクエスト）が設けられています。詳細はインストールログの検索のガイドを参照してください。

概要​

「管理ツールによる一括セットアップ」は、Jamf、Intune、Ansible などの管理ツールを通じてセットアップスクリプトを配布し、開発者による個別操作なしに、各端末へ対応するパッケージマネージャーの設定を書き込む仕組みです。

これまで対応していたエコシステムは npm・PyPI・RubyGems・Go モジュールの 4 種類でした。今回のリリースで Packagist が 5 つ目として加わり、PHP プロジェクトでも他のエコシステムと同じ保護を、開発者の手を煩わせずに展開できます。

セットアップスクリプトは各端末の Composer に Takumi Guard をリポジトリとして登録し、公開 Packagist（packagist.org）を無効化します。これにより composer install と composer update が Takumi Guard を経由し、既知の悪意あるパッケージがインストール前にブロックされます。設定は、composer が PATH 上にあれば公式の composer config で行い、見つからない場合は設定ファイルへ直接書き込むため、CLI が通らない MDM 環境でも保護を有効化できます。

利用方法​

新しいセットアップスクリプト v0.10.0 は以下から取得できます。

• macOS / Linux: https://shisho.dev/releases/takumi-guard-setup-0.10.0.sh
• Windows: https://shisho.dev/releases/takumi-guard-setup-0.10.0.ps1

手順は以下の通りです。Bot および API キーをすでにお持ちの場合は、ステップ 3 から始めてください。

1. Takumi / Shisho Cloud コンソール（設定 > ボット）で Bot を作成し、「Takumi Guard トークン発行者」ロールを付与してください
2. Bot の API キーを生成してください
3. 上記の URL からセットアップスクリプト v0.10.0 をダウンロードしてください
4. お使いの管理ツール（Jamf、Intune、Ansible など）でラッパースクリプトを作成し、対象端末へ配信してください

既定では npm・PyPI・RubyGems・Go モジュール・Packagist のすべてが設定されます。Packagist だけを対象にしたい場合は、スコープ引数に packagist を指定してください。詳しい手順や最新のラッパースクリプト例は管理ツールによる一括セットアップガイドを参照してください。

なお、開発者が個人のローカル環境や CI で Composer を設定する場合は、Packagist クイックスタートが便利です。

組織向け機能を利用する​

Takumi Guard の組織向け機能（一括セットアップ、インストールログの検索など）を利用するには、Takumi サブスクリプションの契約と Guard の有効化が必要です。

1. https://cloud.shisho.dev/hello/takumi にアクセスし、サインインしてください
2. 組織を登録し、Takumi サブスクリプションを契約してください
3. 画面左のサイドバーから Guard > 設定 にアクセスしてください
4. 「有効化する」ボタンをクリックして Guard を有効化してください

有効化が完了したら、管理ツールによる一括セットアップガイドに従ってセットアップを進めてください。

概要​

従来、setup.sh install の実行後に Guard がエンドツーエンドで正しく動作しているかを確認する自動化された手段がありませんでした。ユーザーガイドには手動の検証手順（例：npm install @panda-guard/test-malicious）を記載していましたが、手順が省略されやすく、スクリプトへの組み込みにも対応していませんでした。

healthcheck サブコマンドはこの課題を解決します。サポート対象のエコシステムごとに、以下の 3 段階で検証を行います。

1. 設定確認：パッケージマネージャーが Guard プロキシを参照しているかを検証する
2. 接続確認：Guard プロキシへの到達性を確認する
3. ブロックテスト：ブロック対象のテスト用パッケージのインストールを試行し、拒否されることを検証する

このサブコマンドは読み取り専用であり、API クレデンシャル（TG_BOT_API_KEY / TG_BOT_ID）は不要です。

利用方法​

setup.sh install の完了後にヘルスチェックを実行します。

./setup.sh healthcheck

特定のエコシステムのみを確認する場合は、引数でスコープを指定します。

./setup.sh healthcheck golang

終了コード​

ヘルスチェックは終了コードで結果を返すため、管理ツールによる定期実行や自動化に組み込むことができます。

出力例​

$ ./setup.sh healthcheck golang

[OK] go: GOPROXY → https://golang.flatt.tech
[OK] go: Guard proxy reachable
go: creating new go.mod: module healthcheck-tmp
[OK] go: sentinel module hola-takumi-go@v0.1.0 correctly blocked

[OK] All healthchecks passed

サポート対象のエコシステム​

ヘルスチェックは現在 npm、RubyGems、Go に対応しています。PyPI については、テスト用パッケージの公開後に対応予定です。

ヘルスチェックサブコマンドの詳細については、ユーザーガイドの管理ツールによる一括セットアップ — ヘルスチェックを参照してください。

変更背景​

npm v11.15.0 では、サプライチェーン保護機構である --allow-remote チェックの強制が導入されました。このチェックでは、設定されたレジストリと異なるホストを指す tarball ダウンロード URL を持つ依存パッケージは「remote」として分類され、推移的依存パッケージのダウンロードが拒否されます。

従来の Takumi Guard は、npm クライアントに対してアップストリーム（registry.npmjs.org）の tarball URL をそのまま配信していました。新しいチェックの下では、設定されたレジストリ（npm.flatt.tech）と tarball のホストが一致しないため、npm v11.15.0 以降では Takumi Guard 経由のインストールが EALLOWREMOTE エラーで失敗する場合がありました。

今回の変更により、npm v11.15.0 以降のクライアントに対しては tarball URL を Takumi Guard 自身のホストに書き換えて配信するようになり、正しく「registry」として分類されるようになります。今後の npm のリリースではこのチェックがさらに強化される予定であり（tarball URL がレジストリのパス配下にあることの検証など）、現在および将来の npm バージョンとの互換性を保つために必要な変更となります。

変更の影響範囲​

npm v11.15.0 以降への影響: 有​

新規追加・更新されたロックファイル（package-lock.json）のエントリには、従来のアップストリームの URL ではなく、Takumi Guard のレジストリ URL（https://npm.flatt.tech/...）が resolved フィールドに記録されるようになります。これは意図された挙動であり、npm のサプライチェーンチェックの下でインストールを成功させるために必要な変更でございますので、ご理解いただけますと幸いです。

パッケージの完全性検証への影響はありません。integrity ハッシュは変更されず、npm audit signatures によるレジストリ署名・アテステーションの検証も従来どおり機能します。

npm v11.15.0 未満への影響: 無​

影響はありません。従来どおりアップストリームの tarball URL が配信され、ロックファイルにも変化はありません。

pnpm・Yarn・Bun への影響: 無​

本変更による影響はありません。pnpm は pnpm-lock.yaml に tarball URL 自体を記録しないため、ロックファイルにレジストリのホストが含まれることはありません。Yarn v1 については、以前のリリースノートでご案内したとおり、既に yarn.lock に Takumi Guard の URL が記録される挙動となっています。Yarn v2–v4（Berry）および Bun への影響はありません。

推奨事項​

ロックファイルにレジストリ URL を残したくない場合は、pnpm への移行をご検討ください。pnpm はロックファイルに tarball URL を埋め込まず、Takumi Guard とシームレスに連携できるほか、サプライチェーンセキュリティの観点でも優れた機能を備えています。