How to Check Your Organisation's Public Footprint and Breach Exposure

To check your organisation's public footprint, start from the domains you own and collect what anyone on the internet can already see about them: hostnames and subdomains in DNS and certificate transparency logs, the services those hosts answer on, and the company email addresses that appear in public sources. Then check your company's own addresses against breach data, record each item as a finding with an owner, and repeat the check on a schedule, because the footprint changes every time someone ships a new host or signs up for a service with a work address. Safeguard's OSINT scan does the collection from the CLI: you pass a domain you own, confirm you are authorised, and the results upload to a project in your console next to your other findings.

This guide is for the security engineer or AppSec lead who has been asked "what does an attacker see when they look at us from the outside?" and needs an answer that is better than a guess. The first two thirds work with any tooling, or none: what the standards expect, what "public footprint" and "breach exposure" mean for an organisation rather than for a person, where the line sits between checking your own exposure and profiling people, and a step by step process with a checklist and a triage table. Then it shows the Safeguard flow as the OSINT docs describe it, and what Safeguard does not do.

One boundary up front. Everything here is about an organisation looking at its own domains, its own hosts and its own company mailboxes. It is not about researching individuals, and nothing in this post explains how to compile information on people. If a check would tell you something about a specific person's life rather than your company's systems, it is out of scope.

Key takeaways

• Start from what you own. Your registered domains are the seed. Every host, subdomain and company address in scope should trace back to one of them.
• Attackers do this first. Reconnaissance is the opening tactic in MITRE ATT&CK, and much of it uses public sources the target never sees being queried. Doing the same lookups on yourself is the cheapest way to see what they see.
• Certificate transparency is a public subdomain list. Every publicly trusted TLS certificate is logged, so internal sounding hostnames on public certificates are already disclosed.
• Breach exposure is about the organisation's accounts. For a company, the useful question is which company addresses and which company services appear in known breach data, so the owners can rotate, enforce MFA and close stale accounts.
• Never store the credential. Record the fact of exposure, not the password or token. Handle anything you find as you would any other sensitive security data.
• Safeguard OSINT scan (GA): a Safeguard CLI command that captures a target's public footprint and its data leak and breach exposure from public data sources, without probing your systems. It needs explicit authorisation on every run and uploads findings to a project in your console.
• Breach data providers run only with your own API key, so nothing paid or legally sensitive runs implicitly, and Safeguard's docs say no credential value is ever stored in a finding.
• Safeguard Network Scan (GA) covers the next step for exposed services: open ports, service versions and known CVEs on hosts you own, run from a machine inside the target network. Both are part of Safeguard's VAPT scans from the CLI (GA).

The situation

The question usually arrives in one of a few ways. A board member reads about a breach that started with a forgotten test server and asks whether that could happen here. An auditor asks how the asset inventory is kept complete, and the honest answer is that it covers what the cloud console shows, not what the internet shows. A customer security questionnaire asks whether you monitor for exposure of company credentials in third party breaches. Or an incident at a SaaS vendor lands in the news, and someone wants to know how many company accounts were on it.

The gap is nearly always the same. The internal inventory lists the systems the infrastructure team built on purpose. The public footprint also includes the marketing site a contractor stood up on a subdomain, the staging host with a public certificate, the old mail relay still answering on a forgotten IP, the support portal a business unit bought with a credit card, and the many third party services where staff signed up with a work address. None of that is secret. Most of it is listed in public DNS, certificate logs and search indexes for anyone who looks.

A bad week looks like this: someone outside finds a host you did not know you had, running a version you did not know you ran, or company credentials from someone else's breach are tried against your sign-in page and one works because the account never moved onto MFA. This post is about finding those things on your own schedule instead.

What the standards expect

This section summarises primary sources. It is not legal, regulatory or audit advice; check the current text for your obligations.

NIST Cybersecurity Framework 2.0: know your assets and your exposure

