Why Bragging About Clients Can Be Bad Practice (Supply-Chain Edition)

Every advisor told me the same thing the week we launched. Name your clients. Put their logos on the homepage. Get three case studies up by quarter end. The pitch deck needs a customer wall by Series A. Nobody mentioned supply chain attack risk; nobody mentioned what a published customer roster looks like to a threat actor. You are a B2B vendor; social proof is the entire game; if you do not list customers, nobody will believe the company is real.

I heard it from investors. I heard it from peer founders. I heard it from a marketing consultant who charged by the hour to tell me. The advice was right in the way most conventional advice is right. It works most of the time. It compounds quickly. It is the path of least resistance to credibility.

Unfortunatelly, I disagreed. Not on the credibility math. On the supply chain attack math. Every named client on a vendor's homepage is one more line in a target map an attacker would otherwise have to build by hand. That is the trade I do not want to make on behalf of my customers — and this article is the long-form version of why.

"Just put up a logo wall. Your sales cycle will thank you." — every advisor, every founder forum, every growth playbook published since 2014.

The Kerckhoffs disclaimer before the supply chain attack case studies

Before I get to the supply chain attack case studies, I have to clear one thing out of the way, because every time someone reads "I do not list my clients" they assume the argument is security through obscurity, which is a bad argument and has been a bad argument since 1883.

Auguste Kerckhoffs's principle says a cryptographic system must remain secure even if everything about it except the key is public. Translated: do not depend on a hidden algorithm to protect you, because hidden algorithms eventually surface, and when they surface, the security disappears with them. The corollary in modern software security is OWASP's stance — the Open Worldwide Application Security Project — which treats "but the source code is private" as a non-defense.

I agree with Kerckhoffs. Loomaru's mechanism is not the secret. The runbook is not the secret. How we configure the loomaru data layer is, in principle, describable in a public document and the system would be no less robust.

A customer list is not the algorithm. A customer list is operational hygiene. The question is not "does the security of our system depend on attackers not knowing who our customers are." The question is "does publishing the customer graph expand the attack surface of the people who hired us." That is a different question, and the answer is yes. The next three sections are why.

CVE

Common Vulnerabilities and Exposures — the public catalog of disclosed software-security flaws.

OSINT

Open-Source Intelligence — what an attacker can learn from public information alone, no break-in required.

OWASP

Open Worldwide Application Security Project — the volunteer body that maintains the de-facto application-security risk standards.

CSP

Content Security Policy — a browser security header that limits which scripts a page is allowed to run.

SRI

Subresource Integrity — a browser feature that refuses a third-party script if its hash does not match.

IR

Incident Response — the playbook a company executes after a breach is detected.

MFA

Multi-Factor Authentication — a second proof of identity beyond a password.

MSP

Managed Service Provider — an outsourced IT provider that operates infrastructure on behalf of small businesses.

Magecart

A family of skimming attacks that quietly steals checkout card data from compromised storefronts.

Ransomware

Malware that encrypts a victim's data and demands payment for the key.

Data layer

The structured event stream a website sends out to analytics and ad platforms — purchases, add-to-carts, page views.

Codecov, 2021 — supply chain attack against a developer-tooling vendor

In April 2021, attackers modified Codecov's Bash uploader script. The exploit is catalogued at CVE-2021-32638 (NVD). For roughly two months before discovery, every continuous-integration run that piped credentials through that uploader was at risk of those credentials being exfiltrated to an attacker-controlled endpoint.

Codecov's customer base was the lever. The reason that single supply chain attack mattered was not the cleverness of the script modification — it was the scale of trust the modified script had already earned. Codecov customer logos were public. Investigators and attackers alike could enumerate which repos, which CI pipelines, and which downstream cloud accounts were probably exposed without ever scanning a target. The customer wall was, briefly, an attacker's prioritized target list.

A vendor that publishes a customer list does not cause a supply chain attack. But a vendor that publishes a customer list makes the attacker's reconnaissance phase trivial when one happens. Once the breach is public, the published roster turns into a queue.

SolarWinds, 2020 — supply chain attack at federal scale

The SolarWinds Orion compromise is the supply chain attack case study every CISO references for a reason. The malicious update — eventually catalogued as CVE-2020-10148 (NVD) — was distributed through SolarWinds's own update mechanism. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued Emergency Directive 21-01 ordering federal civilian agencies to disconnect or power down affected Orion products immediately.

The interesting fact for this article is not the malicious code path — that has been written about in exhaustive detail elsewhere. The interesting fact is the response timeline. CISA's emergency directive moved as fast as it did because the customer base was knowable. Federal agencies, Fortune 500 networks, parts of the U.S. defense supply chain — SolarWinds's reach was a matter of public record long before the breach.

