Client engagement · September 2026 · Anonymized

A client had inherited production systems from previous engineering teams. During routine security scanning, we found existing vulnerabilities: fixed what we found in priority order, wrote it up as a formal security report for the client’s leadership, along with a remediation plan for what remains.

To protect the client and their users, we’ve stripped identifying details from this write-up: what the systems do, what they run on, and the specifics of each finding. The shape of the work is accurate.

Outcomes

66 exposure findings ranging from critical to low across both systems' code and deployment history
Hours from approval to critical exposure remediations applied
15 → 0 legacy services callable by anyone on the internet

How we worked

We started with a source review and rated every finding on one severity scale, from critical to low. Reviewing live configuration and logs during remediation turned up more issues the review alone had missed.

Critical exposures came first. Each fix was proposed, approved by the client, applied, and then verified against live traffic. Changes were made in the order of least disruption, so the product kept working throughout. Every change made outside normal deployment was written down along with how to roll it back. Where the final step depended on a third party, the report says so rather than calling the issue closed.

Saying what the evidence supports

A security report is only useful if leadership can act on it, and that means separating what is known from what is assumed. The report sets out what each issue made reachable, and is explicit that this is not a record of what was accessed. Where the logs could not settle whether an issue was exploited, the report says that plainly instead of guessing either way. We also closed the logging gaps, so the question can be answered next time.

What we delivered

  • Source audit: findings across the code and deployment history, rated on one severity scale
  • Critical containment: public exposures closed and verified, with the product kept running
  • Credential and access hardening: leaked credentials contained or rotated, unused features turned off, and access reviewed for people who had left
  • Audit trail: logging enabled so that future activity can be attributed
  • Formal security report: written for leadership, with severity, exposure windows, and evidence of exploitation stated plainly
  • Living remediation plan: every finding traced to a small set of root causes, turning a long list into a short backlog, plus the decisions only the client can make

Details of the client organization are withheld under NDA. Inherited a system you’re not sure about? Get in touch.