CMS Security Handbook: The Comprehensive Guide for WordPress®, Joomla!®, Drupal™, and Plone®

Documenting Your Patches

In the early days of the author's career, the PC “standard wars” were in full swing, and everyone was trying to make it to the top. His employer at the time had several wings of a massive industrial complex filled with mainframes and minicomputers. In the course of his job, whatever tasks he performed on the equipment in that environment were written down in a notebook. This notebook would stay with the equipment for others who came after him to know what he did.

In the same way, you should find a way for documenting your patches. You should make a complete list of what you did in some form. The following are items you should capture:

• Date and time — Always record the date and time the patch was deployed.
• What patch version was applied? — This may be a number, a notation, or other means to identify it.
• What vulnerability or issue does this fix? — This may be something along the lines of a SQL injection, XSS scripting error, or other non–security-related problems.
• Who applied the patch? — This is the developer, technician, company, and so on. You want to be able to reach out to the person responsible for its implementation.
• What software or hardware system did you patch? — This could be your CMS, a third-party add-on, a switch or router, and so on.
• Where was the patch obtained from? — This should include the source of the patch or the developer.
• Any observations — Did anything happen, such as errors or configuration changes?
• Was a backup conducted post ...