Panel-Rückblick: Schlechte Security-Gewohnheiten überwinden mit Corey Quinn

Am 8. Dezember hatten Clinton Herget und Simon Maple, Field-CTOs bei Snyk, die Gelegenheit, sich mit Corey Quinn auszutauschen: Chief Cloud Economist bei The Duckbill Group, Podcast-Host, Kurator von „Last Week in AWS“ und scharfzüngige Twitter-Persönlichkeit.

Das Gespräch nahm einige unterhaltsame Wendungen – von Beschwerden über die einstündige Schlange für einen Kaffee auf der AWS re:Invent bis hin zu Coreys Behauptung, „SBOMs sind reine Fantasie“ (dazu gibt es noch mehr Kontext … lesen Sie weiter). In diesem Blog beleuchten wir einige der wichtigsten Highlights. Wenn Sie jedoch alle Corey-Quinnismen aus dem Gespräch hören möchten, sehen Sie sich hier die gesamte Podiumsdiskussion an.

Erkenntnisse von der AWS re:Invent 2022

Da die AWS re:Invent 2022 gerade zu Ende gegangen war, nahmen sich Corey und Clinton ein paar Minuten Zeit, um ihre wichtigsten Erkenntnisse zu besprechen. Corey betonte, dass es wichtig ist, dem persönlichen Austausch Vorrang vor der Teilnahme an Sessions zu geben.Die Zeit auf der AWS re:Invent ist begrenzt, und Corey nutzt sie gern, um AWS-Mitarbeitende kennenzulernen, statt in Sessions zu sitzen. Schließlich sind die Sessions nach der Konferenz auf Abruf verfügbar – der persönliche Austausch mit AWS-Expertinnen und -Experten dagegen nicht.

Clinton freute sich über die angekündigten Details zur Zusage von Amazon Web Services für ein Open Cybersecurity Schema Framework (OCSF). Mit der Standardisierung eines Sicherheitsframeworks schafft AWS die Grundlage für eine interoperable, maschinenlesbare Sprache zur Beschreibung von Anwendungssicherheit. Clinton sieht darin den ersten Schritt hin zu einem besseren branchenweiten Austausch über gemeinsame Risiken.

Rückblick: AWS-Security-Schrecken des Jahres 2022

Corey Quinn und Clinton Herget blickten ebenfalls auf 2022 zurück und sprachen über einige „Schrecken“ rund um die AWS-Sicherheit, die im neuen Jahr unbedingt angegangen werden müssen. Zu den wichtigsten gehörten:

Die Kluft zwischen Entwicklungs- und Produktionsumgebungen

Laut Clinton ist die Kluft zwischen Entwicklungs- und Produktionsumgebungen eines der größten Probleme der heutigen Softwareentwicklung. Da in der Cloud alles Code ist, müssen Sicherheitsrisiken direkt im Code behoben werden. Er sagt: „Als Betreiber erhalte ich eine große, blinkende, beängstigende rote Warnung: ‚Auf einem Pod in einem EKS-Cluster ist Log4J vorhanden; Sie müssen das beheben.‘ Und dann? Es gibt keine maschinenlesbare und automatisierte Möglichkeit herauszufinden, welche Datei und welches Git-Repository aufgrund dieser Meldung tatsächlich geändert werden müssen.“

Zu viel implizites Vertrauen in die Software-Supply-Chain

Außerdem machten Softwareentwicklungsteams 2022 den Fehler, den Komponenten ihrer Software-Supply-Chain zu sehr zu vertrauen. Statt anzunehmen, dass jede Open-Source-Software und ihre Abhängigkeiten sicher sind, müssen Teams überprüfen, ob die Komponenten von Drittanbietern tatsächlich sicher eingesetzt werden können.

SBOMs, die nicht tief genug gehen

Corey wies außerdem darauf hin, dass die heutigen Software-Stücklisten (SBOMs) nicht ausreichen. Seiner Meinung nach werden sie der Vernetzung moderner Anwendungen nicht gerecht. Bei transitiven Abhängigkeiten kann man sich in einer Kette von „Abhängigkeit einer Abhängigkeit einer Abhängigkeit“ und so weiter verlieren, ohne das Ausmaß der Risiken durch Drittanbieter in der eigenen Anwendung jemals vollständig zu verstehen.

