DIVD-hackers ontdekken 2000 slecht geconfigureerde, publieke Mendix-installaties

Beveiligingsonderzoekers van het Dutch Institute of Vulnerability Disclosure hebben zeker 2000 Mendix-systemen ontdekt die verkeerd geconfigureerd zijn. Daardoor was het mogelijk gevoelige data te achterhalen, zoals medische gegevens en ID-bewijzen.

DIVD schrijft dat het meerdere Mendix-applicaties online heeft gevonden die zowel in de cloud werden gehost als on-premises, maar die dan bijvoorbeeld toch via een openbare poort bereikbaar waren. Mendix is een van oorsprong Nederlands bedrijf dat software maakt waarmee het mogelijk is eigen applicaties te bouwen. DIVD ontdekte geen kwetsbaarheden of bugs in de software zelf, maar vond meerdere instances waarbij een Mendix-omgeving door beheerders onveilig was geconfigureerd.

Het gaat dan bijvoorbeeld om toegangsbeheer dat slecht is ingesteld of verkeerd geconfigureerde rollen, of de mogelijkheid voor nieuwe of anonieme gebruikers om te veel data te achterhalen uit een omgeving. Volgens DIVD is het in veel gevallen al mogelijk informatie te achterhalen door alleen een anoniem account in te zetten. Dat zou het ook lastig maken om misbruik te ontdekken, zeggen de onderzoekers.

Omdat Mendix door zoveel verschillende diensten wordt gebruikt, is het potentiële risico groot. "Er zijn tot nu toe applicaties aangetroffen bij overheden en gemeenten, banken, zorginstellingen, hogescholen, e-learningplatformen, autodealers en interne platformen wereldwijd. In een niet-Nederlandse applicatie zijn bijvoorbeeld 650.000 identiteitsbewijzen toegankelijk", schrijft DIVD. Ook konden de ethische hackers financiële gegevens en medische data inzien. Het was ook mogelijk data te wijzigen, zoals bankrekeninggegevens.

Omdat het niet om een bug gaat bij één specifiek platform of bedrijf, zegt DIVD nu alvast een waarschuwing te publiceren. De organisatie heeft al organisaties benaderd via hun responsible-disclosurebeleid, maar zegt ook andere organisaties te waarschuwen om naar hun Mendix-applicaties te kijken. "Iedere organisatie die Mendix gebruikt, wordt dringend geadviseerd zo snel mogelijk de configuratie van zowel interne als externe Mendix-applicaties te controleren, met nadruk op autorisatie."

Een van de ethisch hackers van DIVD heeft een tooltje gemaakt waarmee het mogelijk is configuraties te scannen op kwetsbaarheden. Ook is er Menscan dat dit kan doen. Verder verwijst DIVD door naar een waarschuwingspagina met mitigatie-informatie van Mendix zelf.

Reacties (63)

[vinkjb]

Hoe zit dat nu toch met al die beveiligingsproblemen? Zijn de ITérs onkundig, of zegt het bedrijf dit kost geld en zien we niet terug of wat is het idee achter al deze ellende steeds?

Kijkt er niemand naar updates van die software?

Ik ben totaal onkundig op dit gebied maar vroeg het me gewoon af

[Jovatov]

In het algemeen geldt dat de vraag naar IT-oplossingen gewoon veel groter is dan het aanbod aan IT-professionals die dat voor een betaalbare prijs, kwalitatief goed kan doen. Door deze mismatch moeten er keuzes gemaakt worden en wordt de focus in eerste instantie gelegd op zaken waar klanten mee binnengehaald worden cq de dagelijkse werkzaamheden in ondersteund worden. IT-werkzaamheden om risico's te verlagen hebben simpelweg geen direct nut en belanden dus onderaan de stapel.

Vergelijk het met het schoonmaken van je bedrijfsruimte met een beperkt aanbod aan schoonmakers. Je zorgt in elk geval dat de receptie/waar de klanten komen goed schoon is. Daarna komen de kantoren waar dagelijks personeel is. De archiefruimtes waar nauwelijks iemand komt worden bijna niet aangepakt.

