Sind mit Delphi erstellte Programm sicherer?

[BlueStarHH]

Hallo,

sind mit Delphi erstelle Programm grundsätzlich "sicherer", als mit anderen Sprachen wie z.B. C? In Delphi gibt es ja die Typisierung und Stack-Overflows können nicht vorkommen, wenn bestimmte Dinge nicht tut (welche wären das)? Bei mit C erstellten programme liest man ja ständig, dass durch Stack-Overflows enorme Sicherheitslücken aufgetreten sind.

Hintergrund ist, dass ich einem Kunden begründen muss, warum mein Delphi-Programm sicher ist. Es ist ein Programm, das lokal bei ihm ohne installation läuft. Es zeigt kurze Hilfe-Animation in einem eingebetteten Chrome-Browser (HTML5/SVG) an. Mehr nicht. Ich muss begründen, warum das kein Sicherheitsrisiko für seine IT ist. Admin-Rechte/Internetzuggang braucht man auch nicht. Was könnte man da noch nennen?

Der Kunde hat Angst, dass wenn dort eine Sicherheitslücke auftreten sollte (was soll das hier sein) der Angreifer Schaden auf seinen System anrichtgen könnte oder sogar Vollzugriff auf alles bekommt.

[Gausi]

Nuja, wenn du einen Browser einbettest, dann hast du schonmal alle Sicherheitsprobleme drin, die der Browser auch hat. ;-)

Aber davon abgesehen: Welche Möglichkeiten zur Eingabe von Daten bietet das Progremm denn? Spielt es nur eine vorgegebene Animation ab? Dann besteht wenig Gefahr - es sei denn, dein Kunde unterstellt dir bösartige Absichten.

Oder kann der Anwender eigene (oder von Dritten, ggf. bösartige) Animationen einbetten und anzeigen lassen? Dann wäre das potentielle Problem deutlich größer - ungepatchte Bugs in der Browser-Engine wären dann unter Umständen auch dein Problem.

[haentschman]

Zitat:

Ich muss begründen, warum das kein Sicherheitsrisiko für seine IT ist

:roll: Welches Programm hat nicht seine "Probleme". Die meisten kommen aber aus dem Betriebssystem...

Zitat:

Was könnte man da noch nennen?

...der typische Layer 8 Fehler. :zwinker: Unbekannte Mailanhänge z.B. öffen. Davor sollte sich die IT fürchten. Nicht vor Delphi. :?

[joachimd]

lass einfach Schwachstellenscanner dagegen laufen und schicke ihm den Bericht.

[BlueStarHH]

Zitat:

Zitat von joachimd (Beitrag 1527772)

lass einfach Schwachstellenscanner dagegen laufen und schicke ihm den Bericht.

Hast Du eine Empfehlung für so einen Scanner?

[Jasocul]

Zitat:

Zitat von Gausi (Beitrag 1527770)

Nuja, wenn du einen Browser einbettest, dann hast du schonmal alle Sicherheitsprobleme drin, die der Browser auch hat. ;-)

Aber davon abgesehen: Welche Möglichkeiten zur Eingabe von Daten bietet das Progremm denn? Spielt es nur eine vorgegebene Animation ab? Dann besteht wenig Gefahr - es sei denn, dein Kunde unterstellt dir bösartige Absichten.

Oder kann der Anwender eigene (oder von Dritten, ggf. bösartige) Animationen einbetten und anzeigen lassen? Dann wäre das potentielle Problem deutlich größer - ungepatchte Bugs in der Browser-Engine wären dann unter Umständen auch dein Problem.

Oder, falls die SVG-Dateien irgendwo auf dem Rechner oder Netzwerk abgelegt sind, könnten diese unabhängig vom Programm manipuliert werden. Darauf hat das Programm dann keinen Einfluss.

[joachimd]

Kali-Linux als Image besorgen, da ist https://openvas.org/ mit drin. Ansonsten bei Web ist https://owasp.org eine gute Wahl.

[BlueStarHH]

Zitat:

Zitat von Gausi (Beitrag 1527770)

Nuja, wenn du einen Browser einbettest, dann hast du schonmal alle Sicherheitsprobleme drin, die der Browser auch hat. ;-)

Es ist ja nur die Chrome-"Engine" ohne die Chrome-GUI. Die GUI ist ja in Delphi erstellt. Wie könnte man das Nutzen um daraus einen Angriff zu starten?

