Handling a PR disaster for your project
I want to say up front that the point of this post is not to disparage Trivy or its maintainers. They’ve had a rough few weeks and I feel for them. I only discuss Trivy as a recent example of a bad day at the office.
The saying “there’s no such thing as bad publicity” always felt a little gross to me. There are a lot of reasons you might get noticed that are bad, and it should feel bad to do bad things. But maybe there’s something to it. If you handle a PR disaster well, you might come out ahead (although you’d still probably prefer to not deal with it in the first place).
Bad publicity is good?
As you may know, the Trivy project fell victim to an attack last month. The compromise affected not just Trivy, but its sponsoring company and many downstream projects and companies. It was — and continues to be — a big deal.
Out of curiosity, I decided to look to see if people were switching from Trivy to other projects. I decided to use GitHub stars as a proxy for interest. Yes, GitHub stars are meaningless. But I figured a relative change might indicate interest in alternatives. Much to my surprise, Trivy’s star count increased pretty dramatically post-compromise. Syft and cdxgen, which seem to be the main alternatives for SBOM generation, saw no such bump. Of course, this doesn’t necessarily mean that people aren’t shifting away from Trivy. But I expected to see the opposite of what the star counts show.
The past few weeks have been a PR nightmare for Trivy, and I’m sure it’s been entirely unpleasant for the maintainers. I don’t wish this on anyone, but if you find yourself in this kind of situation, take heart. There’s at least some indication that your project can survive this kind of catastrophic event.
It’s worth noting that it may just be too early to tell what the future holds for Trivy. While they’ve received a lot more stars and attention, there haven’t been any commits to main in three weeks. People are still opening issues and pull requests, so it may just be that the maintainers are still focused on cleanup. I hope that the project comes back stronger and more secure, but time will tell.
Disaster recovery
If your project has a PR nightmare, stay calm. If you have the resources to bring in a crisis PR expert, do that and ignore everything else I say after this. Most likely, though, you don’t have the resources to bring in a pro. So here’s my amateur advice:
- Mitigate the damage. Take whatever technical steps are necessary to keep the problem from getting worse. This may include rotating credentials, disabling CI pipelines, locking issues, or turning off services. This step is the most important because you don’t want the problem getting worse while you’re handling communication.
- Create an advisory if appropriate. Do this if there’s a vulnerability in your software that you’re addressing. You can skip this for other flavors of disaster. If you’re on GitHub, you can follow the GHSA creation process. Other hosting platforms may have their own system. As a last resort, you can request a CVE at https://cveform.mitre.org/.
- Communicate honestly and factually. Tell people what happened and, if applicable, how to know if they’re affected and how to address it. Don’t try to hide uncomfortable facts. Be honest, but don’t speculate or guess. You can always update as new facts come to light, but you can’t un-say things.
- Don’t feel obligated to correct everyone. As the story spreads, people will get things wrong. Perhaps aggressively so. You don’t need to put your energy into correcting every misstatement posted by some rando online. If news outlets or influential people misstate facts, you can give them the correct version. If they draw inferences that you disagree with, it’s probably best to let it go.
This post’s featured photo by Ante Hamersmit on Unsplash.