Third-Party Vulnerability Disclosure Policy

Last updated: May 2026

Purpose

Offensive security work puts us in an unusual position. During a client engagement, we sometimes find vulnerabilities that live not in the client's own code, but in the third-party software, platforms, or libraries they depend on. A zero-day in a widely deployed framework is not just a client problem. Every other organisation running that software is exposed too.

This policy explains how we handle those discoveries: how we weigh our confidentiality obligations to clients against our responsibility to the wider security community, and what vendors, clients, and the public can expect from us when we find something.

We publish this policy because we think firms in our position should be held to a clear, public standard. It also serves as a direct notice to vendors: if Skuntir contacts your security team about a vulnerability, this is the framework we will follow.

1. What This Policy Covers

This policy applies to vulnerabilities discovered in third-party software, products, platforms, or services found incidentally during a contracted client engagement. That includes:

  • Zero-day vulnerabilities in commercial or open-source software the client uses
  • Security flaws in cloud service provider platforms or shared infrastructure
  • Weaknesses in third-party libraries, SDKs, APIs, or frameworks integrated into client systems
  • Vulnerabilities in hardware, firmware, or embedded systems within the engagement scope
  • Supply chain weaknesses in software components with broad downstream impact

This policy does not apply to vulnerabilities found in Skuntir's own systems (see our Responsible Disclosure Policy) or to findings in client-owned systems, which are governed by the applicable engagement agreement.

2. The Tension We Operate In

Two obligations pull in opposite directions when we discover a third-party vulnerability on an engagement. We take both seriously.

2.1 Confidentiality to the client

Our primary obligation is to the client. The fact that we were engaged and the nature of their environment are confidential. Contacting a vendor without consent can reveal that the client uses a particular product - which is sometimes sensitive operational intelligence.

We will not contact a vendor, a CERT, or any other third party without the client's explicit written consent, unless the conditions in Section 4 apply.

2.2 Responsibility to the broader ecosystem

An unpatched vulnerability in widely deployed software is a risk to every organisation running it, not just our client. Indefinite silence is not a neutral position.

Vendors deserve a fair window to remediate before public disclosure. The public deserves to know when software they rely on has been found vulnerable. These are not in conflict. They are the basis of coordinated disclosure.

3. Standard Disclosure Process

When we discover a third-party vulnerability during an engagement, we follow this process. Individual timelines may shift based on severity, client circumstances, and vendor responsiveness, but the default is:

  • Day 0 - Vulnerability discovered and documented internally: technical details, proof of concept, severity assessment, and affected versions
  • Days 1-5 - Client notified in the engagement report and directly via their designated point of contact. Written consent for vendor disclosure requested. Client risk impact assessed
  • Days 5-14 - If consent is obtained, the affected vendor is contacted through their published security channel or PSIRT. We provide technical details sufficient to reproduce and remediate the issue. We provide no client-identifying information
  • Day 30 - If the vendor has not acknowledged or responded by this point, we notify CERT/CC or an appropriate national CERT as a coordination escalation. Multi-vendor vulnerabilities may be routed to CERT/CC from the outset
  • Days 14-90 - Active vendor engagement and remediation tracking. We maintain communication with the vendor and update the client on progress. CVE assignment coordinated with the vendor during this period
  • Day 90 - Standard disclosure deadline, adjusted to the next business day if it falls on a weekend or public holiday in either Sweden or the vendor's primary jurisdiction. If the vulnerability remains unpatched and no written extension has been agreed, we proceed with public disclosure
  • On patch release (before Day 90) - If the vendor ships a fix before the deadline, we publish no sooner than 14 days after the patch becomes publicly available, to allow time for downstream deployment. The 14-day window may be shortened by mutual agreement
  • Post-publication - A public security advisory is published attributing discovery to Skuntir. Client identity is not disclosed under any circumstances. Affected organisations are provided remediation guidance

A grace period of up to 30 days beyond the standard 90-day deadline may be granted at Skuntir's discretion where a vendor demonstrates active, good-faith development of a fix and consistent communication throughout the process. The total maximum timeline, including any grace period, is 120 days from initial vendor notification. Grace periods must be requested before the 90-day deadline and agreed in writing.

