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.