Inside a CodeBridge software check.

The CodeBridge method for checking a software company before you sign: the 2 to 6 week timetable, the terms that protect both sides, what a good report contains, three real Australian jobs, the rules that apply, and the questions we are asked most often. Every finding is signed, and every one points at an exact line of code.

How we do it in 2 to 6 weeks

This is how Codebridge finishes the job in 15 to 30 working days.

Before we start

Access and Permission

  • We sign the confidentiality agreement first. Ours runs for three years, and up to five if you ask. See section 12.
  • The owner gives us read-only access to where the code is kept. We work with all the common ones, whichever the company uses.
  • We agree with you and the seller how we will hold the code: inside their own systems, or in a locked-down environment of ours. Their choice, written into the agreement.
  • We build a copy of the running system in a sealed environment, so we can watch how it behaves without ever touching anything live.
  • Nothing aggressive runs without written permission. The stress and break testing in section 10 needs sign-off from the owner of the software and whoever hosts it. No sign-off, no test. That is not a formality: running those tools against a system you do not have authority over is a criminal matter, and we treat it as one.
week 1

Set up

  • We build a full map of the code and how every part connects.
  • We list the cloud services, the borrowed code, and every outside service the software talks to.
  • We ask the seller’s technology boss and lead engineers how the system is meant to work. Later we compare that with how it really works.
week 2

Dig in

  • We read all of the code, including the checks for two-part problems from section 6 and the missing-piece pass from section 10.
  • We stress-test the running system against the eight ways systems usually fail.
  • We read the AI-written parts, with the full map in front of us.
  • We work out the real cloud bill for the next 12 months, using your growth plans.
  • Where a handover is contested, we run the deliberate-damage checks from section 9.
week 3

Report

  • We separate the findings that apply to this system from the ones that do not, and say why for both.
  • We sort what is left by three things: how easy it is to exploit, whether it changes the price, and what it costs to fix.
  • We write it up, with the exact file and line for every single item.
  • We walk the draft through with you and with the seller’s technology boss at the same time.
  • We sign the final report and hand it over.
week 4-6

If you want more

  • A full check against the rules in section 16.
  • The evidence pack your cyber insurer needs to price the policy.
  • A plan for the risks of joining the two companies together.

How both sides are protected

This work only happens if the person who owns the code agrees to it. So the terms have to work for them too, not just for you. Four things make that possible.

A three-year confidentiality agreement

The industry standard is one year. Ours is three as standard, and five on request, at no extra cost. That matters more than it sounds. A deal that falls over in month eight leaves the seller exposed under a one-year agreement well before the commercial risk has passed. Three years covers the period in which the information could still be used against them. It is also the single most common reason a nervous seller says yes to us after saying no to someone else.

Read-only access

We can look. We cannot change anything. This is set at the source, not promised in an email.

The owner decides where the code sits

Some companies will not let code leave their building, because their own security rules or their industry regulator do not allow it. In that case we work inside their systems. Others would rather we took a controlled copy into a sealed environment of ours, so their production systems are never touched at all. Both are normal. The agreement says which one applies, and where any copy is destroyed at the end.

Written permission before any break testing

The tools that attack a running system are only pointed at software when the owner and the host have both signed off in writing. This protects them, and it protects us.

If you are the seller reading this

You are allowed to set the terms. A buyer’s adviser who will not accept read-only access, a long confidentiality agreement, and a written limit on what they may run is telling you something about how they intend to work. Ask for all three before you grant anyone access.

What a good report contains

The report is what you are paying for. Your investment committee will read it. Your insurance broker will read it. If the deal goes wrong, lawyers will read it. Almost none of those people are engineers, so the report is built in two halves.

The front – written for the person signing

  • One page, up front. The problems ranked, each marked “this changes the price” or “this does not”, with a number against it.
  • What it will cost you. The money to fix what has to be fixed, and the 12-month cloud bill under three growth scenarios.
  • What we would do about it. Where the first dollar goes, and what can safely wait.
  • What does not apply to you. The warnings we ruled out, and why. This is usually the longest list and the reason the short list is trustworthy.
  • A signed page, with the names of everyone who reviewed it.

The back – written for your engineers

  • Every problem, worst first, each with the file, the line, how hard it is to fix, and how easy it is to attack.
  • Two-part problems, set out separately, because they need a longer explanation.
  • A full list of borrowed code and the licence attached to each piece.
  • How much AI wrote, which parts of the system it wrote, and the duplication it left behind.
  • Who knows what, worked out from the code and its history, not from interviews.
  • A rules check, against each Australian rule that applies.
  • What we looked at and how, including which tools we used and where each finding came from.

The order is the point. A partner or an underwriter should be able to read the first three pages and make a decision. Their technical people should be able to read the rest and start work on Monday. A report that mixes the two gets skimmed by both.

One question to ask before you hire anyone

Ask to see a sample report structure. It must show, for every finding, what they looked at, how they looked at it, and what they concluded. If they cannot show you that, the report will not hold up in an argument after the deal closes. Ask before you sign them up, not after.

Keep checking after the deal closes

The biggest lesson of the last three years is simple. Checking the software once, before you buy, is not enough. That first check is your starting point. After that you keep watching, every three months.

Once the deal is done, the same tools stay switched on inside the company you bought. Every quarter you get a short update: what changed, what new risks appeared, whether the cloud bill is tracking the forecast, and which new rules now apply.

If you own 20 to 40 companies, this replaces the yearly audit from a big consultancy at about 15 percent of the cost. It also gives you the running record that cyber insurers now ask for before they will renew your policy.

