Briefing papers

Open source

10 Steps to a Good Software Audit

By Amanda Brock
Originally published on Black Duck Blog


What makes a good anything? Achieving the outcome you hoped for as a consequence of your actions. When it comes to software audits, taking the following steps will help you achieve a better than good outcome.


  1. Understand why you are undertaking the audit. Has your company been asked by a third party to perform one or are you asking for it to be undertaken on a third party? If it involves more than one party, then it may well be as a result of a potential IPO or acquisition, which can simplify the goal. If the trigger isn’t one of these potential changes to your business, then what, if any, long term goals are there? Are you managing licensing compliance or ensuring your listed company meets its obligations? Once you know what the goals are then the process should be to meet these.
  2. Time-scales. Work to the time-scales you need to. Knowing your goals will help to make the proposed timings realistic. If there’s a genuine urgency, then the resource and man-hours needed to meet this time-scale will be found. Often, if there’s no urgency, the team will be managing their audit team roles along-side a day job and setting unrealistic goals will demoralize a detailed and time consuming process.
  3. Management buy-in. Management isn’t always aware of the open source and third party code its company has in use, or why an audit is needed. Getting executive buy-in for resourcing an audit will be essential to its success.
  4. Identify the key roles in the audit team. The right team is critical to successful output. A lawyer can look at the legal issues of a license or its compatibility with another license, but will not necessarily be able to come up with a clever technical solution to a compatibility issue. To make the best judgment calls for your business and its compliance, the team should include a lawyer who understands OSS licensing, a commercial person who understands the products you distribute, and at least one technical person. If your business has multiple technical units you may wish to include a number of additional technical representatives.
  5. Choose the right scanning and audit tool. To properly identify the open source and third party code in your code base, you will need to run a technical tool against your repository(ies). Choosing the right tool for your audit is important. This choice should be made easier by understanding your goals and time-scales. It will then come down to a combination of what tools and associated services are available to meet your needs and price-range. Of course there are free tools available, but these may not come with the warranties you need, and may require a certain level of skill for their use. Professional audit providers offer a number of different tools, service options, and varying outputs that should be assessed against your goals.
  6. Ownership of the review. Think about who should own the output of your code audit. The audit results spreadsheet will be a potentially discoverable document. How will your lawyers be involved in the commissioning of the audit and would it be more appropriate for a law firm to own and manage the output? Establish this before you contract with an audit tool provider.
  7. Obtain the necessary technical and legal information from your business. To fully understand the output of the audit tool you may wish to add appropriate information to it to allow you to make decisions. What code is open source; which licenses apply to it; do you know what obligations the licenses bring and do you meet them; what license combinations may be problematic; is the code used internally or distributed? Your internal team may well need to add some of this information to the output of an audit tool, to give enough information etc.
  8. Create a policy. Use the output from the audit process to help make an internal open source policy (if you do not already have one). This may differ within different business units and will only be successful if key stakeholders buy into it.
  9. Warranties, disclosure letters etc. If part of your audit’s goal involves third parties (investors, etc.) you may be asked to sign legal statements around your use of open source software and the audit itself. Ensure that any warranties are tailored to the work you have undertaken and any disclosure is accurate and realistic. Beware of over committing.
  10. Establish an ongoing compliance and governance process. Use the learning from your audit to create appropriate processes for your ongoing use of open source and license compliance in your business. Train people around open source and enforce these new policies and processes.