Companies’ use of open source software has surpassed the occasional and solidified itself as the mainstream. Effectively identifying and managing the compliance and security risks associated with open source software can be a difficult task. Whether a company is acquiring another company, preparing for acquisition or simply wanting to manage their use of open source, the universal first step is to figure out the composition of the code, often via an audit. But what do you do once you have the audit report? For more information, please visit our website at https://www.synopsys.com/open-source-audit

1. © 2019 Synopsys, Inc.1
You’ve Got Your Open Source Audit Report—Now
What? Best Practices for Companies of All Sizes
Tony Decicco, GTC Law Group & Affiliates
Leon Schwartz, GTC Law Group & Affiliates

2. © 2019 Synopsys, Inc. 2
Speakers
Leon Schwartz
Associate,
GTC Law Group &
Affiliates
Tony Decicco
Shareholder,
GTC Law Group &
Affiliates

3. © 2019 Synopsys, Inc. 3
Agenda
1. Brief overview of review process
2. How do you select and prepare the code base?
3. How do you get the most out of your Black Duck code scan?
4. How do you implement a third party software policy?
5. How do you contribute to the open source community?
6. Q&A

4. © 2019 Synopsys, Inc. 4
Brief overview of the review process

5. © 2019 Synopsys, Inc. 5
Typical review process
OVERALL GOAL: Identify, quantify, mitigate, and allocate risks related to third party software
Bill of materials
Notice and
attribution files
Reps and
schedules
OUTPUTS
Identify Plan / Remediate
Select code base
Define goals
INPUTS

6. © 2019 Synopsys, Inc. 6
Typical review process: The phases
• Identify
– Open source and commercial software
– Embedded in or used to develop your products
– Developer-identified and via code scan
• Analyze
– Review usage / compatibility analysis
– Assess compliance and business impact
– Consider:
– Internal use, distribution, hosting, modification, linking, use as
a code generator
• Remediate
– Create a remediation plan
– Code remediation
– Legal remediation
– Notice and attribution files
– Transactions: allocate risk through contract terms

7. © 2019 Synopsys, Inc. 7
Typical review process: Not as easy as you think

8. © 2019 Synopsys, Inc. 8
How do you select and prepare the code base?

9. © 2019 Synopsys, Inc. 9
Preparing for a code scan
Initial steps for companies of all sizes:
• Select a code base to scan
– Importance
– Size
– Likely variety of components
– Number of developers
• Smaller companies focus items:
– Biggest “bang” for the buck
– Code base with most shared code
– Likeliest to get done
– Code base with less busy / nicest developers
– Smaller code base
– Code bases with fewer release cycles
– Most important code base
– Which code base are acquirers / investors likely to
worry about most?
– Which code bases are customers asking about?
• Larger companies focus items:
– Code base with most exposure
– Management interest
– Widest distribution / most customers
– Highest revenue
– Highest risk
– Most established product, with fewest
anticipated changes
– Newest product
– Next generation of existing product
• Prepare code base for scan
– Remove known-unused components
– Exclude known third party components?

10. © 2019 Synopsys, Inc. 10
How do you get the most
out of your Black Duck code scan?

11. © 2019 Synopsys, Inc. 11
Prioritize, prioritize, prioritize
• Most of the time, it is difficult
to review everything
• The review process can be time consuming, labor
intensive, and difficult
• Very important to focus on likely riskiest areas
first
• Goal should be to run out of time / energy on the
least risky items
Never
Later
Tomorrow
Today
NOW

12. © 2019 Synopsys, Inc. 12
Strategies for prioritization
• Identify / eliminate false positives
– Components no longer in use / obsolete
– Misidentified components / other explanation
• License categories
– Unknown license
– Less commercially friendly licenses
– Patent non-enforcement
– Public domain

13. © 2019 Synopsys, Inc. 13
Strategies for prioritization
• Components with dual-license models
– Limited use or commercial license
– amCharts
– Restrictive open source license or commercial license
– iText PDF
– Qt for Application Development
– RabbitMQ
– CKEditor
– JasperReports
– Sencha Ext JS
– TinyMCE
– Noncommercial use or commercial license
– Qt for Device Creation
– Highcharts
– MySQL

