Paragon Initiative Enterprises (P.I.E.) got its name on March 14, 2015. How have things changed in three years?

Why P.I.E.?

We started our company in part because we were frustrated by the schism between information security experts and PHP developers.

At the time, there was a prevalence of bad practices in both camps that could only be remedied by working with the other side. Information security experts who specialized in secure development were a rare breed, but even fewer wanted to work with PHP.

As a consequence of the security industry's decades of blatant negligence towards the programming language that powers 80% (now 83%) of the websites on the Internet, and many PHP project's hostility towards security vulnerability disclosure, conditions were not so great in 2015:

• Secure code delivery flew under almost every PHP developer's radar; rather, the curl | sh anti-pattern was widespread and increasingly popular.
• Many PHP frameworks were using insecure cryptography to guard unserialize() calls, which means a clever attacker could get remote code execution with a little effort.
• Mcrypt was widely (ab)used by the PHP community.
• Unauthenticated encryption was everywhere, leaving most software vulnerable to chosen-ciphertext attacks.
• Almost nobody was generating random numbers securely.
• If you typed php [anything security-related] into Google, you were presented with questionable Stack Overflow answers and ancient blog posts that peddled bad security advice (i.e. using mysql_real_escape_string() to try to prevent SQL injection).

We wanted to change all of that.

We formed Paragon Initiative Enterprises to bridge the gulf between software developers and information security analysts. We wanted to ensure the tools and libraries that developers use are secure by default. We wanted to make security best practices accessible to developers the whole world over.

We wanted application security to be easy as pie.

What Happened Next

Our efforts were better received than we could ever have anticipated. Since our inception, we have been directly involved in each of the following:

• PHP 7.0 shipped with a CSPRNG that doesn't fail open or scare developers.
• PHP 7.1 marked ext/mcrypt as deprecated, and it was removed in 7.2.
• PHP 7.2 added ext/sodium to its standard library.
  • One subtle win from its inclusion, even for OpenSSL users, was sodium_memzero().
• Most open source projects that haven't switched to libsodium are using authenticated encryption.
  • For example, via defuse/php-encryption.
• Our random_compat library, which polyfills the PHP 7.0 CSPRNG for PHP 5 projects, has been downloaded with Composer over 50 million times and adopted by WordPress since version 4.4.
  • Conservatively, we can estimate a deployment in the scale of "hundreds of millions of websites".
• Our sodium_compat library has been built into Joomla, and there is an ongoing discussion to get it into the next version of Magento.
• If you type in php [anything security-related] into Google, you're very likely to find good security advice rather than dangerous example code.
• We've published over 20 open source projects that aim to improve the security of PHP products. Some of these open source libraries solve uncommon problems that have far-reaching security boons.
  • Certainty enables entire plugin/extension ecosystems to always have an up-to-date CACert.pem bundle, which means there's no excuse for anyone to disable certificate validation if Certainty is used.
  • GPG-Mailer allows sensitive information to safely be transported over email to power users (i.e. the developers) without fear of interception in transit, even if your mail provider is compromised.
• We've published over 70 blog posts, mostly technical and educational in nature.
  • If Google Analytics is to be believed, many of our blog posts are directly recommended by college programming courses, thereby putting secure development advice in the hands of junior developers.
• We're close to replacing a standardized error-prone cryptographic design with a much more secure alternative, which we call PASETO, and is currently implemented in 7 programming languages by various authors.

This is in addition to directly helping numerous companies shore up the security of their infrastructure. Due to the sensitive nature of computer security work, most of the work we do goes unpublished, but one of our past clients recently told us, "[Your company is] always on point, always great to work with, and always set our minds at ease."

On top of that, we've dedicated a lot of time to researching and reporting security vulnerabilities in open source projects written in various programming languages.

Suffice to say, we've been busy.

Lessons to Learn

At some point in the distant past (possibly during the era of the Revenge of the Nerds franchise), the idea of the antisocial genius began to gain steam. Today in many technology companies around the world, there exists a toxic culture predicated on a few premises we adamantly disagree with.

• Being good at talking to computers and terrible at talking with people is not a virtue. The past three years has demonstrated that a lot of hard problems can be solved with determination and ingenuity, but those solutions will only reach people if you can convince them that they should care about the problem in the first place.
• Nobody is self-made. People who think they succeeded entirely on their own are simply unaware (at best) or unappreciative (at worst) of the people who helped them achieve their goals.

None of the items listed in the previous section that really moved the needle towards improved software security would not have been possible if our company existed in a vacuum.

None of our efforts would have been possible if not for many company leaders swallowing their pride and deciding, "I'm not a security expert and these problems are currently beyond my understanding, we should ask Paragon for help."

None of the initiatives we launched would have been as widely adopted if the project leaders of various open source projects didn't care enough about the problems we were trying to solve to allocate their own time and personnel to make the solutions happen.

None of those initiatives would be anywhere near as excellent as they are today if it wasn't for other developers taking the time to report bugs, suggest improvements to the code and documentation, and write patches with proposed solutions.

At the end of the day, we stand committed to working with people to make everyone's lives and data a little bit safer and a lot more private. People are what matter, first and foremost. We hope to one day inspire others to decide the same.