Security
When security is a report that arrives after the feature is done, it turns into a rework list — and the half that’s too much trouble gets postponed forever. In Spaccy it enters where it’s still cheap: in the design, in the code, in the running application, and at the release gate.
This holds for your product: the steps below run against your repository and your application, with the analysis tools you already use.
Before any code exists
A design flaw found in production costs orders of magnitude more than the same flaw flagged in the proposal. These three steps run while the feature is still just text.
Walks the feature’s data flow element by element applying STRIDE — spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege — and adds the lens of risks specific to systems with agents. The result isn’t a document that sits still: it becomes an acceptance criterion of the feature itself, with a reference to the matching ASVS control.
/threat-model
The privacy impact assessment runs the LINDDUN method over the feature’s personal-data flows, with references to GDPR and ISO 27701. It’s the difference between discovering in legal review that the feature keeps more than it should, and having decided that at design time — when it still costs one line.
/dpia
Starting from the use cases you’ve already documented, it derives the abuse cases: the same flow, seen through the eyes of whoever wants to break it, actor by actor. Out comes what nobody writes because nobody has time — and it’s exactly where incidents live.
/abuse-cases
About the code, and about the application
Audits the pending diff or a directory and maps every finding to the matching ASVS 5.0 control and OWASP Top 10 entry — not to some taxonomy that only exists here. Every finding arrives with the reference your team already uses to prioritize.
/security-review
What static analysis can’t see: the live application responding. Security headers, injection, cross-site scripting and, at the highest tier, unauthorized access to another user’s object and authentication failures. Report-only by design: it points things out and proposes fixes, it doesn’t change anything.
/dast
At the release gate
The decision to ship or block a release shouldn’t depend on someone having read a report on a Friday afternoon.
The gate returns an exit code: zero ships, nonzero blocks. That’s what makes it usable as a CI step — no stage of your pipeline needs to parse prose to decide whether the release passes.
It doesn’t discover anything new at release time, and that’s deliberate: a gate that runs analysis is a slow, non-deterministic gate. This one reads the artifacts the earlier steps produced and decides. Running it twice gives the same result.
Every blocking reason has its own code and an obvious next step: missing threat model, an open critical finding in the scan, an unresolved critical security follow-up. Nobody has to guess why the release stopped.
At the lightest rigor level, and by default, the gate reports and lets it through: blocking the release is strict-tier behavior, for when the project — or the feature — calls for it. You choose when the lock closes; see how rigor is dialed.
# in the CI step, before deploy:
$ /security-gate --tier strict --json
# exit 0 → ships · exit ≠ 0 → blocks, with the reasonWhat holds it together
Spaccy orchestrates the analysis tools that already exist and are better than anything we’d build from scratch — including Anthropic’s own official security reviewer, plugged in as an engine. What the product adds is what’s missing from the market: integration, risk-based dosing, tracking and a gate.
Findings from different sources are normalized into SARIF, the standard static-analysis result format. That means the same finding is readable by your editor, by your code-review interface, and by the gate — with no tool speaking its own dialect.
Every finding enters the same pending-items registry as the rest of the work, tagged as security, with severity and an owner. There’s no parallel backlog that only the security folks open — the vulnerability competes for priority in the same place as the feature.
Depth follows the project’s rigor tier: at the lightest, focus on secrets and authentication; at standard, full static analysis; at strict, supply chain, infrastructure as code and the highest ASVS checklist. What the tier never does is make a scan less correct — it only reduces what it looks at.
Request early access and model threats on the feature you're designing before any code exists.