Security & Trust
Security starts with a simple principle: your code shouldn't have to leave your building to be modernized. API Modernizer is built to run entirely inside your own environment — your source, the generated code, and your data stay on a machine you control. Nothing is uploaded, and no third-party service sits in the conversion path.
Where Your Code Runs
On-premise / air-gapped
Deploy API Modernizer inside your own network, VPC, or a fully air-gapped environment. Your Mule source, the generated Spring Boot code, and your data never leave your infrastructure. There is no upload to us, no third-party cloud, and no third-party LLM in the conversion path — so there is no vendor sub-processor to assess and nothing for anyone else to store, log, or be breached for.
Hosted Playground
The online Playground lets you try individual DataWeave-compatible transformations in your browser — paste a snippet, see the output. It is for evaluation only: you never upload a Mule application or your source estate to us. Anything you paste is processed transiently and not retained. Migrating real Mule applications always runs on-premise, inside your own environment.
Deployment & Requirements
API Modernizer installs and runs entirely on a machine inside your environment. There is no tenant, no upload, and no shared infrastructure — the deployment model is deliberately simple, so your security review is short.
- Install
- A self-contained application that ships with its own bundled Java runtime — nothing to provision first. Windows today; macOS and Linux are on the near-term roadmap.
- Where it runs
- On a workstation or server you control, driven by a local web interface. Every conversion happens on that machine.
- Zero egress
- No outbound calls in the conversion path. The optional AI assistance runs as a local model on the same machine — nothing is ever sent to an external service.
- Self-governing footprint
- The converter continuously caps its own disk use as a share of the host, declines to start when free space is low, halts a runaway job, and cleans up after itself — it cannot fill a production machine.
- Input & output
- In: your Mule 4 application and your existing test collection. Out: a standard Spring Boot 3.2 / Java 17 Maven project you own outright — build and run it with your own JDK and CI, and containerise it if you wish.
- Hardware
- No GPU or specialised hardware. Sized like a standard Java build host, with headroom for the optional local AI model; exact CPU, memory, and disk are confirmed against your environment during the pilot.
Design Principles
- ✓Data sovereignty by deployment — the on-premise option keeps all source, artifacts, and data inside your own environment
- ✓Least privilege by default — no component has access beyond what it requires to perform its function
- ✓No source upload for migrations — real Mule applications are migrated on-premise, inside your environment; the hosted Playground only evaluates pasted DataWeave snippets, processed transiently and never retained
- ✓Zero trust between components — internal components communicate via explicit interfaces with validated inputs
- ✓Defence in depth — multiple independent security controls protect each attack surface
- ✓Transparency — all security controls are documented and verifiable
Technical Controls
- •On-premise / air-gapped deployment — no data egress in the conversion path
- •TLS 1.2+ in transit, everywhere
- •AES/GCM encryption with securely generated random IVs
- •UUID-namespaced job isolation with automatic data deletion (hosted Playground)
- •Zip-slip and XXE protection on all file processing
- •Rate limiting and abuse protection on every public endpoint
- •Strict, allowlisted CORS — no wildcard origins
Compliance Posture
| Standard | Status |
|---|---|
| OWASP Top 10 (2021) | All 10 categories reviewed and addressed |
| GDPR | Data minimisation and retention limits by design; on-premise keeps data in your environment |
| SOC 2 Type II | Roadmap — audit logging framework in place; formal certification planned |
| ISO 27001 | Roadmap — controls aligned; formal certification planned |
We describe our security posture precisely: controls that are implemented today are stated as implemented; certifications that are in progress are stated as in progress, not claimed as complete. On-premise / air-gapped deployment is the only path for migrating real Mule applications — your source estate is never uploaded to us. The hosted Playground processes only pasted DataWeave snippets for evaluation and retains nothing.
Responsible Disclosure
We welcome reports from security researchers and treat them as a partnership. If you believe you have found a vulnerability in API Modernizer, please tell us before disclosing it publicly, and give us a reasonable window to investigate and remediate.
How to report
- •Email [email protected] with a description of the issue, the affected URL or component, and steps to reproduce.
- •If email is unavailable, use the contact form and mark your message as a security report.
- •Please do not disclose the issue publicly until we have confirmed a fix or agreed a coordinated disclosure timeline with you.
Safe harbour
We will not pursue or support legal action against researchers who act in good faith: who make a genuine effort to avoid privacy violations, data destruction, and service disruption; who only interact with accounts they own or have explicit permission to test; and who give us a reasonable time to respond before any public disclosure. Testing must stay within scope — the apimodernizer.com web properties and our published endpoints — and must not include denial-of-service, spam, social engineering of our staff, or physical attacks.
What to expect
We aim to acknowledge a valid report within three business days and to keep you updated as we work toward a fix. We do not currently operate a paid bug-bounty programme, but we credit researchers who report responsibly, with your permission.