Getting a platform ready for someone else's money

Earlier this year we ran a technical due diligence on a fast-growing consumer platform on behalf of prospective investors. The product worked, and parts of its design were very well thought through. The question an investor asks is different from the one a user asks: whether the engineering underneath can carry the growth the investment is meant to fund.

The first review raised serious findings. A few months later the critical findings had been closed and verified in production. The distance between those two positions is worth describing, because most fast-growing platforms have to cover it at some point.

Where the findings clustered

We reviewed the data room first, then the source code, the databases, the cloud accounts, the third-party services and the mobile application. There were many findings, and they gathered in a handful of places we would expect on almost any platform built quickly by a small team.

Credentials in source control. Keys for several third-party services had been committed over the years. Once that has happened, the safe assumption is that they are compromised until rotated.

Real data in a test environment. A non-production environment held real personal information, some of it especially sensitive. Test environments are built for convenience and are rarely protected like production.

Encryption that looked right. Content was encrypted with a sound algorithm used in a way that undid its protection. It is an easy mistake and an expensive one to leave in place.

No view of production. Without application monitoring or useful alerting, the team could not measure an incident, let alone show a customer a service level.

The team had spent its energy on the product, which is usually the right call until the day someone else's money arrives.

Fixing it, and proving the fix

Remediation was a condition of the transaction, and the platform's own engineers did the work. Our job was to verify it.

Every credential was moved into a managed secrets vault and rotated, and a targeted sweep across every repository found none left behind. The encryption was replaced with an authenticated mode and a fresh value per file, and we re-tested it against production artefacts as well as the code. Sensitive data on the device moved into the platform's hardware-backed keystore. The first round had only seen test environments, so we then reviewed the production consoles directly, with read-only access.

Sequencing mattered

We deliberately left penetration testing until the basics were fixed. While a static and configuration review is still producing critical findings, an attacker's-eye test adds little and costs more. The sensible order is to fix what is visible and verify it before paying for a test of what is not.

Questions to settle before the investor asks them

• Are there credentials in source control, now or in its history, and has every one been rotated?
• Does any non-production environment hold real personal data?
• Can the team show from monitoring what production did last week?
• Has anyone independent verified the fixes in production?

A platform that can answer those four cleanly is in a much stronger position at the table. Our cyber security practice does this work before the question is asked.