第9回：IBM Bobのコードと設計の脆弱性チェック

はじめに

IBM Bobには、堅牢なエンタープライズシステムを開発するため、「シフトレフト（開発の早期段階での対処）」と、「セキュア・バイ・デザイン（設計段階からの安全確保）」を可能にする様々な技術が実装されています。コーディングと設計のチェックについて、軽く動作確認してみました。

コーディングの脆弱性チェック

シフトレフトの三段階

IBM Bobは、「入力→実装→実装の最後（提出前）」の三段階で、コードのセキュリティを担保してくれます。

入力段階（リアルタイム・ガードレール）

開発者が、Bobに、「このコードを実装して」などとプロンプトを送信するときに、Bobが悪意のある指示の混入（プロンプト・インジェクション）を防いでくれます。プロンプトは自然言語による指示なので、既存のテキストベースのスキャンツールでは検出できません。（絵文字を混ぜる手法で簡単にバイパスされてしまいます。）そこで、対プロンプトインジェクション用に機械学習された専用のAIスキャンツールとして、Palo Alto NetworksのPrisma AIRSがビルトインされており、文脈や意図から悪意のある指示を検出してくれます。

実装段階（インラインスキャン）

.javaなどの実装コードにカーソルを当てると、「Bob-Setting」で、SECURITY SCANのOn / Offを確認できます。（デフォルトはオンです。）

Vulnerability Scan：脆弱性チェック
AIと対話しながら実装するコードを書くとき、BobはIDE上でコード・アクションとして、脆弱性チェックをしてくれます。文字列パターンだけでなく、コードの構造（抽出構文木）を理解してマッチングするSemgrep（OSSのSAST: Static Application Security Testing 静的アプリケーションセキュリティテストツール）を用いて、高精度なチェックを実施します。

Secrets Scan：機密情報の検出
APIキーや認証情報を検知し、情報漏洩を防ぎます。

実装の最後（コードレビュー）

Bobは開発者の意図を理解し、プルリクエストの前にセキュリティ上の欠陥をチェックする、エージェント型のコードレビューを実行します。（3/25現在、Skillsに対応し、スキルベースのワークフローで、脆弱性レビューを実行することができます。）

脆弱性チェックの実行

インラインスキャン動作確認をしました。
※ 以下、アーリーアクセス版での検証です。

チェックの実行

チェックしたいコードをエディタで範囲選択し、右メニューから「IBM Bob」→「コードの改善」を選択します。
今回は全選択していますが、部分選択の場合は、選択した範囲のみチェックが行われます。

上記の方法以外では、以下の方法もあるようです。

VSCodeのコマンドパレットから「IBM Bob: コードの改善」を選ぶ

プロンプトで直接「〇〇の脆弱性チェックをしてください」と指示する
※ 自動チェック（コード編集時に即時指摘）は見当たりませんでした。

チェック結果

チャット欄には以下のような結果が記載されます。（抜粋）

また、「IBM BOB FINDINGS」というビューに結果が表示されます。

レポートの出力や、修正の依頼は、プロンプトで指示すると行ってくれます。

情報源

情報源として使っている情報と、その鮮度について質問してみました。

他のツールとの違い

Github Copilot

スキャン機能あり（ソース）。ただしチャット欄からプロンプト入力のみ。
Github Actionで脆弱性チェックする機能がある。（CodeQLなど. Copilotの機能とは言えないが）

Claude CodeやCodex

脆弱性チェックの標準機能はなし

実開発ではツール（JavaだとSpotBugsやSonarQubeなど）を使ったチェックが浸透しているので、AIでのチェックはそれほど重要ではないようにも思います。

設計段階のチェック

設計段階では、どうでしょうか？
試しに、プロンプトで「設計書のチェック」を行い、どんな結果になるかを試してみます。
検査に使ったのは、Speckit（Spec駆動開発のツールキット）ベースで作成した仕様ファイル（spec.md, plan.md）です。

Bobに指示を出すと、Bobは以下のようなTodoリストを作成して作業を開始しました。

以下のような分析結果が出力されました。

ひとまず、脆弱性があることを指摘することはできました。
実開発では、Bobにレビューしてもらうというよりは、「Bobと会話を繰り返しながら設計を詰めていく」というイメージですね。

明示的なチェックをタスクにする場合、チェックリストなどを作ってチェック結果を可視化する必要があります。

まとめ

セキュリティを考慮しながら設計・機能実装をすることは、時に開発者のスピードを落とすことがありますが、開発の流れに沿って、IDEから離れることなく、Bobがチェックを手伝ってくれるのはありがたいです。
このほかにも、組織独自のカスタムルールをリポジトリ内に定義することができ、AIがルールに反する提案をすることを抑制したり、チェックポイントを設けて、Bobが意図しない変更をした時に復元するなど、開発ライフサイクルを通した様々な機能があるようです。これらの機能を使いこなしながら、Bobとうまく付き合っていけるといいですね。

※ 記載の製品名及び社名は各社の商標もしくは登録商標です。
※ IBM、ibm.comは、米国やその他の国におけるInternational Business Machines Corporationの商標または登録商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点でのIBMの商標リストについては、ibm.com/trademarkをご覧ください。

執筆者：
IBM Bob検証コミュニティ（基盤システム本部　モダナイゼーション部　代表編集）

前話へ

連載コラム：IBM BobでAIエージェント開発を試してみた

エクサでは、様々なAIエージェントを検証していますが、セキュリティや規制が厳しいエンタープライズの基幹システム構築やレガシーモダナイゼーションにも適用可能な選択肢として、間もなく正式版が公開されるIBM Bobの活用も視野に入れています。
公開に先立ち、アーリーアクセス版を試用しましたので、その過程を共有します。