Every ERP comparison you will find ranks features, licence costs, and ecosystem size. Almost none of them ranks the thing that determines whether your supplier bank details end up for sale: the attack surface. This is that missing comparison, SAP, Odoo, and a minimal custom build, read the way a security engineer reads them.
Why is security missing from every ERP comparison?
Because ERP comparisons are written to sell ERP licences and implementation projects, security gets reduced to a certification checkbox. Yet the ERP is usually the richest single target in a mid-size company, payroll, supplier bank details, pricing, contracts, personal data, and the three options carry radically different attack surfaces.
An ERP compromise is rarely just a data breach. It is invoice fraud (change a supplier IBAN), production stoppage (lock the system logistics runs on), and a regulatory event, all in one incident. Under NIS2, many mid-size EU firms now have to show exactly how this system is patched and monitored, we mapped that work in The NIS2 Engineering Checklist: 40 Controls Mapped to Evidence. So treat attack surface as a first-class selection criterion alongside price and features, not a paragraph in the annex.
How does patch-cycle exposure differ between SAP, Odoo, and custom?
SAP publishes fixes monthly on its Security Patch Day, but enterprise change control commonly delays deployment by weeks or months. Odoo patches its supported major versions continuously, but customized instances often cannot upgrade quickly. A minimal custom build patches like any modern web app: a dependency bump in CI, deployable the same day.
The number that matters is not patch frequency, it is your realistic latency from advisory to production:
- ▸SAP: fixes arrive as monthly notes, some rated Hot News at the top of the CVSS scale. Applying them means transports through development and QA before production, and public reporting has repeatedly shown mass scanning for major SAP flaws within days of disclosure. The gap between those two clocks is your exposure window.
- ▸Odoo: security fixes land in the currently supported major versions. The structural problem is that heavily customized instances get pinned to old versions because upgrading breaks modules, we cover that trap in the Odoo upgrade tax. A pinned ERP quietly stops receiving fixes without anyone deciding it should.
- ▸Custom: there is no vendor calendar. Your patch cycle is your CI pipeline and your dependency scanner. That can mean same-day fixes, or no fixes at all if nobody owns the duty. The tooling is table stakes; the ownership is the real control.
What do public CVE histories actually tell you?
Less than critics claim and more than vendors admit. Raw CVE counts measure research attention as much as code quality, so never choose by count. Read the patterns instead: SAP's public history skews toward high-impact flaws in long-lived proprietary layers; Odoo's toward access-control and injection issues in modules; a custom build has no CVE feed at all.
Three readings that are actually useful:
- ▸Exploitation, not existence. Check which product flaws appear in known-exploited-vulnerability catalogs and incident reporting, not how many CVE identifiers exist. Per public reporting, major internet-exposed SAP components have been mass-exploited within days of patch release in recent years, while Odoo issues more commonly surface as authenticated or module-level flaws.
- ▸Pre-auth versus post-auth. A pre-authentication flaw in a network-exposed service is a different species from a bug behind login. Weight your reading of any advisory feed accordingly.
- ▸No feed is not no bugs. A custom build's empty CVE history is an advantage, no script-kiddie playbook exists for it, and a blind spot: nobody researches your code for free. You have to buy that scrutiny deliberately, as we explain in Penetration Testing 101: What It Is and When Your Business Needs One.
Where does default configuration create day-one risk?
Large platforms ship defaults optimized for successful installation, not for security. SAP landscapes are infamous for well-known standard accounts and permissive interface configurations that hardening guides exist to undo. Odoo installs expose a database-manager page whose master password must be set and locked down. A custom build has no famous defaults for attackers to script against.
- ▸SAP: the hardening literature for a full landscape runs to hundreds of pages, standard clients and accounts, RFC gateway and message-server access rules, and dozens of services a default install leaves reachable. Excellent guidance exists; the risk lives in the gap between the guidance and any given installation.
- ▸Odoo: the database manager, the master password, demo data, and the temptation to expose the whole instance publicly because the website and portal modules live in the same process. Off-the-shelf scanners fingerprint exposed Odoo instances in seconds.
- ▸Custom: no attacker has a checklist for your app, but you have no vendor hardening guide either. The failure mode shifts to skipped basics: weak session handling, missing rate limits, over-broad admin roles. That class of defect is exactly what security auditors find in admin panels, and it is cheapest to prevent at design time, the argument we make in Secure by Design: Why Bolting On Security Later Always Costs More.
How dangerous is the plugin and module supply chain?
This is where the three options diverge most. SAP add-ons come from a comparatively vetted commercial ecosystem but run with deep privileges. Odoo's community app store is vast and unevenly reviewed, and every module runs with the full rights of the framework. A custom build replaces the marketplace with a dependency graph you can pin, scan, and shrink.
- ▸Odoo modules are arbitrary Python inside your ERP process. Weak patterns commonly seen in community modules include missing access rules, unsafe record-rule logic, and abandoned maintainers who never ship a fix. Treat installing one like hiring a contractor and handing them database credentials.
- ▸SAP transports and add-ons are a supply chain into production. Third-party ABAP code and integration middleware inherit the trust of the system they land in; transport review and segregation are the compensating discipline, and they take real staffing.
- ▸Custom builds still have dependencies, npm, PyPI, container base images, and those are a genuine attack vector, as we argued in Supply Chain Attacks: Why Your Dependencies Are Your Biggest Risk. The difference is tractability: a deliberately small dependency set with lockfiles and an SBOM is a reviewable object; a marketplace of thousands of third-party modules is not.
What attack surface does a minimal custom ERP simply not have?
No login page attackers already script against, no database-manager endpoint, no marketplace modules, no dormant HR or e-commerce features listening on the internet, and no exploit economy: mass scanners hunt SAP and Odoo signatures, and a bespoke app matches none of them. Its surface is the short list of endpoints you chose to build.
The deeper point is attacker economics, not obscurity:
- ▸Exploits are products. A working exploit for a popular ERP is reusable against thousands of installations, so it is worth developing, selling, and automating. An exploit for your bespoke tool has a market of one, it only gets built if you specifically are worth targeting.
- ▸Every feature you did not build is code that cannot be exploited. A minimal build covering your actual workflows omits the recruitment portals, forums, and payment pages a suite drags in by default.
- ▸The honest counterweight: your code has bugs too, and a smaller surface is not zero surface. The advantage only holds with secure defaults, code review, dependency hygiene, and periodic testing. Obscurity plus discipline is a strategy; obscurity alone is just a delay.
How should you compare the three for your own threat model?
Score each option against your actual situation, not a generic matrix: what data the ERP will hold, which endpoints face the internet, who administers it, and, honestly, how fast your organization deploys a fix. The best ERP for a team with no patching capacity is not the best ERP for a team with CI.
A five-question scorecard:
- ▸Patch latency: measured in days, what is our realistic advisory-to-production time for this option?
- ▸Pre-auth surface: how many endpoints are reachable before login, and can we put them behind a VPN or an identity-aware proxy?
- ▸Third-party code: who reviewed the last module, add-on, or dependency this system gained, and who will review the next one?
- ▸Blast radius: what does compromise of this system reach, Active Directory, bank integrations, e-invoicing credentials?
- ▸Evidence: can we show an auditor how this system is patched, logged, and access-controlled?
The same method applies to the rest of your stack, we ran it on a typical CRM stack, and if the scoring pushes you off a SaaS suite entirely, sequencing that move safely is its own discipline, covered in our complete guide to escaping SaaS.
How TuniCyberLabs helps
We sit on both sides of this comparison: we harden and test SAP and Odoo estates, and we design and build minimal custom ERPs for EU and North African companies with the security decisions made at scoping, not after go-live. Threat model first, then code.
If you want a threat-model-first read on your ERP options before you commit, talk to our engineers.