Een software-audit afbakenen: welke beslissing moet het onderzoek ondersteunen?

Formuleer eerst de beslissing

Een goede startvraag is bijvoorbeeld of een klantportaal veilig kan worden uitgebreid naar een tweede organisatie, of dat een bestaande applicatie door een nieuw team kan worden beheerd. De onderzoeker kan dan relevante toegang, datagrenzen en publicatieprocessen kiezen. De vraag of de software goed is blijft te ruim om een vergelijkbare opdracht te vormen.

Beschrijf ook welke uitkomsten mogelijk zijn. Het onderzoek mag uitwijzen dat een beperkte aanpassing volstaat, dat aanvullend onderzoek nodig is of dat de voorgestelde uitbreiding voorlopig onverstandig is. Wie alleen bevestiging van een al gekozen oplossing verwacht, verkleint de praktische waarde. Spreek af wie uiteindelijk beslist en welke onzekerheden die persoon moet kunnen beoordelen.

Benoem systeem, omgeving en versie

Leg vast welke applicaties, koppelingen, codeversies en omgevingen binnen het onderzoek vallen. Een repositoryreview zegt weinig over productieconfiguratie als die niet is bekeken. Een testomgeving kan andere rechten of gegevens bevatten dan productie. Het rapport moet deze verschillen noemen, zodat conclusies niet ongemerkt naar een bredere omgeving worden vertaald.

Spreek af hoe veranderingen tijdens het onderzoek worden behandeld. Als de applicatie ondertussen een grote release krijgt, moet duidelijk blijven op welke toestand een bevinding betrekking heeft. Een beperkte controle kan een eerdere bevinding opnieuw toetsen zonder de hele audit te herhalen. Dat vraagt wel een traceerbare versie en een afgebakende test, anders wordt actueel een onduidelijk etiket.

Onderscheid waarneming, gevolg en vermoeden

Een waarneming beschrijft wat de onderzoeker daadwerkelijk heeft gezien: een foutmelding, een codepad, een ontbrekende controle of een geslaagde proef. Het gevolg legt uit waarom dat voor een bedrijfsroute relevant is. Een vermoeden benoemt wat mogelijk mis kan gaan maar nog niet is aangetoond. Die lagen horen in een bruikbaar rapport afzonderlijk terug te komen.

Stel dat een export zonder zichtbare controle kan worden gestart. Dat is niet automatisch bewijs van ongeautoriseerde toegang; misschien beschermt een eerdere stap de functie. Vraag welk deel van de route is onderzocht en welke proef nodig is om het vermoeden te bevestigen. Zo voorkom je zowel onnodige onrust als het te snel wegzetten van een belangrijk signaal.

Spreek ook af hoe bevindingen aan bewijs, gevolgen en een vervolgbesluit worden gekoppeld: Van auditbevinding naar verbetering: bewijs, prioriteit en hercontrole.

Kies steekproeven die iets verklaren

Een steekproef moet aansluiten op de onderzoeksvraag. Voor organisatiegrenzen kies je bijvoorbeeld gebruikers met verschillende rollen en records uit twee organisaties. Voor onderhoudbaarheid onderzoek je een recente wijziging en een route met veel afhankelijkheden. Een willekeurige bestandsselectie kan nuttig zijn voor verkenning, maar zegt minder over de concrete bedrijfsrisico’s.

Leg selectie en beperkingen vast. Eén correct geweigerde aanvraag bewijst niet dat iedere route dezelfde controle gebruikt. Eén trage zoekopdracht bewijst niet dat alle gebruikers hetzelfde ervaren. Vraag daarom welke vervolgsteekproef zinvol zou zijn wanneer een signaal wordt gevonden. De opdrachtgever kan dan bewust kiezen tussen een smal antwoord en extra onderzoeksdekking.

Beveiligingsonderzoek vraagt eigen afspraken

Bepaal welke controles zijn toegestaan en in welke omgeving ze mogen worden uitgevoerd. Een codebespreking, configuratiecontrole en actieve beveiligingstest zijn verschillende activiteiten. Benoem ook grenzen voor belasting, persoonsgegevens en wijziging van gegevens. Een onderzoeker moet een mogelijk schadelijke proef niet improviseren omdat een algemene auditopdracht is gegeven.

