Geplant vs. umgesetzt: Die Lücke überprüfen

Zweck

Ein Linter scannt Code isoliert. Er kann Ihnen sagen, ob der Code intern konsistent ist; er kann Ihnen jedoch nicht sagen, ob der Code das tut, was Sie beabsichtigt haben, da er kein Modell Ihrer Absicht hat. Die schwerwiegendsten Sicherheits- und Korrektheitsfehler liegen in dieser Lücke – eine dokumentierte, aber nie durchgesetzte Berechtigung, ein „cron-only“-Endpunkt, den jeder aufrufen kann, ein als „public-only“ gekennzeichnetes Feld, das private Daten preisgibt.

Diese Fertigkeit ist die Methode, um diese Lücke zu finden. Sie ist das Alleinstellungsmerkmal: Sie funktioniert nur, wenn die Absicht zuvor schriftlich festgehalten wurde (siehe die Fertigkeit „Shipping-Artifacts“), und genau deshalb können Standardtools sie nicht nachbilden.

Kontext

Verwenden Sie diese Funktion, wenn eine dokumentierte Absicht vorliegt – permissions.md, architecture.md, variables.mdusw. Fehlen diese Dokumente oder sind sie veraltet, ist dieses Fehlen selbst bereits der erste Befund: Man kann keine Absicht prüfen, die man nie festgehalten hat. Es wird empfohlen, zuerst zu dokumentieren und dann zu prüfen.

Methode

1. Legen Sie die Absicht fest. Legen Sie die /documentation/*.md als maßgebliche Quelle dafür, was gelten soll: Wer darf auf was zugreifen, welche Grenzen gelten als vertrauenswürdig, welche Daten sind öffentlich? Behandeln Sie die Dokumentation als zu überprüfende Behauptungen, nicht als Beweis.

2. Sammeln Sie Belege für die Umsetzung. Lesen Sie den Code, der jede Behauptung durchsetzt (oder nicht durchsetzt). Ein Beleg ist eine zitierte Datei und Zeile – die tatsächliche Autorisierungsprüfung, der tatsächliche Abfragefilter, der tatsächliche Sanitizer. „Das wird wahrscheinlich weiter oben abgewickelt“ ist kein Beleg; der Codepfad ist es.

3. Vergleichen Sie die Angabe mit dem Code, eine Grenze nach der anderen. Fragen Sie bei jeder dokumentierten Regel: Wird sie tatsächlich an einem Durchsetzungspunkt umgesetzt – auf dem Server, auf jedem Pfad? Misstrauen Sie Kommentaren wie „nur intern“, „nur für Admins“ oder „andernorts validiert“ – überprüfen Sie sie im Code.

4. Klassifizieren Sie jede Abweichung danach, ob sie von Bedeutung ist. Eine Abweichung ist von Bedeutung, wenn ein echter Akteur durch deren Umgehung auf Daten, Geld, Infrastruktur oder einen anderen Mandanten zugreifen kann, auf die er keinen Zugriff haben sollte. Sie ist nicht von Bedeutung, wenn die einzige betroffene Person der Akteur selbst ist, und zwar in Bezug auf seine eigenen Daten. Lassen Sie kosmetische Abweichungen außer Acht; behalten Sie grenzüberschreitende Abweichungen bei.

5. Vermeiden Sie vage Befunde. Jeder Befund muss Folgendes benennen: die dokumentierte Absicht (zitieren Sie die Dokumentation), die implementierte Realität (zitieren Sie den Code), den Angreifer und das Opfer sowie die konkrete Behebung. Wenn Sie nicht beide Seiten der Lücke zitieren können, handelt es sich um eine zu untersuchende Frage, nicht um einen zu meldenden Befund.

Was zählt

• Absicht: eine dokumentierte Regel, Grenze, ein Geltungsbereich oder eine Einstufung als öffentlich/privat.
• Nachweis der Umsetzung: ein zitierter Durchsetzungspunkt (oder dessen nachweisbares Fehlen) im Code.
• Eine relevante Diskrepanz: Die Dokumentation sagt das eine, der Code tut etwas anderes, und der Unterschied überschreitet eine Vertrauens-, Kosten-, Daten- oder Mandantengrenze.

Anmerkungen

• „Dokumentiert, aber nicht durchgesetzt“ ist ein Befund für sich – stufen Sie ihn danach ein, was durch das Aufdecken dieser Diskrepanz zutage tritt.
• „Undokumentiert, aber durchgesetzt“ ist in der Regel in Ordnung, sollte aber gekennzeichnet werden: Die Dokumentation ist mittlerweile veraltet, was die nächste Prüfung schwächt.
• Diese Methode liefert Input für die Sicherheits- und Leistungsaudits; sie ersetzt nicht deren Analyse auf der „Sink“-Ebene – sie ergänzt diese um die Absichtsachse, die dort fehlt.
• Erfinden Sie niemals eine Absicht, um eine Lücke zu konstruieren. Wenn die Dokumentation keine Angaben enthält, geben Sie an, dass die Dokumentation keine Angaben enthält.