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.
Part Two: White Box Testing
In case you missed it, we spoke about Black Box testing in the last part of this series. Today, I’m going to go over Black Box testing’s counterpart, White Box testing. In terms of WordPress website security, White Box testing is the practice of testing the code running behind the scenes from the inside-out. Internal testing can be accomplished through use of various tools to seek out any vulnerabilities that may exist. White Box testing is typically executed in the form of Static Application Security Testing (SAST).