iso27diy-corp/Corpus/Information Security/Software due diligence.md

2.9 KiB

Software Due Diligence

Risk Dimensions:

  • Legal
  • Security
  • Quality

Aspects:

  • product / strategy: is the software competative? Is there a roadmap?
  • people/organization
  • process and tools used by the teams
  • architecture/design
  • code: quality, security, IP/licensing

Consolidated code base

Code is a collection of pieces from different sources, and software is built by assembling from different sources:

  • commercial third party
  • legacy from a previoius product or acquisition
  • open source
  • code from outsourced production

Of code bases audited in 2020 , >70% was open source.

  • Copyright law is applicable to software
  • Using code without proper licensing can lead to lawsuits, loss of IP, reputational damage, loss of money, time and resources

Of code bases audited in 2020, 65% contained licenses with "potential to cause conflict", 26% contained components that were not licensed or contained custom licenses.

Security

Of code bases audited in 2020, 84% contained open source code with known vulnerabilities, and 60% contained high-risk vulnerabilities. The vast majority of these vulnerabilities where publicised and fixes where available, but not implemented.

Quality

Architectural quality influences developer productivity:

  • better design health: 20 KLOC per year per developer, 80% of time spent on features vs. 20% on repair -vs- 8 KLOC, 30% on features, 70% on repair

clear hierarchy, modular built, relatively few interdependencies

Approaching the risks

Acquisition:

  • due dilligence, incl. disclosures and discussions with coders and architects, third party code audits
  • deal terms
  • plan for remediation

Divesting (Selling stuff off):

  • anticipate in acquisition
  • implement best practicises before selling off
  • pre-sales due dilligence (to prevent law suits by buyers)

A 6.1.4 Contact with special interest groups A 12.6.1 Management of technical vulnerabilities A 14.1.1 Information security requirements analysis and specification A 18.1.2 Intellectual property rights

fix vulnerabilities through patches and updates.

Source: https://www.synopsys.com/blogs/software-security/software-risks-private-equity-buyouts/ Phil Odence, of Black Duck / Synopsys

Additional resources offered on website:

Paul doet software DD