The NIST Cybersecurity Framework 2.0 puts asset knowledge at the start of the Identify function. Its Asset Management category (ID.AM) asks organisations to maintain inventories of hardware (ID.AM-01), of software, services and systems (ID.AM-02), and of services provided by suppliers (ID.AM-04). The Risk Assessment category (ID.RA) asks that vulnerabilities in assets are identified, validated and recorded (ID.RA-01) and that cyber threat intelligence is received from information sharing forums and sources (ID.RA-02).

A public footprint check feeds both. It is a reality check on ID.AM, because anything you find on the internet that is not in the inventory is an inventory gap. And it is a source for ID.RA, because an exposed host or an exposed company account is a weakness you can now record and track.

NIST SP 800-115: passive discovery is a legitimate part of an assessment

NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, separates review techniques, which passively examine systems, documentation and configuration with minimal risk to the systems involved, from target identification and analysis techniques. For network discovery it describes both passive and active approaches, and notes that passive discovery can reveal devices without sending a single probing packet. Its Appendix B gives a Rules of Engagement template, which is the written authorisation every assessment should start from.

That split maps directly to this post. Collecting your public footprint from public sources is passive with respect to your systems. Checking which ports and services your hosts expose is active, and should run with the same written authorisation as any other scan.

NIST SP 800-63B: check credentials against breach data

NIST SP 800-63B-4, the digital identity guideline for authentication, says in Sec. 3.1.1.2 that verifiers shall compare a new password against a blocklist of commonly used, expected or compromised values, and lists passwords from previous breach corpuses as an example. It also says verifiers shall force a password change if there is evidence the authenticator has been compromised. The blocklist requirement is about the password at the moment it is set. The organisational version of the same idea is broader: if a company account appears in a known breach, the account owner should be told, the password should be changed if it could have been reused, and the account should be on phishing resistant MFA.

MITRE ATT&CK: reconnaissance comes first

MITRE ATT&CK lists Reconnaissance as tactic TA0043, the first stage before initial access. ATT&CK describes it as adversaries actively or passively gathering information to support targeting. Its techniques include Gather Victim Identity Information (T1589), with sub-techniques for Credentials (T1589.001) and Email Addresses (T1589.002), and Search Open Technical Databases (T1596), with sub-techniques for DNS and passive DNS (T1596.001), Digital Certificates (T1596.003) and Scan Databases (T1596.005). For T1589, ATT&CK's mitigation note says the behaviour happens outside the scope of enterprise defenses and controls, so efforts should focus on minimising the amount and sensitivity of data available to external parties.

Reading those technique pages is a good way to build your checklist, because they describe exactly what an adversary gathers. The defensive translation is: look at the same sources for your own organisation and shrink what is there.

OWASP Web Security Testing Guide: information gathering

The OWASP Web Security Testing Guide v4.2 opens its testing methodology with Information Gathering (section 4.1). Its first test, Conduct Search Engine Discovery Reconnaissance for Information Leakage (WSTG-INFO-01), sets the objective of identifying sensitive design and configuration information about the application, system or organisation that is exposed directly on its own website or indirectly through third party services. A later test (4.1.4) covers enumerating the applications on a web server. If your AppSec team already uses the WSTG for application testing, the footprint check is its first chapter applied to the whole organisation.

Certificate transparency: your subdomains are already public

RFC 6962 defines Certificate Transparency, a system of public, append only logs of issued TLS certificates, designed so that anyone can audit which certificates a certificate authority has issued. The side effect matters for footprint work: every hostname on a publicly trusted certificate becomes publicly listed. If your team issues a public certificate for a staging or admin host, the name is disclosed the moment the certificate is logged, whether or not DNS for it is public.

FTC Safeguards Rule and CISA services: US context

For US financial institutions under the FTC's jurisdiction, the Safeguards Rule at 16 CFR 314.4 requires a written information security program with a risk assessment, and either continuous monitoring or periodic penetration testing and vulnerability assessments. A footprint check does not satisfy those requirements on its own, but it is a natural input to the risk assessment and to scoping the tests.