Zitat:

Zitat von Gausi (Beitrag 1527770)

Aber davon abgesehen: Welche Möglichkeiten zur Eingabe von Daten bietet das Progremm denn?

Er kann einige Dinge konfigueren. Welche Animationen möchte er in welcher Häufikeit sehen. Mehere Hintereinander oder nur eine und sowas in der Art.

Zitat:

Zitat von Gausi (Beitrag 1527770)

Oder kann der Anwender eigene (oder von Dritten, ggf. bösartige) Animationen einbetten und anzeigen lassen?

Nein, kann er nicht. Wäre dann aber auch sein Problem, wenn er selbst Schadcode dort reinladen würde.

[BlueStarHH]

Zitat:

Zitat von Jasocul (Beitrag 1527774)

Zitat:

Zitat von Gausi (Beitrag 1527770)

Nuja, wenn du einen Browser einbettest, dann hast du schonmal alle Sicherheitsprobleme drin, die der Browser auch hat. ;-)

Aber davon abgesehen: Welche Möglichkeiten zur Eingabe von Daten bietet das Progremm denn? Spielt es nur eine vorgegebene Animation ab? Dann besteht wenig Gefahr - es sei denn, dein Kunde unterstellt dir bösartige Absichten.

Oder kann der Anwender eigene (oder von Dritten, ggf. bösartige) Animationen einbetten und anzeigen lassen? Dann wäre das potentielle Problem deutlich größer - ungepatchte Bugs in der Browser-Engine wären dann unter Umständen auch dein Problem.

Oder, falls die SVG-Dateien irgendwo auf dem Rechner oder Netzwerk abgelegt sind, könnten diese unabhängig vom Programm manipuliert werden. Darauf hat das Programm dann keinen Einfluss.

Das stimmt. ALLEs was das Programm braucht ist aber im Programmorder und "Program Files". Durch UAC mit Schreibschutz für nicht Admins.

[Gausi]

Zitat:

Zitat von BlueStarHH (Beitrag 1527776)

Es ist ja nur die Chrome-"Engine" ohne die Chrome-GUI. Die GUI ist ja in Delphi erstellt. Wie könnte man das Nutzen um daraus einen Angriff zu starten?

Die Engine wird die HTML- und SVG-Dateien laden und verarbeiten. Wenn dabei ein "Buffer Overflow" passiert, über den der Angreifer (der das HTML/SVG böswillig manipuliert hat) dann seinen Code ausführen kann, dann geht das - völlig egal, was deine GUI macht.

Da dein Programm aber praktisch keine Eingaben von außen erlaubt (außer ein paar Klicks und Einstellungen), und dein Programm nicht viel mehr zu sein scheint als eine selbststartende Animation, würde ich das dem Kunden so weitergeben. Wo keine komplexen User-Eingaben möglich sind, kann auch kein Angreifer Unsinn machen. ;-)

Zitat:

Zitat von Jasocul (Beitrag 1527774)

Oder, falls die SVG-Dateien irgendwo auf dem Rechner oder Netzwerk abgelegt sind, könnten diese unabhängig vom Programm manipuliert werden. Darauf hat das Programm dann keinen Einfluss.

Dann hat der Angreifer aber schon Zugriff auf das System. Dann sind Security-Probleme im Code von irgendwelchen Programmen auch (fast) egal.

[Sherlock]

Zitat:

Zitat von joachimd (Beitrag 1527772)

lass einfach Schwachstellenscanner dagegen laufen und schicke ihm den Bericht.

Einfach ist gut, die Dinger kosten einen Haufen Geld.

Ian Barker hat zu dem Thema kürzlich gebloggt: https://blogs.embarcadero.com/how-se...ecurity-holes/ Allein schon das hochladen meines Codes zu wem anderen finde ich problematisch.

[Kas Ob.]

Interesting subject and question, though i see deep and complex even more philosophical.

Security and its gap is limitless pit, there is no standard unless you define security and its gap, so what security means here, what your client may be failed to point and may be you also failed to understand his point of view.

Security in many cases is simple trust of chain, if i trust Daniel (the founder of this forum) with my information, then i obliged to trust the administrators he trusted with my information and so on, this a way to handle security and trust, is my email is secure here ? that can't be answered by simply yes or no.

