Vulnerability Disclosure Policy
A structured, transparent channel for responsible disclosure of security vulnerabilities in the PinPole platform. We commit to fast triage, coordinated remediation, and open communication.
PinPole Pty Ltd is committed to the security of the PinPole platform - a cloud architecture design, simulation, and deployment product that processes sensitive information including AWS cross-account credentials, infrastructure topology, and user data. This Vulnerability Disclosure Policy (VDP) establishes a clear, structured channel through which security researchers, engineers, customers, and partners may report potential vulnerabilities in a way that enables PinPole to act before public disclosure occurs.
The objectives of this policy are to provide a trusted and low-friction path for responsible disclosure; define PinPole's obligations to reporters including acknowledgement timelines and remediation commitments; reduce the risk of valid vulnerabilities being publicly disclosed before a fix is available; and establish a CVE handling procedure so that publicly significant vulnerabilities are registered, tracked, and communicated to affected users consistently.
In-scope systems
This policy applies to the following assets owned or operated by PinPole Pty Ltd:
@pinpole scopeOut of scope
The following systems, vulnerability classes, and testing techniques are outside the scope of this policy. Reports in these categories will not be actioned under this policy, though we may forward significant third-party issues to the relevant maintainer:
All vulnerability reports must be submitted to [email protected]. Do not submit reports via the in-app feedback widget, GitHub issues, or any other channel - these are not monitored by the security function and may inadvertently make details public.
[email protected]
PGP encryption
We strongly encourage reporters to encrypt sensitive submissions using our PGP public key. Encrypted submissions prevent interception during transit and allow us to discuss details confidentially before a patch is available.
The full PGP key is also published at pinpole.cloud/.well-known/security.txt in accordance with RFC 9116.
PinPole asks that all reporters follow the principles of coordinated vulnerability disclosure. This means reporting findings privately to PinPole before any public disclosure, allowing sufficient time for a fix to be developed and deployed, and agreeing a public disclosure date with the security team.
Reporter responsibilities
When researching and reporting vulnerabilities, we ask that reporters:
- Only test against systems listed in the in-scope section above.
- Use test accounts and synthetic data - do not use real customer accounts for research.
- Avoid accessing, modifying, or retaining data belonging to other users.
- Avoid any action that could degrade the availability or performance of PinPole services.
- Report findings to [email protected] before public disclosure.
- Keep vulnerability details confidential until PinPole confirms a fix is live or the agreed embargo expires.
PinPole's commitments to reporters
Upon receipt of a valid vulnerability report, PinPole commits to the following response milestones:
| Milestone | Target timeline | Detail |
|---|---|---|
| Acknowledgement | 48 hours | We confirm receipt and assign a tracking reference. |
| Initial triage | 5 business days | Severity assessed using CVSS v3.1; initial finding communicated to reporter. |
| Remediation plan | 10 business days | For confirmed vulnerabilities, an estimated fix timeline and interim mitigations are shared. |
| Fix confirmation | Per severity SLA | Reporter notified when fix is deployed; validation requested where feasible. |
| CVE / public disclosure | Coordinated | For Critical and High severity, disclosure timing is coordinated with the reporter. |
Report template
To accelerate triage, please include the following fields in your submission to [email protected]:
Remediation SLAs by severity
PinPole classifies severity using CVSS v3.1 base scores and applies the following target remediation timelines. These are targets, not guarantees - PinPole will communicate openly if a deadline cannot be met and will agree a revised timeline with the reporter.
| Severity | CVSS score | Fix target | Interim action |
|---|---|---|---|
| Critical | 9.0 – 10.0 | 72 hours | Immediate incident response; affected feature may be taken offline. |
| High | 7.0 – 8.9 | 7 days | Engineering sprint prioritisation; WAF rule or config mitigation where possible. |
| Medium | 4.0 – 6.9 | 30 days | Scheduled in next release cycle; reporter kept informed. |
| Low / Info | 0.1 – 3.9 | 90 days | Backlog item; fix included in next appropriate release. |
CVE assignment criteria
PinPole will request CVE assignment from MITRE for any confirmed vulnerability that meets all of the following:
- The vulnerability is present in a production system accessible to customers or third parties.
- The vulnerability is independently reproducible and has a confirmed security impact.
- The CVSS v3.1 base score is 4.0 or higher (Medium, High, or Critical).
Low and Informational findings will not generally result in CVE assignment unless the reporter requests it and PinPole agrees the finding meets MITRE criteria. Where a vulnerability exists in a dependency or third-party component, PinPole will notify the component maintainer and coordinate disclosure rather than submitting a CVE directly.
CVE lifecycle - from report to advisory
The following procedure governs every CVE-eligible finding from initial report through to public advisory:
PinPole will not pursue legal action against security researchers who discover and report vulnerabilities in good faith and in accordance with this policy. We consider responsible disclosure a valuable contribution to the security of our platform and the safety of our customers.
- Complies with the disclosure process described in this policy.
- Does not intentionally access, retain, or exfiltrate customer data beyond what is minimally necessary to demonstrate the vulnerability.
- Does not disrupt, degrade, or deny service to PinPole systems.
- Does not exploit the vulnerability for personal gain or share it with third parties before a fix is available.
If we believe a researcher is acting outside the scope of this policy, we will attempt to contact the reporter before taking any legal action. Safe harbour does not apply to individuals who engage in conduct that would constitute a criminal offence under the Australian Criminal Code Act 1995 or applicable state legislation, regardless of stated intent.
PinPole does not currently operate a paid bug bounty programme. We recognise the effort of security researchers through the following:
PinPole reserves the right to introduce a paid bounty programme in the future. Any such programme will be announced on the security page and communicated via security.txt.
This policy is owned by the Head of Engineering (or CTO where that role is unfilled). The [email protected] mailbox is maintained jointly by the co-founders until a dedicated security function is established.
This policy is reviewed annually, or sooner in the event of a material change to the PinPole platform, a significant security incident, or a change in applicable law or regulation. The current effective version is always published at pinpole.cloud/security/vdp.
Related documents
[email protected]