Open source software is not inherently less secure than proprietary software. Public code can be reviewed by anyone, and popular projects often fix vulnerabilities quickly. But a fix only protects you once it is installed. Most real-world compromises of open source systems involve known vulnerabilities that were never patched, default settings that were never changed, or plugins that were abandoned long ago. Open source security is therefore less about the software and more about the routine around it.
Why open source security needs a routine
With a subscription service, the vendor patches the platform for you. With self-hosted open source, that job falls to you or your provider. There are usually several layers to keep current:
- The operating system, typically Linux, and its packages.
- Runtimes and servers: PHP, Python, Node.js, Java, web servers and databases.
- The application: WordPress, Odoo, Moodle, Nextcloud, a CRM, or similar.
- Extensions: plugins, modules, themes and add-ons.
- Libraries bundled into custom code, often pulled in through package managers such as Composer, npm or pip.
A weakness in any layer can expose the whole system.
Step 1: Know what you run
You cannot patch what you do not know about. Keep an inventory of every system with:
- The application and its version.
- Installed extensions and their versions.
- The operating system, runtime and database versions.
- Who is responsible for updates.
- Where it is hosted and how it is backed up.
For custom software, a software bill of materials (SBOM), a machine-readable list of included components, makes it far easier to check whether a newly announced vulnerability affects you.
Step 2: Watch for vulnerabilities
Publicly disclosed vulnerabilities usually receive a CVE identifier (Common Vulnerabilities and Exposures), which makes them easier to track. Sources to monitor include:
- Security announcements and mailing lists from each project you use.
- Your Linux distribution's security advisories.
- Dependency scanning tools that compare your components against vulnerability databases. Many code hosting platforms include this as a feature.
- The admin dashboards of applications that report available updates.
Assign someone to review alerts. Notifications that nobody reads provide no protection.
Step 3: Prioritise sensibly
Not every update is urgent. Consider:
| Situation | Suggested response |
|---|---|
| Critical vulnerability in an internet-facing system, especially if being actively exploited | Patch or apply the published mitigation as soon as possible, ideally within days or sooner |
| High-severity vulnerability in a component you use | Schedule promptly, within your normal short patch window |
| Vulnerability in a feature you do not use or that is not reachable | Assess; patch in the next regular cycle |
| Routine minor and bug-fix releases | Apply in regular scheduled maintenance |
| Major version upgrades | Plan as a project with testing |
Severity scores (CVSS) are a starting point, but your own exposure matters: an internal tool behind a VPN carries different risk from a public shop.
Step 4: Patch safely
Updates occasionally break things, which is why some organisations delay them indefinitely. The answer is a safe process, not avoidance:
- Back up first, and confirm the backup is complete.
- Test on a staging copy for anything business-critical, especially major versions and sites with many extensions.
- Apply during an agreed maintenance window and inform users if downtime is expected.
- Verify afterwards: check key functions, logs and monitoring.
- Have a rollback plan if something goes wrong.
Automatic security updates for operating system packages are reasonable for many servers. Automatic major application updates are riskier; decide case by case.
Step 5: Reduce the attack surface
Fewer components mean fewer things to patch and fewer ways in:
- Remove unused plugins, themes, modules and user accounts, rather than just disabling them.
- Prefer well-maintained extensions with recent releases and a security contact.
- Change default credentials and admin paths where the application allows.
- Enforce strong passwords and two-factor authentication for administrators.
- Restrict admin interfaces by IP address or VPN where practical.
- Run services with minimal privileges, and close unneeded ports with a firewall.
- Use HTTPS everywhere.
Step 6: Plan for end of life
Every software version eventually stops receiving security fixes. Running an end-of-life version of PHP, a database, an operating system or an application means new vulnerabilities will never be patched. Track support dates for each component and plan upgrades well before they expire. End-of-life deadlines are among the most predictable risks in IT, yet they regularly catch organisations off guard.
Step 7: Prepare for the worst
Even with good practice, incidents happen. Keep offline or immutable backups that an attacker cannot easily delete, monitor logs and file changes for suspicious activity, and have a written plan covering who to contact, how to isolate a system and how to restore service.
Who should do this?
For a single small site, a disciplined in-house person can manage this routine. As the number of systems grows, the workload and the cost of mistakes rise. Many businesses hand the routine to a managed provider: server management typically covers operating system patching, monitoring and backups, while open source solutions support covers application and extension updates. Whatever the arrangement, make responsibilities explicit so nothing falls between two parties.
Key takeaways
- Most open source compromises exploit known, unpatched vulnerabilities or weak configuration.
- Keep an inventory, monitor advisories and prioritise by severity and exposure.
- Patch with backups, staging tests and rollback plans, not by delaying updates.
- Remove unused components and track end-of-life dates for every layer.