It might never occur to most business owners or software developers to hire a security team to audit their software's source code, but if you're producing or consume a lot of boutique software, the benefits of a code audit are hard to pass up.

Code Auditing in a Nutshell

Code audits are a service, typically provided by information security experts with a background in software engineering and/or cryptography, wherein the auditor obtains a snapshot of your source code and attempts to find exploitable vulnerabilities.

What That Means in More Detail

If your work touches eCommerce at all, you may have encountered penetration tests in order to attain PCI-DSS compliance. A code audit is like a penetration test for your software's source code.

If you can't think of any software projects off the top of your head that have undergone (let alone passed) an audit, don't feel like you're alone. There are surprisingly few information security experts who are also expert programmers. For example, when digital forensics and incident response expert Lesley Carhart was soliciting testimonials for an career advice blog post for people interested in various infosec specialties, almost nobody answered her questions for secure development.

As a consequence, code auditors tend to focus on two keys areas:

1. Paid client work, which is rarely made public
2. High profile encryption/privacy apps, which is almost exclusively made public

What's the Risk of Unaudited Code?

That depends, mostly, on who developed the software and for what purpose.

If you're a software company, unaudited software carries a higher risk of security vulnerabilities, which in turn means higher liability to your customers. For a recent example of the financial impact of a security breach, look at the Yahoo hacks' impact on their Verizon sale.

If you're an independent software developer, code audits can prevent you from losing your weekend trying to piece together clues, understand, and then fix a security issue issue with one of your projects being exploited in the wild.

Are Code Audits Like Bug Bounties?

Sometimes people hear "code audit" and might think of bug bounty programs, but they're worlds apart in terms of both quality and focus:

• A bug bounty program invites thousands of people of varying skill sets to look at your code or systems and report any bugs they find for money through a platform like HackerOne or BugCrowd.
• A code audit invites a dedicated team of experts to thoroughly study your software (both at a code level and an architecture level).

We ourselves run a bug bounty program that covers our open source software. Bug bounties are great if you want diverse input (which is a good thing; more peer review means less bugs get overlooked), but their signal-to-noise ratio can be very low.

Code audits do not suffer from a low signal-to-noise ratio. For an extreme example, contrast these bug bounty reports with one of the code audit reports we've published (PDF).

Why Do Software Companies Need Code Audits?

There are countless reasons that a software company might want a code audit, but the most common reason (outside compliance requirements) is to obtain independent third-party analysis of their software security.

Anyone can say, "We take security very seriously," but a code audit demonstrates a commitment towards excellence. If the auditor is trusted within the technology community, both for their efficacy in finding software vulnerabilities and for their personal integrity in reporting them honestly, then their impartial analysis of the security of your product will build confidence in your company's dedication to security.

Code audits are especially important if you are developing software that handles sensitive information (financial records, patient medical data, cryptography key material for business needs, etc.).

What Happens If We Fail an Audit?

This question is rarely asked of us directly, but it seems to be on most people's minds as they express gratitude when we address it.

If your software "fails" an audit, that means that the auditor was able to identify a serious vulnerability in your software's design or implementation. What happens next does depend on which company is performing the audit, but generally, a preliminary report will be issued that addresses every issue they were able to identify.

Here at Paragon Initiative Enterprises, we prefer to send patches (or pull requests) along with our preliminary reports to demonstrate how we would solve the problem.

Once the vulnerabilities are fixed, your auditor will send a superseding report that explicitly states that the vulnerabilities they found are no longer present in the software. Thus, even if you "fail" the audit by having vulnerabilities in the first place, the final report will clearly demonstrate a commitment to security.

The goal of an audit is not to blame or shame. Everyone makes mistakes; identifying them, fixing them, and learning from them are how we make higher quality products and services.

Can't We Just Do In-House Code Audits?

Sure, but don't expect anyone to trust the results.

One of the most important components of a code audit is that it's provided by an independent third party. Paying for a code audit is not paying for a passing score, it's paying for the time of a domain expert to pour over the code and provide an honest analysis.

An in-house audit amounts to, "Trust us, because we said so."

