Enterprise security posture.
Tested, not asked about.
Posture, risk and controls that read from what your systems are doing rather than from a questionnaire somebody filled in. Real scanners in your own pipeline, a risk register that moves when a control fails, and evidence an auditor can date.
Configuration is not behaviour
Most compliance tooling establishes security posture by reading a cloud configuration through a role and sending the customer a questionnaire. Both answer real questions. Neither answers the one that matters most: what does the code you shipped this week actually do?
A bucket policy tells you the bucket is private. It does not tell you that a new endpoint returns a field it should not, that a dependency added on Tuesday carries a known CVE, or that a secret was committed and rotated but never removed from history. Those live in the pipeline, which is where we put the scanners.
| Question | Answered by configuration scanning | Answered by testing in the pipeline |
|---|---|---|
| Is encryption at rest enabled? | Yes | No |
| Is MFA enforced on the root account? | Yes | No |
| Does this endpoint expose personal data? | No | Yes: route and PII-flow instrumentation |
| Does this dependency carry a known CVE? | No | Yes: SCA on every build |
| Is this input reachable and injectable? | No | Yes: SAST and DAST |
| Did a secret reach the repository? | No | Yes: secret scanning, including history |
| Is the infrastructure change safe to merge? | Partially, after apply | Yes: IaC scanning, before merge |
Both are needed. The difference is that the right-hand column fails a pull request rather than appearing in a report a quarter later.
Risk that moves on its own
A risk register maintained by hand only ever improves, because deterioration is nobody's job to log. Scores drift downward between audits and correct themselves sharply during one.
Deriving residual risk from live control state inverts that. Score a risk on likelihood and impact to get the inherent figure, attach the controls that treat it, and the residual figure is computed from whether those controls are currently passing. A failing access review raises the residual score on every risk it treats, the day it fails. The alert arrives before the audit rather than during it. The mechanics are on the risk register page.
The part that unblocks revenue
The reason security programmes get funded is rarely the auditor. It is the enterprise deal sitting in security review while someone assembles answers by hand.
- A trust portal that shows posture publicly, with sensitive documents behind an NDA gate, so a buyer can self-serve the first two rounds of diligence
- Questionnaire answers drafted from live control state. Upload a SIG or CAIQ and get answers traceable to a dated control result rather than to institutional memory
- Evidence with dates attached. The difference between passing and failing a review is usually not whether a control exists but whether you can show when it last ran and who checked
What we will not do
Worth stating, because the boundaries are the reason a security team can approve this.
- No write access. Integrations take read scopes, and the SDK performs no remediation
- No agent in production. No daemon, no sidecar, no persistent process to operate
- No field values leave your process. Redaction runs inside it
- No invented posture. An uninstrumented service reports as uninstrumented, and a requirement with no control mapped scores as not modelled rather than satisfied
Our own posture, including the plain statement that certification is in progress rather than complete, is on the trust page.
The things people ask us
How is this different from cloud security posture management?
Posture management reads your cloud configuration and tells you whether encryption is enabled and which buckets are public. That is useful and it is not the same question. 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 account. We instrument the code path as well as the configuration.
Does the CI gate slow down our pipeline?
It runs your enabled control set against the diff rather than the whole repository, which keeps it inside the window of a normal pull request check. Teams commonly run it in warn mode during adoption and switch to blocking once the noise is tuned out. A skipped check reports as skipped and is never recorded as satisfied.
How does a failing control change our risk register?
Automatically, and in the direction people find uncomfortable. Residual risk is derived from live control state rather than stored as a number somebody edits, so a control that starts failing raises the residual score on every risk it treats, at the moment it fails rather than at the next review.
What do you need access to?
Read-only scopes on integrations, and the SDK inside your own services. We take no write access to your cloud accounts and perform no remediation on your behalf. Redaction runs in your process, so what we receive is the shape of a data flow rather than the values moving through it.
Can this answer security questionnaires for us?
It drafts answers from live control state and keeps them in a trust portal with NDA-gated documents. The point is not the drafting, it is that the answer is traceable to a control result with a date on it, rather than to a spreadsheet somebody updated last year.
Are you certified yourself?
Not yet. Certification is in progress and we say so plainly on the trust page rather than implying otherwise. The controls described here are ones we will evidence on request; treat them as claims we stand behind, not as independently attested facts.
Run it against your own pipeline.
We add the gate to one repository on the call and show a real finding, with the control reference and the fix, on a real diff.