Penetration testing

The first engagement will cover the CMDash Cloud surface:

• Web application. app.cmdash.net — authenticated and unauthenticated user flows, including login, MFA enrolment, password reset, magic link, SAML SSO, SCIM provisioning, and session handling.
• API. api.cmdash.net — all public endpoints, with a specific focus on:
  • tenant isolation (cross-tenant access attempts);
  • role-based access control (privilege escalation);
  • input validation (injection, prototype pollution, SSRF);
  • idempotency and webhook signature verification.
• Control plane. api.cmdash.com — licence issuance and refresh, billing and AWS Marketplace integration, and the partner and catalogue endpoints, with a focus on authentication of every route and on licence-signing integrity.
• Supporting infrastructure. Lightsail load balancer and Caddy edge configuration, TLS posture, CORS policy, security headers.
• External black-box network recon against the production edge, to validate the exposed attack surface matches the intended one.

On-premise customer deployments are not in scope: every customer runs in their own environment and is responsible for their own pen-test programme where contract or policy requires it. We can share our test methodology and tooling with on-prem customers on request.

• Destructive denial-of-service testing against production. Load and resilience testing are covered separately by our internal k6 suite.
• Social-engineering tests against CMDash staff. Planned for a future engagement once the core product surface is cleanly tested.
• Physical tests against cloud infrastructure (inherited from AWS attestation) or CMDash offices.
• Third-party subprocessor infrastructure. Those vendors run their own programmes; we rely on their attestations and publish the current list at /trust/subprocessors.

We are selecting a testing firm with a methodology aligned to the OWASP Application Security Verification Standard (ASVS) Level 2 for application testing, plus OWASP API Security Top 10 coverage for the API. The engagement will combine:

• Grey-box testing, with tester accounts provisioned at Owner, Admin, and Viewer tiers across multiple tenants, so cross-tenant and privilege-escalation paths are exercised first-hand.
• Source-aware review of the authentication, authorisation, and tenant-isolation modules. The tester gets read access to the affected repositories for the engagement window only.
• External black-box recon using only publicly-available information, as a control check.

Findings will be rated using CVSS v3.1 and categorised against OWASP Top 10 / OWASP API Top 10.

We plan to run a full third-party penetration test at least annually, plus a targeted retest whenever we make a material change to the authentication surface, tenant model, or data-processing pipeline. Each annual engagement will rotate the emphasis (for example: year one — authenticated application; year two — API and supply chain; year three — infrastructure and deployment pipeline) so we accumulate depth, not just breadth.

We commit to triaging every finding within five business days of receiving the draft report and to landing fixes on the following cadence unless a compensating control is in place:

• Critical: fixed within seven days of triage, or mitigating control in place within 48 hours.
• High: fixed within 30 days.
• Medium: fixed within 60 days, or a documented acceptance with an approval trail.
• Low / Informational: fixed within 90 days or closed with a written rationale.

The testing firm will retest every fixed Critical and High finding and sign off in the final report.

After the final report is delivered, we will publish on this page:

• the testing firm’s name and brief credentials;
• the engagement window (dates);
• the scope tested (as above);
• findings counts by severity, with status (fixed / mitigated / accepted);
• an attestation letter from the testing firm stating the engagement occurred and any Critical findings were remediated.

The full, un-redacted report is made available to customers and qualified prospects under an NDA, through the CMDash account team or by emailing security@cmdash.com.

While the first engagement is pending, we rely on layered internal assurance:

• Automated static analysis, secret scanning, and dependency vulnerability alerts run on every pull request.
• Integration tests pin authentication and HTTP security-header behaviour, so a regression is caught in CI.
• Anomaly detection on the audit log flags unusual auth patterns (impossible travel, burst failures) for manual review.
• A public responsible-disclosure policy (see /trust/disclosure) with a safe harbour for good-faith researchers.

These are not a substitute for independent testing — they are the floor beneath it.