This page describes the ZVM Labs security policy, allowed testing boundaries, site security model, and responsible reporting process.

Short Version

  • ZVM Labs is a static Hugo site with no accounts, payments, comments, or private dashboards.
  • Feedback uses mailto: and does not store messages in a website database.
  • The site uses security headers, security.txt, and a minimal set of external services.
  • Aggressive scanning, exploitation, brute force, social engineering, and disruption are prohibited.
  • Security reports are accepted at [email protected].

Scope

In scope:

  • the primary domain zvm.uk;
  • pages, assets, and static files published by this repository;
  • /.well-known/security.txt;
  • the feedback flow that opens the user’s email client.

Out of scope:

  • third-party platforms linked from the site: GitHub, LinkedIn, Discord, X, Bluesky, Mastodon, TryHackMe, HackTheBox, pwn.college, Telegram, Facebook;
  • email provider, hosting provider, DNS provider, or analytics provider infrastructure unless the issue is caused by ZVM Labs configuration;
  • the author’s profiles on external services when they are not part of this site.

Allowed Testing

Allowed:

  • passive review of public HTML, CSS, JS, headers, and security.txt;
  • checking for broken links, mixed content, incorrect security headers, or privacy disclosure gaps;
  • non-invasive checks of CSP, referrer policy, clickjacking protections, and static asset exposure;
  • reporting a vulnerability without exploiting real users or third-party services.

Prohibited Activity

Prohibited:

  • DoS/DDoS, load testing, aggressive scanning, or fuzzing against production;
  • exploitation, persistence, privilege escalation, or attempts at unauthorized access;
  • phishing, social engineering, or attacks against email/social accounts;
  • credential stuffing, brute force, or password spraying;
  • attempts to obtain, modify, delete, or publish third-party data;
  • public disclosure of a potential vulnerability before coordination.

If you are unsure whether an action is allowed, contact [email protected] first.

Reporting Process

Send reports to [email protected] with this subject:

1

Security report - zvm.uk - [short summary]

Please include:

  • affected URL or asset;
  • short risk description;
  • reproduction steps without destructive actions;
  • browser, tool version, or request sample where relevant;
  • impact and suggested remediation;
  • whether you want attribution after remediation.

Do not send passwords, private keys, tokens, session cookies, personal data, or confidential third-party data. If a sensitive artifact is required to explain the issue, first coordinate a safe transfer method.

Response Expectations

ZVM Labs is a personal blog, so response time is not guaranteed like in a commercial bug bounty program.

Target expectations:

  • initial report review - where possible within 7 days;
  • scope or impact clarification - depending on complexity;
  • remediation - depending on risk, author availability, and technical complexity.

ZVM Labs is not a bug bounty program and does not guarantee rewards for reports.

Site Security Model

Architecture model:

  • static Hugo build;
  • no server-side login flow, comments, payments, or user-generated content storage;
  • feedback is implemented through mailto:;
  • search uses a generated JSON index;
  • page view counter uses GoatCounter for aggregated article view statistics;
  • public profiles and social links point to external platforms.

Main risks:

  • supply chain risk in theme, build tooling, assets, and external scripts;
  • CSP or security header mistakes;
  • DNS/hosting/email compromise outside the site code;
  • accidental disclosure in posts, screenshots, code snippets, or feedback;
  • outdated legal/privacy/security disclosures.

Current controls:

  • security headers in static/_headers;
  • security.txt with contact and canonical policy;
  • CI script scripts/security-check.sh for checking the build, security.txt, headers, CSP, PWA files, offline cache, and basic secret patterns;
  • privacy/legal/security pages;
  • editorial checklist for disclosures, secrets, personal data, and security scope;
  • minimal functionality: no accounts, payments, comments, or server-side form storage.

Headers and CSP

The site uses HSTS, nosniff, frame denial, referrer policy, permissions policy, and CSP.

The current CSP still keeps unsafe-inline because the theme and local Hugo templates still use inline scripts for theme toggle, navigation behavior, visual theme control, PWA install prompt, service worker registration, feedback mailto handling, and GoatCounter integration. This is a temporary exception tracked in docs/csp-hardening-backlog.md.

Security CI does not allow unsafe-eval, wildcard CSP sources, or missing core directives. If unsafe-inline remains in the policy, the backlog must exist and define exit criteria.

Preferred next step:

  • move local inline scripts into an asset bundle;
  • minimize theme inline JavaScript;
  • switch to hash-based or nonce-compatible CSP if the hosting pipeline supports it;
  • reduce script-src to self and explicitly allowed external sources without unsafe-inline.

Security CI

The scripts/security-check.sh script runs:

  • production Hugo build with --panicOnWarning;
  • security.txt validation, including Expires, Policy, and Canonical;
  • required security header checks in static/_headers;
  • CSP directive checks, with unsafe-eval and wildcard sources blocked;
  • validation that unsafe-inline is tracked in the CSP backlog;
  • PWA manifest, service worker, and key offline page checks;
  • lightweight scanning for common secret patterns in the repository.

This script runs in GitHub Actions through .github/workflows/site-security.yml.

Analytics and Third-Party Scripts

GoatCounter is used for privacy-friendly aggregated article view statistics, not advertising or behavioral profiling.

Future hardening options:

  • self-host GoatCounter;
  • or disable the external script and rely on server-side logs;
  • or keep GoatCounter while regularly reviewing CSP, privacy notice, and dependency behavior.

Security Labels for Posts

Cybersecurity posts may include security labels in front matter:

1
2
3
4

security:
  scope: "Lab only"
  intent: "Educational / defensive"
  disclosure: "No real targets"

These labels help readers quickly understand the material boundary: lab, defensive, conceptual, responsible disclosure, or no exploit details.

Last updated: June 5, 2026.