Seventy Secrets, One Vault

A SAST scan produces findings, not fixes — in this case, a literal CSV export (`Use-Of-Hardcoded-Password-In-Config-...csv`) enumerating every property file across the notification stack's environments where a credential was sitting in plaintext: SMS gateway auth, email provider keys, partner-specific secrets baked into per-merchant peon configuration.

Each of those properties was live in a running config for a real merchant integration, so 'migrate to Vault' actually meant: for every flagged property, find every place it's read, introduce a Vault-backed lookup, verify the value resolves identically, and only then remove the plaintext fallback.

I worked through the CSV property by property across QA and production configuration, moving each flagged secret into HashiCorp Vault and reconciling application config so services resolved credentials from Vault rather than from checked-in properties — done incrementally enough that QA and prod could be validated independently rather than as one all-or-nothing cutover.

In the same security pass, a separate finding — a Rajasthan GeM peon integration still computing its checksum with MD5 — got replaced with SHA-256, closing a weak-hashing finding that had been sitting alongside the credential issues in the same audit.

The risk in this kind of remediation isn't writing the Vault integration — it's that a single missed property, or a Vault path that resolves to an empty value instead of failing loudly, silently breaks a live merchant's signature verification or SMS delivery in production with no compile-time signal that anything is wrong. The property-by-property, environment-by-environment discipline is the actual engineering content of the work.