The cost of a bad plugin install is not the five minutes it takes to remove it. It is the afternoon the team cannot build, the release that slips a day, and the hour spent explaining to someone outside engineering what happened. This post breaks plugin failure cost down by where the time actually goes, covers the bad install impact most teams never put on paper, lays out a plugin incident response order that survives the first ten minutes, and finishes with a plugin rollback plan you can write in twenty minutes rather than improvising mid-outage.
Where the time actually goes
Teams budget for the removal and forget everything around it. The removal is the smallest line item.
| Stage | What happens | Where the time goes |
|---|---|---|
| Detection | Something breaks, and nobody connects it to the plugin | Half a day, because the first hypothesis is usually the application |
| Containment | The plugin gets disabled or the machine gets isolated | One hour with a rollback plan, most of a day without one |
| Assessment | You work out what it touched, read, wrote or sent | Two hours to two days, depending on how good your logs are |
| Recovery | Rebuild, reconfigure, restore | Half a day for one machine, longer for a shared build runner |
| Reporting | Someone outside the team needs a written account | Two to four hours, and it lands on the most senior person available |
The bad install impact that never gets counted
The rows above are the ones that show up in a ticket. Three more costs are real and almost never written down.
- Context loss. The engineer who knows the setup spends the afternoon on the incident instead of the work they were doing, and whatever they were building moves by a day.
- Trust cost. After one bad install, the team stops approving plugins quickly. Reviews that took ten minutes start taking a week, and that delay costs more than the incident did.
- Audit debt. If the plugin touched credentials or build output, somebody has to state what it could have reached. That statement has to hold up months later, which means evidence gathered during the incident rather than recollection afterwards. The evidence format is at /blog/plugin-supply-chain-security-team-enforcement.
A plugin incident response order that holds up
Under pressure people skip straight to fixing. Fixing second is usually faster overall, because restoring something you have not examined can restore the problem along with it.
- Freeze the blast radius first: disable the plugin, isolate the machine, and revoke any credential the plugin could read. Do all three even if you only suspect one of them.
- Preserve evidence before restoring: copy the plugin directory, the install logs, and the plugin manifest. Restoration overwrites the only copy of what happened.
- Establish what it could reach: file paths, environment variables, network destinations, and child processes. Write it as a list rather than a narrative.
- Then restore, from a known-good state rather than by removing the plugin and hoping.
- Close with a decision record: what happened, what it reached, what you changed, and when it gets reviewed. The template sits at /blog/plugin-supply-chain-security-team-enforcement.
Order matters more than speed. Restoring a machine you have not examined can restore the problem and destroy the evidence in a single step.
Write the plugin rollback plan first
A rollback plan is twenty minutes of work that only pays off during an incident, which is exactly why it never gets written. Four lines cover most plugins.
- Where the plugin writes: config path, cache path, and any file it creates outside its own directory.
- What it can read: credentials, environment variables, and repository contents.
- How to disable it completely, including any service or hook it registered, not just the uninstall command.
- The last known-good state and how long restoring it takes. If you have never timed it, the number in your head is wrong.
Keep the plan next to the approval record. When something breaks, the person reading it is not the person who wrote it, and they are reading it with the clock running.
Prevention, priced
Most prevention here is cheap. The expensive parts are optional.
- Reading install hooks before running them costs five minutes. The mechanics are at /blog/how-install-script-scanning-works.
- Checking the score and the maintenance signals before approval costs two minutes, and what goes into the number is at /blog/dsh-quality-score-decoded.
- Verifying who published the package costs another five. The routine is at /blog/how-to-verify-dsh-plugin-authenticity.
- A sandbox for anything that touches credentials costs an hour to set up once. That is roughly a tenth of one detection phase.
FAQ
- Is the cost really this high for a small plugin? It scales with what the plugin can reach, not how much code it has. A fifty-line plugin with credential access outranks a large one that only formats text.
- Should we remove a plugin before we understand what it did? No. Disable and isolate, copy the logs and the plugin directory, then restore. Removing first destroys the evidence you need for the report.
- How long should we keep the incident record? Follow the retention period that applies to the system the plugin touched, and keep it at least until the decision it informed expires.
- Does a high score mean we can skip the rollback plan? No. The score covers maintenance, documentation, ecosystem health and install behaviour. It does not describe what the plugin reaches on your machine.
- Who should own the decision record? Whoever approved the plugin. Approval and rollback belong to the same person, otherwise both get deferred.
Start with the live plugin index at dshquality.com, where every plugin page states what was checked and what was not. The case for keeping that scoring independent of self-reported data is at /blog/why-independent-plugin-scoring-beats-self-reported-ratings, and everything published on the site is at /blog.