Security most the time is simple as black or white, but there is cases where it is shades aka risk involvement, and this is huge factor many fail to consider.

Now to your question(s)
Is Delphi safer than C?, this can't be answer by yes or no, in general Delphi is less prone to overflow attacks, it is just harder to weaponize/exploit.
Is your client right with being afraid of your code? yes and the client is right not just always, but in this case, you obliged to give him peace of mind, for his money.

So:
1) you must understand him, his point of view and his trusted people, the ones that might be doing their jobs around him.
2) He rightfully doesn't trust you code, or may be doesn't trust you and your ability to write secured code, this is his right.
3) Why using Chrome, for me chrome is a security risk on its own.
4) Delphi on Virus Scanners like https://www.virustotal.com/ will do very badly on its own !
5) Ditch Chrome and adjust the EXE to minimal, switch to ( i can't believe i am saying it) Internet Explorer or Edge, this will help with Security scanners/analyzers.
6) Your client own the source, without it he will rightfully doubt the whole thing for ever, i recommend to give him the source in full, a compile-able source, and let him audit it, himself or by a 3rd party he trust, so ask you to build or if might prefer to ask a 3rd or even 4th party, that will give him the peace and trust he asking for.

When you have (6) on the table as offer without negotiating, thing will shift and the risk factor by his standard will drop greatly.

My 0.002 cent in short and sorry for bad English and sorry if that didn't help.

[joachimd]

Zitat:

Zitat von Sherlock (Beitrag 1527780)

Einfach ist gut, die Dinger kosten einen Haufen Geld.

KALI ist open source und kostenlos....billiger geht's kaum.

[DasWolf]

Zitat:

Zitat von Kas Ob. (Beitrag 1527781)

Interesting subject and question, though i see deep and complex even more philosophical.

Security and its gap is limitless pit, there is no standard unless you define security and its gap, so what security means here, what your client may be failed to point and may be you also failed to understand his point of view.

Security in many cases is simple trust of chain, if i trust Daniel (the founder of this forum) with my information, then i obliged to trust the administrators he trusted with my information and so on, this a way to handle security and trust, is my email is secure here ? that can't be answered by simply yes or no.

Security most the time is simple as black or white, but there is cases where it is shades aka risk involvement, and this is huge factor many fail to consider.

Now to your question(s)
Is Delphi safer than C?, this can't be answer by yes or no, in general Delphi is less prone to overflow attacks, it is just harder to weaponize/exploit.
Is your client right with being afraid of your code? yes and the client is right not just always, but in this case, you obliged to give him peace of mind, for his money.

So:
1) you must understand him, his point of view and his trusted people, the ones that might be doing their jobs around him.
2) He rightfully doesn't trust you code, or may be doesn't trust you and your ability to write secured code, this is his right.
3) Why using Chrome, for me chrome is a security risk on its own.
4) Delphi on Virus Scanners like https://www.virustotal.com/ will do very badly on its own !
5) Ditch Chrome and adjust the EXE to minimal, switch to ( i can't believe i am saying it) Internet Explorer or Edge, this will help with Security scanners/analyzers.
6) Your client own the source, without it he will rightfully doubt the whole thing for ever, i recommend to give him the source in full, a compile-able source, and let him audit it, himself or by a 3rd party he trust, so ask you to build or if might prefer to ask a 3rd or even 4th party, that will give him the peace and trust he asking for.

When you have (6) on the table as offer without negotiating, thing will shift and the risk factor by his standard will drop greatly.

My 0.002 cent in short and sorry for bad English and sorry if that didn't help.

Remove point 6. Why turn a customer's suspected or imaginary security concern into a real security issue for the provider/manufacturer?

Zum TE:
Du musst nicht erklären, warum Delphi-Software sicherer ist, sondern warum Deine Software sicher ist. Das muss kein Aufsatz sein oder eine komplette Beschreibung der Software. Da reicht einfach ein Ein- oder Zweizeiler. Du schließt einfach aus, dass Durch Deine Software ein Sicherheitsrisiko entsteht oder darüber Sicherheitslücken ausgenutzt werden können. Solltest Du Deine Software dahingehend schon diversen Tests unterzogen haben, kannst Du das vielleicht auch noch erwähnen (Stichwort Qualitätssicherung).

[Kas Ob.]

Zitat:

Remove point 6. Why turn a customer's suspected or imaginary security concern into a real security issue for the provider/manufacturer?

