- finding
- Container admitted in privileged mode
- resource
- prod/api-gateway · Deployment · containers[0]
- detected
- kubescape 3.0 · trivy 0.58 · scan #218
- control
- CIS 5.2.1 · NIS2 21(2)(g)
- owner
- platform vendor · due 12 Aug 2026
- history
- open · 12 Jul → assigned · 14 Jul → fixed · 02 Aug → verified · 14 Aug, rescan #241
Independent container security assurance
Your vendor says it's fixed. We keep the receipt.
QubeAuditor audits the Kubernetes clusters, Azure container services and AWS ECS estates your provider operates — then gives every finding an accountable owner, re-tests it on the next scan, and keeps the evidence an auditor will ask for.
- Kubernetes
- Azure Container Apps
- Container Instances
- Session Pools
- AWS ECS · ECR
- Azure & AWS accounts
An illustrative record. Every field shown here is one the platform actually stores.
The gap
A report written by the vendor you are assessing is not evidence.
In most outsourced estates, the security reporting is produced by the same party that operates the infrastructure. That is a status update, not an audit. Three things go missing.
Nobody owns the finding
A list of problems does not say which supplier is accountable, what the deadline is, or what happens when the deadline passes. Ownership is where remediation actually starts.
Nobody re-tests the fix
"Resolved" usually means somebody closed a ticket. Unless the next scan looks for the same finding by a stable identity, a fix that quietly regresses looks exactly like a fix that held.
Nothing survives the audit
Screenshots and exported spreadsheets are not traceable evidence. An auditor asks what was assessed, by which tool at which version, what failed, what was accepted, and what was never assessed at all.
Scope
Six scanner paths, four kinds of estate, one finding model.
QubeAuditor orchestrates proven engines rather than competing with them. Everything they return is normalised into a single finding model with a deterministic identity, so the same problem in the same place stays the same record across rescans.
Trivy · Kubescape · Polaris · kube-score · Prowler · native checks
- engines
- kube-score manifest analysis · Polaris live-cluster audit · Kubescape posture · Trivy vulnerability, misconfiguration and CIS assessment
- native
- 13 RBAC posture checks · 7 NetworkPolicy posture checks
- optional
- SOC 2 and MITRE ATT&CK framework scans through Kubescape
- access
- kubeconfig or in-cluster agent · read-only
- services
- Container Apps · Container App Environments · Container Instances · Dynamic Session Pools
- checks
- identity, network exposure, TLS, logging, secret handling and supply-chain posture
- registry
- image provenance, with optional image vulnerability scanning
- why
- these services sit outside the AKS-shaped coverage most tooling assumes
- checks
- ECS services, task definitions, containers, load balancers, IAM, logging and networking
- catalogue
- 22 AWS Container Assurance Workload controls, aligned to CIS and FSBP
- images
- ECR image scanning through Trivy
- access
- cross-account role assumption with an ExternalId · read-only
- azure
- subscription posture assessment
- aws
- account posture assessment
- why
- the identity, logging and encryption posture underneath the containers is where several NIS2 measures are actually evidenced
Lifecycle
A finding has a life, not just a severity.
Findings carry a deterministic key, so a rescan recognises them. From there they move through states that mean something commercially — each transition, comment and decision kept in the record.
- open
- Detected and unassigned. The clock has not started.
- assigned
- An owner and a vendor, with a due date set by the per-severity SLA policy. Breaches are detected, not hoped about.
- fixed
- The finding is no longer present in the estate.
- fixed · verified
- A later scan looked for this exact finding and did not find it. This is the state that is worth paying for.
- reopened · regressed
- It came back. The history says when, and after which scan.
- accepted risk
- Signed off with a written rationale and an expiry date. An exception, not a permanent mute.
- false positive
- Recorded with a reason and kept in history rather than deleted.
Severity can be overridden with a written rationale. Acceptance policies apply per target, with administrative override. Bulk actions exist so a real backlog is workable.
Verification
The scan that matters is the second one.
Two scans, compared: what is new, what is resolved, what came back. Everything else on this page exists to make this comparison possible.
- finding
- Container admitted in privileged mode
- resource
- prod/api-gateway · Deployment
- owner
- platform vendor · due 12 Aug 2026
- finding
- Not present — looked for by finding key
- resource
- prod/api-gateway · Deployment
- verdict
- closure verified against scan #218
- New
- Findings this scan raised for the first time.
- Resolved
- Findings the previous scan raised that are now gone.
- Regressed
- Findings that were closed and have returned.
Vendor scorecards are built from this: SLA breaches, verified-fix rate, and how often work regresses after handover.
Compliance
We show you the gaps in our own coverage.
Findings map to CIS Kubernetes, NSA/CISA Kubernetes hardening, PCI DSS, CIS Azure, AWS container security aligned to CIS and FSBP, NIS2 Article 21, and — through Kubescape — SOC 2 and MITRE ATT&CK. Every one of them is labelled partial, because every one of them is partial.
NIS2 Article 21(2) — where technical evidence exists
| Measure | Kubernetes | Azure | AWS |
|---|---|---|---|
| 21.2(a)Risk analysis and information system security policiesunassessed | no control mapped | no control mapped | no control mapped |
| 21.2(b)Incident handling | no control mapped | evidenced | evidenced |
| 21.2(c)Business continuity, backup management and disaster recoveryunassessed | no control mapped | no control mapped | no control mapped |
| 21.2(d)Supply chain security | no control mapped | evidenced | evidenced |
| 21.2(e)Security in acquisition, development and maintenance | evidenced | evidenced | evidenced |
| 21.2(f)Effectiveness of cybersecurity risk-management measures | evidenced | evidenced | evidenced |
| 21.2(g)Basic cyber hygiene and cybersecurity trainingpartial | evidenced | evidenced | evidenced |
| 21.2(h)Cryptography and encryption | no control mapped | evidenced | evidenced |
| 21.2(i)HR security, access control policies and asset managementpartial | evidenced | evidenced | evidenced |
| 21.2(j)Multi-factor authentication and secure communicationspartial | no control mapped | evidenced | evidenced |
- A control at this scope evidences the measure
- No control mapped at this scope
- partial
- Technical evidence exists, but part of the measure is organisational and stays outside scanner reach
- unassessed
- No control at any scope — always reported as not assessed
Two of the ten measures have no scanner signal at all: risk analysis (a), and business continuity, backup and disaster recovery (c). They stay unassessed rather than being quietly counted as passes. Several others are partial by nature — training, HR security and end-to-end MFA are organisational controls that posture scanning cannot observe.
No scanner can certify NIS2 compliance, and QubeAuditor does not claim to. What it produces is traceable technical evidence for the measures it can actually evidence, and an explicit statement of the ones it cannot.
Deliverables
What you actually hand over.
Every artifact is generated from the same scan state, so the executive deck and the technical assessment cannot disagree with each other.
Technical assessment
DOCXFinding by finding, enriched from a remediation knowledge base with concrete fix guidance for the exact resource.
Executive presentation
PPTXPosture, top risks, compliance position, and what changed since the previous assessment.
Evidence pack
ZIPA manifest, a SHA-256 for every stored artifact, and an explicit list of anything that is missing. The missing list is the point.
Machine-readable exports
CSV · JSONFor ticketing systems, dashboards and pipeline gates.
Customers also get a scoped portal: their findings, their compliance view, their vendors, their analytics — and nobody else's.
AI drafts
AI that tells you what it did not see.
Guided remediation drafts a fix for a finding from the evidence the scan actually captured. It produces a document for a human to review — not an action, and not a promise about configuration it never read.
It never runs anything
There is no Run button and no automatic application. A draft is downloaded as Markdown, reviewed, and applied by whoever owns the change, through whatever process they already use.
It is graded by evidence
Where the scan captured the manifest, you get an exact RFC 6902 JSON Patch with test preconditions. Where it did not — which is most cloud resources — you get a clearly labelled manual draft that says the live configuration was not inspected. Where neither holds, you get guidance and nothing more.
Secrets never reach the model
Secrets, credentials, tokens, connection strings, environment values, full manifests and raw scanner payloads are excluded by construction. If any is detected, the call is aborted rather than sanitised and sent.
EU region, platform operated
One platform-managed provider in an EU region, on a managed identity. Customers configure no model connection, the feature is off for a tenant until it is explicitly enabled, and every generation is recorded.
Operating model
Read-only access. Your environment. Your evidence.
The control plane and the evidence store run inside the customer environment. Assessment is read-only by design — temporary credentials, managed identity, or a cross-account role — and the agent has no remediation path at all.
You operate it
Your platform team runs the deployment and the agents. We onboard, hand over the runbooks, and stay available for the assessment cycle.
Your MSP operates it
Your provider — or a different one, if independence matters — runs it across their client base from one administrative tenancy, with reports branded as theirs.
We operate it
Shandoola runs the deployment, the scan cadence, the triage and the vendor follow-up as a managed service. You consume the outcome.
Microsoft Entra ID SSO · per-customer API keys · HMAC-signed webhooks to Slack, Teams or your own receiver · agent heartbeat, version and stale-target alerting · encrypted SMTP and webhook secrets · audit events on sensitive operations.
The offer
Start with one estate and a fixed scope.
The first engagement is a Vendor Container Assurance Baseline: bounded, deliverable-led, and designed to prove the whole loop before anything recurring is discussed.
What a baseline includes
- Onboarding and read-only access design
- One environment and an agreed target scope
- Baseline scan and control review
- Vendor attribution workshop
- Technical assessment and executive presentation
- Evidence pack
- One verification rescan within 30–45 days
If it works, it converts into managed assurance on a monthly or quarterly cadence — operated by you, by your MSP, or by us. Pricing is set against the estate, the cadence and how much of the work we run; ask and we will scope it.
Book a baseline assessmentQuestions
Questions we get asked
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.