Outbound Coordinated Disclosure

Last updated: 5 November 2025

We support a safer software ecosystem. If Data Craftsman discovers a security vulnerability in third-party software or services, we follow a cooperative, responsible disclosure process aimed at prompt remediation with minimal risk to users.

Purpose

Define how Data Craftsman engages vendors and open-source maintainers when we discover security vulnerabilities in their products, code, or infrastructure.

Scope

• Vulnerabilities identified through routine usage of third-party software and services.
• Findings from manual review, limited research, or incidental discovery during operations.
• Automation may assist analysis, but all outbound disclosures are reviewed by a human before sending.

Principles

• Ecosystem security: Act in the best interests of users and maintainers.
• Cooperation: Respect vendor/maintainer inbound processes where available.
• Privacy by default: Initial disclosures are private and minimal.
• Actionable quality: Reports aim to be reproducible and clear.
• Attribution: Credit to “Data Craftsman” and, where appropriate, specific contributors—with consent.

Disclosure Workflow

1) Identification & Validation

• Assess impact (e.g., RCE, privilege escalation, injection, data leakage, SSRF, authz bypass).
• Prepare detail sufficient to reproduce: affected versions/commits, environment, and PoC where safe.

2) Peer Review

• A second reviewer checks accuracy, impact, and steps to reproduce prior to sending.

3) Vendor Contact

• Use the vendor’s preferred security channel (security email, private tracker, or form).
• Avoid public trackers by default unless that is the documented process.

4) Coordination

• Cooperate on timelines and patch validation. Provide clarifications as needed.
• We may test candidate fixes where feasible and safe.

5) Public Disclosure

We prefer disclosure with vendor consent once a patch or mitigation is available. Without consent, we may disclose when one or more apply:

• There is credible evidence of active exploitation.
• The vendor is non-responsive or unreachable within a reasonable period.
• Public disclosure is necessary to protect users or the public interest.
• Disclosure is required by law or regulation.

We will avoid publishing details that would materially raise risk before a patch is available, unless immediate public awareness is necessary to mitigate harm.

Report Contents (Typical)

• Summary and severity rationale
• Affected product, versions, and environment
• Reproduction steps or PoC (minimal and safe)
• Potential impact and likely exploitability
• Suggested mitigations or fix hints, if any

Timelines

• No rigid deadline; we aim for reasonable, risk-based timelines.
• We prefer aligned publication after fix/mitigation, or earlier if exploitation risk is significant.

Internal Handling

• Access to report materials is limited to personnel involved in handling the disclosure.
• If the issue affects our own environment, we will prioritise remediation in parallel.

Legal

We operate from New South Wales, Australia. This policy does not create contractual obligations or legal rights and may change without notice.

Contact

Email: support@mail.datacraftsman.com.au