Codebase Security Review Before an Acquisition: Best Practices

Security findings discovered after an acquisition close are categorically more expensive than the same findings discovered during due diligence. The cost is not just remediation — it is the liability that accumulated between when the vulnerability existed and when it was discovered, and the impact on the combined entity's customers, regulators, and reputation. A pre-acquisition security review is not optional for any deal where technology is a material asset.

This guide covers what a rigorous codebase security review looks like before an acquisition, what findings mean for deal terms, and the specific areas where acquirers most frequently find problems.

What Pre-Acquisition Security Review Is Not

It is not a penetration test. A penetration test simulates an external attacker trying to compromise a system from outside. A pre-acquisition security review is a code-level and configuration-level assessment conducted with full access to the codebase, infrastructure, and documentation. The scope is broader, the access is deeper, and the output is a structured risk assessment rather than a list of exploitation paths.

It is also not the same as the security audit the target company may have commissioned on its own behalf. When a company commissions its own security review, the scope is often limited to what the team is comfortable disclosing, and the incentives are not aligned with surfacing every material finding. An independent pre-acquisition review is conducted on behalf of the acquirer with full access rights.

Core Areas of a Codebase Security Review

Authentication and Session Management

This is the most commonly problematic area in acquired codebases because authentication is often implemented quickly in early product stages and never revisited.

Review specifically:

• Whether passwords are hashed using a current algorithm (bcrypt, scrypt, or Argon2). MD5 or SHA-1 hashed passwords are a material finding.
• Whether session tokens are generated with cryptographically secure randomness and expire appropriately.
• Whether there is rate limiting on authentication endpoints — unlimited login attempts are an elementary control gap.
• Whether multi-factor authentication exists for administrative access to the system.
• Whether authentication tokens or session identifiers are transmitted only over TLS.

Secrets Management

Secrets — API keys, database credentials, signing keys — in version control history are one of the most consistent findings in acquired codebases. Even if a secret has been removed from the current codebase, it may still exist in git history and be recoverable by an attacker with repository access.

Check:

• The full repository history for committed secrets, not just the current state. Use a tool that scans the entire history, not just a current-branch scan.
• How secrets are managed in the production environment. Hardcoded values in deployment scripts or configuration files that are stored in version control represent the same risk as secrets in code.
• Whether secrets are rotated on a defined schedule, and whether rotation has actually occurred (not just been planned).
• Whether the principle of least privilege applies to service accounts and API credentials — each service should have only the permissions it actually requires.

Authorization and Access Control

Authentication confirms who a user is. Authorization determines what they can do. Authorization failures — where a user can access or modify resources belonging to another user or can call administrative functions they should not have access to — are a class of vulnerability that static analysis tools frequently miss because they require understanding the application's business logic.

Review:

• Whether there are direct object reference vulnerabilities — endpoints that accept an ID parameter and return or modify the corresponding record without verifying that the requesting user owns or has access to it.
• Whether administrative endpoints are protected by role checks, not just authentication.
• Whether the API surface has any endpoints that are present in the codebase but not documented or monitored — shadow APIs that may have been added for development convenience and never secured.

Dependency and Supply Chain Risk

Third-party dependencies are a significant attack surface. A library with a known critical vulnerability is an exploitable path into the system regardless of how well the first-party code is written.

Assess:

• Whether the dependency manifest is locked (lockfiles committed to version control) so that the exact versions in production are known.
• The current vulnerability status of all production dependencies, using a tool like snyk, npm audit, pip-audit, or equivalent.
• Whether there are transitive dependencies with known vulnerabilities that the direct dependency list does not make obvious.
• Whether any dependencies are sourced from unofficial or forked repositories rather than primary package registries.

Encryption at Rest and in Transit

• Is TLS enforced across all endpoints, including internal service-to-service communication?
• Is sensitive data (PII, payment information, credentials) encrypted at rest in the database?
• Are encryption keys stored separately from the data they protect?

Logging and Monitoring for Security Events

Post-acquisition, the acquirer needs to be able to determine whether the system was compromised before the deal closed. This requires that appropriate logging was in place.

Check whether authentication failures, privilege escalation events, and access to sensitive resources are logged, and whether those logs are retained for a sufficient period and stored in a location that would survive compromise of the primary application infrastructure.

How Security Findings Affect Deal Terms

Material security findings discovered during pre-acquisition review have several potential effects:

Escrow or holdback: The acquirer may require a portion of the purchase price to be held in escrow pending remediation of specific findings within a defined post-close timeframe.

Price adjustment: If the remediation cost of security findings is material, it may be deducted from the purchase price directly or used as leverage in renegotiation.

Representations and warranties: The seller may be required to make explicit representations about the security posture of the system, with associated indemnification for any breach discovered post-close.

Delayed closing: If findings are severe enough, the acquirer may require remediation before closing rather than accepting the risk at all.

The appropriate response depends on the severity of the findings and the deal context. The important point is that findings discovered during review are negotiating data — findings discovered post-close are liabilities.

Clixo conducts pre-acquisition security reviews as part of technical due diligence engagements and as standalone assessments. If you are evaluating an acquisition and need an independent security review of the target codebase, reach out to discuss scope and timeline.