mboost-dp1
Patch eller betal
Skråplan.
Myndighederne bør holde sig fra de rå tekniske detaljer. Mere vil have mere. Det ender med at man skal hyre to jurister før man kan hyre en programmør.
Til sidst kan kun store, certificerede, regulerede, godkendte softwarehuse få lov til at levere IT, helt generelt, pga. legal risk og juridiske krav. Det skal nok komme.
Myndighederne bør holde sig fra de rå tekniske detaljer. Mere vil have mere. Det ender med at man skal hyre to jurister før man kan hyre en programmør.
Til sidst kan kun store, certificerede, regulerede, godkendte softwarehuse få lov til at levere IT, helt generelt, pga. legal risk og juridiske krav. Det skal nok komme.
#2
De siger at hvis en virksomhed bliver hacket i fremtiden og det viser sig at hackerne er kommet ind via de nu meget kendte log4j svagheder så vil de udstede bøder i XXX M$ klassen.
De blander sig ikke i hvilket software virksomhederne bruger, hvem der skal udvikle/vedligeholde den software eller hvem der skal patche softwaren.
De siger kun at det er virksomhedens ansvar at de ikke har det her sikkerhedshul, når nu både problem og løsning er kendt.
Og de etablerer vel en vis praksis.
Equifax blev hacket may-juli 2017 og Struts 2 patchen var releaset i marts 2017. Det kostede 700 M$ i bøde.
Log4j blev patchet i december 2021. Og nu forventer myndighederne at den patch bliver rullet ud og hvis ikke det sker og hvis det går galt så falder der bøde igen.
De siger at hvis en virksomhed bliver hacket i fremtiden og det viser sig at hackerne er kommet ind via de nu meget kendte log4j svagheder så vil de udstede bøder i XXX M$ klassen.
De blander sig ikke i hvilket software virksomhederne bruger, hvem der skal udvikle/vedligeholde den software eller hvem der skal patche softwaren.
De siger kun at det er virksomhedens ansvar at de ikke har det her sikkerhedshul, når nu både problem og løsning er kendt.
Og de etablerer vel en vis praksis.
Equifax blev hacket may-juli 2017 og Struts 2 patchen var releaset i marts 2017. Det kostede 700 M$ i bøde.
Log4j blev patchet i december 2021. Og nu forventer myndighederne at den patch bliver rullet ud og hvis ikke det sker og hvis det går galt så falder der bøde igen.
De siger kun at det er virksomhedens ansvar at de ikke har det her sikkerhedshul, når nu både problem og løsning er kendt.
Jeg har udviklet medicinsk udstyr. Jeg har set hvad simple krav som "efficacy and safety" kan føre til. Det hele handler om at kunne besvare spørgsmål i denne stil:
1. Show us your written software development process
2. Show us how you enforce the process
3. How do you verify and validate the intended functionality
4. Show us your suppliers and how you approve them
5. Show us a risk assessment for the product and mitigation efforts
6. Are your developers certificated for their work
7. Show us a papertrail for the development of the product
etc.
Det samme kan snildt ske indenfor generel software når myndighederne først kommer i gang. I første omgang sikkert for software der vurderes "kritisk" for samfundet.
Problemet er bare at den slags "regulatory oversight" fører til at alt går i stå, man hænger fast i waterfall modeller, og spilder enorme mængder af tid og ressourcer på papirarbejde.
#5
De krav er vel rimelige hvis der skal leveres kvalitetes software.
Jeg tvivler på kvaliteten hvis der ikke findes nogen dokumenteret process d.v.s. at man bare gør et eller andet baseret på personerne erfaring og ideer.
5000 sider er dog ikke bedre end 5 sider. Formentligt dårligere da ingen læser 5000 sider!
Hvis man ikke ved hvordan man tester softwaren så kan det næsten garanteres at kvaliteten er elendig.
Kvaliteten af det færdige produkt afhænger ikke kun af det kode der skrives men også af de compilere, biblioteker og hardware som indgår i løsningen.
Det er en naturlig del af kvalitetskontrol også at kontrollere dem.
Der er rigtigt mange som ikke checker kvaliteten af de oceaner af biblioteker som deres package manager hiver ind, men det hjælper ikke på kvaliteten.
Det er vel et sted mellem en god ide og en nødvendighed at analysere lidt på hvad der kan gå galt.
Der er stor forskel på ALLE og NOGEN her.
Jeg vil forvente at i et kvalitets team har de fleste en relevant uddannelse, relevante kurser etc..
Men vi ved godt at der i branchen er folk med lidt utraditionel og i nogen tilfælde meget utraditional baggrund. Så det giver ikke mening at insistere på at alle skal have formelt papir på deres kvalifikationer.
++++
Men at noget er en god ide betyder jo ikke at det giver mening at gøre det til et lovkrav.
Min fornemmelse for hvad der giver mening er:
software hvor fejl resulterer i tab af menneskeliv : stil lovkrav til kvalitetssikringen (man kan ikke gøre døde levende ved at straffe de skyldige bagefter)
software hvor fejl resulterer i tab af penge : undlad specifikke lovkrav men sikker at ofrene for fejl kan få erstatning, så bliver det dyrt at sjuske med kvaliteten
software hvor fejl resulterer i ulejlighed og pinlighed : det må markedet ordne - kunderne kan droppe de leverandører som har dårlig kvalitet - og gør de ikke det så må de leve med den dårlige kvalitet
De krav er vel rimelige hvis der skal leveres kvalitetes software.
1. Show us your written software development process
2. Show us how you enforce the process
...
7. Show us a papertrail for the development of the product
Jeg tvivler på kvaliteten hvis der ikke findes nogen dokumenteret process d.v.s. at man bare gør et eller andet baseret på personerne erfaring og ideer.
5000 sider er dog ikke bedre end 5 sider. Formentligt dårligere da ingen læser 5000 sider!
3. How do you verify and validate the intended functionality
Hvis man ikke ved hvordan man tester softwaren så kan det næsten garanteres at kvaliteten er elendig.
4. Show us your suppliers and how you approve them
Kvaliteten af det færdige produkt afhænger ikke kun af det kode der skrives men også af de compilere, biblioteker og hardware som indgår i løsningen.
Det er en naturlig del af kvalitetskontrol også at kontrollere dem.
Der er rigtigt mange som ikke checker kvaliteten af de oceaner af biblioteker som deres package manager hiver ind, men det hjælper ikke på kvaliteten.
5. Show us a risk assessment for the product and mitigation efforts
Det er vel et sted mellem en god ide og en nødvendighed at analysere lidt på hvad der kan gå galt.
6. Are your developers certificated for their work
Der er stor forskel på ALLE og NOGEN her.
Jeg vil forvente at i et kvalitets team har de fleste en relevant uddannelse, relevante kurser etc..
Men vi ved godt at der i branchen er folk med lidt utraditionel og i nogen tilfælde meget utraditional baggrund. Så det giver ikke mening at insistere på at alle skal have formelt papir på deres kvalifikationer.
++++
Men at noget er en god ide betyder jo ikke at det giver mening at gøre det til et lovkrav.
Min fornemmelse for hvad der giver mening er:
software hvor fejl resulterer i tab af menneskeliv : stil lovkrav til kvalitetssikringen (man kan ikke gøre døde levende ved at straffe de skyldige bagefter)
software hvor fejl resulterer i tab af penge : undlad specifikke lovkrav men sikker at ofrene for fejl kan få erstatning, så bliver det dyrt at sjuske med kvaliteten
software hvor fejl resulterer i ulejlighed og pinlighed : det må markedet ordne - kunderne kan droppe de leverandører som har dårlig kvalitet - og gør de ikke det så må de leve med den dårlige kvalitet
#6 Det er et tricky emne. Hvad jeg konstaterede i en stærkt reguleret udviklingsprocess var at det førte til nogen ret uheldige bivirkninger:
1. Jeg skrev ca. en linje kode om ugen på selve produktet i gennemsnit (lille microcontroller dims i et medical device).
2. Tiden gik med møder, QA slåskampe, dokumenter, protokoller, konstruktion af testsystemer, manuelle test
3. Vi hang fast i old gamle versioner af diverse tools, fordi det var så trægt at godkende nye versioner.
4. Dygtige udviklere stak af. (mig selv inklusive om jeg så må sige). "Dovne" udviklere havde det fint.
I sidste ende blev der brændt uanede mængder resourcer af på meget lidt. Den slags er der kun råd til i den medicinske branche. Ja, det endelige produkt var gennemtestet og bundsolidt, men også enormt meget dyrere end det behøvede at have været. Og allerede tæt på at være forældet da det endelig blev lanceret.
Gode intentioner er ikke altid vejen til gode resultater.
1. Jeg skrev ca. en linje kode om ugen på selve produktet i gennemsnit (lille microcontroller dims i et medical device).
2. Tiden gik med møder, QA slåskampe, dokumenter, protokoller, konstruktion af testsystemer, manuelle test
3. Vi hang fast i old gamle versioner af diverse tools, fordi det var så trægt at godkende nye versioner.
4. Dygtige udviklere stak af. (mig selv inklusive om jeg så må sige). "Dovne" udviklere havde det fint.
I sidste ende blev der brændt uanede mængder resourcer af på meget lidt. Den slags er der kun råd til i den medicinske branche. Ja, det endelige produkt var gennemtestet og bundsolidt, men også enormt meget dyrere end det behøvede at have været. Og allerede tæt på at være forældet da det endelig blev lanceret.
Gode intentioner er ikke altid vejen til gode resultater.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund