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 global and Japanese domestic frameworks:

ISMAP (Information System Security Management and Assessment Program)

For Japanese public sector and enterprise environments, ISMAP is the centralized framework for assessing the security of cloud service providers. Because ISMAP inherits the technical controls of ISO 27001 and NIST SP 800-53, Guardimesh's node-level malware scanning inherently satisfies its strict Operations Security requirements. Guardimesh provides active malware defense mechanisms and intercepts malicious code at cluster entry points.

Common Standards for Information Security Measures for Government Agencies (政府機関等の情報セキュリティ対策のための統一基準)

Established by NISC, this framework dictates the baseline security rules for all Japanese government ministries. Guardimesh directly addresses Section 6.2.2 (Measures for protection against malware) by deploying technological measures to detect, isolate, and prevent malicious software across containerized information systems and web traffic at the point of ingress.

ISO/IEC 27001 (JIS Q 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)

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

PCI DSS v4.0

Guardimesh satisfies Requirement 5 of the Payment Card Industry Data Security Standard (PCI DSS v4.0), which mandates the protection of all systems against malware. By running advanced malware protection mechanisms with "detect and respond" capabilities at network entry points (container ingestion on nodes), it prevents malware from reaching the Cardholder Data Environment (CDE).

US Federal Frameworks (FedRAMP High & DoD CMMC)

(Note for translators: Keep this section as it demonstrates global security rigor)

Guardimesh's DaemonSet architecture directly addresses US federal baseline requirements (such as NIST SP 800-53 SI-3) for malware scanning at system entry and exit points. By scanning containers on the node where images are pulled and instantiated, Guardimesh satisfies both FedRAMP High and DoD CMMC requirements for malicious code protection.

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