Keurmerk voor veilige programmeurs in de maak

De Secure Programming Council heeft een concept van exameneisen online gezet waarmee bedrijven de kennis over veilig programmeren in Java en JavaEE bij hun software-ontwikkelaars 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. Met name vanuit de financiële wereld en het defensie-apparaat zou de vraag naar dergelijke examens groot zijn. Een financiële instelling zou al hebben aangegeven dat al zijn software-ontwikkelaars het examen moeten doen. Programmeurs die niet slagen, zouden 'geen enkele regel code' meer mogen 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.

Reacties (81)

[machuidel]

Ik begrijp echt niet waarom men per definitie al meteen zoveel waarde aan zo een certificaat / keurmerk hecht (ik hoor de managers al praten straks). Hoor namelijk mensen nu al praten over dat dit de oplossing is voor het tegengaan van slechte programmeurs. Helaas denk ik dat je hiermee de slechte programmeurs er juist niet uitfiltert omdat ze alles letterlijk gaan leren zoals het in een boek staat (afkortingen, functienamen) en voor een groot deel niet weten hoe en waarom. Misschien filter je zo juist de echte goede programmeurs eruit

Zoals ik het lees lijkt het erop dat de examen specifiek op een gekozen taal gaat testen. Waar gaat het mij op testen als ik bijv. voor C kies. Dat ik de functie "snprintf" moet gebruiken in plaats van "sprintf"? Of dat ik mijn eigen implementatie van "snprintf" kan schrijven? Maar waarom?

Als iemand echt weet hoe een computer in elkaar steekt en hoe er met informatie om moet worden gegaan gaat men vanzelf wel op zoek naar de juiste manier en is taal specifieke kennis (naar mijn mening en ervaring) niet nodig.

Zelf programmeer ik meerdere programmeertalen waaronder C, C++, PHP, Perl, Scheme en Python. Geef les aan mensen over veilig programmeren. Doe code audits. Moet ik nu voor het doen van een examen voor een taal dat ik nu alweer een jaar niet heb geprogrammeerd alle Perl functies uit mijn hoofd gaan leren terwijl dat (volgens mij) niet is waar het om gaat?

Bijv. toen ik begon met Linux bestonden er nog geen certificaten voor, laat staan dat zelfs de grootste computer professionals die ik tegenkwam het kende (banen waren er ook niet voor). Plots toen Linux bekender begon te worden (voornamelijk Redhat) gingen bedrijven certificaten eisen. Moest ik opeens allemaal Redhat specifieke dingen kennen terwijl ik Slackware en Debian gebruikte. Moest ik weten dat Joe een teksteditor is die het meest op Notepad in Windows lijkt. Waar is / was dat nou weer voor nodig. Ben er dus niet meer mee verder gegaan. Net alsof ik zelf niet binnen een paar seconden uit kan vinden hoe ik een RPM package kan installeren zonder het eerst uit mijn hoofd te leren. Betekent dit dan dat ik formeel niet voldoende Linux kennis heb?


Update:
Men zegt dat werkdruk vaak de oorzaak is voor slechte code. Zelf vind ik een programmeur die dit toelaat geen goede programmeur. Het afleveren van goede code hoeft naar mijn mening niet meer tijd te kosten. Het afleveren van slechte code staat voor mij gelijk aan het niet halen van de milestone.

[Reactie gewijzigd door machuidel op 25 juli 2024 17:34]

[J.J.J. Bokma]

Helemaal eens met wat je in je update schrijft.

Verder, in elk beroep is er slechts een heel klein percentage dat daadwerkelijk er kaas van gegeten heeft, de rest is (helaas) aan het prutsen. Dat haal je niet weg met een certificaat, want zo'n certificaat kan niet ineens het merendeel als ongeschikt gaan aanmerken. Kortom, het riekt naar geldklopperij met 0 aan toegevoegde waarde.

[Laurens-R]