CISA's Cyber Hygiene Services are available at no cost to US federal, state, local, tribal and territorial governments and to public and private sector critical infrastructure organisations. Their Vulnerability Scanning service continuously monitors internet accessible assets, and the same page recommends identifying assets that are searchable via online tools and taking steps to reduce that exposure. That framing is useful even if you are not eligible: look at your organisation from the internet's side, repeatedly, and fix what is exposed.

What "public footprint" means for an organisation

"Footprint" is a vague word. For a security program it helps to break it into parts you can list, own and close.

Domains and registrations

The seed is the list of registered domains the organisation owns. It is rarely complete. Domains get registered by marketing for a campaign, by a product team for a launch, by an acquired company years ago, by a regional office. Each one can carry live DNS, mail records and hosts.

Start the list from the registrar accounts finance pays for, the DNS zones you host, and the domains on your TLS certificates. Add the domains of acquired companies. Mark each one as active, parked or due for retirement. A parked domain still needs an owner, because it can still receive mail and still be used to send it if records allow.

Hosts and subdomains

Under each domain sit the hostnames. Some are deliberate: www, mail, the API, the status page. Others are leftovers: a test environment, a demo for a trade show, a vendor's hosted portal on a CNAME to your domain. Public sources for hostnames include public DNS, certificate transparency logs and search engine indexes.

The two risks to look for are hosts nobody owns and hosts that point somewhere you no longer control. A CNAME that points at a cloud resource or a SaaS tenant that was deleted can let someone else claim that resource and serve content on your subdomain. The fix is ordinary hygiene: remove DNS records when the thing they point to is retired.

Exposed services

A host is only part of the story. The question that matters is what answers on it: which ports are open, which software and version is listening, and whether that version has known vulnerabilities. That is an active check, so it needs authorisation and a defined scope, and it should run from somewhere appropriate for the hosts you are assessing.

Typical surprises are management interfaces reachable from the internet, old protocol endpoints left on for one integration, database ports opened for a migration and never closed, and admin consoles for appliances that were meant to be internal.

Company email addresses in public

Company addresses appear on the website, in press releases, in public code commits, in mailing list archives and in document metadata. For a company the interesting addresses are role and shared mailboxes (security, support, billing, admin, noreply), service account addresses used to sign up for third party tools, and the address patterns that make guessing other addresses easy.

The defensive questions are which shared mailboxes are publicly listed and therefore targets for phishing and password spraying, which service accounts were used to register with outside services, and whether your mail domain publishes the records that stop others spoofing it.

Code, documents and other public content

Public code repositories, package registries, paste sites and document sharing links can all carry company hostnames, internal paths, configuration and occasionally credentials. Whether you look for that content, and with which tool, is a separate decision from the footprint check; this post does not describe a credential search, and the Safeguard section below quotes the docs exactly on what the OSINT scan reports.

What "breach exposure" means for an organisation

Company accounts in third party breaches

When a third party service is breached, the stolen data often includes email addresses, and sometimes password hashes or other account data. If staff signed up for that service with a work address, the company now has exposure even though its own systems were never touched. The concrete risks are password reuse, where the same password protects a company account, and targeted phishing that references the breached service.

For an organisation, the useful output of a breach exposure check is a list of company addresses and the breaches they appear in, so the owners of those accounts can act. The output you do not want is a database of personal information about staff. Collect the minimum: the company address, the breach name and date, the data classes the breach included, and nothing else.

What a breach check can and cannot tell you

A breach check tells you that an address appeared in a known data set. It does not tell you whether the password in that breach was the same as the company password, whether the account still exists, or whether anyone has tried to use the data. It also only covers breaches that a data source knows about and has loaded.

So treat a breach hit as a reason to act on the account, not as evidence of a compromise. The standard response is to confirm the account is on MFA, force a password change if the breached service is one where reuse is plausible, and check sign-in logs for that account around and after the breach date.

Handling results responsibly

Breach and footprint results are sensitive. Store them in your security tooling with access limited to the people who need them. Do not paste them into chat channels. Do not keep credential values, ever; if a source returns one, record that it exists and discard it. Write down how long you keep results and who can see them, and make sure your privacy and HR teams agree with the process before you start telling people their work address appeared in a breach.

Where the line is: your assets, not people

