veriomServices, deployments, and dependency impact
Connect root causes to affected services and inspect the evidence behind deployment and dependency associations.
The inventory connects reviewed architecture to the teams and environments responsible for it. Evidence strength stays visible at each step.
Trace a root cause
Open the Root-cause explorer from reviewed structural context. Select an affected entity to inspect its relationships, related findings, source evidence, and associated remediation programs.
Follow the evidence references before interpreting a path as reachable. A graph edge summarizes a supported relationship or an explicitly qualified inference; missing evidence and contradictions remain part of the result. Selecting an entity narrows the inspected relationships and evidence rather than changing the underlying review.
Maintain the service inventory
Open Service inventory to see the workspace's recorded services. Refresh from an existing audit to reuse retained architecture evidence. Where your role permits, add a service, update its owner or repository association, and record a deployment.
Service ownership identifies responsibility. It does not grant workspace membership or establish provider permissions.
Distinguish deployment evidence
| State | What it establishes |
|---|---|
| Observed | Retained deployment evidence matches the service or repository, environment, event, and deployed facts |
| Attested | A producer asserts the deployment, but matching retained proof is incomplete |
| Declared | A person records the intended or known deployment without provider observation |
| Unknown | The required deployment information has not been established |
A branch name in a manifest is not proof of a live deployment. Compare environments using their recorded commits, image digests, timestamps, evidence state, and discrepancies. Keep declared and observed differences distinct.
Inspect dependency impact
Search Dependency impact by package or vulnerability reference. Open a result to inspect the package version, SBOM source, repository or service, audit revision, vulnerability evidence, and any deployment association.
There are separate questions:
- Is the package present in the assessed source or SBOM?
- Does a recorded deployment correspond to that assessed commit or artifact?
- Is the vulnerable behavior reachable or executed in that environment?
An SBOM answers the first question. Matching deployment evidence can support the second. Neither automatically answers the third. Runtime reachability stays unknown when the supporting evidence is missing, and an association alone does not promote an advisory into reviewed architectural impact.
For repeatable revision comparisons, use repository reviews. For coordinated remediation, continue to reports and remediation.
Was this guide useful?
Your response stays in this browser unless you open a GitHub issue.