Friday, October 23, 2026

ship-safe for auditing AI-written code and agent configs with evidence-backed verdicts

ship-safe for auditing AI-written code and agent configs with evidence-backed verdicts

ship-safe is an MIT-licensed local CLI that scans repositories, agent configs, and dependencies, then investigates each finding to confirm or refute it with citable evidence for authorized DevSecOps teams.

Toolasamassekou10/ship-safe — an independent security agent for AI-written software that finds issues, investigates them, and shows the evidence
CategoryStatic analysis and security investigation CLI (JavaScript/npm, MIT-licensed)
Primary UseScanning repos, MCP configs, prompts, dependencies, CI/CD, and secrets with ship-safe audit and ship-safe investigate, then gating pull requests via ship-safe ci
Safe UseAuthorized defensive use: scanning codebases and repositories you own or are contracted to assess, hardening your own AI agent configurations, and enforcing security gates in your own CI pipelines
Telemetry NoteRuns locally with no signup or API key for core checks; --no-ai guarantees a fully offline scan, while AI-backed modes send bounded, best-effort-masked context to your configured LLM provider

ship-safe positions itself as an independent security reviewer for software that AI agents wrote, and the framing is more deliberate than marketing. The core insight in the README is the "marked its own homework" problem: when a coding agent reviews the repository it also authored, the reviewer and the author are the same actor with the same blind spots. ship-safe answers that with a two-layer architecture — a deterministic sensor layer that produces findings fast and repeatably, and an investigation layer that adjudicates each finding before you ever see a severity label. At roughly 848 stars on GitHub with an active CI badge and a published npm package, it has enough traction that the design claims deserve a close read.

The deterministic engine is what most teams will run first, and its coverage matrix is unusually wide for a single CLI. It scans application code for the classic categories — SQL and NoSQL injection, XSS, SSRF, auth bypass, path traversal — but it also reaches into surfaces that traditional SAST tools largely ignore: MCP server configs, agent permission grants, prompt files, RAG pipelines, GitHub Actions workflows, and dependency manifests. The README's coverage table calls out AI-specific failure modes like prompt injection, agent hijacking, memory poisoning, RAG poisoning, and unsafe tool calls, alongside supply-chain checks for typosquatting, dependency confusion, and risky install scripts. That breadth is the point: AI-native applications scatter their attack surface across config files no single-file linter ever reads.

The investigation layer is where ship-safe differentiates itself from pattern-matchers. Rather than emitting raw rule hits, it resolves each finding to one of four verdicts — confirmed, likely, unresolved, or refuted — and it does so through a ranked cascade of passes. The ordering is explicit in the README: a traced data path outranks a model's reading of the same file, and a live probe that actually authenticated outranks both. A cheaper pass never overturns a more expensive one, which is a sensible epistemic hierarchy for a tool that wants its conclusions to be arguable rather than merely asserted.

The sample output against OWASP NodeGoat shows what that looks like in practice. A NOSQL_INJECTION_WHERE finding in app/data/allocations-dao.js:78 is traced backwards through three steps: the tainted threshold value is destructured in app/routes/allocations.js:20, passed into the DAO at line 23, and reaches the $where sink without validation on that path. The suggested fix — replacing $where with standard MongoDB operators like $eq or $gt — is advisory rather than automatic. This is exactly the kind of cross-file taint narrative that turns a scanner hit into something a reviewer can actually adjudicate, and the README's phrasing, "disagree with a step instead of a severity label," captures the intended workflow.

The --verify flag deserves a note on ethics and boundaries, because it is the closest the tool comes to active probing. It tests a leaked key against its provider to establish that the credential is live — an authentication check, not an exploitation step, and one that stays entirely within your own repository's findings. If your threat model or engagement scope forbids any outbound validation, leave it off; the default investigate mode is purely static. For defenders, the value is obvious: a confirmed-live key forces immediate rotation in a way a "possible secret" finding never does.

