Secret Manager Secret
Does ZopNight manage Secret Manager Secret?
Secret Manager bills per secret version per month plus per-access operations, keeping cost small while stale versions and unrotated credentials accumulate silently. ZopNight inventories secrets through Cloud Asset Inventory as metadata only (names, versions, and IAM context) and never reads or stores a secret's payload.
Rules that fire on Secret Manager Secret
No active rule family targets Secret Manager Secret today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
Secret Manager stores API keys, passwords, and certificates with versioning and IAM control, billed per secret version per month plus access operations. Cost is small, but stale versions and unrotated secrets are hygiene risks.
Version-months and access operations
Secret Manager’s meter has two parts, and both are easy to underestimate structurally rather than in magnitude. Storage bills per active secret version per month, not per secret, so a credential rotated 40 times with no version cleanup pays 40 version-months every month. Access operations bill per call, which stays negligible for applications that fetch a secret at startup and becomes a real line for ones that read it on every request instead of caching. Neither charge is large; both are pure overhead when the versions are dead or the access pattern is accidental.
Metadata-only discovery: payloads stay sealed
ZopDev inventories secrets via Cloud Asset Inventory (metadata only, never values) for topology and hygiene checks. The boundary is worth stating plainly, as the stub does: secret payloads are never read or stored by ZopDev. What discovery sees is the shape of the secret (its name, versions, and surrounding IAM context), which is exactly what hygiene analysis needs and nothing an attacker could use. Secrets have no lifecycle to schedule and effectively nothing to rightsize; their place in the directory is as a security-topology object with a small, self-inflicted cost tail.
Stale versions and unrotated credentials
The two failure modes pull in opposite directions. Version accumulation is over-rotation without cleanup: every deploy adds a version, old ones are never disabled or destroyed, and the version-month meter compounds while the actually-dangerous versions, the old credentials, remain fetchable by anything with access. Unrotated secrets are the reverse: a database password stored once, years ago, still version 1, shared by every environment. A healthy secret has few active versions and a recent one; an audit that sorts secrets by version count and by age of newest version finds both failure modes immediately.
Secret Manager console path
Google Cloud console → Security → Secret Manager lists every secret; opening one shows its versions with states (enabled, disabled, destroyed) and creation dates. Destroying superseded versions ends both their storage charge and their usefulness to anyone who once had access.