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, 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;
  • 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, feedback mailto handling, and GoatCounter integration. This is a known hardening backlog.

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.

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.