Development

Juridische zaken
Approved

De prijs van softwaremissers

Wie is verantwoordelijk voor de kwaliteit van software?

© CC0 - Pixabay OpenClipart
17 oktober 2017

Wie is verantwoordelijk voor de kwaliteit van software?

Digitalisering, robotisering, Internet of Things, autonome voertuigen; software heeft een groeiende invloed op de economie en het maatschappelijk leven. Echter, door de roep van klanten om functionaliteit en een snelle time to market, komt bij de ontwikkelaars de aandacht voor kwaliteit in het gedrang. Daarmee dient zich de vraag op: wie is verantwoordelijk voor de kwaliteit?

Jeff Moss, de initiator van de Black Hat-beveiligingsconferenties, en IT-beveiligingsgoeroe Bruce Schneier pleiten al langer voor meer aansprakelijkheid bij de softwarebouwers. In veel gevallen verschuilen leveranciers zich nu veel te veel achter de End User License Agreement (EULA), claimen zij.

Daarin wordt veel van de aansprakelijkheid afgewenteld op de afnemer. En waar er wel sprake is van aansprakelijkheid, is vaak de aanschafprijs of de contractwaarde het maximum dat de leverancier wil uit- be­talen bij schade. De motivatie bij de producent om maximaal haalbare kwaliteit te leveren, wordt daardoor  niet geprikkeld. Menno Weij van SOLV Advocaten treedt in de rechtbank regelmatig op als raadsheer voor leveranciers. Hij maakt een duidelijk onderscheid tussen business to consumer (B2C) en business to business (B2B).

  • Het consumentenrecht regelt veel in B2C-zaken. Toch heeft software nog steeds een onduidelijke positie in het consumentenrecht, omdat je formeel software niet koopt maar er een licentie op krijgt. De wet zou daarop aangepast moeten worden.
  • In de B2B-sfeer komt het op de contractonderhandeling aan. Het Nederlands recht schrijft voor dat je in de contractfase over en weer een zorg- en informatieplicht hebt.  De opdrachtgever moet voldoende informatie geven en de opdrachtnemer moet voldoende vragen stellen.  Er geldt daarbij een grote mate van contractvrijheid.  

Weij: “Wat ik lastig vind is bijvoorbeeld het mislukken van het project Gemeentelijke Basis Administratie. Na 10 jaar moet de minister de stekker eruit trekken omdat het project nergens toe leidt.  De COO van een niet al te kleine softwareleverancier zegt dan ‘wij hadden alleen een inspanningsverplichting’ en  ‘de overheid had ons maar beter moeten aansturen’. Daar heb ik vanuit ethisch perspectief wel moeite mee.” Niet voor niks zijn de afspraken tussen opdrachtgever en opdrachtnemer vaak het punt waar het mis gaat.

Aansprakelijkheid bij open source

Het gebruik van opensourcesoftware is veelal gratis. De kwaliteit zou hoog moeten zijn omdat vele ogen onafhankelijk van elkaar kunnen kijken naar de code en verbeteringen voorstellen. Dat het soms akelig mis kan gaan bleek wel met de OpenSSL- (Heartbleed en POODLE) en Shellshock-problematiek. Grote financiële organisaties gebruikten de opensourcecode.

Wie is in zo’n geval aansprakelijk? Menno Weij van SOLV Advocaten zegt dat het voor de aansprakelijkheid niet uitmaakt of je van een opensourcelicentie gebruik maakt of van een closedsourcelicentie. Bij een closedsourcelicentie weet je echter met wie een contract hebt gesloten en wie je moet benaderen met een claim. Bij open source ligt dat veel lastiger door het grote aantal onafhankelijke ontwikkelaars dat werkt aan zo’n project. Bovendien zou het individueel aansprakelijk stellen van een lid van de opensourcegemeenschap kunnen betekenen dat de hele opensourcebeweging ineen klapt uit angst voor een grote financiële strop als gevolg van een kleine misser. De huidige opensourcelicenties zitten dan ook vol met disclaimers.

