Vulnerability Disclosure Policy

Version: 1.0  |  Effective Date: April 20, 2026  |  Classification: Public

How SafeHill discovers, coordinates, and publicly discloses security vulnerabilities in third-party software.

1. Purpose and Scope

SafeHill, Inc. is a cybersecurity company that discovers security vulnerabilities in third-party software through penetration testing, security assessments, code reviews, and independent research. This policy governs how SafeHill handles those discoveries from the point of validation through public disclosure.

This policy exists to:

• Protect SafeHill, its researchers, and its clients throughout the disclosure process
• Provide affected vendors a fair and clearly defined opportunity to remediate before public disclosure
• Serve the public interest by ensuring that security vulnerabilities are ultimately disclosed so that defenders and users can protect themselves
• Give external parties (vendor legal teams, PSIRTs, regulators, clients) a definitive reference for how SafeHill operates

This policy does not govern vulnerabilities in SafeHill’s own products or infrastructure. It applies exclusively to vulnerabilities SafeHill discovers in software owned by other organizations.

2. Finding Categories

SafeHill’s vulnerability discoveries fall into three categories. Each category has different obligations, and the policy applies differently to each.

2.1 Client-Owned Findings

Vulnerabilities in code owned and operated by the client, discovered during a paid engagement. These are governed exclusively by the engagement agreement (MSA, SOW, or engagement letter) and are reported to the client. They are not subject to this policy and are not disclosed publicly by SafeHill.

2.2 Third-Party Findings During Client Engagements

Vulnerabilities in third-party software (libraries, frameworks, APIs, infrastructure components) discovered while assessing a client’s system. The client’s application may be affected, but the root cause is in software the client does not own.

For these findings:

• SafeHill notifies the client immediately
• SafeHill recommends the client authorize SafeHill to report the vulnerability to the affected third-party vendor
• If the client authorizes, SafeHill proceeds under this policy. SafeHill will never identify the client to the vendor without the client’s explicit written consent
• If the client refuses authorization, SafeHill retains the right to report the vulnerability to the vendor and/or a coordination body (CERT/CC, CISA) independently, stripping all client-identifying information, if SafeHill determines that public safety requires disclosure

SafeHill’s standard engagement agreements reference this policy and preserve SafeHill’s right to report third-party vulnerabilities affecting public safety.

Timing restrictions: Client engagement agreements may impose reasonable timing restrictions on third-party disclosure (e.g., pre-IPO embargo, regulatory audit period). SafeHill will honor these restrictions up to a maximum of 180 calendar days from the date of discovery. SafeHill will not agree to suppress disclosure beyond this limit under any engagement agreement.

2.3 Independent Research Findings

Vulnerabilities discovered through SafeHill’s own security research, not related to any client engagement. These findings are fully governed by this policy.

3. Research Conduct

All SafeHill vulnerability research is conducted under the following constraints:

• Research is limited to publicly accessible systems and information, or systems SafeHill has explicit contractual authorization to test
• SafeHill does not exploit authentication bypasses to access production user data beyond what is minimally necessary to demonstrate the vulnerability
• SafeHill does not exfiltrate or retain personally identifiable information or user data beyond what is necessary for proof-of-concept documentation. Any such data is redacted or destroyed after validation
• SafeHill does not conduct denial-of-service attacks against production systems
• All research activity is documented to demonstrate good faith, including tools used, systems accessed, and data encountered

These constraints are intended to keep SafeHill’s research within the scope of good-faith security research as recognized by the U.S. Department of Justice’s revised CFAA enforcement policy (May 2022), which directs federal prosecutors not to charge good-faith security researchers.

4. Internal Review and Authorization

Before any external contact with a vendor, every discovery undergoes an internal review. No SafeHill researcher contacts a vendor unilaterally.

The internal review evaluates:

• Conflict of interest: Is the affected vendor a current or prospective SafeHill client?
• Contractual restrictions: Was this vulnerability discovered during a client engagement? If so, what are the engagement-specific obligations?
• Regulatory implications: Does the vulnerability affect critical infrastructure, medical devices, or other systems with regulatory notification requirements?
• Legal exposure: Does the research or disclosure create any legal risk that needs advance preparation?

The SafeHill Research Lead (or designee) authorizes external vendor contact after the review is complete. The authorization and review findings are logged in SafeHill’s internal disclosure tracker.

5. Vendor Notification

5.1 Initial Contact

SafeHill will make reasonable efforts to identify the vendor’s preferred security reporting channel before sending the initial notification. SafeHill checks, in order:

• The vendor’s security.txt file (RFC 9116)
• Published vulnerability disclosure program or bug bounty platform (HackerOne, Bugcrowd, or equivalent)
• PSIRT contact page or dedicated security contact
• security@[vendor domain]
• General corporate contact as a last resort

The channel used is documented. All notifications are sent via encrypted email where the vendor’s PGP key is available, or through the vendor’s designated secure intake platform.

5.2 Notification Contents

The initial notification includes:

