SaaS digital footprint: what customer-facing infrastructure exposes before anyone attacks
Geert WarmenbolApril 29, 2026
Key takeaways
In Vulnox assessments, the average SaaS company has 11 externally reachable assets its own engineering team cannot name -- staging servers, forgotten OAuth endpoints, internal dashboards -- each one a potential entry point.
Exposed .git directories on production servers allow an attacker to download full source code and credentials in under two minutes. This shows up in roughly 4 in 10 SaaS assessments.
SOC 2 Type II audits check for evidence of continuous monitoring, but a monthly vulnerability scan does not satisfy that standard. The gap between what auditors accept and what the requirement actually demands is where most SaaS companies sit.
Multi-tenant SaaS platforms fail data isolation at the support portal layer more often than at the API layer. The support tooling gets less architectural scrutiny than the product itself.
Digital footprint assessments run before a vendor questionnaire response produce materially different answers than those run after. Most SaaS companies discover their worst exposures during a prospect's security review, not their own.
TL;DR
SaaS companies spend most of their security budget on the application layer and almost none on what is visible before anyone touches a login screen. The external footprint -- subdomains, staging servers, CI/CD artifacts, internal tooling accidentally exposed to the internet -- is where attackers start. Most SaaS teams have not mapped it accurately since the last major infrastructure change. That is the gap this article addresses.
The asset the customer found before you did
A 60-person SaaS company was three weeks from closing an enterprise deal when the prospect's security team sent over a spreadsheet. Fourteen rows. Each one was a subdomain or endpoint belonging to the SaaS vendor that the vendor's own infrastructure team could not immediately explain. A staging environment with a different SSL certificate. A Grafana dashboard on a non-standard port requiring no authentication. A webhook receiver that had been deprecated internally eight months earlier but was still responding to requests. The security team lead described it later: 'We thought we knew what we had. Apparently we knew what we built, which is different.'
The deal did not collapse, but it got delayed by six weeks while the vendor remediated and produced evidence. The cost was not a breach. It was the gap between what the company believed about its own perimeter and what a moderately thorough external scan revealed in 40 minutes.
Why the footprint grows faster than the inventory
SaaS infrastructure accretes. A new microservice gets a subdomain. A demo environment gets spun up for a sales call. A third-party monitoring tool gets its own endpoint. An acquisition brings in a different cloud account. None of these individually are incidents. Collectively, they produce an external surface that is usually larger by 30 to 50 percent than what appears in any internal asset register -- based on what Vulnox passive recon consistently returns against client-provided asset lists.
The mechanism is not negligence. It is velocity. Teams deploying multiple times per week cannot maintain a real-time asset inventory through manual processes. The inventory is always a snapshot of what existed at the last audit cycle, which is a minimum of several months behind the live environment.
What an attacker using passive recon tools sees is not your internal inventory. It is the DNS record set, the SSL certificate history, the port scan results, and the HTTP response headers on every IP block your ASN owns. They see everything that has ever been published, including assets you stopped thinking about.
Example
Certificate transparency logs are public and append-only. Every SSL certificate ever issued for a domain is recorded there, including certificates for subdomains that no longer exist in your DNS. An attacker using crt.sh against a SaaS company's primary domain gets the full historical subdomain list for free, including the staging environment that got decommissioned from DNS but whose server is still running because someone forgot to terminate the instance.
This is not a sophisticated attack technique. It requires no credentials, no prior access, and no specialized tooling beyond a browser and a free API query. It is the first step in almost every external reconnaissance workflow, which is why it keeps producing findings in assessments despite being entirely preventable.
What the assessments actually show
Assessment base: Vulnox digital footprint assessments, 2023-2024, SaaS companies across B2B, fintech-adjacent, and healthcare SaaS segments
Unknown asset count consistently exceeds client estimates
When Vulnox runs passive recon against a SaaS company's primary domain and ASN before the client provides their own asset list, the external-facing asset count averages 11 assets higher than what the client lists. The gap is not always critical infrastructure -- it often includes deprecated endpoints, internal tooling, and old staging environments -- but any reachable asset is a potential entry point.
The asset inventory is not a security control. It is documentation. If you are making security decisions based on an inventory that is six months old and manually maintained, you are making decisions about a different environment than the one attackers can reach.
.git and .env directory exposure on production servers
In Vulnox assessments, roughly 4 in 10 SaaS companies have at least one production server where the .git directory or .env file is accessible over HTTP without authentication. This is not a finding that requires any exploitation -- it requires typing a URL. The .git directory exposes full source code history. The .env file commonly contains database connection strings, third-party API keys, and internal service credentials.
This finding survives because deployment pipelines move fast and the check is not automated. The developer who set up the server did not expose it intentionally. The CI/CD pipeline that deployed the application did not check for it. The vulnerability scanner that ran last quarter checked for CVEs, not for directory listing on paths that are not in the scanner's default wordlist.
Support portal data isolation failures in multi-tenant platforms
Multi-tenant SaaS products generally receive significant architectural scrutiny at the API and database layer for tenant isolation. The support portal gets less. In assessments of SaaS platforms with more than 500 enterprise customers, Vulnox found that impersonation or 'view as customer' functionality in support tooling had inadequate scope controls in the majority of cases -- allowing support staff access to data beyond the ticket they were working on, and in some cases allowing horizontal access across tenants with a single parameter change.
The attackers who want your customer data are not necessarily trying to exploit your authentication system. Compromising one support account -- through phishing, credential stuffing, or a session token leak -- is often sufficient if the support tooling does not enforce least-privilege data access at the query level.
Staging environments with production data subsets
SaaS engineering teams copy production data to staging for realistic testing. This is operationally understandable. The staging environment then gets a less-monitored security posture, fewer authentication controls, and in several Vulnox assessments, a subdomain that is publicly resolvable and not behind any access control. The data in staging is often a recent snapshot of production, meaning customer PII, contract terms, and usage data are all accessible to anyone who finds the subdomain.
The argument that staging is temporary does not hold. Staging environments in SaaS companies typically outlive the feature they were built to test by months. 'Temporary' infrastructure with production-grade data and development-grade security is a permanent misconfiguration.
The finding that surprises every client: cloud security is not perimeter security
Common belief
Most SaaS security leads we work with start the engagement believing their cloud provider's network controls -- VPCs, security groups, WAF rules -- are the equivalent of a hardened perimeter. The reasoning is: traffic that does not match the rules does not get through, so everything inside the perimeter is protected.
What we found
In one assessment, a SaaS company had a security group configuration that was genuinely tight -- only ports 80, 443, and 22 from a bastion, exactly as it should be. They also had a subdomain serving their internal metrics dashboard over port 443 with no authentication, because it had been set up for a demo and the DNS entry was never removed. The security group did not protect against this because the security group had no reason to. The exposure was at the application layer, visible from any browser.
Cloud security groups and VPC rules control network layer traffic. They do not control what your application exposes over port 443, which is what everything is on. An internal Grafana dashboard served over HTTPS on a subdomain with no authentication is completely invisible to a security group that only restricts traffic to known ports. The firewall sees HTTPS traffic to a web server. That is allowed. What the web server returns is the application's responsibility.
The shared responsibility model means the cloud provider secures the infrastructure layer. The SaaS company is responsible for what the application exposes. These are categorically different problems. One is solved by configuration. The other requires knowing what you built.
Where SaaS digital footprint assessments find what internal teams miss
Certificate transparency history
Internal teams audit their current DNS. Certificate transparency logs record every certificate ever issued, including subdomains that have been removed from DNS. An environment decommissioned from DNS but still running is invisible to an internal DNS audit and visible in 30 seconds to an external attacker using crt.sh.
Third-party integration callback endpoints
Webhook receivers, OAuth callback handlers, and payment processor integration endpoints get created during vendor onboarding and often outlive the vendor relationship. They are rarely in the asset inventory because they were added by a developer in the context of a specific integration, not by the infrastructure team. They frequently have no authentication beyond a shared secret that has not rotated since the integration was built.
Acquired company infrastructure
Post-acquisition infrastructure integration is almost always incomplete at the security layer. The acquired company's domains, subdomains, and cloud accounts exist in a different inventory, under different ownership, with different security policies. Vulnox assessments of companies that have made acquisitions in the prior 24 months consistently return the highest asset-gap numbers.
Open source dependency exposure through package metadata
Publicly accessible package.json files, requirements.txt, or Gemfile.lock files on staging servers or in exposed .git directories reveal exact dependency versions. An attacker does not need to scan for vulnerabilities. They can read the manifest, cross-reference known CVEs, and arrive at the engagement knowing which vulnerabilities the application is carrying.
Where SaaS footprint risk is heading
Vendor security questionnaires will include automated digital footprint scans as a pre-qualification step within three years. SaaS companies that have not run their own assessment will be caught off guard when a prospect's tool returns findings the vendor cannot explain.
Enterprise procurement teams are adding automated external scanning to vendor onboarding workflows. Several large financial services firms already do this as part of third-party risk management. The tooling to run a passive footprint scan has become cheap enough that mid-market buyers will adopt it. The SaaS companies that currently find their worst exposures during prospect reviews will start losing deals because of it.
Confidence: highIf, by 2027, fewer than 30 percent of enterprise software vendor questionnaires include any automated external scan component, this prediction is wrong.A significant SaaS breach will be traced publicly to a CI/CD artifact leak -- a build log, a deployment manifest, or an exposed artifact repository -- rather than to a direct application vulnerability. This category of exposure is not yet on most security teams' radar as a primary breach vector, but the infrastructure for it is in place at the majority of SaaS companies.
CI/CD pipelines now contain some of the most sensitive data in a SaaS company: production credentials injected as environment variables, internal service URLs, signing keys, and deployment scripts. These pipelines are also the area where security investment has lagged the most. Build logs get written to locations developers can read, which sometimes means locations that are more broadly accessible than intended. This has not produced a widely publicized breach yet. The structural conditions for one are present.
Confidence: mediumIf no breach in the 2025-2028 period is publicly attributed to CI/CD artifact exposure as the initial vector, this prediction is wrong.
The argument I keep having with myself about continuous monitoring
The standard advice in this space is: implement continuous external attack surface monitoring. Run automated scans. Get alerting. This advice is correct and I give it to clients. But it addresses the symptom, not the structural problem.
The reason SaaS companies accumulate unknown external assets is not that they lack monitoring tooling. It is that the process for creating infrastructure has no mandatory exit step. A developer spins up a staging environment, uses it, and moves on. There is no decommission checklist. There is no DNS cleanup step in the offboarding workflow. There is no quarterly review that asks 'what did we create in the last 90 days and is any of it still running?'
Continuous monitoring catches the gap after it exists. The better fix is process -- making sure that infrastructure creation and infrastructure destruction are equally formal. This is harder to sell because it requires changing how engineering teams work, not buying a tool. But the companies with the smallest footprint gaps are not the ones with the best monitoring. They are the ones with the most disciplined infrastructure lifecycle processes.
Counterargument
The counterargument is that in a company deploying multiple times per week, a formal decommission process for every asset creates overhead that slows engineering. That is a real trade-off. My answer is that the overhead is not uniform -- the cost of a decommission checklist is minutes, while the cost of a breach traced to a forgotten staging environment is months. The asymmetry is not close enough to justify skipping the checklist.
One thing to do this week
Run a passive recon query against your primary domain using crt.sh. Enter your domain, look at the full certificate history, and identify every subdomain that appears there. Cross-reference that list against your current DNS records. The subdomains in the certificate log that are not in your DNS are your first list of unknown assets -- servers that may still be running, endpoints that may still be responding, environments that your team stopped thinking about but an attacker has not. Do this before your next prospect security review does it for you.
Further Reading
Digital Footprint
digital footprint analysis serviceGap Analysis
SOC 2 gap analysisNIST Vulnerability Assessment Definition
NIST vulnerability assessment definitionOWASP Web Security Testing Guide
OWASP security testing guideSOC 2 Compliance Guide Vanta
comprehensive SOC 2 compliance guide
Frequently Asked Questions
What is a SaaS digital footprint assessment and what does it find?
A digital footprint assessment maps every externally reachable asset associated with a SaaS company's infrastructure -- subdomains, API endpoints, staging servers, internal tools accidentally exposed to the internet -- using passive recon techniques like certificate transparency logs, DNS enumeration, and port scanning. In Vulnox assessments, the average SaaS company has 11 externally reachable assets its own team cannot name before the assessment begins.
Why do SaaS companies have more external assets than they think?
SaaS infrastructure accretes faster than asset inventories are updated. Demo environments, microservice subdomains, third-party integration endpoints, and acquired company infrastructure all add to the external surface without always going through a formal registration process. The inventory reflects what was built; passive recon reflects what is still running.
How do exposed .git directories on production servers get exploited?
A .git directory accessible over HTTP lets an attacker download the full version-controlled source code of an application, including historical commits. .env files found alongside or within the repository commonly contain database connection strings, API keys, and internal service credentials. This requires no authentication and no exploitation -- only a URL that the server responds to.
Does SOC 2 compliance require continuous external attack surface monitoring?
SOC 2 Type II audits evaluate whether controls operate continuously over the audit period. Point-in-time vulnerability scans do not satisfy the continuous monitoring standard. Most SaaS companies sitting for SOC 2 have implemented periodic scanning and documented it as continuous monitoring. Auditors who are not technically deep often accept this. Auditors who are, do not.
What is the most commonly missed SaaS digital footprint exposure?
Certificate transparency logs record every SSL certificate ever issued for a domain, including subdomains removed from DNS. An environment decommissioned from DNS but with the server still running is invisible to internal DNS audits and visible in under a minute using crt.sh. This is the most consistent gap Vulnox finds between client-provided asset lists and passive recon results.
How do staging environments become a data protection liability for SaaS companies?
Engineering teams copy production data subsets to staging for realistic testing. The staging environment then operates with weaker authentication controls, less monitoring, and sometimes a publicly resolvable subdomain. 'Temporary' staging environments in SaaS companies typically outlive the feature they were built to test by months. The result is production-grade customer data accessible through a development-grade security posture.
What should a SaaS company do before responding to a vendor security questionnaire?
Run a passive digital footprint assessment against your own primary domain before the prospect's security team does it for you. At minimum, query certificate transparency logs via crt.sh, enumerate subdomains, and cross-reference against current DNS. Any subdomain in the certificate history that is not in your current DNS records is a potential unknown asset. Discovering these during a prospect review rather than before it extends deal cycles and raises questions that are hard to answer under time pressure.
Related Articles
Basic digital footprint check: what free tools find and what they miss
A basic digital footprint check using free tools takes less than an hour and reliably surfaces subdomains, certificate history, and indexed content. What it misses — assets with no DNS record, credential material in archived repositories, and vendor-created infrastructure — is where the regulatory exposure lives.
Digital footprint exposure and data protection risk: what regulators find that internal teams miss
Forgotten subdomains, undocumented SaaS integrations, and exposed API keys are data protection violations waiting to be discovered -- by a regulator, not your internal team. Vulnox assessments found at least one forgotten subdomain in 71% of environments reviewed. Here is what that exposure looks like through a regulatory lens.
How your digital footprint cyber risk score is actually calculated
Most organizations do not know which external assets are dragging their cyber risk score down until an insurer tells them. Here is what the scoring models actually weight, and what DFA data shows about where the gaps are.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.