Ship Safe：agent 時代の security check を local repository に戻す
AI coding tool が日常の開発に入り込むと、security check の境界も変わる。
以前なら SQL injection、XSS、hardcoded token、pin されていない GitHub Actions を見ていればよかった。今はもう一段ある。.mcp.json が untrusted server を auto-launch しないか。Claude/Cursor の rules file に prompt injection がないか。agent fix loop が広すぎる変更をしないか。RAG document、model weight、npm lifecycle script が新しい supply chain entry point になっていないか。
今日メモしておきたい asamassekou10/ship-safe は、この「traditional security + agent security + AI supply chain」を local CLI にまとめた project だ。SaaS-only scanner でも、ただの checklist でもない。repository の中で npx ship-safe を実行し、findings、remediation、CI gate、SARIF を出せる。
2026-07-15 時点で GitHub repository API、repository page、README、Releases、Tags、commit history、LICENSE から確認できる公開情報では、asamassekou10/ship-safe は 763 stars、83 forks。主言語は JavaScript、license は MIT。repository 作成日は 2026-02-02 08:19:37 UTC、最近の public push は 2026-07-15 08:52:07 UTC。default branch main の最新 commit は 858badb、commit time は 2026-07-15 08:51:57 UTC。GitHub Releases の latest release は v9.5.0 で、published at は 2026-07-14 14:27:38 UTC。Tags page でも latest tag は v9.5.0 だ。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | asamassekou10/ship-safe |
| 位置づけ | AI-native codebase 向けの local security scanning CLI |
| Stars | 763 |
| Forks | 83 |
| 主言語 | JavaScript |
| ライセンス | MIT |
| リポジトリ作成日 | 2026-02-02 08:19:37 UTC |
| 最近 push | 2026-07-15 08:52:07 UTC |
| 最新 main commit | 858badb、2026-07-15 08:51:57 UTC |
| Latest GitHub release | v9.5.0、2026-07-14 14:27:38 UTC |
| 最新 tag | v9.5.0 |
| 主な入口 | npx ship-safe、npx ship-safe audit .、npx ship-safe agent .、npx ship-safe ci . --sarif results.sarif |
| キーワード | security scanner、AI agents、MCP security、secrets、CI/CD、supply chain |
なぜこの方向を見る価値があるのか
security scanner は多い。ただ、Ship Safe の面白さは「よくある vulnerability をもう一度 scan する」ことではなく、AI development toolchain そのものを attack surface として扱うところにある。
README にある scan scope は広い。application vulnerability、secrets、compliance data、dependency supply chain、CI/CD config、MCP と agent config、prompt injection、agent hijacking、memory poisoning、RAG poisoning、unsafe tool calls。coding agent を repository に接続している team にとって、これらはもう理論上の話ではない。
たとえば agent config。repository には .cursorrules、CLAUDE.md、MCP server config、auto-approval policy、hook、tool allowlist が置かれるようになった。これらは traditional SAST では code vulnerability として扱われないかもしれないが、agent が何を読めるか、何を書けるか、どこへ接続できるか、どんな command を実行できるかに影響する。Ship Safe はこの種の file も scan scope に入れ、agent-related config を review 対象にする入口を作っている。
もう一つは supply chain だ。v9.5.0 release では、model weight risk、repository symlink escaping、slopsquatting、ClickFix lure、npm lifecycle worm といった方向が追加されている。これらの detection は成熟途上で false positive も出るはずだが、見ている変化は本物だ。AI toolchain によって、development time に実行されるものが増え、attack surface は production runtime だけではなくなった。
CLI-first な使い方
Ship Safe の入り口は低い。
npx ship-safefull audit もそのまま実行できる。
npx ship-safe audit .CI に入れるなら、次のような形になる。
npx ship-safe ci . --threshold 80 --sarif results.sarifREADME には agent mode もある。remediation plan を作り、diff を見せ、approval を待ち、結果を verify し、undo も用意する。この設計は「全部自動修正する」より現実的だ。security fix は context judgment が必要になる。suggestion を出せることと、その patch を受け入れてよいことは別だからだ。
個人的に見ているのは、REPL、audit、agent fix、CI gate が同じ CLI に入っている点だ。small team にとって、security tool の問題は capability だけではない。account を作り、project を作り、dashboard を設定し、report を待つ platform になりがちだ。Ship Safe の open-source CLI は、少なくとも local command から始められる。
MCP と agent config が差別化ポイント
Ship Safe README には多くの agent が並んでいる。traditional なところでは injection、auth bypass、SSRF、config audit、PII、git history secrets、CI/CD scanner がある。より特徴的なのは AI/agent 側だ。
MCPSecurityAgentは MCP server misuse、tool poisoning、typosquatting、unvalidated inputs を見る。AgenticSecurityAgentは agent hijacking と privilege escalation を見る。AgentConfigScannerは.cursorrules、CLAUDE.md、Claude Code hooks にある prompt injection を見る。ManagedAgentScannerは always_allow、unrestricted networking のような managed-agent misconfig を見る。TrustBoundaryAgentは repo から外へ出る symlink、~/.ssh、~/.aws、.envへの link など trust boundary 問題を見る。
これらの check に共通するのは、ordinary code vulnerability ほど長年の成熟パターンがない一方で、いまの development workflow の中に実際に存在していることだ。prompt file、MCP config、hook は production build に入らないかもしれない。それでも development machine 上の agent behavior には影響する。
Gumi で取り上げる価値があるのもここだと思う。これは「AI が security report を書く」タイプの generic wrapper ではなく、AI agent toolchain 自体を scan 対象として扱っている。
local scan と commercial layer の境界
README では境界も明確だ。open-source CLI は local scan、audit、agent-assisted fixes の入口。Pro/Team layer は scan history、cloud dashboard、PDF report、shared workspace、PR Guardian、team report が中心になる。
この境界は注意したい。private repository で local check を一度走らせたいだけなら、CLI から始められる。一方で full team security platform を期待するなら、commercial workflow へ向かう。この分離自体は悪くないが、adoption 前にどこが open-source core で、どこが hosted layer なのかを見ておく必要がある。
もう一つの現実は false positive だ。Ship Safe の scope はかなり広い。SQL injection から AI Bill of Materials、secrets から fake CAPTCHA lure まで見る。coverage が広いほど、team 側で threshold、ignore path、finding review を調整する必要がある。early security signal としてはよいが、判断なしの final verdict として扱うべきではない。
向いている場面
第一の場面は、Claude Code、Cursor、Codex、MCP server、custom agent hooks を repository で使っている team だ。agent-facing file が permission boundary を広げすぎていないかを見たい。
第二の場面は、PR や release 前に local security gate を一つ足したい small team だ。npx ship-safe audit . と ship-safe ci は、full platform integration より先に試しやすい。
第三の場面は、AI-native app だ。prompt、RAG、tool call、agent memory、model weight、MCP registry が repository に入っているなら、traditional lint/SAST だけでは context を拾いきれない。
第四の場面は、security review 前の quick preflight だ。human review の代わりにはならないが、secrets、dangerous config、CI/CD pitfalls、agent config risk を先に並べられる。
注意したいところ
第一に、project はまだ若い。作成日は 2026-02-02。すでに 763 stars、83 forks、342 commits、v9.5.0 release があるとはいえ、ecosystem feedback はもう少し観察したい。
第二に、README と release note の coverage は非常に広い。採用時はまず default scan を走らせ、CI threshold は段階的に入れた方がよい。初日からすべての finding を blocker にするのは危険だ。
第三に、AI/agent security rule は traditional vulnerability scanning より context dependent になる。prompt injection、agent hijacking、tool poisoning の判断は、team の実際の使い方と合わせて見る必要がある。
第四に、open-source CLI と commercial workflow は分かれている。hosted dashboard や report capability が open-source かどうかを気にする team は、先に自分たちの使用境界を確認したい。
まとめ
Ship Safe が面白いのは、security scanning の視点を「application code」から「development-time agent が触れる一式」へ広げているところだ。
repository に MCP config、agent rules、AI prompts、RAG documents、model dependencies、auto-fix scripts が増えているなら、traditional lint と dependency audit だけでは足りない。asamassekou10/ship-safe は toolbox に入れて試す価値がある。まずは local で npx ship-safe audit . を走らせ、agent 時代の新しい risk を早めに表面化できるかを見るのがよさそうだ。