77 lines
2.9 KiB
Markdown
77 lines
2.9 KiB
Markdown
# 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.
|
|
|
|
## Legal aspect
|
|
|
|
- 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)
|
|
|
|
|
|
## Related ISO clauses and controls
|
|
|
|
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:
|
|
- [Best practices eBook](https://www.synopsys.com/software-integrity/resources/ebooks/software-audits-in-mergers-acquisitions.html?intcmp=sig-blog-pebuyout)
|
|
- [Due diligence framework white paper](https://www.synopsys.com/software-integrity/resources/white-papers/evaluating-tech-mergers-acquisitions.html?intcmp=sig-blog-pebuyout)
|
|
- [Software due diligence checklist](https://www.synopsys.com/software-integrity/resources/white-papers/software-due-diligence.html?intcmp=sig-blog-pebuyout)
|
|
- [Open source data-based study](https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html?intcmp=sig-blog-pebuyout)
|
|
|
|
|
|
|
|
> Paul doet software DD
|
|
|