[Seth_Chaos]

Toen dat tekort er niet was, was het net zo slecht, zo niet nog veel slechter gesteld met de veiligheid van het IT landschap. De realiteit is dat veel personeel ook gewoon het werk doet, omdat het moet. En die doen niet meer dan het minimum van wat van ze verwacht wordt. En kiezen uitsluitend voor de gebaande paden.

En dan zit je nog met het probleem dat er boven de specialisten vaak een management laag zit, die niet de kennis en of kunde heeft, maar wel de beslissingsbevoegden zijn die het werk en de richting bepalen. Een beetje vergelijkbaar met de politiek waar onkundige volksvertegenwoordigers een portfolio in de handen gedrukt krijgen waar ze totaal geen kaas van gegeten hebben. Heel af en toe heb je geluk, en zit er iemand op zo'n post die wel kundig is. Maar dat is en blijft een zeldzaamheid.

[satya]

Op dit moment is het tekort echt nijpend. Wij beheren een redelijk omvangrijke omgeving met specialistische applicaties en bij alle leveranciers kunnen we merken dat het spaak loopt en veel zaken langer duren.

[Pepweb]

Ja, maar dit is toch ridicuul om dat te negeren bij de overheidssoftware?

[Ozymandias]

Bij schoonmakers geldt ook altijd: het mag niks kosten. En dan wordt er niet goed schoongemaakt.

[TERW_DAN]

Er zijn zoveel manieren waarop dit fout kan gaan.
- onkundige ITers. De wereld verandert snel, en als ze dan niet meekomen dan kun je dit soort dingen krijgen.
- managers die het niet snappen. Een ITer kan nog zo'n goed punt hebben. Als de manager het verbiedt, of simpelweg zegt dat er geen tijd is om config xyz uit te rollen, dan kan zo'n ITer ook niet zoveel.
- Tijdelijke oplossingen, die alles behalve tijdelijk blijken te zijn. Er wordt snel even iets in elkaar gezet als proof of concept, maar omdat dat goed genoeg werkt wordt het gelijk in productie gebruikt, in plaats van dat het fatsoenlijk geconfigged wordt.
- Een niet ITer die hiermee aan de gang gaat. Zeker met de opkomst van AI denkt iedereen vanalles in elkaar te kunnen vibe-coden, zonder gehinderd te worden door enige kennis. En dat wordt live gegooid omdat het toch wel werkt. Maar dat het zo lek is als een mandje ziet niemand. Of het wordt niet geupdate omdat niemand weet dat het nog ergens draait.

En zo zijn er vast nog wel een aantal dingen te bedenken. Het is vaak ook een samenloop van meerdere factoren, maar in een tijdperk dat alles aan het internet moet hangen vaak wel erg vervelend.

[vargo]

Om nog even door te gaan:

• Kwetsbaarheden zijn ten tijde van oorspronkelijke oplevering vaak nog niet bekend: onderhoud aan systemen met security patches is essentieel
• Het bouwen van IT infra en software is en blijft mensenwerk (okay Anthropic en OpenAI claimen dat bots dit gaan overnemen ), en iets over het hoofd zien of verkeerd doen kan altijd gebeuren, ook al ben je nog zo kundig.
• In het verlengde hiervan: social engineering. Simpel gezegd wordt iemand in de organisatie voor de gek gehouden, en lekt deze data, of geeft deze privileges aan een kwaadwillend persoon
• soms: zero-day exploits (kwetsbaarheden die nog niet publiek bekend zijn maar die een aanvaller al wel in zijn gereedschapkist heeft)
• etc

Wat betreft de individuen die de fout in gaan, dat speelt zeker een rol, maar ook de organisatie als geheel moet cultuur ontwikkelen waarbij security voorop staat. Denk aan:

