January 2020 Summaries

The WordPress default configuration allows administrators to install plugins and edit PHP files, posing a significant risk of malicious code execution on the underlying web server. To mitigate this, site owners can enable security hardening mechanisms, such as disabling file editing and plugin installation from within the admin dashboard. Even with these measures in place, an attacker could exploit vulnerabilities like Cross-Site Scripting to gain privileges and install backdoors by manipulating media file uploads or leveraging Local File Inclusion (LFI) vulnerabilities in themes. A vulnerability discovered in WordPress prior to version 5.2.4 allowed attackers to execute code on the web server using simple Cross-Site Scripting flaws, highlighting the importance of keeping WordPress installations up-to-date and utilizing security hardening mechanisms like those described in the official WordPress hardening guide.

Legacy code often presents overwhelming issues such as code smells, bugs, and low test coverage, leading developers to feel compelled to address these problems immediately. However, the text advocates for focusing on maintaining high standards in new code rather than delving into old code, as fixing technical debt can risk functional regression and often lacks the necessary resources. Developers are encouraged to take personal responsibility for the quality of new code, ensuring that it remains clean and error-free, while managers should prioritize addressing old code issues based on business needs. Tools like SonarQube provide automated solutions for monitoring code quality, assigning issues, and emphasizing the importance of clean new code, allowing gradual improvement as developers touch old code for new changes. The overarching message is to prioritize clean new code and let the natural course of business slowly address legacy issues, improving code quality over time.

Bit rot is a phenomenon where software decays over time due to changes in dependencies and tooling required to build, test, and deploy it. This can happen even if the code hasn't been touched for years, leading to unexpected breaks in functionality. Bit rot occurs because software is built on top of hundreds of different pieces from open source frameworks and libraries, which are updated and patched with varying frequency, sometimes requiring changes that break compatibility with other parts of the application stack. The longer an application has been running, the more susceptible it becomes to bit rot, as dependencies accumulate updates and potential incompatibilities. To combat bit rot, developers can take steps such as keeping dependencies up to date, using lockfiles and container images for reproducibility, minimizing excess dependency usage, writing integration and unit tests, and running tests regularly.