4. Overriding the Client Consent Requirement

Requiring client consent before disclosure creates a risk: a client could withhold consent indefinitely, leaving a dangerous vulnerability unaddressed across the broader ecosystem. Where the risk to third parties is serious, that is not an outcome we will accept.

Skuntir reserves the right to proceed with vendor disclosure without client consent in the following circumstances:

  • The vulnerability is being actively exploited in the wild by threat actors
  • The vulnerability could reasonably enable mass data exfiltration, ransomware deployment, or disruption of critical national infrastructure if independently discovered or disclosed
  • The client has withheld or declined to respond to a consent request for more than 60 days without a substantive legal or operational justification
  • A regulatory authority or law enforcement body with jurisdiction directs disclosure

Where we invoke this override, we will give the client a minimum of 5 business days notice before contacting the vendor, except where doing so would itself create a safety risk. Client-identifying information will not be shared with the vendor under any circumstances.

5. What We Will Never Disclose to a Vendor

Regardless of circumstances, we will not provide a vendor with any of the following when reporting a third-party vulnerability:

  • The identity of the client in whose environment the vulnerability was found
  • The name, type, or description of any client-owned system
  • Any indication that the vulnerability was discovered during a commercial engagement rather than independent research
  • Any data, credentials, or artefacts obtained from the client's environment
  • Any information that would allow the vendor to identify or contact our client

These protections are unconditional. They apply whether or not client consent for disclosure was obtained, and whether the disclosure is coordinated or emergency.

6. CVE Assignment

For vulnerabilities of public significance, Skuntir may request CVE assignment through MITRE or an appropriate CVE Numbering Authority (CNA). We coordinate CVE requests with the affected vendor where possible, and initiate them only with client consent or under the override conditions in Section 4.

For vulnerabilities approaching the disclosure deadline without a patch, we will proactively request CVE pre-assignment to ensure that the first public mention of the vulnerability includes a CVE identifier. We attribute CVE discovery accurately and will not request CVE numbers for findings that do not warrant public tracking.

7. Emergency Disclosure

Where a vulnerability is confirmed to be under active exploitation in the wild, or where independent discovery by a threat actor appears imminent based on available threat intelligence, we accelerate the timeline to 7 days from initial vendor notification. Seven days is intentionally aggressive. A vendor may not be able to ship a patch that fast, but 7 days is generally enough time to publish interim mitigations - disabling a service, restricting access, or issuing a pre-disclosure advisory - that reduce immediate risk to users.

In emergency situations, we notify the client and vendor simultaneously and compress the standard timeline to match the severity of the situation. The client will be informed of the emergency classification and the accelerated timeline before any external contact is made. We will give as much advance notice as circumstances safely allow before any public communication.

8. Non-Weaponisation

Skuntir will not sell, transfer, broker, or provide any discovered vulnerability, exploit, or proof-of-concept to any party for offensive purposes outside the contracted engagement in which it was discovered. This applies without exception, regardless of the financial value of the finding or the identity of a prospective buyer.

We do not participate in vulnerability broker markets, grey-market exploit trading, or government acquisition programmes for offensive zero-days. We do not accept finder's fees from vendors conditioned on non-disclosure. Every vulnerability we discover follows the coordinated disclosure process in this policy.

9. Vendor Response Expectations

When Skuntir contacts a vendor under this policy, we expect:

  • Acknowledgement of receipt within 5 business days
  • Initial triage assessment within 10 business days
  • A remediation plan and estimated timeline within 30 days of confirmation
  • Transparent, substantive communication throughout the remediation process

Vendors who are unresponsive, who deny valid findings without substantive technical justification, or who attempt to use legal pressure to prevent disclosure will be considered to have forfeited their right to a full embargo period. We will proceed with coordinated public disclosure at our discretion in such cases.

We are not in the business of being reasonable with vendors who are not being reasonable with us.

10. Contact

Questions about this policy, or vendor responses to a Skuntir disclosure report: security@skuntir.com

General legal enquiries relating to this policy: legal@skuntir.com