It is worth being precise about scope, because the same public sources that show your organisation's exposure can be misused against individuals.

In scope: domains your organisation has registered, hosts and subdomains under them, IP ranges you are assigned or rent, services running on those hosts, company owned shared mailboxes and service account addresses, and company accounts on third party services.

Out of scope: personal email addresses, personal social media accounts, family members, home addresses, and anything that describes a person rather than a company system. Searching for staff on social platforms is not footprint management, and it is not something this post covers.

Authorisation: write down who approved the check, which domains and ranges it covers, and when it runs. For passive collection from public sources that is good practice; for any active scan of hosts it is a requirement, and for hosts run by a provider you should check the provider's testing policy first. If a domain or host is not clearly yours, leave it out until ownership is confirmed.

Step by step: run a footprint and breach exposure check on your organisation

These steps work with any tools. The template and the triage table at the end are meant to be copied.

1. Get written scope and approval

Write a one page scope: the domains, the IP ranges, the shared mailboxes, the people who approved it, the people who will see results, and the date range. Include a line that excludes personal accounts and individuals. Get it signed by whoever owns security risk. Keep it with the results; it is the first thing an auditor or a lawyer will ask for.

2. Build the domain list

Pull domains from registrar invoices, DNS hosting, TLS certificates and the acquisition list. For each one note the business owner, whether it is in active use, and whether it sends mail. This list is your seed for every later step.

3. Collect hosts and subdomains from public sources

For each domain, gather hostnames from public DNS, certificate transparency logs and search engine results. Record each hostname with where you found it and when. Resolve each one and note where it points: your own address space, a cloud provider, a SaaS platform or nowhere.

4. Reconcile against the inventory

Compare the host list with the asset inventory or CMDB. Every host should land in one of three buckets: known and owned, known but unowned, or unknown. The unknown and unowned buckets are the real output of the exercise. Assign every item an owner before you move on.

5. Check what the hosts expose

For hosts in your own address space, run an authorised service scan from an appropriate location to list open ports, service versions and known vulnerabilities. For hosts on a cloud provider or SaaS platform, check that the resource behind the DNS record still exists and is yours. For hosts nobody claims, the default is to remove the DNS record after a short notice period.

6. Check company addresses against breach data

For the shared mailboxes and service account addresses on your scope, check known breach data through a reputable service, using an API key your organisation holds and terms that allow organisational use. Record the address, breach name, breach date and data classes. Do not record any credential values.

7. Check mail domain protections

For each domain, check that SPF, DKIM and DMARC records exist and are set to a policy that stops others sending as you. Parked domains should publish records that say they send no mail at all. This closes one of the cheapest abuses of a public domain list.

8. Triage and assign

Turn each item into a finding with a severity, an owner and a due date. Use the table below as a starting point.

9. Fix, then record the fix

Remove dangling DNS records, close unneeded ports, patch or upgrade exposed services, move breach-hit accounts onto MFA and force password changes where reuse is plausible, and retire unused shared mailboxes. Record what you changed and when, so the next run shows the improvement.

10. Repeat on a schedule

The footprint changes with every launch, migration, acquisition and new SaaS signup. Run the passive collection on a regular schedule, after any major change and after a large third party breach is announced. Run active service checks at the interval your risk assessment and any regulatory schedule set.

A scope template you can copy

Footprint and breach exposure check: scope
Approved by:            (name, role, date)
Results visible to:     (team or named people)
Domains in scope:       (list)
IP ranges in scope:     (list, with provider testing policy checked: yes or no)
Shared mailboxes:       (list of role and service account addresses)
Out of scope:           personal accounts, personal addresses, individuals
Active scanning:        (allowed hosts and ranges, time window)
Breach data source:     (service, account holder, terms reviewed: yes or no)
Retention:              (how long results are kept, where)
Next run:               (date)

Triage table

A one-page checklist

