How Be API sped up its WordPress vulnerability response by trading its in-house tool for WP Umbrella’s API

Be API is a 38-person WordPress agency that has built and run high-stakes sites for large enterprises, institutions and media since 2009. Its biggest maintenance headache was not updates or uptime. It was knowing, fast, which sites were exposed when a plugin vulnerability was published. This is the story of how the agency stopped maintaining its own detection tool and plugged WP Umbrella into its security workflow instead.

---

Company Card

“WP Umbrella has become a reliable building block in our RUN chain: it sees, it alerts, and our tooling does the rest.”

Amaury Balmer, CEO Be API

---

At a glance

• When a vulnerability is published, the exposed sites are identified automatically and the team goes straight to fixing.
• The agency no longer maintains its own vulnerability tracking tool. A specialized vendor maintains that part of the chain.
• WP Umbrella runs inside Be API’s existing process: installed via Composer, updates through the agency’s CI, the platform sees and alerts.

The question that mattered: which sites are exposed, and how fast are they fixed?

Be API runs complex WordPress projects for clients whose IT departments sit at the table: design, development, hosting and maintenance, which the agency calls RUN. Each site it delivers moves into maintenance, so the fleet grows at the pace of its projects. Fewer than a hundred sites, but almost all of them high-stakes platforms for large accounts.

Maintenance is a team effort. RUN project managers own the client relationship and incoming requests, the DevOps team runs infrastructure, monitoring and security, and developers handle fixes and updates.

Before WP Umbrella, the agency relied on its own tooling. Sites are managed with Composer on Bedrock and deployed through CI/CD with Buddy.works, alongside WP-CLI and in-house scripts. For security, the team had built an internal tool that cross-referenced vulnerabilities published by Patchstack with its own codebase. Monitoring was spread across several systems: uptime checks, Sentry, server logs. A few clients had backups through a dedicated plugin.

The pain was not spread evenly. One problem dominated.

“When a vulnerability is published for a plugin, the only question that matters is: which sites are exposed, and how quickly are they fixed? Our in-house tool answered the first part, but it had to be maintained and made reliable, and that time was not spent fixing.”

Amaury Balmer, CEO Be API

The agency declines to put a number on the time involved. The issue was not the average workload but the peaks. Every wave of vulnerabilities pulled the team away from other work to check the fleet’s exposure and prioritize fixes.

Build or buy: the decision to stop maintaining an in-house tool

The trigger was the threat itself. The number of vulnerabilities published across the WordPress ecosystem, and plugins in particular, has risen markedly in recent years. Be API needed a faster and more reliable response, without turning security monitoring into a second line of business.

The agency did not run a classic comparison of management platforms. The real choice was between WP Umbrella and the next version of its own tool.

“Technically, it was feasible. But maintaining an inventory and monitoring tool is not our core business, and its cost over time did not justify itself against a specialized tool.”

Amaury Balmer, CEO Be API

Four reasons tipped the decision toward WP Umbrella:

1. Vulnerability detection that automatically matches the fleet inventory against a vulnerability database.
2. An open API, which let the team integrate WP Umbrella into its security monitoring bot, connected to Redmine and Buddy.works.
3. A straightforward model and a readable price.
4. A French vendor, with proximity and responsive support.

The reservations were just as concrete, and any agency serving enterprise clients will recognize them: adding a third-party plugin to sensitive sites, giving a SaaS visibility over clients’ sites, and compatibility with Composer-managed installs.

Be API lifted them in three steps. Direct discussions with the WP Umbrella team. A usage framework set by the agency’s own processes: the plugin is installed via Composer, updates always go through the agency’s CI, and WP Umbrella’s role is to see and to alert. And a validation round with the IT departments of the clients concerned.

A pilot first, then the whole fleet

The rollout followed the same discipline. A pilot on a handful of sites validated the technical integration and the security framework. Then the agency generalized WP Umbrella to its entire maintenance fleet.

Two jobs, done through the API

Be API uses WP Umbrella for two things. First, vulnerability detection and the fleet inventory, both consumed through the API by the agency’s security monitoring bot. Second, uptime monitoring.

The agency does not use bulk updates. On Composer-managed sites, updates go through the CI/CD pipeline, and that is where they stay. WP Umbrella sees and alerts. The agency’s own tooling does the rest.

Asked whether any feature surprised them, the answer says a lot about a team that treats WP Umbrella as production infrastructure:

“No surprise, and that is rather good news: it does what we expected of it, reliably. For a production component, that is the criterion that counts.”

Amaury Balmer, CEO, Be API

🖼 SCREENSHOT: the public API documentation page. No raw API responses: account and site identifiers stay out of the picture. (placeholder, replace with the image)

The gain is measured in delay, not hours

Be API does not frame the result in hours saved.

“We do not think in hours saved. The real gain is on delay: when a vulnerability is published, identifying the exposed sites is automatic and the team goes straight to fixing.”

Amaury Balmer, CEO Be API

The second gain is structural. Rather than evolving its in-house tool, the agency now relies on a component maintained by a specialized vendor.

Two things did not change, and Be API is clear about both. Clients see no difference: WP Umbrella is an internal system, transparent to them, and its effect is indirect, on the reliability of the agency’s security monitoring and surveillance. And it has not sold any additional maintenance contracts, which was never the goal. For Be API, WP Umbrella is a production system that serves the quality of its maintenance work, not its sale.

Advice for agencies considering the move

Be API’s advice to agencies still hesitating comes in two parts. The first is about the temptation to build.

“Don’t fall for the illusion that you can do it yourself by vibe-coding an in-house tool: building it is easy, maintaining it and keeping it reliable over time is much harder.”

Amaury Balmer, CEO, Be API

The second is about method: run a pilot on a few sites, validate the security framework with your clients, then generalize. That is what Be API did.

Recap

• Be API’s dominant maintenance pain was vulnerability response: which sites are exposed, and how fast are they fixed.
• The agency chose WP Umbrella over the next version of its own detection tool, because maintaining that tool was not its core business.
• Enterprise-grade objections were resolved through vendor discussions, a strict usage framework and client IT validation.
• WP Umbrella now feeds the agency’s security bot through the API and monitors uptime. Updates stay in the agency’s CI/CD.

Ready to stop checking your fleet by hand every time a vulnerability is published? Start your 14-day free trial, no credit card required. → Get started for free