Een lek in de WordPress-plugin Elementor Pro maakte deze week complete sites overneembaar, via een component dat de meeste eigenaren nooit bewust hebben gekozen. Als je met een AI-tool hebt gebouwd, is dat je situatie in het klein: er staan tientallen pakketten in je project waarvan je de naam nooit hebt gelezen. Hieronder hoe je daar in een uur overzicht in krijgt.
Het is niemands schuld, het is hoe modern bouwen werkt.
Een gemiddeld modern project heeft een handjevol directe afhankelijkheden, en elk van die pakketten neemt er zelf weer een paar mee. Twee lagen verder sta je op honderden stukjes code van mensen die je nooit hebt gesproken. Dat is niet fout: het is de reden dat je in een dag iets kunt bouwen waar vroeger maanden overheen gingen.
Bij AI-ondersteund bouwen komt daar iets bij. De tool kiest de pakketten, installeert ze en gaat door. Er is geen moment waarop iemand tegen je zegt: we nemen nu dit erbij, ben je het daarmee eens. Het resultaat werkt, en dat is precies waarom niemand kijkt.
Dat gaat goed tot het moment dat er een melding komt over een lek in iets waarvan je niet weet of het in jouw project zit. Het Elementor-lek van deze week is daar het schoolvoorbeeld van: een uploadfunctie in een uitbreiding die veel mensen ooit hebben geïnstalleerd en daarna vergeten.
Drie kolommen, meer heb je niet nodig, en het meeste kun je automatisch ophalen.
De lijst van pakketten die je project gebruikt, met hun versienummer, is meestal met één commando op te halen uit je pakketbeheerder. Bewaar die uitvoer in je project in plaats van hem elke keer opnieuw te draaien, want dan zie je ook wanneer er iets bij is gekomen.
Zet er per belangrijk pakket in één zin bij wat het doet. Dit is het handwerk, en het is precies het deel dat je later redt: bij een melding kun je in tien seconden zien of je de kwetsbare functie überhaupt gebruikt.
Meestal geen probleem, maar er zitten licenties tussen die commercieel gebruik beperken of eisen dat je je eigen code publiceert. Dat merk je pas als je product succesvol wordt, en dan is het duur. Eén keer nakijken is genoeg.
Niet elk pakket is een risico. Deze signalen zijn het bekijken waard.
Vier momenten waarop deze lijst het verschil maakt.
Bij een melding over een lek. Dan is de eerste vraag of jij dat pakket gebruikt, en de tweede of je de kwetsbare functie gebruikt. Met de lijst duurt dat een minuut, zonder de lijst een middag. Hoe je daarna bepaalt of het haast heeft staat in hoe snel moet jij een lek dichten.
Bij een vragenlijst van een zakelijke klant. Bijna elke lijst vraagt naar componenten van derden en onderaannemers, en dit is letterlijk het antwoord. Zie de beveiligingsvragenlijst van je eerste zakelijke klant.
Bij het opruimen. In vrijwel elk project dat snel is gebouwd, zitten pakketten die ooit ergens voor zijn geïnstalleerd en nu nergens meer voor worden gebruikt. Die weghalen verkleint je project en je risico tegelijk, en het is het soort werk dat een AI-tool prima voor je kan uitzoeken.
En bij overdracht. Wil je ooit iemand anders laten meewerken of het project verkopen, dan is dit het eerste dat gevraagd wordt. Een project waarvan de eigenaar niet kan zeggen waar het uit bestaat, is minder waard dan hetzelfde project met een lijst erbij.
Omdat modern bouwen zo werkt. Een handvol directe afhankelijkheden neemt er elk weer een paar mee, en twee lagen verder sta je op honderden stukjes code van anderen. Bij AI-ondersteund bouwen komt erbij dat de tool die keuzes maakt zonder ze aan je voor te leggen, omdat het resultaat gewoon werkt.
De lijst met pakketten en versienummers haal je meestal met één commando uit je pakketbeheerder. Bewaar die uitvoer in je project. Zet er daarna met de hand per belangrijk pakket in één zin bij wat het doet. Dat handwerk is het deel dat je later redt, want daarmee kun je een melding meteen op jezelf betrekken.
Op pakketten die al jaren niet zijn bijgewerkt en door één persoon worden onderhouden, op alles dat invoer van gebruikers verwerkt zoals uploads en formulieren, en op pakketten waarvan je niet kunt achterhalen waarom ze erin zitten. Die laatste categorie is vaak gewoon overbodig geworden.
Eén keer wel. De meeste licenties leveren geen probleem op, maar er zitten er tussen die commercieel gebruik beperken of eisen dat je je eigen code publiceert onder dezelfde voorwaarden. Dat merk je pas als je product succesvol wordt, en op dat moment is het een duur probleem.
Voor het inventariseren en het opruimen prima: uitzoeken welke pakketten nergens meer worden gebruikt is precies het soort mechanische taak waar dit goed in is. Voor het beoordelen van een beveiligingsrisico is voorzichtigheid geboden, om de reden die in AI je beveiligingsfouten laten repareren staat.
Zodra er iets bij komt, en dat gaat vanzelf als je de uitvoer in je project bewaart in plaats van hem los te draaien. Dan zie je bij elke wijziging welke pakketten er zijn toegevoegd. De handmatige beschrijvingen hoef je alleen aan te vullen voor nieuwe belangrijke onderdelen.
Ja, alleen zit het overzicht dan bij de aanbieder in plaats van in je code. Vraag welke onderdelen en integraties je project gebruikt en welke externe diensten daarbij worden aangeroepen. Je hebt dezelfde lijst nodig, je moet hem alleen ergens anders vandaan halen.
Kijk eerst of je de kwetsbare functie gebruikt, want dat is vaak niet zo, en dan is de haast er meteen af. Kijk daarna of het onderdeel bereikbaar is vanaf internet en of er staat dat het al wordt misbruikt. Die drie vragen bepalen of je het vandaag doet of op je vaste onderhoudsmoment.
Stuur ons je idee. Wij kijken in een intake mee welke flow je wilt testen en leveren in één werkdag een klikbaar prototype, met de juiste tools voor jouw geval.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.