Laten we dan wel aannemen dat de architect wel z'n werk goed heeft gedaan. Als die het verkeerd doet, ontstaan er ook (indirecte) veiligheids risico's. Een slecht ontwerp heeft vaak ook slechte code als gevolg, omdat de programmeur zich in allerlei rare bochten moet wringen om de boel toch werkend te krijgen...

[Verwijderd]

Gezien de voorbeelden ziet het er uit alsof het iets voor web programmeurs is. Tja, in die hoek zitten inderdaad veel knoeiers. Als je aan embedded software werkt zal deze cursus wel niet echt relevant zijn denk ik.

[OddesE]

Die 'knoeiers' opereren dan ook wel in een heel frequent aangevallen segment he. Hoe vaak probeert iemand 'in te breken' in de boordcomputer van je auto? Websites aanvallen is de hobby van velen en bovendien zitter er ook de nodige zwakheden in de onderliggende protocollen. Zo is secure login bij HTTP er als afterthought aan toegevoegd, waardoor elke website hier andere systemen voor heeft. Als iedereen zijn eigen login systeem moet programmeren is het logisch dat er meer problemen ontstaan he.

[BCC]

Steeds meer embedded spul heeft tegenwoordig een UTP aansluiting..

[Verwijderd]

Waar denk ik wel voor gewaakt moet worden is dat een dergelijk examen (en let op : straks bijbehorende opleiding) absoluut geen garantie is voor veilige code en die status mag het dan ook niet krijgen. Als een kandidaat het examen met succes aflegt zal dan bewijzen dat hij/zij weet hoe je 'veilige' code schrijft, maar dat zegt absoluut niet dat hij/zij dat dan ook in jouw bedrijf gaat doen !
Waar ik dan meer heil in zie is collective code auditing bij oplevering.

[Verwijderd]

Inderdaad iemand die slaagt in dit examen zal daarom nog geen veilige code schrijven voor het bedrijf. Maar (en ik vermoed dat het de bedrijven hier eerder om gaat) iemand die niet slaagt in dit examen zal hoogstwaarschijnlijk ook geen veilige code schrijven voor het bedrijf.

Zoiets in de aard van. "Als A dan niet automatisch B" maar "Als niet A dan wel automatisch niet B".

[Niemand_Anders]

Leuk initiatief, maar zal weinig bijdrage aan veiligere programma's. Elke programmeur weet al hij hij externe input moet valideren voordat er mee gewerkt wordt. Dat wordt je op elke programmeer opleiding/cursus gezegd.

Echter in de praktijk, meestal nadat een aantal milestones zijn gemist en er dus extra druk op de programmeurs ligt om het programma toch op tijd af te krijgen, wordt er minder aandacht besteed aan validatie, sql injection en andere 'simpele' hacks.

Beter maken ze een keurmerk voor de planners. Want als milestone 1 met 1 week wordt vertraagd, wordt helaas zelden de rest van de milestones opgeschoven. Bij planningen wordt ook zelden rekening gehouden met ziekte verzuim. Hoeveel planners ken jij welke 4 man uur per week reserveert voor onvoorziene zaken?

Wij gebruiken sinds januari een andere planning. Een fulltime (40 uur) programmeur mag per week maximaal 32 uur op projecten worden gezet, 4 uur is er voor onvoorziene zaken en 4 uur (vrijdag middag) gebruiken wij voor presentaties en code review. Sindsdien hebben wij geen milestone meer gemist en ook het aantal bugs is erg verminderd.

Druk en (te) weinig toezicht zijn de grootste veroorzakers van onveilige code, niet dat een programmeur niet weet hoe hij veilige code moet schrijven.

[mjtdevries]

Elke programmeur weet al hij hij externe input moet valideren voordat er mee gewerkt wordt. Dat wordt je op elke programmeer opleiding/cursus gezegd.

Is jou wel eens verteld dat je een hopeloze optimist bent?

Milestones worden niet gemist omdat een programmeur netjes de input valideert. Dat kost namelijk niet veel extra werk. (En zeker niet bij grote projecten)


Dat programmeurs het niet doen komt door laksheid en gebrek aan kennis.