Weij ziet daar een rol voor de opensourceorganisaties zoals de Free Software Foundation. Die zou de aansprakelijkheid kunnen overnemen tegen een vergoeding voor een lidmaatschap. De organisatie zou zich dan op zijn beurt kunnen verzekeren tegen al te grote claims.

Uit onderzoek van Hans Mulder, hoogleraar aan de Antwerp Management School, naar mislukte softwareprojecten bij overheidsinstellingen en bedrijven, blijkt dat in minder dan 10 procent van de gevallen de technologie het probleem is. De technische standaard is dus best al hoog.  Het gaat mis bij het inzichtelijk maken van wat de opdrachtgever wil en dat vastleggen in afspraken met de opdrachtnemer – niet alleen wat betreft functionaliteit, ook wat betreft kwaliteit en veiligheid. Dit leidt tot een ‘prisoners dillema’, stelt Rob van de Veer van de Software Improvement Group (SIG). “Eigenlijk zou elke softwareleverancier moeten zeggen: ‘Als je kwaliteit wil, moet je duidelijk maken wat je daarmee bedoelt. Als je dat niet doet, kan ik je niks garanderen over kwaliteit.’ Het probleem is dat geen enkele leverancier dat doet, een enkele uitzondering daargelaten. Want eigenlijk zeg je dan tegen je klant: ‘Als je me niet vertelt welk kwaliteitsniveau je wilt, krijg je rommel.’ Daarmee prijs je jezelf uit de markt.”

Dialoog als oplossing

Pas wanneer de hele markt komt tot een gemeenschappelijk idee over wat kwaliteit wordt verstaan, kan een goede dialoog tussen opdrachtgever en opdrachtnemer ontstaan. Zo ver is het nog lang niet. Het gevolg is verkeerde aannames, onduidelijkheid, vage eisen en onterechte eisen. De leverancier laat het erop aankomen en zegt als het mis gaat: ‘Dan had je maar duidelijker moeten specificeren.’

Volgens Van der Veer is er wel hoop. Zo is er het initiatief van het Centrum informatiebeveiliging en privacybescherming (CIP) genaamd Grip on Secure Software Development (Grip on SSD). Het initiatief heeft tot doel opdrachtgevers handvatten te bieden om goed na te denken over wat de risico’s zijn en hoe je dat inzicht in je opdracht verwerkt.  Grip op SSD is gebaseerd op best practices en industriestandaarden. Van der Veer: “Het is een briljant voorbeeld van een breed gedragen werkwijze in overheidsland en de grote system integrators, Capgemini, Sogeti en CGI. Het komt erop neer dat we een gemeenschappelijke taal gaan spreken  als het op security aankomt. We weten dan waar we over praten en we kunnen ervaringen uitwisselen.”  Volgens Van der Veer is het een succes omdat partijen hebben moeten tekenen om deel te kunnen nemen. Ze committeren zich aan een aantal uitgangspunten en eisen in de processen. Het is mogelijk om af te wijken, maar dan moet je ook uitleggen waarom. De anderen kunnen dan beoordelen waarom een opdrachtgever kiest voor risicomethode y en niet voor methode x.  

Professionaliteit en toeval

Het streven is nu Grip op SSD breder te trekken dan alleen de overheid. Het probleem is dat er zo veel standaarden zijn op het gebied van kwaliteit en beveiliging. Je hebt die van OWASP, NIST, SANS, BIR, BIG PCI DSS en meer. Dat maakt het voor bedrijven  die de kwaliteit willen specificeren  lastig door de bomen het bos te zien.  Als je op internet gaat zoeken en profes­sionals vraagt, krijg je steeds weer andere antwoorden. Er moet dus een consolidatieslag komen. Vooral omdat functioneel specificeren al lastig is, maar specificeren op non-functioneel vlak nog veel  moeilijker is.  Van der Veer: “Je kan 100.000 manieren bedenken om in te breken in een systeem en je kan 200.000 manieren bedenken om fouten te maken. De enige manier  om dat aan te pakken, is te omschrijven welke fouten er niet gemaakt mogen worden. Dat is onmogelijk. Dus moeten de belangrijkste zaken worden gespeci­ficeerd en de rest berust toch op de professionaliteit van de ontwikkelaar  en misschien ook het toeval.” Van de Veer schetst een voorbeeld.  “Je stelt twintig eisen aan de manier waarop een verbinding tussen twee systemen moet worden gelegd. Maar de ontwikkelaar denkt te goeder trouw:  ‘Het gaat me niet snel genoeg dus bouw ik een cache in.’ Vervolgens vergeet hij ervoor te zorgen dat die cache geleegd wordt. Dat is niet handig, maar het legen van de betreffende cache stond niet in de eisen. Is de ontwikkelaar dan aansprakelijk? Heeft hij niet zijn best gedaan? Dat blijft lastig.”  