• Scope written, approved and stored with results.
• Domain list built from registrar, DNS, certificates and acquisitions.
• Hostnames collected from DNS, certificate logs and search indexes.
• Every host reconciled to an owner or flagged for removal.
• Active service checks run only on authorised hosts and ranges.
• Company addresses checked against breach data with an organisational key.
• No credential values stored anywhere.
• Mail records checked on every domain, including parked ones.
• Findings triaged, owned and dated.
• Next run scheduled.

Which inputs belong in an organisational check?

Most footprint tools accept several kinds of input: a domain, an email address and a username. For an organisation checking itself, the domain is the main input, because it fans out into hosts, subdomains and the addresses published under it.

Email addresses belong in the check only when they are company owned: shared role mailboxes and service account addresses. Personal addresses do not belong in an organisational check.

Usernames are the input most likely to drift from "our accounts" to "a person". If you use them at all, restrict them to company brand handles and service accounts that the organisation registered and controls.

Free public sources or paid breach data?

Public sources such as DNS, certificate transparency logs and search indexes are free and need no agreement beyond normal terms of use. They cover most of the host and subdomain picture.

Breach data is different. Breach notification services usually offer APIs under a paid key, with terms that say how the data may be used. Before you wire one in, read the terms, check that your legal team is comfortable with the source, and make sure the key belongs to the organisation rather than to an individual.

The safe default is the one many tools take: run free public sources automatically, and run breach data providers only when someone has deliberately supplied an organisational key.

How Safeguard does this

Safeguard runs this work as part of its VAPT scans from the CLI (GA). The VAPT overview describes them as assessments of infrastructure you own, run from the Safeguard CLI (GA) on a machine you control, which upload only their results to your Safeguard console. The OSINT scan (GA) covers the public footprint and breach exposure; the Network Scan (GA) covers exposed services on hosts you own. The steps below follow the docs; commands are shown exactly as the docs show them and were not run for this post.

What the OSINT scan does

Safeguard's OSINT docs say the scan captures a target's open source intelligence footprint, along with its data leak and breach exposure. The docs list what that footprint includes: exposed emails, hosts and subdomains, and account and username presence. The scan queries public data sources only. It does not probe the target's own systems, so the docs say it can be run from anywhere.

For an organisational check, this post uses the domain input, which the docs say collects the public footprint: hosts, subdomains and exposed emails.

1. Install the CLI and sign in

Every VAPT scan runs from the Safeguard CLI. The docs give the install command and the sign-in step:

curl -fsSL https://cli.safeguard.sh/install | bash

safeguard login

Signing in is what lets results upload to your console. The docs add that the CLI provisions the tools each scan needs on first use, so you do not install them by hand.

2. Confirm authorisation

The docs require authorisation for every VAPT scan, in one of two ways: pass --i-am-authorised on the command, or place an authorising scope.yaml in a .safeguard/ folder in your working directory that lists the targets you are permitted to scan. Targets outside your authorised scope are refused.

For a recurring organisational check, the scope file is the better habit. It turns the signed scope document from step 1 of the generic process into something the tool enforces, and it travels with the working directory. The docs do not show the file's format, so this post does not either; check the docs or the CLI's help for the current shape.

3. Run the scan against a domain you own

The docs show the domain form of the command:

safeguard osint example.com --i-am-authorised

Replace example.com with a domain on your approved list. The docs say inputs are classified by shape, so one command fans out to the right sources, and that you can pass a domain, an email, a username or a combination. In an organisational check, keep the inputs to your domains and, where your process allows, company owned shared mailboxes. The docs state the boundary plainly: run OSINT only against domains, addresses and identities you own or are authorised to assess.

4. Decide whether to add a breach data provider

The docs say free public sources run automatically, and breach data providers run only when you supply your own API key, so that nothing paid or legally sensitive runs without someone choosing it. The key is passed as an environment variable on the command; the OSINT docs page shows the exact variable name and an example.

If you add one, use an organisational key under terms your legal team has reviewed, and run it against company owned addresses only. The docs also state that no credential value is ever stored in a finding, only the fact of exposure.

5. Review the results in the console

When the scan completes, the docs say results upload to a project in your console. The OSINT page lists the findings as public footprint and breach or data leak exposure for the target. The VAPT overview says each scan registers a project and uploads its findings and any discovered assets, which you review in the usual Findings, Vulnerabilities, Assets and Checks views.