Maar gebruik aan tijd is natuurlijk een lekker makkelijke smoes!

[OddesE]

Nee hoor, de input valideren is niet veel werk... Dat ligt er maar net aan in welke taal je werkt, wat de constraints zijn waartegen je moet valideren, welke libraries je daarvoor ter beschikking hebt etc.

Probeer maar eens een validatie voor een e-mail adres te schrijven... dan kom je er wel achter...

[Emmef]

Voordat je een certificaat als dit haalt, zou je eerst een robuustheids certificaat moeten halen. Ik ken zoveel mensen die prima een algoritme kunnen bedenken maar totaal geen besef hebben wat voor pitfalls er verder nog zijn. Die er vanuitgaan dat alle zichtbare code alleen maar wordt aangeroepen volgens jouw specificaties. (Oh: was die code zichtbaar dan?)
NOT! Zelfs jouw eigen collega's misbruiken je code en later als jij je eigen code gebruikt zul je die ook soms misbruiken (al is het maar per ongeluk).
Ik noem maar de bekende buffer overflows, maar ook concurrency gerelateerde zaken, visibility, immutablilty. Met een doorgewinterde kennis van al die zaken kun je al zoveel veiliger code schrijven.

En als toevoeging kan je dan uiteindelijk ook de wijde buitenwereld in en je communicatie voorzien van validatie en encryptie.

[elmuerte]

Wat een bullshit. Dit geeft weer goed weer wat er voor enorm misplaatst vertrouwen is in keurmerken. En het is ook niets anders dan een probleem oplossen op de verkeerde plek, sterker nog, het lost helemaal niks op. Je moet programmeurs niet toetsen, je moet hun output (e.g. programmas) toetsen.

[Blackbird-ce]

Je hebt gelijk: als ik een kinderfeestje organiseer gooi ik ook alle kinderen zo het zwembad in. Wie wil er nu eerst weten dat het kind heeft bewezen te kunnen zwemmen?

Dit is een extra'tje. Natuurlijk moet je alsnog een beveiligingstest uitvoeren op de opgeleverde programmatuur, net zoals je functionaliteit wilt toetsen en vele andere dingen. Het papiertje geeft geen garantie (net zoals een kind mét zwemdiploma nog steeds kan verzuipen), maar wél een stukje meer vertrouwen dát er over nagedacht wordt.

[Roland684]

Dus het kind dat ooit net zijn zwemdiploma heeft weten te halen (hij kent de theorie) en verder nooit water gezien heeft, gooi je vol vertrouwen in het zwembad en een kind dat kan zwemmen als een waterrat, maar nooit het papiertje is wezen halen, mag zijn kleren aanhouden?

En dan nog, iedereen kent de verkeersregels, maar niet iedereen houdt zich er aan.

Zo'n certificaat is leuk voor je CV, verder niet.

[Corrit]

Dus het kind dat ooit net zijn zwemdiploma heeft weten te halen (hij kent de theorie) en verder nooit water gezien heeft, gooi je vol vertrouwen in het zwembad

Om het even in de goede context te gooien: Het lijkt me sterk dat je ooit een "programmeur" zult aannemen die nog geen regel code heeft geproduceerd.

Als de persoon in kwestie gewoon een goede programmeur is zal hij dit diploma ook wel kunnen halen, en een diploma blijft natuurlijk een makkelijke methode om een bepaald basisniveau te kunnen garanderen, en de slechte programmeurs er uit te plukken.

[ReLexEd]

Om het even in de goede context te gooien: Het lijkt me sterk dat je ooit een "programmeur" zult aannemen die nog geen regel code heeft geproduceerd.

Klopt... dan neem je geen programmeur aan, maar een consultant... (Sorry, kon het niet laten )

[Blackbird-ce]

Het gaat erom dat degene met het papiertje iets heeft aangetoond, diegene zonder papiertje wellicht niet. Dat kind dat kan zwemmen maar geen diploma heeft, gooi je niet met een gerust hart het water in als je die nog nooit eerder hebt zien zwemmen (of een vertrouwd persoon beweert dat dat goed gaat). Je wilt een zekere mate van zekerheid.