Als je me niet vertelt welk  kwaliteitsniveau  je wilt, krijg je rommel.

Testen, Tools, Code Review

Afspraken maken over de kwaliteit is de eerste stap, aansprakelijkheid de laatste. Eigenlijk zou het niet zo ver moeten komen. Daartussen zitten immers de stappen waar het op aankomt: het ontwerpen, schrijven, testen en controleren van  de code. Inmiddels zijn ontwikkelaars voorzien van een hele gereedschapskist vol testtools om  te beoordelen of wat ze aan code hebben geproduceerd ook voldoet aan de standaarden. Geautomatiseerd testen krijgt een steeds belangrijker rol. Juist nu de agile ontwikkelingsmethoden bij steeds meer organisaties de standaard wordt, neemt de druk op snelheid en efficiëntie toe. De aandacht ligt vooral op functionaliteit en time to market, niet op maximale kwaliteit. Bovendien voelen traditionele testers zich vaak niet op hun plek als lid van een Scrum- of  DevOpsteam, zoals onlangs bleek uit het World Quality Report 2017 van Sogeti, CapGemini  en Micro Focus. Een oplossing ligt in de inzet  van artificiële intelligentie (AI) bij het testen.

AI-tools blijken veel sneller, efficiënter en grondiger penetratietests (pentests) te kunnen uitvoeren  dan een team hackers. Dat betekent overigens niet dat de humane testers buiten spel komen te staan, zegt softwaretest-expert Tom van de Ven van Sogeti. Hun taken komen op een hoger niveau te liggen, bijvoorbeeld het analyseren  van de geaggregeerde data die de verschillende geautomatiseerde testtools genereren (dashboarding).

Tools blijven bovendien altijd beperkingen houden, zegt Rob van de Veer van de Software Improvement Group (SIG). Tools geven zowel false positives als false negatives. Uiteindelijk moet er ook een code review plaatsvinden. Dat kan door ontwikkelaars elkaars code te laten nalopen (peer review). Dat is een goedkope manier en bovendien goed om elkaar scherp te houden en te weten hoe teamleden te werk gaan.  “Maar peer review is ook lastig. Ontwikkelaars beschouwen hun code toch als hun kindje en daar gaat een collega kritiek op hebben. Het doen van een code review moet je ook leuk  vinden. In praktijk is de waarde ervan dus beperkt”, zegt Van der Veer. Een code review door een externe partij is  duur, maar heeft als voordeel dat er op een  onafhankelijke manier naar wordt gekeken.  “Als wij worden ingehuurd om een code review te doen, proberen we geen waardeoordeel  te koppelen aan onze bevindingen.  Ook onderbouwen en valideren we onze  analyse. Wij kunnen de teamleiding laten zien dat het belangrijk is meer tijd te reserveren voor de kwaliteitsborging. Dat vinden ontwikkelaars  fijn omdat ze zo meer ruimte krijgen om hun vakmanschap uit te oefenen. Het leveren van ondeugdelijke code is immers niet het gevolg van onwil van ontwikkelaars. Iedere ontwikkelaar heeft blinde vlekken. Het gaat er om daar aandacht aan te besteden, met tools, peer review  of een externe review.”

Lees meer over Development OP AG Intelligence
Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.