🔄 Topic

Standing up a new private remote for Hermes’ binaries was the excuse to build the habit I should have had from day one: a pre-push secret scan, plus a one-command Google reauth so recovering from an expired credential is never a reason to paste a token somewhere it shouldn’t live.

🎯 Goal

Make it structurally hard to accidentally push a secret to a new remote, and make credential recovery boring enough that nobody is ever tempted to shortcut it.

🛠 What I Did

I paired infrastructure setup with the hygiene habit that should ship alongside it.

Main areas covered:

  • created a private remote for hermes-bin, versioned binaries that don’t belong in the main history
  • added a pre-push secret scan as a first-class part of that remote’s workflow, not an optional afterthought — nothing reaches the remote without passing the scan
  • recorded a completed install-integrity finding from the same session, closing out a separate question about whether the installed binaries matched what was expected
  • built a one-command Google re-auth (google-reauth, extended with an all mode) so recovering from an expired grant is a single documented command instead of an improvised sequence typed under pressure
  • finished the n8n webhook authentication that had been left with a placeholder — a credential that “never shipped” but existed in config, which is its own small risk removed
  • recorded bin/ versioning conventions, a calendar-delete fix, and an Apple Mail index fix in the same pass, since they surfaced during the same audit

🔗 Key Cybersecurity Connections

Pre-push scanning belongs at the moment a remote is created, not bolted on after the first accidental leak — the best time to add a control is before the thing it controls has ever happened. A placeholder credential that “never shipped” is exactly the kind of dead config that looks harmless and isn’t: it’s an unused door that still has a lock nobody is watching.

The one-command reauth is a security control disguised as convenience: recovery procedures that are slow or manual get worked around under pressure, and workarounds are where secrets end up pasted into chat logs, shell history, or scratch files that never get cleaned up.

🔍 Investigation Questions

  • Does every new remote get a pre-push secret scan before its first real push, or only after a scare?
  • Is there any placeholder or “never shipped” credential still sitting in configuration?
  • How many manual steps does credential recovery take, and does that number invite shortcuts?
  • Does the installed binary set actually match what the build process claims to have produced?
  • Are versioning conventions for binaries documented, or just known by convention?

🚨 Detection Opportunities

Checks for credential and remote hygiene:

  • a new remote created without a pre-push scan configured
  • a placeholder or unused credential present in any config file
  • a credential-recovery procedure requiring more than one command under time pressure
  • installed binaries diverging from their expected build provenance
  • secret-scan findings on a push that get bypassed rather than resolved

Example:

project=hermes-bin-remote
signal=push_without_secret_scan_configured
risk_area=credential_leak_via_new_remote
triage=confirm_scan_hook_present_before_first_real_push

🧭 MITRE ATT&CK Techniques

Possible mapping for the risk being controlled:

  • T1552 — Unsecured Credentials

🗺 Visual Investigation Diagram

New private remote created
    ↓
Pre-push secret scan added first
    ↓
Placeholder credential found + removed
    ↓
One-command reauth built
    ↓
Recovery no longer invites a shortcut
    ↓
Install-integrity confirmed separately

⚠ Challenges

The placeholder credential was the sneaky one — it looked inert precisely because it had “never shipped,” which made it easy to overlook as harmless instead of recognizing it as unused attack surface sitting in plain sight.

📚 What I Learned

I learned that credential hygiene compounds: the scan prevents a leak, the one-command reauth prevents the workaround that would have caused a leak, and removing the placeholder closes a door nobody was watching. None of them individually feels dramatic; together they are the actual defense.

➡ Next Steps

  • Apply the pre-push scan pattern to every remote created going forward, by default
  • Audit remaining configs for other placeholder or “never shipped” credentials
  • Time the one-command reauth against a real expiry to confirm it holds up under pressure
  • Keep bin/ versioning conventions documented alongside the workflow that depends on them

🧠 Reflection

None of today’s fixes were exciting on their own. Together, they’re the difference between “we haven’t leaked a secret yet” and “it would be structurally hard to.”

🧩 Lessons Learned

What worked

Adding the secret scan at remote creation, and making credential recovery a single documented command.

What broke

A placeholder credential that never shipped, sitting unnoticed in configuration.

Why it broke

It looked harmless precisely because it was never used, which is exactly the reasoning that lets dead credentials survive audits.

Fix / takeaway

Add hygiene controls at creation time, not after an incident, and treat unused credentials as risk regardless of whether they’ve ever been exercised.

📈 Skill Progression Context

This supports my cybersecurity progression because secret scanning, credential lifecycle hygiene, and reducing the friction that causes workaround-driven leaks are daily concerns in any real DevSecOps practice.

😄 TL;DR

New remote, and the secret scan came with it — plus a one-command reauth so recovery never tempts a shortcut.