🕵️ Shadow IT — Part 1
𝗧𝗵𝗲 𝗮𝘀𝘀𝗲𝘁𝘀 𝗻𝗼𝗯𝗼𝗱𝘆 𝗸𝗻𝗼𝘄𝘀 𝗮𝗯𝗼𝘂𝘁

If it's not in your inventory, it's not being protected. But it's definitely on the internet.

Every organization has an asset inventory. And every asset inventory is incomplete.

💻 A developer spun up a cloud instance for a demo.
💻 A team stood up a test API on a subdomain.
💻 A contractor deployed a tool and left the company.

None of it went through change control. All of it is reachable from the internet.

🏗 Shadow IT isn't rogue behavior — it's the natural byproduct of teams moving fast. The problem is that security can't protect what it 𝗱𝗼𝗲𝘀𝗻'𝘁 𝗸𝗻𝗼𝘄 𝗲𝘅𝗶𝘀𝘁𝘀.

📌 Next up: cloud sprawl — one click to launch, no clicks to decommission.

🕵️ Shadow IT — Part 2
𝗖𝗹𝗼𝘂𝗱 𝘀𝗽𝗿𝗮𝘄𝗹

One click to launch. No clicks to decommission.

Cloud infrastructure is easy to create and easy to forget.

☁️ A staging environment that outlived the project it was built for.
☁️ A load balancer pointing at servers that no longer exist.
☁️ A storage bucket with public read access — created for a one-time data share two years ago.

The cloud bill might flag the cost. But cost is not the same as risk. A $3/month instance running an unpatched service is 𝗰𝗵𝗲𝗮𝗽 𝘁𝗼 𝗼𝗽𝗲𝗿𝗮𝘁𝗲 and 𝗲𝘅𝗽𝗲𝗻𝘀𝗶𝘃𝗲 𝘁𝗼 𝗯𝗿𝗲𝗮𝗰𝗵.

The real danger is that cloud assets often sit outside the perimeter your team actively monitors. Different account, different region, different owner — same brand on the certificate.

📌 Next up: forgotten subdomains — the DNS records that point to infrastructure nobody maintains.

🕵️ Shadow IT — Part 3
𝗙𝗼𝗿𝗴𝗼𝘁𝘁𝗲𝗻 𝘀𝘂𝗯𝗱𝗼𝗺𝗮𝗶𝗻𝘀

The DNS record is still there. The service behind it might be anything.

⸻

Subdomains accumulate like dust. Every project, every campaign, every vendor integration leaves DNS records behind.

🌎 staging.example.com — still resolves, still serves a login page.
🌎 old-api.example.com — points to an IP you no longer own.
🌎 dev.example.com — running a framework version from 2022.

Some of these are just stale. But others are actively dangerous — a subdomain pointing to an IP you've released can be 𝗰𝗹𝗮𝗶𝗺𝗲𝗱 𝗯𝘆 𝘀𝗼𝗺𝗲𝗼𝗻𝗲 𝗲𝗹𝘀𝗲 and used to impersonate you.

The DNS inventory is one of the hardest things to keep clean, because records are created by many teams and deleted by none.

📌 Next up: what happens when acquisitions bring someone else's shadow IT into your perimeter.

🕵️ Shadow IT — Part 4
𝗜𝗻𝗵𝗲𝗿𝗶𝘁𝗲𝗱 𝗶𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲

You acquired a company. You also acquired their technical debt.

⸻

Mergers and acquisitions bring customers, talent, and intellectual property. They also bring infrastructure nobody audited.

🏢 Legacy systems the acquired team was already planning to retire.
🏢 Vendor integrations with credentials nobody can find.
🏢 Entire environments that weren't in the acquisition due diligence.

This infrastructure is now yours. It carries your brand. A breach there is 𝘆𝗼𝘂𝗿 breach.

The challenge: you can't protect it until you find it, and you can't find it from the org chart alone. IP ranges, domain names, cloud accounts — the acquisition paperwork rarely covers all of it.

⚠️ The first security action after any acquisition isn't a policy review. It's discovery.

📌 Next up: developer tools on the perimeter — the assets that live at the edge of corporate control.