The practical benefit is that footprint results sit next to your other projects instead of in a separate spreadsheet.

6. Or start it from the Integrations page

The docs describe a second way in. On the Integrations page, under the Add Project/Product tab, search for "OSINT". The card opens a panel with the exact command to copy and run, with your target filled in. It is the same CLI command; the panel saves typing and keeps the target consistent with what you entered.

7. Check exposed services with the Network Scan

The OSINT scan tells you which hosts exist; it does not probe them. For hosts you own, the Network Scan docs say Safeguard's Network Scan (GA) discovers open ports, identifies the services and versions listening on them, and checks live services against known CVEs and a set of named high profile vulnerability checks. Run it from the CLI on a machine inside the target network, against a single host or a CIDR range, as the docs show:

safeguard network-scan --targets scanme.example.com --i-am-authorised
safeguard network-scan --targets 10.0.0.0/24 --i-am-authorised

The docs say each open service becomes an asset with its port, protocol and detected version; CVEs and misconfigurations appear as vulnerabilities; and the named checks appear with a pass or fail outcome. The docs also describe an --all option that sweeps the machine's local networks, which still requires authorisation and respects scope exclusions. The VAPT overview advises starting each scan against a small, known target before running it against a whole network, because active scanning can be slow on large or quiet ranges.

8. Keep the results current

The docs describe the scan as a CLI command, so recurring runs are up to you: schedule the command on a machine you control, with a scope file in its working directory, and run it after major changes. Each run uploads to your console.

What Safeguard reads, stores and leaves alone

Requirement, Safeguard, and what you still own

What Safeguard does not do

• It does not fix what it finds. The OSINT scan reports exposure. Removing DNS records, closing ports, rotating passwords, enforcing MFA and retiring mailboxes are your team's changes in your DNS, network and identity systems.
• It is not continuous external monitoring. As the docs describe it, the OSINT scan is a CLI command you run. Recurring coverage depends on you scheduling it, and anything that appears between runs is not reported until the next one.
• It does not decide what you own. The scan collects what public sources show for the target you give it. It cannot tell you whether a domain or host is yours, and it relies on your authorisation and scope to stay within your assets.
• It does not bring its own breach data. Breach data providers run only with your own API key. Coverage of breach exposure depends on the provider you choose and the breaches it has loaded.
• It does not judge a breach hit. A finding that a company address appears in a breach is a fact about a data set, not evidence of compromise. Deciding whether to reset, investigate or notify is yours.
• It does not probe your systems. The OSINT scan uses public data sources only. Exposed services need the Network Scan, run separately from inside the network with its own authorisation.
• It is not a people search tool. This post covers organisational use only. Safeguard's docs restrict OSINT to domains, addresses and identities you own or are authorised to assess, and your own privacy and HR rules decide how staff related results are handled.
• It does not replace a penetration test or a regulatory assessment. It is an input to your risk assessment and test scoping, not a substitute for the tests your regulators or customers require.

Common mistakes

• Starting from the inventory instead of the internet. If you only check hosts you already know, you find nothing new. Start from domains and let public sources tell you what exists.
• Skipping the scope document. A footprint check without written scope is hard to defend later, and active scans without one can break provider terms or the law.
• Drifting into people. Adding staff names, personal addresses or social profiles turns an organisational check into a privacy problem. Keep the inputs to company assets.
• Storing credentials "for evidence". If a source returns a credential value, record that it exists and discard the value. Evidence is the fact of exposure and the date, not the secret.
• Treating breach hits as compromise. A hit is a prompt to check MFA, reset where reuse is plausible and review sign-in logs. Escalating every hit as an incident burns trust and time.
• Forgetting parked and acquired domains. These are the domains most likely to have stale records and no owner.
• Scanning other people's infrastructure. A CNAME to a SaaS platform does not make the platform's hosts yours. Check the resource exists and is yours; do not scan it.
• Running once for the audit. A single run is a snapshot, not a control.

FAQ

What is an OSINT footprint check for a company?

