- Container admitted in privileged mode
- prod/api-gateway · Deployment · containers[0]
- kubescape 3.0 · trivy 0.58 · scan #218
- CIS 5.2.1 · NIS2 21(2)(g)
- platform vendor · due 12 Aug 2026
- 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. Every finding gets an accountable owner, a re-test on the next scan, and 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.
QubeAuditor
QubeAuditor is a container security assurance platform. It assesses Kubernetes clusters, Azure container services and AWS ECS estates read-only, gives every finding an accountable vendor and a deadline, re-tests the fix on the next scan, and keeps the evidence an auditor will ask for. It does not do runtime protection, admission control or automatic remediation, and it does not certify compliance with anything.
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. Three things go missing on the way to an audit.
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 only a severity.
Findings carry a deterministic key, so a rescan recognises them. From there they move through states that mean something commercially, and every transition, comment and decision stays 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 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 that 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)nis2Measures.21.2(a)unassessed | no control mapped | no control mapped | no control mapped |
| 21.2(b)nis2Measures.21.2(b) | no control mapped | evidenced | evidenced |
| 21.2(c)nis2Measures.21.2(c)unassessed | no control mapped | no control mapped | no control mapped |
| 21.2(d)nis2Measures.21.2(d) | no control mapped | evidenced | evidenced |
| 21.2(e)nis2Measures.21.2(e) | evidenced | evidenced | evidenced |
| 21.2(f)nis2Measures.21.2(f) | evidenced | evidenced | evidenced |
| 21.2(g)nis2Measures.21.2(g)partial | evidenced | evidenced | evidenced |
| 21.2(h)nis2Measures.21.2(h) | no control mapped | evidenced | evidenced |
| 21.2(i)nis2Measures.21.2(i)partial | evidenced | evidenced | evidenced |
| 21.2(j)nis2Measures.21.2(j)partial | 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, because 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. That missing list is why the pack is worth having.
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 the case for 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, through a temporary credential, a 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 to 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
What is a Kubernetes security audit?
A Kubernetes security audit is a systematic review of cluster configuration, workload settings, RBAC, network policies and container images against a security baseline such as the CIS Kubernetes Benchmark. A useful audit does three things a raw scan does not: it prioritises findings by real risk, it maps them to the control frameworks your auditors work from, and it assigns each one to whoever is accountable for fixing it. QubeAuditor runs the scan, normalises the results, and manages the accountability and verification that follow.
Which scanners does QubeAuditor run?
For Kubernetes it runs six scanner paths: kube-score for manifest best practice, Polaris for live-cluster auditing, Kubescape for posture including optional SOC 2 and MITRE ATT&CK framework scans, Trivy for vulnerabilities, misconfiguration and CIS Kubernetes assessment, plus 13 native RBAC checks and 7 native NetworkPolicy checks written specifically for this platform. Azure and AWS container services are assessed by purpose-built native scanners, and Prowler assesses Azure subscription and AWS account posture. All of it is normalised into one finding model.
Does QubeAuditor make us NIS2 compliant?
No. No scanner can certify NIS2 compliance, and any vendor claiming otherwise is overselling. QubeAuditor produces traceable technical evidence for the NIS2 Article 21(2) measures that container and cloud posture scanning can actually evidence: incident handling, supply chain security, network security, cryptography, access control, basic hygiene and cloud-identity MFA. Two measures, risk analysis (a) and business continuity, backup and disaster recovery (c), have no scanner signal and are reported as unassessed rather than passed. Training, HR security and end-to-end MFA remain organisational controls.
What does QubeAuditor not do?
It does not do runtime or eBPF threat detection, admission control enforcement, automatic remediation, attack-path graphing, SBOM or VEX management, or GCP targets. It does not block anything in production, because assessment is read-only. It is not a CNAPP and does not try to be. If you need runtime prevention or full multi-cloud posture breadth, a platform like Wiz, Prisma Cloud or Defender for Cloud is the better fit, and QubeAuditor is complementary to it rather than a replacement.
What access does QubeAuditor need?
Read-only access, and nothing more. For Kubernetes that is a kubeconfig or an in-cluster agent. For Azure it is a temporary credential or a managed identity. For AWS it is a cross-account role assumed with an ExternalId. The agent implements no remediation path, so it cannot change your environment even if it is compromised. Scope, timing, expected API calls and image-pull behaviour are agreed before onboarding.
Where does the scan data live?
In the primary operating model, the control plane, the PostgreSQL evidence store and the generated artifacts all run inside the customer environment or a deployment the customer controls. Nothing has to leave it. Webhook and SMTP secrets are encrypted with AES-256-GCM, per-customer API keys are stored as bcrypt hashes, and sensitive operations are recorded as audit events.
How is a fix actually verified?
Every finding gets a deterministic key derived from the check and the resource it applies to, so the same problem in the same place is the same record on the next scan. When a later scan runs, the platform looks for that key specifically. If it is gone, the finding moves to fixed and verified. If it returns after being closed, it is marked regressed with the date and the scan that caught it. Scan-to-scan comparison reports new, resolved and regressed findings separately.
Can it audit Azure Container Apps and AWS ECS, not just Kubernetes?
Yes, and that is deliberate. Purpose-built scanners cover Azure Container Apps, Container App Environments, Container Instances and Dynamic Session Pools, services that generic Kubernetes tooling tends to miss because they are not clusters. On AWS, native checks cover ECS services, task definitions, containers, load balancers, IAM, logging and networking, with ECR images scanned through Trivy against 22 catalogued AWS Container Assurance Workload controls.
Why not just run Trivy, Kubescape and Prowler ourselves?
You can, and QubeAuditor runs those same engines. What you would be building yourself is everything after the scan: deduplication into one finding model, stable identity across rescans, owner and vendor assignment, per-severity SLAs and breach detection, accepted-risk with expiry, verified closure, tenant history, and the deliverables an auditor or a board will accept. If your team already maintains that layer and it works, you do not need us.
Does QubeAuditor use AI?
For one bounded thing: drafting remediation for a finding. The draft is a Markdown document a human reviews and applies, with no Run button and no automatic change. Where the scan captured the full manifest, the draft is an exact RFC 6902 JSON Patch with test preconditions. Where it did not, the draft is explicitly labelled as not having inspected live configuration. Secrets, credentials and raw scanner payloads are never sent to the model, the provider is platform-managed in an EU region, and the feature is off for a tenant until it is explicitly enabled.
Read next
- How the platform works
The architecture behind the finding model: scan orchestration, the read-only access design, the agent, and what runs where.
- What NIS2 Article 21 evidence looks like
Which of the ten risk-management measures container scanning can evidence, which are partial, and which stay unassessed.
- QubeAuditor compared with CNAPP platforms and DIY scanners
Where this fits against Wiz, Prisma Cloud and Defender for Cloud, and against running Trivy and Kubescape yourself.
- Running it as a managed service
Multi-tenancy, branded reports and the commercial shape for MSPs and consultancies.
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.