🕵️ Shadow IT — Part 5
𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝘁𝗼𝗼𝗹𝘀 𝗼𝗻 𝘁𝗵𝗲 𝗽𝗲𝗿𝗶𝗺𝗲𝘁𝗲𝗿

It was supposed to be internal. It's not.

Developers need tools to do their jobs. The problem is where those tools end up.

🛠 A CI/CD dashboard with no authentication.
🛠 A debug endpoint left enabled in production.
🛠 A monitoring stack exposed on a public IP because someone needed remote access.

These aren't intentional decisions. They're shortcuts that became permanent. And they're some of the 𝗵𝗶𝗴𝗵𝗲𝘀𝘁-𝘃𝗮𝗹𝘂𝗲 𝘁𝗮𝗿𝗴𝗲𝘁𝘀 on any perimeter — admin-level access, often with no MFA, sometimes with no password at all.

Developer tools are built for productivity, not defense. When they're exposed to the internet, they offer exactly the kind of access an attacker is looking for.

📌 Next up: closing the loop — why discovery has to be continuous, not a one-time project.

🕵️ Shadow IT — Part 6
𝗗𝗶𝘀𝗰𝗼𝘃𝗲𝗿𝘆 𝗻𝗲𝘃𝗲𝗿 𝘀𝘁𝗼𝗽𝘀

You can't secure what you can't see. And the picture changes every day.

A one-time asset inventory is already outdated the moment it's finished. New infrastructure goes live daily. Old infrastructure drifts.

The organizations that stay ahead of shadow IT don't run bigger audits. They run continuous ones.

🔄 New cloud instances — found as they appear, not months later.
🔄 Stale subdomains — flagged before they become takeover targets.
🔄 Inherited assets — surfaced during integration, not after a breach.

Shadow IT isn't a problem you solve once. It's a condition you monitor 𝗽𝗲𝗿𝗺𝗮𝗻𝗲𝗻𝘁𝗹𝘆. The gap between what you know about and what actually exists is your real attack surface.

✅ Closing that gap is what Netbot is built for.

🛡 CVE Exposure — Part 1
𝗧𝗵𝗲 𝘃𝘂𝗹𝗻𝘀 𝘀𝗶𝘁𝘁𝗶𝗻𝗴 𝗼𝗻 𝘆𝗼𝘂𝗿 𝗽𝗲𝗿𝗶𝗺𝗲𝘁𝗲𝗿

A new series. Vulnerabilities don't expire. If the software is still running, the CVE is still valid.

Every organization patches. And every organization has gaps.

The gap isn't usually negligence. It's visibility. A critical CVE gets published, the security team patches the known instances — but misses the one running on a forgotten host, an older version, a different port.

🔴 The appliance that's "too critical to restart."
🔴 The service pinned to an old version because of a dependency.
🔴 The host nobody remembers deploying in the first place.

These are the assets where CVEs accumulate. Not because the team isn't working — because the team 𝗱𝗼𝗲𝘀𝗻'𝘁 𝗸𝗻𝗼𝘄 𝘁𝗵𝗲𝘆'𝗿𝗲 𝘁𝗵𝗲𝗿𝗲.

💬 https://netbotter.cc

🛡 CVE Exposure — Part 2
𝗧𝗵𝗲 𝗹𝗼𝗻𝗴 𝘁𝗮𝗶𝗹

The headline CVEs get patched. The ones from three years ago don't.

When a critical vulnerability makes the news, teams mobilize. Patches get deployed. Crisis averted.

But what about the CVEs that never made the news?

🗓 The 2021 OpenSSL vulnerability that still applies to 12 hosts.
🗓 The 2019 Apache Struts issue on a service that "works fine, don't touch it."
🗓 The PHP version from 2020 with a known RCE that nobody upgraded.

These aren't exotic zero-days. They're well-documented vulnerabilities with public exploits and available patches. They persist not because they're hard to fix, but because 𝗻𝗼𝗯𝗼𝗱𝘆 𝗶𝘀 𝗹𝗼𝗼𝗸𝗶𝗻𝗴 at those hosts anymore.

The long tail of CVEs is where most real-world breaches begin. Not the latest headline — the one from years ago that everyone assumed was already handled.

