AIチュートリアル

Iron LawsでAI生成コードを監査・改善する

Iron Lawsのインストール、プロジェクトのスキャン、AI対応の修正手順の生成、適用しきい値の設定、ベースラインと抑制の管理、AIパッチの検証、SARIFレポートとGitHub Actionsの統合方法を学びます。

2026年10月4日約19分で読了

Iron Lawsとは？

Iron Lawsは、오철칙としても知られる、AI生成プロジェクトでよく見られるセキュリティと保守性の問題を検出するための静的検査ツールです。企業や公共部門のシステム統合監査から得られた知見を適用し、各検出結果をわかりやすい言葉で説明します。

このツールは、アプリケーションが単に動作するかどうかだけを確認するものではありません。ハードコードされた秘密情報、安全でない入力処理、握りつぶされた例外、認証のない管理用API、欠落したSupabaseまたはFirebaseのアクセス制御、コミットされた.envファイル、重複関数、循環依存、型安全性の回避などの問題を検査します。

Iron Lawsは、AIコーディングアシスタントに貼り付けられる、構造化された修正手順も生成します。これにより、次の反復可能なワークフローを実現できます。

AIで構築 → iron-laws check → iron-laws fix-prompt
→ AIに検出結果を修正させる → もう一度checkを実行

Iron Lawsは開発時のレビュー支援ツールであり、公式の認証製品でも、アプリケーションが安全であることの証明でもありません。テスト、コードレビュー、その他のセキュリティツールと併用してください。

主な機能

セキュリティと品質の検査

このプロジェクトには、複数の領域にまたがる90個のルールが含まれています。

リファレンスルール：韓国行政安全部のソフトウェア開発セキュリティガイドで参照されている、実装段階の49項目すべてをカバーしています。インジェクション、XSS、SSRF、XXE、脆弱な暗号処理、証明書検証の無効化、安全でないデシリアライゼーション、エラー処理、メモリ安全性などが含まれます。
AIコードの修正：ハードコードされた設定、秘密情報のフォールバック値、フロントエンドでの秘密情報の露出、安全でないCORS、欠落したアクセスルール、危険なDockerまたはCI設定、依存関係名の誤記、固定されていない依存関係、機密情報のログ出力、IDOR、Cookie属性を検査します。
アーキテクチャチェック：過大な関数やファイル、不適切なレイヤー依存、リクエストハンドラーからのデータベースへの直接アクセス、循環依存、重複関数、繰り返される文字列定数、欠落したテストを検査します。
型安全性チェック：TypeScriptのanyと@ts-ignore、Pythonのtype: ignoreとキャスト、Javaのraw型、C#のdynamic、その他の対応言語における型システムの回避を検査します。

読みやすい検出結果と修正ガイダンス

すべての検出結果には、問題の説明、危険な理由、修正方法が含まれます。公開ガイドの項目に対応するルールでは、項目番号とCWEマッピングもレポートに含まれます。プロジェクト固有の品質ルールは、外部要件ではなくIron Lawsのルールであることが明示されます。

AI対応の修正プロンプト

fix-promptコマンドは、検出結果を重大度別に整理し、AIコーディングツール向けの指示に変換します。プロンプトでは、エラーを握りつぶさないこと、ソースコードに秘密情報を置かないこと、型チェックを回避しないこと、重複実装を作成しないことといった原則も強調されます。

ローカル解析

必要なパーサーはパッケージに含まれているため、インストール後はネットワークアクセスなしで検査を実行できます。

言語とファイルのサポート

サポートの深さは、言語とファイル形式によって異なります。

詳細サポート：Python、JavaScript、TypeScript、Java、C#では、構文解析、入力追跡、最も広範なルールカバレッジが提供されます。
基本サポート：GoとPHPでは、構文解析に加えて、重要なインジェクション、エラー処理、暗号処理のチェックが提供されます。
限定サポート：RustとC/C++では、エラー処理、メモリ使用、フォーマット文字列、API、型の回避に関するチェックが提供されます。
設定および定義ファイル：SQL、YAML、JSON、.env、Dockerfile、Compose、GitHub Actions、MyBatis XML、HTMLテンプレートを対象に、関連する秘密情報、アクセス制御、デプロイ、エスケープの問題を検査します。

関数内では、Iron Lawsが分岐、ループ、例外を通じたフローを解析します。同一ファイル内のヘルパー呼び出しは、最大4レベルまで追跡します。Pythonではさらに、解析上の制限はあるものの、インポートを通じた実験的なファイル横断追跡が可能です。他の言語では、ファイル横断のフローが見逃されたり、レビューが必要なものとして報告されたりする場合があります。

インストール

Iron LawsにはPython 3.12以降が必要です。uvを使ってスタンドアロンツールとしてインストールする方法が推奨されています。

uv tool install git+https://github.com/JinHo-von-Choi/iron-laws.git

また、pipでインストールすることもできます。

pip install git+https://github.com/JinHo-von-Choi/iron-laws.git

インストール後、同梱されたルールを一覧表示してコマンドが利用可能であることを確認します。

