De Secure Programming Council heeft een concept van exameneisen online gezet waarmee bedrijven de kennis over veilig programmeren in Java en JavaEE bij hun softwareontwikkelaars kunnen toetsen.
In een later stadium volgen exameneisen voor C, C++, Php, Perl en .NET-talen. Doel van de toetsing is om bedrijven zekerheid te verschaffen dat hun programmeurs de basiskennis en de vaardigheid hebben om veilige code af te leveren. Daarmee moet het aantal bugs die hackers eenvoudig kunnen misbruiken, verminderd worden.
De Secure Programming Council heeft de komende twee maanden uitgetrokken voor inspraak op het concept. In de voorgestelde exameneisen komen basisconcepten als data handling, authenticatie, sessiemanagement en toegangscontrole aan bod. Zo moet een Java-programmeur in staat zijn om externe data op een betrouwbare manier te valideren en te verwerken. Ook wordt kennis vereist over veelgebruikte aanvalsconcepten van hackers, zoals cross-site scripting en sql-injecties, en de programmeur moet het nodige weten over verschillende encryptiemethoden.
In totaal hebben veertig bedrijven en overheidsinstellingen meegeholpen om de exameneisen van de Secure Programming Council op te stellen. Vooral vanuit de financiële wereld en het defensieapparaat zou de vraag naar dergelijke examens groot zijn. Een financiële instelling zou al hebben aangegeven dat al zijn softwareontwikkelaars het examen moeten doen. Programmeurs die niet slagen, mogen ‘geen enkele regel code’ meer schrijven.
De eerste examens bij het Sans-Institute staan al voor volgende maand in Londen op het programma. In een latere fase moeten de tests ook in andere Europese en Amerikaanse steden aangeboden worden. Een examen kost 50 dollar voor een student en maximaal 450 dollar voor werknemers van grote bedrijven.
Veiligheid komt niet door goed programmeren, maar door goed testen. Zinloze CV vuller.
Ik heb een dubbel gevoel bij deze ontwikkeling.
Het is natuurlijk goed om ontwikkelaars op te leiden zodat ze meer kennis bezitten m.n.t. het ontwikkelen van veilige software. Het certificaat is daarmee een beloning voor de investering, aangezien het de marktwaarde van de ontwikkelaar vergroot.
Aan de andere kant is dit op geen enkele manier een garantie dat de software die gecertificeerde ontwikkelaars maken ook werkelijk veilig is.
De verantwoordelijkheid voor voor kwaliteit en veiligheid van software kan niet enkel en alleen bij ontwikkelaars liggen. De veiligheid van software moet in een Quality Assurance-proces vortdurend getoetst worden. In geen enkele andere sector wordt het toetsen van de kwaliteit van werk aan de uitvoerder overgelaten. Denk aan de accountant die een boekhouder controleerd, of een bouwinspecteur die een bouwvakker controleert. Er is niet voor niets deze scheiding, omdat de uitvoerder ook aan andere krachten (zoals deadlines en werkomstandigheden) onderhevig zijn waarop zijn vaak geen invloed hebben.
Daarnaast is het ook zo dat in veel sectoren waar kwaliteit en veiligheid van groot belang wordt geacht de wetgever een rol speelt in het QA-proces. In de bouwsector zijn er veel normen en regels waaraan voldaan moet worden en die ook duidelijk controleerbaar zijn. In de accountancy zijn er strakke boekhoudregels die de laatste jaren alleen maar verder zijn aangescherpt. In de ICT is er nauwelijks tot geen wetgeving, terwijl er wel veel belangen (financieel, privacy, nationale veiligheid, in de medische wereld zelfs levens) van afhangen. Dit heeft als gevolg dat zowel opdrachtgever als leverancier onder de druk van marktwerking soms zelfs de meest basale maatregelen om kwaliteit van software te waarborgen overboord gooien, met soms grote gevolgen.
Kennis van hoe je veilige software kan bouwen is randvoorwaarde voor het bouwen van veilige software. Dit certificaat kan echter een wassen neus blijken te zijn wanneer er ook niet op andere vlakken randvoorwaarden gecreeerd, gecontroleerd en wellicht wettelijk afgedwongen worden.