- access
- kubeconfig, or an in-cluster agent deployed as a container or host service
- mode
- live-cluster read plus manifest analysis
- writes
- none
Layers
- Scanner & agent
- Control plane
- Evidence store
- Portal
- Reporting
- Edge & deployment
Scanners find things. The platform is what happens next.
A Python scanner and agent, a TypeScript control plane, a PostgreSQL evidence store, a client portal and a report service — deployed inside the environment you control, reading and never writing.
Book a baseline assessment- Scanner & agent
- Control plane
- Evidence store
- Portal
- Reporting
- Edge & deployment
The loop
From read-only scan to evidence somebody will accept.
Every stage exists because the one before it is not enough on its own. A scan without normalisation is noise; normalisation without ownership is a backlog; ownership without verification is a promise.
- 01
Read-only collection
The scanner runs near the environment — locally, from a pipeline, or as an in-cluster agent polling for jobs. It executes the engine set for the target type and produces a normalised bundle. Bundles can be kept on disk, uploaded later, or uploaded immediately, so the data flow stays under customer control.
- 02
Normalisation and identity
Ingestion deduplicates overlapping engine output into a single finding model and assigns each finding a deterministic key from the check and the resource. That key is what makes a rescan able to recognise a finding it has seen before.
- 03
Current state and history
The store keeps both: the current state of every target, and an append-only history of every scan. Workflow transitions are applied inside the same transaction as ingestion, so state and history cannot drift apart.
- 04
Ownership and governance
Findings carry an owner, a vendor, a due date from the per-severity SLA policy, comments, severity overrides with rationale, and exceptions with an expiry. Acceptance policies apply per target, with administrative override.
- 05
Verification
The next scan looks for known finding keys specifically. Scan-to-scan comparison separates new, resolved and regressed findings, which is what turns a closed ticket into a verified fix.
- 06
Artifacts
The same scan state produces the technical assessment, the executive deck, the machine-readable exports and the evidence pack — with a SHA-256 for every stored artifact and an explicit list of anything absent.
Architecture
What runs where.
The default deployment is a single site under Docker Compose with Nginx terminating TLS. The database and the report service sit on internal-only networks and are not reachable from outside the deployment.
- scanner & agent
- Python with Typer and the Kubernetes, Azure and AWS SDKs. Executes local or remote scan jobs and uploads normalised bundles.
- engines
- Trivy, Kubescape, Polaris, kube-score, Prowler, plus native RBAC, NetworkPolicy, Azure container and AWS ECS/ECR checks.
- control plane
- Express and TypeScript. Authentication, tenant data, ingestion, workflow, compliance, jobs, artifacts, notifications and webhooks.
- evidence store
- PostgreSQL 16 with JSONB. Current findings, scan history, control results, workflow events, policies and audit log.
- portal
- React with TanStack Query. Separate administrative and customer-scoped experiences.
- reporting
- Python DOCX and PPTX reporters behind an internal FastAPI service, generating from the retained raw bundles.
- edge
- Nginx and Certbot for TLS termination, routing and service isolation.
Access
Read-only by design, not by policy.
The agent implements no remediation path. There is no code in it that changes a cluster, a subscription or an account — which is a stronger guarantee than a permission boundary somebody has to remember to maintain.
- access
- temporary credential or managed identity, scoped to the assessed resources
- scope
- container services and subscription posture
- writes
- none
- access
- cross-account role assumption with an ExternalId
- scope
- ECS, ECR and account posture
- writes
- none
Scope, timing, expected API calls, permissions and image-pull behaviour are agreed before onboarding, and a first engagement usually starts with one target and a bounded scan window.
Operations
Built to be run by somebody, repeatedly.
An assurance service is only as good as its worst month. These are the parts that exist because the process has to survive contact with a real operations team.
Agent fleet health
Heartbeat, health, version and target inventory per agent, with alerts when a target goes stale. A silent agent is a failed assessment, and it should be visible as one.
Tenancy
Administrative and customer-scoped views, tenant-linked users and roles, per-customer API keys stored as bcrypt hashes and revocable individually, and customer-scoped notifications.
Identity
Local authentication or Microsoft Entra ID single sign-on, with PostgreSQL-backed sessions and session-ID regeneration at login.
Integration
HMAC-signed webhooks to Slack, Teams or your own receiver, with signature verification and a documented retry and destination policy. SMTP and webhook secrets are encrypted with AES-256-GCM.
Honest status
Where the product actually is.
QubeAuditor is delivered today as a managed engagement or a controlled single-customer deployment, not as self-service SaaS. That is a deliberate choice about what is ready, and we would rather write it here than let you discover it in a procurement review.
- ready
- multi-engine Kubernetes, Azure container and AWS ECS/ECR scanning; ingestion and normalised state; compliance evidence; finding lifecycle, SLAs, vendor scorecards and scan diffs; remote scan jobs and agent health; DOCX, PPTX and evidence packs; Entra SSO, notifications and webhooks
- partial
- framework coverage is partial and labelled as such throughout; artifacts use a local volume rather than object storage; report generation is serialised
- absent
- GCP targets; runtime or eBPF detection; admission enforcement; attack-path graphs; SBOM and VEX workflow; self-service onboarding
- delivery
- bounded baseline engagements and managed assurance, operated by you, by an MSP partner, or by Shandoola
Questions
Platform questions
Or start with something you already have
Bring one recent security report from the vendor operating your estate. We will map how many of its findings have an accountable owner, a verification state, and evidence you could hand to an auditor.
Book a baseline assessmentContact
Book a baseline assessment
Tell us what you run and who operates it. We will come back with a scope, a timeline and a fixed price for one estate.