The Pre-Engagement DevSecOps Audit I Always Run

The worst client onboarding I ever sat through lasted eleven minutes and ended with me declining the contract. The founder was charming, the rate was generous, and the moment he shared screen access I counted four live AWS keys sitting in a Slack channel, a deploy key with write access to all forty-two repositories “since we set it up in 2019”, and a CI workflow that ran whatever the internet submitted. I told him I would need a month of pipeline work — an intake DevSecOps audit, in the jargon — before touching his product roadmap. We settled on two weeks. This post is the audit I ran on his systems and have run on every engagement since — a freelancer-sized DevSecOps review, meaning it takes hours, not quarters, and it has saved me from inheriting three breaches that I know about.

Why a Solo Consultant Needs a DevSecOps Walkthrough

Here is the uncomfortable truth about contract work: you inherit risk the moment you push your first commit. If the repository you join has a compromised dependency or a leaked key, your name is in the git history of whatever happens next. Clients rarely think of it this way, which gives you a genuine opening — the audit is not just self-defence, it is the easiest upsell you will ever pitch, because the alternative framing (“your house is on fire”) is not required. What you are actually selling is a DevSecOps habit: security checks that live inside the delivery pipeline, applied to every change, with a record that survives the engagement. Small companies cannot hire a security team for a two-month project. They can absolutely hire you for a systematic walkthrough, and the walkthrough document you leave behind outlives your invoice.

Remote engagements make all of this more important, not less. On site, you absorb a company’s habits through hallway context — who shouts about what, which dashboards everyone actually watches. Remote, the pipeline is often the only honest witness to how the place really runs, because it cannot attend meetings politely. Ask for read-only access on day one, run the walkthrough before writing any product code, and treat what you find as the true onboarding document. Teams that resist a read-only review are telling you something that a video call never would.

The Checklist Itself

Everything below fits in a single working day for a mid-sized setup. I run it in this order because each step can change how urgently you treat the next:

Secrets sweep. Scan the repository and its history for credentials. Look specifically at old config files, CI environment blocks, and infrastructure modules where someone “temporarily” pasted a key in 2021. Gitleaks is free and takes minutes.
Push protection status. Check whether the platform actually blocks secret pushes, and — this is the detail people miss — who can bypass that block. On GitHub, by default, any repository writer can override push protection. A guardrail that every developer can silently lower is a note on a wiki.
Rotation story. Ask the client: if a key leaked this morning, who rotates it, how fast, and does anyone rewrite history afterwards? The correct order is rotate first and rewrite second; teams that answer this question with silence answer it again the hard way later.
CI credential hygiene. Long-lived keys stored as pipeline variables are the standard finding. The upgrade path is short-lived federated access — OIDC and workload identity — where tokens live for minutes instead of years. Wildcard trust policies in cloud roles deserve their own line in your report; “anyone in this account can assume this role” is not a policy, it is a wish.
Workflow supply chain. Are third-party actions pinned to full commit SHAs or floating on tags? Tags move; digests do not. While you are in there, confirm that pull requests from forks never receive secrets and that no workflow runs untrusted code under a privileged trigger. That particular trap has a name — pull_request_target — and checking out fork code under it is how public projects end up in incident reports.
Job permissions. Open the workflows and check whether every job declares minimum permissions or whether the whole pipeline runs on the default, which is usually too much. This fix is a diff of a few lines and it caps the blast radius of everything else you missed.
Dependency inventory. Confirm the team can answer “what versions of which libraries are in the running build?” without archaeology. If the answer is no, set up an SBOM on every build before your engagement ends — receipts beat memory, and the next vulnerability headline will test whether anyone kept them.
Gate sanity. Find out what, if anything, blocks a merge. The healthy configuration is narrow: fresh problems only, high confidence, genuinely fixable, serious enough to matter. Greedy gates that block on every medium-severity stale finding get overridden, and a gate the team overrides is worse than no gate, because it teaches people that security stops delivery.
Exception hygiene. Whatever did not block, ask where it lives. Exceptions need owners and expiry dates; ninety days is the common ceiling. An exception list without dates is a to-do list written in disappearing ink.
Write the memo. Two pages maximum: what you found, what you fixed, what remains, who owns each remainder. This document is why the client remembers the engagement as professional rather than expensive.

Red Flags That End Conversations

Some findings change the negotiation rather than the pipeline. I walk away — or reprice hard — when I see these:

Production databases reachable from CI runners with no audit logging, and no interest in changing that.
A “temporary” security exception older than the client’s current logo.
Nobody, including the founder, can name who receives alerts when something breaks at 3 a.m.
The word “compliant” used as a substitute for the word “secure” more than twice in one meeting.

None of these are technical problems at heart. They are tells about how the organisation treats evidence, and you would be joining that culture, not fixing it, on a short engagement.

What to Charge for a DevSecOps Audit

Price it as a fixed-fee deliverable, never hourly — hourly pricing punishes you for being fast, and this audit should be fast. My rough brackets for context: a solo founder with one repo and one pipeline sits at the low end of a day’s rate; a ten-repo organisation with cloud infrastructure runs two to four days; anything with regulated data goes up and brings a specialist along. Position the audit as phase zero, with the remediation work priced separately once the findings exist. And when the client asks what framework you are following — they will, because a name makes the invoice defensible to their board — point them at the DevSecOps reference I keep pinned in every client chat, which grounds the vocabulary without pretending there is a certification behind it. There is no official standard that blesses any of this, and saying so plainly has closed more deals for me than any acronym collection.

The broader freelance skills conversation — rates, positioning, the mess of wearing every hat — is well covered in the FAQ collection for people starting out in DevOps freelancing. If you are doing this alongside a day job, the audit is still worth running, just scoped to one repository at a time; the advice on holding down a DevOps side hustle without burning out applies double to anything that touches someone else’s production systems. And for those scaling toward bigger contracts, the guide on pairing cloud computing work with DevOps consulting pairs naturally with this one — the audit is the wedge that opens cloud architecture conversations, because every one of its findings is a cloud misconfiguration wearing a security costume.

Eleven minutes of screen sharing told me everything that mattered about that founder’s company. The audit turned what I learned into a document, the document turned into a retainer, and the retainer started — as these things increasingly do — with a rotated key and a calmer pager. That is the whole pitch. Run the checklist, write the memo, and let the receipts argue for the next contract.