It is a review of what public sources show about the organisation's own domains, hosts, subdomains and company email addresses, so the security team can find assets it did not know about and close exposure before an attacker uses it. It covers company systems and company accounts, not individuals.

How do I find all subdomains of my own domain?

Combine public DNS, certificate transparency logs and search engine results for each domain you own, then resolve each hostname and reconcile it with your inventory. Certificate transparency is often the richest source, because every publicly trusted certificate is logged. Safeguard's OSINT scan (GA) collects hosts and subdomains for a domain you pass it.

How do I check whether company email addresses were in a data breach?

Use a reputable breach notification service with an organisational API key and terms that allow organisational use, and check company owned addresses only. Record the address, breach name, date and data classes, never the credential. In Safeguard, breach data providers run in the OSINT scan only when you supply your own API key.

Is it legal to run OSINT on my own organisation?

Collecting public information about assets you own is generally a normal security activity, but the details depend on jurisdiction, provider terms and your privacy obligations to staff. Write a scope, get approval, check breach data terms and talk to your legal and privacy teams. This post is not legal advice.

Does Safeguard's OSINT scan touch my servers?

No. Safeguard's docs say the OSINT scan queries public data sources only and does not probe the target's own systems, which is why it can be run from anywhere. Checking open ports and services on your hosts is the Network Scan (GA), which runs from inside the target network.

Does Safeguard store leaked passwords?

No. The OSINT docs say no credential value is ever stored in a finding, only the fact of exposure.

What authorisation does Safeguard need before a scan runs?

Every VAPT scan needs either the --i-am-authorised flag on the command or an authorising scope.yaml in a .safeguard/ folder in the working directory that lists permitted targets. Targets outside the authorised scope are refused.

Where do OSINT results appear in Safeguard?

When the scan completes, results upload to a project in your Safeguard console. You review them in the Findings, Vulnerabilities, Assets and Checks views alongside your other projects.

How often should we run a footprint check?

Run passive collection on a regular schedule, after major changes such as migrations or acquisitions, and after a large third party breach is announced. Active service scans follow your risk assessment and any regulatory schedule. With Safeguard you schedule the CLI command yourself.

Can I use the OSINT scan to look up a person?

That is not what this post covers, and it is not an organisational security use. Safeguard's docs say to run OSINT only against domains, addresses and identities you own or are authorised to assess. Keep inputs to company domains and company owned accounts.

Footprint findings often lead back to software: an exposed service running an old version, or an internet facing application built on vulnerable open source components. The section below is Safeguard's standard guidance on fixing vulnerable dependencies and images without waiting for an upstream release.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session: you install the CLI, open the interactive terminal with safeguard, and ask it to fix a lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json, runs the install and the tests with your approval, prints a summary and pushes nothing. The OSINT and Network scans run from the same CLI, so this is the tool you would install and sign in to before running them.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Once your footprint scans have uploaded to projects in your console, the same connection is a way to read those projects' findings from Claude, with you deciding which tools it may call.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Safeguard docs: OSINT
• Safeguard docs: VAPT Scans (CLI)
• Safeguard docs: Network Scan
• Safeguard docs: Integrations overview
• NIST Cybersecurity Framework 2.0 (CSWP 29)
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
• NIST SP 800-63B-4, Authentication and Authenticator Management
• MITRE ATT&CK: Reconnaissance (TA0043)
• MITRE ATT&CK: Gather Victim Identity Information (T1589)
• MITRE ATT&CK: Search Open Technical Databases (T1596)
• OWASP Web Security Testing Guide v4.2: Information Gathering
• OWASP WSTG-INFO-01: Search Engine Discovery Reconnaissance for Information Leakage
• RFC 6962, Certificate Transparency
• eCFR: 16 CFR 314.4, FTC Safeguards Rule elements
• CISA Cyber Hygiene Services

Related reading: OSINT and the software supply chain, dark web monitoring for supply chain threats, hardening the supply chain after a breach and Spring Boot Actuator endpoint exposure.

Try it yourself: download Safeguard or read the Safeguard docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.