• iemand die eigenaarschap op zich neemt en zich verantwoordelijk voelt (bv security en privacy officer); die het mandaat heeft pushback kan geven op bv commerciele belangen die ten koste van security of privacy gaan (GDPR vereist trouwens het aanstellen van een Data Protection Officer)
• het definieren van standaarden tav veilige infra en applicatie ontwikkeling
• skill en awareness training, toegespitst op de rollen en vereiste expertise (helpdesk medewerker heeft andere kennis en behoeften dan software engineer)
• duidelijke eisen tav leveranciers van IT tech en diensten
• tijd en budget voor periodieke security audits om kwetsbaarheden zelf te ontdekken en om van te leren
• een mindset bij mensen dat security een hygiene factor is (net als schone handen in een ziekenhuis)

Het zal nooit een 100% garantie zijn, maar als het goed is leidt het tot practices als DevSecOps, Security-by-design, least-privilege access, aandacht op c-level dat dit op orde is etc etc.

[dmantione]

Ik zou daaraan willen toevoegen: Beveiliging is per definitie onhandig. De verleiding om iets van het slot te halen uit gemak is heel groot en een goed compromis bedenken tussen veiligheid en gemak vergt vaak investering. Zo lang het goed gaat, blijft het slot er dan vaak af.

[timonb]

Iedereen gebruikt op een bepaalde manier low code. Jij gebruikt die ene library, lees: je gebruikt dus een heel stuk code waarvan je uitgaat dat het goed is. Met andere woorden jij hoeft niet meer die specialist te zijn op het gebied dat die library voor je oplost.

je gebruikt die ene programmeertaal die zorgt ervoor dat je niet meer in machinetaal met de cpu en het geheugen hoeft te praten.

Dat maakt de wereld echt stukken makkelijker.

Tegelijkertijd blijft software maken echt een vak. Het is echt heel eenvoudig een appje te bouwen. Maar goede software maken is echt heel moeilijk. Je hebt naast het schrijven van juiste syntax ook te maken met kwaliteit van software. Is de beveiliging op orde? Presteert de applicatie goed als er vele gebruikers ingelogd zijn? Is het gebruiksvriendelijk? Is het efficient? En dan heb je het nog niets eens over hoe past dat stuk software in de organisatie?

Ongeacht welke taal (high or low code) je gebruikt, slechte software is zo gemaakt

[sfranken]

Vaak is het management druk. Manager X wil dat de applicatie binnen X of Y periode draait want dat heeft hij/zij beloofd aan "de baas" en dus moet dat gebeuren, want anders komt dat knullig over! Dus dingen als beveiliging e.d "komen nog wel"...

[Blokker_1999]

Waarom voelen sommigen toch altijd de nood om direct maar weer eens een stereotype boven te halen? Ik kan tientallen andere verklaringen verzinnen die allemaal waar kunnen zijn in dit geval.

[sfranken]

Omdat mijn ervaring is dat dit stereotype in 90% van de gevallen klopt

[ctrl-tab]

Geef de schuld maar aan de manager. Je faalt als it'er als je security opiffert om een manager te pleasen. Zeker als het grove fouten betreft zoals het open zetten van applicaties voor de wereld.

[iqcgubon]

Als jij het niet wil doen escaleert die wel en vraagt die het wel aan de volgende helaas.

[Onbekend]

Het is altijd een kwestie van tijd en geld.
In de ideale wereld heb je voldoende tijd en geld om alle problemen aan te pakken. In de praktijk heb je dat helaas niet en moet je keuzes maken, met het gevolg dat sommige zaken te lang blijven liggen of zelfs nooit worden opgepakt....

[Siaon]

Veel dingen zijn volgens mij ook gewoon echt onnodig. Waarom hangt een bepaald systeem uberhaupt aan het internet? Waarom beperk je toegang niet tot een bepaald IP. Waarom gebruik je niet gewoon een fysieke token, net als een sleutel om een deur van slot te doen.

[dvz89]

Omdat je dan dingen moet inregelen. VPN tunnel, een network policy of iig een firewall. En iemand die het allemaal bijhoudt

[Kerfuffle]