• Vulnerability summary and affected product/version
• Technical description with reproduction steps
• CVSS v3.1 or v4.0 base score
• CWE classification
• Potential impact assessment
• SafeHill’s contact information
• An explicit disclosure deadline: “SafeHill intends to publish a security advisory for this vulnerability on [specific date, 90 calendar days from this notification]. We welcome coordination on the timing and content of public disclosure.”

SafeHill does not include full proof-of-concept exploit code in the initial notification unless it is necessary for reproduction. PoC is provided upon request after the vendor acknowledges the report.

6. Disclosure Timeline

6.1 Default Timeline: 90 Calendar Days

SafeHill operates a 90-calendar-day disclosure timeline. Day 0 is the date SafeHill sends the initial notification to the vendor. The clock runs from this date regardless of whether the vendor acknowledges receipt.

SafeHill will publish a security advisory on or after Day 90, with or without a vendor fix in place.

6.2 Escalation Ladder for Unresponsive Vendors

If the vendor does not acknowledge SafeHill’s notification, SafeHill follows a documented escalation process:

Day	Action
0	Initial notification sent through vendor’s preferred security channel.
7	Follow-up sent if no acknowledgment received.
14	Second follow-up via an alternative channel (e.g., different email, VDP form, direct outreach to vendor PSIRT or engineering leadership via LinkedIn/phone).
21	SafeHill engages a third-party coordinator (CERT/CC or CISA) to facilitate contact with the vendor.
30	SafeHill sends a formal written notice stating the vendor is considered non-responsive and the 90-day disclosure deadline stands.
60	SafeHill sends one last formal written notice stating the vendor is considered non-responsive and the 90-day disclosure deadline stands.

Every step in the escalation ladder is documented and timestamped in SafeHill’s disclosure tracker.

6.3 Extensions

SafeHill may grant one extension of up to 14 calendar days (total maximum: 104 days). Extensions are available only when all three conditions are met:

• The vendor has acknowledged the vulnerability
• A fix is demonstrably in development (not merely planned)
• The vendor provides a specific, committed ship date that falls within the extension window

Extensions are SafeHill’s decision, not the vendor’s right. If no fix has been deployed or committed by Day 90, SafeHill will publish regardless.

6.4 Actively Exploited Vulnerabilities

If SafeHill discovers evidence that a vulnerability is being actively exploited in the wild, the disclosure timeline compresses to 7 calendar days. Users are already at risk, and withholding information does not protect them. SafeHill will publish a mitigation-focused advisory after 7 days even if the vendor has not shipped a fix.

6.5 Critical Infrastructure Exception

For vulnerabilities in industrial control systems, medical devices, transportation systems, or other safety-critical systems where exploitation could cause physical harm, SafeHill may extend the timeline to 120 calendar days upon confirming that:

• The vendor is actively developing a fix
• The extended timeline is necessary due to the nature of the system (e.g., regulatory approval, firmware distribution, hardware recall)
• CISA (through ICS-CERT) has been notified in parallel

This exception does not apply to software-only systems, regardless of their operational importance.

6.6 Multi-Vendor Vulnerabilities

When a vulnerability affects multiple vendors (e.g., a protocol flaw, shared library, or supply chain issue), SafeHill will coordinate an embargo date with all affected vendors, targeting 90 calendar days from the date the first vendor was notified.

If individual vendors cannot meet the embargo date, SafeHill will publish on the agreed date regardless. The advisory will note which vendors have shipped patches and which have not.

SafeHill may engage CERT/CC as a neutral coordinator for multi-vendor disclosures. When CERT/CC is engaged as coordinator, SafeHill will generally defer to CERT/CC’s disclosure timeline for its VU# note. SafeHill may separately publish its own advisory with additional technical detail.

7. Third-Party Coordination

SafeHill’s default approach is direct contact with the vendor. SafeHill will engage a third-party coordinator (CERT/CC, CISA, or another appropriate body) under any of the following conditions:

• Vendor non-response after two documented contact attempts over 14 calendar days (per the escalation ladder)
• Multi-vendor vulnerabilities requiring synchronized patching
• Vulnerabilities affecting critical infrastructure (CISA/ICS-CERT notification is mandatory)
• SafeHill anticipates a hostile vendor response and wants a neutral record
• SafeHill’s discretion, for any other reason

8. Response to Vendor Legal Threats

SafeHill will not suppress or delay legitimate security research in response to legal intimidation. If a vendor responds to SafeHill’s notification with a legal threat, cease-and-desist, or similar action, SafeHill will conduct an expedited internal legal review (target: 48 hours). If the review confirms that SafeHill’s research was conducted in good faith and within the scope of this policy, SafeHill reserves the right to immediately publish the vulnerability advisory.

SafeHill will provide legal defense for researchers acting within the scope of this policy who face legal threats or action from vendors. SafeHill will not require researchers to retract findings or issue apologies to vendors as a condition of legal defense.

9. Advisory Publication

9.1 Publication Channel

SafeHill publishes security advisories at safehill.com/research/advisories and, where appropriate, through full-length technical blog posts at safehill.com/blog.

