Security teams rarely struggle to find risk. The harder challenge is making that risk actionable.

In modern cloud and AI environments, the same issue can surface across multiple environments, workloads, and deployments. Without the right operating model, security findings quickly become noisy, hard to assign, and even harder to remediate at scale.

That is what made Service Catalog so compelling for our team here at Wiz.

Rather than treating security as a long list of disconnected findings, the team began organizing risk around a more intuitive unit: the service. That shift is helping us build a clearer source of truth for ownership, route issues to the right teams automatically, and create a more scalable remediation process.

Why services are the right lens for security

For developers, services are the natural unit of work. Teams own services, deploy them, monitor them, and get paged for them. But security programs don’t always reflect that structure.

The Wiz platform helps bridge the gap between security and development by identifying critical risks, adding context, and proposing remediation steps. Still, for many teams, these insights don’t map cleanly to how engineering actually operates. 

Service Catalog changes that. By grouping cloud assets, issues, and ownership around services, it creates a shared frame of reference for both security and engineering. We’ve continued to add functionality to operationalize services for security use cases, for example we’ll be releasing services and service issue context to Wiz Workflows this month to make it easier to orchestrate responses and remediation.

Instead of asking who owns a resource or where an alert should go, teams can ask a simpler question: which service does this belong to? That shift improves communication immediately and makes ownership actionable.

As Erico Fusco, Senior Security Engineer at Wiz, put it: “If you own a service, you should be able to see the security issues tied to it, act on them, and be accountable for resolving them. That is the direction we are building toward.”

Building on what already existed

Erico and our team at Wiz did not start on the Service Catalog journey from scratch. Engineering teams already had a way to associate services with operational ownership. Inside our code repositories, there were existing mappings for monitored services and the people who should be paged for operational issues. That system was not originally built for security, but it gave the team a practical starting point.

Instead of reinventing ownership from the ground up, we reused that structure and built an internal tool to sync those mappings into Service Catalog through the Wiz API. That tool reads the repository data, updates service ownership, and applies the tags needed for downstream automations. 

We also discovered several gaps to operationalize services for security. For example, a single service could appear in multiple monitoring areas. That worked for operational alerting, where multiple teams might receive signals, but it was not a clean fit for security, where a service needs a clearly defined owner. To fully prepare to implement Service Catalog, we identified three areas that needed to improve:

• Tagging wasn’t consistent enough

• Ownership wasn’t always explicit

• Automation was needed to keep everything up to date

The team fine-tuned those mappings and separated “who gets alerts” from “who owns the service.” Then, once the ownership source was identified, Service Catalog could be populated automatically and kept in sync through internal tooling. While we still have more room ahead of us to improve these tagging, our initial focus let us spend our time improving service quality and coverage, ultimately making the rollout itself technically easy to deploy.

Turning services into an operating model

We also used the same internal concepts for engineering operational alerts to create dedicated Slack channels for security issues. Service tags are attached to services so automation rules could route issues to the right teams automatically.

That means a service does not just have an owner. It also carries the metadata needed to notify the right Slack channel, connect the right people, and support future workflows around reminders and escalations. Today, almost all services in scope at Wiz have:

• an owner

• a Slack channel

• an on-call assignment

The result is a mature ownership flow from end to end: security issues can now be mapped to services, routed to the right communication channel, and tied back to the teams responsible for remediation. In the future, we also plan to also strengthen reminder and escalation workflows to support strong ownership and accountability for service owners.

This is where Service Catalog starts to become more than a record system, and instead an operating model for security.

From noisy findings to service issues

One of the most important benefits for us at Wiz has been the way Service Catalog turns many related risks into a single service issue.

Cloud environments generate repetition by design. The same service may exist in a sandbox, production, and staging. It may run across many regions or data centers. For us, a single service may be deployed hundreds of times. Without grouping, the same underlying problem can show up again and again.

Service Issues reduce that noise by consolidating related risks into one remediation object. Instead of reporting the same root cause repeatedly, Wiz can surface one service-level issue for the team to address. That improves the remediation process in a few important ways:

• it reduces alert fatigue

• it helps teams focus on the underlying cause instead of every individual instance

• it gives security and engineering a shared object for tracking and resolution

This is one of the clearest reasons Service Catalog matters for us. The model helps our teams stop reporting the same thing over and over and instead work from a single, actionable issue. 

What’s next for Service Catalog at Wiz

One of the most important ideas Erico described ahead is to make service tagging part of the deployment standard itself. In practice, that means treating a missing service tag like any other misconfiguration: something that should be caught automatically, ideally before it ever reaches production.

For teams considering a similar path, his advice is straightforward: do not treat Service Catalog as just an inventory project. Its value comes from what it enables around ownership, routing, accountability, and remediation.

That starts with the basics: reliable tagging, clear ownership, and automation to keep both up to date. Once those pieces are in place, services become a powerful organizational construct: one that helps security teams operate in the same structure engineering teams already trust.