Because it is is right to take care of his business, security and managing his own risk factor.

OP question can interpreted as relative subject, in general you build a solution and market it, you should show some security concerns or at least mention them, to show your professionalism, so if the software on a web site with sales contact, you have to address potential clients question to each and every question, and if fact if you have like 100 clients 5 or 10 of them refuse due security or whatever concern you can't explain, then it is fine and your business is OK, that belongs to your own risk factor of losing clients, not matter the percent.
But if you are after one client, you are the one need to convince him then you and only you should make the compromise to satisfy him, it is simple market, offer and demand.

Zitat:

You don't have to explain why Delphi software is more secure, but rather why your software is secure.

Now to explain if Delphi is better or not, this is absolutely relative, for your it is crucial, for him, it is not, and i agree explaining your software is secure is the best way to go, but how without source and audit (review or whatever) ?
Almost every company out their show their clients list as card to gain trust and establish this trust chain, for small companies or individuals, your code is your proof, then your reputation, these two things goes hand by hand, the reputation level you gain the more client you will have, then less question about your code quality before hand will be asked.

[atari1040]

Eigentlich kann man nie Sicherheit garantieren und Risiken ausschliessen. Man kann nur garantieren, dass aktuell keine Sicherheitslücken bekannt sind, das man seine Software auf dem neuesten Stand hält und in der Zukunft eventuell bekannt werdende Sicherheitslücken umgehend beseitigt.

[Sherlock]

Zitat:

Zitat von joachimd (Beitrag 1527782)

Zitat:

Zitat von Sherlock (Beitrag 1527780)

Einfach ist gut, die Dinger kosten einen Haufen Geld.

KALI ist open source und kostenlos....billiger geht's kaum.

Das testet doch nur Netzwerksicherheit. Ich dachte es geht um allgemeine Sicherheit, wie die genannten Buffer Overflows oder SQL-Injection über Eingabefelder etc. Sorry, mein Fehler.
Noch eine dann vermutlich OT Randbemerkung, ich suche noch nach einem Produkt, daß zumindest statische Codeanalyse hinsichtlich Cybersecurity durchführt. Wie gesagt, teuer ist da gar kein Ausdruck.

O'Neill

[himitsu]

Zitat:

Zitat von Jasocul (Beitrag 1527774)

Oder, falls die SVG-Dateien irgendwo auf dem Rechner oder Netzwerk abgelegt sind, könnten diese unabhängig vom Programm manipuliert werden. Darauf hat das Programm dann keinen Einfluss.

Dann hat der Angreifer aber schon Zugriff auf das System. Dann sind Security-Probleme im Code von irgendwelchen Programmen auch (fast) egal.[/QUOTE]
Bezüglich dem "fast".

Wenn die SVG in einem ungeschützten Bereich von einem normalen Nutzer bearbeitet werden kann (bzw. von einem Programm mit diesen Rechten)
und diese Datei dann z.B. von einem Programm mit Admin- oder System-Rechten gelesen und verarbeitet wird,
dann bekommt dieser Code somit dann auch die höheren Rechte.

[jaenicke]

Es gibt viele Alternativen zur Anzeige von Animationen, z.B. Delphi SVG für SVGs, die komplett in Delphi implementiert sind und deren Quelltext man mit bekommt. Die Wahrscheinlichkeit, dass dort dann Sicherheitslücken ausgenutzt werden, ist geringer als bei weit verbreiteten riesigen Bibliotheken wie eine komplette Browserfunktionalität, die viel mehr potentiell gefährliche Funktionen haben.

[Sherlock]

Ich würde in der Tat erst dann einen Browser in meine Anwendung integrieren, wenn sonst absolut nichts geht - und damit meine ich auch selbst schreiben mit ca. einem Mannjahr Aufwand. Denn Browser öffnen dem entsprechend geneigten Menschen Tür und Tor.

[dummzeuch]

Zitat:

Zitat von Sherlock (Beitrag 1527792)

Ich würde in der Tat erst dann einen Browser in meine Anwendung integrieren, wenn sonst absolut nichts geht - und damit meine ich auch selbst schreiben mit ca. einem Mannjahr Aufwand. Denn Browser öffnen dem entsprechend geneigten Menschen Tür und Tor.

