Waarom softwarebeveiliging tekortschiet en hoe we systemen weerbaarder maken
Vijf veelvoorkomende beveiligingsfouten en hoe we ze aanpakken met aandacht voor ontwerp, toegangsrechten, softwareonderdelen en beheer.
Belangrijkste punten
- 1We nemen beveiliging mee tijdens ontwerp en ontwikkeling, niet alleen vóór de release.
- 2We beperken toegang, beschermen bouwreferenties en controleren externe softwareonderdelen.
- 3We kiezen maatregelen die passen bij het systeem en de risico's.
- Gepubliceerd op
Onderwerpen
Op deze pagina
Een gelekt wachtwoord, een kwetsbaar softwareonderdeel of een API met te ruime toegangsrechten kan een alledaags systeem kwetsbaar maken. Zulke problemen zijn lastiger op te lossen als beveiliging pas aan het einde wordt gecontroleerd in plaats van onderdeel te zijn van het ontwikkelwerk.
We nemen beveiliging mee in het ontwerp, de code en het releaseproces. Dit zijn vijf veelvoorkomende fouten waar we op letten, en zo pakken we ze aan.
“Beveiliging is geen laatste controle. Het vraagt om keuzes in iedere fase van een systeem.”
— Brian Timmermans
Vijf beveiligingsfouten en hoe we ze aanpakken
1. Pas bij de release aan beveiliging denken
Als de software bijna klaar is, staat het basisontwerp al vast. De omgang met gevoelige gegevens of de toegangsrechten aanpassen kan dan veel tijd en werk kosten.
We bespreken tijdens het ontwerp welke gegevens gevoelig zijn, wie ze gebruikt, welke systemen verbonden zijn en waar het mis kan gaan. Als de software verandert, bekijken we die keuzes opnieuw. We nemen controles op in het ontwikkel- en releaseproces en vertrouwen niet alleen op een eindcontrole.
2. Meer toegang geven dan nodig is
Een account met ruime beheerdersrechten kan meer van een systeem blootleggen dan voor het werk nodig is. Een privénetwerk of VPN bewijst op zichzelf niet dat iedere gebruiker of gekoppelde dienst te vertrouwen is.
We controleren identiteit en rechten waar systemen met elkaar verbonden zijn. Iedereen krijgt alleen toegang die nodig is voor het werk. Ook maatregelen zoals versleuteling en meervoudige verificatie stemmen we af op het systeem en de risico's.
3. Afhankelijkheden uit het oog verliezen
De meeste applicaties gebruiken softwareonderdelen die door andere mensen en organisaties worden onderhouden. Heeft zo'n onderdeel een bekende kwetsbaarheid of verandert het onverwacht, dan kan dat gevolgen hebben voor de hele applicatie.
We houden afhankelijkheden en de risico's ervan bij, leggen versies vast waar dat nodig is en voeren regelmatig beveiligingsscans uit. We beoordelen de uitkomsten en bepalen wat moet veranderen. Een scan heeft pas waarde als we de resultaten opvolgen.
4. Toegangssleutels in code of bouwsystemen laten staan
Wachtwoorden, verbindingsgegevens en API-sleutels kunnen uitlekken als ze in broncode staan. Bouw- en releasesystemen hebben vaak toegang tot belangrijke omgevingen. Ook hun referenties en rechten moeten dus goed worden beschermd.
We houden toegangsgegevens buiten de broncode, beperken wie en wat ze kan gebruiken en vervangen ze als ze uitlekken. Als het platform dat ondersteunt, gebruiken we sleutels die snel verlopen en alleen rechten voor één taak hebben. We beperken ook welke wijzigingen software mogen publiceren.
5. Denken dat een privénetwerk genoeg is
Netwerken helpen systemen van elkaar te scheiden, maar vervangen geen controle van afzonderlijke verzoeken. Als een apparaat of dienst wordt overgenomen, willen we voorkomen dat andere delen van het systeem automatisch bereikbaar zijn.
We controleren identiteit en rechten bij de grenzen tussen systemen en beperken hoe ver toegang reikt. Waar het systeem en de omgeving daarom vragen, gebruiken we ook netwerkscheiding.
Zo bouwen we beveiliging in
We kiezen hosting- en identiteitsdiensten die passen bij de eisen van de klant en de bestaande systemen. Met Terraform leggen we infrastructuur vast, zodat omgevingen kunnen worden gecontroleerd en opnieuw opgebouwd. Playwright helpt ons browsertrajecten te testen. SonarQube en Qodo ondersteunen codekwaliteit en codebeoordeling. Met OWASP Dependency-Track houden we risico's van softwareonderdelen bij, Trivy gebruiken we voor regelmatige beveiligingsscans en OpenTelemetry koppelt applicatiesignalen aan monitoring en logging.
Onze aanpak volgt de principes van ISO/IEC 27001; we zijn niet gecertificeerd voor deze norm. EU-dataresidentie is de standaard voor klantoplossingen. De maatregelen die we kiezen hangen af van het systeem, de gegevens en de risico's. Lees meer op de pagina Beveiliging & vertrouwen.