best practices for simplifying software audits

1Protecode Inc. 2015

Best Practices for Simplifying Software Audits

Wednesday, June 24th, 2015

Protecode Inc. 2015 2

Agenda

Software audits– What, why, who and how

How to prepare for an audit

Documentation you need– Per file, folder, project, organization

Audit reports

Resolving background & foreground IP

Policies and internal education

Wrap up and Q & A

Tiberius Forrester,Director of Solutions

[email protected]


Software Audits

Complex projects use a mix of in house and third party code– Wide adoption of open source software– Code contributions across organizational boundaries– Popularity of outsourcing software– Ease of access to code (OSS repositories, WWW, Previous life work)

It is our software.Do we know what we have?

Why

Reduces uncertainties and vulnerabilities– IP Ownership and compliance with code obligations– Identifies known security exposures

Helps technology organizations– Adopt open source software profitably– Reduce effort and shorten timelines

Value


What Does a Software Audit Do?

A software audit is a discovery process

Identifies all components in a software portfolio– Own software– Open source software (OSS)– Other 3rd party software

Identifies code attributes – Licensing, authorship and copyrights– Security vulnerabilities, encryption content– Software pedigree, versions, modifications

Highlights legal obligations and reduces vulnerabilities– Licensing, known security vulnerabilities, exportability

Creates a software Bill of Materials (BOM) – Software inventory


Internal audit team– Combination of legal and software expertise

• Often an overworked and underpaid team (of 1)

– Manual audit• Rely on records, examination of files and packages

– Or automated scanning for improved speed and accuracy• Acquired or implemented in house

External audit team– Arms-length software audit organizations

• Typically used for financial transactions

– Uses automated code scanning and discovery solutions– Delivers high level executive reports as well as signed-off machine generated

reports

Who performs the audit?


Preparing for the Audit

Access to all code

Knowledge of business model

Understanding of the development environment– Tools, repositories, libraries

List of known 3rd party components– Open source, commercial (and their licenses)

Access to a list of developers– Within or outside organization

Current and previous company copyright formats– Eg ACME Inc, copyright © ACEME Inc,

List of company acquisitions

– And their copyright formats

Internal or External Audit


Preparing for an external audit

Have a single point of contact

Sign Non-Disclosure Agreement (NDA)– 2 way, 3 way, 4 way or more!

Explain the purpose of audit– M&A / tech transfer / collaboration / product delivery? – Who is the sponsor (recipient of the audit report)

Provide company overview– What business? R&D practices– Contracting, outsourcing practices

Describe software characteristics– Is there an open source adoption policy?– Composition and complexity of the code portfolio,

• Structure, Languages, archives, Size- Mbytes or Files

Have an audit agreement (SOW) in place– Duration, cost, confidentiality


Auditable Code Organization

Flat structure– AVOID

Hierarchical– Software manifest

Systematic top-down structure Breakdown portfolio into

Products and product components (eg: modules per software architecture) Third party components and open source software Libraries

Identify Portfolios shared between different products

Divide and Conquer!– Audit one reasonable-sized block at a time


Desired Folder Structure for Audits

Applicable sequence of information1. File-level licenses and notes2. Folder-level licenses and notes3. Project-level licenses and notes


File Level Information

Source file headers– Invaluable source of information

Do not remove existing headers If there is something to add, then add to existing header

– Open Source Software Retain existing header

– Proprietary software, Use a list of standard headers Include copyright, date, author name, abstract Set up machine-generated code headers

Binary files– OSS: you are stuck with what you get Proprietary: include copyright in the binary

Protecode Inc. 2015

0.0%

10.0%

20.0%

30.0%

40.0%

50.0%

Percentage of Proprietary CodeMissing Header Information

Small Portfolio Medium Portfolio Large Portfolio

Missing Headers


OSS Header

Information added

Don’t remove this!


Proprietary Headers

Copyright (agree on a single format within your organization)

Include author, date, summary, project

Machine-readable header info (eg: xml) is preferred


Folder Level Information

Include text files containing– Folder description– License(s)– Copyrights– For open source software

• url pointing to download site• date it was acquired

Watch for open source licenses– License evolution– Dual licensed (commercial and GPL) options– Multi-license projects– Composite projects


Factors Impacting License Obligations

Distributed versus hosted software

Modified versus unmodified third party software– Must be declared– May impact obligations

Embedded code versus bundled software

Binary-linked software

Dependencies


Dependencies

Typically a product software depends on other code (eg: libraries)

Dependencies are resolved at build time

A complete software audit requires– Manual interpretation of dependencies (eg: make

files) PAINFUL!– Or access to the complete code post build-time

Package managers can simplify auditing dependencies

Protecode Inc. 2015

Package Managers

Handle software libraries and dependencies.

– NuGet (.NET) – Packagist / Composer (PHP), – NPM (Node.JS), – RubyGems / Bundler (Ruby)– Bower (JS, CSS, HTML)– Maven (Java)– And others …

Store a list of all packages and dependencies within a file in the root folder.

Create and label 3rd party folders for easy navigation and links to source url and license

Simplify auditing process


Attribution Obligation

Common obligation between OSS licenses

Is there a per file reference? Where is the actual text of license?

• Per file• Per package, or folder

Is there one text file containing concatenated list of all licenses?

Copyleft (eg: GPL V2) Where can the public find the source

code of the whole project?


Background VS. Foreground IP

Needed for collaborative development– Commercial <> commercial– Academic <> commercial

Before start of collaboration– Audit best practices (documentation, code structure, headers,

dates) are in place– Each organization has completed an audit of their code

• Automated audits create accurate code inventories with traceable code signatures

– Dated backups of complete portfolios are available• Resolving post-development issues

During collaboration– Audit best practices are in place– Regular (automated) audits and inventory lists are maintained


How Often Should You Audit?

Don’t leave it to the last minute.


Software Audits and OSS Adoption Have a policy in place

– What is acceptable? • 3rd party software, sources, licenses, copyright per project, per

portfolio

– What documents to maintain and where– What to do and who to go to?

Communicate the policy

Pre-approval process

Use automated tools to build a software inventory and ensure compliance.


Summary

Educate – Let the software team know what is auditable

Structure the code– Software structure or code manifest

File headers contain essential Information– Keep 3rd party (and OSS) headers, company headers on proprietary files– File info trumps folder Info trumps package info

Document– Structures, licenses, contracts, OSS sources

Audit early, Audit often

Manual Audits are painful– Various automatic scanning and discovery applications in the market


Q&A

Please type your questions into the chat box to the right


[email protected]

best practices for simplifying software audits

Software

party software

software portfolio

software expertise

software characteristics

audit access

simplifying software

agenda software audits

manual audit