Het is helaas lang niet altijd onkunde qua security. Vaak is het een kwestie van prioriteit en/of gewenning. IT-werknemers weten vaak wel dat er "nog iets moet gebeuren", maar als daar lang genoeg geen prioriteit aan kan worden gegeven, zie je dat mensen ophouden met het opnieuw aankaarten. Ook zie je vaak dat mensen het wel roepen, maar niet tegen de juiste mensen; bijv. omdat ze gewoon niet weten hoe ze de mensen met mandaat kunnen bereiken. En tenslotte zijn mensen in het algemeen slecht in risico inschatten - dat wil zeggen: de kans dat het misgaat overscahtten en de de gevolgen daarvan onderschatten. Zeker wanneer andere zaken duidelijkere pay-off hebben, raken securityaspecten makkelijk achterop. Daarom is een CISO die het mandaat heeft om bijv. minimale requirements en audits af te dwingen geen overbodige luxe.

[Blokker_1999]

En soms is het ook gewoon een kwestie van shadow IT of geen enkele interesse hebben in beveiliging. Heb het zelf ook al gezien. Applicaties in een cloud omgeving opgezet die, ondanks dat ze enkel intern bereikbaar moeten zijn, toch een extern IP adres hebben, geen firewalling en gewoon op poort 80 communiceren.

[dasiro]

"het werkt, dus het is goed". Er is echter meer dat fout kan gaan dan dat er juist kan gaan en al die scenario's afdekken is enorm duur/tijdrovend/kennisintensief. Ik vind het persoonlijk absoluut niet leuk om niet elk detail te kennen, maar weet dat dit voor de overgrote meerderheid jammer genoeg geen zorg is.

[Transportman]

Het is zoals anderen al zeggen een combinatie van factoren, maar meestal is het ook een flink stuk complexiteit en (on)bewuste afwegingen. Daarnaast luistert beveiliging heel nauw, één verkeerde instelling en je kan al nat gaan of informatie lekken waar aanvallers verder mee kunnen. En dan heb je nog de programma's waar de documentatie incompleet is of de standaardinstellingen gewoon ronduit onveilig zijn omdat de leverancier het makkelijk wil maken dat iedereen het programma meteen kan starten zonder nog van alles uit te moeten zetten om lokaal er mee te kunnen werken.

En dat is dan alleen nog maar het programma zelf, meestal zitten er nog firewalls en dergelijke voor die ook weer een rol spelen...

[Unstable Element]

https://xkcd.com/2030/

[keejoz]

Als je soms reacties leest over hoe slecht AI coding is en over hoe geweldig menselijke programmeurs zijn zou je toch geloven van niet

[Sebastian1313]

Wat bedoelt u precies? En wat moet ik niet geloven?

Even ter info, persoonlijk heb ik alleen maar last van slechte AI prestaties dus dat u het veel Leest geloof ik inderdaad heel graag.

[oef!]

Alles hierboven en IT is gewoon moeilijk, je hebt je security, je hardware, je besturingssysteem, je software infra, je databases en nog dan de software die uiterst complex kan zijn. En dan is dat stuk software op zijn beurt weer onderdeel van een heel ecosysteem aan software.


Ontwikkelaars zijn druk met nieuwe features en bugfixes dus hebben ze niet voldoende tijd om fundamentele verbeteringen door te voeren. Hardware is geoutsourced naar een externe beheerspartij wat onduidelijkheid schept Beheerders lopen van issue naar naar incident. Software wordt zo complex dat consultants niet meer de tijd hebben om het hele pakket te kennen. Er is gewoon niet genoeg tijd.

[flurb]

Dit is een lowcode oplossing, soort van configureerbaar ipv te moeten coderen. Trekt met name business analisten achtige engineers die functioneel denken en niet perse focussen op de technische zaken, mede door de aard van de software. En deze situatie is het gevolg van de valse beloften dat een low code omgeving alles "regelt". Verkoopt lekker aan managers. Als dit nu pas publiek wordt, als gevolg van onderzoek door DIVD, is dit waarscjijnlijk al heel lang bekend bij minder vriendelijke hackers. Zie ook de recente Salesforce en Oracle hacks..

[nullbyte]

