The most alarming security incident I have been close to did not involve our systems being broken into at all. A small supplier we used for a single, unglamorous back-office function got compromised, and because that supplier held an integration token into one of our environments, the attackers arrived through a door we had personally installed and then stopped thinking about. Our perimeter was fine. Our patching was current. None of it mattered, because the weak link was a company of eleven people whose security posture we had assessed exactly once, three years earlier, with a questionnaire.
That questionnaire is the part that stays with me. We had done the process correctly by the standards of the time. Somebody had filled in a spreadsheet, ticked boxes about encryption and background checks, and filed it. What we never did was revisit it, or ask what access we had actually granted after the contract was signed, which turned out to be considerably more than the original scope described. The paperwork described a relationship that had been true at signing and had drifted steadily ever since, the way every integration does.
Third-party risk is uncomfortable precisely because you cannot fix it with better engineering on your side. You can harden everything you control and still be exposed through a connection you deliberately created for good business reasons. The vendor is not the enemy here, and treating them as one produces nothing but adversarial paperwork. But their controls are now genuinely part of your attack surface, and pretending otherwise because they are outside your org chart is a comfortable fiction.
So the questions I care about have shifted from what a supplier promises to what they can actually reach. What exact permissions does this integration hold, and would anyone notice if it started doing something unusual at two in the morning? Is the credential scoped to the one thing it needs, or is it a convenient key with far more range than the use case requires? Can we cut that connection quickly, on a bad day, without a change advisory board meeting first?
You cannot audit your way to trusting someone else's security team. You can limit what their bad day is capable of doing to yours.
– Serguey Shinder
Top comments (0)