Software Audit Strategies - How often is good enough for a software audit?

Protecode Inc. 2015 Proprietary 1
Software Audit Strategies:
How Often is Enough?
February 25, 2015

Protecode Inc. 2015 Proprietary
Agenda
 Manageable challenges of OSS
 Software audits
– What it is
– What it is not
 One-time audit versus continuous audit
– How often?
 Typical software audit process
 Q/A
2

OSS Market Penetration
 Unstoppable growth
– 85% industry adoption (Gartner 2008)
– 98% worldwide adoption (Accenture 2010)
– 99% worldwide adoption (By 2016, Gartner)
 Adoption at various levels
– Organizational level
– Personal level
 Not a niche play
– Automotive, healthcare, financial
– Cloud, mobile, database, security
– Gaming, tools, imaging, aerospace
– Anything that includes any code!
3

Manageable Challenges of OSS
 Open Source software belongs to those who create it
– License = blanket permission to use, generally under certain
conditions
– Licenses and license terms can be confusing to the development
groups
• Copy Left, Weak Copy Left, Permissive
• Attribution, Internal use, distribution, SaaS use, modifications, binary
distribution, static versus dynamic links, DRM measures, derivatives
– Compliance Obligations
 Security Vulnerabilities
– Every software can be vulnerable
– Commercial or OSS
 Export Control Attributes
4

What is a Software Code Audit?
 It is a discovery process
 Identifies third-party components in a software portfolio
– Open source software (OSS)
– Other 3rd party software
 Highlights attributes such as
– Licensing
– Authorship and copyrights
– Security vulnerabilities
– export suitability
– Software pedigree, versions, modifications
 Reduces vulnerabilities
– Intellectual Property (IP) uncertainties, Compliance & Security
5

Value of Software Code Audits
 Reduces IP uncertainties
 Focuses licensing/legal teams on compliance
– Audits accelerate, and improve accuracy of, the discovery stage
 Helps technology organizations
– Adopt open source software profitably
• Lower effort for non-strategic components
• Shorten time-to-market
• Decrease development costs
– Improve business competitiveness
• Ensures adherence to IP policies
• Improved quality
• Eliminates cross-project IP Contamination
 Assists open source community
– Allows publication of code pedigree and communication of licenses
– Frees OSS adopters from uncertainties
6

Understanding Software Composition
 Code complexity is growing
 Good developers do not write code from scratch
– Open source usage is growing
• Benefits (variety of choice, access to source, reduced effort, lower development cost,
faster time to market)
• And challenges (IP ownership and license obligations)
 Access to code is easy
– OSS repositories, WWW, Previous life work
 Outsourcing software is common
 Detailed software BoM not available
– Required during a transaction
– Needed for internal compliance and vulnerability management
(Do We Own Our Code?)
7

Typical Issues Uncovered in an Audit
 OSS content with ambiguous / no licenses
– Software copyrights but no licenses
– Software with authors but no copyrights/ licenses
– Software with no pedigree information
– Public domain software with proprietary licenses
 Licenses   business model mismatch
– i.e. modified restrictive copyleft licensed content in
closed source commercial software
– Cloud deployments and newer license models
– Warranties and support models
– Attribution obligations
 OSS packages with reported vulnerabilities
– Examples: Heartbleed, Shellschock/Bashdoor
8

How Often is Good Enough?
 Companies taking stock of the portfolio
– When triggered by a transaction (M&A, shipping product, Technology
Transfer, investment)
– Regular time Intervals (daily, weekly, monthly, quarterly)
– When code is acquired (from contractors, suppliers)
 Effort increases as time elapses
– Volume of code increases
– Code gets dispersed in the product lines
– Developers move around…
– When information is fresh
• Audits take less effort
• Unknowns are resolved quickly
• Remedies are less costly
9

Waiting for the “Trigger”
 Unchecked, vulnerabilities scale with time and volume of software
 Audits at transaction time take effort and fixing problems can be
costly
10

Regular Time Intervals
11
 Audits at regular intervals, or as new code is acquired, can detect
licensing and security vulnerabilities quickly
 Reduces effort and remedial costs, and avoids propagation of
“bad” code

Anatomy of an Audit
1. Audit Questionnaire and discussion
– Who is the sponsor?
– Purpose of Audit
• M&A? Tech transfer? A collaborative work?
• Product delivery? Ongoing quality process?
– Company information
• What business? R&D practices
• Contracting, outsourcing practices
• Third party including OSS usage practices
• Is there an open source adoption policy?
• Composition and complexity of the code portfolio,
– Structure, Languages, archives, Size- Mbytes or Files
12

Audit Steps: Software Scanning
– Access to software, and scan set-up
• Look for specific copyrights, authors, company names
• Look for specific terms such as “modified” “copied from” “stolen from”
– Scans software files
• Software files (Source code, Binaries, archives)
• Information files (README, COPYING, LICENSE, etc)
– Automated Scan
a. Local scrubbing of software files
b. Similarity with public-domain OSS
– Raw machine results
• OSS projects, packages, versions, licenses, copyrights, vulnerabilities,
encryption content, etc
• Modified/unmodified software
• Proprietary, unknowns, conflicting licenses, etc
– Fast: ~ 4k files (100 – 200 Mbytes)/hour
13

Audit Steps: Resolution and signoff
5. Manual Analysis and approval
– Review every package, every file and all attributes reported by
Automated analyzer
• Resolve unknowns (eg proprietary software with no headers)
• Flag inconsistencies (eg file license  package license)
• Add missing information
• Highlight areas requiring attention (eg copyright, but no license info)
– May need consultation with the R&D team
– Longest part of the process ~ days
– Prepare the final Executive Report
14

Audit Steps: Reports & Q/A
 High level executive report
– High level view of the findings
– Highlight key findings, areas requiring attention
– Reference material on licenses found, best practices
 Machine reports
– Overview
– Detailed file-by-file
– License incompatibilities
– License obligations report
– Security vulnerabilities
– Encryption Package Report (including ECCN)
– Text of all licenses applicable to software packages
 Post-report consultation & Q/A
15

Compliance and Vulnerability Management
as a Quality Development Process
16
License and Vulnerabilities Management is most
effective when applied early in development life
cycle

Crowdsourcing “Compliance”
17
# of issues created
Issues are
created here…
…and resolved here
Developers
Effort
Licensing
Team

Crowdsourcing “Compliance”
18
# of issues created
Issues are
created here…
…and resolved here
Developers
Licensing
Team
Effort

OSSAP
Open Source Software Adoption Process
19
Define a
Policy
Establish a
Baseline
Package
Pre-Approval
Scan in
Real-Time
Scan at
Regular
Intervals
Final Build
Analysis

About Protecode
 Open source compliance and security vulnerability management
solutions
– Reduce IP uncertainties, manage security vulnerabilities and ensure compliance
 Accurate, usable and reliable products and services for organizations
worldwide
20

Pitfalls of IP Uncertainties
 Negatively impacts M&A activities
 Lowers company valuations
 Delays product shipments
 Deters downstream users
 Reduces ability to create partnerships
 Introduces delays and threatens closures in financings
 Creates litigation risks to the company and clients
22

Partial Matches (modified OSS code)

Analyzer Raw Output
24

Software Audit Strategies - How often is good enough for a software audit?

More Related Content

What's hot (20)

Viewers also liked (11)

Similar to Software Audit Strategies - How often is good enough for a software audit? (20)

Recently uploaded (20)

Software Audit Strategies - How often is good enough for a software audit?