Don't make it easy for attacks: Build defenses that cover software relationships

Cybersecurity Awareness Month puts most of its attention on keeping attackers out, and that attention is well placed. The advice works. Access control, segmentation, monitoring that notices something moving where it shouldn't, and regular testing all raise the cost of reaching you.

Most of the software your business runs on, though, belongs to other companies, and their security is something you read about in a questionnaire once a year. When one of them is breached, the outage lands on you and the fix doesn't.

This post follows an attack across a software relationship, from how it reaches you, to who pays on each side when it lands, to what keeps recovery possible when the other side is offline.

Hardened stacks still leave a door open

You can harden your own systems as far as you like, and plenty of companies have. Their defenses have been tested by people paid to break them, their certifications have been audited by people paid to doubt them, and the controls in place are the ones every framework recommends.

Attacks land anyway. Sophos surveyed organizations hit by ransomware last year and found that 56% of attacks succeeded in encrypting data. Among victims breached through stolen credentials, 97% already had multi-factor authentication deployed. Having a control is not the same as being covered by it.

And however thoroughly you have boarded up access to your own software, that protection ends at the edge of your own systems. Everything past that edge was secured by someone else, to a standard you didn't set.

Your security program decides how hard you are to breach. Your software relationships determine whether an attack gets in anyway.

Attacks reach you through the companies you rely on

Attack is one of four risks that can take your software away from you, and the one companies prepare for hardest and still lose to. When it hits a company you depend on, you don't get a seat in their incident room. You get the consequences.

An attack on a vendor can stay entirely on their side, take their service offline, and pull down everything you run on it. It can also travel down the relationship and end up inside your own systems, carried there by software they supply.

• Ransomware encrypts a vendor's production and development environments in one operation, and Sophos puts the average recovery cost at $1.7 million before any ransom. Their service stays offline until that recovery finishes, and so does every system of yours built on it. 

• Supply chain infiltration comes through the update channel you were told to keep current. Credential-stealing worms hijack developers' publishing accounts, poison every package those accounts control, and ride the next routine update into your systems. Shai-Hulud, for example, hit over 500 packages in 2025 and passed 1 280 in August 2026.

• Backup destruction goes after your vendor's fallback, and with it yours. Ransomware crews hunt for disaster recovery first, because removing the way back is what makes the ransom worth paying. In a Sophos survey of victims, attackers went after backups in 94% of incidents and succeeded 57% of the time.

All three routes turn someone else's breach into your outage, and Verizon found the share of breaches involving a third party doubled to 30%. Every company you rely on is fielding around 2 422 attacks a week, the August 2026 average Check Point recorded, and only one has to get through.

» Find out how common attacks are in your industry in our State of Software Resilience article. 

A single breach lands on both sides of the relationship

Let's take a closer look at how an attack on a vendor cascades down to everyone who depended on them. A recent incident in European aviation shows it clearly, because the same breach handed the vendor and its customers very different problems.

On September 19, 2025, attackers hit MUSE, the check-in, bag drop, and boarding software Collins Aerospace supplies to airports across Europe. Brussels, Berlin Brandenburg, and London Heathrow went back to checking passengers in by hand, and the EU's cybersecurity agency, ENISA, confirmed ransomware as the cause.

MUSE lets several airlines share the same check-in desks and boarding gates instead of each running their own systems. That shared setup is why airports adopt it, and it is also why one breach at one supplier stopped check-in at several airports over the same weekend.

RTX, Collins Aerospace's owner, told reporters the impact was limited to electronic check-in and baggage drop and could be handled manually. That same weekend, Brussels Airport asked airlines to cancel half of its 276 Monday departures, because Collins was not yet able to deliver a secure version of the software.

Both statements were accurate, but Collins could work on the fix while the airports could only wait for it. Their own networks weren't the target, yet they had no way to repair software they didn't run, so passengers queued for hours until Collins delivered.

Collins carried the other half of the damage. Its own breach was now the cause of its customers' outages, and RTX had to confirm to the SEC that customers had shifted to backup or manual processes. For a software vendor, that is the scenario buyers ask about before they sign.

Both sides came out of it needing the same thing: a way for customers to keep operating that doesn't hinge on the vendor's incident response. Your attack surface is as big as every service you rely on, and if you sell software, you sit inside each customer's attack surface too.

» Take a look at how another attack exposed over 70 banks in the Marquis breach.

Secure your ability to recover outside the software relationship

Every set of armor has seams somewhere. A motivated attacker finds one eventually, either in your own defenses or in the defenses of a company you rely on, and protection only decides how long that takes. What happens after that depends on what you can recover.

There is a short list of things you cannot do about the second route. You cannot audit your way into another company's incident response, you cannot patch their build pipeline, and you cannot make their backups survive an intruder who found disaster recovery first.

What you can decide is whether a clean copy of the software exists somewhere neither network can reach. This is where your own backups stop being enough, for the reason the ransomware groups worked out years ago. Your backups live inside the environment the attack is in.

Escrow is how that copy gets made and kept. An independent third party like Codekeeper holds it under release conditions agreed in advance, because nothing useful gets negotiated during an incident. What it covers depends on how the software runs and what keeps it running.

• Software Escrow holds the source code, data, and documentation for software installed on your own systems. When the release conditions in the escrow agreement are met, the deposit comes to you, and you can rebuild without waiting on the vendor.

• SaaS Escrow goes further for software that runs in someone else's cloud, where source code alone would leave you with a repository and nowhere to run it. It also holds the deployment infrastructure, third-party dependencies, and credentials, so the whole environment can be stood back up.

• Continuity Escrow keeps the hosting and third-party services behind your software paid for when a payment lapses, a real risk for a vendor absorbing an expensive recovery. Once the missed payment is flagged, Codekeeper covers the bills for up to 12 months while a long-term fix goes in.

A deposit nobody has opened carries the same risk as a backup nobody has restored. Verification builds the deposit and confirms it runs, and because deposits can't be altered once they're stored, what you recover can't have been encrypted or changed by an attacker on either side.

Every verification also produces a Software Resilience Certificate, documented proof of recovery. Buyers get evidence that a vendor's breach won't strand them. Vendors get something concrete to put in front of buyers who raise that scenario before signing, which is a stronger answer than any description of their defenses.

Test your recovery before an attacker does

That proof matters, because penetration tests and audits only ever give your defenses a practice score. The real grade comes from an attacker, on a date you don't choose, and a breach that never happens leaves nothing to measure.

Recovery is different. You can rebuild from the deposit, bring the environment back, and confirm the people involved know how, on an ordinary Tuesday with nothing on fire. And because that deposit sits outside both networks, an attack can't change it, so Tuesday's result holds on the worst day too.

An attack is the fastest way for one side of a software relationship to go dark. It is not the only way, and the next post in our Cybersecurity Awareness Month series covers what happens when a vendor fails on their own accord.

» Secure your way back with Codekeeper's software resilience solutions, so you're ready to recover no matter what happens to the software you rely on.