Hetzelfde geldt voor dit keurmerk. Zoals ik zei is het een extra'tje. De programmeur bewijst ermee een zekere mate van kennis en kunde te hebben. Erg handig in de gevallen dat je geen ervaring met desbetreffende persoon hebt.

[mjtdevries]

Een kind met een zwemdiploma heeft altijd in de praktijk moeten leren zwemem en moeten afzwemmen.
Die vergelijking gaat dus mank.

En de vergelijking met de verkeersregels gaat ook mank. Je gaat er namelijk vanuit dat programmeurs wel weten hoe het moet, maar zich er niet aan houden.
Het tegendeel is echter waar. De overgrote meerderheid van de programmeurs weten niet eens hoe het zou moeten.

Het zal het gemiddelde kennisnivo van de programmeurs verhogen, en daarmee wel degelijk meer invloed hebben dan alleen maar een melding op een CV.

[Hyronymus]

Zelf geen zwemdiploma's op zak zeker?! Dan zou je namelijk weten dat het volgen van zwemles een vereiste is voor het behalen van een zwemdiploma. Een zwemdiploma bestaat niet uit een theorie- en praktijkdeel.

[Patriot]

Sinds wanneer is er een theoriedeel? Ik heb het nooit gehad (ben 17), bovendien heb ik twee kleinere broertjes ronddartelen die beiden geen zwemtheorie hadden.

Er is volgens mij helemaal geen sprake (meer) van een theoriedeel.

[PulsatingQuasar]

Ik denk dat het ook te maken heeft met de tijd krijgen om goede veilige code af te leveren. Het kost toch over het algemeen meer tijd om secure code te schrijven.

Bedrijven zijn vaak dan ook direct schuldig aan het ontbreken van goede secure code. Ren je rot trajecten kun je geen geen goede secure code van verwachten. Bedrijven die dat niet door hebben moeten eerder bij zichzelf kijken.

[Verwijderd]

Een goede programmeur kan dit wel, helaas zijn er maar weinig. Want een programmeur kan geen programma, een TO en een FO maken.

Wil je echt een goed programma dan zul je er met meerdere aan moeten werken en met een goede structuur en liefst zonder consulent.

[PulsatingQuasar]

Dat een programmeur het toch voor elkaar krijgt in ren je rot trajecten heeft meer te maken met het feit dat die persoon overuren gaat draaien om het voorelkaar te krijgen.

Als die programmeur gewoon zijn 8 uur per dag zou draaien krijgt ie het ook niet voorelkaar voor de deadline. Soms is het ook een spelletje waarbij een manager hoopt dat de programmeurs overuren gaan draaien om een eigenlijk te krappe deadline te halen en dat alles technisch en security technisch nog steeds goed in elkaar zit.
Maar als die programmeurs dat niet van plan zijn dan worden er consessies gedaan. 1 er van is security.

Een docent gaf eens een goede opmerking waar ik helemaal achter sta. "Als je geen tijd krijgt om security te programmeren is het niet jouw probleem".
Op de standaard kleine programeer technische zaken na zoals het Microsoft 70-340 Implementing Security certificaat kost het gericht veilig programmeren kennis in wat er allemaal fout kan gaan en daarmee dus tijd op vele fronten. Niet alleen een programmeur moet weten welke exploits er mogelijk zijn maar ook een tester.
Als een manager daar niet gericht op stuurt dan is het ook niet je probleem. Mocht je moeite hebben met bovenstaande opmerking dan heb je niet begrepen wat die zin inhoudt.

Ik ben het er mee eens dat je met meerdere mensen aan een programma moet werken om het echt goed te krijgen. Maar vaak is een gebrek aan geld en een gebrek aan het inzien van het feit dat programmeren helemaal niet snel gaat( helemaal als security er bij komt kijken) er de oorzaak van dat er veel security problemen zijn.

