The argument for hiding your own vulnerabilities is wrong
The standard practice in the security industry is to run an internal pentest, remediate the findings, and publish a sanitised “we completed a penetration test” statement. If the test surfaces a critical finding, it does not appear in any customer-facing document. The logic is that disclosure would create reputational risk.
We disagree with this logic, for a specific reason: it optimises for short-term optics over long-term trust. When a security vendor hides its own vulnerabilities, it signals to customers that the vendor treats security as a compliance exercise rather than an engineering discipline. And if a vulnerability is later discovered externally — by a researcher, a customer, or an attacker — the concealment becomes part of the story.
The alternative is radical transparency: publish what you found, what the risk was, how you fixed it, and how quickly. This is not a comfortable practice. It requires accepting that customers will see the imperfections. But it is a stronger trust signal than any polished security page.
What we published from our May 2026 self-pentest
In May 2026, we ran AssurePort’s own Web Pentest engine against our production API surface. The pipeline surfaces findings in the same format we deliver to customers. We published the results directly on our security disclosure page.
Five findings were surfaced. Here is a summary of each:
The /api/health endpoint returned internal version strings and dependency names without authentication. Fixed: minimal public response, full detail behind Bearer gate.
The OTP regeneration endpoint had no per-IP rate limit, allowing enumeration attempts. Fixed: 5 requests per 10 minutes per IP via Cloudflare KV rate-limit middleware.
The free intel DNS tool accepted arbitrary hostnames with no public-IP validation. Risk: SSRF to internal Cloudflare metadata. Status: Accepted risk (DoH IP allowlist + internal network not reachable from Workers). Documented in known issues register.
Scan status responses included internal D1 error messages on malformed tenant_id queries. Fixed: error normalisation middleware added, generic 400 response returned.
Marketing pages lacked a Content-Security-Policy header. Fixed: CSP added to Cloudflare page rules for all public pages (report-only mode initially, enforcing mode after 7-day observation).
Why we publish finding details: Customers evaluating a security vendor need to know whether the vendor treats its own security posture as a first-class engineering concern. Showing the finding, the severity, and the fix demonstrates the process working, not just a claim that the process exists.
The responsible disclosure process we follow
For findings against our own platform, the process is straightforward:
- Identify and classify. CVSS score, affected component, potential impact.
- Remediate before disclosure. We fix before publishing. We do not publish open vulnerabilities.
- Write a plain-English summary. What was the finding, what was the risk in plain terms, what was the fix.
- Publish in the changelog with a version tag. No separate security advisory for low/info findings. Medium and above get a dedicated entry.
- Update the Trust Center. The security controls page at
/trustis updated to reflect the current state.
For third-party findings — if an external researcher reports a finding in AssurePort — we follow a 90-day coordinated disclosure window. The researcher gets credit in the changelog unless they request anonymity. The /.well-known/security.txt file documents the contact process.
What this means for customers
If you are evaluating AssurePort as a security vendor, our self-pentest record in the changelog is a direct signal of how we treat security internally. You can see:
- What we found when we ran our own tool against ourselves
- How quickly we closed each finding (PE-001 through PE-004 closed within 48 hours)
- Which findings we accepted as known risk and why (PE-003)
- The format of a real AssurePort finding — the same format your scan output will use
This is not a marketing exercise. We publish the findings because we think the security industry’s default of hiding its own vulnerabilities is counterproductive. We have built a product for customers who take security seriously. We should be willing to demonstrate that we take our own security seriously in the same way.
The Trust Center as a living document
Beyond the changelog, we maintain a Trust Center at /trust that includes the current state of our security controls, sub-processor list, DPA template, and incident response runbook. The Trust Center is updated after every self-pentest cycle and after any material security event.
If you have a specific question about our security posture that is not answered there — a DPA requirement, a specific control question from an InfoSec team, a question about a specific finding — the fastest path is the feedback form or the security@assureport.com address in our security.txt.