In general, a software audit is a process in which a company’s software is reviewed to gather information about its use, proliferation, or quality. A company might have many reasons for conducting such an audit, such as certifying compliance with licensing restrictions to documenting open source modules present in its source code to even preparing for litigation.
There are many factors to consider when determining whether a software audit would be valuable in a given case and how such an audit should be conducted.
Below, we outline a few of the considerations that, in our experience, are frequent factors to consider. This listing is neither exhaustive nor exclusive, but rather a general overview of factors for counsel and software experts to consider when contemplating a software audit.
1 – Purpose Considerations
The first question typically asked in performing a software audit is regarding its necessity.The purpose of the audit obviously drives the scope of work. For example, if the audit intends to demonstrate that certain annual license restrictions for third-party software are being met, the work may involve investigating all systems on which such software may be installed.
If the audit is in preparation for litigation, the scope of work will likely be driven by the facts of the litigation. For example, if the litigation is copyright-related, the audit may need to investigate what protectable elements of the source code should be included in a copyright registration, who created the work to be registered, and when the work was completed. If the litigation is trade secret-related, the audit may need to investigate what claimed trade secrets exist in the source code.
It is often helpful to have in mind a purpose that is intended to be served before actually starting the software audit so that the expert performing the audit can sharpen the focus of the investigation, and limit their analysis to only material relevant to the questions being asked.
2 – Logistical and Scope of Work Considerations
When preparing for a software audit, one important consideration is how the audit will be conducted. Specifically, will the expert be provided with a copy of the source code to be audited or will the work need to be done on-site at a secured location? While on-site work may be more secure, it is typically more expensive to conduct. Thus, confidentiality and security concerns typically need to be balanced against the needs of the audit.
These considerations may become more complex if the audit is related to potential or ongoing litigation, as an audit may be requested by an opposing party’s expert as well. When litigation is involved, the parties will generally need to reach some agreement on the parameters of the audit and how the work will be conducted.
Once a general approach for the audit is established, the parameters of the work to be conducted will typically need to be fleshed out. Typically, understanding the work to be conducted requires certain basic information, including:
- Where is the code stored?
- Are there multiple versions of source code that need to be audited?
- How many lines of source code compose each version of source code?
- Are Subject Matter Experts (“SME”s) available to support the software audit if necessary?
These are only some of the logistical considerations that may need to be considered when conducting such an audit. Such considerations typically vary from audit to audit, but typically impact the overall cost and effort required to complete a software audit.
3 – Overview of Software Audit Process
The software audit process generally consists of three major components:
- gathering, inventorying, and initial assessment;
- review and analysis; and
- reporting the findings.
(a) Gathering, inventorying, and initial assessment
Regardless of the manner in which the material is made available, it is almost always useful to perform an initial inventory of the production. This work helps ensure that the relevant data is present and available for analysis. Typically, an expert will want to determine:
- Was all relevant data produced?
- Does the data produced appear to be complete?
- Does the volume of material align with expectations?
- What is the high-level structure of the data and how is it organized?
In an initial assessment and inventory of source code, for example, it may be the case that the estimated volume of code discussed at the outset is substantially larger or smaller than the code that is actually made available. Such a discrepancy could have an impact on the overall effort required to audit the code and provide answers.
Once the relevant material is in hand, one first step that is often useful is to index the production. An index of the produced material can be used to conduct targeted keyword searches and to quickly focus on areas of interest within the produced code.
These efforts typically should be used to ensure that the production is actually complete for the purposes of the audit. Incomplete data may yield incorrect or inaccurate results, and possibly require re-work or additional review if or when the correct or complete production is later made available.
(b) Review and Analysis
Once it is clear that the relevant material is in hand, the substantive analysis work of the audit can begin. This work typically includes both a combination of programmatic and manual review efforts.
Programmatic tools can often reduce the volume of code or material to be considered in a software audit. In determining what kind of programmatic tools might be useful various questions are worth considering, including:
- Are software tools necessary to answer the questions at issue for this software audit?
- If so, what tools are most appropriate to aid the expert in answering the questions at issue for a given software audit?
- What are the relevant keywords to search for in identifying which files are critical to answer the questions at issue for the software audit?
- Which areas of source code or evidence appear to be most relevant to answering the questions at issue for the software audit?
For example, in software copyright infringement matters where the objective is often to search for and evaluate similarities within the source code, tools like Beyond Compare, dtSearch, and Understand can help an expert quickly identify potential similarities and earmark them for further manual review and analysis, or potentially find and identify third-party or open-source code within the source code production.
In other matters, where the purpose of the source code audit is to gain factual insights into the development or copying of the source code itself on a given developer’s computer, forensic software tools, such as EnCase, FTK Imager, or X-Ways forensic software may be employed to aid in determining when specific code files were created, deleted, or potentially transferred to an online file share or external USB flash drive. Forensic examinations can also reveal if potential tracks-covering software was installed or run at any point in time, or if the hard drive for the system reviewed has been recently formatted.
Once programmatic analysis has been conducted, an expert may also conduct manual review of the data as well. Such manual review can be used to validate results from the programmatic analysis and to ensure that the reported results are relevant for the purposes of the audit.
(c) Reporting
The final stage of an audit typically involves reporting findings. Depending on the case, findings from the analysis may be reported in various forms, such as an informal phone or video call, an informal summary report, a formal report, or even expert reports, affidavits, and declarations to support court motions. Important questions should be considered in deciding the form of the final reporting:
- Is the software audit part of a litigation proceeding, and is a formal report necessary?
- What findings and opinions are necessary or relevant to report?
- What level of detail is appropriate for the report?
- Does the report appropriately address and attempt to answer the questions at issue for the software audit?
- Are there any important constraints or limitations to the analysis to disclose?
The level of formality required of the situation will impact the overall effort required to complete the software audit report. The level of effort for an informal phone call is much lower than a formal report with precise and detailed findings, particularly like those used in expert reports, affidavits, and declarations.
At DisputeSoft, our software experts frequently undertake software audits for various purposes to serve clients in many different industries, with different needs. Occasionally, our experts are called upon to serve as neutral software audit experts jointly by both parties involved in litigation.
DisputeSoft’s software experts are knowledgeable and experienced with the various tools available to assist in these types of analyses and reach findings in which they are confident.
