Secrets and configuration
A credential committed alongside the code has been distributed to everyone who has ever taken a copy, and deleting the file does not retrieve it.
A credential committed alongside the code has been handed to everyone who has ever taken a copy of it, including whoever takes one after the person responsible has moved on. Deleting the file does not retrieve those copies, and version control remembers deleted files — which is why removal is not the fix most people assume it is.
The response to an exposed credential is to rotate it, not to delete it. Rewriting history is occasionally worth doing and it does nothing about the clones that already exist; only invalidating the value ends the exposure.
Credentials are held as configuration, supplied to the system as it starts, and never written into the work itself, into what gets published, or into anything sent to a browser. The last is the easiest mistake: a key embedded in a page is served to every visitor and trivially readable.
Each environment has its own credentials. A key valid in both the test system and the live one means compromising the less-guarded one compromises the other, which removes the reason for having a boundary.
Credentials are scoped to the narrowest permission that accomplishes the task. A key that can read one bucket is a smaller incident than a key that administers the account, and the difference costs nothing at the moment of creation.
Rotation is exercised, not described. A credential nobody has ever rotated is a credential nobody knows how to rotate, and that gets discovered during the incident requiring it — usually along with the three services that were quietly using the same value.
Which credential each system depends on is recorded, because rotation is among the most common causes of a working system stopping. The connection between a key changed on Tuesday and a job that has failed silently since Tuesday is rarely made quickly without a list.
Configuration that is not secret is committed. Switches, addresses, timeouts, and schedules belong under version control where they are recorded and reviewable — treating everything as a secret means the real ones stop receiving special handling.
Access to production configuration is separated from access to source. A contributor who can read the code does not thereby hold the keys, and where a small team makes that separation impractical, the honest response is to say so instead of to describe a control that is not operating.
What this does not cover.
- Deleting a committed secret in place of rotating it.
- Shared credentials across environments.
- API keys embedded in client-side code.
Security & Compliance
Claims and their disclosures
A claim and its required condition are one object, so a claim whose disclosure is missing cannot be rendered at all.
Data handling
The design question comes before the security question: a field that was never collected cannot leak, be retained too long, or turn up in a log.
Security posture
A description of practices, not a certification, published so it can be inspected and argued with.
Input and trust boundaries
Anything arriving from a browser was composed by whoever is sitting there, not by the form that was designed.
Sources and verification
A requirement drafted from general knowledge reads exactly like one drafted from the statute, so the source and the date are stored as fields.
Subprocessors
Every third party a system talks to holds part of what customers hand over; the list is short by design and written down.