To map a repository to the production asset it runs as, follow the build and deploy trail: from the repository to the pipeline, to the image or artifact, to the workload, to the service and its public address. Record the link once, then reuse it for every finding that repository produces.
The mismatch
Dependency scanners usually report findings against repositories. Exposure, data and business role belong to deployed services. One repository may deploy to several services. One service may be built from several repositories. Without a link, a finding in a library sits on a code project that has no exposure label.
The CVSS v4.0 specification notes that Environmental information is available only to the end consumer. For code, that means the context lives where you deploy it, not where you store it.
The trail
| Hop | Where to look |
|---|---|
| Repository to pipeline | CI configuration file in the repo |
| Pipeline to artifact | Image name, package name or bundle in the build step |
| Artifact to workload | Deployment manifest, release config, function config |
| Workload to service | Service, route or load balancer definition |
| Service to exposure | Public hostname, ingress rule, gateway |
Follow each hop and write down what you find.
Steps
- Start with your most important services, not all repositories.
- For each, find the artifact name in the deployment configuration.
- Search pipelines for builds that produce that artifact.
- Record the repository, or repositories, that feed it.
- Add the repository path to the asset record, and the asset ID to the repository metadata if you can.
Handling the awkward cases
One repository, many services. A monorepo may deploy dozens of services from different directories. Map by directory, not repository, so findings in one folder do not inherit the exposure of another.
Shared libraries. A library repository may not deploy anything itself. Map it to every service that consumes it, and rank a finding by the most exposed consumer.
Forks and vendored code. Code copied into another repository belongs to the consumer. Map it there.
Unmapped repositories. Some repositories deploy nothing, such as documentation or samples. Mark them as non deployed so they stop adding noise. Check that claim, because some contain scripts that run in pipelines.
Keep the link current
Mappings drift when someone renames an image or splits a service. Add a check that flags deployed artifacts whose source repository is unknown, and repositories that claim to be deployed but have no recent release.
Using the map
Once the link exists, a finding in a shared library can be shown with the services that consume it, their exposure and their data label. That gives the person fixing it a reason to act and the person approving it a reason to say yes.
Test your map
Pick one service and trace backward to its source, then pick one repository and trace forward to where it runs. If both traces agree, your map is working. If not, you have found a gap.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning and asset discovery, which can help connect components to the applications and assets that use them. Safeguard also offers a free scan at gold.safeguard.sh/scan if you want to see your own dependency findings first.
Try it yourself
Click through it at your own pace, or open it full screen. Follow how a dependency in one place connects to the applications that consume it.
Quick check
What if I cannot find which repo builds a service?
Mark the service as source unknown and treat that as a finding. It means nobody can fix it quickly.
Should shared libraries inherit exposure?
Rank them by their most exposed consumer, and list every consumer.
Sources
Last reviewed: 19 October 2026.
