Credentials in Development

The setup guide says install the tools. The reality is that a new developer spends two days waiting for access to a registry, a database and a shared cache.

Where the time goes

Sequential approval. Three access requests, each taking a day, raised one after another because nobody listed them upfront.

Undocumented prerequisites. A credential everybody has and nobody remembers obtaining.

Manual provisioning, where someone must be found and asked.

Rotation with no notice, which breaks working environments and produces a support queue.

Fix the sequencing first. Listing every credential a developer needs, and raising all the requests on day one, frequently halves onboarding time on its own.

The workarounds people use

Predictable and worth naming, because they are the cost of a bad process.

Sharing credentials between developers.

Committing a .env file, usually accidentally and permanently in history.

Long-lived personal tokens with broad scope, created once and never rotated.

Copying production credentials for local use, which is the worst of them and is done because the alternative was slower.

Each is a rational response to friction, which means the fix is the friction rather than a policy telling people not to.

A workable arrangement

A single command that provisions everything a developer needs, authenticated through the identity system they already have.

Short-lived credentials, issued on demand rather than held.

Read-only where possible. Most local development needs to read from the registry and the cache, not write.

No production access by default, with a separate, audited path where it is genuinely required.

Local secrets in the operating system's credential store, not in files in the repository.

Scanning for committed secrets on every commit, blocking rather than warning, with a documented override.

The shared cache case

Specific to this field and frequently mishandled.

Developers should read from the remote build cache and not write to it. Writes come from trusted CI machines.

That is a security property and a correctness one: a poisoned cache entry from a compromised laptop propagates to everyone.

Read credentials can be short-lived and broadly issued; write credentials should be few and machine-held.

When a credential is exposed

It will be. Have the procedure before it happens.

Rotate first, then investigate. The order matters and gets reversed under pressure.

Assume the history is public once something is committed, regardless of whether the commit was amended.

Record it, because the pattern matters more than the instance: three exposures in the same place is a tooling problem.

What to measure

Time from joining to full access, which is part of the onboarding number.

Number of manual steps in provisioning.

Age of the oldest long-lived credential in developer use.

Secrets caught by the commit scanner, trended. A rise means the friction has increased somewhere and people are working around it again.

The access checklist

The document that halves onboarding time in most organisations, and it does not exist anywhere.

Every credential a developer needs, listed: registry, container registry, build cache, test database, monitoring, deployment.

Who grants each, and how long it takes.

Raised on day one, in parallel, rather than discovered in sequence over a fortnight.

Reviewed when anything changes, which is the part that requires an owner.

Include it in the setup script where the request can be automated.

Scanning on commit

The control that stops the problem growing while the process is fixed.

Run detection before the commit reaches the shared repository.

Block rather than warn on high-confidence findings, with a documented override.

Scan history once for the existing backlog.

Treat every true positive as a compromise and rotate, because you cannot know who read it.

Tune the rules, since false positives train people to override reflexively and that is worse than no scanner.