just-vibeSecurity · inspect by default
/security-inputs
Audit validation and injection risks at input boundaries
Use for injection and unsafe interpreter boundaries; llm-injection handles model instruction confusion, and security-fix repairs a confirmed injection.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select security-inputs from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv security-inputs, /just-vibe security-inputs and /jv:security-inputs in Claude. See shortcut setup and context examples.
/just-vibe:security-inputs Trace untrusted filters to SQL and template sinks without active remote probing./just-vibe:security-inputs Review SQL and template paths where only one uses unsafe concatenation./just-vibe:security-inputs Inspect source without sending destructive payloads or probing third parties.What the agent does
- Trace each untrusted value from its source through transformations and validation to the final sink.
- Assess parameterization or contextual encoding at the actual interpreter boundary, distinguishing validation from authorization.
- Propose safe regression cases.
Inputs
- entry points, input formats, interpreters/sinks, and relevant source.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Injection, unsafe parsing, traversal, and validation gaps along reachable paths.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Inspect; entry points, input formats, interpreters/sinks, and relevant source.
- Prerequisites
- Defined application boundary, authorized code/environment, relevant trust/access rules, and evidence sources. Default to defensive inspection; active tests use owned or explicitly authorized isolated targets. Minimize sensitive evidence and never print usable credentials.
Expected output
- Evidence-backed findings or justified protections with the source-to-sink path, required conditions, focused remediation and a safe regression fixture.
How the work is checked
- A concatenated query path is assessed end to end; safe parameterization is not flagged solely due to user input presence.
When to stop or clarify
- No destructive payloads or third-party probing. Unsupported exploitability remains a risk hypothesis rather than a confirmed breach.
Handling missing context
- Infer
- Resolve the requested surface, source/runtime version, reachable callers and actual trust/access boundaries.
- Assume
- Start with source analysis and bounded owned fixtures; treat scanner output as leads and preserve legitimate controls.
- Ask
- Ask when target authorization or necessary trust semantics are unresolved before active probing; source inspection need not wait for production access.
Technical guidance
- Evidence
- Identify attacker-controlled sources, transformations and actual SQL/shell/template/URL/parser/path sinks.
- Method
- Load matching vulnerability cards and framework defaults; trace a reachable path and effective parameterization, encoding or allowlist controls.
- Pitfall
- A dangerous-looking API with trusted constants is not automatically exploitable; input validation alone does not make every interpreter safe.
- Check
- Exercise a safe local regression for the unsafe boundary and a valid control; retain unknown reachability/configuration as conditional.
Situational decisions
When the input reaches a safe parameterized sink: Do not flag injection solely because the input is user controlled; inspect other reachable sinks separately.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.