20.3 External Communication and Disclosure¶

External communication during a supply chain incident determines how customers, partners, and the public perceive your organization's security posture and integrity. When Okta disclosed the Lapsus$ breach in March 2022, their initial communications first denied any breach, then minimized the incident's scope to "a small percentage" of customers. As additional details emerged revealing broader impact, customer trust eroded—not because of the breach itself, but because of perceived communication failures. Conversely, when Cloudflare disclosed their Okta exposure with a transparent, detailed blog post, their proactive communication provided a notable contrast to Okta's approach.

External disclosure involves communicating incident information to parties outside your organization: customers, partners, upstream and downstream projects, regulators, security researchers, and the public. Each audience has different needs, different notification requirements, and different implications for your organization. Balancing transparency with responsible timing, legal requirements with practical constraints, and stakeholder needs with organizational interests requires careful planning and execution.

Customer Notification: Timing, Content, Channels¶

Customers entrust you with their data and depend on your systems. When supply chain incidents potentially affect that trust, they deserve prompt, clear notification that enables them to protect themselves.

Customer notification decision tree:

Was customer data potentially accessed or exposed?
├── Yes → Notify affected customers (required by most regulations)
│         Timeline: As soon as scope is understood, typically within 72 hours
│
└── No → Was customer system security potentially impacted?
          ├── Yes → Notify affected customers (best practice)
          │         Timeline: Within days of confirmation
          │
          └── No → Did the incident affect service availability?
                    ├── Yes → Status page update, notify affected accounts
                    │
                    └── No → Disclosure optional, consider proactive transparency

Timing considerations:

The tension between speed and accuracy is real. Early notification with incomplete information can cause unnecessary alarm or misdirected response. Delayed notification can leave customers exposed and damage trust when they learn you knew before telling them.

We recommend:

• Notify when actionable: Customers should be able to do something with the information. "You may be affected, but we don't know how or what you should do" is less valuable than "Your API keys may have been exposed; rotate them immediately."

• Don't wait for complete information: Perfect understanding may never arrive. Notify when you have enough information to be useful, and commit to updates as you learn more.