Internal audits are a good idea if you're trying to enforce a code review before the end of a release a cycle. For example, we do internal audits before every release of CMS Airship. But our internal audits are informal and not an assertion of trustworthiness.

Even if you believe your team to be best-in-class security experts, humans are usually blind to their own biases and mistakes. Your products and services will benefit from an honest appraisal from outside expertise.

Why You Should Hire Us to Audit Your Code

Superior Code Auditing Process

Paragon Initiative Enterprises prides itself on not merely identifying problems, but providing solutions for them.

Typically, this means that any vulnerabilities we identify will not only be identified and analyzed in our code audit report, but they will also be accompanied by a patch or pull request that offers a proposed fix for each vulnerability. We find that this follow-through and our solution-focused approach to code auditing delivers better immediate results for our clients than merely reporting vulnerabilities, and primes the development teams for better long-term security. In sum, it's a win-win.

Additionally, we don't just report positive vulnerability findings ("we found this vulnerability in this component"), but also significant negative findings ("we found that the software is resistant to attacks X, Y, and Z, which is unexpectedly good and noteworthy"). This has two benefits:

1. It lets the development team know what they were already doing that works well.
2. If a follow-up audit is performed by another team, it allows them to know which areas have been examined closely.

If the follow-up team trusts our expertise, they can focus on areas not mentioned in the report. If they do not, they can focus on disproving our analysis and searching for vulnerabilities in areas we said were safe. Which ever path they take, the end result still benefits the company that makes the software being audited.

Our Team Offers Very Rare Expertise

If you ask any security company to draw a Venn diagram of...

• People who can find vulnerabilities in software
• People who can consistently write secure software

...they would almost certainly draw two large circles with a very small overlap. Now add cryptography and the PHP programming language to the mix.

Despite PHP powering about 5 out of 6 websites on the Internet, there aren't a lot of information security or cryptography experts that specialize in PHP development.

In the past two years, our company has done all of the following:

• Advised the discussion on a better design for PHP 7's CSPRNG functions.
• Successfully pushed for the deprecation of mcrypt support in PHP 7.1, and removal in PHP 7.2.
• Successfully pushed for the adoption of libsodium in PHP 7.2.
• Wrote a pure-PHP polyfill of libsodium for legacy software support. (More information)
• Published over a dozen security-focused open source PHP libraries.
• Identified vulnerabilities in many popular PHP frameworks and libraries.
• Won a DEFCON contest for designing cryptography backdoors.
• Published over 50 security-focused blog posts on our website, which has become a primary resource for PHP developers seeking to write more secure software.
  • Additionally, if Google Analytics can be trusted, several college courses already link to our blog posts.

This is on top of the clients we've helped produce better software or respond to attacks.

Although other PHP security shops exist, you will be hard-pressed to find one as capable, diligent, or community-focused as our team.

How to Get the Ball Rolling

If you've decided to proceed hiring Paragon Initiative Enterprises to conduct a code audit for your software, let's talk. Depending on the nature of your products and exact needs, the process we follow may vary, but generally this has worked for most of our past clients:

1. We discuss the specific goals and intended scope of the audit, and whether or not it's meant to be published on our website. This also is the contract negotiation step, where NDAs are sometimes involved.
2. We share an SSH public key so we can be granted access to the source code repository for your software. This is a distinct that will not be reused across engagements, and will be securely deleted from our computers upon completion of our work.
3. We look at the code involved and provide a time and cost estimate for our audit.
4. After we've reached an agreement, we select an exact commit hash to use for our investigation.
5. We perform our audit of the code, verifying vulnerabilities on our own hardware rather than on live systems.
6. Depending the client's needs, we will either:
   • Send a .zip file containing all of the relevant patches for the vulnerabilities alongside our preliminary findings report.
   • Send pull requests or .patch files as we find issues.
7. After our preliminary report has been received, we'll help answer any questions the development team has about any vulnerabilities we've discovered.
8. After all of the vulnerabilities have been addressed, we'll look over the changes and send a superseding report that details all of the steps taken to make the software secure. If our client wants the audit to be published, this is the version that gets released.

We try to keep our process simple, yet flexible. Most clients' needs are different, and we won't try to fit you into a mold.

Looking forward to working together to make your products more defensible and trustworthy!