Skip to content

Penetration Testing & Vulnerability Scanning

MazeVault Security Assessment Methodology and Vulnerability Management

Document Version: 2.0.0
Last Updated: 2026-10-12

1. Security Assessment Program

MazeVault maintains a comprehensive security assessment program combining automated scanning, manual testing, and continuous monitoring to identify and remediate vulnerabilities proactively.

Assessment Type Frequency Scope
Dependency Vulnerability Scanning Continuous (per build) Go modules (govulncheck), npm packages (npm audit)
Container Image Scanning Per build Docker base and application images
Static Application Security Testing (SAST) Per code change Application source code
Dynamic Application Security Testing (DAST) Monthly Running application endpoints (OWASP ZAP)
Manual Penetration Testing Annual Full platform

2. Testing Scope

In Scope

Component Test Categories
API Server Authentication bypass, authorization escalation, injection, business logic
Web Interface XSS, CSRF, clickjacking, session management, client-side security
OCSP Responder Protocol compliance, denial of service, response manipulation
Database Layer SQL injection, access control, encryption validation
Network Layer TLS configuration, certificate validation, protocol security
Agent Communication mTLS validation, bootstrap flow, key exchange
Dependencies Known CVEs in Go modules, npm packages, Docker base images

Out of Scope

  • Physical security of customer infrastructure
  • Third-party cloud provider infrastructure (Azure, AWS)
  • Customer network configuration
  • Social engineering

Customer testing rules

The Customer must not perform penetration tests, load tests, security scans or similar interventions against the Product without the prior written consent of the Provider or the Partner, unless they take place exclusively in the Customer's own environment and without impact on third-party rights (License Terms, Article III). Performing such tests without consent is an unsupported configuration (see Required Software list).

If the Customer discovers a vulnerability or a security incident, it reports it without delay, no later than 72 hours from identification, to the Partner and to info@mazevault.com, and does not disclose it publicly until remediated (responsible disclosure; License Terms, Article XI).

3. Vulnerability Classification

MazeVault uses CVSS v3.1 and the three severity bands consistent with the legal documentation — the Technical Support and Product Escalation Terms (SLA) and the License Terms:

Severity CVSS Provider's target fix release Customer's deadline to apply the patch
Critical ≥ 9.0 or access to Security Assets within 48 hours within 7 calendar days
High 7.0–8.9 within 7 days within 30 calendar days
Medium / low < 7.0 per the release cycle, no later than 90 days in the next planned window, no later than 90 days

Binding nature and source of the deadlines

The Provider's target fix release is a best-effort target, not a fixed defect-removal deadline (SLA, Art. 8.1 and 10.2). Binding on the Customer are the patch-application deadlines under the License Terms (Art. V) and the Required Software list. For an actively exploited vulnerability, the Provider starts emergency response without delay and within 4 hours provides the Partner with early warning and available mitigations (SLA, Art. 10.2). Regulated entities (NIS2, DORA, the Cybersecurity Act) may be subject to stricter statutory deadlines that take precedence.

4. Reporting and Remediation

MazeVault tracks every identified vulnerability and remediates it according to the deadlines defined in Section 3. Verified fixes are delivered through the standard release process, and security-relevant changes are summarized in the product release notes.

Detailed vulnerability assessment reports, penetration test summaries, and remediation attestations are available to customers and prospects on request, under a non-disclosure agreement. To request current security documentation, contact your MazeVault representative.

MazeVault does not publish live vulnerability counts, specific advisory identifiers, or unremediated findings in public documentation. This protects customers by avoiding disclosure of exploitable detail while an issue is being addressed.

5. Continuous Security Monitoring

Automated Scanning Tools

Tool Purpose Frequency
Trivy Container image and filesystem CVE scanning Per build, all CI events
govulncheck Go dependency vulnerability checking with call-graph analysis Per build
npm audit Frontend and SDK dependency vulnerability checking Per build
OWASP ZAP Dynamic application scanning Periodic

Security Objectives

MazeVault operates to the following standing objectives, measured internally and reviewed on an ongoing basis:

  • Remediate Critical and High dependency and container vulnerabilities within the deadlines defined in Section 3.
  • Maintain zero known, unremediated Critical/High vulnerabilities in shipped artifacts.
  • Run the full automated security pipeline on every build.

CI/CD Security Pipeline

Security scanning is integrated into the CI/CD pipeline and runs on every event (push, pull request, manual dispatch):

  1. Source code scanning — Trivy filesystem scan for known CVEs
  2. Go vulnerability analysis — govulncheck with call-graph analysis (fewer false positives than pattern matching)
  3. npm dependency audit — npm audit for frontend and SDK packages
  4. Container image scanning — Trivy image scan after Docker build