Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

An inventory tells you what exists in a cloud environment. It does not, by itself, show how an attacker might move from an exposed weakness through permissions and connected resources to sensitive data. Cloud security teams need both: a dependable asset inventory and the relationships that make its risks understandable.

Why relationships change what an asset list can tell you

A cloud resource rarely carries its risk in isolation. Its importance depends on facts around it: whether it is reachable from the internet, whether it has a vulnerability, which identities can access it, what those identities can reach next, and whether the chain leads to sensitive or critical data.

A security graph connects those facts so a team can reason about possible routes through an environment. Microsoft Learn describes the cloud security graph in Microsoft Defender for Cloud as “a graph-based context engine” and documents its use in security exploration and attack-path analysis. That is one documented product approach, not proof that every graph or security product captures the same relationships.

Inventory remains essential: a team cannot protect resources it does not know about. The point is that inventory answers “what is here?” while relationship context helps answer “what could this resource lead to, and why does that matter?”

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

What an attack path means

Microsoft Learn defines an attack path as “a series of steps a potential attacker uses to breach your environment and access your assets.” In practice, this is a risk-analysis model: a plausible chain inferred from an environment’s configuration and observed conditions, not a claim that an attacker has already taken that route or that every breach follows one pattern.

A simplified example

  1. An internet-reachable resource has a vulnerability that could be exploited.
  2. An identity or permission associated with that resource can access another cloud resource.
  3. That access provides a possible step toward a database or other sensitive asset.

Looking at each item separately can make the issue seem like several unrelated findings: an exposed resource, a vulnerability, a permission, and a database. Looking at the connections reveals why the sequence may warrant attention. Microsoft says its prioritization considers factors including internet exposure, permissions, and lateral movement; detection and prioritization depend on the configuration and signals available in the particular environment.

How to turn relationship context into security work

A useful review turns a path into a specific, testable question: which connection makes the route possible, and what change would interrupt it? A long path is not automatically more serious than a short one, and a finding is not proof of exploitability. Validate the conditions before assigning urgency.

  1. Start with a high-value target. Identify the data store, workload, or other resource whose exposure would matter most to the organization.
  2. Trace backward from that target. Look for identities, permissions, network reachability, and dependent resources that could provide a route to it.
  3. Check the entry conditions. Confirm whether the proposed starting point is externally reachable and whether the cited vulnerability or configuration issue applies to the deployed resource.
  4. Verify each permission and connection. Check the actual identity, scope, and service configuration rather than assuming that a graph edge alone demonstrates usable access.
  5. Choose a remediation that breaks the route. Depending on the verified cause, that may mean removing unnecessary access, correcting a configuration, restricting reachability, or addressing a vulnerability. Then reassess whether another route remains.

This makes the unit of work more useful than “close another alert”: it is a validated risk path, its enabling relationships, and a change that removes or reduces those conditions.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Why customer responsibility still matters

Relationships are useful only when the team can change the controls they expose. Cloud security responsibility is divided differently across service models, but it does not disappear when a provider operates more of the stack.

Microsoft Learn’s shared-responsibility guidance, last updated August 24, 2026, assigns customer responsibility for data, configurations and settings, and identities and users across on-premises, IaaS, PaaS, and SaaS. Responsibility for applications, network controls, operating systems, and physical infrastructure varies by service model. Microsoft presents its matrix as governance guidance about configuring, operating, and monitoring controls; it is not legal advice and does not alter contractual agreements.

AWS describes the division as “Security of the Cloud” for provider infrastructure and “Security in the Cloud” for customer duties determined by the services selected. Its examples show why a generic cloud-wide rule is insufficient:

Service example Provider role described by AWS Customer responsibilities described by AWS
Amazon EC2 Secures the underlying cloud infrastructure. Manages the guest operating system, application software, and security-group firewall configuration.
Amazon S3 or DynamoDB Runs the infrastructure and abstracted platform layers. Manages data and its classification, encryption choices, and appropriate IAM permissions.

AWS’s examples are not substitutes for checking the selected service and use case. A graph can show a permission or route, but ownership determines who can validate and remediate it.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Why identity and permissions deserve close attention

Cloud access is granted to both people and software. Application and workload identities can accumulate permissions just as human accounts can, so permission review should account for both kinds of identity and for whether access is still needed.

Microsoft Security Blog’s May 29, 2024 summary of its 2024 multicloud risk report said that, in Microsoft’s analysis of cloud-security product usage, more than 50% of cloud identities had access to all permissions and resources in 2023. The same vendor summary reported that workload identities made up 83% of identities in Microsoft Entra Permissions Management and that 40% of those workload identities were inactive, defined as having no login or permission use for at least 90 days. These figures describe Microsoft’s analyzed product population and period; they are not independent estimates of prevalence across all cloud estates.

The operational lesson is to ask what each identity can reach, whether that access is necessary, and whether the identity remains in use. AWS guidance recommends least-privilege access for application identities, IAM roles, avoiding policy wildcards, scanning policies, and using reusable infrastructure as code to make safer patterns repeatable.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

What the multicloud figures do—and do not—show

Microsoft’s May 2024 blog summary reported that 86% of organizations had adopted a multicloud approach. It also reported an average of 351 exploitable attack paths to high-value assets per multicloud estate and more than 6.3 million exposed critical assets across organizations. These are figures reported by Microsoft in a vendor summary of analysis across its security products; the summary does not establish that every organization has these conditions or that the figures represent an independently sampled universal rate.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The figures illustrate why disconnected inventories can be difficult to prioritize at scale, but they do not establish which tool performs best, how much a deployment costs, or what any particular organization will find. Teams should use their own verified configurations and exposure to determine their risks.

How to assess a graph or attack-path workflow

Whether using a platform feature or an internal process, assess whether it helps answer the questions needed to act:

  • Does it connect inventory to identities, permissions, internet exposure, network links, vulnerabilities, and sensitive targets?
  • Can analysts trace a plausible route from an entry point to a critical resource and see why it was prioritized?
  • Can the team validate reachability and configuration conditions instead of treating a displayed path as proof of compromise?
  • Does the workflow account for different cloud providers and service models, including controls the customer retains?
  • Do findings point toward changes that break or reduce a path, rather than adding another alert without ownership?
  • Can application teams build least-privilege access and policy review into development workflows?

Microsoft documents configuration analysis, reachability checks, and suggested remediations for its Defender for Cloud feature. That describes its documented capabilities, not an independent comparison or a guarantee that a recommendation will fit every environment.

Make the relationships actionable

Organizations can distribute security ownership between cloud and application teams, translate requirements into controls, document developer guidance, and create reusable implementation patterns. AWS specifically recommends artifacts such as reusable infrastructure as code alongside least-privilege identity practices. This helps connect a finding to the team that controls the relevant permission, network rule, configuration, or code.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The practical goal is not a bigger graph for its own sake. It is a clearer explanation of how a weakness could matter, a responsible owner for the relationship that enables it, and a verified change that reduces the route to valuable assets.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.