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 (High Baseline)

Guardimesh's DaemonSet architecture directly addresses the FedRAMP High baseline requirement for malware scanning at system entry and exit points. In a Kubernetes cluster, the "entry point" is the node where container images are pulled and instantiated — and Guardimesh runs a scanner on every node, scanning each container as it arrives.

Control	Title	How Guardimesh Satisfies It
SI-3	Malicious Code Protection	ClamAV-based scanning on every node where containers are deployed. Scans at the point of entry (the node), not just in a registry or pipeline. Real-time fanotify monitoring detects malware written after initial deployment.
SI-3(1)	Central Management	Centralized scan configuration, signature management, and reporting via the web console. Policies propagate to all nodes automatically through remote config polling.
SI-3(2)	Automatic Updates	Signature databases are updated automatically every 12 hours from the on-cluster cvdupdate mirror, with no manual intervention required.
SI-4	System Monitoring	Continuous monitoring of container writable layers for new file writes (fanotify), executable drift detection, memfd fileless payload scanning, and deleted binary/library detection. All findings are reported to a central dashboard with alerting.
SI-4(2)	Automated Tools and Mechanisms for Real-Time Analysis	Real-time file monitoring via the Linux fanotify API detects and scans new files as they are written inside containers — not on a polling interval, but at write time.
SI-4(5)	System-Generated Alerts	Configurable alerting via PagerDuty, Slack, email, Jira, and ServiceNow when threats are detected. Detection actions can automatically quarantine affected pods.
SI-7	Software, Firmware, and Information Integrity	Executable drift detection identifies binaries that appear after container startup, flagging unauthorized modifications to the container image.
AU-2	Audit Events	Every container creation, scan result, and signature update is logged with timestamps and retained for up to 180 days (tier-dependent).
SC-8	Transmission Confidentiality and Integrity	All scanner-to-backend communication uses TLS 1.2+ with FIPS 140-3 approved cipher suites when FIPS mode is active.
SC-13	Cryptographic Protection	AES-256-GCM encryption for forensic checkpoint archives. Go's FIPS 140-3 certified cryptographic module (CMVP Certificate #5247).

Why Node-Level Scanning Matters for FedRAMP

NIST SP 800-53 SI-3 requires malicious code protection "at system entry and exit points." In a Kubernetes environment:

Registry scanning catches known malware before deployment, but cannot detect threats introduced at runtime (supply chain compromise, in-memory payloads, post-deployment file writes).
Pipeline scanning runs once at build time and misses runtime mutations entirely.
Node-level scanning (Guardimesh's approach) scans containers on the node where they are pulled and instantiated — the actual system entry point. The DaemonSet ensures every node in the cluster has a scanner, with no gaps.

This architecture satisfies the "entry and exit points" language because the scanner operates at the boundary where external container images enter the cluster's runtime environment.

NIST SP 800-53

Guardimesh maps to the following NIST SP 800-53 Rev. 5 controls:

Control	Title	Coverage
SI-3	Malicious Code Protection	Node-level ClamAV scanning at system entry points, real-time monitoring, automated signature updates
SI-3(1)	Central Management	Web console provides centralized policy, signature, and reporting management
SI-3(2)	Automatic Updates	12-hour signature update cycle via on-cluster mirror
SI-4	System Monitoring	Continuous container monitoring via pod watching, fanotify, drift detection, and memfd scanning
SI-4(2)	Real-Time Analysis	fanotify-based real-time file monitoring at write time
SI-4(5)	System-Generated Alerts	PagerDuty, Slack, email, Jira, ServiceNow integrations
SI-7	Software and Information Integrity	Executable drift detection flags post-startup binary modifications
AU-2	Audit Events	Full audit trail of container events, scans, and findings
AU-6	Audit Record Review	Web console dashboard with filtering, search, and exportable reports
SC-8	Transmission Confidentiality	TLS 1.2+ for all external communication
SC-13	Cryptographic Protection	FIPS 140-3 certified Go cryptographic module, AES-256-GCM
SC-28	Protection of Information at Rest	Encrypted checkpoint archives, encrypted scan data in BigQuery

NIST SP 800-190 (Container Security)

NIST SP 800-190 provides container-specific security guidance. Guardimesh addresses:

Recommendation	Section	How Guardimesh Addresses It
Use container-specific vulnerability management	4.1	Runtime ClamAV scanning of container filesystems, not just image layers
Monitor container runtime for anomalies	4.3	fanotify real-time monitoring, executable drift detection, memfd scanning
Use DaemonSets for security tooling	4.3.4	Scanner deploys as a DaemonSet — one scanner per node, no gaps
Protect data in containers	4.4	Read-only scanning; file contents never leave the node

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 (High Baseline)​

Why Node-Level Scanning Matters for FedRAMP​

NIST SP 800-53​

NIST SP 800-190 (Container Security)​

Vulnerability Disclosure​

Third-Party Dependencies​

Scanner Components​

Infrastructure​

Security FAQ​

Next Steps​