📌 Next up: why knowing the exact version changes everything.

🛡 CVE Exposure — Part 3
𝗧𝗵𝗲 𝘃𝗲𝗿𝘀𝗶𝗼𝗻 𝗴𝗮𝗽

"We run nginx" is not a security posture. Which version? That's the question that matters.

Most vulnerability scanners can tell you what software is running. Fewer can tell you the exact version. And without the version, a CVE match is just a guess.

🔍 nginx 1.18.0 — 4 known CVEs, one critical.
🔍 nginx 1.25.3 — patched, clean.
🔍 nginx (version unknown) — could be either. You're 𝗳𝗹𝘆𝗶𝗻𝗴 𝗯𝗹𝗶𝗻𝗱.

Version detection turns a vague risk into a concrete finding. It's the difference between "you might be vulnerable" and "you 𝗮𝗿𝗲 running a version with a known remote code execution."

Not every service reveals its version. But when it does — in a banner, a header, a response body — that single data point maps directly to the CVE database.

💬 https://netbotter.cc

🛡 CVE Exposure — Part 4
𝗦𝗲𝘃𝗲𝗿𝗶𝘁𝘆 𝗶𝘀𝗻'𝘁 𝗽𝗿𝗶𝗼𝗿𝗶𝘁𝘆

A CVSS 9.8 on an internal test server. A CVSS 7.2 on your payment gateway. Which one do you fix first?

CVSS scores measure how bad a vulnerability is. They don't measure how much it 𝗺𝗮𝘁𝘁𝗲𝗿𝘀 𝘁𝗼 𝘆𝗼𝘂.

⚖️ A critical RCE on a honeypot — high severity, zero business impact.
⚖️ A medium-rated auth bypass on your customer portal — lower score, catastrophic if exploited.

Priority comes from context: what the host does, who owns it, whether it's internet-facing, what data it touches. A CVE list sorted by severity is a starting point. It's not an action plan.

The teams that patch effectively don't chase the highest CVSS first. They ask: which of these vulnerabilities, on which assets, would cause the 𝗺𝗼𝘀𝘁 𝗱𝗮𝗺𝗮𝗴𝗲 if exploited tomorrow?

That question can only be answered when CVE data meets asset context.

📌 Next up: your vendors' CVE debt — the exposure you don't control but still carry.

🛡 CVE Exposure — Part 5
𝗬𝗼𝘂𝗿 𝘃𝗲𝗻𝗱𝗼𝗿𝘀' 𝗖𝗩𝗘 𝗱𝗲𝗯𝘁

You patched your infrastructure. Did they patch theirs?

Your perimeter doesn't end at your own infrastructure. Every vendor, partner, and managed service provider extends it.

🏢 The managed firewall running firmware with 6 known CVEs.
🏢 The SaaS vendor whose login page leaks its web server version.
🏢 The hosting provider with a shared IP where three of your neighbors are unpatched.

You can't force a vendor to patch. But you can 𝗸𝗻𝗼𝘄 whether they have — and make decisions accordingly.

Vendor CVE exposure is one of the clearest, most objective signals in third-party risk assessment. No questionnaire required. No self-reported compliance score. Just observable, verifiable facts about what's running and what's vulnerable.

🛡 CVE Exposure — Part 6
𝗙𝗿𝗼𝗺 𝗹𝗶𝘀𝘁 𝘁𝗼 𝗮𝗰𝘁𝗶𝗼𝗻

A CVE report that sits in a PDF isn't reducing risk. One that feeds a workflow is.

Every scanner produces a list of findings. The question is what happens next.

The teams that actually reduce CVE exposure have three things in common:

✔️ 𝗖𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀 𝘃𝗶𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 — not quarterly scans, but a live picture that updates as infrastructure changes.

✔️ 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 — every CVE tied to an owner, a business function, and a priority that reflects impact, not just severity.

✔️ 𝗔 𝗳𝗲𝗲𝗱𝗯𝗮𝗰𝗸 𝗹𝗼𝗼𝗽 — when a patch ships, the next scan confirms it worked. No more "we think we fixed it."

A CVE is a known problem with a known solution. The hard part was never the fix. It was knowing where to look, and knowing when you're done.

