Ask any cloud engineer how many applications are running across their environment, and you’ll get a ballpark number. Ask again five minutes later, and they might double it. Not because they’re being evasive, but because they just don’t know the exact number. It’s hard to believe, but between CI/CD pipeline redeployments, zombie workloads, legacy apps in obscure corners of infrastructure, and too many identity providers (IdPs) to count, it’s easy to lose track. When you don’t know what’s running, you can’t manage and secure it. What this isn’t: a governance problem reserved for IAM compliance checklists. What it is: a real-time security gap. Orphaned apps without MFA, apps still relying on legacy authentication, or workloads redeployed by an outdated script are easy prey for bad actors. IAM compliance IAM compliance With everything else becoming continuous — from integration to deployment — discovery should be too. The fragmentation issue In a typical enterprise today, apps are deployed across AWS, Azure, GCP, and maybe a private cloud or two. Even within a single cloud provider, there’s sprawl. Using Google Cloud Platform (GCP) as an example, an application can be deployed in multiple ways . You’ve got options that include App Engine, Cloud Run, Compute Engine, Google Kubernetes Engine, and Apigee Gateway. Other cloud platforms like Azure and Amazon Web Services similarly have many deployment options for application workloads. Some are similar, like Kubernetes support, but other technologies could be unique to that cloud platform. Without a central discovery mechanism, some of these apps can easily fall through the cracks. Even infrastructure-as-code (IaC), like Terraform, doesn’t always capture the whole picture, especially when developers bypass templates for manual deployments or forget to update tags. Of course, there is a similar sprawl for the Identity systems that control access to these application environments. Enterprises can have a mix of Okta, Microsoft Entra ID, and Amazon Cognito, as well as on-premises Active Directory or legacy web access management products, legacy SiteMinder instances, and on-prem Active Directory, often coexisting. Fragmented identity Apps might authenticate against different IdPs depending on when or where they were deployed. For example, a team might choose Okta for internal apps, while customer-facing systems rely on Microsoft Entra ID or Cognito. Entra ID Entra ID The result is a sprawling mesh of credentials, policies, and access patterns that make it nearly impossible to audit consistently. Even knowing whether MFA is turned on for a given app becomes a research project. This level of identity fragmentation is certainly inconvenient, but worse, it’s dangerous. Attackers don’t need to compromise your crown jewels; they just need to find that unguarded door. When apps are deployed without adequate visibility and controls, you are leaving doors wide open. identity fragmentation identity fragmentation Why traditional audits don’t cut it One audit model example involves bringing in a Big Four consultancy, running an audit, generating a report, and calling it a day. The report was already out of date the moment it was emailed. CI/CD pipelines might redeploy decommissioned apps. A dev team might spin up something new without informing security. Or worse, a dormant app with a loose SiteMinder policy might still let anyone with an @company.com email walk right in. What’s more troubling, these audits are inherently narrow in scope. They capture a point-in-time snapshot of a system that is constantly changing. Any meaningful discovery is siloed to the people involved in the audit process and often stored in static documents that nobody revisits until the next round. There’s no continuity, no automation, and no assurance that the data remains accurate beyond the day it was collected. Dollars and security sense Let’s not forget the cost. These assessments often take weeks of effort and hundreds of thousands of dollars. The result is a pretty-looking presentation, with charts and bullet points that look great in a boardroom. But what value do they bring to an engineer trying to track down which IdP governs access to a containerized app running on a forgotten GCP cluster? Meanwhile, attackers aren’t waiting for your next audit cycle. They’re scanning your attack surface, looking for endpoints that your spreadsheet didn’t catch. That’s why the shift to continuous discovery is a necessity today. What does continuous discovery look like? Many security teams are stuck playing blindfolded whack-a-mole with application visibility. They discover one shadow app only to find three more hiding in the cracks. The problem isn’t due to laziness or lack of tooling, it’s that environments are constantly shifting. Between dev teams spinning up new services, CI/CD pipelines redeploying old ones, and infrastructure evolving by the week, maintaining a static inventory is impossible. That’s why continuous discovery scales. It shifts visibility from something you do once a quarter to something you build into the fabric of your operations. Here's what that means: **Cloud-native scanning:**Call into APIs across cloud platforms (GCP, Azure, AWS) to list deployments across services: App Engine, ECS, Lambda, Cloud Run, etc. Identity correlation: Map each app to its IdP, verify MFA enforcement, and catalog authentication patterns (SAML, OIDC, LDAP, header-based, etc.). Identity correlation CI/CD monitoring: Catch apps that reappear after being decommissioned because a pipeline didn’t get the memo. CI/CD monitoring Tagging and classification: Apply metadata to organize by compliance scope (e.g., PCI apps), department, or data sensitivity. Tagging and classification Continuous discovery provides the connective tissue between your infrastructure and your identity architecture. It sets the stage for real-time security posture management, proactive compliance, and efficient incident response. Without it, the next application-related breach may not come from a sophisticated exploit, but instead, something your team didn’t even know was running. Instead of periodic fire drills, continuous discovery treats application visibility as a live process. Real-world use case: The 2,500 vs. 4,500 app guess In one Fortune 500 company, a newly appointed CTO was asked a seemingly straightforward question: "How many applications are in your environment?" "2,500," she answered confidently. Then paused. "Wait, we just acquired another company about the same size. Let’s call it 4,500." That answer didn’t come from a system of record. It was a guess, based on acquisition headcount and a rough assumption of parity. There was no application inventory to consult, no dashboard to confirm the total — just back-of-the-envelope math. And this wasn’t a junior IT analyst. This was a top executive being asked a foundational question about the organization's digital footprint. Scenarios like this are telling because they highlight the absence of a reliable, continuously updated application registry. Without one, companies are forced to rely on memory, manual spreadsheets, and tribal knowledge — all of which fail in dynamic, cloud-based environments. It also uncovers the operational and security risks of uncertainty. If the leadership team can’t quantify the number of apps in play, how can they be sure those apps are secure, compliant, and properly governed? Why should engineers and IAM teams care? Untracked apps are low-hanging fruit for attackers. If you’re managing IAM, and an app is still using basic authentication without MFA, that’s on you, whether you knew about the app or not. And if you’re responsible for keeping things compliant, that six-month-old spreadsheet won’t protect you when an auditor asks for current access and authentication details. With continuous discovery: You know what’s out there
You know who has access
You know if it’s secure You know what’s out there You know who has access You know if it’s secure And you can prove it. The way to keep up with a world of changes Discovery goes far beyond compiling a list. It plays a critical role in surfacing hidden risks—those dark corners of your cloud estate where legacy applications, misconfigured services, or unauthorized deployments may still be running quietly and unnoticed. Overlooked systems can become attack vectors, compliance liabilities, or sources of unexpected cost. Continuous discovery closes the loop, giving security and identity teams a real-time map of their application landscape—what’s running, how it’s secured, and who has access — so they can take decisive action before issues escalate. (As noted, Gerry Gebel is professionally affiliated with a company operating in the identity management and security space. His views reflect his expertise and experience in the industry.) (As noted, Gerry Gebel is professionally affiliated with a company operating in the identity management and security space. His views reflect his expertise and experience in the industry.)

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Cloud Sprawl Is Real. Continuous Discovery Is Your Best Defense

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Modern Authentication Isn’t Enough on It's Own

5 Tips for Integrating Security into Development - Part 1

5 Types of Cyber Security and Why It’s Important to be Aware of Them

Application Security Posture Management: An Overview

Balancing Cybersecurity Risk with Technological Innovation: Using Policy as Code

Modern Authentication Isn’t Enough on It's Own

5 Tips for Integrating Security into Development - Part 1

5 Types of Cyber Security and Why It’s Important to be Aware of Them

Application Security Posture Management: An Overview

Balancing Cybersecurity Risk with Technological Innovation: Using Policy as Code

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps