Wat als jouw externe ontwikkelaar je niet toestaat om de code van een applicatie met ons te delen voor een pentest, zelfs als de applicatie speciaal voor jou is gemaakt? Dit is problematisch. Het dwingt je om genoegen te nemen met een minder effectieve test van je applicatie: een waarbij leveranciers de code niet kunnen bekijken terwijl we de pentest uitvoeren.
Hoe kun je voorkomen dat dit jou overkomt?
In deze korte blog zal ik drie onderwerpen bespreken die relevant zijn in het kader van pentesten wanneer een externe partij jouw applicatie ontwikkelt: eigendom, audits en beveiligingseisen.
Het beste moment om over deze onderwerpen na te denken is voordat je een project in gang zet. Daarna wordt het lastiger, omdat het wijzigen van de voorwaarden van een contract nodig kan zijn. En het spreekt voor zich dat je deze punten eerst met je juridisch adviseur moet bespreken.
Eigendom
De beste optie is om ervoor te zorgen dat je de daadwerkelijke eigenaar wordt van de code voor alle software die je laat ontwikkelen. Eigenaarschap betekent dat je volledige controle hebt wat betekent dat je geen toestemming nodig hebt om de code met een derde partij te delen.
Een bezwaar dat je van je externe ontwikkelaar kunt horen, is dat terwijl sommige van hun code specifiek voor jou wordt gemaakt, andere code gedeelde code is die ze voor meerdere klanten gebruiken, en dat je daarom geen eigendom kunt krijgen. Dit kan natuurlijk het geval zijn. Als reactie hierop kun je om gedeeltelijk eigendom vragen. Dit kan echter moeilijk zijn, omdat het vereist dat iemand aan de kant van je leverancier beslist wat "jouw" code is en wat niet. Maar het is de moeite waard om het te proberen. Voor alles waarvan je echt geen eigendom kunt krijgen, heb je rechten nodig om audits uit te voeren of inzicht te krijgen in auditresultaten.
Weet, dat eigendom van de code meer voordelen heeft dan alleen de controle hebben over pentests. Dus zelfs als je inzicht krijgt in de kwaliteit van je applicatie op andere manieren dan een pentest, is het nog steeds de moeite waard om eigendom veilig te stellen.
Audits
Als je geen eigendom van de code kunt krijgen, moet je alternatieve manieren kijken om inzicht te krijgen in de kwaliteit van je applicatie. Eén manier is het veiligstellen van het recht om de code te laten auditen. Het hebben van auditrechten betekent dat je, ook al bezit je de applicatie niet, kunt beslissen om de applicatie te laten auditen. Zorg ervoor dat je van tevoren bespreekt hoe dit in de praktijk zal werken: ontvang je de code van je ontwikkelaar om deze vervolgens te delen met je pentest-provider (onder de juiste geheimhoudingsovereenkomsten), of deelt je ontwikkelaar de applicatiecode rechtstreeks met je pentest-provider? In beide scenario's moet je tot de directe ontvangers van het auditrapport behoren.
Het kan zijn dat je ontwikkelaar je vertelt dat al hun applicaties al worden geauditeerd. In dat geval kun je besluiten dat de auditrechten niet nodig zijn. Zorg er dan voor dat de audits worden uitgevoerd door een externe partij en weet wanneer ze worden uitgevoerd. Zorg er daarnaast voor dat je applicatieontwikkelaar de onbewerkte auditrapporten met je deelt zodat je inzicht krijgt in de kwaliteit van je applicatie.
Beveiligingseisen
In alle gevallen moet je de beveiligingseisen voor je applicatie aan je externe ontwikkelaar verstrekken, ongeacht de methode die je gebruikt om inzicht te krijgen in de kwaliteit en bijbehorende risico's van de applicatie die jouw leverancier voor je zal bouwen. De Application Security Verification Standard (ASVS) (https://owasp.org/www-project-application-security-verification-standard/) is een goed startpunt om je eisen te definiëren. ASVS is een uitgebreid raamwerk van beveiligingscontroles en het definieert van tevoren drie beveiligingsverificatieniveaus om uit te kiezen. Bij het stellen van eisen kun je een van de drie vooraf gedefinieerde niveaus kiezen die overeenkomt met het zekerheidsniveau dat je zoekt.
Samenvattend
Als je een applicatie laat bouwen door een externe ontwikkelaar, moet je in staat zijn om de risico's die gepaard gaan met het eindproduct te begrijpen. De beste manier is om iemand de resulterende product te laten auditen of testen met toegang tot de code. Bespreek aan het begin van het project, tijdens de contractfase, de onderwerpen van beveiligingseisen, audits en eigendom met je juridisch adviseur en je opdrachtgever. Zo voorkom je mogelijke frustratie op een later moment in het project.