Software audit strategies: how often is enough?

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. NDA in place

– May be 2 way, 3 way, 4 way or more!

2. 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

3. Audit Agreement (SOW)

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

Eff

ort


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


Audit Questionnaire

25


Audit Report

26


Software Bill of Materials

27


License Obligations Report

28


Security Vulnerability Report

29


License Text

30