OWASP ASVS kan helpen specifieke beveiligingseisen te kiezen en te benoemen. De verwijzing naar dat kader is op zichzelf geen volledige verificatie of certificering. Vraag welke eisen daadwerkelijk zijn onderzocht, op welke manier en met welke beperkingen. Laat bevindingen over toegang of gegevensafscherming koppelen aan de betrokken gebruikersroute, zodat de technische observatie een begrijpelijke betekenis krijgt.

OWASP Application Security Verification Standard ↗

Maak prestatievragen reproduceerbaar

Vertaal langzaam naar een beschreven handeling met gegevensomvang, omgeving en waarnemingsmoment. Een scherm met honderd records stelt andere eisen dan een historische export. Vraag of de traagheid ontstaat tijdens gegevens ophalen, berekenen, verzenden of weergeven. Een algemene snelheidsbeoordeling zonder deze context maakt een vervolgvoorstel moeilijk te controleren.

Gebruik een afgesproken meetopstelling en noteer verschillen met productie. Een kleine test kan een knelpunt aanwijzen zonder een voorspelling over alle toekomstige belasting te rechtvaardigen. Spreek ook af of het onderzoek alleen de oorzaak verkent of daadwerkelijk een verbetering implementeert. Diagnostiek en optimalisatie zijn verschillende deliverables, ook wanneer ze door dezelfde ontwikkelaar worden uitgevoerd.

Google SRE: Testing for Reliability ↗

Vraag om een rapport dat tot keuzes leidt

Laat iedere belangrijke bevinding beschrijven wat is onderzocht, welk bewijs beschikbaar is, wat de zakelijke betekenis kan zijn en welke vervolgstap past. Voeg onzekerheid en afhankelijkheden toe. Een ernstlabel zonder uitleg vertelt niet of een probleem vandaag moet worden opgelost of eerst nader onderzocht.

Een bruikbare prioriteitenlijst onderscheidt directe maatregelen, aanvullend onderzoek en later planbaar werk. Benoem een eigenaar die de aanbeveling kan beoordelen. Vraag daarnaast welke bevindingen samenhangen: één oorzaak kan meerdere symptomen verklaren. Zo voorkom je dat een opdrachtgever ieder punt als losse ontwikkelopdracht behandelt en onnodig dubbel werk inkoopt.

Voorbeeld: een portaal uitbreiden

Fictief voorbeeld: een bedrijf wil zijn bestaande portaal aanbieden aan een tweede klantorganisatie. Het eerste onderzoek richt zich op de manier waarop gebruikers, bestanden en exports aan een organisatie zijn gekoppeld. Een algemene beoordeling van de hele programmeerstijl valt buiten die eerste scope.

De onderzoeker volgt twee gebruikersroutes met speciaal gemaakte testrecords. Eén exportpad blijkt een organisatiekeuze anders toe te passen dan de gewone schermen. Het rapport beschrijft het verschil, de uitgevoerde proef en de nog niet bekeken routes. Het vervolgvoorstel bevat een gerichte correctie en hercontrole. Dat is een onderbouwde stap, zonder te beweren dat na die correctie het hele portaal volledig is doorgelicht.

Leg vast hoe bevindingen worden afgesloten

Een wijziging in de code is niet automatisch een afgesloten bevinding. Spreek af welk gedrag na de correctie moet worden aangetoond, in welke omgeving en op welke versie. Neem waar relevant een controle op ongewenste neveneffecten mee. Bewaar zowel de oorspronkelijke waarneming als de uitkomst van de hercontrole.

Voor sommige punten is risicobewust accepteren een zakelijke keuze, bijvoorbeeld wanneer een beperkte functie binnenkort vervalt. Leg dan vast wie die keuze maakt, welke beperking blijft bestaan en wanneer opnieuw wordt gekeken. Een auditrapport is daarmee een beslisdocument dat kan worden bijgewerkt, in plaats van een eenmalige lijst die na oplevering zijn betekenis verliest.

Van uitleg naar een concrete projectkeuze

Leg je aannames, open vragen en oplevercriteria vast in de bijbehorende tool. Gebruik de dienstengidsen om uitvoering en afbakening te bespreken.

• Legacy Software Moderniseren ↗
• Software Audit ↗

Vragen over dit onderwerp

Verder met een aansluitende vraag