Managers en bedrijven in Nederland moeten eens inzien dat goede software een kwestie is van genoeg tijd hebben. Het constant beknibbelen op het budget omdat je eigenlijk niet wilt inzien dat maatwerk gewoon veel kost is de bron van alle problemen.

In de basis is dit keurmerk dus een goed ding. Programmeurs worden gewezen op een aantal zaken en kunnen er gerichter naar kijken maar dit wordt dan weer te niet gedaan als die programmeur vervolgens te weinig tijd heeft om het ook uit te voeren.

[Donderwolk]

Door je programmeurs op een dergelijke wijze bewust te maken van veilig programmeren zorg er juist indirect wel weer voor dat hun output minder veiligheidsfouten bevat natuurlijk.

Ik denk dat je veiligheidsgevoelige programma's altijd moet testen op lekken. Maar in de praktijk blijkt dat dit vaak niet gebeurt. Daarom is het aanpakken bij de bron een goed idee imho.

[Roland684]

Mwa.. elk boek over webdesign vertelt je dat je data van buiten (alles wat de browser teruggeeft) nooit mag vertrouwen, toch wordt dat vaak blindelings gedaan. En overal staat dat je er nooit van uit mag gaan dat cookies gebruikt kunnen worden, toch zijn er zat site die de mst in gaan zonder cookie.

De theorie is al bij iedereen bekend, maar in de praktijk wordt er gewoon slordig gewerkt.

Je moet gewoon een 'hacker' in dienst nemen die de programma(code) controleert en de terugstuurt naar de programmeur die zijn werk niet goed gedaan heeft.

[Vaudtje]

Het is toch handig als de 'hacker' de triviale dingen er niet meer uit hoeft te halen omdat de programmeur die er niet in stopt?
Als je een gecertificeerde programmeur hebt, kun je er meer op vertrouwen dat hij oog heeft voor beveiligingsissues en daarop anticipeert.

[Verwijderd]

Ik deel je mening in dit geval niet, in veel gevallen wel.

SANS is een instituut dat vooral werkt op handson ervaring en kennis. Je moet bij veel certificeringen van SANS zelfs proefschriften afleveren.

[jmzeeman]

Helemaal met je eens. Alhoewel het erg praktisch zou zijn als je programmeurs op basis van certificaten en diploma's zou kunnen beoordelen blijkt dat in de praktijk onmogelijk. Ik ken programmeurs zonder ook maar enig certificaat die ik de besturing van een kerncentrale zou toe vertrouwen maar ook programmeurs met certificaten die ik nog geen website zou laten maken. Programeer kwaliteit is en blijft volgens mij iets dat erg lastig te kwantificeren valt.
Het belangrijkste is zoals je al zegt goed testen en goede ontwerp/analyse documentatie waarin de reden dat iets op een bepaalde manier wel/niet werkt uiteengezet wordt.

[OddesE]

Alle mogelijke paden testen van zelfs een kleine applicatie is al ondoenlijk. Voorkomen is beter dan genezen.

[Destralak]

