← All work

An Australian financial services licensee · 2026

Deployment without stored credentials

If anything in your environment deploys automatically, it authenticates as something. Removing that credential is usually a shorter piece of work than writing the rotation policy you would otherwise need.

How to tell whether you have this

If anything deploys automatically, ask one question: where does it keep its credentials, and who can read them.

In a small firm the answer is often a variable in a pipeline that several people can see and nobody has looked at since the day it was set.

Why it happens

This is the finding that sounds careless and almost never is. A credential gets placed somewhere to make a deployment work, on the clear understanding that it will be tidied up once the thing is running. The thing runs. Nobody goes back. Two years later it is load-bearing and the person who put it there has left.

The trap in fixing it

The reflexive answer is a rotation schedule, and rotation is a real control. But it concedes the premise: that there is a secret, that it lives somewhere, and that its safety depends on a process being followed by people who have other jobs.

The stronger position is that the deployment path holds no credential at all. That is also much easier to evidence, because there is nothing to point at.

How I would approach it

  1. Replace the credential rather than protect it better. Federated identity means the pipeline authenticates without anything stored.
  2. Move whatever genuinely must persist into a vault, referenced rather than copied.
  3. Add the checks that belong in the same place anyway: dependency and composition scanning, artefact signing, and a manual approval gate on production.
  4. Make rollback boring. An explicit feature toggle with fail-fast configuration validation, so reversing a change is a decision rather than an incident.

What you end up with

Nothing left to leak, rotate, forget, or discover during an incident. The exposure is closed by removal, not by a control that depends on somebody remembering.

On who checks the work

Worth answering directly, because a single practitioner describing peer-reviewed pull requests invites the question, and the fashionable failure mode is a model reviewing its own output.

Peer review is by colleagues at AppGenie, where I am employed and through whom engagements can also run. On the engagement below, the design cleared four adversarial reviews and three compliance passes before anything was built. Those were human reviews. Tooling was used alongside them and deliberately left out of the count.

What it looked like in practice

delivered

Figures from the engagement described above, not a projection of what your estate would produce. Yours will look different.

RefFoundNowWhat the figure refers to
010stored deployment secrets after the change
0269automated unit and regression tests behind the shipped software

Is this yours?

If any of the above sounds like your estate, say so and I will tell you what checking would involve. Most of these start as a short look rather than a project.

Not sure it is this one? The rest of the work covers monitoring, identity, deployment, cost, AI use and compliance documentation.

Related work

All work