Two commands address risks that simply did not exist two years ago. ship-safe trust inspects an unfamiliar folder before you open it with an agent — answering "what runs on open?" — which is the right question before pointing Claude Code or Cursor at a take-home exercise or a cloned repo. ship-safe capabilities inverts the view: instead of asking what's in the code, it asks what an agent working in this repo can actually reach. The README's example is compelling, chaining CLAUDE.md (repository-controlled instructions), permissive .claude/settings.json grants like Bash(git push:*) and Write, and an MCP tool grant into a path from "any landed commit" to "privileged write with no human in the loop." Each line is unremarkable alone; no single-file review could ever assemble the chain.

CI integration is where the evidence model pays off structurally. ship-safe ci emits SARIF for GitHub code scanning, and the gating logic can key on verdicts rather than severities: --fail-on-verdict confirmed blocks only what the investigation established, while --ignore-refuted stops refuted noise from blocking builds. Baseline comparison is handled thoughtfully — a trusted base scan written via --write-baseline-report stores hashed finding identities and rule metadata but explicitly not raw matched secrets, and PR results classify findings as introduced, resolved, unchanged, or uncertain, with ambiguous matches surfaced but non-blocking. That is a mature take on the "existing debt vs. new risk" problem that plagues severity-gated pipelines.

The fix workflow is deliberately conservative. ship-safe agent proposes a plan and a diff, asks before writing anything, runs a static rescan afterwards, and keeps changes reversible via ship-safe undo or branch-and-PR modes with --branch --pr. The README is candid about a subtle trap: it explicitly states that "detector disappearance is not an independent retest," acknowledging that a fix can silence a rule without actually removing the vulnerability. Seeing a tool document its own verification limits in its README is rare and speaks well of the engineering culture behind it.

Data flow and privacy boundaries are documented rather than hand-waved. Core checks run offline with no signup and no API key; --no-ai forces a fully local scan. AI-backed modes — provider-backed classification, deep analysis, and the GPT-Red scenario generator — send bounded context to your configured LLM provider after best-effort credential masking, with the README pointing to a dedicated security page for exact boundaries. Reports default to project-relative paths precisely so they can move between workstations and CI without leaking local directory names, and the JSON contract carries schemaVersion: 1, the tool version, and a UTC generatedAt timestamp — small details that make machine consumption tractable.

The benchmarking philosophy is worth pausing on because it addresses the failure mode that matters most. The CI-gated benchmark scores conclusion quality — how many known-real findings the tool settles, how much known noise it refutes — and it tracks whether the tool ever refutes something real, with a stated budget of zero for that error class. The reasoning is sound: a false refutation is the only error that silently loses a vulnerability, because a false positive annoys a developer but a false negative ships the bug. Determinism means asking twice yields the same answer, which is what makes CI gating on verdicts coherent at all.

Commercially, the split is clean. The MIT-licensed CLI — scanner, agents, rules, fixtures, CI integrations — lives in the public repository, while the hosted dashboard (scan history, PR Guardian, team workflows) is a private commercial product. Nothing in the free tier is crippleware: audit, investigate, capabilities, trust, red-team scenarios, and the fix agent are all in the open core. Requirements are Node.js 22.13+ on the 22.x line or Node 24+, with 18 and 20 explicitly dropped, so check your runtime before scripting it into pipelines.

For authorized teams, ship-safe fits naturally into defensive workflows: pre-merge gates on your own repositories, pre-onboarding inspection of third-party code before an agent touches it, and configuration audits of agent permission grants you control. The one-command entry point — npx ship-safe — drops you into an interactive REPL for scanning, fixing, and asking questions, while npx ship-safe audit . runs the full pass covering secrets, all 31 agents, dependencies, and a remediation plan. It is a tool built for the reality that modern attack surface lives as much in CLAUDE.md and .claude/settings.json as in application code, and it treats that reality with more rigor than most of what's currently in the AI-security tooling space.

Official project repository for asamassekou10/ship-safe.
Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Share articleFacebookXLinkedIn

Continue exploring

Browse all articles →

0 comentários:

Post a Comment

Note: Only a member of this blog may post a comment.