Skip to main content
Kliper handles sensitive compliance evidence — firewall configurations, access control policies, network diagrams, cardholder data flow documentation. The platform enforces a multi-layered security pipeline on every uploaded file and provides clear boundaries around how AI processes your data.

​
File Integrity — SHA-256 Hashing

Every file uploaded to Kliper is cryptographically hashed using SHA-256 at the moment of upload, before it is written to storage.

​
How It Works

  1. The file buffer is received in memory via the upload endpoint.
  2. A SHA-256 hash is computed immediately using Node.js crypto.createHash('sha256').
  3. The resulting 64-character lowercase hex digest is stored alongside the file record in the database (hash_sha256 column).
  4. The file is then written to encrypted storage (Supabase Storage / S3).

​
On-Demand Integrity Verification

At any point after upload, an authorized user can trigger an integrity verification check via the Verify action. The platform:
  1. Re-downloads the file from storage.
  2. Recomputes the SHA-256 hash of the downloaded content.
  3. Compares the recomputed hash against the stored original.
  4. Records the result (verified or tampered) along with a timestamp in the file’s metadata.
This guarantees that evidence has not been altered in storage — a critical requirement for audit trail credibility during PCI DSS assessments.
Integrity verification is non-destructive and read-only. It does not modify the file. The verification timestamp is recorded in the file’s metadata for audit purposes.

​
What the Assessor Sees

FieldValue
Stored Hasha3f2b8c1d4e5... (64-char hex)
Current HashRecomputed on verification
Integrity StatusVerified or Tampered
Verified AtISO 8601 timestamp

​
Malware Scanning — Dual-Engine Pipeline

Every file passes through a dual-engine malware scanning pipeline before it is accepted into the platform. No file reaches an assessor’s workbench without being scanned.

​
Scan Pipeline

The pipeline runs three checks in sequence, plus two scanners in parallel:
1

Static Analysis

Before any scanning, the file undergoes static validation:
  • MIME type check — blocked types include executables (.exe, .dll), scripts (.bat, .sh, .ps1), Java archives (.jar, .class), and 30+ other dangerous MIME types.
  • Extension check — 40+ blocked extensions including .exe, .dll, .bat, .cmd, .vbs, .ps1, .msi, .scr, .lnk, .hta, and more.
  • Magic bytes inspection — the first bytes of the file are compared against known executable signatures (PE/MZ headers, ELF binaries, Mach-O binaries, Java class files). This catches files that have been renamed with a safe extension but contain executable content.
  • MIME mismatch detection — warns when the declared MIME type does not match the file’s actual content signature.
Files that fail static analysis are immediately rejected with a 422 status and a quarantined scan status. They are never written to storage.
2

ClamAV Antivirus Scan

The file is written to a secure temporary location and scanned by ClamAV (clamdscan) with a 30-second timeout. ClamAV is an open-source antivirus engine with regularly updated virus definitions.
  • Clean result — no threats detected.
  • Infected result — one or more virus signatures identified. The specific virus names are captured and stored.
  • Error result — scanner unavailable (logged as a warning; does not block upload if VirusTotal is available).
3

VirusTotal Hash Lookup

In parallel with ClamAV, the file’s SHA-256 hash is checked against the VirusTotal database via API. This cross-references the file against 70+ antivirus engines without uploading the file itself — only the hash is sent.
  • Clean result — 0/N engines flagged the hash.
  • Infected result — one or more engines flagged the hash. Detection count, engine names, and threat names are recorded.
  • Not found — hash not in VirusTotal’s database (file has never been scanned globally). This is treated as clean — absence of evidence is not evidence of malice.

​
Scan Statuses

StatusMeaning
cleanFile passed all scan engines with no detections.
quarantinedFile was blocked by static analysis or flagged by one or more scan engines. File is rejected and not stored.
pendingScan is in progress (brief transitional state).

​
Scan Results Storage

Full scan results are persisted in the scan_result JSON column on the file record. Each engine’s individual result is stored: 
{
  "engines": [
    {
      "name": "ClamAV",
      "status": "clean",
      "detail": "No threats detected"
    },
    {
      "name": "VirusTotal",
      "status": "clean",
      "detail": "0/72 engines flagged",
      "permalink": "https://www.virustotal.com/gui/file/a3f2b8c1...",
      "detections": 0,
      "totalEngines": 72
    }
  ],
  "scanned_at": "2026-02-28T14:30:00.000Z"
}
Assessors can view per-engine scan results directly in the Attachments Panel of the assessment workbench.

​
File Type Restrictions

