richardk/iso27diy-corp
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Cleaned up Literature folder

Browse source
This commit is contained in:
Richard Kranendonk 2026-05-18 12:48:01 +02:00
parent 73a6380034
commit fe5eda4e05
586 changed files with 53911 additions and 2475 deletions
Download patch file Download diff file Expand all files Collapse all files

77
Corpus/Sparks/Software due diligence.md
View file

@ -1,77 +0,0 @@
# 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