Security and Compliance

This page describes Guardimesh's security model, data handling practices, and compliance posture. It is intended for security teams evaluating Guardimesh for deployment in their environment.

Data Handling

What Data Leaves Your Cluster

Guardimesh transmits only scan metadata to the SaaS backend. Specifically:

Data Transmitted	Example
Pod name	`web-app-7d8f9c6b4-x2k9p`
Namespace	`production`
Container ID	`abc123def456...`
Image name	`nginx:1.25`
Node name	`worker-node-3`
Cluster ID	`prod-us-east-1`
Pod/Host IP addresses	`10.244.0.42`, `10.0.1.15`
Scan findings (signature name, file path)	`Trojan.Linux.Generic`, `/var/tmp/payload.bin`
Timestamps	`2026-05-26T10:30:00Z`

What Is Never Transmitted

File contents (application data, configs, secrets)
Environment variables
Kubernetes Secrets or ConfigMaps
Container logs (stdout/stderr)
Network traffic or packet captures
Application source code

The scanner reads file contents only to pass them to the local ClamAV daemon via a Unix socket on the same node. File content never leaves the pod, let alone the cluster.

Data at Rest

Component	Storage	Encryption
Scan results (SaaS)	Google BigQuery	AES-256 (Google-managed keys)
User accounts	Google Firestore	AES-256 (Google-managed keys)
Session data	Firestore or PostgreSQL	AES-256
Signature files	Google Cloud Storage	AES-256
Scan results (air-gap)	PostgreSQL	Encryption depends on storage layer

Data in Transit

All communication between the scanner and the Guardimesh backend is encrypted with TLS 1.2+.