14. © 2019 Synopsys, Inc. 14
Strategies for prioritization
• Components with known enforcement or other
potential issues
– “Familiar names”
– Continuent vs. Tekelec
– XimpleWare vs. Versata
– CoKinetic vs. Panasonic
– Artifex vs. Hancom
– Patrick McHardy (Netfilter and other projects)
– Dual-licensed components
– Increasing efforts to coerce commercial licenses
• Components that follow recent trends
– License changes for Confluent, MongoDB, Redis
Labs, Cockroach DB, and others
– Attempt to limit use “as a service”
– Might be broader than intended

15. © 2019 Synopsys, Inc. 15
Additional “cheat codes” for prioritization
• Companies of all sizes:
– Well-run/long-standing projects
– Projects that have completed review
– Projects with subscription agreements
STARTB AB A
• Smaller companies focus items:
– All the items to the left
– License collection for “generic” licenses
– Strategic usage information collection
– Lower-risk usage scenarios
– Lower-risk licenses
• Larger companies focus items:
– Review of “fourth party” components
– Easy-to-remediate components
– Industry practice / well-known components
– Linux
– Hibernate
– Commercial components
– How familiar is the list?
– “Microsoft Content”

16. © 2019 Synopsys, Inc. 16
Security vulnerabilities
• Rank vulnerabilities by order of:
–Severity of risk
–Complexity of exploiting the risk
–Complexity of fixing the risk
• Create a process for evaluating security fixes and applying them
• The process does not have to be perfect (none are), but it should be reasonable
–Following NIST guidelines
–GDPR Article 32
–“Implement appropriate technical and organizational measures to ensure a level of security
appropriate to the risk, including … (d) a process for regularly testing, assessing and
evaluating the effectiveness of technical and organizational measures for ensuring the
security of the processing.”

17. © 2019 Synopsys, Inc. 17
Web services
• External services used by your applications
– Usually through an API
– Can be “free”
– Can be hard to identify/quantify
• Prioritization
– Examine how used
– Separate API agreement?
– Not common; usually morass of terms (ToU, EULA, privacy policy, data policy)
– Importance of external service to product
– Who is the licensor?
– Competitors, “frenemies”
• How to review
– Review is same as code: confirm you have rights and using within scope

18. © 2019 Synopsys, Inc. 18
Overall calibration
Many of the details are in the eye of the beholder
Important to keep in mind:
• Your goals
• Context of the review

19. © 2019 Synopsys, Inc. 19
How do you implement
a third party software policy?

20. © 2019 Synopsys, Inc. 20
Third party software policy
• What is it?
– High-level guidelines for use of third party software
– Processes for review of third party software
– Consider privilege
• How is it created?
– Best when collaborative effort, not edict from mountaintop
– Identify stakeholders and highly-opinionated influencers (key people)
– Draft policy and solicit input
– Listen to the stakeholders’ feedback
• When should it be written?
– Ideally after initial review, when you know your risk tolerance
– As soon as possible, so less remediation will be required in the future
• What does it cover?
– Broad, but not so broad as to capture software present on fax machines
• What makes a good one?
– Brevity; avoid overly complicated policies and covering every “corner case”
– Balancing act between strict compliance and practicality
– Ironclad policies that don’t work in the real world won’t be followed
– Living document

21. © 2019 Synopsys, Inc. 21
Third party software policy considerations
• Smaller companies focus items:
– More informal policy and review process
– Train developers to use easier-to-approve
components
– Mandate use of package managers?
– Update policy as new licenses are encountered
• Larger companies focus items:
– Diverse approval committee
– Automatic approval / rejection?
– Record-keeping
– Available tracking tools
– Black Duck Hub
– Code Center
– Auditing mechanism
– Periodic code scans

22. © 2019 Synopsys, Inc. 22
Third party software policy substance
• How is guidance on preferred licenses provided?
– Broad-terms guidance in the policy itself
– More detailed guidance, including “corner cases” through training
• How will the policy be enforced?
– Integrate review/enforcement tools with tools already in use
– Consider having employees sign the policy
– Perform future code scans
– Perform spot checks
– KGB-style encouragement of tattling on your neighbor
• Final thoughts
– Make sure policy matches practice
– Do not treat policy as set in stone