Three real examples

Three jobs, three different reasons for the call. Details are kept general where the parties are identifiable or matters are still on foot.

first reason

A handover nobody wanted to make

An Australian point-of-sale software business was changing hands in the middle of a legal dispute. The lawyers involved asked us to check the software for anything left behind deliberately, before the new owners switched it into their own name. We were brought in specifically because neither side trusted a check run by the other.

We found three things.

  • Code set to delete the entire system at four in the morning, triggered if the software ever lost contact with the place the code was stored. Cutting off the old team’s access would have set it off.
  • A way into the biggest customer’s database, left open to anyone on the internet, with full access to read and destroy the contents.
  • A third access point of the same kind, in a different part of the system.

None of these were accidents, and none would have shown up in a standard security scan. The handover went ahead with all three closed first.

second reason

A hosting bill nobody could explain

An established Australian software business had watched its monthly cloud bill climb for two years. Their team had already tried the obvious answer, moving to cheaper machines, which had not worked because the problem was not the machines.

We went through the software and the setup together. The bill was high because the code was making the rented computers do a great deal of unnecessary work: repeating the same database questions, retrying failed jobs indefinitely, and making customers wait for things that should have run quietly in the background.

We took between $5,000 and $6,000 a month off the bill, with no noticeable change in speed for their customers. Nothing was bought. Nothing was migrated. The savings came from fixing what the software was doing.

third reason

A committee voting in 21 days

An Australian investment fund had agreed to buy a finance software company. The seller would not let anyone copy the code off site. The first firm the buyer asked quoted 10 weeks. The buyer’s committee was voting in 21 days.

We worked inside the seller’s own systems from day one. By the end of week two we had found three problems big enough to change the price. The seller’s own security scanner had missed all three.

  • Two pieces of borrowed code that, together, let an outsider reach the company’s internal systems. This is the example from section 6.
  • A part of the payment system that made customers wait instead of working in the background. Under the buyer’s growth plan, it would have fallen over in month six.
  • A cloud bill that would run 40 percent higher than the seller had forecast, once the buyer’s growth plan was applied.

The signed report landed in 15 working days. The buyer used it to knock the cost of the two engineering fixes off the purchase price, and to rebuild their financial model with the real cloud bill. The deal closed on time.

Australian rules you must follow

Every check has to say whether the company follows the rules that apply to it. Four sets of rules matter most.

Rule

Who has to follow it

What we check

APRA CPS 234

Banks, insurers and super funds, plus the companies that supply them

Installs and runs open-weight models on site with safety controls.

Can they keep data safe? Do they report break-ins on time? Do they check their suppliers?

APRA CPS 230 (from 2025)

The same companies, wider rules

Do they know which systems are critical? How long can each one be down? Do they have a list of who they depend on?

Australian Privacy Principles

Most Australian businesses earning over $3 million a year

How they handle personal data, whether they send it overseas, and whether they can report a leak quickly

DORA (European rule)

Any company with European finance customers

How they manage technology risk, supplier risk, and whether they test that the system keeps running under stress

If the company sells to Australian banks, or to anyone in Europe, the report must name these rules directly. If you buy a company that does not follow them, the cost of fixing that becomes yours on day one.

Common questions

They interview the engineers, read some of the code, and write a careful report that avoids saying anything too firm. We run AI tools across all of the code, point at exact lines, and finish in a fraction of the time. The two can work together. We often act as the technical partner while a big firm handles the financial side.

Our tools are built to run on machines the seller controls, so the code never has to leave their building. Sellers who have already refused a big consulting firm over code copying usually say yes to us after a 30-minute call with their head of security. Where a seller would rather we took a controlled copy instead, so their live systems are never touched, we do that. Section 12 covers both.

Yes, in writing, from the owner of the software and from whoever hosts it. The tools that attack a running system are indistinguishable from a real attack, and using them without authority is a criminal offence. If we cannot get that permission, we do the code work and leave the live testing out of scope. We will not proceed on a verbal assurance.

Yes, and it is the cheapest version of this work. You get the same report a buyer’s adviser would produce, months earlier, while you still have time to fix things. Most sellers use it to close the two or three findings that would otherwise have cost them real money at the table.

Yes. The full history of the code shows where the work is actually happening: which parts of the system are being maintained, where changes get rewritten, and how the effort is distributed across a team. It answers questions a status report cannot. Section 4.7 sets out how we handle it.

Yes. It is a growing part of what we do. When a software business fails, someone has to tell the creditors what the code is worth, whether it will keep running, and what it will cost to keep it running. We do that, and we have been through the full process before: the check, the handover, and helping the new owners keep the business trading.

Yes. Every finding points at a specific file and line, and we can trace it back from the report to the raw code. The report also records what we looked at, how, and what we concluded. That is what a court or a regulator asks for. We have produced this work in the middle of active litigation, at the request of the lawyers involved.

Yes, and it often is. Insurers need the same evidence to price a policy. One piece of work, two uses.

The main 2 to 3 week job is $60,000 to $120,000, depending on how big the software is. The 6-week version, with the rules check and the insurance evidence pack, is $120,000 to $180,000. Ongoing quarterly checks after the deal are about $8,000 per company per year, with a minimum of 10 companies.

Yes. We are based in Melbourne, and we work on companies in the UK, the US, Europe and across Asia. The work does not depend on being in the room, so it does not matter which country the software sits in.

Get the PDF version.

The whole guide as a PDF you can print and hand around: to your deal team, your investment committee, your underwriters, your lawyers, or the board. We will send our checklist template with it.

talk to our teamCall 1300 840 340