The argument for hiding your own vulnerabilities is wrong
Responsible disclosure is a settled norm when a vendor finds a bug in someone else’s software, yet most vendors apply a very different standard to their own. 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 responsible disclosure of your own weaknesses 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.
Why disclosure speed is the real trust signal
Publishing a finding is only half of the story. What customers actually judge is how fast you close it. That matters more every year, because the window between a vulnerability becoming known and being attacked keeps shrinking. Google’s Mandiant reported that the median time-to-exploit for observed vulnerabilities collapsed to just five days, down from more than a month a few years earlier. Some flaws are now weaponised before a patch is even public.
Against that clock, the industry is moving in the wrong direction. Veracode’s 2025 State of Software Security report found the average time to fix a flaw has climbed to roughly 252 days, up from 171 days five years earlier. When we publish our self-pentest log, the 48-hour remediation time on PE-001 through PE-004 is the number we most want customers to see, because it is the number that separates a genuine security culture from a compliance checkbox.
This is also why our responsible disclosure practice remediates before it publishes. We never post an open vulnerability. By the time a finding appears in the changelog, the fix has already shipped, verified against the same engine that found it. That sequencing is the whole point of responsible disclosure: protect users first, inform the public second.
Frequently Asked Questions
What is responsible disclosure?
Responsible disclosure, also called coordinated disclosure, is the practice of privately reporting a security vulnerability to the affected vendor and giving them time to release a fix before technical details go public. It protects users because the flaw is only published once a patch is available.
Why do most security vendors hide their own vulnerabilities?
The usual argument is reputational risk: publishing your own findings exposes imperfections. We consider that short-sighted. Concealment optimises for optics over trust, and if a hidden vulnerability is later found externally, the cover-up becomes part of the story.
How long does a responsible disclosure window usually last?
The widely used industry standard is 90 days from private report to public disclosure, popularised by Google Project Zero. AssurePort follows a 90-day coordinated disclosure window for third-party findings and remediates its own findings before publishing them.
How fast should a vulnerability be remediated?
Speed matters more than ever because attackers now exploit some flaws before patches ship. Industry data puts the average fix time at around 252 days, yet AssurePort closed four of its five May 2026 self-pentest findings within 48 hours.
Where can I report a vulnerability in AssurePort?
Our /.well-known/security.txt file documents the contact process. Reports go to security@assureport.com, and researchers receive credit in our changelog unless they request anonymity, under a 90-day coordinated disclosure window.