iron-laws rules

言語およびルールごとの実装状況と検証状況を確認するには、次を実行します。

iron-laws support

パーサーが存在するからといって、その言語ですべてのルールが検証済みであるとは限らないため、この区別は重要です。

最初の検査を実行する

現在のプロジェクトをスキャンする

プロジェクトディレクトリでターミナルを開き、次を実行します。

iron-laws check .

デフォルトでは、HIGH以上の重大度の検出結果が見つかるとコマンドは失敗します。終了コードは次のとおりです。

0：選択した重大度ポリシーに基づき、検査に合格しました。
1：設定された失敗重大度以上に該当する検出結果が少なくとも1件ありました。
2：入力または設定が無効である、検査対象ファイルがない、またはルールエラーやファイル読み取り失敗などにより検査を完了できませんでした。

不完全な検査では、確定した評価や合格結果は得られません。その理由は diagnostics に記録されます。また、--allow-empty を明示的に指定しない限り、対象が空の場合もスキャン成功とはみなされません。

個別のルールを理解する

ルールを平易な言葉で説明する必要がある場合は、explain を使用します。

iron-laws explain IL-501

参照されている49個の実装項目のうち、どれが対象になっているかも確認できます。

iron-laws coverage

レポートを生成する

参照されている49個すべての項目の検査ステータスを含むMarkdownレポートを生成するには、次を実行します。

iron-laws audit . --format markdown -o report.md

GitHub Code Scanningやその他の互換システム向けにSARIFファイルを生成するには、次を使用します。

iron-laws audit . --format sarif -o iron-laws.sarif

AIコーディングアシスタント向けの指示を生成する

検出結果を確認した後、AI向けの修正プロンプトを生成します。

iron-laws fix-prompt .

生成された指示をコーディングアシスタントに貼り付け、提案された変更を確認してから、もう一度検査を実行します。

iron-laws check .

fix-prompt コマンドは、検出結果が存在する場合でも終了コード 0 を返します。これは指示を生成することが目的だからです。デプロイのゲートとして使用しないでください。強制適用には check または audit を使用します。

認識されたシークレット値は、レポートと生成されたプロンプト内で **** にマスクされます。ただし、認識されないシークレットは自動的にマスクできないため、生成されたテキストを外部のAIサービスに送信する前に確認してください。

プロジェクトポリシーを設定する

次のコマンドで初期設定ファイルを生成します。

iron-laws init

このプロジェクトでは .iron-laws.yml を使用します。一般的な設定は次のとおりです。

fail_on: HIGH
excludes: [".git", "node_modules", "dist"]
disabled_rules: ["ARC-206"]
limits:
  max_function_lines: 80
  max_file_lines: 600
  max_parameters: 7
  max_nesting: 5
  duplicate_similarity: 0.9

fail_on には CRITICAL、HIGH、MEDIUM、LOW を指定できます。優先順位は、--fail-on コマンドラインオプション、設定ファイル、デフォルト値の HIGH の順です。レポートには、現在のしきい値をどの設定元が指定したかが記録されます。

デフォルトでは、Iron Lawsは検査対象ディレクトリの設定を使用します。特定のファイルを選択するには --config を使用し、親ディレクトリを検索するには --search-parents を使用します。不明なキーや無効な設定は黙って無視されず、終了コード 2 が返されます。

意図的な例外を処理する

誤検出や意図的な例外を抑制できるのは、抑制に理由が含まれている場合だけです。理由のないコメントは無視されます。

Pythonで1件の検出結果を抑制するには、次のようにします。

except ImportError:  # iron-laws: ignore[IL-301] Optional dependency disables this feature
    yaml = None

ファイル全体に対してルールを抑制するには、最初の30行以内に ignore-file ディレクティブを記述します。

# iron-laws: ignore-file[IL-102] Pattern definitions intentionally identify weak algorithms

抑制には有効期限を指定できます。

# iron-laws: ignore[IL-101] until=2026-12-31 Temporary exception with documented reason

期限切れの抑制は適用されなくなり、レポートに表示されます。Iron Lawsは、未使用の抑制や不明なルールIDへの参照もレポートします。

既存プロジェクトにIron Lawsを導入する

ベースラインを作成する

既存のリポジトリに承認済みの検出結果がすでにある場合は、それらを承認済みの技術的負債として記録します。

iron-laws baseline create .

その後、保存したベースラインに対して新たに導入された検出結果だけを評価します。

iron-laws check . --baseline .iron-laws-baseline.json

変更されたファイルを検査する

変更されたファイルに焦点を当てたプルリクエストのフィードバックを行うには、メインブランチとの差分を比較します。

iron-laws check . --changed-since origin/main

READMEでは、リポジトリ全体の問題を見落とさないよう、変更ファイルの検査を完全スキャンおよび定期スキャンと組み合わせることを推奨しています。

レビューのフィードバックを記録する

レビューが必要とマークされた検出結果は、分類してレビューコストを割り当てることができます。

