Op build-servers en CI-machines draait dezelfde antivirus als op kantoor en builds zijn factor 3 trager dan op een vergelijkbaar dev-laptop.

Een build-runner is functioneel een server. Dezelfde policy als laptops geven hem onnodig veel scan-werk op kortlevende files. Aparte policy met een smalle scope is verdedigbaar en hoort gedocumenteerd.

Probeer dit eerst zelf

1. 1Maak in je AV-console (Defender, Sentinel, CrowdStrike, etc) een aparte policy voor build-machines. Plaats ze in een aparte device-group zodat de productie-policy niet verandert.
2. 2Sluit de build-workspace en cache-folders uit: typisch 'C:\agent\_work', '%LOCALAPPDATA%\Pip\Cache', '%LOCALAPPDATA%\NuGet\v3-cache', npm/yarn caches.
3. 3Voeg process-exclusions toe voor compilers en runners: 'msbuild.exe', 'dotnet.exe', 'node.exe', 'go.exe', 'java.exe'. Smaller dan paden, dus voorkeur waar mogelijk.
4. 4Plan een wekelijkse full scan in een rustig venster en houd real-time scanning aan op alles buiten de build-paden. Zo verlies je geen detectie op binnenkomende artefacts.
5. 5Meet het verschil: draai dezelfde build voor en na de policy-aanpassing en log de tijd. Concrete cijfers helpen bij security-review.
6. 6Zet een review-datum in de kalender, bijvoorbeeld elke 6 maanden. Build-tooling verandert en uitsluitingen blijven anders eeuwig staan.

Past het bovenstaande niet?

Beschrijf je situatie hieronder. We sturen jouw input plus de stappen die je al zag naar onze AI en geven gericht vervolg-advies. Als het te risicovol is om zelf te doen, zeggen we dat ook.