Open Source · MIT · @aegiskit
Aegis — Next.js / Supabase の
AIコーディングエージェントを含め、速く出荷する開発者が見落としがちな統制を自動化するOSS。ヘッダー/CSP・レート制限・入力検証・CSRF・秘密情報衛生を肩代わりし、ライブラリには直せない縦のリスク（認可/IDOR・RLSの設計ミス）を検出して警告します。
npx @aegiskit/cli scanインストール・設定不要。いまのプロジェクトを静的解析する。インストールも設定も不要です。
「完全に守る」とは言いません。どんなツールもそうは言えず、そう謳う製品はむしろ危険です。Aegisはセキュアな設計を補完するものであって、置き換えるものではありません。
なぜ必要か
「デモは動く」と「本番で漏れない」は別物だ
生成AIはハッピーパスのコードを驚くほど速く書きます。しかし本番で問われるのは、不正な入力・同時アクセス・他人のIDを指す正規リクエストにどう振る舞うか。ここが抜けたまま出荷すると漏れます。これは感想ではなく、公開された事実です。
オブジェクト単位の認可欠陥（IDOR / BOLA）は、OWASP API Security Top 10 で2019年以来ずっと第1位の最頻出リスク。
出典: OWASP API Security Top 10 — API1:2023 BOLAAIビルダー製アプリのRLS未設定により、未認証で他人のデータを読み書きできる事例が登録（CVE-2025-48757、CWE-863、CVSS 9.3 CRITICAL）。
出典: NVD — CVE-2025-48757AIが生成したコードの45%が既知のセキュリティ欠陥を含み、モデルが賢くなってもセキュリティ成績は横ばい。
出典: Veracode 2025 GenAI Code Security ReportSupabase の service_role キーは PostgreSQL の BYPASSRLS で動き、RLSを完全に無視する（守りの境界は鍵の置き場所に移る）。
出典: Supabase Docs — Row Level Security
この「RLSの外側に空くIDOR」を、脆弱→修正の実コードで深掘りした記事があります。
記事を読むAegis の守備範囲（正直に）
自動化できる「水平」と、できない「縦」
セキュリティ対策には、アプリ横断で一律に効く水平の統制と、アプリ固有の「誰が何を所有するか」に依存する縦のリスクがあります。前者はライブラリが肩代わりでき、後者はできません。Aegisはこの境界を誤魔化しません。
水平の統制
Aegis が自動化する
- セキュリティヘッダー / Content-Security-Policy（nonce対応）
- サーバーレスでも正しく効くレート制限（Upstash Redis 対応のアトミックなストア）
- CSRF / Origin 検証
- 型付き env 境界（`process.env` の直接参照を排除）
- 境界での入力バリデーション（Zod）と安全なデフォルト
- 秘密情報の混入検知（ハードコードされた鍵・トークン）
縦のリスク
Aegis は検出・警告のみ（修正はあなたの設計）
- 認可の欠陥 / IDOR・BOLA（他人のIDを指して他人のデータに触れる）
- Supabase RLS の設計ミス（未設定テーブル・service_role バイパス・WITH CHECK 欠落）
- 業務ロジックの欠陥（数量・価格・状態遷移の悪用）
- 権限昇格・テナント越境
これらは「製品を入れれば守られる」類のリスクではありません。WAFやヘッダーでも防げない——攻撃が認証も書式も正しい正規リクエストだからです。閉じるには設計とレビューが要ります。
できること
検出して、直して、CIで守り続ける
構文マッチングを超えたデータフロー解析と、SQLで書かれた認可境界の検証。静的で疑い、動的で確証し、安全なものだけ自動修正します。
静的解析（taint / データフロー）
構文マッチングでは見えない注入クラスを、関数内のデータフローで追跡。汚染された入力が、適切なサニタイザを通らずに危険なシンクへ到達する経路を、source→sink のトレース付きで指摘します。
- SQLインジェクション・SSRF・パストラバーサル・オープンリダイレクト・DOM XSS
- サニタイザの妥当性はシンク別に判定（URL安全 ≠ SQL安全）
- 所有権スコープのない汚染入力＝IDOR の検出（authz/idor-tainted-scope）
Supabase RLS / SQL 検証
TypeScriptスキャナが構造的に盲目な、SQLで書かれた認可境界を検証。`supabase/migrations/**.sql` を読み、RLS未設定・WITH CHECK欠落・無条件true・anonへの過剰付与・search_pathを固定しないSECURITY DEFINERを指摘します。
- 弱いRLSのテーブルを非管理クライアントが叩く箇所を「確定した露出」として相関
- 正しい本番RLS設計では0件になるよう設計（＝ノイズではなく実害）
- RLSは検証する——設計やレビューを置き換えはしない
安全な自動修正 + エージェント連携
証明可能に安全な変換だけを自動適用し（例：ルートハンドラを secureRoute で包む）、人間の判断が要るものはコピペ可能な手順として提示。直せないものを直したとは決して主張しません。
- `aegis fix` で安全な差分をプレビュー、`--write` で適用（git diff で確認）
- `--format json` で計画を機械可読化し、コーディングエージェントに渡せる
ランタイム強化（ミドルウェア）
ライブラリが正しく所有できる統制を、エッジ安全なプリミティブで一括導入。ヘッダー/CSP・レート制限・CSRF・型付きenv境界を、ミドルウェア1枚とenvモジュール1つで足します。
- @aegiskit/core はランタイム非依存（Node / Edge / Browser）
- fail-secure：曖昧さやエラー時は安全側に倒す（危険なヘッダーは出さない）
動的解析（DAST）と SAST↔DAST 相関
静的解析は「疑い」、動的解析は「確証」。自分が所有するアプリへ安全・境界つき・非破壊のHTTPを送り、実行時に再現したものを build-blocking に格上げします。
- 反射XSS・オープンリダイレクト・SQLi（真偽/エラー推論）・SSRF（OOBカナリア）
- テストID供給時は missing-auth / IDOR も確認（@aegiskit/dast）
- localhost既定・スコープ固定・リクエスト予算つきで安全
CI 連携（SARIF / 高信頼のみブロック）
高信頼の検出だけがCIを失敗させ、SARIFをGitHubコードスキャニングへアップロード。source→sink のデータフローがクリック可能なトレースとして残ります。
- GitHub Action（`aegis ci` ラッパー）で1ステップ導入
- ノイズを足さずに「歯」を足す——誤検知でビルドを壊さない
クイックスタート
3つのコマンドで始める
インストールも設定も不要。まずscanで現状を可視化し、initでランタイムを固め、probeで実行時に裏取りします。
- スキャン— インストール・設定不要。いまのプロジェクトを静的解析する
npx @aegiskit/cli scan - ランタイム強化— ヘッダー/CSP・レート制限・CSRF・型付きenv境界をミドルウェアで導入する
npx @aegiskit/cli init - ランタイム確認— 自分のアプリへ安全・非破壊なプローブを送り、静的検出を実行時に裏取りする
npx @aegiskit/cli probe http://localhost:3000 --correlate
CI に組み込む（SARIF を GitHub に連携）
高信頼の検出だけがビルドを失敗させ、データフローのトレースが GitHub コードスキャニングにクリック可能な形で残ります。
# .github/workflows/security.yml
name: Security
on: [push, pull_request]
jobs:
aegis:
runs-on: ubuntu-latest
permissions:
contents: read
security-events: write # upload SARIF to the Security tab
steps:
- uses: actions/checkout@v4
- uses: tomodahinata/aegis@main
with:
severity: HIGH
- uses: github/codeql-action/upload-sarif@v3
if: always()
with:
sarif_file: aegis.sarif正直なスコープ — Aegis が「しないこと」
「入れたから大丈夫」という油断こそ、最悪のセキュリティ結果を生みます。だから何ができないかを最初に明記します。
- 認可が「正しい」ことは証明しません。見ているのはポリシーや実装の“形”であって、あなたの事業ルールやデータモデルの“意味”ではありません。
- データフロー解析は intraprocedural（関数内）です。モジュールやフレームワークを跨ぐ流れは見逃します。
- RLS の設計・コードレビュー・脅威モデリング・手動ペネトレーションテストを置き換えません。補完します。
- クリーンな結果は「よくある罠は踏んでいない」であって、「このコードは安全だ」ではありません。
それでも、最頻出の穴を機械的に潰せる価値は計り知れません。検出が“歯”を持ち、ノイズを増やさず、人間が本当に難しい判断（＝設計と認可）に集中できるようになります。
FAQ
よくある質問
Aegis は無料ですか？
はい。MITライセンスのオープンソースで、`npx @aegiskit/cli` から今すぐ使えます。スキャン・ランタイム強化・CI連携まで含めて無料です。
Aegis を入れれば、アプリは「完全に安全」になりますか？
いいえ。そう謳うツールはむしろ危険です（「入れたから大丈夫」という油断が最悪の結果を生みます）。Aegisは水平の統制を自動化し、ライブラリに直せない縦のリスク（認可/IDOR・業務ロジック）は検出・警告するだけです。セキュアな設計・コードレビュー・手動ペネトレーションテストを補完するものであって、置き換えません。
Next.js / Supabase 以外でも使えますか？
中核（@aegiskit/core）はランタイム非依存のプリミティブ群で、ヘッダー/CSP・レート制限・型付きenvなどは汎用に使えます。Next.js（App Router）アダプタとSupabase RLS検証は、その2つに最適化された部分です。
誤検知でCIが壊れませんか？
既定では高信頼の検出だけがCIを失敗させます。さらに静的解析の「疑い」を動的プローブで再現できたものだけを build-blocking に格上げするため、ノイズを足さずに実害だけを止められます。
AIが生成したコードのレビューにも役立ちますか？
まさにその用途を想定しています。AI生成のNext.js × Supabaseコードが頻繁に作り込む注入・RLS・認可の罠を機械的に洗い出し、`aegis fix --format json` で修正計画をコーディングエージェントへ渡せます。
検出された認可/IDORの問題は、どう直せばいいですか？
そこはライブラリの範囲外（=あなたの設計判断）です。RLSの張り方・service_role経路の所有権チェック・テナント分離は、設計とレビューで閉じる必要があります。手が足りなければ、その設計レビューと実装の支援を承っています。
次の一歩
無料のOSSで今すぐ試せます。そして、検出された「縦のリスク」を実際に塞ぐ設計レビューが必要なら、私が承ります。
設計レビューを依頼する
検出された「縦のリスク」、私が塞ぎます
認可/IDOR・Supabase RLS の設計・テナント分離は、ライブラリの範囲外＝設計判断です。既存の Next.js × Supabase アプリの認可レビューや、検出された問題の修正設計・実装を承っています。
セキュリティ監査を見る（料金・内容）スポット診断¥98,000〜／標準監査¥280,000〜。まずは30分の無料相談から。
まず自分で試す
無料・オープンソースで今すぐ
インストール不要。いまのプロジェクトを1コマンドでスキャンできます。MIT ライセンスで、改変も商用利用も自由です。
npx @aegiskit/cli scan有料の上位プラン「Aegis Team」は提供準備中です。先行登録（ウェイトリスト）はこちら