Wat is een afhankelijkheid?

Een stuk software van iemand anders dat je applicatie gebruikt, zoals een pakket uit npm of PyPI. Zo'n onderdeel heeft zelf ook onderdelen: dat zijn de indirecte afhankelijkheden.

Maken jullie een SBOM?

Nee. We laten zien welke onderdelen een bekende kwetsbaarheid hebben of bekendstaan als kwaadaardig. Een volledige stuklijst leveren we niet.

Werken jullie de onderdelen ook bij?

Nee. We repareren niets en veranderen niets in je repository. Jullie beslissen wat je bijwerkt.

Dat draait toch al in onze pipeline?

Misschien, en dat is goed. Wij draaien de scanner in een vaste versie, leggen de uitkomst naast je tests, je documentatie en je architectuur, en laten het zien voor elke rol.

Welke talen en pakketbeheerders?

Python, JavaScript en TypeScript. Andere talen passen nog niet in de pilot.

Kwetsbare afhankelijkheden controleren

Kwetsbare afhankelijkheden in je Python- en JavaScript-code vinden

Je software draait op veel onderdelen van anderen, en elk onderdeel kan een bekende kwetsbaarheid hebben. Wij lezen je lockfiles en leggen elk onderdeel naast de openbare lijsten van bekende kwetsbaarheden. Je ziet per bevinding welk onderdeel, welke versie en waar het in je repository staat.

Bijgewerkt op 18 oktober 2026

Wat we controleren

Een erkende open-source scanner in een vaste versie, zonder AI, op de lockfiles in je repository. Een lockfile legt vast welke versies je gebruikt, ook van onderdelen van onderdelen.

Onderdelen met een bekende kwetsbaarheid, direct en indirect
Pakketten die bekendstaan als kwaadaardig
Of er lockfiles zijn: zonder lockfile weet niemand precies welke versie live draait
Runtimes en frameworks die geen beveiligingsupdates meer krijgen

Supply chain: wat we wel en niet leveren

We laten zien welke onderdelen een bekend probleem hebben. We maken geen softwarestuklijst (SBOM) en we werken geen onderdelen voor je bij.

Jullie bepalen welke update je doorvoert en wanneer. Wij laten zien wat er is, met bewijs, zodat je weet waar je begint.

Wat je terugkrijgt

Per bevinding: het onderdeel, de versie, de melding in de openbare lijst en de lockfile waarin het staat. In je werkplek zie je dat in lagen: een stoplicht voor de directie, en voor developers precies waar het zit.

Waarom een controle bij elke nieuwe versie

Een onderdeel dat vandaag veilig lijkt, kan morgen een melding krijgen. En met AI komt er sneller een nieuw onderdeel bij. Daarom kijken we bij doorlopende controles steeds opnieuw naar je lockfiles.

Aanmelden voor de pilot

De pilot is op uitnodiging. Meld je aan, dan kijken we of je applicatie past en mailen we je. Je koppelt je repository met leesrechten, de eerste controle start vanzelf, je ziet wat er gecontroleerd en bewezen is, en daarna vragen we wat het je waard is. Heb je eerst een vraag? Stel hem in het bericht hieronder.

Ons team

Leest elke aanmelding en elke vraag

Ons team leest wat je stuurt en antwoordt per mail. Een gesprek volgt alleen als je erom vraagt: met de mensen die het werk doen, niet met een verkoper.