Shift-links voor veiligheidscontroles, ja of nee?

De Crowdstrike-storing van een paar weken geleden ligt nog vers in het geheugen. Een wereldwijde chaos veroorzaakt door één foutieve update. Als we denken aan de ontwikkeling van nieuwe software, lijken de termen kwaliteitsgarantie en beveiliging nog steeds tot verschillende werelden te behoren. Maar is dat wel nodig? Misschien was dit een deel van het probleem dat de oorzaak was. Moeten we onze beveiliging integreren in onze QA-processen of is het gewoon een klasse apart? Met andere woorden, moet beveiliging ook naar links verschuiven?

Ons QA-brein ging van: “Beveiliging integreren met QA?”

Net zoals overmatige blootstelling aan UV-straling kan leiden tot huidkanker, kan onvoldoende beveiliging van uw digitale systemen ernstige schade toebrengen aan je bedrijf. Het toepassen van het shift-links principe voor cyberbeveiliging helpt om beveiligingsrisico’s vroegtijdig te identificeren. Traditioneel wachten bedrijven tot de website/applicatie live is voordat ze controleren op beveiligingsproblemen. Helaas is dit net zoiets als zonnebrandcrème smeren nadat je al een uur in de zon hebt gezeten; het helpt, maar het blijft pijn doen.

Beveiligingscontroles opnemen in QA kan verschillende voordelen hebben:

1. Allesomvattende kwaliteit
   Wanneer we naar kwaliteit kijken, moeten we de helikopterview hebben om verder te kijken dan alleen functionaliteit. In die visie maakt een veilig product deel uit van wat software echt van hoge kwaliteit maakt.
2. Vroegtijdige detectie van beveiligingsproblemen
   Kleine problemen blijven klein voordat ze groot kunnen worden. Het is veel goedkoper om beveiligingsfouten in een vroeg stadium van de SDLC op te lossen dan tijdens de productie. Dit bespaart tijd en geld.
3. Gebruikersvertrouwen opbouwen
   Door ervoor te zorgen dat beveiliging een kernonderdeel is van je kwaliteitsborgingsproces, bouw je vertrouwen op bij je gebruikers. Vertrouwen helpt je reputatie als bedrijf, wat je relatie met klanten ten goede komt.
4. Gestroomlijnde processen
   In plaats van aparte fasen voor beveiliging en kwaliteitscontroles, bespaar je tijd en middelen door ze te combineren. Dit maakt het ontwikkelingsproces efficiënter.

Ons veiligheidsbrein ging van: “Wacht even…”

Naast deze redenen zijn er nog andere argumenten om beveiligingstesten als een aparte discipline te beschouwen.

1. Gespecialiseerde expertise
   Beveiligingstesten vereisen gespecialiseerde vaardigheden die QA-professionals niet volledig kunnen bezitten. Het gebied van cyberbeveiliging is voortdurend in ontwikkeling, met dagelijks nieuwe bedreigingen en kwetsbaarheden. Om deze bij te houden, moet je voortdurend leren en je specialiseren.
2. Toewijzing van middelen
   Beveiligingstests omvatten vaak meer gedetailleerde en tijdrovende procedures dan functionele tests. Het combineren van de twee kan leiden tot langere testcycli en hogere kosten.

1. Verschillende doelstellingen
   QA en beveiligingstesten hebben verschillende primaire doelstellingen. QA richt zich op het verzekeren dat de software voldoet aan de gespecificeerde functionele eisen en goed presteert, terwijl beveiligingstesten zich bezighouden met het identificeren en beperken van mogelijke kwetsbaarheden. Ook de methodologieën en benaderingen kunnen verschillen.
2. Risicobeheer
   Door beveiliging gescheiden te houden, kunnen organisaties ervoor zorgen dat beveiligingsbeoordelingen onbevooroordeeld zijn en niet worden beïnvloed door hetzelfde team dat verantwoordelijk is voor de ontwikkeling en functionaliteit van de software.
3. Regelgeving en compliance-eisen
   Bepaalde industrieën hebben wettelijke vereisten. Dit betekent dat voor deze branches en bedrijven het integreren van beveiliging in QA niet voldoet aan deze wettelijke vereisten. In andere gevallen hebben organisaties een auditspoor nodig om aan regelgevers en auditors te bewijzen dat er uitgebreide beveiligingstests zijn uitgevoerd.

Laat QA en cyberbeveiliging elkaar ontmoeten in het midden

Stel dat je een van die 99% bedrijven bent die niet in elk team een beveiligingsexpert heeft. Er zijn misschien een paar praktische, niet-technische stappen die je toch kunnen helpen om de lat van je beveiligingsniveau binnen je QA-proces hoger te leggen:

1. Train je team in de basisprincipes van beveiliging
   Zorg ervoor dat iedereen in je team de basisprincipes van softwarebeveiliging begrijpt. Je hoeft niet van iedereen beveiligingsexperts te maken, maar met een fundamenteel begrip van veelvoorkomende bedreigingen en best practices kom je al een heel eind.
2. Gebruik (geautomatiseerde) beveiligingstools
   Er zijn veel gebruiksvriendelijke beveiligingstools beschikbaar die kunnen worden geïntegreerd in je QA-proces. Scan je code automatisch op mogelijke kwetsbaarheden zonder dat je diepgaande beveiligingsexpertise nodig hebt.
3. Werk samen met beveiligingsexperts
   Werk samen met beveiligingsexperts die begeleiding en ondersteuning kunnen bieden. Dit kan een intern beveiligingsteam zijn of externe consultants die kunnen helpen bij het integreren van beveiligingspraktijken in je QA proces.
4. Neem beveiliging op in je QA checklist
   Maak beveiliging een standaard onderdeel van de QA checklist. Zorg ervoor dat beveiligingsoverwegingen worden opgenomen in elke fase van je testproces, van planning tot uitvoering.

Conclusie

In een ideale wereld krijgen zowel QA als beveiligingstesten de aandacht en expertise die ze nodig hebben. Helaas leven de meeste bedrijven niet in een ideale wereld met onbeperkte middelen en tijd. Dus is het een onmogelijke taak om alles te testen.

En hoewel het combineren van QA en beveiliging een goed idee lijkt, kan het maar tot een bepaald punt. Elk gebied heeft zijn eigen expertise en verdient zijn eigen respect. Ons advies? Maak beveiliging een aandachtspunt voor alle mensen in de organisatie. Als QA snelle beveiligingswinst kan boeken door geautomatiseerde controles aan hun pipeline toe te voegen, waarom zou je het dan niet doen?