The fintech that shipped fast and could not say what it shipped

The situation

A company selling software into regulated financial institutions is part of those institutions' supply chain, and is assessed accordingly. The buyer's obligations become the seller's questionnaire.

What has changed is the nature of the questions. A buyer used to ask whether you had been penetration tested. A buyer now asks which version of a specific library is running in your production environment, and expects an answer in days, because that is the question they have to answer to their own regulator when a vulnerability is disclosed.

The problem

The fintech was good at security in the way most engineering-led companies are good at it. It ran regular penetration tests and passed them. It had a security engineer who was competent and overcommitted. It shipped several times a day.

It had just lost a procurement process with a tier-one bank, and the reason was not a vulnerability. It was that the bank had asked for a software bill of materials and a statement of which of its products contained a particular library, and the fintech had taken nine days to produce an answer that it then had to correct.

The underlying problem was that nobody knew what was in the product. Dependencies were pulled at build time, transitive dependencies were not tracked at all, and the answer to "what is running in production" could only be reconstructed by inspecting running containers. For a company shipping several times a day, any such reconstruction is out of date before it is finished.

The penetration tests had not caught this, and could not have. A penetration test tells you what an attacker could do on the day of the test. It says nothing about what you would do when a vulnerability is announced in something you did not know you had.

What we did

We argued against the client's initial plan, which was to pursue ISO 27001 immediately because that was what the lost deal had asked about. Certification was the right destination and the wrong first move: certifying a process you cannot evidence produces a certificate and no change, and the next bank would ask the same question and get the same nine-day answer.

The first work was therefore unglamorous. Generate a software bill of materials on every build, store it against the deployed artefact, and make it queryable. That turned "what is in production" from an investigation into a lookup.

It found 1,847 third-party packages in production, the large majority transitive. Three were unmaintained upstream, which nobody had known.

We then put the supply chain into the pipeline rather than beside it: build provenance attested, dependency policy enforced at merge rather than reviewed afterwards, and vulnerability alerts routed to the owning team with the affected services already named.

Only once that was running did we take the company through ISO 27001, which went quickly because the evidence the auditor wanted was now generated as a byproduct of shipping rather than assembled for the occasion.

The outcome

Time to answer a client vulnerability enquiry fell from about four days to around forty minutes, and the answer is now generated rather than researched.

Certification followed, and two stalled enterprise deals closed in the following quarter. The firm's own view is that the certificate mattered less than being able to answer the question in the meeting rather than afterwards.

The change in posture is the part that generalises. Security had been an event the company passed periodically. It is now a property the pipeline maintains, which is the only version that survives shipping several times a day.

A penetration test is a photograph. What the buyers wanted was a live feed.