Cybersecurity is gelaagd en kost altijd meer configuratie, middelen, moeite en geld. Voor de eindgebruiker geldt ook, meer en hogere beveiliging kost meer moeite in gebruik van het systeem. Een ww dat uit 8 tekens mag bestaan en nooit vervalt is makkelijker dan 15 karakters, met OTP of een ubikey.

Telnet gebruiken is makkelijker dan ssh, een server direct aan het internet knopen met ssh is makkelijker dan een vpn server en een firewall / proxy configureren. wachtwoorden in een .env zetten is makkelijker dan een vault gebruiken, SELinux op disabled zetten is makkelijker dan op enforcing, inloggen als root is altijd makkelijker, UAC uitzetten is makkelijker dan al die irritante pop-ups, http is makkelijker dan https, enz, enz, etc, etc.

Tel daarbij op dat cybersecurity jarenlang een afterthought is geweest i.p.v. een design.

[Reactie gewijzigd door nullbyte op 1 maart 2026 13:19]

[CivLord]

Het kan van alles zijn.

Hier gaat het om configuratie.
Het kan zijn dat de configuratie ingewikkeld is en dat er iemand bezig is geweest die niet goed door had wat de gevolgen van bepaalde instellingen zijn.
Het kan ook zijn dat een bepaalde instelling in versie 1 t/m 10 deed wat het moest doen. Waarna in versie 11 een andere optie geïntroduceerd werd, waarbij geen van beide opties gebruikt wordt zolang er geen keuze wordt gemaakt tussen de oude optie of de nieuwe optie. Zoiets staat natuurlijk in de release notes (mag je hopen) maar wordt niet altijd opgepikt

[PieterDenGraaf]

Het is een partij waar je op moet letten als je ermee werkt, ook als leverancier. Mendix staat onder de paraplu van Siemens, Siemens heeft diepe zakken. Maar financieel verkeert het bedrijf zelf in een uiterst precaire situatie. Al jaren maken ze forse verliezen, vaak groter dan hun omzet. Hierdoor is het eigen vermogen diep negatief, rond de 350 miljoen euro op een omzet van 80 miljoen.

Het is dat Siemens de verliezen dekt, anders was Mendix al omgevallen of had Mendix de prijzen moeten verhogen.

[Heimdallr]

Wat je hier over Siemens zegt is domweg niet waar en erg misleidend. Daarom hier een linkje naar de feiten: https://assets.new.siemens.com/siemens/assets/api/uuid:6f0a40f1-9119-4007-b012-5b973b42574d/Annual-Financial-Report-FY2025.pdf

[JTW]

Heb je een bron / jaartal voor de inkomsten? Toen ik vertrok bij Mx in 2018 was er al 50M ARR.

[millerman_sf]

Mendix maakt sinds 2025 gewoon zwarte cijfers. Bron: ik ken de werkgever erg goed. En ja, dat is een trust me bro, maar ivm opsec hou ik het graag iets minder concreet dan dit.

[JTW]

Volgens mij ook. Nou zijn zwarte cijfers wel iets anders dan mega winst en het is de vraag hoe visuele low-code tools het gaan doen met al het AI coding geweld. Iig geen honderden miljoenen verlies zoals hierboven geschetst werd.

[PieterDenGraaf]

Op te vragen bij de KVK. Tot dit jaar werden ze gepubliceerd voor de losse BV:

1. Omzet 82M
2. Operationeel resultaat: -63M
3. Equity: -308M

[timonb]

Boekhouden is ook een vak, net als software maken dat is.

Waar je naar kijkt is het resultaat van de Nederlandse onderneming binnen de Siemens groep.

Je kijkt naar de verkopen in Nederland en je kijkt naar de ontwikkelkosten van het platform. Die voor een grootdeel gemaakt worden in Nederland. Het zal me niet verbazen als de hosting enz ook vanuit Nederland gemaakt worden.

