Ask A Security Pro: Secure Website Life Cycle For WordPress Admins

Some of the most significant reasons that WordPress has seen such widespread adoption is because it’s free, because of its modularity where features could be simply plugged-into the website with a few clicks, and because of its ease-of-use in that non-developers can easily develop websites. On the other hand, free software means you’re going to be performing a lot of your own support. Modular features mean you’re potentially introducing code that may not have been properly audited. And eliminating the developer means you’re now the one responsible for the integrity of the project. That means you’re supplementing the role of the developer to the best of your abilities and if you want your website to remain a safe place you need to become familiar with how a Secure Development Life Cycle (SDLC) works, in what I’ve termed the Secure Website Life Cycle (SWLC) for WordPress Administrators.

I’ve written a little bit on SDLC in the Ask a Security Professional Series earlier this year and delivered a few presentations on using a SDLC at various WordCamps, but for those of you who haven’t had a chance to attend one of my WordCamp talks on SDLC, I’ll fill you in on the process.

Code starts simple. To paraphrase our Director of Product & Technology, Binod Purushothaman, development projects are a lot like children; they start simple but over time they evolve to introduce new complexities and often unforeseen challenges. In WordPress we start with a (relatively) simple canvas, that is, the core infrastructure that you initially downloaded from WordPress.org. Then you have this idea for how you want to implement new features.

As WordPress users we tend to add new things like parent themes, child themes, plugins, more custom CSS, rockets, and racing stripes. Perhaps not the last two, but you get where I’m going with this. We add features, the project grows in complexity, we build the circumstances where we may encounter those unforeseen challenges.

For most WordPress users, the majority of the development life cycle occurs out of sight, and likely out of mind. The initial code writing is performed by the plugin or theme author, tested for bugs in functionality, bugs are addressed, then the code is made available to the WordPress community through the plugin distro. The WordPress website owner is left to perform only the final, and most dangerous, task in the development life cycle — Publishing. This is important because up to this point, the parts of the application have been theoretical, existing only in the minds of the pieces’ original authors. You’re the one who took these pieces, put them together, and gave them life on the open internet as one website. You’re Dr. Frankenstein in this equation, and you’re responsible for the behavior your creation, with all the liability that comes with it.

The problem is not only that as website administrators we are completely removed from the majority of the development process, as is the case for most WordPress site owners, but that this model is entirely flawed in the first place. When a plugin or theme developer is writing and testing their code, they may not necessarily have evaluated the code for security vulnerabilities. You have to keep in mind that in most professional enterprise environments, the original code developer is rarely the same person performing security evaluations, their skillset will more often lie in creating innovative features to share with the world. There are most certainly niches in development.

Remember that we’re still responsible for our project, the WordPress website we’re serving to the public, and therefore the code contained within. To ensure that we’re presenting only safe content and protecting our visitors, it is critical that we are able to secure the project, every line of it. In contrast to the flow above, a secure development life cycle as it applies to the WordPress administrator should look more along these lines.

In this model, we’ve introduced a code review for vulnerabilities and penetration testing. While there may still be areas that we’ll need a developer to assist with the remediation of vulnerabilities we may find in the code (e.g. items in the yellow box), we’re ensuring that the website we’re serving to our visitors is safe to visit and any stored data has been properly secured before making the application public. Testing of this kind is referred to as white box testing, which I’ve detailed in a previous article. SiteLock provides vulnerability assessments and penetration testing for environments of exactly this type through the use of the SiteLock® TrueCode™ Static Application Security Testing (SAST) system. Implement your Secure Website Life Cycle today, use TrueCode.