Wat moet er deze maand aan het portfolio gebeuren?
Alle schermafbeeldingen op deze pagina komen uit vigil zelf, gevuld met een verzonnen demoportfolio. Echte projecten en klanten tonen we niet; waarom leest u verderop.
Waarom het bestaat
Beveiligingslekken
Uit dezelfde bronnen als composer audit en npm audit, over de volledige boom: de meeste lekken zitten niet in wat u zelf vroeg, maar in wat daaronder meekwam. Eén regel per package, niet per CVE, met de versie waarin het opgelost is.
Einde ondersteuning
Voor PHP, Symfony en Node. Dit is de enige bevinding met een datum in plaats van een versienummer, en dus de enige die vanzelf dringender wordt: eerst "alleen nog beveiligingsfixes", dan "minder dan een half jaar", dan kritiek.
Nu bij te werken
De nieuwste versie past binnen de constraint die er al staat. Eén composer update verder, vandaag te doen.
Te plannen
Er is een nieuwe major die de constraint bewust buitensluit. Dat is een beslissing, geen taak. Families worden samengevouwen: dertig regels symfony/x 6.4 → 7.4 zijn één afweging.
Hoe een scan verloopt
-
Manifesten ophalen
composer.lock,package.jsonen de lockfiles, rechtstreeks via de API van GitLab. - Vergelijken Met Packagist en de npm-registry voor de nieuwste versies, met de advisory-databanken voor lekken, en met endoflife.date voor de runtimes.
- Bevindingen Gerangschikt naar wat ze van u vragen, niet naar hoe groot het versieverschil is.
- Werklijst Samen met uw eerdere besluiten: wat al uitgesteld of bewust aanvaard is, telt niet meer als openstaand werk.
Niets clonen, niets installeren
Dat is geen optimalisatie maar een grens. composer install en pnpm install voeren scripts van derden uit. Dat wekelijks en zonder toezicht over tientallen repositories laten draaien is precies het supply-chain-scenario dat u wil vermijden.
De prijs is dat vigil versie-constraints benadert in plaats van ze op te lossen. Die benadering zit op één plek en is getest. Wat ze niet begrijpt, meldt ze als zodanig in plaats van het stil te laten passeren.
Wat er naar buiten gaat
Aan de registries vraagt vigil alleen naar pakketnamen: welke packages er bestaan en wat hun nieuwste versie is. Niet welk project ze gebruikt, en nooit code. De antwoorden worden enkele uren bewaard, zodat een scan van het hele portfolio niet honderden keren hetzelfde vraagt.
Een werklijst, geen rapport
Open
Werk dat op u wacht. Zolang u niets beslist, is het open.
Uitgesteld
"Ik weet het, maar niet deze maand." Komt vanzelf terug op de datum die u koos.
Bewust aanvaard
Bijvoorbeeld op een LTS blijven. Geldt voor één concreet verschil: verschijnt er een nieuwere major, dan hoort u het opnieuw.
Einde ondersteuning kan u niet aanvaarden, alleen uitstellen, en nooit tot voorbij de dag waarop de beveiligingsfixes stoppen. Die grens wordt afgedwongen, niet gehoopt.
Security in één oogopslag
Samen met het agentteam
Opdrachten
Eén knop op een project: "laat het team dit bijwerken". vigil maakt het updateplan en start een pipeline. Daarin werkt een agent de dependencies bij en draait de tests, de reviewers kijken mee, en het resultaat is een merge request die een mens beoordeelt.
Reviews
Na elke teamreview, lokaal of in CI, komt het rapport van de security- en code-reviewer binnen in vigil. Zo ziet u per project het laatste oordeel, en welke projecten nog nooit een review kregen.
In de editor
vigil is ook een MCP-server. Een agent in Wisp of Claude Code vraagt vanuit de projectmap wat er híer te doen valt, of welke eerdere reviews er zijn, voor hij aan het werk gaat.
Hoe het is opgebouwd
Het draait intern, met opzet
Wat vigil bijhoudt, is welke live sites op welke versies draaien, en dus welke bekend kwetsbaar zijn. Dat is geen configuratie maar een aanvalskaart van het hele portfolio. Daarom staat vigil niet op het internet maar op een eigen machine in ons privénetwerk, en ook daar is inloggen verplicht: netwerkbeveiliging is geen authenticatie.
Eén rapportlaag voor alles
Het dashboard, de wekelijkse mail, de statuskaart op onze interne startpagina en de MCP-server bouwen hun uitkomst met dezelfde code. Berekenden ze elk hun eigen cijfers, dan was de mail de eerste die u niet meer vertrouwt.
Geheimen versleuteld, niet in een configbestand
Toegangstokens staan versleuteld in de database. API-tokens voor de editor worden alleen als hash bewaard: u ziet de waarde één keer, en kwijt is kwijt.
Klaar voor meer dan één organisatie
Elke rij hangt aan een organisatie en elke zoekopdracht vraagt er één, terwijl er vandaag precies één bestaat. Achteraf multi-tenancy inbouwen betekent elke query nalopen, en één vergeten filter is de ergste bug die dit soort software kent.
De gevoelige logica (versies vergelijken, constraints lezen, de vervalregels van besluiten) is gedekt door tests. Elke fout daarin schuift een bevinding tussen "nu bij te werken" en "te plannen", of maakt erger nog iets stil dat open hoorde te staan.