To find the owner of an untagged vulnerable asset, follow the build trail: image source and revision annotations, then the repository and its commit history, then the account or site owner. Record whatever you find as a tag straight away, so the next finding routes itself.
The lookup order
Go from the most reliable evidence to the least.
- Image annotations. The OCI spec defines
org.opencontainers.image.sourcefor the URL of the source andorg.opencontainers.image.revisionfor the revision. If present, you have the repository and commit. - Repository ownership. Read the repository's owners file or team settings, and look at who merged recent changes.
- Deployment records. The pipeline that deployed the asset, or the infrastructure code that defines it, often names a team.
- Naming conventions. Names may carry a team prefix. Treat that as a lead, not proof.
- Account or site owner. The owner of the account is accountable for what runs in it, even if they did not build it.
- Network and access clues. Which systems talk to it, and which identities have deploy access.
Record what you find
| Evidence | Confidence | Next step |
|---|---|---|
| Source annotation plus owners file | High | Assign directly |
| Deployment pipeline owner | Medium | Confirm with the team |
| Name prefix only | Low | Ask the likely team |
| Account owner only | Fallback | Ask them to find the builder |
Always ask the likely owner to confirm. A wrong assignment wastes days.
When nobody claims it
If no one admits ownership, do not close the finding. Options in order:
- Assign it to the account owner with a deadline for finding the builder.
- If the asset is exposed to the internet and nobody can justify it, plan to isolate or remove it, following your change process.
- Add it to a visible list of orphans, reviewed in the weekly meeting.
Stop it happening again
- Require tags in templates. The AWS tagging guidance describes tags as the mechanism to track which resources are assigned to which application, including for patching and incident management.
- Add annotations to builds. Make source and revision part of the shared pipeline template.
- Report coverage. Track the share of assets with an owner and drive it up.
- Block new untagged assets where the platform allows policy checks.
An example trail
A scan flags an old image with no tags. Its source annotation points to a repository that was archived last year, but the owners file still lists the data engineering team, and the deployment pipeline posts to their channel. A message to that channel gets a reply the same day: the job is retired, nobody switched it off. The image is isolated, then removed through the normal change process, and the finding closes with a note.
Quick check
Is the person who last committed the owner?
Not necessarily. They are a lead. Confirm with the team and record the team, not the person.
Can I delete an asset nobody owns?
Follow your change process. Isolating it first and watching for complaints is safer than immediate deletion.
Safeguard's asset discovery can enumerate what runs, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
