Ownership and identity matching

Ownership answers who should act on a finding. Identity matching answers which accounts belong to a person. SecOps uses both, but they are separate decisions.

Who owns a vulnerability finding?

The owner resolves in this order:

1. An exact repository or target rule in Settings.
2. A team named on the finding itself.
3. Repository or cloud owner data adopted with the app.

In Settings → Owner rules, pick a target and team. Read the preview showing how many findings the rule affects and their current teams, then apply the draft. A rule takes precedence over a team in the source data.

Use Owner team → No owner yet to find unassigned findings. No owner means work needs routing; it is not evidence that a particular person failed to do it.

What changes when we assign a team?

Team ownership affects filters, backlog breakdowns, alerts and Jira routing. It does not automatically give that team access to the app. SecOps is currently available to environment owners and admins.

A fix may span several teams, because a team is not part of its fix identity. Such fixes use the Jira fallback project, as do fixes with no single owner.

Match provider accounts to people

Google Workspace supplies directory identities and whether people are active. Provider accounts are matched by email where possible. In SecOps Settings, open People to link discovered GitHub and Google Workspace accounts to one person and choose a team.

Only those two providers can be linked through that People screen. Other provider account names and activity still appear through their own access sources. Service identities are treated separately from people, so an automated account is not automatically an unmatched employee.

Check ambiguous matches and aliases before interpreting leftover access. A suspended or archived Workspace person is inactive for this comparison. An account that does not match the directory is a reason to investigate, not proof of unauthorised access.

Keep the two ownership questions separate

Linking a person's GitHub account does not assign their repositories' vulnerabilities to their team. A repository owner rule does not establish who owns a credential or whether their access is still needed.

Use Access for account and privilege review, and Working findings for remediation ownership.