The document discusses the importance of conducting audits on open source software (OSS) to manage risks, including legal liabilities and security vulnerabilities. It outlines the processes for scanning OSS, analyzing the results, and creating compliance reports, alongside steps to mitigate future risks. It emphasizes the need for organizations to establish a robust OSS policy, utilize automated scanning tools, and remain vigilant about licensing obligations and security updates.

1. Performing an Audit
Dave McLoughlin
Director, Open Source Auditing Services
Rogue Wave Software
dave.mcloughlin@roguewave.com

2. 1. Future of Open Source survey
1% 10% 89%
What I
write
What
my team
writes
What my team uses and/or what
the OSS community writes
My Application =
• Over 50% of enterprise organizations adopt and contribute
to OSS today 1
OSS usage

3. OSS Risk

4. Lawsuit Threatens to break new ground on the GPLand
Software Licensing Issues
Aaron Williamson Open Source.com “Lawsuit Threatens to break new ground on GPL and software licensing issues http://opensource.com/law/14/7/lawsuit-threatens-break-new-ground-gpl-and-
software-licensing-issues July 30/2014
XimpleWare
V.S.

5. Technology acquisitions
• Inherited OSS Risks
• Reps and Warranties
• Value of target

6. Measuring open source risks
• Know your inventory with OSS scanning
– Automated, repeatable way to locate OSS packages (and
packages within packages!) and licensing obligations
– Look for scanning tools that:
• are SaaS – easier to set up and maintain
• Protect your IP by not requiring source code upload
• Maintain OSS support
– Get notified of latest patches, risks, bugs
• Establish an OSS policy to minimize risk
– Use only trusted packages
– Notify and update security fixes

7. Preparing for an audit
• How do scanners work?
• Create fingerprints of your code to compare with a fingerprint KB
• May also look for copyright, author, url, license information
• What do you scan?
• Ideally source code, but binary is okay
• Determine what you want to scan (version, product)
• Check your code out of your source code repository
• Objectives
• Set direction for audit: Security, Compliance, Governance

8. Audit process
• Scan files
• Small scans can take a less than a day to complete
• Large > million files could take a few days to complete
• Analyze results
• Analysis is done by professional OSS auditors
• Analysis typically takes a few days
• Create reports
• Reports should include OSS BOM and non-OSS BOM
• Licenses
• Obligation information
• Security reports (CVE and vulnerability information)
• Review reports

9. Example report
© 2015 Rogue Wave Software, Inc. All Rights Reserv
Open Source Bill of
Material (BOM) License Information
Compliance
Information

10. Next steps after an audit
This is where your work really begins
• Compliance work
• OSS License obligations are conditional
• Create compliance check list
• Review and complete compliance obligations
• Security review
• Review applicability of CVE
• Take necessary remediation steps
• Target review
• Review findings and assess impact on acquisition

11. Conclusions:
• Run an audit by to determine the following:
• Are there any licenses in deployed software that can put you at
risk. (i.e. Copy Left licenses)
• Are there any known vulnerabilities in the open source packages
you’ve distributed
• Create a policy to mitigate future risk:
• Establish a safe place to download open source software
• Ban licenses that can lead to risk
• Ban packages with known vulnerabilities
• Run periodic delta scans to ensure that the policy is
working

12. QUESTIONS
dave.mclouglin@roguewave.com