Path	Protocol	Certificate
Scanner → backend-api	HTTPS (TLS 1.2+)	Public CA (Let's Encrypt)
Puller → storage-access	HTTPS (TLS 1.2+)	Public CA
Web console → browser	HTTPS (TLS 1.2+)	Public CA
Intra-cluster (air-gap mode)	HTTP	Not encrypted (in-cluster only)

For environments with TLS inspection proxies, customers can provide a custom CA certificate via scanner.saas.tls.caSecret.

Data Retention

Tier	Retention Period
Trial	14 days
Individual	90 days
Startup	90 days
Team	180 days
Enterprise	Custom (negotiable)

After the retention period, scan results are permanently deleted from BigQuery. Deletion is automated and cannot be reversed.

Customers can request early deletion of all their data by contacting support.

Authentication and Access Control

Scanner Authentication

Scanners authenticate to the backend using API keys:

Keys are generated in the web console and stored as Kubernetes Secrets
Each key is a bearer token sent in the Authorization header
Keys can be revoked immediately from the console
Multiple keys are supported (2–5 depending on tier, unlimited for Enterprise)

User Authentication

The web console supports:

Email + password with bcrypt hashing
Google OAuth 2.0
GitHub OAuth 2.0
GitLab OAuth 2.0
TOTP two-factor authentication

OAuth tokens are used only during the login flow to verify identity. They are not stored long-term.

Session Security

HTTP-only cookies (not accessible to JavaScript)
Secure flag (HTTPS-only in production)
SameSite attribute (CSRF protection)
Server-side session storage (Firestore or PostgreSQL)
Configurable session expiry (default: 7 days)

Cluster RBAC Requirements

Scanner ClusterRole

The scanner requires the following Kubernetes permissions:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: guardimesh-scanner
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list"]
  - apiGroups: [""]
    resources: ["namespaces"]
    verbs: ["get", "list"]

Why these permissions:

Permission	Justification
pods: get, list, watch	Monitor pod lifecycle events for active scanning triggers
nodes: get, list	Report node metadata and validate against node limits
namespaces: get, list	Evaluate namespace skip rules

The scanner does not require write access to any Kubernetes resources. It operates in a read-only mode with respect to the Kubernetes API.

Privileged Security Context

The scanner container requires:

Capability	Justification
`privileged: true`	Access host filesystem overlay layers for container scanning
`hostPID: true`	Read `/proc/[pid]/exe` and `/proc/[pid]/fd` for deleted binary and memfd detection
`hostPath: /` mounted at `/host`	Access container writable layers (upperdir) on the host filesystem

These privileges are limited to the scanner and inspector containers only. The antivirus, puller, and obfuscation scanner containers run unprivileged.

Network Security

Minimal Attack Surface

No inbound ports exposed to the internet
Scanner pods do not accept incoming connections
Backend communication is outbound-only from the cluster
Web console access is optional (not required for scanning to operate)

Network Policy Compatibility

Guardimesh works with Kubernetes NetworkPolicies. Required egress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: guardimesh-egress
  namespace: guardimesh-system
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: guardimesh-scanner
  policyTypes:
    - Egress
  egress:
    # Backend API
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
      ports:
        - port: 443
          protocol: TCP
    # Kubernetes API
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
      ports:
        - port: 6443
          protocol: TCP
    # DNS
    - to: []
      ports:
        - port: 53
          protocol: UDP
        - port: 53
          protocol: TCP

Abuse Prevention

Registration Security

Account registration is protected by multiple layers:

Layer	Protection
reCAPTCHA Enterprise	Bot/spam filtering
IP rate limiting	5 registrations/hour, 10/day per IP
Per-email activation limiting	Max 3 activation attempts with escalating cooldowns
Multi-account detection	Blocks IPs creating 3+ accounts
IP audit logging	90-day forensic trail of registration events

API Rate Limiting

All API endpoints are rate-limited per tier to prevent abuse. See Subscription Tiers for specific limits.

Compliance Frameworks

Guardimesh is designed to support compliance with the following frameworks:

SOC 2 Type II

Guardimesh supports SOC 2 compliance through:

Encryption of all data in transit and at rest
Access controls with audit logging
Automated scanning provides continuous monitoring evidence
Data retention policies aligned with control requirements
Incident detection and notification capabilities

ISO 27001

Relevant controls supported:

A.12.2 — Protection from malware (runtime scanning)
A.12.4 — Logging and monitoring (scan results, pod logs, audit trails)
A.13.1 — Network security management (TLS, minimal attack surface)
A.14.2 — Security in development processes (container image drift detection)

FedRAMP

Guardimesh addresses FedRAMP control families:

SI-3 — Malicious Code Protection
SI-4 — Information System Monitoring
AU-2 — Audit Events
SC-8 — Transmission Confidentiality and Integrity

NIST 800-53

Relevant controls:

SI-3: Malicious Code Protection
SI-4: System Monitoring
SI-7: Software, Firmware, and Information Integrity
AU-6: Audit Record Review, Analysis, and Reporting

Vulnerability Disclosure

If you discover a security vulnerability in Guardimesh, please report it to security@guardimesh.com. We commit to:

Acknowledging receipt within 24 hours
Providing an initial assessment within 72 hours
Coordinating disclosure timeline with the reporter

Third-Party Dependencies

Scanner Components

Component	Source	License
ClamAV	Cisco Talos	GPL-2.0
ClamAV signatures (official)	Cisco Talos	Proprietary (free for use)
Sanesecurity signatures	Sanesecurity	Free for personal/business use
YARA	VirusTotal	BSD-3-Clause

Infrastructure

Service	Provider	Certification
Compute (Cloud Run)	Google Cloud	SOC 1/2/3, ISO 27001, FedRAMP
Data warehouse (BigQuery)	Google Cloud	SOC 1/2/3, ISO 27001, FedRAMP
Database (Firestore)	Google Cloud	SOC 1/2/3, ISO 27001, FedRAMP
Secrets (Secret Manager)	Google Cloud	SOC 1/2/3, ISO 27001, FedRAMP
Container registry (Quay.io)	Red Hat	SOC 2

Security FAQ

Q: Can Guardimesh modify or delete files in my containers? A: No. The scanner operates in read-only mode. It reads files to scan them but never writes, modifies, or deletes any data in your containers or on the host filesystem.

Q: Can Guardimesh access my application secrets? A: No. The scanner does not read Kubernetes Secrets, ConfigMaps, or environment variables from other pods. It only accesses the container filesystem overlay to scan file contents locally.

Q: What happens if the SaaS backend is unavailable? A: Scanners continue to detect threats locally. Results are buffered in memory (up to 1000 entries) and retried with exponential backoff when connectivity is restored. Scanning never stops due to backend unavailability.

Q: Is my data shared with other customers? A: No. All data is isolated per customer account. BigQuery datasets are partitioned by customer. There is no shared tenancy for scan data.

Q: Can Guardimesh employees access my scan data? A: Access to customer data is restricted to authorized personnel for support purposes only, subject to audit logging and access controls.

Next Steps

Architecture — Understand the full system design
Air-Gap Deployment — Deploy without internet access
Subscription Tiers — Retention and limits by plan

Data Handling​

What Data Leaves Your Cluster​

What Is Never Transmitted​

Data at Rest​

Data in Transit​

Data Retention​

Authentication and Access Control​

Scanner Authentication​

User Authentication​

Session Security​

Cluster RBAC Requirements​

Scanner ClusterRole​

Privileged Security Context​

Network Security​

Minimal Attack Surface​

Network Policy Compatibility​

Abuse Prevention​

Registration Security​

API Rate Limiting​

Compliance Frameworks​

SOC 2 Type II​

ISO 27001​

FedRAMP​

NIST 800-53​

Vulnerability Disclosure​

Third-Party Dependencies​

Scanner Components​

Infrastructure​

Security FAQ​

Next Steps​