Wat je niet ziet in de cijfers van Mendix is de winsten die wereldwijd gemaakt worden. Je ziet niet die ene klant die Mendix koopt bij de Mendix tak in de VS. Je ziet niet de winsten die een directe klant is van Siemens die gebruik maakt van de Mendix software.

Al die winsten zitten bij Siemens en de locale entiteiten, maar niet bij Mendix. Dus als je bedoelt dat je voor Mendix moet oppassen, omdat het veel potenie heeft binnen de Siemens groep. Zou dat best kunnen kloppen.

[camper69]

Niet iedereen uiteraard, maar veel techneuten die ik ben tegengekomen binnen low-code of ERP-achtige omgevingen maakten op mij technisch geen sterke indruk. Enige interesse in techniek leek vaak beperkt aanwezig. Daarom verbaast het mij eerlijk gezegd niet dat security bij Mendix bovengemiddeld zwak is ingericht.

[sequenter]

Helemaal mee eens... ben van 71 en ik zie zoveel mensen om me heen die niet weten hoe bijvoorbeeld bestandsystemen werken of hoe je bepaalde logica opzet binnen software. En dat je je dan ook nog eens tot in de treuren moet verdedigen om mensen aan hun verstand te peuteren dat hoe ze bezig zijn niet schaalbaar is. Meeste mensen missen de fundamenten om verstandige beslissingen te maken. De opleidingen vergeten compleet de onderliggende logica van computers uit te leggen, of ze gaan daar te theoretisch op in en vergeten dan dat die kennis dan totaal niet toepasbaar is. Gaat steeds meer een groot probleem worden.

[ctrl-tab]

Systemen worden complexer en complexer. Laag over laag over laag. Als je daar langzaan inrolt, zoals wij , leer je dat kennen in fases

Ik haal vaak het kubernetes in de public cloud aan als voorbeeld;

Vroeger had je een aantal fysieke servers met een applicatie erop.
Nu heb je fysieke hypervisors met fysiek netwerk, daarop vm's met een virtual network, daar bovenop een kubernetes cluster met virtual overlay network.
Daar draaien dan (soms) weer virtuele kubernetes clusters op voor je dta.
Vervolgens configureeer je daar via een api services en containers op. Containers, weer een verhaal opzich.
En dan zijn er inmiddels weer frameworks die de consumptie van kubernetes vergemakkelijken door extra abstractielagen toe te voegen.

Dit is allemaal goed behapbaar als oude techneut die elke individuele techniek aan de lijve heeft ondervonden (als dat een redelijk goede techneut is). Je moet alle lagen tot bepaalde hoogte kennen of snappen.

Dit is denk ik ontzettend lastig als newbie.

Dit verhaal gaat natuurlijk ook op voor andere gebieden, tis maar een voorbeeld.

[Reactie gewijzigd door ctrl-tab op 28 februari 2026 11:28]

[malskippetje]

Klopt, ik werk dagelijks met Mendix, bij mijn vorige werkgever was het overgrote merendeel van de Mendix developers Business-IT studenten, en dus geen 'hardcore' software engineers met een diepere kennis van de code achter hetgeen wat er in Mendix wordt gebouwd. Ikzelf ben wel als software engineer opgeleid en ervaarde altijd al een andere manier van denken en doen, wat in mijn ogen tot wat minder kwalitatief werk leed

[Argantonis]

Dit is denk ik ook meteen het probleem, je kan een hoop snel en makkelijk bouwen met Mendix maar als je niet die technische insteek hebt en gewoon denkt ‘ja het werkt toch’ dan ga je niet nog eens kijken naar wat elke rol dan precies wel of niet mag doen en zien.

Ik weet niet of die form visibility setting er nog is (zelf in 2015 bij Mendix vertrokken) maar dat verleidt mensen er ook wel toe om ‘t visueel wel goed in te richten maar verder de boel niet dicht te zetten.

[satya]

Als je can 69 bent kan het zomaar zijn dat je een steeds grotere groep tegenkomt die bepaalde fundamenten compleet ontberen. Waarom weet ik niet, veel IT opleidingen van nu zijn soms erg specialistisch misschien.

[Usselite]

