Skylos について
Skylosは、コード分析とプルリクエストのゲートに使うオープンソースのコマンドラインツールです。Pythonを最も深くカバーし、ほかの複数言語にも対応します。デッドコードを検出し、追加チェックでセキュリティ、シークレット、依存関係、品質、AI生成コードのリスクを分析します。
主な機能
- 01デッドコードと未使用ファイルの検出
- 02セキュリティ問題とコードフローのスキャン
- 03シークレットと依存関係の脆弱性確認
- 04コード品質とAIコードのリスク分析
- 05ブランチ変更とテスト保護の評価
活用シーン
- 01Pythonプロジェクトのデッドコード確認
- 02マージ前のエージェント作成ブランチの検査
- 03プルリクエストCIへのコードチェック追加
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。
詳細
翻訳後に原文が更新されています。最新の内容は原文をご確認ください。
Skylos
検査の根拠を示すコードチェック。
Skylos とは?
Skylos は、アカウントなしで実行できる、Python プロジェクト向けのオープンソース(Apache-2.0)の CLI およびプルリクエストゲートです。skylos . を実行すると、使われていない関数、クラス、インポート、空のファイルなどのデッドコードを検出します。-a を追加すると、セキュリティ上のバグ、ハードコードされたシークレット、脆弱な依存関係、コード品質、AI 生成コードの問題もチェックします。検出結果にはソースコード上の位置と、根拠となる分析が含まれます。skylos done を実行すると、多くの場合コーディングエージェントが作成したブランチが、マージできる状態かどうかをチェックします。
以下のユーザー向けに構築されています。
- Claude Code、Codex、Cursor などの AI コーディングエージェントからプルリクエストをマージするチーム。
skylos doneはテストを実行し、削除またはスキップされたテスト、緩和された CI のテスト手順、無効化された lint や型チェック、テスト専用の特例を検出します。 - フレームワークを考慮したデッドコード、セキュリティ、シークレットのチェックを求める Python のメンテナー。 最も幅広く対応しているのは Python です。その他の言語については言語サポートをご覧ください。
pip install skylos
skylos . # find dead code
skylos . -a # add security, secrets, quality, dependency and AI-code checks
skylos done --base main # is this branch finished? runs your tests, compares with main
見落としも含めた実績: Skylos を活用したデッドコード整理のプルリクエストは、Black、NetworkX、Optuna、mitmproxy、pypdf など、9 つのオープンソースプロジェクトで 10 件がデフォルトブランチにマージされています。実際の成果には、この一覧にある整理および品質修正のプルリクエスト 26 件が記載されています。クローズ、リバートされたものや、デフォルトブランチに到達しなかったものも含みます。これらは受け入れられた整理プルリクエストであり、推薦を意味するものではありません。
ウェブサイト | ドキュメント | リポジトリマップ | クイックスタート | GitHub Action | VS Code 拡張機能 | 実際の成果 | ベンチマーク | ロードマップ | コントリビューション
Skylos はデフォルトでローカル実行され、CI でプルリクエストのゲートとしても使用できます。リポジトリやプルリクエストを次の項目について、1 つのコマンドでチェックしたい場合にご利用ください。
- デッドコードと未使用ファイル
- セキュリティ上の欠陥と危険なデータフロー
- シークレットと依存関係の CVE
- CI/CD およびエッジデバイスへのデプロイ設定の誤り
- 複雑さ、重複する分岐、深いネストなどの品質低下
- ガード不足、偽のヘルパー、存在しないパッケージ API、実現不可能な依存関係のバージョンなど、AI 生成コードによくある問題
- 安全でないツールの使用や出力検証の不足など、LLM アプリのリスク
最も幅広く対応しているのは Python です。TypeScript/JavaScript と Java ではデッドコード、セキュリティ、品質のチェックも利用できます。PHP、Rust、Dart ではデッドコードとセキュリティのチェックが利用できます。Go のデッドコードとセキュリティのチェックには別途ビルドされた skylos-go エンジンが必要です。このエンジンはコンテナーイメージと GitHub Action に含まれていますが、PyPI パッケージには含まれていません。C# は一部のみ対応し、Kotlin はデッドコードのみ、C++ はファイル内でのみ使用される関数に限定して対応し、Shell はセキュリティのみ対応しています。Skylos は CI/CD とデプロイ設定もチェックします。言語サポートをご覧ください。
結果を読む
リスク、保守性、デッドコード、ゲートを確認してください。
| 読み取り項目 | 内容 |
|---|---|
| リスク | 未解決の問題のうち、最も高い重大度と件数です。リポジトリの規模にかかわらず、重大な問題が1件あれば重大な問題として扱われます。 |
| 保守性 | アドバイスの件数、影響を受けるコード単位、測定値が上限をどの程度超えているかを示します。 |
| デッドコード | 信頼度と根拠を伴う削除候補です。削除する前に、動的呼び出しと公開 API を確認してください。 |
| ゲート | 検出結果が設定済みの上限を満たしているかを示します。合格はポリシーの範囲内であることを意味し、検出結果がゼロであることを意味するわけではありません。 |
検出結果のタイプは重大度とは別です。欠陥は具体的な正確性に関わるパターン、要レビューはコンテキストの確認が必要なもの、アドバイスは保守性やツールに関するものです。要レビューの検出結果が重大である場合もあります。アドバイスはルールグループ内で引き続き表示されます。--expand-advice を指定するとすべての箇所が表示され、JSON には完全なレコードが保持されます。グループ化しても評価が改善されたり、ゲートを回避できたりすることはありません。
セキュリティの検出結果では、利用可能な場合、記録されたソースからシンクまでの根拠が表示され、静的解析が部分的な場合はその旨が示されます。依存関係のカバレッジでは、未解決のバージョンと、確認に必要なサポート対象の入力が示されます。どちらの表示も、実行時の悪用可能性や、インストール済み環境全体を網羅していることを示すものではありません。JSON には根拠の全体が保持されます。
uv.lock では、有効な Git、URL、パス、プライベートインデックスの依存関係は未チェックとして表示されます。Skylos はサポート対象の公開パッケージを引き続き照会します。カバレッジの不足だけを理由に終了コード 2 にはなりません。ただし、依存関係の評価に問題がないことを確認するものではありません。uv のソースカバレッジを参照してください。
新しいソーススキャンでは、従来の総合 A~F グレードに代わり、これらの読み取り項目が表示されます。無効なチェックは未評価、失敗したチェックは未完了です。保守性の割合は、実際に測定された関連単位のみを用いて算出され、分母を推測したり、未調整のグレードを使ったりしません。独立した debt スコアと defend スコアは、従来の意味を維持します。出力ガイドを参照してください。
適切なコマンドを選ぶ
各コマンドは、それぞれ異なる問いに答えます。ソースのスキャンでは PATH が必要です。
verify、suite、defend、clean の角括弧付きパスを省略すると、現在のディレクトリが使われます。suite と
defend にはディレクトリが必要です。verify と clean はファイルも受け付けます。
| 問い | コマンド | チェック対象 |
|---|---|---|
| このソースツリーにはどのような問題がありますか? | skylos PATH | ソースファイルとプロジェクト設定。デフォルトではデッドコードを検出し、-a を指定するとすべての主要なソースアナライザーを実行します |
| エージェントは本当にこのブランチの作業を完了しましたか? | skylos done --base main | main とのマージベース以降におけるブランチの変更。Skylos はテストを実行し(pytest は自動で実行します。他のランナーでは [tool.skylos.done] に test_command が必要です)、テスト、テスト設定、CI のステップをベースと比較し、レシートを .skylos/receipts/ に書き込みます |
| このコードには AI コードの誤りが含まれていますか? | skylos verify [PATH] | 選択したファイルまたはツリーに対する AI 欠陥チェックに加え、対応する Python の作業中の変更について、Git HEAD との動作比較を別途実行します |
| 静的解析で見つかったデッドコードをモデルにレビューさせるべきですか? | skylos agent verify [PATH] | デフォルトでは LLM を使用します。オプションで、Jev のみ、または Jev と LLM によるレビューを選べます |
| 統合リポジトリスイートはどのような結果を報告しますか? | skylos suite [DIRECTORY] | 静的解析、技術的負債、AI 防御、来歴。ローカルで検出された項目は、デフォルトではレポートのみです |
| エージェントの実装にはデプロイ時のガードレールがありますか? | skylos defend [DIRECTORY] | 認識対象の Python および TypeScript/JavaScript の LLM 統合。ゲートを有効にするには、しきい値フラグまたはポリシーが必要です |
| Skylos が削除できる Python のデッドコードはどれですか? | skylos clean [PATH] --dry-run | Python のインポート/関数のクリーンアップ候補。--dry-run は書き込みを行いません |
| このローカル GPU ビルドは、出荷先のマシンに本当に適合しますか? | skylos preflight [ARTIFACT] | ローカルのビルド済みファイルまたはディレクトリと .skylos/gpu-targets.yml。OCI リファレンスは識別にのみ使われ、CLI では UNKNOWN が返されます |
| このコンテナイメージにはどのような脆弱性がありますか? | skylos image scan IMAGE@sha256:<digest> --platform os/arch | 別途インストールした Trivy でスキャンするリモートレジストリイメージ。--fail-on を指定すると、検出結果がゲートになります |
この選択ガイドを表示するには skylos --help を、コマンドの詳細を表示するには
skylos <command> --help を、コマンド群の一覧を表示するには skylos commands を実行してください。
レポートコマンドでは、ゲートとネットワークの動作がそれぞれ異なります。
image scanでは、信頼できるPATH上に Trivy が必要です。また、Trivy のリモートイメージ ソースを使うため、レジストリへのネットワークアクセスと必要なレジストリ認証情報を 事前に利用できるようにしておく必要があります。--fail-onを指定しない場合、脆弱性が報告されても、スキャンが完了すれば終了コードは0です。suiteはローカルプロセスで実行され、--uploadを指定しない限りアップロードしませんが、依存関係のスキャンで OSV に問い合わせることがあります。検出結果はレポートのみで、件数にかかわらずコマンドは終了コード0を返します。運用上のエラーや出力エラーはゼロ以外の終了コードになります。--uploadを指定した場合は、アップロードエラーまたは Cloud 品質ゲートによって失敗することもあります。defendは、デフォルトではガードレールの検出結果を報告します。--fail-on、--min-score、または明示的なポリシーのゲート設定を指定すると、ゲートになります。cleanに--dry-runも--applyも指定しない場合は対話型で、最後に確認すると書き込みが行われることがあります。現在のコードモッドは Python のインポートと関数に対応しています。適用処理では個々の編集が失敗を出力しても終了コード0が返されるため、完了時の出力を確認してください。doneは、チェックに合格すると0、ブロック対象のチェックが失敗または未完了だと1、Skylos が実行できなかった場合(たとえば、ベースがフェッチされていない場合)は2を返します。設定はベースコミットから読み込むため、変更によって自身のゲートを緩和することはできません。
60 秒で始める
pip install skylos
skylos .
4.47.2 より前のバージョンでは、pip install skylos を実行すると、ソースからビルドされ、C コンパイラーを必要とする Dart パーサーもインストールされます。4.47.2 以降では、Dart のサポートはオプションの skylos[dart] エクストラです。コンパイラーがないためにインストールが失敗する場合は、コンテナイメージを使用してください。
オプションの Rust による高速化は、ソースからビルドできます。
標準のインストールでは Python のフォールバックを使用します。高速化された処理と、
検出結果に生じる可能性のある差異については、ビルドガイドを参照してください。
デフォルトのスキャンはデッドコードに焦点を当てています。セキュリティ、シークレット、
品質、依存関係、AI 欠陥チェックを含むすべての主要なソースアナライザーを実行するには、
-a を使用します:
skylos . -a
ブランチ(多くの場合 AI エージェントのもの)が本当に完了しているかを確認します:
skylos done --base main
skylos done はブランチを main 上のマージベースと比較し、テストを実行します。
削除またはスキップされたテスト、緩和されたテスト設定と CI テストステップ、無効化された
lint または型チェック、テストを特別扱いするコードを検出し、レシートを
.skylos/receipts/ に書き込みます。pytest は自動的に実行されます。それ以外のテスト
ランナーには [tool.skylos.done] に test_command 行が 1 行必要です。すべてのチェックと
その限界については、done ゲートガイドを参照してください。
エビデンスに基づく AI 欠陥チェックのみを実行するには:
skylos . --ai-defects
エージェントがレビューに引き渡す前に、リポジトリ、ファイル、または範囲を検証します:
skylos verify . --file src/app.py --range 40:75 --project-context
. のようなディレクトリの場合、AI 欠陥スキャンは選択されたツリーを対象とします。
別個の behavior 結果は、サポート対象の Python ワーキングツリーの変更を Git HEAD と
照合してモデル化しますが、これは AI 欠陥スキャンのスコープセレクターではありません。
依存関係ハルシネーションチェックはパスターゲットに対して有効になり、パッケージ
レジストリに問い合わせることができます。これらのルックアップを無効にするには
--no-dependency-hallucinations を使用します。選択されたファイル/範囲内の高/重大な
セキュリティ検出 (category: "security") およびハードコードされたシークレット
(category: "secret"、値は伏せ字) も検証を失敗させます。AI コードのみの判定には
--no-security を使用します。
対話型ターミナルでは人間向けレポートが表示されます。リダイレクトされた stdout と
-o はバージョン付き JSON 結果を生成します。
skylos verify スキーマバージョン 2 は pass、fail、または incomplete を返します。
incomplete は、要求された証明を確立できなかったことを意味します。たとえば、ローカルの
TS/JS インポートの欠落、計算された名前空間メンバー、サポートされていない言語ローカルな
API チェック、または Skylos が証明できなかったパーサーサーフェスなどです。--no-fail が
設定されていない限り、終了コード 2 で終了します。coverage オブジェクトには、検出された
言語、期待されるチェック、言語サポート、欠落しているチェック、完了/スキップされたチェック、
チェックされた参照、および決定論的なスキップ理由が一覧表示されます。宣言された
サードパーティ依存関係と認識された Node ビルトインは、ローカルの TS/JS API 証明の対象外です。
それらの参照は out_of_scope_references にカウントされ、クリーンな検証を incomplete に
することはありません。未知のベアインポートは依然としてレビューが必要です。
決定論的なローカル/ワークスペース API 検証は、現在、対象コードを実行せずに Python、 TypeScript/JavaScript、Go、Java をカバーしています。PHP、Rust、Dart、C#、Kotlin、Shell は 既存の静的解析カバレッジを維持しますが、それらのローカル API 証明はサポート外として 報告されるため、incomplete となります。AI コード検証カバレッジ を参照してください。
リポジトリ固有の生成コードの真実に関するローカル AI ハルシネーションコントラクトを
作成します。skylos verify は .skylos/ai-contract.yml を自動検出します:
skylos contract init
skylos contract inspect
skylos verify .
実行中のエージェントを決定論的な応答およびツール使用シナリオに対してテストします:
skylos agent init
skylos agent test --allow-contract-endpoint
しきい値、無視、テンプレートフック、vibe 辞書拡張を含むプロジェクト設定を作成します:
skylos init
スターターのローカルルールパックを作成します:
skylos rules init
skylos rules validate .skylos/rules/local.yml
skylos rules list --json
skylos rules list cross --json
skylos rules list --packs --json
skylos cache stats
GitHub Actions でプルリクエストをゲートします。Skylos アカウントや API キーは 不要です:
git checkout -b add-skylos-gate
skylos cicd init --no-upload
git add .github/workflows/skylos.yml
git commit -m "Add Skylos pull request gate"
git push -u origin add-skylos-gate
gh pr create --fill
生成されたワークフローはプルリクエストの変更行をレビューし、テストを検出すると
skylos done ジョブを追加します。--no-upload を指定しない場合、デフォルトブランチへの
プッシュ用に Skylos Cloud アップロードジョブも追加されますが、これはリポジトリに
Skylos GitHub App がインストールされるまで失敗します。
最初の Skylos ゲート付きプルリクエストでは、チェックを
必須にすることを含め、約 8 分で手順を説明しています。
ゲート(skylos . --gate、skylos cicd gate、および生成されたワークフロー)は、重大なセキュリティ上の問題、シークレット、および PyPI に存在しないパッケージのインポート(SKY-D222)や、定義もインポートもされていない関数の呼び出し(SKY-L012)など、重大な AI コードの問題が1つでもあれば失敗します。それ以外の指摘事項は、件数が上限を超えた場合にのみ失敗します。pyproject.toml の [tool.skylos.gate] で上限を変更できます。
[tool.skylos.gate]
max_high = 5 # high-severity security issues allowed
max_quality = 10 # quality issues allowed
max_ai_defects = 10 # AI-code issues allowed (defaults to max_quality)
# AI-code issues at these severities fail the gate whatever max_ai_defects
# allows. Add "HIGH" to block more; [] turns the rule off.
block_ai_defect_severities = ["CRITICAL"]
max_ai_defects と block_ai_defect_severities は別々にチェックされ、どちらか一方でも失敗するとゲートは失敗します。プルリクエストでは、skylos cicd gate --diff-base はベースブランチからこのポリシーを読み込むため、プルリクエストからルールを無効にすることはできません。Skylos Cloud から同期されたゲートポリシーは、リポジトリの [tool.skylos.gate] セクションを置き換えます。
ゲートを実行すると、判定とその理由を示す行が最後に出力されます。Quality Gate: PASSED、Quality Gate: FAILED(終了コード1)、または必要な解析が完了しなかった場合(たとえば、依存関係スキャンで解決できないロックファイルがある場合)の Quality Gate: INCOMPLETE — could not decide (exit 2) です。各理由には、中断したチェック、確認できなかったファイルまたは依存関係の数、変更すべき内容が示されます。--format json では、最上位の gate オブジェクトに同じ判定が含まれます。簡潔な形式、LLM 形式、GitHub 形式、GitLab 形式の出力では、判定が標準エラー出力に表示されます。終了コードと不完全な解析を参照してください。
ほかのコマンドについては、CLI リファレンスをお読みください。
すべてのエージェントの編集をチェックする(Claude Code、Codex、Cursor)
エージェントの作業中にチェックできるよう、ローカルフックをインストールします。
skylos agent install-hooks # Claude Code (.claude/settings.json)
skylos agent install-hooks --codex # Codex (.codex/hooks.json)
skylos agent install-hooks --cursor # Cursor (.cursor/hooks.json)
- 編集のたびに: 変更された行のみを検証し(セキュリティ、シークレット、AI コードの誤り)、エージェントに修正内容を伝えます。
- ファイルの読み取り前: ハードコードされたシークレットを含むファイルをブロックします。
- パッケージのインストール前: 幻覚によるパッケージやタイポスクワッティングされたパッケージをブロックします。
- 停止時: エージェントが追加した未解決の問題が残っている場合、「完了」とするのをブロックします。
フックはフェイルオープンですが、決して通知なしに通すことはありません。Skylos でエラーが発生した場合、チェックなしで操作を許可したことがエージェントとユーザーに通知され、stop では未チェックの件数が報告されます。フックは .skylos/hook.log に記録され、既存のフックと統合されます。--uninstall は Skylos のエントリのみを削除します。契約、レイテンシ、制限については、エージェントループフックを参照してください。
Cursor では、指摘事項は各編集後ではなく、stop 時に通知されます。フックはサンドボックスではありません。編集、ファイルの読み取り、パッケージのインストールはチェックしますが、すべてのコマンドをチェックするわけではありません。フックが行わないことを参照してください。
よくあるワークフロー
| 目的 | コマンド | 得られるもの | 詳細 |
|---|---|---|---|
| 初回のデッドコードスキャン | skylos . | 未使用の関数、クラス、インポート、ファイル、フレームワークのエントリーポイントの誤りを検出します | デッドコードのドキュメント |
| 決定論的なクリーンアップのプレビュー | skylos clean . --dry-run --types import,function --confidence 80 | Python のインポート/関数の削除予定を、書き込みを行わずに表示します。ファイルを編集するには --apply を追加します | デッドコードのドキュメント |
| セキュリティと品質の監査 | skylos . -a | 危険なデータフロー、シークレット、依存関係、設定、品質、AI の欠陥に関するチェックを追加します | セキュリティのドキュメント |
| リポジトリの統合レポート | skylos suite . | 静的解析の検出結果、技術的負債、AI 防御、来歴をレポートします。SCA は OSV に問い合わせることができ、検出結果のみの場合は終了コード 0 になります | CLI リファレンス |
| オプションの Python リンティング | pip install "skylos[lint]" && skylos lint . | Skylos CLI を通じて、Ruff をネイティブ設定、出力、修正、終了コードのまま実行します | Python リンティング |
| エージェントのブランチ完了チェック | skylos done --base origin/main | テストを実行し、削除、スキップ、または弱体化されたテスト、緩和されたテスト設定や CI のテストステップ、無効化されたチェック、テスト専用の特例を検出し、記録を作成します | 完了ゲート |
| PR ゲート | skylos cicd init --no-upload | プルリクエストをゲートし、テストを実行できる場合に skylos done を実行する GitHub Actions ワークフローを生成します。--no-upload を外すと、GitHub OIDC を使用してデフォルトブランチのスキャン結果も Skylos Cloud にアップロードします。このジョブは、リポジトリに Skylos GitHub App がインストールされるまで失敗します | 最初のゲート付き PR |
| GitLab マージリクエストレポート | skylos . --format gitlab -o gl-code-quality-report.json | GitLab CI アーティファクト用に、ネイティブの Code Quality レポートをエクスポートします | GitLab Code Quality |
| オフラインの依存関係 SBOM | skylos sbom . -o sbom.cdx.json | ネットワークリクエストを行わずに、対応する記録済み依存関係を CycloneDX 1.6 JSON として一覧表示します | 依存関係のスキャン |
| SPDX SBOM +ライセンスポリシー | skylos sbom . --format spdx-json / license_deny = ["GPL-*"] | 宣言済みライセンスを含む SPDX 2.3 JSON を生成します。-a スキャンでは、拒否対象のライセンスを SKY-SCA-LIC001 で検出します | ライセンスコンプライアンス |
| 署名付き判定によるデプロイゲート | skylos verify-verdict verdict.json --commit "$SHA" --repository github.com/org/repo --require-repository-verified --require-trusted-upload --max-age 7d --require-passed | Skylos Cloud のチェック判定(Ed25519 DSSE、in-toto/SLSA)をオフラインで検証し、対象のコミットとリポジトリに対する最近のポリシー合格判定でない場合は失敗します。skylos[verdict] が必要です | 署名付き判定の検証 |
| 読みやすいターミナルレポート | skylos . --format pretty | ファイルごとに検出結果をまとめ、重大度バッジ、コードスニペット、コピー可能な file:line 形式の位置を表示します | CLI の出力モード |
| 単一ルールのレビュー | skylos . --select SKY-L012 --format concise | 該当するアナライザーファミリーを有効にし、完全なメッセージとともに指定したルールだけをレポートします | CLI の出力モード |
| 選択可能なターミナルトリアージ | skylos . --tui | キーボードで操作するカテゴリ一覧、検出結果一覧、詳細ペインを開きます | CLI の出力モード |
| IDE/テストスクリプト向けの出力 | skylos --format concise src/test.py | 省略されていない file:line RULE_ID message 形式の検出結果を出力し、検出結果がある場合はゼロ以外の終了コードで終了します | CLI リファレンス |
| ループ内での AI コード検証 | skylos verify . --file src/app.py --range 40:75 | 幻覚によるヘルパー、未完成のコード、古い参照、無効化された制御、API/依存関係の幻覚を限定的にレポートします。出力をリダイレクトする場合、または -o を指定する場合は JSON を使用します | AI 機能 |
| AI の幻覚に関するコントラクト | skylos contract init && skylos verify . | .skylos/ai-contract.yml を自動検出し、リポジトリ固有のシンボル、依存関係、API、ルートガード、テスト要件に照らして生成コードを検証します | AI 幻覚コントラクト |
| 変更行のレビュー | skylos . -a --diff origin/main | レガシーな負債ではなく、現在の作業に絞って検出結果を提示します。このリリースでは、--diff により制御の削除に関する検出結果(削除された認証デコレーターなどの SKY-L021)が除外される場合があります。それらを確認するには、--diff を付けずに skylos . -a --diff-base origin/main を実行してください | 品質ゲートのドキュメント |
| 既存スキャナーとの比較 | skylos compare . --against incumbent.sarif | Skylos を現在のスキャナーと並行して実行し、リビジョンを考慮したスコアカードを生成します。アクティブな重複、カテゴリごとの未加工の固有検出数、証拠に裏付けられた未使用シンボル内の対象検出を提示し、現在のゲートは置き換えません | スキャナー比較 |
| ランタイム支援によるデッドコードチェック | skylos . --trace | ランタイムトレースを使用して、動的コードに関する誤検出を減らします | スマートトレーシング |
| ローカルルールパック | skylos rules init | プロジェクト固有のセキュリティおよび品質チェック用の YAML ルールをひな形として作成します | カスタムルール |
| セキュリティエージェントのクイックスキャン | skylos agent security-quick . | 1 回限りの LLM セキュリティ監査です。skylos agent scan . --security の互換エイリアスです | AI 機能 |
| セキュリティエージェントの詳細スキャン | skylos agent security-deep . | 脅威モデルのコンテキスト、静的な脅威トレース、検出/検証、修正への引き継ぎを含む 3 段階のセキュリティワークフローです | AI 機能 |
| AI 支援レビュー | skylos agent scan . | 静的解析に、オプションの LLM レビューと修正案を組み合わせます | AI 機能 |
| エージェントハーネスのリプレイ | skylos agent replay .skylos/runs/<run-id> | 保存済みのエージェント検証フェーズ、ツール呼び出し、判断、予算を検証し、要約します | エージェントハーネスのアーティファクト |
| ランタイムエージェント動作テスト | skylos agent init && skylos agent test --allow-contract-endpoint | バージョン管理されたコントラクトに照らして、最終応答、ツールの選択、明示的な拒否、ソース ID をチェックします | エージェント動作テスト |
| 検証に裏付けられた修正 | skylos agent remediate . | 対応する検出結果をスキャンして修正した後、それらを再スキャンし、利用可能な場合は証明テストのメタデータを記録します | AI 機能 |
| エージェントループフック | skylos agent install-hooks [--codex|--cursor] | すべてのエージェント編集を検証し、シークレットの読み取りと幻覚によるパッケージのインストールをブロックし、新たな問題が残っている間は「完了」と判定されないようにします | エージェントループフック |
| エージェント向けプロジェクト標準 | skylos agent install-standards --enforce SKY-L002 | Codex、Claude Code、Cursor にプロジェクトスキルを提供し、フックと CI のチェックに使用する測定可能な品質ルールを選択します | プロジェクト標準 |
| MCP エージェント検証 | verify_change MCP tool | Claude、Cursor、その他の MCP クライアントが、skylos verify と同じスキーマで編集済みのファイル/範囲を検証できるようにします。無料の Skylos API キー(SKYLOS_API_KEY)が必要です。skylos verify とエージェントループフックにはキーは不要です | MCP サーバー |
| LLM 統合インベントリ | skylos discover . | Python および TypeScript/JavaScript 内の、認識された LLM 呼び出し、エージェントツール、プロンプト箇所、入力ソースをマッピングします | エージェント検証 |
| デプロイ前のエージェント検証 | skylos defend . --format md -o evidence.md | エージェントのガードレールを検証し、OWASP LLM/Agentic のカバレッジをスコア化し、証明付きのエビデンスレポートを出力します | エージェント検証 |
| エージェント検証 CI ゲート | skylos defend . --fail-on critical | ガードされていない LLM 統合を含むデプロイをブロックします。--format sarif を指定すると、コードスキャン用に SARIF を出力します | エージェント検証 |
| MCP エージェントの事前チェック | verify_agent MCP tool | コーディングエージェントが構築したエージェントを静的に検証できるようにします。スコア、失敗したチェック、証明ダイジェストを提示します。無料の Skylos API キー(SKYLOS_API_KEY)が必要です。skylos defend にキーは不要です | MCP サーバー |
| 技術的負債のトリアージ | skylos debt . | ホットスポットと負債の傾向を順位付けします | 技術的負債 |
Skylos が検出するもの
| カテゴリ | 例 | 重要な理由 |
|---|---|---|
| デッドコード | 未使用の関数、クラス、インポート、パッケージのエントリーポイント、ルートハンドラー | 動的なフレームワークを壊さずに、メンテナンスコストを削減します |
| セキュリティ上の欠陥 | SQL インジェクション、XSS、SSRF、パストラバーサル、コマンドインジェクション、安全でないデシリアライゼーション | コードが main に到達する前に、悪用可能なフローを検出します |
| シークレット | API キー、トークン、秘密の認証情報、高エントロピー文字列 | コミットや PR による認証情報の漏えいを防ぎます |
| CI/CD ワークフロー | GitHub Actions と GitLab CI の危険なトリガー、固定されていないアクション/インクルード、過剰な権限を持つトークン、OIDC の誤用、キャッシュポイズニング、変更可能なイメージ | リリースジョブの実行前に、CI/CD のサプライチェーンリスクを低減します |
| エッジデプロイ設定 | Docker Compose の特権デバイスアクセス、ホストネットワーク、systemd の root サービス、過剰な権限、サンドボックス化の欠如 | リポジトリで制御される設定がアプリの不具合をデバイスの侵害につなげることを検出します |
| Kubernetes デプロイの公開 | 機密性の高い FastAPI/Flask ルートに到達する、明示的に外部公開された Ingress パスで、デプロイ時に必要なガードがない場合、Flask の --debug、または --reload を使用するアプリケーションサーバー | すべてのリソースがひとつのレンダリング済みバンドルに含まれ、デプロイ経路をすべて明確に解決できる場合にのみ報告します |
| GPU リリース互換性 | ソース/ビルド契約の不一致に加え、ビルド済みアーティファクトの識別情報、選択された CUDA アーキテクチャ、パッケージ化されたランタイム、フリートチェック | 宣言された意図の誤りを早期に検出し、リリース前に生成されたローカルアーティファクトを検証します |
| 品質の劣化 | 複雑度、深いネスト、重複した分岐、長い関数、一貫性のない戻り値 | AI を活用したリファクタリングによって脆弱なコードが追加されるのを防ぎます |
| AI コードの誤り | 実在しないセキュリティ関数の呼び出し、デコレーターの不足、未完成のスタブ、無効化された制御、実在するパッケージに対する架空の API の呼び出し、存在し得ない npm/Go のバージョン | よくある幻覚や未完成のコードパスがレビューに回る前に検出します |
| LLM アプリのリスク | 安全でないツールの使用、プロンプトインジェクションへの露出、出力検証の欠如、レート制限の欠如 | チームがガードレールを備えた AI 機能をリリースできるよう支援します |
全項目については、ルールリファレンスを参照してください。
依存関係のライセンス
skylos sbom . は宣言された依存関係のライセンスを CycloneDX に書き込み、
skylos sbom . --format spdx-json は SPDX 2.3 SBOM を書き込みます。ライセンス情報は
ロックファイルとインストール済みパッケージのメタデータからオフラインで取得されます。BSD などの不明または曖昧な値は
推測されず、NOASSERTION のままになります。--license-lookup を指定すると、
deps.dev へのクエリが有効になります。-a スキャンでライセンスをブロックするには、ポリシーを設定します。
[tool.skylos]
license_deny = ["GPL-*", "AGPL-3.0-only"]
license_severity = "HIGH"
違反は SKY-SCA-LIC001 として報告されます。ライセンスコンプライアンスを参照してください。
コーディングエージェントにプロジェクトの標準を適用する
.skylos/standards.md を作成し、エージェントに従わせたいガイダンスを記述します。
# Coding standards
- Keep functions focused and handle exceptions explicitly.
- Add a focused test when changing behavior.
次に、プロジェクトスキルをインストールし、適用する Skylos の品質ルールを選択します。
skylos agent install-standards --enforce SKY-L002
skylos agent install-hooks --codex # use --cursor for Cursor, or omit for Claude Code
skylos agent check-standards . # run this project-wide check in CI
インストーラーは Codex、Cursor、Claude Code 用の SKILL.md ファイルを書き込みます。
エージェントスキルはガイダンスを提供し、フックとプロジェクト全体のチェックで、選択した組み込み品質ルールを適用します。
生成されるファイル、ルールの選択、カバレッジの制限については、プロジェクト標準を参照してください。
出荷前に AI エージェントを検証する
ランタイムのガードレールが WAF なら、Skylos は SAST です。skylos discover は、
Python と TypeScript/JavaScript をスキャンし、認識されている LLM 統合(プロバイダー
SDK、OpenAI Agents SDK、Claude Agent SDK、Google ADK などのエージェントフレームワーク、
MCP サーバーとそのツール、LLM API または OpenAI 互換ゲートウェイへの直接 HTTP 呼び出し、
さらにエージェントツール、プロンプトの配置場所、入力ソース)を検出します。skylos defend
は、検出された統合を囲むガードレールを、モデルを介さずローカルプロセス内で決定論的に
チェックします。デフォルトではエビデンスを出力し、しきい値フラグまたはポリシーでゲート
基準を指定した場合にのみ CI ゲートになります。
skylos discover . # inventory LLM integrations and agent tools
skylos defend . # score guardrails (13 weighted checks)
skylos defend . --format md -o evidence.md # auditor evidence report + attestation
skylos defend . --format sarif -o defend.sarif # GitHub code scanning upload
skylos defend . --fail-on critical # CI gate: exit 1 on critical gaps
skylos defend . --owasp-framework agentic # report against OWASP Agentic ASI Top 10
これらのコマンドは、他の言語の統合を検査しません。検出でサポート対象の統合が見つからない
場合、defend は空のインベントリを返します。結果のスコアだけを根拠に、サポート対象外または
認識されていないエージェント実装にガードレールがあると判断しないでください。
統合ごとに、危険な出力先(eval/exec/subprocess)、エージェントツールのスコープと型付き スキーマ、プロンプトインジェクションへの露出(区切り文字、信頼できない入力経路、RAG コンテキストの分離)、出力検証、PII フィルタリング、モデルの固定を検証します。さらに、 運用チェック(ログ記録、コスト制御、レート制限)を別途スコア化するため、セキュリティ スコアが不当に上がることはありません。
- OWASP マッピング: LLM Top 10(2024/2025)および Agentic ASI Top 10(2026)。
- エビデンスレポート(
--format md): 統合インベントリ、チェックごとの結果、OWASP カバレッジ、規制フレームワークのエビデンス(EU AI Act、NIST AI RMF、ISO/IEC 42001 —「エビデンスに向けた」マッピングであり、コンプライアンスを主張するものではありません)、 および修正に関する付録。 - 証明: JSON/md/SARIF レポートには、ファイル内容、ポリシー、プラグインセット、統合インベントリ、 スコア、およびすべてのチェックエビデンスを対象とした、再現可能な SHA-256 ダイジェストが含まれます。 同じツリーに対して同じフラグと Skylos のバージョンで再実行すると、ダイジェストは一致します。
- CI ネイティブ:
skylos cicd init --defendはワークフローのステップを生成し、skylos-defendの pre-commit フックはローカルでゲートを適用します。また、Actions では$GITHUB_STEP_SUMMARYにスコアの概要が自動的に追加されます。 - コードとしてのポリシー:
skylos-defend.yamlでゲートのしきい値と重大度の上書きを固定します (--policy)。 - エージェントネイティブ:
verify_agentMCP ツールを使うと、コーディングエージェントは 自身が構築するエージェントを検証できます。これは決定論的な検証であり、AI による AI のチェックではありません。
デプロイ前の静的検証は、ランタイム制御(ゲートウェイ、ポリシーエンジン、人による承認フロー)を 補完するものであり、置き換えるものではありません。詳しいガイド: docs/agent-verification.md。
エージェントの動作をテストする
Skylos は、生成コードの正しさ、静的なエージェントのガードレール、観測されたランタイムの動作を それぞれ分けて扱います。
| コマンド | 検証する内容 |
|---|---|
skylos verify | エージェントは有効で、幻覚に基づかないコードを生成しましたか? |
skylos defend | エージェントの実装には必要なガードレールが含まれていますか? |
skylos agent test | 実行中のエージェントは契約に従って動作しましたか? |
.skylos/agent-test.yml を作成してから、稼働中の OpenAI 互換エンドポイントをテストします。
skylos agent init
skylos agent test --allow-contract-endpoint
または、ネットワーク呼び出しを行わずに、記録済みのエビデンスを評価します。
skylos agent test --observations agent-observations.json
skylos agent test --observations agent-observations.json \
--format json --output agent-results.json
バージョン 1 では、応答内の完全一致する部分文字列、必須・許可・禁止されたツール呼び出し、
ツール引数と呼び出し順序、呼び出しの最大回数、明示的な拒否、明示的なソース ID を決定論的に
チェックします。型付きエビデンスが欠落している場合は、pass ではなく incomplete になります。
終了コードは、0 が合格、1 が違反、2 が未完了/無効です。ツール選択と最終回答のソース ID
チェックは、個別の1ターンシナリオです。Skylos はローカルで再生可能なエビデンスを記録しますが、
対象エージェントから返されたツールを実行することはありません。オフラインの観測結果は、ランタイムの
証明ではなく、未検証のフィクスチャとして記録されます。
認証が必要なリモートエンドポイントでは、送信先とシークレットの選択を、信頼できる CLI 呼び出し内に 保持してください。
skylos agent test --endpoint https://agent.example.com/v1/chat/completions \
--allow-remote --auth-env MY_AGENT_API_KEY
詳しいガイド:docs/agent-behavior-testing.md。
Skylos の役割
Skylos は、あらゆる専用スキャナーを置き換えるものではありません。ローカルファーストのリポジトリおよび PR チェッカーとして、一般的なレビュー項目を 1 つの CLI にまとめます。
- フレームワークを考慮したデッドコード検出: FastAPI、Django、Flask、pytest、 SQLAlchemy、Next.js(App/Pages Router のファイルとメタデータルート)、React、 Laravel(自動検出されたコマンド、リスナー、コンポーネント、ファクトリー、シーダー)、 ツール設定ファイル、パッケージのエントリーポイント、一般的なプラグインパターン。
- PR に特化した出力: 差分スキャン、CI のしきい値、GitHub アノテーション、既存の検出結果に対するベースライン。
- ローカルファーストの動作: コア分析はローカルで実行され、ソースをアップロードしたり LLM を呼び出したりしません。依存関係/CVE チェックでは OSV またはパッケージレジストリに問い合わせることがあり、コンテナーを直接スキャンする場合は Trivy を介してレジストリに接続します。
- AI による変更レビュー: 生成または編集されたコードについて、削除された検証、認証、ロギング、CSRF、レート制限、タイムアウト、実在するパッケージの API に関する幻覚、その他のガードレールをチェックします。
- エージェントループ検証:
skylos verifyと MCPverify_changeは、AI コードの信頼性、セキュリティ、シークレットの検出にバージョン管理された結果スキーマを使用するため、コーディングエージェントは人間が変更を確認する前に自己修正できます。CLI はターミナルでは人間向けのレポートを表示し、リダイレクト時または-oで書き出す場合は JSON を出力します。 - 根拠に基づく AI の欠陥検出:
--ai-defectsとフルスキャンでは、AI コードの厳格な失敗チェックをai_defectsの下に分類します。これには、実在しない参照、偽のパッケージ API、存在しないパッケージ、実現不可能な依存関係のバージョン、弱められたテストアサーションが含まれます。 カテゴリー/タグはai_defectです。抑制とベースラインとの互換性を保つため、いくつかのルールでは従来のSKY-LまたはSKY-DID を意図的に維持しています。一方、新しい AI 欠陥専用チェックではSKY-Aを使用します。 - 検証に裏付けられた修正: セキュリティ修正は分析を再実行して検証され、対応する検出結果には対象を絞った回帰テストの証明メタデータを含められます。
- プロジェクト固有のルール: ローカル YAML ルールを追加し、設定からプロンプト、認証情報、機密ファイル、タイムアウトの辞書を拡張できます。
- 一貫したコマンド体系: デッドコード、セキュリティ、シークレット、依存関係、品質、技術的負債、エージェントレビュー、デプロイ前のエージェント検証の各コマンドは、同じ CLI を使用します。
エージェントハーネスの成果物
skylos agent verify . と skylos agent test は、再生可能な成果物を
.skylos/runs/<run-id> の下に記録し、テーブル形式の出力に実行ディレクトリを表示します。JSON
出力には、同じハーネスの概要が harness キーの下に含まれます。
skylos agent replay .skylos/runs/<run-id> を使用すると、LLM を呼び出さずに保存済みの実行を検証し、内容を確認できます。別のエージェントや CI ジョブで機械可読なステータスが必要な場合は、--format json を追加します。有効な再生は終了コード 0 を返し、無効または破損した成果物セットは、問題コードとともに終了コード 1 を返します。再生出力には schema_version が含まれるため、CI やエージェントは成果物の契約に変更があったことを検出できます。
再生では内部整合性と破損をチェックします。成果物には署名が付与されておらず、実行ディレクトリ全体を書き換えられる攻撃者への対策を証明するものではありません。
各実行ディレクトリには、次のファイルが含まれます。
events.jsonl:実行、フェーズ、ツール呼び出しのイベントを時系列順に記録します。state.json:フェーズ、ツール呼び出し、判断、予算の使用状況を含む、観測可能な状態全体を記録します。summary.json:ステータス、件数、予算、成果物のパスを簡潔にまとめます。behavior-results.json:skylos agent testの実行について、正規化されたランタイムアサーション、来歴、カバレッジ、ダイジェストに紐付けられた根拠レポートを記録します。
現在のハーネス状態は観測可能であり、再生によって検証されます。ただし、中断された検証の実行を続行するための再開機能ではありません。
インストール方法
# Core static analysis
pip install skylos
# LLM-powered agent workflows
pip install "skylos[llm]"
# Ruff Python linting through `skylos lint`
pip install "skylos[lint]"
# Ed25519 verification for `skylos verify-verdict`
pip install "skylos[verdict]"
# Dart analysis, 4.47.2 and later (builds the Dart parser from source; needs a C compiler)
pip install "skylos[dart]"
# All published optional extras
pip install "skylos[all]"
コンテナイメージ:
docker pull ghcr.io/duriantaco/skylos:latest
docker run --rm -v "$PWD":/work -w /work ghcr.io/duriantaco/skylos:latest . --json --no-provenance
タグを指定しないイメージは Python 3.14 を使用します。Python 3.11 から 3.14 まで、ランタイムごとのタグも公開されているため、コンテナスキャンでローカル環境または CI のパーサーと正確に一致させることができます。
docker run --rm -v "$PWD":/work -w /work ghcr.io/duriantaco/skylos:latest-python3.13 . --json --no-provenance
Python ファイルを解析できない場合、Skylos は analysis_errors を報告し、カバレッジを不完全としてマークします。また、スキップしたファイルを問題なしとして扱うのではなく、コード 2 で終了します。完了したチェックの検出結果は引き続き利用できます。
ソースからのインストール、コンテナの使用方法、オプションの依存関係については、インストールを参照してください。
テンプレートと Vibe チェックを設定する
skylos init を実行して、これらのセクションを pyproject.toml に追加します。
[tool.skylos]
exclude = ["node_modules", "dist"]
[tool.skylos.templates]
# security = ".skylos/templates/security.md"
# quality = ".skylos/templates/quality.md"
# security_audit = ".skylos/templates/security_audit.md"
# review = ".skylos/templates/review.md"
[tool.skylos.vibe]
extra_phantom_names = ["verify_enterprise_auth"]
extra_phantom_decorators = ["tenant_admin_required"]
extra_credential_names = ["tenant_signing_secret"]
extra_network_timeout_calls = ["vendor_sdk.fetch"]
[tool.skylos.dead_code]
entrypoints = []
[[tool.skylos.dead_code.entrypoints]]
type = "method"
name = ["create", "pre_hook", "post_hook"]
parent = { name = "Main", base_classes = ["Application"] }
path = "src/**"
reason = "project framework lifecycle hook"
[tool.skylos.contribution]
collect_local_signals = false
contribute_public_corpus = false
structural_signatures_only = true
include_source = false
テンプレートファイルは Skylos の組み込みプロンプトを拡張します。JSON のみの出力契約や、信頼できないコードに関する安全ルールを置き換えるものではありません。Vibe 辞書の拡張機能を使うと、チーム固有の偽認証ヘルパー、プロジェクトの認証情報名、機密ファイル、タイムアウトの設定が必要なネットワーク呼び出しについて、Skylos に情報を追加できます。デッドコードのエントリーポイントを使うと、型、名前、パス、デコレーター、基底クラス、親クラスに関する正確なルールを指定し、独自フレームワークのクラス、ライフサイクルメソッド、デコレーターで登録された関数を使用中としてマークできます。
ルールには、name、decorators、base_classes、parent などのシンボルセレクターを含める必要があります。path と module は一致対象を絞り込む場合にのみ使用できます。
コントリビューションシグナルはデフォルトで無効です。有効にすると、Skylos は生のソースコードを含めず、構造化されたローカルの承認/却下/学習イベントを .skylos/contribution/ に記録します。
デフォルトでは、Skylos はスキャンパスから上の階層をたどり、pyproject.toml 内の [tool.skylos] を検出します。専用の TOML 設定ファイルを使うには、--config-file PATH を渡すか、SKYLOS_CONFIG_FILE を設定します。スタンドアロンのファイルでは、[tool.skylos] またはトップレベルの [skylos] のどちらも使用できます。同期された Skylos Cloud ポリシーは、リポジトリで管理される設定よりも優先されます。トップレベルの [tool.skylos].exclude リストはメインのスキャンと、skylos debt や skylos clean などのコマンドに適用されます。コマンド単位で追加の除外対象を指定するには --exclude を、除外されたフォルダーを対象に含めるには --include-folder を渡してください。
フルスキャンでは、生成ファイルとベンダー提供ファイル(Django のマイグレーション、static/**/lib/**、*.min.js、*.min.css、ベンダーライブラリのバナー)がスキップされ、その件数が出力の 1 行に表示されます。これらもスキャンするには、[tool.skylos] の下に include_generated = true を設定するか(または --include-generated を渡し)、フルスキャンで対象外となるものを参照してください。
言語サポート
| 言語 | デッドコード | セキュリティ | 品質 | ローカル API の証明(verify) | 備考 |
|---|---|---|---|---|---|
| Python | はい | はい | はい | 対応 | 最も充実したカバレッジ。フレームワークを考慮した静的解析と、オプションのトレース機能 |
| TypeScript / JavaScript | はい | はい | はい | 対応 | Tree-sitter による解析、パッケージグラフの到達可能性、フレームワークの規約 |
| Java | はい | はい | はい | 対応 | Tree-sitter による解析、構造化されたセキュリティフロー解析、保守的な静的メンバーの証明 |
| Go | はい¹ | 一部¹ | 一部 | 対応 | ネイティブエンジンのステータスは、決定論的なワークスペース API の証明とは別に扱われます |
| PHP | はい | はい | いいえ | 非対応 | PHP パーサーによるカバレッジ、型と docblock の参照、Laravel の規約に加え、taint 方式のセキュリティシンクとソース |
| Rust | はい | はい | いいえ | 非対応 | Rust パーサーによるカバレッジに加え、セキュリティシンク/ソースのチェック |
| Dart | はい³ | はい³ | いいえ | 非対応 | Dart パーサーによるカバレッジに加え、選択されたセキュリティシンクとソース |
| C# | 一部 | 一部 | 一部 | 一部 | C# シンボル、直接ブロック内の到達不能コード、選択されたセキュリティシンク、直接的な NuGet インベントリ |
| C++ | 一部 | いいえ | いいえ | 非対応 | .cpp、.cc、.cxx 内のファイルローカル関数を保守的に未使用と判定。C++ ヘッダーは参照解析のために解析されます |
| Kotlin | はい | いいえ² | いいえ | 非対応 | 保守的な静的解析カバレッジによる Kotlin シンボルの抽出 |
| Shell | いいえ | はい | いいえ | 非対応 | コマンドインジェクション、SSRF、パストラバーサルを対象としたシェルスクリプトのセキュリティチェック |
¹ Go のデッドコードチェックとセキュリティチェックには、別途ビルドされた skylos-go エンジンが必要です。これは PyPI パッケージには含まれていません(コンテナイメージには含まれており、公式の GitHub Action はこれをビルドします)。これがない場合、Go の品質チェックのみが実行され、スキャンは不完全であると報告されます。詳細は以下の Go エンジンに関する注記を参照してください。 |
² 組み込みの Kotlin セキュリティルールはありません。シークレットスキャンは引き続き .kt ファイルと .kts ファイルを対象とします。
³ 4.47.2 以降、Dart のチェックにはオプションの skylos[dart] エクストラが必要です(pip install "skylos[dart]")。それ以前のリリースでは Dart パーサーがデフォルトでインストールされます。このパーサーにはビルド済みホイールがないため、インストールには C コンパイラが必要です。これがない場合、.dart ファイルを含むスキャンは、それらを黙ってスキップする代わりに SKY-ANALYSIS-INCOMPLETE を報告し、終了コード 2 で終了します。skylos doctor は Dart サポートがインストールされているかどうかを表示します。
「いいえ」は、Skylos がその言語向けのその種の組み込みルールを持たないことを意味します。
C# のデッドコード検出結果は保守的です。完全な実行可能ファイルまたは Web アプリケーションのスキャンでは、参照されていないパブリック型とパブリックメソッドは低信頼度の候補となります。ライブラリ API、protected メンバー、および既知のフレームワークまたは設定済みのエントリポイントは、引き続き外部から到達可能です。C# のソースファイルの到達可能性は実装されていません。品質スキャンは、直接ブロック内の無条件の return、throw、break、または continue の後のステートメントを検出します。これは完全な制御フロー分析ではありません。セキュリティカバレッジには、選択されたテイントされた入力のシンクと、--secrets または -a が有効な場合の .cs ファイルの汎用シークレットスキャンが含まれます。補間された raw 文字列式は、C# のテイント分析ではまだ追跡されません。SCA は .csproj ファイル内の直接の NuGet PackageReference エントリをインベントリします。アドバイザリに対してチェックできるのは、ローカルの Update/Remove による変更がない、無条件の正確な Version ピン([version])のみであり、VersionOverride や一元管理されたバージョンは対象外です。通常の NuGet バージョン値は最小境界であるため、解決済みのロックファイルがない場合、そのインストール済みバージョンと脆弱性の状態は不明のままです。推移的なパッケージはインベントリされません。
Java のセキュリティ分析は、同一パッケージ内のファイル、または検証済みのローカルソースルート下で正確なインポートや完全修飾名によって識別されたソースファイル内で、直接実装されたリクエストデータヘルパーを追跡します。ヘルパーの読み取りは制限されており、シンボリックリンクを拒否します。Java コードやビルドスクリプトは実行されません。これは完全なクラスパス分析や再帰的なヘルパー分析ではありません。不明なヘルパーは、リクエストソースやサニタイザーであるとは見なされません。
C++ 分析は .cpp、.cc、.cxx、.hpp、.hh、.hxx を対象とします。最初のリリースでは、明らかに未使用のファイルローカルのフリー関数のみを報告します。ビルド設定がない場合、テンプレート、オーバーロード、マクロ、外部での使用を完全に解決することはできません。これらの検出結果は保守的なヒューリスティックであり、C++ のデッド性の証明ではありません。曖昧な .h ファイルと C ファイルは C++ として分析されません。
Java の弱いハッシュのチェックは、ローカルのアルゴリズム変数と、リテラルのクラスローダーリソースから java.util.Properties を通じて読み込まれた値も追跡します。リソースの検索は、一致する src/main/resources または src/test/resources ディレクトリ内にとどまります。存在しないリソース、サポートされていないローダー/レイアウト、競合する分岐値、および未解決の変更は不明のままです。Properties は暗号の証拠としてのみ使用され、セキュリティガードを証明したり安全な分岐を選択したりするために使用されることはありません。これは任意のランタイムクラスパス、JAR リソース、または環境によるオーバーライドを解決するものではありません。
TypeScript と JavaScript のデッドコード分析は、bin を含む package.json のエントリフィールドを認識します。dist/ または out/ 下のターゲットについては、宣言された出力の前に、まず一致する src/ の場所を確認し、次にパッケージルートを確認します。これは、dist/bin/palee.js が bin/palee.ts にマッピングされる場合や、dist/src/index.js が src/index.ts にマッピングされる場合も対象とします。両方のソースの場所が存在する場合、src/ のマッピングが優先されます。無関係なファイルはエントリとして扱われません。
package スクリプトから呼び出される ESM ビルドスクリプトについて、Skylos は変更されていない定数、スプレッド構文、テンプレート、Node のパスヘルパー、単純なリテラル配列のマップを使用するトップレベルの esbuild 呼び出しも追跡します。ビルドスクリプトが実行されることはありません。ネストされたビルド呼び出しやファイルシステムで生成されたエントリーリストは引き続きサポートされず、未使用ファイルの検出結果が出る場合があります。
.vitepress/config.* および .vitepress/config/index.* の VitePress 設定は、.js、.ts、.mjs、.mts の開発エントリーポイントとして認識されます。.vitepress 内のその他のファイルは、引き続き参照されるか、別のエントリーポイントルールに従う必要があります。scripts/ などの既存のディレクトリ規則は、ネイティブの Windows セパレーターでも機能しますが、CI ワークフロー内のコマンドを一般的に検出する機能が追加されるわけではありません。
Vue 単一ファイルコンポーネント(.vue)は、明示的に渡された場合も含め、ソース解析の対象外です。Skylos は現時点では、これらの <script> ブロックや <script setup> ブロックを解析しません。JavaScript、TypeScript、バックエンドのソースファイルは引き続き個別に解析されます。テンプレート内の既存のブラウザースクリプトおよびイベント参照には影響しません。
Go のデッドコードチェックとセキュリティチェックには、ネイティブの skylos-go エンジンが必要です。Skylos が Go ファイルを検出してもそのエンジンを実行できない場合、レポートは不完全とマークされ、クリーンな結果は生成されず、CLI はステータス 2 で終了します。skylos doctor を実行してエンジンを利用できることを確認してください。別途ビルドしたエンジンを使用する場合は、SKYLOS_GO_BIN を設定してください。公式 GitHub Action は、対応するネイティブエンジンを自動的にビルドします。
ルールファミリーとスキャナーの対象範囲については、ルールリファレンスを参照してください。
設定とデプロイのサポート
| 対象 | ファイル | セキュリティの対象範囲 |
|---|---|---|
| GitHub Actions | .github/workflows/*.yml、.github/workflows/*.yaml、action.yml、action.yaml | 危険なトリガー、トークン権限、バージョンが固定されていないアクション、テンプレートインジェクション、シークレット、OIDC、キャッシュ、アーティファクトのポリシー |
| GitLab CI | .gitlab-ci.yml | 変更可能なイメージ、バージョンが固定されていないインクルード、リテラルなシークレット、信頼できない eval、Docker-in-Docker、OIDC、キャッシュ、タイムアウト、ランナータグのポリシー |
| Dockerfile | Dockerfile、Dockerfile.*、*.dockerfile | 危険な RUN コマンド、チェックサムなしのリモート ADD、リテラルなビルド ARG/ENV シークレット |
| エッジ Docker Compose | compose*.yml、compose*.yaml、docker-compose*.yml、docker-compose*.yaml | 特権コンテナー、広範なホストデバイス/制御マウント、GPU/デバイスランタイム、ホストネットワーク |
| エッジ systemd | *.service | root で実行されるエッジサービス、変更可能な ExecStart パス、サンドボックス設定の欠落、広範なケイパビリティ、広範なデバイスアクセス |
| レンダリング済み Kubernetes の公開設定 | 1 つの複数ドキュメント *.yml または *.yaml バンドルと、契約に従った Python ソースファイル | Ingress のアノテーション skylos.dev/network-scope: external(または public)および skylos.dev/backend-protocol: http から、その Service とワークロードまでのオプトイン証明。SKY-DEP001 は、トップレベルに直接定義された FastAPI/Flask ルートを skylos.dev/source-file および skylos.dev/required-guards と照合し、SKY-DEP002 は有効な Flask デバッガーを検出し、SKY-DEP003 は有効なリロードモードを検出します |
| GPU リリース契約 | .skylos/gpu-targets.yml、Dockerfiles、CMake/CUDA ビルドファイル、TensorRT ソース | ドライバー、コンピュートアーキテクチャ、シリアライズ済みエンジンの互換性に関する静的なターゲットフリートチェック。ハードウェアのプローブは行いません |
--danger または -a を指定すると、Git ワークツリー内のディレクトリスキャンでは、そのワークツリーのルートにある .github/workflows/*.yml/*.yaml と .gitlab-ci.yml もチェックされます。たとえば、skylos src --danger は src に適用される CI 設定をチェックしつつ、ソース、コンテナー、デプロイの解析は src 内に限定します。ステージ済みまたは未ステージの無関係な編集によって、全体スキャンの対象範囲が狭まることはありません。明示的な差分フィルターでは、変更された設定ファイルが引き続き選択されます。単一ファイルのスキャンは、そのファイルだけが対象です。スキャンの対象範囲を参照してください。
その他のワークフロー
これらのワークフローでは、コンテナイメージ、Kubernetes のデプロイ公開、および GPU リリース成果物に関する、より限定的なタスクを扱います。
| 目標 | コマンド | 得られるもの | 詳細 |
|---|---|---|---|
| コンテナイメージのスキャン | skylos image scan IMAGE@sha256:<digest> --platform linux/amd64 --fail-on high | 別途インストールした Trivy、レジストリへのネットワーク接続と認証、および固定されたリモートイメージに対する明示的な重大度ゲートを使用します | コンテナイメージのスキャン |
| コンテナイメージレポートのインポート | skylos ingest trivy --input trivy.json --sarif image.sarif | 既存の Trivy イメージ脆弱性レポートを Skylos JSON/SARIF に変換します。ダイジェストに紐付いた重大度チェックも任意で実行できます | コンテナイメージのスキャン |
| Kubernetes の公開状態の証明 | skylos . --select SKY-DEP001,SKY-DEP002,SKY-DEP003 --format concise | 明示的に外部公開され、明示的に平文 HTTP を使用する Ingress チェーンを、レンダリング済みの単一の複数ドキュメントバンドル内でチェックします。ルートチェックでは、フレームワークの正確な配線と、ワークロードで宣言されたソースファイルおよび必須ガードを照合します | デプロイ公開ルール |
| GPU のソース/ビルド意図ゲート | skylos . --select SKY-GPU000,SKY-GPU001,SKY-GPU002,SKY-GPU003 --gate --format concise | 成果物のビルド前に、宣言された CUDA イメージ、アーキテクチャ、ドライバー、TensorRT のパッケージ化意図をチェックします | GPU ターゲット契約 |
| ビルド済み GPU 成果物の事前チェック | skylos preflight build/app | 正確なローカル成果物の識別情報、選択された CUDA アーキテクチャ、パッケージ化されたランタイムルート、および宣言されたフリート互換性を検証し、PASS、FAIL、または UNKNOWN を返します | リリースの信頼性 |
特定の GPU リリース成果物を確認する
skylos preflight は、ビルド済みの成果物自体を、リポジトリで宣言された GPU フリートと照合します。これは、成果物がまだ存在しない段階で Dockerfile、CUDA ビルド設定、TensorRT のパッケージング方針を確認する SKY-GPU* ソーススキャンとは別のものです。
同じリリースを受け取るすべてのマシンを宣言します。
# .skylos/gpu-targets.yml
version: 1
targets:
- name: inference-t4
vendor: nvidia
driver: "535.104.05"
compute_capability: "7.5"
platform: "linux/amd64"
標準のファイル名は .skylos/gpu-targets.yml です。同じスキーマは .skylos/gpu-targets.yaml としても使用できます。
次に、ローカルビルドを検査します。Skylos は信頼できるシステムの cuobjdump を使用し、プライベートなスナップショットを作成します。成果物を読み込んだり実行したりすることはありません。
skylos preflight build/app
CI でコマンドに引数を渡さずに済むようにするには、厳格なリリースレシートを使って、プロジェクト相対の成果物に紐付けます。
{"version": 1, "artifact": "build/app"}
そのファイルを .skylos/release.json として保存し、skylos preflight を実行します。レポート生成まで進んだリクエストでは、ターミナル出力は簡潔になり、リダイレクトされた出力はスキーマバージョン付きの JSON になります。引数またはアダプターのエラーはプレーンテキストで表示され、終了コードは 2 になる場合があります。
| ステータス | 終了コード | 意味 |
|---|---|---|
PASS | 0 | 宣言されたすべてのターゲットが、明示された静的な証拠の範囲内で互換性を持ち、特定の成果物の識別情報が検証されています |
FAIL | 1 | 成果物の証拠により、宣言されたターゲットの少なくとも 1 つに互換性がないことが確認されています |
UNKNOWN | 2 | 必要な証拠が欠落している、曖昧である、未対応である、または不完全です。暗黙に合格となることはありません |
cuobjdump は、選択された実行可能 fatbin 内の生成元ラベルによって識別される、複数のコードオブジェクトグループを報告する場合があります。Skylos は、報告されたすべてのグループに互換性のある経路を要求します。静的検査では、デプロイ先のドライバーが正常に JIT コンパイルできることを証明できないため、PTX のみの経路は UNKNOWN のままです。いずれかのターゲットまたは必須チェックが失敗した場合、全体の結果は FAIL になります。それ以外で、いずれかの結果が不明な場合は UNKNOWN になり、すべての結果が合格した場合にのみ PASS になります。
バージョン 1 では、ローカル成果物の識別情報、Linux ELF プラットフォーム、選択された実行可能 fatbin のアーキテクチャ経路、パッケージ内の静的な $ORIGIN CUDA ランタイム経路、および文書化された CUDA ドライバーファミリーとの互換性を証明します。ランタイム実行、ワークロードの正確性、メモリ需要、パフォーマンス、選択されていない fatbin または再配置可能な fatbin、カーネルごとのシンボル同等性は証明しません。Windows PE のランタイムインポートの証明には対応していません。ダイジェストで固定された OCI リファレンスは識別情報として受け入れられますが、プルも起動もされないため、CLI は常に UNKNOWN を報告します。信頼できる呼び出し元は、skylos.preflight.run_preflight(...) を通じてダイジェストに紐付いた検査情報を渡すことができます。
ベンチマークの概要
Skylos には、デッドコード、セキュリティ、品質、エージェントレビュー、AI コードの欠陥に関する回帰テストスイートが含まれています。これらは回帰を防ぐためのゲートであり、独立したベンチマークではありません。テストケースは私たちが作成したものなので、スコアを精度として公表していません。スイートの拡充に伴ってケース数は変わります。現在のマニフェストが最新の情報源です。
| スイート | ケース | 実行方法 |
|---|---|---|
| デッドコード | benchmarks/dead_code/manifest.json | python scripts/dead_code_benchmark.py |
| セキュリティ | benchmarks/security/manifest.json | python scripts/security_benchmark.py |
| 品質 | benchmarks/quality/manifest.json | python scripts/quality_benchmark.py。すべてのプルリクエストで CI でも実行されます |
| エージェントレビュー | benchmarks/agent_review/manifest.json | python scripts/agent_review_benchmark.py(LLM API キーが必要です) |
| AI コードの欠陥 | benchmarks/ai_code_defects/manifest.json | python scripts/ai_code_defect_benchmark.py |
手法、日付付きの結果、競合製品のベースライン、注意事項については、凍結された golden-v0.2 スイートも含め、BENCHMARK.md をご覧ください。
完了ゲートベンチマークでは、公開済みのエージェント実行を再生し、ゲートが見逃したものを報告します。
実験的な Jev ランナーでは、ピン留めされた jev-1.13.0 型付き判定モデルを、チェックイン済みのデッドコードラベルまたは凍結された skylos-benchmarks コーパスに対して、事前情報なしでスコアリングできます。リクエストからラベルとレビュー理由を除外し、分類器を正確に比較できるよう、正解ラベル ID はローカルに保持します。また、フィクスチャの意味を変えずに可能な場合は、回答を示唆する識別子を無効化してテストを繰り返します。オフライン比較ツールでは、凍結された Skylos の結果と照らし合わせ、ラベルごとの修正、後退、判定保留、安全でない削除を報告します。ライブモードではフィクスチャのソースを TypeSafe に送信します。このモードには明示的なフラグと、別途 TYPESAFE_API_KEY が必要です。実行数を制限した再開可能な実行に対応し、リクエストとローカルの契約検証それぞれのレイテンシーを記録します。通常の Skylos スキャンに Jev キーは必要ありません。これまでの有料 Jev 実行は、合成スイートを対象とした小規模な開発用実行であり、独立したホールドアウトではありません。また、一部のスイートでは Jev による分類の改善はありませんでした。
デッドコードベンチマークガイドと同一実行での比較では、注意事項とともにこれらの結果を報告しています。
デッドコードレビューはオプトインです。通常の skylos . スキャンはローカルで実行され、モデルを使用しません。skylos agent verify . はデフォルトで LLM ベリファイアを使用します。Jev を使う場合は明示的に選択してください。
skylos agent verify . --format json # LLM only
skylos agent verify . --dead-code-review jev --format json # Jev only
skylos agent verify . --dead-code-review jev-llm --format json # Jev, then LLM if uncertain
Jev のみを使う場合に必要なのは TYPESAFE_API_KEY であり、LLM キーは不要です。確信度の高い Jev の「未使用」という判定では静的検出結果を維持し、確信度の高い「使用中」という判定ではその検出結果を抑制します。判定が不確実な場合や Jev を利用できない場合は、検出結果を未検証として表示したままにします。Jev と LLM を併用する場合は、設定済みの LLM プロバイダーも必要となり、不確実な判定は LLM に送られます。Jev だけで --fix が許可されることはありません。TYPESAFE_API_KEY を設定せずにいずれかの Jev モードを選択すると、Skylos はレビュー方式を黙って切り替えるのではなく、セットアップ手順を表示して停止します。公式の TypeSafe コンソールにサインインしてキーを取得し(アクセスには招待が必要な場合があります)、環境に TYPESAFE_API_KEY を設定してください。ソース管理やコマンドライン引数にキーを含めないでください。
Jev は、上限サイズが設定されたプロジェクトのソーススナップショット(現時点では最大 64 KB)を TypeSafe に送信します。埋め込みシークレットがないことを確認し、共有が許可されていることを確かめてください。ローカルのファイルガードはシークレットスキャナーではありません。サイズ超過または安全でないスナップショットは Jev で判定できません。以前の --jev-judge と --jev-precheck フラグも互換性のために引き続き利用できます。新しいワークフローでは --dead-code-review を使用してください。キーの設定、フォールバック動作、制限事項については、デッドコードレビューガイドをご覧ください。
実プロジェクトでの回帰テスト
liveness_primer は、Matthew Digman が作成し、メンテナンスしている Skylos 公式の実プロジェクト向け回帰テストツールです。各 PR で、同じ固定された Python プロジェクトに対してベースとマージ提案の結果を比較し、追加、削除、または変更された検出結果を報告します。
比較結果とダウンロード可能なレポートは、Analyzer Blast Radius チェックをご覧ください。これらの結果は、上記のラベル付きベンチマークを補完するものです。検出数の変化だけでは、精度を証明できません。対象範囲、レビュー手順、再現コマンドについては、liveness_primer ガイドをご覧ください。
プロジェクトでの実績
Skylos を活用したデッドコードのクリーンアップ PR 10 件が、Black、NetworkX、Optuna、mitmproxy、pypdf、pdm など、9 つのオープンソースプロジェクトのデフォルトブランチにマージされました。記録したその他の PR 16 件のうち、1 件はメンテナーのステージングブランチにマージされましたが、main には到達せず(Flagsmith)、1 件はデッドコードではなく品質修正としてマージされ、1 件はマージ後に取り消され、4 件はメンテナーによってクローズされ、7 件は当方でクローズし、2 件は現在もオープンです。これらは受け入れられたクリーンアップ PR であり、推奨や採用を示すものではありません。
候補は Skylos の静的解析から得られ、多くの場合、LLM ベースの skylos agent verify でトリアージしたうえで、各 PR の前に手作業で確認しました。実環境での結果には、記録されたクリーンアップおよび品質修正 PR 26 件と、その結果およびメンテナーが示した理由を記載しています。
インテグレーション
| インテグレーション | リンク | 目的 |
|---|---|---|
| GitHub Action | GitHub Action | リポジトリの PR ゲート、または任意のダイジェスト固定コンテナイメージゲート |
| GitLab Code Quality | GitLab のセットアップ | マージリクエストのレポート成果物。コメント投稿ボットや API トークンは不要 |
| Bitbucket Pipelines / Azure Pipelines | パイプラインのセットアップ | Skylos Cloud チェック用のプルリクエストコンテキストを検出します。--diff は PR のターゲットブランチを使用します |
| VS Code extension | VS Code 拡張機能 | エディター内での検出結果と AI 支援による修正 |
| Claude Code / Codex / Cursor hooks | エージェントループフック | エージェントによる編集、ファイルの読み取り、パッケージのインストールをローカルで都度チェックします |
| MCP server | MCP のセットアップ | Skylos のスキャンを AI エージェントやコーディングアシスタントに公開します。analyze はキーなしで利用できます(24 時間のローリング期間あたり 5 回)。その他のツールには無料の Skylos API キーが必要です。認証済みスキャンではクレジットを利用できます |
| Ruff | Python のリンティング | skylos lint を通じた任意の Python リンティング |
| Docker image | インストール | ローカルに Python をインストールせずに Skylos を実行します |
| Skylos Cloud | クラウドワークフロー | 任意のアップロードおよびダッシュボードのワークフロー |
CLI から GitHub Actions ワークフローを生成します。
skylos cicd init --no-upload # without Skylos Cloud
skylos cicd init --no-upload --scan-path apps/api # a monorepo subproject
skylos cicd init # with Skylos Cloud uploads
生成されたワークフローは、プルリクエストの変更行をレビューし、テストが見つかった場合は
skylos done ジョブを追加します。--no-upload を指定しない場合、GitHub OIDC を使用して
デフォルトブランチへのプッシュから完全なスキャン結果もアップロードします。このアップロード
ジョブは、リポジトリに Skylos GitHub App がインストールされるまで失敗します。
--scan-path によるモノレポのサブプロジェクトにも対応しています。Skylos でゲートされた最初のプルリクエストを参照してください。
コンポジット Action でビルド済みイメージをスキャンするには、呼び出し元のジョブで固定された Trivy バージョンをインストールし、
image に信頼できる repository@sha256:<digest> 形式のビルド出力と image-platform を設定します。これはイメージのみをスキャンします。mode: gate は image-fail-on(デフォルトは high)を使用し、mode: scan は検出結果を報告するだけです。
コンテナイメージのスキャンを参照してください。
ドキュメント一覧
| 必要な情報 | こちらをお読みください |
|---|---|
| インストール方法、ソースからのインストール、Docker | インストール |
| 最初のスキャンと主要なワークフロー | クイックスタート |
| CLI コマンド、フラグ、使用例 | CLI リファレンス |
| CLI の出力モード、見やすいレポート、TUI の操作 | CLI 出力モード |
| Skylos CLI によるオプションの Ruff リンティング | Python のリンティング |
| CI の設定、PR ゲート、注釈、ブランチ保護 | CI/CD |
| GitLab のマージリクエストレポートと CI の例 | GitLab Code Quality |
| Bitbucket Pipelines と Azure Pipelines のプルリクエストチェック | Bitbucket と Azure Pipelines |
| デッドコードの挙動とフレームワークの認識 | デッドコード検出 |
| セキュリティスキャンと汚染解析 | セキュリティ分析 |
| 依存関係の CVE、uv/npm/pnpm/Poetry/Yarn のロックファイル、オフライン SBOM、CI での SCA | 依存関係のスキャン |
| 依存関係のライセンス、SPDX 2.3 SBOM、ライセンスの拒否/許可ポリシー | ライセンスコンプライアンス |
| ダイジェスト固定されたコンテナイメージのスキャンと GitHub Action の設定 | コンテナイメージのスキャン |
| ソース GPU コントラクトとビルド成果物のプリフライト | リリースの信頼性 |
| ルール ID の接頭辞と製品用語 | ルール辞書 |
| エージェントによるスキャン、検証、修正、モデルの設定 | AI 機能 |
| AI 防御チェックと LLM ガードレール | AI 防御 |
| Claude Code、Codex、Cursor のフック | エージェントループのフック |
エージェントによる変更の完了ゲート(skylos done) | 完了ゲート |
| GitHub Actions を使った最初のゲート付きプルリクエスト | 最初のゲート付き PR |
| MCP サーバーの設定 | MCP サーバー |
| Skylos を活用したすべてのクリーンアップ PR とその結果 | 実際の導入結果 |
| ベースライン、フィルタリング、抑制、ホワイトリスト | 設定 |
| スマートトレーシング | スマートトレーシング |
| ルールファミリーと言語のサポート | ルールリファレンス |
| クラウドへのアップロードとダッシュボードのワークフロー | CLI からダッシュボードへ |
| VS Code 拡張機能 | VS Code 拡張機能 |
| ベンチマークと方法論 | BENCHMARK.md |
| セキュリティポリシー | SECURITY.md |
| リリースプロセス | RELEASE_WORKFLOW.md |
| 貢献の優先事項 | ROADMAP.md |
| 貢献方法 | CONTRIBUTING.md |
よくある質問
Skylos は Bandit、Semgrep、CodeQL、または Vulture に取って代わりますか?
いいえ。Skylos はそれらと併用できます。フレームワークを考慮したデッドコードの検出、PR のゲート、AI 時代のリグレッションチェック、そしてデッドコード、セキュリティ、シークレット、品質、AI の欠陥チェックを組み合わせたワークフローに重点を置いています。
Skylos に LLM は必要ですか?
いいえ。コアの静的解析は API キーなしでローカル実行できます。LLM 機能は skylos[llm] とエージェントコマンドから任意で利用できます。
Skylos は無料ですか?
Skylos CLI は無料のオープンソース(Apache-2.0)です。Skylos Cloud には 1 プロジェクト向けの Free プランと Workspace プランがあり、使い切りのクレジットパックを 1 つ購入すると、シート数やサブスクリプションなしで Workspace を永続的に利用できます。
MCP サーバーにアカウントは必要ですか?
SKYLOS_API_KEY がない場合、MCP サーバーが公開するのは analyze のみです(デッドコード、24 時間のローリング期間あたり 5 回)。その他すべての MCP ツール(verify_change、verify_agent、security_scan、secrets_scan など)は、SKYLOS_API_KEY を設定してサーバーを起動するまで認証エラーを返します。Skylos Cloud のダッシュボード設定で無料のキーを作成してください。認証なしの analyze 呼び出しは無料です。認証済みの analyze、セキュリティ、品質、シークレット、プロベナンスのスキャンにはクレジットを使用する場合があります。現在の費用は Skylos Cloud で確認できます。remediate は現在、1 回の呼び出しにつき 10 クレジットかかります。CLI の同等コマンド(skylos verify、skylos defend、skylos . -a)と skylos agent install-hooks は、アカウントやキーなしで完全にローカル実行できます。
Skylos は Ruff に取って代わりますか?
いいえ。skylos lint は Ruff に処理を委ねる、任意で使える便利なエントリーポイントです。pip install "skylos[lint]" でインストールしてください。通常の Skylos スキャンは Ruff を実行せず、Ruff の違反を SKY-* の検出結果に統合することもありません。
変更したコードだけを対象にできますか?
はい。ローカルでは skylos . -a --diff origin/main を使うか、CI ゲートを設定して新たな検出結果に対象を絞ります。このリリースでは、削除された認証デコレーター(SKY-L021)など、削除されたセキュリティ制御に関する検出結果が --diff によって除外される場合があります。それらを確認するには、--diff を付けずに skylos . -a --diff-base origin/main を実行してください。
skylos done は、変更が完了したように見せかけるあらゆる方法を検出できますか?
いいえ。テスト関数(pytest、unittest、JavaScript/TypeScript)を比較するため、カスタムのテストランナースクリプトを書き換えたり、テストデータファイルからテストケースを削除したりしても検出されません。また、静的なアサーション数では把握できない方法でテストが弱められる場合もあります。done ゲートの制限事項とベンチマークを参照してください。
意図的な動的コードはどのように扱えばよいですか?
ベースライン、ホワイトリスト、インライン抑制、またはランタイムトレースを使用してください。設定ドキュメントとスマートトレースのドキュメントを参照してください。
コントリビューションとサポート
- セキュリティ上の問題は SECURITY.md から報告してください。
- バグや誤検知の報告は、最小限の再現手順を添えて投稿してください。
- コントリビューションに適した分野は ROADMAP.md で確認してください。
- プルリクエストを送る前に CONTRIBUTING.md をお読みください。
- プロジェクトの品質とゲートに関する要件は QUALITY.md を参照してください。
- コミュニティサポートは Discord にご参加ください。
ライセンス
Skylos は Apache License 2.0 の下でライセンスされています。
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。