1 Mannjahr? Und Deine Kunden bzw. dein Arbeitgeber bezahlt das dann?
Bei meinem müsste ich dafür schon ziemlich gute Argumente bringen.

[himitsu]

Grund: Sicherheit :stupid:

[jaenicke]

Bei manchen Aufgabenstellungen wie z.B. einer XSL Transformation gibt es leider oft gar keine andere Wahl. Wenn da eine Chromium-basierte Bibliothek die einzige ist, die diese Transformation korrekt ausführt...
(Selbst große und teure Bibliotheken waren daran gescheitert.)

Wenn es aber nicht wirklich nötig ist, würde ich auch von einer solchen Integration absehen. Gibt es keine Alternative, sollte ein Plan vorliegen, wie man die Bibliotheken aktuell hält, um Sicherheitslücken zu stopfen.

[gubbe]

Zitat:

Zitat von BlueStarHH (Beitrag 1527769)

Der Kunde hat Angst, dass wenn dort eine Sicherheitslücke auftreten sollte (was soll das hier sein) der Angreifer Schaden auf seinen System anrichtgen könnte oder sogar Vollzugriff auf alles bekommt.

Wo stellt sich denn der Kunden einen potentiellen Angreifer vor? Aus dem Internet? Das fällt ja hier aus, wenn Dein Programm keinen Internet-Zugriff braucht. Wenn ich es richtig verstehe, verarbeitet es auch keine fremden Dateien. Dann bliebe ja nur ein lokaler Angreifer, der sowieso schon Zugriff auf den Rechner hat. Dann braucht er auch keine Lücke in Deinem Programm mehr zu nutzen, sondern könnte sowieso alles mit den Rechten des lokalen Nutzers machen. Solange Dein Programm nicht mit höheren Rechten läuft, ist es für Angreifer auch nicht interessant.

Ob das Programm jetzt in Delphi, C oder einer anderen Sprache geschrieben ist, spielt hier doch gar keine Rolle. Einziger Knackpunkt ist vielleicht die Einbettung eines Browsers. Wie liest der Browser denn die mitgelieferten HTML-Dateien und SVG-Animationen? Einfach lokal mit dem File-Protokoll oder von einem (lokalen) Webserver? Wenn der Browser mitgeliefert wird, sollte er natürlich keinesfalls dafür benutzt werden können, irgendwelche externen Internet-Seiten anzuzeigen, da er vermutlich nicht regelmässig aktualisiert wird und für diesen Zweck als unsicher gelten muss. Ist ausgeschlossen, dass die Benutzer ihn trotzdem dafür verwenden können?

Ohne jetzt das Konzept in Frage stellen zu wollen, aber warum muss überhaupt ein Browser in Delphi eingebettet werden? Die Seiten mit einem normalen Browser anzuschauen ist nicht möglich?

[himitsu]

Zitat:

Zitat von gubbe (Beitrag 1527801)

Ob das Programm jetzt in Delphi, C oder einer anderen Sprache geschrieben ist, spielt hier doch gar keine Rolle. Einziger Knackpunkt ist vielleicht die Einbettung eines Browsers.

oder andere Fremdkomponenten (extern oder intern)

oder selbsteingebaute Lücken (SQL-Injektion uvm.)

oder Lücken in den Funktionen der verwendeten Basis-Libraries. (.NET-Runtime, C++Runtime, RTL, VCL, FMX, .......)

oder

oder

[gubbe]

Zitat:

Zitat von himitsu (Beitrag 1527802)

oder andere Fremdkomponenten (extern oder intern)

oder selbsteingebaute Lücken (SQL-Injektion uvm.)

oder Lücken in den Funktionen der verwendeten Basis-Libraries. (.NET-Runtime, C++Runtime, RTL, VCL, FMX, .......)

oder

oder

Ja, aber jegliche Lücken lassen sich doch nur ausnutzen, wenn fremde Benutzereingaben oder Dateien verarbeitet werden. Angenommen, die verwendete JPG-Bibliothek wäre verwundbar, spielt das in diesem Fall gar keine Rolle, solange das Programm keine fremden JPGs lädt.

[Sherlock]

Zitat:

Zitat von dummzeuch (Beitrag 1527797)

1 Mannjahr? Und Deine Kunden bzw. dein Arbeitgeber bezahlt das dann?
Bei meinem müsste ich dafür schon ziemlich gute Argumente bringen.

