I Did Recon on My Own Company , Using Only What We Published.

Twenty minutes of public-only recon on my own company: the README architecture diagram, job postings as a vendor list, an error-message hostname, .env.example as a secrets schema. The fix: split the manual from the map, scrub errors at the boundary, review jobs like publications.

Quarterly habit: twenty minutes attacking myself with public information only. No credentials, no insider knowledge. This quarter I pointed it at the asset I'd never audited because I never thought of it as one: our documentation.

The notebook I ended up with made me slightly nauseous.

What the public pile gave away

• README architecture diagram — service names, queue names, the worker fleet. A map with a legend, updated last quarter.
• A support-thread screenshot — an error toast containing an internal hostname and stack path. Errors are involuntary documentation.
• Job postings — "must know Kafka, Datadog, Auth0, Terraform" is a vendor list with a budget attached, including which parts we're unhappy enough to replace.
• A 2023 conference talk, still indexed, "simplified" diagram 90% accurate.
• .env.example — variable names are a schema of your secrets; ours enumerated every third-party integration, alphabetically, with comments.

None of it was a breach. All of it was publishing. Recon is the cheapest phase of an attack, and we were subsidizing it.

Run your own twenty minutes (the sweep)

# 1. involuntary docs: hostnames, internal ranges, vendor names in the repo
grep -rniE '(\.internal|\.local|10\.0\.|192\.168\.|hostname|stack)' docs/ README.md | head -30

# 2. the secrets schema
cat .env.example          # read it like an attacker: that's an inventory

# 3. your jobs page is a publication
grep -iE 'kafka|datadog|auth0|pagerduty|terraform' jobs/*.md

# 4. then do the human part:
#    - search "yourproduct architecture"
#    - site:yourdomain.com diagram
#    - open your last three conference/blog artifacts

The manual vs. the map
Docs have two audiences by default, and only one is friendly; the document can't tell them apart. So we split:

docs-public/    # the MANUAL — behavior, interfaces, examples. Generous.
docs-internal/  # the MAP — topology, internal names, runbooks, vendor wiring.
                # Access-controlled, reviewed like code.

And the habits that cut involuntary leaks:

Errors get scrubbed at the boundary — what happened, never where:

app.use((err, req, res, next) => {
  const id = crypto.randomUUID();
  log.error({ id, err });                    // hostnames + stacks stay in logs
  res.status(err.status || 500).json({
    error: "Something went wrong.",          // no internal names in the toast
    ref: id
  });
});

.env.example documents shape, not inventory:

- # Stripe live key for payments team
- STRIPE_KEY=sk_live_...
- KAFKA_BROKERS=kafka-3.internal:9092
+ PAYMENTS_KEY=        # your payments provider key (scoped, rotated)
+ EVENT_BROKER=        # event pipeline endpoint

Job postings reviewed like publications:

- Own our Kafka + Datadog + Auth0 stack.
+ Own high-throughput event pipelines, observability, and auth integrations.

Candidates understand the second version perfectly. So does the person drafting your attack plan — except they learn less from it.

The honest part

• Not security by obscurity. The walls stay walls: no public IP by default, own kernel per Cube, default-deny inbound, scoped secrets. Doc discipline just stops handing out the floor plan of the building the walls protect.
• Open source moves the line, not the principle. If your topology is the repo, the discipline shifts to what isn't: your environments, vendors, operational wiring. Publish the software's manual; your instance's manual is yours.
• Total erasure is impossible. Mirrored slides live forever. The goal is that today's publishing is deliberate, and the freshest intel an attacker gets is stale.

Run your own twenty minutes
Search your product name plus "architecture." Read your last three job postings like a stranger with a grudge. Open the .env.example. Screenshot one customer-facing error.

Then ask, for each artifact: who needs this to use us — and who else just learned something?