23. © 2019 Synopsys, Inc. 23
Shifting “left” and automation
• Shifting “left”
– Move assessment and compliance process earlier in the development process
– Provide feedback earlier
– Make corrections before they become costly
– Changes culture of development team
• How?
– Integrations
– Black Duck software composition analysis
• Automation
– Allows to auto-approve and auto-reject certain components
– Use automated policy engines and rules
– 80/20 rule: 80+ percent of components can be approved or denied based on
bright-line rules
– Permissive licenses can be approved for virtually any use, but beware the “hidden
patent license”
– Tempting to reject certain licenses, but almost every license can be approved under
certain conditions (except maybe CCA-NonCommercial licenses)

24. © 2019 Synopsys, Inc. 24
Third party software policy mechanics
• Who initiates review?
– Developer
– Tech lead
– Automatic (via integrated tool)
• Who is on the review committee?
– Representatives from all areas of company
– Legal, Business, Development, SecOps
• Who reviews first?
– Obtain technical “pre-review?”
• How to kick off review?
– Use the tools the developers already use
– Jira, Slack, Black Duck, email
– Use easy-to-follow forms for initial information
• Where are records kept?
– Use the tools the developers already use
– Make sure to provide access of prior decisions to developers to avoid duplicate requests

25. © 2019 Synopsys, Inc. 25
Third party software approval sample flowchart
START

26. © 2019 Synopsys, Inc. 26
How do you contribute
to the open source community?

27. © 2019 Synopsys, Inc. 27
Contributing to the open source community
• Define goals for contributing to existing projects
– Publicity (reputation, goodwill, visibility)
– “Good citizen” – believe in giving back to the community
– Make it easier to maintain your code (contribute back patches / bug fixes)
• Define goals for running your own projects
– Recruiting tool
– Develop relationships with open source developers
– Attract talent
– Crowdsource development
– Non-core ideas implemented for “free”
– Reduce development costs and time
– Drive adoption of platform/ecosystem
– Create a new line of business (support, apps/plug-ins)
• Recognize risks
– Competitors / competitive issues
– Loss of control over contributed code (forking)
– Contributor license agreements (CLAs)
– Material changes
– Unintended patent licenses
– Overshare (accidental/malicious contribution of trade secrets)
– Cost and resources to support open source contributions
– Contributing to “ghost towns” (orphaned projects)

28. © 2019 Synopsys, Inc. 28
Contributor license agreement (CLA)
• Typically based on the Apache Software Foundation
form agreements
– Two forms: individual and corporate
• Usually slightly modified, but sometimes materially
• Really broad license grants
– Copyright
– Covers the contribution and derivative works,
sublicensable, perpetual
– Granted to anyone who receives software from the
Foundation that includes the contribution (not just the Work
to which it was submitted)
– Patent
– Covers the contribution and the combination of the
contribution and the Work to which it was submitted,
irrevocable
– No temporal restriction
– Does contain defensive termination clause
• Contributor has no control over direction of project

29. © 2019 Synopsys, Inc. 29
Contributing to open source projects considerations
• Considerations for companies of
all sizes:
– Beware the corporate CLA
– Individual submissions versus
corporate submissions
– Beware the rogue CLA
– Not all CLAs are created equal
– License vs. transfer of ownership
– Know your competitors
– Decide whether to contribute to their
projects
– Impact of GDPR
• Smaller companies focus items:
– Protect the “crown jewels”
– Think about future investors / acquirers and what they
would want
– Beware of project scope creep
– Keep in mind potential future markets
– Revise policies to match company’s growth
• Larger companies focus items:
– Review all code prior to submission
– Policy should match employment agreements
– Even code written outside business hours / not
using Company resources?
– Consider sponsorship without code submission

30. © 2019 Synopsys, Inc. 30
Some takeaways
• It’s not as hard as it looks, but need to start somewhere
• Performing a code scan is an easy way to get started and allows a baseline
– Always finds previously unknown components
• It’s hard to undo the impact of poor practices
• You don’t have to do everything we discussed
• Start small, scale up as needed
– Get initial list of third party components, licenses, usage

31. © 2019 Synopsys, Inc. 31
Q&A

32. Thank You
This material is provided for your convenience and does not constitute legal advice or create an attorney-client relationship. Prior results do not guarantee similar outcomes. Attorney Advertising