Compliance SDK, CI gate and API.
Integrate once, never touch it again.
One module registration wires up scanning, evidence, consent, audit logging and the CI gate. Every capability we ship afterwards arrives on the next SDK bump, there is no client code to go back and edit.
It instruments what you already wrote
The SDK auto-instruments routes, database access and PII flows, so evidence is a by-product of running your service rather than a task somebody schedules.
- Route, query and PII-flow instrumentation
- Consent banner and ledger endpoints included
- Evidence pushed with redaction on by default
- No agent in production, read-only by design
// One import. Every capability, forever. import { TryTrustableModule } from '@trustable/sdk'; @Module({ imports: [ TryTrustableModule.forRoot({ apiKey: process.env.TRUSTABLE_KEY, frameworks: ['soc2', 'iso27001', 'dpdp'], scanners: { sast: true, sca: true, iac: true }, consent: { banner: true, ledger: true }, evidence: { auto: true, redactPII: true }, gate: { failOn: 'critical' }, }), ], }) export class AppModule {}
Block the merge, not the release
The gate runs your control set against the diff. A change that would break CC6.6 fails the pull request with the control reference and the fix, instead of surfacing in an audit six months later.
- Merge-blocking on the severity you choose
- Control references in the failure output
- SAST, SCA, IaC and DAST in one run
- Typically under a second for a normal diff
The fix, where you are
VS Code and JetBrains surface control violations as you type, with the remediation inline, the shortest possible distance between writing the problem and fixing it.
- Inline control violations as you type
- One-click remediation where it is deterministic
- Framework context on hover
- Works offline against the cached control set
Everything the UI can do
REST and GraphQL cover the whole surface, and signed webhooks push state changes to your systems so you are not polling for a control that flipped.
- REST and GraphQL, same auth model
- Signed webhooks with replay protection
- Scoped API keys per environment
- Rate limits published, not discovered
Wire it up on the call.
Bring a repo. We will add the SDK, run the gate on a real pull request and push the first evidence to the ledger.
Why the SDK, and not an agent
Most compliance tooling observes your infrastructure from outside: it reads cloud configuration through a role, sends a questionnaire, and infers posture. That works for asking whether encryption is enabled. It cannot tell you whether the endpoint you shipped last Tuesday touches personal data, because that fact lives in your code rather than in your cloud console.
The SDK sits where the answer is. It registers as a module, instruments routes, database access and PII flows, and emits evidence as a by-product of the service running, not as a task somebody schedules before an audit. There is no daemon in production and nothing writes to your systems: the SDK is read-only by design, with redaction on by default so field values never leave your process.
| Surface | What it does | Where it runs |
|---|---|---|
| Backend SDKNode, Python, Go | Auto-instruments routes, queries and PII flows; exposes consent and ledger endpoints | In your service, read-only |
| CI gateGitHub Actions, GitLab CI | Runs your control set against the diff and fails the pull request with the control reference and the fix | In your pipeline |
| Security scannersSAST, SCA, DAST, IaC, secrets | Real security testing inside your pipeline rather than a questionnaire about it | In your pipeline |
| IDE pluginVS Code, JetBrains | Surfaces the finding and the control it breaches at the line that causes it | On the developer's machine |
| REST and GraphQL APIsSigned webhooks | Everything the UI can do, scriptable, with HMAC-signed event delivery | Anywhere |
Blocking the merge instead of the release
A compliance finding is cheapest at the moment it is written and most expensive in an audit report six months later, by which point the author has forgotten the context and the code has been built on. The gate exists to collapse that distance.
It runs your enabled control set against the diff rather than the whole repository, so it stays fast enough to sit in the default pull request check. When something fails, the message names the control (CC6.6, or DPDP Section 8(5)) and the specific change that breaks it, because "compliance failure" with no reference teaches nobody anything and gets disabled within a month.
Failures are blocking by default and can be set to warn while a team adopts it. What the gate will not do is pass something quietly and record it as satisfied: a skipped check reports as skipped, for the same reason a requirement with no control scores as not modelled rather than as satisfied.
Integrate once
This is a design rule rather than a marketing line, and it constrains what we are allowed to ship. Every capability has to arrive on an SDK version bump. If a customer has to go back and edit client code to pick up a feature we built, we designed it wrong and the feature does not ship until it is redesigned.
The practical consequence is that one module registration wires up scanning, evidence collection, consent endpoints, audit logging and the CI gate together, and the surface you integrate against does not grow as the platform does. It is also why the SDK spreads through engineering teams rather than procurement, which is a distribution property as much as a technical one.
What the SDK never does
- It does not write to your systems. Read-only by design, with no remediation actions taken on your behalf
- It does not ship field values. Redaction runs in your process; what leaves is the shape of the flow, not the contents
- It does not run an agent in production. There is no daemon, no sidecar and no persistent process to operate
- It does not fabricate posture. An uninstrumented service reports as uninstrumented rather than as passing
Full API reference and installation are in the docs, and the trust page covers isolation, encryption and residency in detail.
The things people ask us
Which languages does the SDK support?
Node, Python and Go for the backend SDK, with VS Code and JetBrains plugins for the editor and GitHub Actions and GitLab CI integrations for the pipeline. Anything not covered by an SDK can use the REST or GraphQL API directly.
Does the SDK run an agent in production?
No. There is no daemon, sidecar or persistent process. The SDK is a library inside your service, it is read-only by design, and redaction runs in your process so field values never leave it.
What does the CI gate actually check?
Your enabled control set, run against the diff rather than the whole repository so it stays fast enough for a default pull request check. A failure names the control reference and the change that breaks it, so the developer can fix it without reading an audit report.
Can the gate be set to warn instead of block?
Yes. Blocking is the default because a warning nobody acts on is a finding you have logged rather than fixed, but teams commonly run in warn mode during adoption. A skipped check reports as skipped and is never recorded as satisfied.
What does 'integrate once' mean in practice?
Every capability we ship has to arrive on an SDK version bump. If picking up a new feature would require you to edit client code, we treat that as a design failure and rework it. One module registration wires up scanning, evidence, consent, audit logging and the CI gate.
How is this different from agentless cloud posture scanning?
Cloud posture scanning reads configuration and can tell you whether encryption is enabled. It cannot tell you whether the endpoint you shipped last week touches personal data, because that lives in your code. The SDK instruments the code path, so evidence reflects what the service does rather than how the account is configured.