Lösungen für die heutigen Sicherheitsherausforderungen

Clinton und Corey sprachen auch darüber, wie Unternehmen angesichts des nahenden neuen Jahres mit diesen „Schrecken des Jahres 2022“ umgehen sollten. Sie diskutierten:

SBOMs durch weitere Best Practices ergänzen

Was ist also die Lösung, um die heutigen SBOM-Praktiken zu verbessern? Corey Quinn sagte scherzhaft: „Um das wirklich zu beheben, müsste man Menschen patchen.“

Anders gesagt: Die gesamte Software-Supply-Chain zu dokumentieren, löst keine Sicherheitsprobleme. Entscheidend sind eine Veränderung der Unternehmenskultur und die Befähigung von Menschen, Sicherheitsprobleme zu lösen. Dazu gehört vor allem, Sicherheitswarnungen zu reduzieren – also Störsignale zu minimieren, damit Ihr Team die wirklich wichtigen Einträge in der SBOM priorisieren kann.

Clinton ergänzte, dass Unternehmen ihre Open-Source-Nutzung nicht so sehr verbergen sollten. Wenn sie verstehen, dass der Einsatz von Open Source akzeptabel ist und keinen potenziellen Risikofaktor für den Geschäftserfolg darstellt, können Unternehmen viel transparenter darüber sein, welche gemeinsam genutzten Komponenten wo zum Einsatz kommen.

Die bestehenden Prozesse Ihres Unternehmens genau verstehen

Wie hängen Ihre IaC, Ihre Cloud und Ihr Quellcode zusammen? Wie arbeitet Ihr Security-Team mit Ihren Entwicklerinnen und Entwicklern zusammen – und umgekehrt? Welche Kontexte berücksichtigen diese Personen im Alltag? Clinton und Corey betonten, wie wichtig es ist, einen Schritt zurückzutreten und diese Fragen zu beantworten. Das beeinflusst maßgeblich, wie die einzelnen Geschäftsbereiche Risiken wahrnehmen und angehen.

Corey erwähnte außerdem, dass er „sehr zögert, Ratschläge zu geben, die über ‚Verstehen Sie den Kontext, in dem Sie arbeiten, und treffen Sie Entscheidungen, die für Sie sinnvoll sind‘ hinausgehen.“ Deshalb müssen Unternehmen tiefergehende Fragen stellen und die Sicherheits-Best-Practices finden, die zu ihnen passen.

Mit dem Kontext Ihres Entwicklungsteams arbeiten – nicht dagegen

Sicherheit ist oft eine reaktive Disziplin. Corey merkte an, dass Sicherheitsmaßnahmen zwar notwendig sind, Ihr Unternehmen aber nicht auf greifbare Weise voranbringen. Deshalb werden sie oft zurückgestellt. Da die meisten Abteilungen Sicherheit vermutlich so wahrnehmen, müssen Teams Sicherheitsmaßnahmen so reibungslos wie möglich gestalten.

Der SDLC muss mit möglichst wenig manueller Arbeit abgesichert werden. Besonders wenn es darum geht, Entwicklerinnen und Entwickler mit Sicherheits-Best-Practices zu unterstützen, kommt es darauf an, an ihren Kontext anzuknüpfen und zu verstehen, womit sie täglich arbeiten.

Neues Jahr, neue Möglichkeiten für AWS-Sicherheit

Das ist nur ein kleiner Ausschnitt dessen, was Corey und Clinton besprochen haben. Sie nannten zahlreiche Möglichkeiten, die AWS-Sicherheit 2023 zu verbessern – von einem stärkeren Fokus auf Developer-First-Security bis hin zu mehr Transparenz in Software-Supply-Chains und vielem mehr.

Sehen Sie sich unbedingt hier das vollständige Gespräch an. Erfahren Sie außerdem mehr darüber, wie die Developer-Security-Plattform von Snyk Sie dabei unterstützen kann, Ihr Security-Programm 2023 auszubauen.