Automating Security is an Ownership Problem
This post is a bit different to my usual, there’s no code and it’s more high level. I hope it’ll still be useful though.
I recently gave a talk at the Wiz Club London event, covering how we built up automation flows on top of ownership data that we set up in Wiz. It seemed to land really well so I’m turning this post I had in draft into a summary of the talk. The overarching topic is idea on how small security teams can leverage ownership data, automation and tooling such as Wiz to avoid drowning in busy maintenance work. This then frees security up to work on bigger ticket items like guardrails.
We’ll cover the basic flow of:
- Gathering ownership data
- Adding it to Wiz
- Keeping it up to date
- Allowing users to see their issues (and only their issues)
- Automations you might want to create
Automating Security is an Ownership Problem
OK, I know, that’s reductive. But between interviewing, chatting at meet ups and personal experience a common issue is how you manage ownership of security findings. It’s something we faced and as team structure, architecture and company culture change, so the ownership model needs to adapt and evolve with it.
Add to this the increased velocity required now AI is in the picture (it’s 2026, every blog post need to mention AI) and it’s clear manual processes are in trouble.
When it comes to automating workflows: if you’ve not solved the ownership problem you soon hit a blocker. Sure you can create Jira tickets and slack alerts, but these all end up routed to the SoC rather than the actual owning team. This then leads to a massive amount of time and resource spent chasing down an owner and letting them know about the issue. If you get the ownership data problem sorted this can all be automated, leaving security teams free to build guardrails and tackle the meaty problems.
Finding Issues is the Easy Part
I can’t glance at my inbox without someone trying to sell me a magic box that will find all my security vulnerabilities. But a big list of vulnerabilities without context is all but useless. You can’t set a priority, you can’t map them to business processes, and throwing massive numbers at engineering teams just leads to paralysis.
Personally, I think Wiz is really good at giving context to findings. It handles toxic combinations well and uses as much data as you give it to help you set priority.
Let’s say you’ve rolled out a tool such as Wiz, it’s given you the context and you’ve got 200 critical issues. Now what? Well now you have to find owners to resolve them. If you don’t have ownership data now is the time to start creating it.
In our case as we reached out to teams we recorded which team owned what. We put this in a JSON file to begin with, and slowly we got a good picture.
Once we reached a good level of maturity we started working with other departments who needed the data like architecture and finops. Once we hit this level of traction we centralised the data and roped our cloud ops and infra teams in to make sure account/tenant vending and decom updated this data source. At this point we had a clear view of who owned what, which was a great starting point to drive automation from.
Ownership in Wiz
So now you’ve started getting a list of teams set up, you can use the Wiz terraform provider to create projects for these teams. It’s worth using folder projects to group these into departments or pods or whatever your structure is. You can then hang permissions off that structure, and when you generate reports to take to risk forums you’ll have the data at both team and department level.
What’s great about using the terraform provider is you can set the pipeline to run on some event (such as the ownership data changing) or just run it a few times a day on a cron. It means as the ownership data evolves so does the Wiz setup without any manual maintenance.
For each team project you can set resource scopes to map cloud and code resources to the team. These might be based on subscription, k8s namespaces, services in the service catalog, code repos etc. The idea is to get as much ownership data into Wiz as you can. It removed so much manual chasing and frees the security teams up for solving the bigger hitting issues and building guardrails.
You’re a Wiz-ard Harry
Right, so we now know who owns each issue, but that’s far from the end. There’s no point in security having the data and not letting teams see it.
One of the great things about getting the structure into Wiz is that you can give teams access to their findings without giving them access to everything. We bang the least privilege drum constantly, it’s time to practice what we preach.
To do this you need to make sure your identity provider mirrors your ownership structure. This may mean creating groups in the IDP to mirror the teams, or (my preference) working with the enterprise identity team to make the IDP the master data source for ownership.
Once you have this you can then set up SSO role mappings to map the IDP group to the corresponding project in Wiz. Then when engineers log in they can see their issues and data, but not that of other teams.
It’s also worth having a few pseudo teams you can add people to who need higher level access. CISOs, Directors etc generally want to see all the data across the org, so have a team you can add them to which maps them to global reader. Someone dubbed this team “security wizards” and I cringe every time I have to talk about it, but it’s a useful team. Likewise some teams such as Cloud Ops and Networking often want to see all the inventory data in Wiz without seeing the associated security issues. There’s an inventory role in Wiz you can use for this.
There’s one snag here, and it’s something I’d love to see Wiz address in the future. When someone is in multiple teams they can only view the data for one team at a time. In order to see the issues etc for a different team they are in they need to switch roles in the UI. It’s confusing, leads to a lot of “why can’t I see this” support tickets, and - most critically - means links in messages and PR scans don’t always work until the user has switched into the correct role. Please badger your Wiz TAM about this one.
Set up alerting
You have the data, and engineers can log in and see their issues. Wonderful. But in my experience they wont. Well, that’s not quite true, about 20% will, and the rest won’t without a call to action of some sort.
Raising tickets with teams is great, but if you don’t have standardised ticket types, transitions and properties then it’s pretty horrible to roll out globally. We tend to make this one opt-in and have a terraform map with all the optional properties teams want to set like ticket type, component field, status etc. Then teams can opt in with a PR to the terraform.
We’ve had much better buy-in with chat messages on Slack or Google Chat. We’ve updated the ownership data with a teams alerting channel, and send alerts to the channel when certain events happen. Events to consider when rolling this out are:
- New critical or high severity issue. It’s worth making other severities opt in for keen teams
- Close to SLA breach. You can add SLA data to Wiz which will add a due date to issues. You can then alert when it’s getting close. Something to consider here is teams sprint times. If your teams run 2 weeks sprints then send alerts early enough they can plan the work in. E.g. 17ish days from breach so the message is “plan this into next sprint or you’ll breach SLA” rather than “derail your sprint to fix this”
- Everyone’s favourite “you’re on the naughty list” SLA breach
- Overnight scan of a repo has found something critical or high
That said its worth focusing in on the things you care about and not bombarding teams with alerts just because you can, else you risk hitting alert fatigue.
Again these can all be managed in terraform via automation rule and Workflows in Wiz.
Strong Foundations
By this point, in my view, you’ve got strong foundations you can really build on. We’ve found this data so useful that we drive security improvements programs off it each quarter. We build queries in Wiz to define what we want teams to focus on and we have a ready-built league table based on projects. It also gives teams an idea of how much work they need to plan for each quarter to keep security off their backs.
Actually, that feels like the subject of a future blog post.