• Meet regulatory deadlines: Legal requirements (GDPR's 72 hours, various state laws) establish maximum timelines. Plan to meet these even when investigation is ongoing.

Customer notification content template:

Subject: Security Notice: [Brief Description] - Action Required

Dear [Customer],

# What Happened
[2-3 sentence description of the incident in plain language]

We discovered that [specific component/system] was affected by [vulnerability/compromise]. 
This occurred between [dates] and was discovered on [date].

## What Information Was Involved
[Specific data types that may have been affected]
- [Data type 1]
- [Data type 2]

## What We Are Doing
[Actions you have taken and are taking]
- Immediately [containment action]
- Engaged [forensic firm/law enforcement if applicable]
- Implemented [remediation measures]

## What You Can Do
[Specific, actionable steps for the customer]
1. [Action 1 with specific instructions]
2. [Action 2 with specific instructions]
3. [Action 3]

## For More Information
[Contact information, FAQ link, dedicated support resources]
- Security hotline: [number]
- Email: [address]
- FAQ: [URL]

We will provide updates as our investigation continues. The next update 
is scheduled for [date/time].

[Signature]

Notification channels:

For significant incidents, use multiple channels. Email provides detailed information; in-app alerts ensure active users see it immediately; status pages provide ongoing updates.

Partner and Supplier Communication¶

Supply chain incidents ripple through business relationships. Partners who integrate your software, suppliers whose components you use, and vendors who depend on your systems all need appropriate communication.

Upstream communication (to projects/vendors whose software you use):

When you discover a vulnerability in an upstream component, responsible disclosure to the maintainers enables them to fix the issue and protect other users:

1. Check for security contact: Look for SECURITY.md, security@project.org, or bug bounty program
2. Report through appropriate channel: Private report, not public issue
3. Provide actionable detail: Enough information for them to reproduce and fix
4. Agree on disclosure timeline: Coordinate public disclosure timing

Downstream communication (to customers/partners who use your software):

When your software is affected:

• Notify partners before public disclosure when possible
• Provide them with information to assess their exposure
• Offer support for their response efforts
• Coordinate disclosure timing to allow preparation

Partner communication protocol:

## Partner Security Notification

**Classification**: [Confidential until public disclosure]
**Embargo**: [Date/time of planned public disclosure]

### Summary
[Brief description of the issue]

### Partner Impact Assessment
Your integration with [our product/service] may be affected if:
- [Condition 1]
- [Condition 2]

### Recommended Actions
1. [Specific partner action]
2. [Timeline recommendation]

### Coordination
- Public disclosure planned: [Date/time]
- Partner support contact: [Email/phone]
- Technical briefing available: [Date/time]

Please treat this information as confidential until public disclosure.

Coordinated Disclosure with Upstream Projects¶

When you discover vulnerabilities in open source dependencies, coordinated disclosure balances the need to protect users against the risk of alerting attackers before fixes are available.

Coordinated disclosure process:

1. Identify the security contact:
2. Check SECURITY.md in the repository
3. Look for security@ email addresses
4. Check for bug bounty program (HackerOne, Bugcrowd)
5. GitHub Security Advisories for GitHub-hosted projects

6. If no security contact, try maintainer directly with encrypted communication

7. Make initial report:

8. Clear description of the vulnerability
9. Steps to reproduce
10. Potential impact assessment
11. Any suggested fixes

12. Your proposed disclosure timeline

13. Negotiate timeline:

14. Standard timeline is 90 days (an industry norm established by Google Project Zero and widely adopted), but adjust based on severity and fix complexity
15. Critical vulnerabilities under active exploitation may warrant shorter timelines

16. Complex fixes requiring coordinated release may need longer

17. Support fix development:

18. Review proposed patches if asked
19. Test fixes in your environment

20. Provide additional technical detail as needed

21. Coordinate disclosure:

22. Agree on disclosure date and time
23. Prepare your advisory to publish simultaneously
24. Coordinate with downstream users if you distribute the component

When coordination breaks down:

Sometimes maintainers are unresponsive, disagree about severity, or refuse to fix issues. Options include:

• Escalate timeline pressure: "We plan to disclose in 30 days regardless of fix status"
• Engage CVE authority: Request CVE assignment independent of maintainer
• Coordinate with others: Work with security community or CERT for mediation
• Disclose with mitigation: If no fix forthcoming, disclose with workarounds

Avoid public disclosure without warning except in extreme circumstances (active exploitation, maintainer actively hostile). Even contentious disclosures benefit from advance notice.

Working with Security Researchers and Reporters¶

Security researchers who report vulnerabilities to your project deserve professional, respectful engagement. How you treat reporters influences whether future vulnerabilities come to you or to Twitter.

Researcher relationship management:

1. Acknowledge promptly: Respond within 1-2 business days confirming receipt. Researchers who hear nothing assume you're ignoring them.

2. Set expectations: Provide estimated timeline for initial assessment and next communication.

3. Communicate progress: Regular updates, even if just "still investigating," maintain the relationship.

4. Be transparent about decisions: If you disagree about severity or exploitability, explain your reasoning. Researchers may have additional context.

5. Credit appropriately: Public acknowledgment (with permission) recognizes contribution and encourages future reports.

6. Compensate if possible: Bug bounty payments or swag show appreciation, but respectful treatment matters more than money.

Researcher communication template:

Subject: Re: Security Report - [Reference ID]

Thank you for reporting this issue to us. We take security seriously and 
appreciate you taking the time to help us improve.

## Status
We have confirmed the issue and are working on a fix.

## Timeline
- Fix development: Estimated completion by [date]
- Testing: [timeframe]
- Release: Targeting [date]
- Public disclosure: [date], coordinated with you

## Credit
We would like to acknowledge your contribution in our advisory. Please 
confirm how you would like to be credited: [Name, affiliation, social handles]

## Questions
[Any clarifying questions about the report]

Please let us know if this timeline works for you or if you have concerns.

[Signature]

When reporters are journalists rather than security researchers, different considerations apply. Journalists may be writing about a vulnerability you've already disclosed or investigating rumors. Work with your communications team to provide accurate information while protecting sensitive details during active incidents.

Regulatory Notification Requirements¶

Supply chain incidents affecting personal data trigger notification obligations under various regulations. Failure to notify timely can result in significant penalties independent of the underlying breach.

Key regulatory frameworks:

Notification content requirements:

Regulations typically require specific content in notifications:

• Nature of the breach
• Categories of data affected
• Approximate number of individuals affected
• Name and contact details of data protection officer
• Likely consequences
• Measures taken to address the breach

Work with legal counsel to ensure notifications meet all applicable requirements. Requirements vary by jurisdiction and data type; generic notifications may not satisfy specific regulatory language.

Multi-jurisdictional complexity:

Organizations operating globally face overlapping requirements. A single incident might require:

• GDPR notification to Irish DPC for EU users
• State notifications across 20+ US states
• HIPAA notification if health data involved
• Contractual notifications to business customers
• SEC disclosure if material

Map your notification obligations before incidents occur. Incident response is not the time to research which regulations apply.

Public Statements and Press Releases¶

Major supply chain incidents may warrant public communication beyond direct stakeholder notification. Public statements shape broader perception and can demonstrate transparency and competence—or their absence.

When to issue public statements:

• Incident is likely to receive media coverage regardless
• Significant portion of user base is affected
• Incident has implications beyond direct customers
• Proactive transparency serves organizational values

Press release considerations:

1. Timing: Issue statements when you have confirmed information and clear messaging. Rushed statements often require correction; delayed statements appear evasive.

2. Accuracy: Every word will be scrutinized. Verify facts before stating them. Acknowledge uncertainty rather than overstating knowledge.

3. Completeness: Address the key questions: What happened? Who is affected? What are you doing? What should affected parties do?

4. Tone: Acknowledge impact on affected parties. Avoid defensive language. Express commitment to transparency and improvement.

5. Coordination: Align public statements with customer notifications, partner communications, and regulatory filings. Inconsistencies create confusion and erode trust.

What to avoid:

• Minimizing language that later proves inaccurate ("small number of users")
• Premature attribution of the attack
• Blaming upstream projects or vendors publicly
• Legal language that sounds dismissive of customer concerns
• Promises about future security that you cannot guarantee

A core principle of crisis communication is to state what you know, acknowledge what you don't know, and commit to providing updates. Then follow through.

Statement review process:

Before publication, statements should be reviewed by:

• Legal: Regulatory compliance, liability implications
• Communications: Messaging clarity, brand consistency
• Technical: Factual accuracy
• Executive: Strategic alignment, authority to commit

Build time for this review into your disclosure timeline. Last-minute reviews under deadline pressure produce mistakes.

Recommendations¶

We recommend the following external communication practices:

1. Prepare templates before incidents: Draft customer notifications, partner alerts, and statement frameworks now. Under pressure, you will adapt templates faster than creating from scratch.

2. Default to transparency: When uncertain whether to disclose, lean toward disclosure. Trust lost through perceived secrecy is harder to rebuild than trust tested by honest acknowledgment of problems.

3. Coordinate timing across audiences: Customers should not learn about incidents affecting them from press coverage. Plan notification sequencing carefully.

4. Treat researchers professionally: Your vulnerability disclosure process influences whether you hear about issues before or after attackers do.

5. Map regulatory requirements proactively: Document which regulations apply to your data types and jurisdictions. This analysis is much harder during active incidents.

6. Commit to updates and follow through: Every communication should specify when the next update will come. Honor those commitments.

7. Review and improve: After incidents, review external communications for effectiveness. What questions did customers ask? What confusion arose? Update templates accordingly.

External communication is where technical incident response meets organizational reputation. Clear, timely, accurate communication—even about difficult situations—builds long-term trust that transcends individual incidents.