FAQ

Does it replace GitHub Spec Kit?

No. speckit-security is a Spec Kit extension, it installs on top of Spec Kit and adds security gates to Spec Kit's existing phases. You still need Spec Kit (specify CLI) to use it.

Is this a complete security solution?

No, and it's not trying to be. speckit-security catches a specific class of issues at a specific point in the lifecycle: it enforces that feature specs declare the required security sections, that model versions are pinned, that guardrail configs exist, and that implementation code doesn't contain inline prompts, committed secrets, or direct SDK imports outside an allowlisted gateway layer.

That's a meaningful subset of what production AI security requires. It is not a replacement for:

• Continuous organization-wide compliance monitoring
• SAST / DAST code scanners
• Dependency vulnerability scanning
• Secret rotation and key management
• Network security, WAF, DDoS protection
• Infrastructure hardening
• Employee security training
• Incident response tooling
• Penetration testing by humans
• External security audits

Use it as one layer of your broader security program, not as the whole program. The project is designed to be extended, see Customization for the config, template override, and sibling-extension paths for adding your own checks.

Does it work with my AI agent?

Probably yes. Spec Kit supports ~20 AI agents and the extension is agent-neutral, so any agent Spec Kit supports should also support speckit-security. Five agents are hands-on verified (Claude Code, OpenCode, Copilot, Gemini CLI, Cursor); the others are inferred.

See Agent Compatibility for the full matrix and how to test your own agent.

Does it work on Windows?

Indirectly. The bash scripts (gate-check.sh, audit.sh, red-team-run.sh, install-rules.sh) require POSIX bash, so Windows users need WSL or Git Bash. The Spec Kit CLI itself runs fine on Windows, but the check scripts won't.

Will it slow me down?

The gates add friction at phase transitions, that's the point. Without them you ship faster in the short term and pay interest in debt, incidents, and rewrites later. With them you ship slightly slower in the short term and avoid the compounding cost.

Practically, on a well-prepared spec, gate-check.sh runs in under a second and audit.sh runs in under two seconds.

What happens if a gate fails?

In strict mode, the hook blocks the phase transition. You either:

1. Fix the issue the gate is catching, or
2. Document it as deferred debt in the spec's §8 Deferred / Debt section with a remediation plan, or
3. Temporarily disable the extension (specify extension disable tekimax-security) if you have a legitimate reason to bypass

In warn mode, the hook still reports the failure but does not block.

Can I use this without spec-driven development?

Yes, but the value is lower. The gates are designed to run at SPECIFY, DESIGN, IMPLEMENT, and VERIFY transitions. If you don't write specs, you only get the post-implementation audit.sh checks (inline prompts, secrets, direct SDK imports). That's still valuable but it's about 20% of what the extension offers.

Can I add my own gates or checks?

The intended paths today are:

1. Config-level overrides, edit .specify/extensions/tekimax-security/tekimax-security-config.yml to extend the built-in secret patterns, inline-prompt patterns, and direct-SDK allowlist. User entries are additive, so you keep the defaults plus your custom rules. See Customization for the full list of keys the scripts actually read and which are still hardcoded.
2. Template overrides, drop replacement templates into .specify/templates/overrides/ so your team's spec and guardrail templates are used instead of the bundled ones.
3. Fork the extension, modify or add bash scripts directly, then install with specify extension add --dev from your fork. Please also open an issue upstream if the change is broadly useful so it can be merged back.
4. Sibling extension, write a second Spec Kit extension that coexists with speckit-security and hooks into the same lifecycle phases. Both extensions run their own gates.

A formal plugin system (register a custom gate via config, no fork needed) is planned for a later release. If you have a concrete use case, please open an issue describing what you need, the API will be shaped by real demand.

See Customization for the full details.

How do I contribute?

See CONTRIBUTING.md for the issue-first workflow, dev setup, and the development rules PRs must follow. Non-negotiable rules are listed in DEVELOPMENT-RULES.md.

Where do I report a vulnerability?

security@tekimax.com, see SECURITY.md for the responsible disclosure policy, scope, and response SLAs. Do not open a public issue for security reports.