Incident Response: Communicating With Developer Communities

Threats to developer-facing companies are rising and coming in more varied forms than ever. Associate Director of Technology Kyle Tyacke discusses best practices for incident response and the value of open communication.

Threats to developer-facing companies are rising and coming in more varied forms than ever. From security breaches to repository compromises, Denial-of-Service (DoS) attacks to insider threats, companies face an onslaught of risks, each with the potential to impact users and damage reputations.

In fact, 2023 saw a 72% increase in data breaches compared to the previous record year of 2021. While you can (and should) take steps to prevent these types of incidents from occurring, the reality is that they’re often out of your control.

The good news is that some advanced preparation can positively influence the experience your users have during and after an incident. If something happens, an incident response plan will allow you to act confidently, clearly, and quickly.

How Incidents Affect Developer Communities

Developers in your ecosystem face exposure to various threats to their data, security, and customers. While you can’t offer protection from everything, properly managed communications can, at minimum, reduce the fallout from an incident and can even go so far as to increase trust with your users.

The key is knowing how, what, when, where, and why to communicate after an incident. This can be a difficult balance to get right since developers have highly individualized needs, expectations, and preferences for communication. An effective response will position your company as a trusted partner and equip users with the information they need to address the issue.

Frequently Reported Incidents

Here are a few examples of incidents that can have adverse consequences on your developer community:

• Service Outages: While not necessarily an attack vector, outages happen frequently and are often out of the organization's control (due to downstream dependencies). These must be treated as any other incident with swift and honest communication.

• Security Breaches: Unauthorized access to software systems, theft of sensitive data, or exploitation of vulnerabilities can disrupt software development workflows and compromise the integrity of software products.

• Data Breaches: Incidents involving the unauthorized access, disclosure, or theft of sensitive data, such as user credentials or personal information, can have severe consequences for software developers and the users of their applications.

• Code or Repository Compromise: Breaches involving the compromise of source code repositories or codebase access can lead to the theft or manipulation of proprietary code, including intellectual property theft or the introduction of malicious code.

• Supply Chain Attacks: Attacks targeting third-party dependencies, libraries, or software components used in development processes can compromise the security and reliability of software products, as seen in incidents like the SolarWinds supply chain attack.

• Denial-of-Service (DoS) Attacks: DoS attacks targeting software systems or development infrastructure can disrupt development activities, cause downtime, and degrade the performance of software products.

• Insider Threats: Insider threats, including accidental or malicious actions by employees or collaborators, pose a risk to software development environments and the confidentiality, integrity, and availability of software assets.

Incident Response: Best Practices

The worst has happened: You’ve experienced an incident impacting hundreds of your users' accounts. What do you do now?

To start: Communicate early and often.

These situations require immediate, honest, and transparent communication to minimize the potential risks. Your initial goal should be to notify users of the incident before they’ve discovered it occurred. A head start will give them the best chance of reducing downstream impacts on their customers and demonstrate your commitment to an open partnership.

Let’s review the types of information you should provide when informing users of an incident.

Incident Overview

An incident overview should provide concise, high-level information about the nature of the incident. You can think of this as the “elevator pitch” of what occurred. The goal is to give users the details they need to check for downstream impacts.

• What happened? Provide a brief description of the incident and its impact. Honesty and transparency are critical - owning the failure will earn empathy from your community while withholding information will cause distrust.

• When did it occur? Specify the date and time of the incident.

• Who does it impact? Identify the individuals, groups, or systems impacted and how the incident affects them. This information will guide your users as they resolve outstanding issues and seek additional support.

• How (and why) did it happen? Provide a detailed analysis of the factors that contributed to the incident. Open communication will show users that you understand the problem, have the ability to solve it, and can be trusted to prevent future issues.

Resolution Details

Ideally, the issue gets resolved before your users are aware of it. If this is the case, clearly outline the incident's timeline as part of your response strategy.

• Resolution summary: Describe how the issue was resolved.

• Resolution process: Outline the specific steps taken to address the issue.

• Resolution timeline: Specify the date and time of resolution, as well as the overall duration of the incident.

Ongoing Management

If the issue is ongoing, make it clear that you’re committed to resolving it. Outline what actions are being taken, how and when users will receive updates, and the expected timeline for resolution.

• Unresolved issue management: If the issue remains unresolved, outline ongoing efforts to address and resolve it.

• Expected resolution date: Specify the anticipated timeline for resolving the issue.

• Ongoing communication: Explain how and when users will receive updates on the issue.

Preventive Measures

Provide insights into how you plan to prevent similar issues from occurring in the future. Doing this will help you reestablish trust and user confidence.

• Preventive actions: Detail the steps taken or planned to prevent similar incidents in the future.

• Timeline for prevention: Provide an estimated timeline for implementing preventive measures.

Incident Response: Communication Strategy

While communicating the facts of the incident is an essential first step, you can do even more to re-establish trust with your users and reduce negative sentiment toward your company. Remember, honesty and transparency are paramount when working with your developer community.

• Acknowledge the failure: Take responsibility for the incident and acknowledge any shortcomings that led to it.

• Make it personal: When possible, tailor messages to individual users with specifics about how the incident impacted them.

• Apologize: Offer a sincere apology for the consequences of the incident.

• Improvement actions: Highlight the actions taken (or planned) to improve future interactions and prevent similar incidents.

• Reinforce company values: Reiterate your company’s commitment to its users and core values.

• Meet them where they live: Draft messages in forms suited to the channels where you will most likely reach your users (like email, Reddit, or Slack). It is always best to post information broadly across multiple channels.

Support and Resources

One of the worst things you can do is leave your users in the dark. Show up for your developer community by providing access to resources and opening lines of communication. Let users know you’re there for them and can still be relied on as a trusted partner.

• Support channels: Provide information on how affected individuals can seek additional support or have their questions answered. It’s also helpful to provide a location where they can subscribe to receive notifications of future incidents. 

Example of an Effective Incident Response

Bored Ape Yacht Club notified users about a significant incident involving the potential loss of data. Although it’s a brief message, they were prompt, clear on the resolution, and provided instructions for further support.

1,800 "likes" isn’t exactly what you’d expect from a post about a security breach, but it reflects an understanding of what their users needed to hear. This type of response is exactly what you’re looking for.

Building a Resilient Developer Community

Incidents happen - it’s a natural part of working in the tech industry. Remember that how you communicate with users could be the difference between a minor disruption and a full-blown disaster.

Effective communication in the event of an incident requires an in-depth understanding of your developer community. Put your users' needs first and meet them on their terms. Showing that you’re prepared for the incident and committed to resolving it will strengthen the long-term connection between you and users.

---

Find yourself with more questions than answers around developer community communication? We’re here to help. Drop us a line!