In het verleden ook eens aangehaald bij een bekendere Outsystems consultancy club. Het project valideerde niet afdoende of de gebruikers daadwerkelijk voldoende rechten hadden. Met als gevolg dat web requests gemanipuleerd konden worden als je eenmaal geauthentiseerd was.

Vaak hebben de low code consultancy clubs niet de technische kennis in huis om een degelijk veilig systeem in elkaar te zetten.

[Sandor_Clegane]

Nee, want weten hoe het werkt is niet 'low code'.

[Argantonis]

Dat kán wel, je kan best met low-code weten hoe je vervolgens die security goed instelt. Het kan dan zelfs een stuk veiliger zijn dan de zoveelste Spring Boot app die ook in elkaar is gezet door mensen die maar oppervlakkig weten waar ze mee bezig zijn. Het probleem is meer dat dat niet als belangrijk wordt gevonden door het type mensen dat dit werk over het algemeen doet en vaak toch half in de business consultancy zitten.

[Sandor_Clegane]

Exact mijn punt.

[Hidrolix]

Misschien is dit vloeken in de kerk.. en misschien is het er al ?

Maar waarom komt er geen normering voor ?

Als ik kijk naar elektrische kabels zitten allemaal eisen aan.. op basis van het gebruikt, locatie en of mensen hulpbehoevend zijn.


Voor IT kan je toch ook iets maken dat die bepaalde security scans moet doorstaan ofzo ?

Zelf ken ik check Marx en zeg niet dat het perfect is maar filtert ook al een hoop rommel eruit.

[Argantonis]

Er zijn best standaarden, OWASP publiceert bijvoorbeeld aanbevelingen, er zijn ISO standaarden, etc.

Maar om te detecteren of een bepaald product zich daaraan houdt is allemaal niet geautomatiseerd en ook niet permanent geldig. Het leuke aan een kabel is dat als je 'm koopt, hij gewoon klaar is. Het is daarnaast relatief een ancient product.

[r0ut]

Super dat zo’n onderzoek is gedaan. Het feit dat veel enterprise apps gebouwd met Mendix vaak door niet vakkundige programmeurs zijn gedaan is een risico. Dat gepaard met standard API die makkelijk is te voorspellen is het extra gevaarlijk. In nieuwere versies van het platform wordt dit laatste iets moeilijker.

ik ben van mening dat iedereen goede en slecht beveiligde apps kunnen maken. Tooling is noodzakelijk hulpmiddel hierin waar je makkelijk inzicht in kunt krijgen.

Geinspireerd door high-code tools als linters, een statische code anaylze tool, ben ik mxlint.com begonnen. mxlint is breed toepasbaar. Goed geintegreerd in het governance en CICD proces kan het best practices zoals maintainability , security en conventies bevorderen.

[Reactie gewijzigd door r0ut op 28 februari 2026 08:41]

[Pepweb]

Wat niet helpt is dat de mendix runtime closed source is. Vendor lock-in

Dat vind ik ernstig en zeer onwenselijk bij overheden

[JTW]

Vrij vreemd dat er niets staat over een tijdslijn, communicatie met Mendix oid. Deze disclosure komt niet erg "responsible" over.

[empheron]

Het probleem zit dan ook niet in het platform of de development stack, maar in hoe low-code engineers daar mee omgaan.

[Okazuta]

Het verbaast mij eigenlijk niet met al die "low code" rommel.
Managers verkopen het als snel en flexibel maar dat valt allemaal vies tegen.

Maarja het is zo lekker makkelijk in elkaar te flansen. Iedereen kan het

[malskippetje]

Ik werk dagelijks met Mendix, en het kan ook echt wel sneller werken. Helemaal als je ziet wat Mendix al voor je doet wat betreft de hele database, authentication en UI lagen. Binnen een dag heb je al een simpele CRUD app draaien met productie level configuraties.

Naarmate een app groter en ouder wordt, wordt die lastiger te onderhouden. Dat gaat wel erg afremmen. Ook omdat iedereen het kan wordt een applicatie door veel verschillende mensen gebouwd wat tot verschillende bouwstijlen lijd, dit remt ook af bij het doorontwikkelen. Maar deze problemen heb je met high code ook wel.

