Codebase Security Review Before an Acquisition: Best Practices

A pre-acquisition codebase security review identifies risks the buyer may inherit and estimates the work needed to address them. Define access, scope, and evidence requirements early enough for findings to inform remediation and deal discussions.

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. Check the scope, access limitations, date, and unresolved findings of any previous review. Agree on the access an independent reviewer will need for the acquisition assessment.

Core Areas of a Codebase Security Review

Authentication and Session Management

Review authentication and session management even if they have changed little since the product launched.

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

Look for secrets such as API keys, database credentials, and signing keys in version control history. 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. Record each finding, its evidence, remediation estimate, and owner so the deal team can assess it.