What a software review covers
Technical due diligence for software is a structured review of a codebase to understand its quality, risk, maintainability, security, and likely remediation effort before a commercial or operational decision is made.
In the past, a senior consultant might review a codebase, speak with the engineers, and provide an opinion. Today, that is often no longer enough. Software is more complex, more interconnected, and more exposed to security, maintenance, and commercial risk than it once was. A meaningful assessment now requires a deeper review of the code itself, along with a clear view of its vulnerabilities, maintainability, and overall health.
Some of the most important issues in software are not visible in a quick review. Modern systems are made up of code, dependencies, integrations, and services that can work well on their own but create risk when considered together. A proper technical review looks across the whole system so hidden vulnerabilities, maintainability issues, and cross-system problems are not missed.
Where software has been built or modified in-house, it is important to understand what was changed, how it was reviewed, and whether the resulting code still meets the standard the business needs. A technical due diligence review is designed to identify those risks before they become expensive problems.
Who uses this service
The organisations that use this service vary, but they share the same objective: to understand the software well enough to make an informed decision. We custom the report to the priorities of the person or team commissioning the review, so the findings are relevant, clear, and decision-ready.
Why traditional reviews now fall short
Traditional software reviews were designed for a simpler technical environment. Modern systems are more complex, more interconnected, and more dependent on code working correctly across multiple services, integrations, and environments. That requires a more complete, evidence-based review.
Sellers are increasingly unable or unwilling to allow code to be copied to an external laptop. Security policy, regulatory obligations, and incident-reporting requirements often make that impossible. Reviews now need access methods that work within those constraints, rather than assuming one fixed approach.
At the same time, deal timelines have compressed. Software review work that once had months now often has only weeks, so slower models no longer fit the transaction window.
How software risk is assessed
A thorough review needs to look across the parts of the software that are most likely to affect value, risk, maintainability, and future change. The exact scope depends on the engagement, but the goal is always the same: to identify material issues before they become a commercial problem.
Code quality and maintainability
A Codebridge review looks at whether the codebase is readable, well structured, and practical to support over time. It identifies complexity, duplication, and design issues that may make future change harder or more expensive than it should be.
Security and access risk
A Codebridge review assesses whether the system is protected against unauthorised access, data exposure, and common security weaknesses. It looks for issues such as weak authentication, missing authorisation controls, exposed credentials, vulnerable dependencies, and other gaps that could increase the risk of intrusion or misuse.
Cloud costs and scalability
A Codebridge review assesses what the cloud infrastructure costs today, how those costs are tracked, and whether they are likely to remain sustainable as the business grows. It looks at spend trends, cost per customer, unused resources, and other factors that can affect margin and future investment needs.
Borrowed code and licensing risk
A Codebridge review assesses the use of third-party and open-source code, including whether it is properly tracked, licensed, and maintained. It looks at provenance, licence obligations, dependency chains, and security vulnerabilities that may create legal, operational, or intellectual property risk.
Extent of AI-generated material
A Codebridge review assesses the extent to which AI tools were used in the development of the product, and whether that use has been appropriately governed. It looks at code, documentation, and other content that may have been generated or assisted by AI, along with the associated risks around quality, ownership, consistency, and disclosure.
Key person risk
A Codebridge review assesses how dependent the business is on one or a small number of individuals for critical knowledge, decision-making, or delivery. It looks at what would happen if a key person left, including risks to continuity, maintenance, delivery speed, and the transfer of technical knowledge.
Development spend allocation
A Codebridge review assesses how development time and budget are allocated across new features, maintenance, technical debt, security, infrastructure, and other priorities. It looks at whether the business is investing in areas that support growth and resilience, or whether too much effort is being absorbed by rework, support, and legacy issues.
Scalability and growth capacity
A Codebridge review assesses whether the platform can handle more customers, higher usage, and greater transaction volumes without unacceptable performance, reliability, or cost issues. It looks at architecture, bottlenecks, load behaviour, and whether the current design can support the growth plan without major re-engineering.
Dead code and integrity risk
A Codebridge review assesses whether the codebase contains dead code, unused components, hidden logic, or other artefacts that were left behind intentionally or through neglect. It also looks for signs of code tampering, concealment, or malicious changes that could affect security, reliability, governance, or trust in the codebase.
Compliance and governance
A Codebridge review assesses whether the product and its development process comply with applicable laws, standards, contractual obligations, and internal policies. It looks at whether the business can demonstrate control over security, documentation, approval processes, dependency management, and other requirements that matter in a due diligence review.
Separating theoretical risk from real exposure
Run a security scanner over a real business system and it may return hundreds of warnings. Each finding may describe a technically valid weakness, but not every weakness is relevant to the way that particular system is hosted, configured, or used.
A vulnerability’s real significance depends on its environment. A weakness that is exposed on one hosting platform may be protected by default on another. A finding that matters on a shared server may have little relevance on a dedicated or tightly controlled environment. Automated scanners generally cannot make that distinction on their own, so they report a broad range of theoretical risks.
The result can be a long list of findings with no clear indication of which ones require immediate attention. When everything is presented as urgent, teams may focus on the easiest issues to resolve while the small number of genuinely serious risks remain unresolved.
How we assess real exposure
We map the codebase and its operating environment before interpreting the warnings. This includes the hosting, network, access controls, and the way the system’s components connect. We then assess which findings are genuinely reachable on that system and rank them according to what an attacker could realistically do.
The result is a focused, prioritised action list rather than hundreds of equally urgent warnings. Findings that are not applicable remain in the report, with the reasoning documented, so the assessment is transparent and does not need to be repeated later.
If you have limited time and limited money, this is the whole game. Everything else in this guide is about finding problems. This section is about knowing which ones to spend your first dollar on.
When safe components create a business risk
Many security reports list findings one file or component at a time because that is how automated scanning tools operate. This can miss risks that only appear when separate parts of a system interact.
Two parts of a system may each appear safe on their own, but create a security risk when they are connected. Their permissions, data flows, or points of access can combine to create an unintended path into sensitive information or critical functionality. These risks are unique to the way each organisation’s system is designed, so they will not appear in a generic warning list or a file-by-file scan. Identifying them requires the codebase, architecture, access controls, and system connections to be assessed together.
An example
A finance company uses one third-party component to generate PDF documents. The document design is retrieved from a web address supplied by the customer. On its own, that function may appear reasonable.
The company also uses another third-party component to process images. If an image address redirects elsewhere, the component follows that redirect. On its own, that may also appear reasonable.
The risk emerges when both components operate within the same request. A customer may be able to provide an address that the system follows, causing the server to reach internal services that should not be accessible from outside the organisation.
Each component may receive only a medium or low-risk rating in a standard scan. The serious issue appears only when the components, permissions, and network connections are assessed together. Mapping the complete system reveals the attack path and identifies the precise point where it begins.
This is the difference between a report that supports a real security decision and a list of scanner output. A file-by-file review may identify the individual components without showing how they combine to create an exposure. A complete assessment must explain the system-level path, its potential impact, and the specific location where the risk can be addressed.
AI-generated code and technical debt
AI-assisted development is now common across the software industry, but many organisations do not know how much of their codebase was generated or influenced by AI tools. That matters because AI-generated code can be functional and production-ready while still introducing duplication, unnecessary dependencies, security weaknesses, and maintenance work that is difficult to see from the outside.
Why AI-generated code can create hidden work
For a human developer, finding and reusing an existing solution is often preferable to writing the same functionality again. AI tools can make new code appear faster than searching a large or unfamiliar codebase, which can encourage repeated implementations of similar functions. Over time, this can create several versions of the same logic in different parts of the system. Each version may then need to be tested, maintained, and corrected separately when a defect or security issue is discovered. The result is not necessarily a visible failure today, but a larger and more expensive maintenance burden in the future.
Three common risks:
We assess the extent of AI-generated or AI-assisted code, identify where it is concentrated, and measure the duplication, unnecessary dependencies, and technical debt it may have introduced. We then review the highest-risk areas with the full system architecture in view, rather than treating the code as a collection of isolated files.
This matters particularly to investors and decision-makers. A company may build an impressive product in six months, while the underlying code carries years of unpriced maintenance, security, and remediation work. The question is not only what the product can demonstrate today, but what it will take to support, secure, and develop it tomorrow.
What the cloud really costs
Cloud infrastructure is often one of the largest operating costs for a software business, alongside its people. It is also a useful indicator of how efficiently the software operates.
The connection is not always obvious, so it is worth stating plainly: inefficient or poorly structured code can make the infrastructure work harder than necessary. It may request the same data repeatedly, retry failed operations too often, keep customers waiting for tasks that could run in the background, or handle errors inefficiently. The software may continue to function, so these issues do not always appear as visible faults. Instead, the infrastructure uses more computing power, database capacity, storage, or network traffic to keep the system running, and those costs continue each month.
An unexplained increase in cloud spend may therefore be more than a finance issue. It can be a sign that the software is carrying inefficiencies that have not yet been identified or addressed.
What happens when you fix it
When the underlying software issues are addressed, two costs can reduce at the same time: cloud spend, because the infrastructure is no longer compensating for inefficient code, and development effort, because the team can work with the system rather than around it.
Over the following year or two, those costs may gradually rise again as new features, integrations, and customer requirements are added. That is normal. Software health is an ongoing cycle, not a one-off exercise, which is why understanding where the system sits in that cycle has real financial value.
For a buyer, this is a number to put into the financial model: what will the software cost to operate over the next 12 months under the buyer’s growth plan, rather than the seller’s assumptions? Codebridge assesses the real infrastructure setup and provide a practical range for expected cloud costs under the organisation’s growth plan.
For an existing organisation, the same analysis shows whether current cloud spend reflects genuine growth or inefficiency in the software. It can identify opportunities to reduce unnecessary infrastructure costs without reducing customer-facing performance, while also showing how those costs are likely to change as demand increases.
Code integrity and handover risk
Most software problems are accidental, but some risks may arise from deliberate changes made by someone with legitimate access to the code or systems. These can include hidden access, unauthorised changes, or logic designed to disable or damage the software if a particular person, account, service, or condition changes.
This risk deserves particular attention during an acquisition, handover, ownership dispute, insolvency, or change in development team. The central question is whether the organisation can take control of the software with confidence that it has not been altered, weakened, or made dependent on people who are no longer involved. Insider threats can include malicious code, unauthorised access, sabotage, and misuse of legitimate privileges.
What we look for:
A genuine case study
This is not a hypothetical risk. During a software handover connected to a legal dispute, we were asked to assess whether the system contained deliberate mechanisms that could cause damage after control changed hands. The review identified code designed to delete the system if it lost contact with the location where the code was stored.
It also identified an internet-accessible path into a major customer database. This documented case demonstrates why code integrity, hidden access, and system dependencies must be assessed before software is placed under new ownership or control.
Where software is being transferred under difficult circumstances, code integrity and access security are not optional extras, they are essential preconditions for a safe handover. The system should be assessed before it is operated under new organisational control.
It is reasonable to hope that no deliberate damage or hidden access has been left behind. It is not reasonable to rely on hope where the consequences could include loss of data, operational failure, customer exposure, or serious reputational harm.
The Codebridge Assessment Stack
Codebridge uses a proprietary assessment stack built to analyse software more quickly and more thoroughly than conventional scanner-led reviews. Where large consulting firms often rely on the same commercial tools available to the rest of the market, then charge for the time required to interpret the output, Codebridge runs a purpose-built set of internal tools on every engagement.
This is one reason the work can be completed in weeks rather than months, and at a substantially lower cost than traditional consulting-led reviews. The four tools below perform much of the underlying analysis. What follows is not the mechanics of how they work, but the distinct question each one is designed to answer.
Why the last one matters most
Absence is difficult for a conventional scanner to detect. Most tools can only report what they can see directly, which means they are good at listing visible issues but weak at identifying what should have been present and was not. On one system, a standard scan produced approximately 800 findings. Analysing the same environment for missing controls, missing logic, and other forms of absence increased the number of potential issues into the tens of thousands. Most were minor, some were not, and many would not have appeared in a conventional scanner-led report.
How we do it in 2 to 6 weeks
This is how Codebridge finishes the job in 15 to 30 working days.
Access and Permission
Set up
Dig in
Report
If you want more
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
The back – written for your engineers
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.
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.
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.
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.
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.
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
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.