Security
Vulnerability disclosure.
We run offensive security engagements for a living, so we know what a good disclosure process looks like. Here is ours.
Report a vulnerability
Email your report to contact@cavementech.com with “Security vulnerability report” in the subject line. We aim to acknowledge reports promptly and will tell you what we intend to do about the issue and roughly when.
Please use email rather than the contact form for security reports, so it is triaged as a disclosure rather than a sales enquiry.
Scope
What is authorised, and what isn't.
Testing outside the scope below is not authorised. That matters here more than most places: under the Prevention of Electronic Crimes Act 2016, unauthorised access to an information system is a criminal offence in Pakistan — and we cannot consent on behalf of customers whose environments we monitor.
In scope
- This website (services.cavementech.com)
- Publicly reachable infrastructure we operate
Out of scope
- Denial-of-service or volumetric testing of any kind
- Social engineering of staff, customers or suppliers
- Physical security testing
- Automated scanning that degrades availability for others
- Any customer environment we monitor — those are not ours to authorise
- Reports generated solely by automated scanners with no demonstrated impact
Ground rules
What we ask, and what you get.
Report privately, first
Give us a reasonable opportunity to remediate before any public disclosure. We will keep you updated on progress rather than going quiet.
Include enough to reproduce
Clear steps, the affected URL or component, and what impact you were able to demonstrate. A proof of concept is more useful than a severity label.
Minimise impact
Use only the access needed to demonstrate the issue. Do not access, modify or exfiltrate data belonging to anyone else, and stop as soon as impact is established.
No compensation offered
We do not currently operate a paid bug bounty. We will acknowledge your report and, if you want, credit you once the issue is resolved.
About this site
This is a static site. It holds no database, runs no server-side application code, and stores no credentials or secrets in the client bundle. Form submissions are sent directly to a third-party form provider — validation, rate limiting and abuse protection are enforced there.
A Content-Security-Policy is applied. Some hardening headers — notably frame-ancestors, HSTS preload and X-Content-Type-Options — require response-header control that the current static host does not provide. We would rather state that plainly than imply protection that isn't in place.