- 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, all deployed inside the environment you control, reading and never writing.
Book a baseline assessment- Scanner & agent
- Control plane
- Evidence store
- Portal
- Reporting
- Edge & deployment
QubeAuditor
The QubeAuditor platform is the layer between a scanner and an auditor. It runs six Kubernetes scanner paths plus native Azure and AWS checks read-only, deduplicates the output into one finding model with a deterministic key, tracks each finding through assignment, remediation and verified closure, and generates the reports and evidence pack from that same state.
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, either 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
Can QubeAuditor run in CI or a pipeline?
Yes. The scanner is a CLI first: it can run locally, from a pipeline, or as a long-lived agent that polls the control plane for jobs. Scan bundles can be retained on disk and uploaded later, which is what makes offline review and air-gapped handling possible.
Does the agent need inbound network access?
No. The agent polls the control plane for jobs rather than receiving pushed work, so it needs outbound access to the control plane and to the target APIs it is assessing. It reports heartbeat, health and version so a stalled agent is visible.
Is QubeAuditor self-hosted or SaaS?
The primary operating model is a deployment inside the customer environment or one the customer controls, which is what keeps scan data and evidence under customer ownership. It can be operated by your team, by an MSP partner, or by Shandoola as a managed service. Public self-service onboarding does not exist.
What happens when a scanner cannot check something?
It is reported as unassessed or as an error, never as an implicit pass. A permission-denied result is a gap in the evidence, and silently converting it into a green control is how compliance reporting loses its value.
Read next
- The published NIS2 Article 21 control mapping
Every measure, the control identifiers that evidence it, and the two that nothing evidences. Reviewable rather than scored.
- What the Azure container checks cover
Container Apps, Container App Environments, Container Instances and Dynamic Session Pools, across 17 container-scope controls.
- What the AWS ECS and ECR checks cover
22 Container Assurance Workload controls over ECS services, task definitions, IAM, load balancers and ECR images.
- How this compares with a CNAPP
Where a read-only assurance platform stops and where a runtime security platform starts.
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.