Dit is echt ideaal. Als het keurmerk maatschappelijk geaccepteerd wordt, dan staat dit onwijs leuk op je CV.
Hetzelfde als de status van een MVP (Microsoft Valued Professional: http://mvp.support.microsoft.com/), bijvoorbeeld.
Vooral aangezien de examenkosten ook nog eens meevallen, is dit voor veel mensen te doen.

[Reactie gewijzigd door Destralak op 25 juli 2024 17:34]

[humbug]

MVP gaap. SCJP gaap en zo kan ik nog wel even doorgaan. Al dat soort examens kan ik op zijn hoogst als "MBO" niveau inschatten. Leuke CV vulling maar inhoudelijk zegt het erg weinig. En hetzelfde gaat waarschijnlijk voor dit examen op. Veel meer dan de echte basis eisen ze vast niet. Anders raken die duizenden matige programmeurs bij de grote bedrijven nog hun baan kwijt. En dan kunnen die bedrijven geen grote opdrachten meer aannemen.

Een keurmerk. Yeah, right.

[koli-man]

Je hebt wel gelijk. Nu gaat het enigszins redelijk in de it met aanvragen en opdrachten. Echter, het zal ook een keer weer wat minder gaan, en er dus meer it'ers zijn dan aanvragen. En er liggen 2 redelijk identieke cv's op het bureau, dan zal vaak degene met de certificering er uitgepikt worden, terwijl het misschien de mindere programmeur is.

Echter is er ook iets te zeggen over het 'aanneembeleid' van bedrijven. Dat moet ook maar eens onder handen genomen worden....

[humbug]

Tsja, ik heb net weer even door de beschikbare programmeurs/SAs van een groot IT bedrijf mogen lopen om wat mensen te vinden voor een project. Dan schrik je toch wel van de inhoud van sommige CVs Bij interviews blijken de mooiste CVs bij mensen te horen waar je niets aan hebt terwijl mensen met een CV zonder veel certificaten maar met echte projecten vaak veel bruikbaarder blijken.

[hamsteg]

lekker generaliserend ... tuurlijk heb je deze uitersten. Statistisch gekeken naar een normaalverdeling is een goede CV in 68% van de gevallen een korrecte weergave van de werkelijkheid. Ja er zitten ook neppers of hele goede zelfleerders tussen maar dit is niet de standaard meerderheid.

[voodooless]

Ow? dus het is meer een CV vuller dan een serieus iets dat echt laat zien dat je iets daadwerkelijk goed kunt. Ja echt ideaal

Seirously, ik kan me helemaal aansluiten bij elmuerte hierboven: Het vertrouwen in dergelijke "keurmerken" is volledig misplaatst. Dit soort dingen horen gewoon in een opleiding meegenomen te worden.

Wat al helemaal raar is, is dat het taalafhankelijk is. Sure er zijn bepaalde verschillen wat security betreft in diverse talen, maar dat wil nog niet zeggen dat je de achterliggende concepten van niet hoeft te snappen. Als die duidelijk zijn, dan maakt het geen drol uit in welke taal je bezig bent. Ze zijn altijd toepasbaar.

[mjtdevries]

Het hoort inderdaad in een opleiding meegnoemen worden.

De praktijk is echter dat dat niet gebeurd, of dat de programmeurs die opleidingen niet gevolgd hebben.

Dan is het heel handig dat je een aparte opleiding/certificaat speciaal op dat gebied instelt.

Ten dele heb je gelijk dat een groot deel taafonafhankelijk zou moeten zijn. (En dat is het waarschijnlijk ook wel zo). Maar als je specifiek naar implementatie binnen een taal gaat kijken, dan zitten daar uiteraard wel verschillen in.
In C++ heb je bv heel wat meer security risicos om rekening mee te houden dan in Java.

[OddesE]

Bovendien zijn heel veel security problemen gemakkelijk te voorkomen door bepaalde gewoontes aan en andere juist af te leren.

Zo moet je niet dit doen:

Query query = connection.createQuery("SELECT * FROM users WHERE username = '" + username + "' and password = '" + password);
query.execute();

maar

Query query = connection.createQuery("SELECT * FROM USERS WHERE username = ? AND password = ?");
query.setString(0, username);
query.setString(1, password);
query.execute();

(syntax verzonnen, maar het lijkt hier op in Java)

Dan escaped de API namelijk netjes de parameters voor je, zodat SQL injection onmogelijk wordt. Zulke dingetjes zijn API / taal specifiek. Dus waarom niet een taal specifiek examen? Bovendien moet je niet vergeten dat sommige mensen al jaren in de praktijk zitten en het IT landschap enorm veranderd is sinds ze van school zijn. Bijspijkeren kan nooit kwaad.

[koli-man]

MVP betekent volgens mij Most Valuable Professional...
en dit kun je niet worden door alleen maar een examen.

Jij bedoelt waarschijnlijk MCP (MS Certified Professional)

[Reactie gewijzigd door koli-man op 25 juli 2024 17:34]

[brompot758]

Mooi initiatief. Het heeft echter alleen zin als de frameworks/libraries/... net zo veilig geschreven zijn als de code die je zelf produceert.

Als je zelf de boel veilig hebt, maar je loopt tegen een buffer overflow in .NET/Java framework aan, of een bug in je J2EE applicatieserver/ASP.NET dan ben je nog net zover van huis.

Je moet dus ook zorgen dat je leveranciers gecertificeerd werken.

[SPee]

Over het algemeen zou een buffer overflow in .Net/Java niet voor moeten komen. Het geheugen beheer is daar uit jouw handen. Volgens mij kan het bij .Net nog wel, maar bij Java niet (tenzij je weer native libraries aanroept, maar die zijn geen java).
En mocht het onverhoopt toch gebeuren zou je JVM eruit knallen.

Voor Java geldt meer het valideren van input parameters. Dus of een String niet null is.

En je zit meestal aan een applicatie server vast. Die moet juist geconfigureerd worden zodat anderen niet via extern de applicatie kunnen bekijken/aanpassen.

[OddesE]

De runtime echter, is een native applicatie die wél last van een buffer overflow last kan hebben. Maar het voordeel is dat dan alle apps daar last van hebben, waardoor het snel opgemerkt en gefixed zal worden. Juist de code die heel weinig draait is link.

[humbug]

Als je veilige code wilt is er maar 1 oplossing. Een audit. En hoeveel bedrijven doen een (externe) audit? Juist. Erg weinig. Dit "keurmerk" lost weinig tot niets op en zegt totaal niets over de kwaliteit en veiligheid van de opgeleverde software. Maar het maakt wel dat de grote bedrijven weer 10,- per uur extra kunnen vragen. Want ja, hun personeel heeft dat "onmisbare" papiertje.

[servies]

Tja... en dan weet je hoe je moet programmeren en dan krijg je een vraag om iets te implementeren en een tijdsinschatting aan te geven.
Je wilt het netjes doen en dus heb je wat extra tijd nodig om de nodige checks en foutafhandeling toe te voegen en voor het testen. Je komt uit op een tijdsinschatting van 20 dagen...
"Ja maar, dat kan niet. Dat duurt veel te lang en dan wordt het veel te duur. Je krijgt maximaal 14 dagen"....
Waarop zal er dan 'bezuinigd' worden...

[Reactie gewijzigd door servies op 25 juli 2024 17:34]

[mjtdevries]

Ja ja, input checks en nette foutafhandeling kost je 6 dagen op een totaal van 20 dagen? Onzin!

Als je er aan went dat altijd netjes te doen, dan kost het je 1 dag op een totaal van 20!

En aangezien netjes programmeur ook zorgt voor minder bugs, zal het uiteindelijk helemaal niet meer tijd kosten om het product op te leveren!

[Sfynx]

Je zal hoe dan ook je testcases moeten bepalen, schrijven en automatiseren, en als het even kan net zolang totdat elke regel code is getest, en opnieuw getest kan worden na elke verandering. En dat kost wel degelijk tijd. Maar omdat het testen geen nieuwe knopjes en venstertjes oplevert, zien veel werkgevers het als verloren tijd en beperkt het testen zich te vaak tot het aanklikken van wat knoppen en zien of er foutmeldingen verschijnen.

Je moet niet alleen goede code kunnen schrijven, je moet ook betrouwbaar kunnen controleren dat de code goed is en deze controle constant kunnen herhalen om nieuw geïntroduceerde bugs te vangen (regression testing). Het schrijven van goede code hoeft zeker niet langer te duren als je een goede werkwijze hebt, maar de extra tijd gaat in de controle zitten. Tenzij je een deel van je systeem 1 keer test en daarna ercvanuit gaat dat dit altijd goed blijft werken (en dat breekt je een keer op).

[servies]

Droom maar lekker door...
met een paar extra foutafhandelingetjes kom je er wel... Dat is niet alles...

[Reactie gewijzigd door servies op 25 juli 2024 17:34]

[humbug]

Maar 20 dagen is gewoon lang. Ik heb hier een inschatting van een project met enkele honderden dagen werk voor me neus. Van alle deeltaken is er maar 1 die 20 mandagen inneemt. En dat is echt een behoorlijke taak.

[servies]

20 dagen lang???
We zijn niet allemaal websitejes aan het maken...
Wie zegt er overigens dat ik het over een subtaakje heb...

[IEF]

lang is relatief. Hangt er natuurlijk helemaal vanaf wat voor project het is

Er zijn best projecten welke niet zomaar in vele kleine deeltaken kunnen worden opgedeeld. Dus 20 mandagen is heus wel mogelijk.

Het punt is juist dat een werkgever bij dat soort grote taken (die dus veel tijd en geld vergen) zal bezuinigen op de kwaliteit/veiligheid.

Ook is het natuurlijk niet zo dat je checks/foutafhandeling alleen maar na je 'main tasks' doet. Dus helemaal eerlijk is het ook niet.

[Reactie gewijzigd door IEF op 25 juli 2024 17:34]

[Verwijderd]

Ik bezuinig dan niet op mijn reacies

Dan geeft je een van de volgende antwoorden.

1 dan moet je me deze vraag 20 dagen geleden stellen.
2 kan ik dan extra personeel krijgen om dit op te lossen ?
3 als je vaker komt met dit soort vragen, wordt het de volgende keer 40 dagen. Wat wil je.
4 JA maar dat kan niet ?? Zo heb je iets belooft zonder met mij te overleggen.
5 Doe het dan zelf maar

ach vraag naar het hoe en waarom .

[Laurens-R]

Antwoord 1 en 2 -> ok..

Antwoord 3 - 5: ... Ik snap dat je niet met alles akkoord moet gaan, maar zo jaag je toch wel erg snel mensen in het harnas! Ik werk nog niet zolang hoor (ben pas 24 ), dus misschien gebrek aan ballen van mijn kant.

[Woet]

Dat is mooi, er zijn veel te veel mensen die denken dat ze kunnen programmeren, en dan veel veiligheidsfouten achterlaten, waar het bedrijf later pas enorme schade door lijdt.

Vooral (In PHP) MySQL injection of XSS zorgen voor veel problemen.

[Verwijderd]

Ik vraag me dan wel weer af waarom ze een Perl examen gaan maken, want Perl is al behoorlijk verourderd(o.a. qua programmeer concepten) en wordt volgens mij niet veel meer gebruikt.
nofi btw

[mae-t.net]

Tsja, dat jij en ik niks in perl doen betekent nog niet dat het verouderd en in onbruik is... Ik neem niet aan dat ze er een examen voor maken als er geen user base voor is. In mijn omgeving zitten wat Python liefhebbers, misschien dat die taal over een paar jaar wel meer gebruikt wordt dan perl, maar dat zien we tegen die tijd wel weer.

[Reactie gewijzigd door mae-t.net op 25 juli 2024 17:34]

[Mr_Light]

Het gaat waarschijnlijk (voornamelijk) om applicaties die nu nog onderhouden worden en geloof me dat zijn er best nog veel. En bij onderhoud wordt er ook nog wel wat security issues (erbij) gefixed.

[Verwijderd]

Er draait nog veel oud spul, dit komt omdat het nog doet wat het doen moet.
En er als er geen update nodig is van de funtionaliteit blijft het zo.
Zo zit de mens in elkaar want waarom iets veranderen als het nog doet.
Veranderen kost geld en je hebt kans dat het niet werkt, want de kennis van het oude systeem is weg

[Verwijderd]

Ja natuurlijk draait er nog veel op Perl, maar er wordt volgens mij niet zo heel veel meer in ontwikkeld op dit moment. Prachtig dat er nog zo veel op draait maar dat heeft natuurlijk weinig met dit keurmerk te maken, dat is voornamelijk belangrijk voor nieuwe projecten.

Wel een goed initiatief.

[CMG]

Waarschijnlijk voor CGI scripts in Pearl, dat wordt online nog wel redelijk gebruikt.