10. Februar 2013 06:35

Re: Kein Quellcode -> Kein Test moeglich && TUEV == Geld

Sid Burn schrieb am 8. Februar 2013 16:31

> > Genau diese Sichtprüfung fällt beim Softwaretest weg, wenn keinerlei
> > Einblick in die Sourcen gegeben wird,

> Was natürlich kompletter Blödsinn ist. Auch eine Software wo kein
> Quellcode offen ist, kann hinreichend geprüft werden ob sie mängel
> besitzt.

Schwachsinn...

> Die meisten Sicherheitslücken bei Propietärer Software wird auch
> genau so gefunden.

Notgedrungen...

> Nach deiner Logik wäre es dann ja eher ein riesen Vorteil wenn kein
> Quellcode verfügbar ist, weil man dann nämlich auch keine Lücken
> finden kann. Den es ist ja alles verschlossen. 

Unfug.

> Es ist aber nunmal so das der Quellcode verstecken kein Vorteil ist.
> Warum? Weil eine Software nämlich trotzdem hinreichend auf Mängel
> prüfbar ist und Lücken genauso gefunden werden.

Unfug, denn letztlich liegt immer eine Form von Quellcode vor. D.h.
es ist nur eine Frage wieviel Aufwand ein Tester bzw. ein böswilliger
Angreifer treibt.

> Und genau das hat auch genau den Effekt das man auch eine Software
> ohne Quellcode hinreichend prüfen kann.

Blödsinn. - Letztlich wird es ein komerzieller Tester bei wenigen
standardisierten Funktionstests belassen. Z.B. wird man bei einem
CRUD-Interface auf typische SQL-Injection Probleme praktisch testen.
Aber Fehler, die sich ggf. in einem schicken Zweizeiler verstecken,
deren alleiniges theoretisches Verständnis schon eine halbe Stunde
Erklärungsbedarf mit sich bringen, wirst Du qua Zufall so gut wie nie
erwischen. Überhaupt ist die Idee am Ende durch Handauflegen etwas
testen zu wollen grenzdebil.
In der schnöden Praxis rutschen dann Nummern wie der jüngste
Apple-Patzer mit "File://" irgendwie in der Endkontrolle durch,
obgleich derartiges überhaupt erst einzubauen man bei Entwicklern mit
Hirn eigentlich nicht für möglich hält.

Ein böswilliger Angreifer hingegen wird sich ggf. die Zeit mit dem
Disassembler nehmen.

Beispiel - Intelligenter^W Kostenpflichtiger Ratschlag eines
Zertifizierers: "SSL-Verschlüsselung im LAN aus Sicherheitsgründen
zwingend notwendig".
Bei einer Software die vom Kunden an dutzenden Stellen ausdrücklich
defekt geordert wurde. Einschließlich im Klartext gespeicherter
Passwörter, eines einheitlichen hartcodierten DB-Benutzers,
Constraints nur in SW, uvm.. D.h. die Datenbank steht offen wie ein
Scheunentor, aber es ist essentiell, dass die Daten im LAN keiner
mitlesen können soll ;-)

Diagnose: Ein Spielkind wollte mal Etherreal ausprobieren und hat
sich dies vom Kunden vergolden lassen. Bei einem tatsächlichen Test
und tatsächlich geprüfter Sicherheit hätte der Zertifizierer dem
Kunden klarmachen müssen, dass er sein Geld wegen eigener Unfähigkeit
verbrannt hat.

Anzeige