Platform
Security testing for serious AI software delivery
Every finding is confirmed against the running application before it reaches you — so the dashboard shows real risk, not scanner noise.
Ciao Security is the platform's application security layer: static scanning, dependency checks and access-control probes, with vulnerabilities confirmed against the live app before they are flagged. Unlike raw scanner output that buries teams in false positives, Ciao verifies each finding against the running application and rolls the result into a safe-to-publish dashboard — so teams ship when the app is demonstrably safe.
Published 2026-07-03 · Last updated 2026-07-03
Findings you can act on, not scanner noise
Application security tooling has an honesty problem: scanners produce hundreds of findings, most of which do not matter, and teams learn to ignore the report. Meanwhile AI-assisted development raises the stakes — more changes, more surface, more chances for an access rule to quietly weaken.
Ciao Security makes a different contract with your attention: static scanning, dependency checks and access-control probes run continuously, and every candidate vulnerability is confirmed against the live application before it is flagged. What reaches the dashboard is real.
This page covers the security testing built into every Ciao project. For Ciao's own posture as a vendor — SOC 2 Type II, SSO, data handling, zero-retention model contracts — see the security and compliance overview.
How Security works
Security testing runs continuously inside the delivery loop, not as a quarterly event.
1. Static scanning on every change
Code is analyzed as it is written — insecure patterns, injection risks and dangerous constructions are caught at the change, not at the annual audit.
2. Dependency checks
Third-party packages are checked for known vulnerabilities, so the riskiest code in most applications — the code nobody on the team wrote — is watched too.
3. Access-control probes
Probes attempt what an attacker would: reading data across tenant boundaries, calling admin endpoints as a regular user, reaching routes that should require authentication.
4. Live confirmation before flagging
Candidate issues are confirmed against the running application before they are flagged, separating provable risk from theoretical noise.
5. The safe-to-publish dashboard
One view answers the release question: is this application safe to publish right now? Green reflects confirmed evidence, not the absence of a scan.
6. Fixes flow back through the loop
Confirmed findings come with drafted fixes that ship the way every change ships — through Builder, Guardrails review where policies require it, and QA gates.
Why it matters
A finding confirmed against the live app changes the conversation. It is not "the scanner says this pattern can be risky" — it is "this request, against your running application, returned data it should not have." Teams fix those.
And because the checks run inside the delivery loop, security keeps pace with development instead of auditing it months later. The safe-to-publish dashboard makes the release decision explicit: green is evidence, not optimism.
Live confirmation also changes who can act on security. A verified finding with its evidence attached does not need a security engineer to interpret it — the person running the project can see what happened and ship the drafted fix through review. Expertise still matters; it just stops being the bottleneck for every fix.
Who uses it
The safe-to-publish dashboard means different things to different readers.
- Teams without a security function — Most teams building internal tools and portals have no AppSec engineer. They get continuous testing anyway, with findings already verified.
- Engineering leaders selling to regulated buyers — Security questionnaires get answered with evidence from the running product, not aspirations from a policy document.
- Agencies — Every client application is tested to the same bar, and "is it secure?" has a dashboard behind the answer.
- Security teams — AI-built applications are often a blind spot. Ciao holds them to a continuous, live-verified standard the team can inspect.
Security and governance notes
- ✓ Static scanning, dependency checks and access-control probes run on every project.
- ✓ Vulnerabilities are confirmed against the live application before being flagged.
- ✓ Safe-to-publish status is visible per project and across the fleet in Conductor.
- ✓ Findings and their fixes are recorded in the append-only audit trail.
- ✓ Row-level security in the Supabase backend is exercised by access-control probes.
- ✓ Probes re-run after changes to authentication and permissions, so regressions surface early.
- ✓ Vendor-side compliance — SOC 2 Type II reports under NDA, SSO, zero-retention contracts — is covered on the security overview page.
Raw scanner output vs live-confirmed findings
The difference is what you can trust without triage.
| Typical scanner report | Ciao Security | |
|---|---|---|
| Volume | Hundreds of findings per run | Findings confirmed against the live app |
| False positives | Yours to triage | Unconfirmed candidates do not gate a release |
| Access control | Pattern-matched in code | Probed against the running application |
| Release decision | A judgment call from a PDF | The safe-to-publish dashboard |
| Fix path | A ticket to a backlog | A drafted fix through review and QA gates |
Frequently asked questions
How is this different from the /security page?
That page covers Ciao as a vendor — SOC 2 Type II reports under NDA, SSO via SAML and OIDC, the audit trail, zero-retention model contracts. This page covers what the platform does to your applications: scanning, probing and confirming vulnerabilities so each release is demonstrably safe to publish.
What does live-confirmed actually involve?
Candidate findings are exercised against the running application. A cross-tenant read attempt either returns data or it does not; an unauthenticated request either reaches the route or it does not. Confirmation turns a pattern into a fact before anyone is asked to act on it.
Does this replace a penetration test?
It does not claim to. Continuous, live-confirmed testing raises the everyday bar and catches regressions between formal engagements. Teams with contractual or regulatory requirements typically still commission periodic penetration tests — the two are complementary.
What happens when a real vulnerability is confirmed?
It appears on the dashboard with the evidence that confirmed it, alongside a drafted fix. The fix ships through the normal loop — Guardrails review where policies require it, QA gates before publish — and the trail records the finding and its resolution together.
Our security team wants to evaluate this — where do they start?
Book a demo and bring your questionnaire. SOC 2 Type II reports are available under NDA through the compliance track, and serious production programs start at USD 10,000 per year.