Knowability cuts both ways. It accelerated containment. It also accelerated the prioritization of follow-on supply chain attack stages against the same exposed customer set, in the months that followed, by adversaries who now had a curated map of which networks were running the compromised version. That is the part the logo-wall conversation never includes: the attacker reads the same press releases the press does.

Kaseya, 2021 — the supply chain attack that hit small business hardest

If Codecov was a developer-tooling story and SolarWinds was a federal-agency story, Kaseya is the supply chain attack that should land hardest for anyone selling B2B services to small and mid-market businesses.

In July 2021, attackers exploited a vulnerability in Kaseya's VSA software, catalogued at CVE-2021-30116 (NVD), and used the access to push REvil ransomware downstream through Managed Service Providers (MSPs) to their customers. CISA published advisory AA21-187A within days.

The ~1,500 small businesses ransomwared in the Kaseya supply chain attack were not, in most cases, Kaseya customers. They were customers of MSPs that ran Kaseya. Many of those MSPs published their client rosters — local dental practices, regional retailers, small accounting firms — for the same growth-marketing reason every advisor told me to publish mine. The roster was a catalog. The supply chain attack turned the catalog into a hit list.

Three supply chain attack incidents, side by side

Three incidents. Three different vendor topologies. One common ingredient across every supply chain attack on the table: the customer graph was visible enough that the second-stage targeting was cheap.

Why a logo wall is better than OSINT (and still bad)

The honest counter-argument is that an attacker can usually rebuild a vendor's customer list from scratch using OSINT — Open-Source Intelligence. Job postings name the tools. Conference talks name the customers. Procurement records surface in public-budget databases. A determined attacker is going to figure out who runs what.

This is true and it changes nothing. A logo wall is a structured, vendor-confirmed, dated, machine-readable customer roster. OSINT reconstruction is noisy, partial, and stale. The difference between the two is the difference between a curated index and a pile of fragments. An attacker prioritizing limited capacity in the wake of a fresh supply chain attack will always choose the curated index. Publishing the index is doing the attacker's prioritization for them.

This is not a security claim about Loomaru's system. It is operational hygiene for our customers. The merchants we work with have their own security obligations, their own compliance posture, and their own decisions to make about how loud they want their vendor relationships to be in public. That is their call. Our job is not to make the loud option easier than the quiet one.

What I tell prospects who ask for references

I do offer references. They are real, named, and willing to talk on a call. They do not appear on a homepage, in a press release, or in a deck that gets emailed without a non-disclosure conversation first. A prospect who wants verification gets verification — through a channel that does not also broadcast their name to every threat actor who happens to read marketing pages.

This costs me sales cycles. I know it does. The advisor cohort was right that named references close faster than anonymous ones. I am making the trade anyway, because the alternative is asking my customers to absorb a non-trivial increase in their own attack surface — and a non-trivial increase in their odds of being on the next supply chain attack target list — so that my marketing copy looks more conventional.

Mechanism proof beats social proof in a supply chain attack era

The deeper point is that a B2B vendor in 2026 has tools to demonstrate competence that did not exist in 2014. Public technical writeups. Versioned, dated changelogs. Reproducible benchmarks. Open postmortems on incidents the vendor itself caused or recovered from. Public drift-guard inventories that show what the system mechanically refuses to do. Sandboxed demos that work without an account.

Mechanism proof is harder to produce than a logo wall. It also stays valid the day after a supply chain attack hits an industry peer, when every named-client list on the internet is suddenly being prioritized by someone who was not interested yesterday. That is the kind of robustness — and the kind of transaprency — I would rather build into the company's evidence base.

I would rather a prospect read a public technical writeup, ask me three sharp questions on a call, and decide based on the answers, than read a logo wall and decide based on which familiar names appeared on it. The first path is slower. It is also the path that does not ask the customer to volunteer to be a future target.

References

• NVD — CVE-2021-32638 (Codecov Bash uploader): https://nvd.nist.gov/vuln/detail/CVE-2021-32638
• NVD — CVE-2020-10148 (SolarWinds Orion / SUNBURST): https://nvd.nist.gov/vuln/detail/CVE-2020-10148
• CISA — Emergency Directive 21-01 (mitigate SolarWinds Orion code compromise): https://www.cisa.gov/news-events/directives/ed-21-01-mitigate-solarwinds-orion-code-compromise
• NVD — CVE-2021-30116 (Kaseya VSA): https://nvd.nist.gov/vuln/detail/CVE-2021-30116
• CISA — Advisory AA21-187A (Kaseya VSA supply-chain ransomware attack): https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-187a
• OWASP — Application Security Risks reference: https://owasp.org/