[Pepweb]

Technische schuld gaat snel oplopen. Dit is echt niet wat je wil bij overheidsinstanties. Mendix schrijft uurtje factuurtje na uurtje factuurtje wegens vendor lock-in

Belastingbetaler is de dupe indirect. Slecht verhaal. Overheid moet gewoon open source gebruiken met kundige mensen

[timonb]

Technische schuld ontstaat bij elke regel code die je schrijft. En het maakt niks uit of je dat nou doet in Mendix, Python, C# of wat desnoods in Cobol.

Het ontstaat door alle keuzes die gemaakt worden. Dat is niet lowcode eigen. Het enige echte verschil tussen high code en low code is de snelheid waarmee je kunt ontwikkelen. Een grote applicatie in lowcode is net zo moeilijk te beheren/beheersen als een grote applicatie in highcode.

En die vendor lockin waae je het over hebt… is dat werkelijk zo erg? Met een groot landschap in welke programmeertaal dan ook heb je ook een enorme afhankelijkheid. Je neemt niet zo maar afscheid van de gekozen technologie, kijk maar eens naar Cobol applicaties of AS400 mainframes die nog steeds draaien…

[Pepweb]

Ja, dat is werkelijk zo erg. Je hebt voor elke wijziging, al is het een komma een mendix developer nodig. Zodra je open source gebruikt heb je de keuze om een team eruit te gooien en een nieuw team neer te zetten die ook bij dezelfde code kunnen. De html, js en css output van mendix voldoet compleet niet aan wcag normen. Sterker nog, de kwaliteit daarvan gaat voor een groot deel 20 jaar terug in de tijd.

Maar dat kan allemaal, want je kunt ‘sneller’ ontwikkelen. Niets is minder waar. Ja, je kunt een formuliertje in elkaar klikken in 5 minuten, maar het wordt al snel complex en zodra het complex wordt moet mendix widgets gaan importeren en krijg je de widget hell. Daar is low code niet voor gebouwd. En dan ben je al te laat als organisatie en zit je vast aan een hoop ellende en hoge kosten en contracten.

Debuggen is overigens ook niet waar je in mendix blij van wordt. Unit testing? Dat heeft mendix niet en als ze het al hebben wordt het niet ingezet, en met een reden natuurlijk. Dit zou verplicht moeten zijn. Met open source is dit allemaal veel toegankelijker en kwalitatief veel beter neer te zetten en het is volledig transparant wat een developer commit aan code. Mendix heeft zijn eigen gitlab omgeving die niemand kan inzien, behalve mendix die zijn eigen vlees keurt

Al met al een drama dus

[Argantonis]

Je hebt een Mendix developer nodig? Ehh nee dus. Je kan prima iemand in je eigen bedrijf een introductie geven om dit soort kleine wijzigingen te doen, juist makkelijker dan wanneer je daar een gespecialiseerde developer voor nodig hebt.

Er is best valide kritiek op hoe complex Mendix kan worden, zeker als het gebouwd is door mensen die niet weten waar ze mee bezig zijn. Maar dat je een Mendix developer nodig hebt om een komma te wijzigen is er daar geen van.

Overigens gaat het overnemen van een code base van een significante applicatie, of die nou in Cobol of Rust is geschreven, echt allemaal niet vanzelf en stel je je dat echt veel te simpel voor.

[Pepweb]

Mendix is een low code platform. Veel ‘developers’ zijn eigenlijk geen developer. Daar gaat t al fout. De aap moest een keer uit de mouw komen in de ‘mendix verkoop machine’.

[Maarten69]

/s

[satya]

Men kan ook een agent opzetten die met een voor deze omgeving gespecialiseerde MCP tegen de omgeving aankijkt en de (security) puntjes op de i kan zetten.

[kuurtjes]

Deze problemen gaan inderdaad verdwijnen omdat er nog honderdmaal ergere problemen gaan komen.