Vulnerability Disclosure Policy

01 Purpose & Scope

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.cloud

Marketing website and public-facing documentation

app.pinpole.cloud

Primary SaaS application — canvas, simulation, and deployment

api.pinpole.cloud

REST and WebSocket APIs consumed by the front-end

AWS deployment pipeline

Cross-account IAM / STS infrastructure used for customer deployments

PinPole SDKs & CLI tools

Any client-side tooling published under the PinPole namespace

Authentication infrastructure

Cognito, WAF, Secrets Manager, and KMS integrations

Out of scope

The following are explicitly excluded from this policy:

Vulnerabilities in third-party services that PinPole does not control (AWS, Stripe, Cloudflare, etc.) — please report those to the relevant vendor.
Findings produced solely by automated scanning without evidence of exploitability.
Denial-of-service attacks or disruptive testing against production systems.
Social engineering or phishing attacks targeting PinPole staff.
Physical security of PinPole premises or hardware.
Any testing that accesses, modifies, or exfiltrates customer data belonging to accounts you do not own.

02 Security Contact

All vulnerability reports must be submitted to the PinPole security team via the dedicated channel below. Do not report security vulnerabilities through public GitHub issues, social media, or any other channel not listed here.

Primary security contact

Submit reports to the dedicated security mailbox. All reports are treated as confidential and are not shared outside the response team without the reporter's consent, except where required by applicable law.

security@pinpole.cloud

PGP encryption (recommended for sensitive reports)

Reporters who wish to submit sensitive details — proof-of-concept code, credentials, or architecture extracts — are encouraged to encrypt their submission using PinPole's published PGP public key. The key is available at pinpole.cloud/.well-known/security.txt, which also complies with RFC 9116 and specifies the canonical contact address, policy scope, and preferred languages for disclosure communications (English).

Unencrypted submissions are also accepted and handled with the same level of confidentiality.

03 Responsible Disclosure Process

Reporter responsibilities

PinPole asks that reporters act in good faith throughout the process and specifically:

Submit reports privately to security@pinpole.cloud before any public disclosure.
Provide sufficient detail to reproduce and assess the vulnerability (see the report template below).
Allow PinPole a reasonable remediation window before disclosing publicly (see SLA table).
Avoid accessing, modifying, or retaining data belonging to other users.
Avoid any action that could degrade the availability or performance of PinPole services.

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 security@pinpole.cloud:

report template · security@pinpole.cloud

Title

A concise description of the vulnerability class — e.g. SSRF in canvas export endpoint

Affected asset

The URL, service, SDK, or component affected — refer to the scope table in §1

Severity

Your self-assessed CVSS v3.1 score and vector string, if known

Description

Step-by-step reproduction instructions from an unauthenticated or authenticated starting state

Impact

What an attacker could achieve if the vulnerability were exploited

Evidence

Screenshots, HTTP request / response logs, or proof-of-concept code (encrypt if sensitive)

Suggested fix

Optional — your recommended remediation approach

Reporter

Name or handle and preferred contact method. Anonymous submissions are accepted.

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.

Coordinated disclosure window

The default maximum embargo before a reporter may publish is 90 days from acknowledgement, in alignment with norms established by Google Project Zero and the CERT/CC. If remediation cannot be completed within the applicable SLA, PinPole will notify the reporter at least 7 days before deadline and provide a revised estimated fix date. Extensions beyond 90 days require mutual written agreement.

04 CVE Handling Procedure

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:

1

Report received

Security team assigns internal tracking ID and sends acknowledgement to reporter within 48 hours.

2

Triage

Security team reproduces the finding and scores it using CVSS v3.1. Engineering lead is notified for Critical and High findings within 24 hours of triage completion.

3

CVE request

If criteria are met, security team submits a CVE request to MITRE via the CVE Submission Portal. A reserved CVE ID is obtained before public disclosure.

4

Patch development

Engineering develops and tests the fix on an isolated branch. Code review is mandatory; at least one reviewer must be a senior engineer not involved in the original implementation.

5

Internal validation

Security team validates the patch. Reporter is invited to verify the fix in a staging environment where feasible.

6

Release & deploy

Patched version is deployed. Release notes describe the fix at a functional level without providing exploitation detail prior to the public disclosure date.

7

CVE population

Security team submits full CVE details to MITRE — affected versions, fixed version, CVSS score, CWE mapping, and technical description. Reporter is credited by name or handle (with their consent).

8

Customer notification

For Critical and High CVEs, PinPole notifies all affected customers via in-app notification and email within 24 hours of the CVE going public. Medium CVEs are covered in release notes.

9

Public advisory

A security advisory is published at pinpole.cloud/security/advisories referencing the CVE ID, affected versions, fixed version, CVSS score, and a brief description of the vulnerability class.

10

Post-incident review

Within 10 business days of closure, the security team conducts a root cause analysis and updates relevant threat models and security controls to prevent recurrence.

05 Safe Harbour

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.

Safe harbour applies when the reporter

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.

06 Recognition

PinPole does not currently operate a paid bug bounty programme. We recognise the effort of security researchers through the following:

✓ Named credit in CVE records and published advisories (with consent)

✓ Security Hall of Fame at pinpole.cloud/security/hall-of-fame

✓ Written letter of acknowledgement on company letterhead on request

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.

07 Policy Governance

This policy is owned by the Head of Engineering (or CTO where that role is unfilled). The security@pinpole.cloud 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.