9.2 Advisory Format

Each advisory follows a standard format:

• SafeHill advisory ID (e.g., SH-2026-001)
• CVE ID (if assigned)
• Title
• Affected product(s) and version(s)
• CVSS v3.1/v4.0 base score
• CWE classification
• Technical description
• Remediation status (patched, mitigated, or unpatched)
• Disclosure timeline: date of discovery, date of vendor notification, date of vendor acknowledgment (if any), date of patch availability (if any), date of publication
• Researcher credit

Advisories contain technical facts only. SafeHill does not include editorial commentary on vendor response quality, competence, or speed.

9.3 Proof-of-Concept Publication

The advisory and the proof-of-concept are published on separate timelines:

• Advisory: Published at the disclosure deadline (Day 90, or earlier if the vendor has shipped a fix). Contains a technical description sufficient for defenders and users to assess risk.
• Full PoC: Published 30 calendar days after the advisory, to give defenders time to patch. If the vendor has not released a patch by the advisory date, full PoC publication is deferred to 30 days after patch availability.

SafeHill may publish PoC earlier if the vulnerability is already being exploited in the wild or if PoC is already publicly available from other sources.

9.4 Vendor Advisory Preview

SafeHill will offer the vendor a preview of the draft advisory at least 7 calendar days before the planned publication date. The vendor may suggest technical corrections (e.g., affected version ranges, remediation instructions). The vendor does not have veto power over publication timing or content.

9.5 CVE Assignment

SafeHill will request a CVE identifier for every confirmed vulnerability. If the vendor is a CVE Numbering Authority (CNA), SafeHill will request the CVE through the vendor. If the vendor declines or is not a CNA, SafeHill will request the CVE through MITRE or another appropriate CNA.

10. Researcher Credit and Presentations

SafeHill will credit the discovering researcher by name (or handle) in every published advisory. Researcher credit is not optional and is not subject to vendor approval. The only exception is if the researcher personally requests anonymity.

For vulnerabilities discovered during client engagements where the client requests confidentiality, the researcher is still credited for the vulnerability. The engagement context is not disclosed.

Conference presentations: SafeHill encourages researchers to present disclosed findings at industry conferences (DEF CON, Black Hat, BSides, and others). Conference submissions should be coordinated with the Research Lead to ensure timing aligns with the disclosure timeline. SafeHill supports conference travel for accepted talks on SafeHill-disclosed vulnerabilities. Pre-publication discussion of vulnerability details, including social media teasers or countdown posts, is prohibited.

11. Dispute Resolution

If the vendor disagrees with SafeHill’s severity assessment, technical findings, or disclosure timeline, either party may request mediation through CERT/CC or another mutually agreed neutral coordinator.

SafeHill will respond to vendor disputes within 10 business days (U.S. Eastern Time) with written technical justification for its position.

Disputes do not pause the disclosure timeline. SafeHill will note any active disputes in the published advisory.

12. Conflict of Interest

If the affected vendor is a current SafeHill client, prospective client in active sales discussions, or a business partner, the internal review (Section 4) must identify the conflict before vendor contact. The following applies:

• The disclosure process is handled identically to a non-client vendor. SafeHill does not grant preferential treatment, extended timelines, or publication suppression based on a business relationship
• The SafeHill researcher handling the disclosure must not be involved in the commercial relationship with the vendor
• If the conflict cannot be adequately managed, SafeHill will transfer coordination to a neutral third party (CERT/CC)

13. Record Keeping and Evidence

SafeHill maintains an internal disclosure tracker with a unique case number for every reported vulnerability. The tracker logs:

• Date and method of discovery
• Internal review authorization and conflict-of-interest assessment
• All vendor communications with timestamps and delivery confirmation
• Escalation steps taken (follow-ups, coordinator engagement, formal notices)
• Vendor responses (acknowledgment, severity disputes, extension requests, legal threats)
• Advisory drafts and publication records

These records are retained for a minimum of 3 years following advisory publication. They exist to protect SafeHill in the event of a vendor dispute or legal proceeding.

14. Policy Governance

This policy is owned by the SafeHill Research Lead and reviewed annually or following a significant disclosure event. Material changes to the disclosure timeline, publication standards, or legal provisions will be announced at safehill.com/research/advisories with at least 30 calendar days’ notice.

Disclosures that are already in progress at the time of a policy change are governed by the version of the policy that was in effect when the vendor was first notified.

Version	Date	Summary of Changes
1.0	4/20/2026	Initial release.

15. Legal Notice

SafeHill conducts security research in good faith and consistent with the U.S. Department of Justice’s CFAA enforcement policy (May 2022), which recognizes that good-faith security research should not be charged under 18 U.S.C. § 1030.

This policy does not constitute a waiver of any legal rights by SafeHill, Inc. Nothing in this policy restricts SafeHill’s right to publish factual security research. Publication of security advisories constitutes protected speech under the First Amendment to the U.S. Constitution.

Vendor inquiries regarding this policy should be directed to [email protected].