✔️ That's what Netbot is built for.

🔗 Third-Party Risk — Part 1
𝗬𝗼𝘂𝗿 𝘃𝗲𝗻𝗱𝗼𝗿𝘀' 𝗮𝘁𝘁𝗮𝗰𝗸 𝘀𝘂𝗿𝗳𝗮𝗰𝗲 𝗶𝘀 𝘆𝗼𝘂𝗿𝘀

A new series. You did everything right. Your vendor didn't. The breach is still your problem.

Your security program ends at your own infrastructure. Your risk doesn't.

Every vendor with access to your data, every partner integrated into your workflows, every managed service provider running a piece of your stack — they all extend your attack surface.

🔗 A vendor's exposed admin panel is your data at risk.
🔗 A partner's unpatched server is your integration compromised.
🔗 A provider's misconfigured API is your customers affected.

The hard part isn't recognizing this. It's 𝗺𝗲𝗮𝘀𝘂𝗿𝗶𝗻𝗴 it. Vendor risk assessments have traditionally relied on questionnaires and certifications — what the vendor 𝘀𝗮𝘆𝘀 about their security, not what their infrastructure actually 𝘀𝗵𝗼𝘄𝘀.

𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗹𝗲 𝘀𝗶𝗴𝗻𝗮𝗹𝘀

A questionnaire tells you what the vendor claims. Their infrastructure tells you what's true.

You don't need a vendor's permission to see their public attack surface. It's public.

What you can observe from the outside:

🔎 Expired or misconfigured TLS certificates
🔎 Services running software with known CVEs
🔎 Admin panels and management interfaces exposed to the internet
🔎 Outdated server software in response headers
🔎 Open ports with no clear business purpose

None of this requires scanning the vendor's internal network. It's what their infrastructure 𝘃𝗼𝗹𝘂𝗻𝘁𝗲𝗲𝗿𝘀 to anyone who connects.

These signals aren't proof of a breach. But they're proof of how the vendor 𝗼𝗽𝗲𝗿𝗮𝘁𝗲𝘀. A company that can't keep its public-facing certificates valid probably isn't running a tight ship internally either.

📌 Next up: the hygiene test — what expired certs and default configs really tell you.

🔗 Third-Party Risk — Part 3
𝗧𝗵𝗲 𝗵𝘆𝗴𝗶𝗲𝗻𝗲 𝘁𝗲𝘀𝘁

If a vendor can't keep its certificates valid, what else isn't being maintained?

Basic security hygiene is the most reliable indicator of how a vendor runs its operation.

🧹 Certificates renewed on time → someone is maintaining the infrastructure.
🧹 Current software versions → patches are being applied.
🧹 No default credentials or test pages → services are configured for production.

The inverse is equally telling:

🚩 Expired certs across multiple hosts → systemic neglect.
🚩 Software versions years behind → no patch management.
🚩 Factory-default admin pages on the internet → no hardening process.

This isn't about catching one mistake. Everyone has a bad day. It's about 𝗽𝗮𝘁𝘁𝗲𝗿𝗻𝘀. A vendor with consistent hygiene is a very different risk profile from one with systemic gaps.

🔗 Third-Party Risk — Part 4
𝗦𝗵𝗮𝗿𝗲𝗱 𝗶𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲

Your vendor shares an IP with six other companies. One of them is compromised. Now what?

Not every vendor runs dedicated infrastructure. Many share hosting, IP ranges, and even physical servers with other tenants.

That's a business decision. But it's also a risk decision — one that's rarely surfaced in vendor assessments.

🏠 Shared hosting means shared IP reputation. One compromised neighbor, and your vendor's traffic gets flagged.
🏠 Shared infrastructure means shared exposure. A vulnerability in the hosting layer affects everyone on it.
🏠 Co-tenancy means blast radius. An attacker who breaches one tenant may reach others.

This doesn't make shared hosting wrong. It makes it a 𝗳𝗮𝗰𝘁𝗼𝗿. One your vendor probably isn't volunteering in their security questionnaire.

Knowing who your vendor shares infrastructure with — and what those neighbors look like — is part of understanding the real risk.