Do you know what your team has installed this month?

The integrations your team uses every day got there without anyone deciding they should.

I've been working in IT since 2007 and in cybersecurity since 2017. Across that arc, the pattern that keeps showing up in organizations of every size is the same: the security threat that grows quietest is the one nobody's tracking.

Browser extensions. Microsoft 365 add-ins. Slack apps. Zoom integrations. QuickBooks plugins. A marketing person needed a screenshot tool. A finance person needed a calendar connector. An account manager needed something that pulled data into a deck. Each install was small and nobody approved any of them, because nobody was watching for them in the first place.

A year or two later, every organization I've worked with has a long list of integrations running quietly across its tools, and most of them have never been reviewed by anyone. If you asked the leadership team to write down every integration the org has added in the last twelve months, they couldn't.

That's the gap this post is about.

How integrations arrive without a decision

The thing about an extension or add-in is that it usually isn't a procurement decision. There's no purchase order. There's no approval thread. There's often no money changing hands at all, because most of these tools are free or have free tiers that cover the use case. Finance never sees them. IT may or may not see them, depending on how the device is managed. Most of the time, the only person who knows the integration exists is the person who installed it, and even they forget within a few months.

Over time, an organization builds up a surface area of integrations that nobody owns. Some of them stay quietly active in the background, checking for updates, syncing data, requesting tokens. A few of them carry very broad permissions because the install dialogue asked for them and the person clicking through wasn't reading carefully. (Most install dialogues aren't designed to be read carefully.)

And then, sometimes, the integration itself goes bad.

In May, GitHub got caught by exactly this dynamic. A poisoned version of a popular Visual Studio Code extension was published to the official marketplace. It was live there for eighteen minutes before being pulled. An employee installed it during that window. About 3,800 of GitHub's internal repositories were exfiltrated. The company has stated there's no evidence customer data was affected.

GitHub got caught here by an eighteen-minute window in a trusted distribution channel, the same kind of channel every team I've worked with uses to install things every week. During that window, no amount of reading reviews or waiting for reputation signals would have caught the bad version. The defense is a process for evaluating the install as a decision before it happens, and most organizations don't have one.

Why scanners and bans don't close the gap

When the third-party integration question lands in front of a small organization, the reflex is usually to look for a tool. A scanner that audits every installed extension. A policy that bans installs without approval. An allowlist that gates what people can add.

Each of these has a place, but none of them addresses the underlying issue. Here's why:

Scanners are reactive. They catch the obvious bad cases, and they're useful for sweeping the existing surface. They don't catch the next eighteen-minute window. Bans are unrealistic for most organizations, because extensions and add-ins are how modern knowledge work gets done, and a blanket ban tends to mean people either work around the rule with personal accounts or quietly stop telling anyone what they're using. Allowlists are stronger in theory but require ongoing maintenance, a person to own them, and a process for adding exceptions. Most small organizations don't have the staffing for that.

The limitation of all three is that they treat the install as a thing happening to the organization, rather than as a decision the organization is making. What's missing in most orgs is the habit of evaluating new integrations the same way they'd evaluate a new hire's reference check or a new vendor: briefly, structurally, and before the relationship starts.

A lightweight process for vetting integrations

Nothing fancy is needed. Ten minutes, whoever wants to add the integration, the following five questions:

1. What problem does this solve, and how often will we actually use it? Most installs are tried once and then sit unused. If the honest answer to "how often" is "maybe once a quarter," the install might not be worth the surface it adds.

2. Who's the publisher, and how established are they? Look at install count, how long the integration has existed, and who maintains it. Brand-new publishers and one-off authors carry more uncertainty. Established publishers carry less, though the GitHub example earlier in this post is a reminder that "established" isn't the same as "risk-free."

3. What permissions is it asking for? Read all your email. Access your calendar. See the contents of every spreadsheet you open. Many integrations ask for more than they actually need to do their job. If the request is wildly broader than the function, that's information worth pausing on.

4. Where does the data go? Some integrations process data locally; others pipe it to third-party servers as part of how they work. If the integration touches financial, customer, or donor data, knowing where that data lands matters.

5. What happens if it stops working tomorrow? Integrations get pulled from marketplaces. Publishers get bought and shut down. Free tiers go away. The more important an integration becomes to a workflow, the more important it is to know in advance how badly its disappearance would hurt, and whether there's a backup option.

Ten minutes. No security expertise required. Just the willingness to pause before installing.

Zoom out

This install-without-decision gap is the same shape as a lot of the security gaps small organizations carry. The most common pattern I've seen across organizations of every size is that the defaults around them, including auto-renewals, auto-installs, auto-anything, are doing more of the deciding than the people are. The same gap opens at other moments in the same organization: when a contract comes up for renewal, when a new product gets bought, when an integration gets installed. The habit that closes it is the same each time, which is pausing to decide rather than letting the default decide on its own.

Security work at the size of organizations LockFort serves comes down, more than anything, to building the habit of asking the question at the right moment about whether the thing in front of you is actually earning its place. The shift is one of timing: making the decision earlier in the cycle than most organizations are used to.

A starting point for this week

If you want to start closing the gap, here's a way to do it that doesn't require new tooling.

1. Pull the inventory. Ask each team, or each person in a small enough org, to list every browser extension, Slack app, Microsoft 365 add-in, Zoom integration, and other plugin they've installed in the last twelve months. Not for blame, for visibility.

2. Sort by what each one touches. The integrations that read email, access the calendar, see financial data, or sit close to customer or donor information get attention first. The rest can wait.

3. Adopt the five questions for new installs. Whoever wants to add a new integration runs the questions in ten minutes before clicking install. Log the decision somewhere lightweight: a message in a shared channel is enough.

4. Schedule a quarterly review. Twice a year, look at the inventory together. Anything nobody's used in six months gets pulled. Anything still in use that nobody can answer the five questions about gets a closer look.

What changes when an organization starts treating installs as decisions is mostly quiet. The integrations that earn their place still get installed. The ones that don't earn their place stop quietly accumulating, and the ones that do carry the weight of an actual choice.

If you'd like to think through what a lightweight vetting process for integrations would look like for your organization, that's the kind of conversation LockFort is built to have.

---