Code scannen
Vier manieren om software op zwakke plekken te onderzoeken, en welke wij gebruiken.
- Secret scanning
- Zoeken naar wachtwoorden, API-keys, tokens en privésleutels in code en in de git-geschiedenis. Wij doen dit met gitleaks over de geschiedenis van je standaardbranch, tot tweeduizend commits terug; de waarde laten we nooit zien.
- Meer hierover: Geheimen in code
- SAST (static application security testing)
- Code lezen zonder hem uit te voeren, op zoek naar riskante patronen zoals SQL uit losse tekst of invoer in een shell-commando. Bij ons: semgrep en bandit, in een vaste versie.
- Meer hierover: Beveiligingsscan
- SCA (software composition analysis)
- De onderdelen van anderen in je software naast de openbare lijsten van bekende kwetsbaarheden leggen. Bij ons: osv-scanner op je lockfiles.
- Meer hierover: Afhankelijkheden
- DAST (dynamic application security testing)
- Een draaiende applicatie van buiten testen door er verzoeken op af te sturen. Dat doen wij niet: we lezen code en configuratie. Je publieke site bekijken we alleen passief, en pas nadat je hebt aangetoond dat hij van jou is.
- Meer hierover: AVG en cookies
- Pentest
- Een mens of een tool valt je draaiende applicatie aan om te zien hoe ver hij komt. Wij doen geen pentest: we lezen code en configuratie.
- Meer hierover: Beveiligingsscan
Onderdelen en de keten
Je software bestaat grotendeels uit onderdelen van anderen. De woorden die daarbij horen:
- Dependency (afhankelijkheid)
- Een pakket van iemand anders dat je applicatie gebruikt, uit npm of PyPI. Zo'n pakket heeft zelf ook pakketten: de indirecte afhankelijkheden.
- Meer hierover: Afhankelijkheden
- Lockfile
- Een bestand dat precies vastlegt welke versie van elk onderdeel je gebruikt, zoals package-lock.json of uv.lock. Zonder lockfile weet niemand welke versie live draait.
- Meer hierover: Afhankelijkheden
- SBOM (software bill of materials)
- Een stuklijst van alle onderdelen in je software, met versie. De Cyber Resilience Act vraagt fabrikanten hun onderdelen bij te houden. Wij leveren geen SBOM; we laten zien welke onderdelen een bekend probleem hebben.
- Meer hierover: Cyber Resilience Act
- Supply chain (toeleveringsketen)
- Alles wat van buiten je software binnenkomt: pakketten, images, pipelines, de tools van je CI. Een zwakke schakel daarin is een zwakke schakel in je product.
- Meer hierover: Cyberbeveiligingswet
- End of life
- Een runtime of framework dat geen beveiligingsupdates meer krijgt. Wij leggen je versies naast de ondersteuningsdata.
- Meer hierover: Codekwaliteit
- Infrastructure as code
- Hoe je applicatie draait, vastgelegd in bestanden in je repository: een Dockerfile, Kubernetes, Helm, Terraform. Wij lezen die bestanden; met je cluster maken we geen verbinding.
- Meer hierover: Dockerfile en Kubernetes
Onderhoud en kennis
Wat een applicatie op de lange duur onderhoudbaar houdt, en hoe je dat meet.
- Technische schuld
- Werk dat je uitstelt en later terugbetaalt, in tragere wijzigingen en meer fouten. Zelf niet te meten; de sporen wel: complexe bestanden die vaak veranderen en weinig tests hebben.
- Meer hierover: Technische schuld
- Bus factor
- Het aantal mensen dat kan wegvallen voordat niemand de software meer kan onderhouden. Bij een bus factor van 1 zit alle kennis bij één persoon. Wij meten het uit de git-geschiedenis.
- Meer hierover: Continuïteit
- Hotspot
- Een bestand dat complex is en ook het vaakst verandert. Daar wringt het eerst.
- Meer hierover: Codekwaliteit
- Testdekking (coverage)
- Welk deel van de code door tests wordt geraakt. Een getal zegt niet alles: wij kijken ook of het rapport bij de commit hoort en of de pijplijn iets testte.
- Meer hierover: Testbewijs
- CI (continuous integration)
- De pipeline die bij elke wijziging bouwt en test, zoals GitHub Actions of Azure Pipelines. Wij lezen de rapporten ervan met leesrechten; je tests draaien we in de pilot niet zelf.
- Meer hierover: Testbewijs
Bouwen met AI
De woorden die bij ontwikkelen met AI-assistenten horen, en wat ze voor een controle betekenen.
- Vibe coding
- Bouwen in gesprek met een AI-assistent en houden wat werkt. Het tempo gaat omhoog; of tests, architectuur en documentatie meekomen, vraagt niemand vanzelf.
- Meer hierover: Ontwikkelen met AI
- AI code review
- Een AI die één wijziging in een pull request beoordeelt. Wij doen iets anders: we controleren het resultaat, de hele codebase en het bewijs in je CI, binnen een dag na elke nieuwe versie.
- Meer hierover: Ontwikkelen met AI
- Prompt injection
- Tekst in een bestand of op een pagina die een AI-assistent instructies geeft die niet van de gebruiker komen. Wij zoeken ernaar in je repository, en onze eigen inspectie volgt zulke tekst niet op.
- Meer hierover: Ontwikkelen met AI
- Instructiebestand voor assistenten
- Een bestand zoals AGENTS.md dat een assistent leest voordat hij aan je code werkt. Wij nemen het mee bij de documentatie.
- Meer hierover: Documentatie
- Nagekeken bewering
- Wat ons AI-model over je code beweert, telt pas als onze code het heeft nagekeken op bestand, regel en citaat. Anders komt het niet in je werkplek.
- Meer hierover: Zo controleren we