Das dient rein der Abschreckung. Browserbasiertes Zeug darf jeder gerne im Browser nutzen. Aber ich bring mich doch nicht in Richtung Haftbarkeit, nur um einen schicken Rahmen drumherum zu bauen. Davon abgesehen, bin ich in der glücklichen Situation nicht selbständig zu sein und keine browserbasierten Applikationen herstellen zu müssen. Meine Applikation muss gemäß MPDG und einem Stapel Normen entwickelt sein, da fallen Spirenzchen wie Browser schon fast automatisch raus. Es reicht da auch nicht, nur zu schreiben die Software sei sicher, das muß entsprechend unabhängig belegt werden.

Sherlock

[QuickAndDirty]

"Das Programm braucht keinen privilegierten Zugriff, ist also sicher!"

[Gausi]

Zitat:

Zitat von QuickAndDirty (Beitrag 1527874)

"Das Programm braucht keinen privilegierten Zugriff, ist also sicher!"

Ich glaube kaum, dass man mit diesem Argument einen auf Sicherheit fixierten IT-Admin überzeugen kann. :lol:

"Zum Starten des Autos braucht man keinen Führerschein. Also ist es sicher." (Ich liebe hinkende Auto-Vergleiche.)

[masc-online]

Zitat:

Zitat von Gausi (Beitrag 1527882)

Zitat:

Zitat von QuickAndDirty (Beitrag 1527874)

"Das Programm braucht keinen privilegierten Zugriff, ist also sicher!"

Ich glaube kaum, dass man mit diesem Argument einen auf Sicherheit fixierten IT-Admin überzeugen kann. :lol:

"Zum Starten des Autos braucht man keinen Führerschein. Also ist es sicher." (Ich liebe hinkende Auto-Vergleiche.)

Beim ursprünglichen Zitat fehlt hoffentlich nur das Zwinker-Smiley. Ansonsten dürfte die Aussage gar keinen IT-Admin überzeugen. Auch ohne Admin-Rechte kann man genügend Schindluder treiben (Stichwort Ransomware).

Bei solchen Fragen geht es in der Regel weniger darum darzulegen, dass eine Software, die mit Programmiersprache A programmiert wurde, mehr oder weniger fehleranfällig ist, als eine Anwendung, die mit Programmiersprache B entwickelt wurde. Man soll nur darlegen, dass man weiß

• Was die Anwendung macht
• Was drin steckt
• Es eine verantwortliche Person oder Firma gibt, die sich um den Lifecycle der Anwendung kümmert

Es hilft / ist in der Regel ausreichend, wenn man den entsprechend interessierten Personen darlegen kann:

• In welcher Frequenz neue Versionen veröffentlich werden (gerne inkl. Changelogs)
• Ein Fehlertracking / Support Tool im Einsatz zu haben
• Eine Erreichbarkeit im Problemfall sicherzustellen
• Welche Bibliotheken verwendet werden
  • Klingt erstmal lästig, aber eigentlich sollte man 3rd-Party-Komponenten schon aus Eigeninteresse inkl. Quelle dokumentieren
  • Wenn man nicht jeden Kleinkram angeben will (und auch aus bspw. Lizenzgründen nicht muss), sollten in der Liste zumindest die größeren Kandidaten auftauchen (bspw. Synopse mORMot, JEDIs, TMS VCL UI Pack, etc.)
  • Insbesondere eingebettete Browser sind inkl. Version anzugeben
  • Programme Dritter, die man mit ausliefert, inkl. Version und Lizenz angeben
  • Wenn man schon nicht selbst jeder Release-Note der entsprechenden Pakete hinterherlaufen will, kann die anfragende Person aufgrund der Infos auf Wunsch selbst ein CVE-Tracking der genutzten Pakete durchführen und dem Anwendungsentwickler bei Bedarf auf die Füße treten und anfordern, dass die Software entsprechend aktualisiert wird

Wenn alles nichts hilft, kann man noch einen Pentest für die Anwendung beauftragen, was aber dann auch kostet. Aber dann hätte man (wenn's gut läuft) im Anschluss in der Regel ein Schriftstück, in dem vermerkt ist, dass keine Probleme wie SQL-Injektions, unverschlüsselte Passwörter, Memory Leaks, etc. gefunden wurden. Oder man hat eine Liste mit offenen Punkten und weiß, was man noch zu verbessern hat. ;-)