Kliper accepts common evidence file types and blocks anything that could execute code:
  • Documents — PDF, DOCX, DOC, XLSX, XLS, PPTX, PPT, VSDX
  • Images — PNG, JPG, JPEG, GIF, BMP, TIFF, SVG, WebP
  • Text — TXT, CSV, JSON, XML, YAML, LOG, MD, HTML, SQL, CONF, INI
  • Certificates — PEM, CRT, CER, KEY, PUB, CSR, P12, PFX
  • Archives — ZIP (inspected for Java archives)
  • Logs — EVTX (Windows Event Logs)
  • Executables — .exe, .dll, .com, .scr, .pif, .so, .dylib
  • Scripts — .bat, .cmd, .vbs, .vbe, .js, .jse, .ps1, .sh, .bash, .csh
  • Windows system — .msi, .msp, .mst, .cpl, .hta, .inf, .reg, .scf, .lnk
  • Java — .jar, .class
  • Shell — .ws, .wsf, .wsc, .wsh

​
Automatic Metadata Extraction

On upload, Kliper automatically extracts metadata from supported file types to provide assessors with a preview before opening the file:
File TypeExtracted Metadata
PDFPage count, word count, text preview (first 500 chars), document metadata
Word (DOCX/DOC)Word count, text preview
Excel (XLSX/XLS)Sheet names, row/column counts, header names
PowerPoint (PPTX)Slide count, text preview from first slide
Visio (VSDX)Page count, text labels extracted from diagram elements
CSVColumn headers, row count, first 3 rows as preview
ImagesFormat, file size
Text/Config filesLine count, word count, text preview
Certificates (PEM)Certificate type (certificate, private key, public key, CSR)
This metadata is stored in the file record and displayed in the Attachments Panel, giving assessors immediate context about uploaded evidence without downloading each file.

​
Cortex AI — Privacy and Data Handling

Cortex is Kliper’s built-in AI assistant. It uses OpenAI’s API (model: gpt-4o-mini) to provide PCI DSS guidance, validate evidence, and generate ROC findings text.

​
What Cortex Can Access

Cortex operates within strict boundaries:
  • Assessment context only — Cortex can only see data from the assessment the user is currently working in. It cannot access other assessments, other clients, or other organizations.
  • Requirement-scoped — when invoked on a specific testing procedure, Cortex receives only the relevant reporting instructions, the assessor’s existing responses for that requirement, and the names of uploaded evidence files tagged to that requirement.
  • No raw file content by default — Cortex receives file names and AI-generated summaries of file content, not the raw file contents. The only exception is the Document Validation feature, which sends extracted text content (up to 30,000 characters) to the AI for criteria-based validation.

​
What Cortex Cannot Do

  • Cannot access data across organizations — tenant isolation is enforced at the API level.
  • Cannot store or learn from your data — Kliper uses the OpenAI API with no training on customer data. Your assessment data is not used to train or fine-tune any model.
  • Cannot make assessment decisions — Cortex generates draft text and validation results. The assessor retains full control over all findings, status selections, and the final report content.
  • Cannot modify assessment answers directly — all AI-generated content is presented as suggestions that the assessor must explicitly accept or modify.

​
Data Flow

Assessor invokes Cortex on Requirement 3.4.1
        │
        ▼
Backend builds prompt with:
  • Reporting instructions for 3.4.1
  • PCI DSS guidance (purpose, good practice, definitions)
  • Assessor's existing responses (if any)
  • Evidence file names + AI summaries
  • Selected finding status + methods
        │
        ▼
OpenAI API (gpt-4o-mini, temperature 0.3)
  • No training on your data
  • Processed and discarded per OpenAI's API data policy
        │
        ▼
Response returned to assessor in the UI
  • Assessor reviews, edits, accepts, or discards

​
AI Transparency

Every AI-generated output in Kliper includes:
  • Warnings — if data is missing (e.g., no assessor responses yet, no evidence files uploaded), Cortex explicitly flags what is incomplete rather than fabricating content.
  • Placeholders — for data that does not yet exist, Cortex uses [PENDING_RESPONSE] or [TAG] markers instead of generating plausible-sounding but unverified text.
  • Model attribution — the AI model used and token counts are recorded for every validation and autofill operation.

​
Multi-Tenant Isolation

Kliper enforces strict tenant isolation at every layer:
  • Database — every query is scoped to the user’s current organization via the org_id foreign key. There is no mechanism to query across organizations.
  • Storage — file paths are prefixed with the organization ID. Signed download URLs are scoped per organization.
  • API — the x-organization header is validated on every authenticated request. Requests without a valid organization context are rejected.
  • RBAC — four roles (Admin, Manager, Contributor, Viewer) with fine-grained permissions per resource type and action.

​
Audit Trail

Every state change in Kliper is recorded in the audit log:
  • Who — user ID, name, email.
  • What — action type (created, updated, deleted, reviewed, approved).
  • When — ISO 8601 timestamp.
  • Where — IP address, user agent string.
  • Detail — old value and new value snapshots for data modifications.
Audit logs are immutable and queryable from the Admin Dashboard. They are designed to withstand QSA peer review and PCI Council quality assurance inquiries.