iron-laws feedback add IL-501 src/a.py:3 --verdict false-positive --minutes 10

AI生成パッチを検証する

Iron Lawsには、AIがコードを変更した後に何が検証され、何が検証されなかったかの証拠を保持する高度なワークフローが含まれています。

証拠契約を確認する

証拠契約は、スキャンが完了しただけの場合と、必要な証拠が実際に生成された場合を区別します。

iron-laws check . --contract .iron-laws-contract.yml

解決されていない入力ソースが、自動的に問題のない結果へ変換されることはありません。現在、証拠契約ではPythonコマンド実行、パスアクセス、SQL構築の各ファミリーが対象となっています。

パッチ検証レシートを作成する

提案されたパッチを検査し、検証レシートを保存するには、次のようなコマンドを実行します。

iron-laws verify-patch . --patch fix.diff \
  --finding IL-504@app.py:6 \
  --runner docker \
  --image IMAGE_NAME \
  -o receipt.json

検証ツールは、同じポリシーを使用して元の状態と候補を比較します。テストの削除、スキップの追加、新しいignoreコメント、ポリシーの弱体化など、疑わしい変更は個別にレポートされます。警告が消えたことだけでは、有効な修正の証明とはみなされません。

テストは、認証情報を使用しない使い捨ての隔離環境でのみ実行されます。隔離環境を確保できない場合、Iron Lawsはホスト上でテストを黙って実行せず、結果を不確定のままにします。

識別力のある回帰テストを提案する

検出結果に対する回帰テスト仕様の候補を生成できます。

iron-laws regression propose . --finding IL-504@app.py -o spec.yml

想定される検証パターンでは、元のコードが欠陥のために失敗し、候補の修正では成功し、さらに修正を元に戻したミューテーションでは再び失敗することを確認します。READMEでは、この一連の処理を3回繰り返すよう説明しています。生成されたテストは、確認されるまで提案のままです。

人による承認を記録する

理由を添えて承認を保存します。

iron-laws approvals add . \
  --finding IL-504@app.py \
  --reason "Documented review reason" \
  --store approvals.jsonl

スキャン中に有効な承認を適用します。

iron-laws check . --approvals approvals.jsonl

承認は、その前提が維持されている間だけ有効です。呼び出し元、データフロー、サニタイザー、アクセス範囲、またはルールの意味が変更された場合、再レビューが必要になることがあります。脆弱なコードを複製しても、既存の承認は引き継がれません。

GitHub Actionsと統合する

次のワークフローはIron Lawsをインストールし、SARIFレポートをアップロードした後、高重大度のデプロイゲートを適用します。

name: Iron Laws
on: [push, pull_request]
jobs:
  audit:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v3
      - run: uv tool install git+https://github.com/JinHo-von-Choi/iron-laws.git
      - run: iron-laws audit . --format sarif -o iron-laws.sarif || true
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: iron-laws.sarif
      - run: iron-laws check . --fail-on HIGH

検出結果が存在する場合でもSARIFファイルをアップロードできるよう、レポート生成ステップでは|| trueを使用しています。実際の成功・失敗ゲートは、最後のcheckコマンドが提供します。

実用上の制限

クリーンな結果は、実装済みのルールと対応する分析範囲内で問題が見つからなかったことを意味します。アプリケーションに脆弱性がないことを証明するものではありません。
ファイル間の入力追跡はPythonでは実験的で、その他の言語では限定的です。一部のフローが見逃されたり、手動レビューが必要なものとして報告されたりする場合があります。
サニタイザーは、HTML、SQL、シェルコマンド、パスなど、保護するコンテキストに対してのみ認識されます。
READMEによると、パッチ検証、回帰テスト、承認追跡は、独立した評価や実環境での試験をまだ受けていません。
プロジェクトが引用するOWASP Benchmarkの結果では、複数のカテゴリで改善が示されていますが、安全にサニタイズされたSQLやコマンドインジェクションのケースを含め、誤検知は残っています。
パッケージリポジトリを参照しない限り、すべての偽造依存関係を確実に特定することはできません。代わりに、人気パッケージに似た名前を報告します。
圧縮ファイルと生成ファイルはスキップされ、その理由はskipped_filesに記録されます。

詳しくは、リポジトリのドキュメントにあるパッチ検証、精度測定、言語とルールの対応状況、レポート形式を参照してください。

まとめ

Iron Lawsは、AIが生成したソフトウェアをレビューし、隠れたセキュリティや保守上の問題が本番インシデントになる前に対処するための、体系的な方法を提供します。まずiron-laws check .を実行し、説明を確認して修正プロンプトを生成し、AIの変更をレビューしてから、もう一度スキャンします。プロジェクトの成熟に合わせて、設定、ベースライン、SARIFレポート、パッチレシート、人による承認を追加すると、プロセスを反復可能かつ監査可能にできます。

このプロジェクトはMIT Licenseの下で提供されています。その結果は、テスト、手動コードレビュー、より広範なセキュリティ評価を置き換えるものではなく、それらを補完するものとして利用してください。