Zu den zahlreichen Tools des Kaspersky-Portfolios geh\u00f6rt eine spezielle Plattform f\u00fcr den Schutz von Container-Umgebungen. In diesem Artikel m\u00f6chte ich jedoch nicht als Vertreter des Herstellers \u00fcber Kaspersky Container Security (KCS) sprechen, sondern als Mitglied eines Teams, das diese L\u00f6sung aktiv und tagt\u00e4glich einsetzt. Unser Produktsicherheitsteam ist daf\u00fcr verantwortlich, im gesamten Unternehmen sichere Entwicklungsprozesse zu etablieren. Wir sind in jeder Phase der Softwareentwicklung dabei, und wir helfen den Produktteams, Sicherheitsprobleme fr\u00fchzeitig zu erkennen, damit Produkte p\u00fcnktlich nach Zeitplan ver\u00f6ffentlicht werden k\u00f6nnen. Dazu haben wir verschiedene Workflows entwickelt, von denen sich einer speziell auf die Container-Sicherheit konzentriert. Und genau dabei setzen wir auf unsere eigene Plattform: Kaspersky Container Security.<\/p>\n
Unter Container Security-L\u00f6sungen stellt man sich in erster Linie Image-Scanner f\u00fcr die Container-Registry vor. Kaspersky Container Security (KCS) ist jedoch eine umfassende Sicherheitsplattform f\u00fcr Container-Umgebungen und \u00fcbernimmt aufgrund ihrer Ende-zu-Ende-Integration in den Container-Workflow mehrere Aufgaben. Obwohl KCS nat\u00fcrlich ein Szenario zur Container-Untersuchung enth\u00e4lt (was zweifellos wichtig ist), zeigt unsere Erfahrung, dass sich der wahre Wert von KCS erst dann deutlich zeigt, wenn es an mehreren Stellen im Workflow gleichzeitig integriert wird:<\/p>\n
Dies ist eigentlich ein standardm\u00e4\u00dfiger Vorgang. KCS untersucht Images auf f\u00fcr Container typische Probleme: bekannte Schwachstellen, Malware, hartcodierte Geheimnisse und fehlerhafte Konfigurationen. Die Untersuchung ergibt jedoch nicht nur ein einzelnes, abstraktes Verdikt. Basierend auf den Ergebnissen berechnet das System eine Risikoeinstufung, die ein klares Bild \u00fcber die Sicherheitslage des Untersuchungsobjekts liefert. In der Praxis ist dies unheimlich n\u00fctzlich: Die Teams bekommen nicht nur die Meldung \u201eschlechtes Image\u201c, sondern erfahren ganz genau, worauf das Risiko beruht und was zuerst behoben werden sollte.<\/p>\n
Das ist aber l\u00e4ngst nicht alles. KCS eignet sich auch f\u00fcr Szenarien, in denen es nicht ausreicht, ein Problem einfach zu finden, sondern wenn das Problem auch mit dem Lebenszyklus des Artefakts verkn\u00fcpft werden muss. Wenn ein Team Hunderte von Builds verwaltet, ist eine regelm\u00e4\u00dfige Untersuchung der Registry nicht ausreichend und erfordert fast immer manuelles Eingreifen. Man muss wissen, welche Pipeline das Risiko verursacht hat, welche Richtlinien ausgel\u00f6st wurden und wie das weitere Vorgehen aussieht. KCS bietet diese wichtigen M\u00f6glichkeiten.<\/p>\n
Eine weniger bekannte KCS-Funktion ist die vollst\u00e4ndige Untersuchung innerhalb von CI\/CD-Pipelines. F\u00fcr unser Team ist dies die effektivste Methode zur Nutzung von KCS. Die Logik ist simpel: Der Scanner wird in die Pipeline integriert, und die Untersuchungsergebnisse erscheinen direkt in den Ausf\u00fchrungsprotokollen. Au\u00dferdem werden sie an die zentrale Konsole der L\u00f6sung gesendet und dort in einem dedizierten CI\/CD-Abschnitt protokolliert. Dabei werden die Ergebnisse mit dem Artefaktnamen, der Untersuchungszeit, der Pipeline und dem Schweregrad verkn\u00fcpft.<\/p>\n
In einer CI\/CD-Umgebung k\u00f6nnen Images aus tar-Archiven oder direkt aus Git-Repositorys untersucht werden. Standardm\u00e4\u00dfig werden GitLab, Jenkins, TeamCity und GitHub Actions unterst\u00fctzt. KCS l\u00e4sst sich aber praktisch in jeden Pipeline-Orchestrator integrieren.<\/p>\n
Ein weiterer wichtiger Aspekt beim Einsatz von KCS in CI\/CD sind Sicherheitsrichtlinien. Unsere L\u00f6sung verwendet ein Modell, bei dem Richtlinien nicht nur das Erfassen von Ergebnissen erm\u00f6glichen, sondern auch das Verhalten der Pipeline steuern. Dies ist praktisch f\u00fcr gestaffelte Rollouts. Du kannst im \u00dcberwachungsmodus beginnen und, falls Geheimnisse, kritische Fehlkonfigurationen oder Schwachstellen ans Tageslicht kommen, die fehlerhaften Builds schrittweise unter die Lupe nehmen. Dieser evolution\u00e4re Ansatz funktioniert generell besser, als einfach nur einen Schalter umzulegen, um alles auf einen Schlag zu blockieren.<\/p>\n
Da wir zur Kompositionsanalyse unser eigenes System verwenden, betrachten wir KCS nicht als einzige Quelle der Wahrheit. Es dient in unseren Workflows vielmehr als leistungsstarke zus\u00e4tzliche Ebene. Und genau hier entfaltet es den gr\u00f6\u00dften Nutzen.<\/p>\n
W\u00e4hrend unser internes Kompositionsanalyse-System das Komponenten-Tracking, die Abh\u00e4ngigkeiten und die Risikobewertung auf Code-Ebene \u00fcbernimmt, sorgt KCS hervorragend f\u00fcr den Schutz des Container-Perimeters. Es k\u00fcmmert sich um die technische Image-Untersuchung und die CI\/CD-Sicherheit, wobei Berichte \u00fcber Container-Artefakte aggregiert werden. Dieses Vorgehen steht nicht im Widerspruch zu unserer internen Analyse, sondern unterst\u00fctzt es genau dort, wo Container in echten Workflows genutzt werden.<\/p>\n
F\u00fcr uns ist dies in zwei Szenarien besonders n\u00fctzlich. Erstens: F\u00fcr die Artefaktkontrolle in einem fr\u00fchen Stadium der Entwicklung. Zweitens: KCS fungiert w\u00e4hrend der Release-Annahme als T\u00fcrh\u00fcter. Wir diskutieren nicht mehr irgendwann nach dem Release \u00fcber Risiken. Nein, wir fangen Risiken genau an dem Punkt ab, an dem das Team ohne umst\u00e4ndliche Genehmigungsketten noch schnell eine Dockerfile, ein Helm-Diagramm oder Einstellungen fixen kann.<\/p>\n
Ebenfalls bemerkenswert ist die Art und Weise, wie Software-St\u00fccklisten (SBOM) gehandhabt werden. Unser System st\u00fctzt sich prim\u00e4r auf aktuelle, relevante SBOMs. KCS bietet spezielle Modi f\u00fcr die SBOM-Verarbeitung und kann Untersuchungsergebnisse sogar im gleichen Format ausgeben. In dieser Hinsicht f\u00fcgt sich KCS nahtlos in unsere internen Prozesse ein, sodass wir es in unsere bestehenden Workflows integrieren k\u00f6nnen (und nicht umgekehrt).<\/p>\n
Eine weitere leistungsstarke Ebene ist die Cluster-Sicherheit. In dieser Phase agiert KCS nicht nur als ein reines Tool zur Image-Untersuchung. Es bietet Laufzeitrichtlinien f\u00fcr Container und Knoten, \u00dcberwachungs- und Blockiermodi sowie eine Auswahl von Sicherheitsprofilen. In anderen Worten: KCS kann nicht nur dazu verwendet werden, Schwachstellen in einem Image zu finden, sondern auch um zu \u00fcberwachen, was der Container tats\u00e4chlich tut, sobald er live ist. Richtlinien k\u00f6nnen die Herkunft von Images, digitale Signaturen, Beschr\u00e4nkungen f\u00fcr Funktionen und Volumes ber\u00fccksichtigen und dar\u00fcber hinaus auch die Prozesse und Netzwerkverbindungen, die innerhalb des Containers ausgef\u00fchrt werden.<\/p>\n
Sobald ein Problem erkannt wird, k\u00f6nnen die Ergebnisse erst einmal im \u00dcberwachungsmodus protokolliert werden, anstatt den Vorgang sofort zu blockieren. In Produktionsumgebungen ist dies immer der kl\u00fcgere Schritt. Ein weiteres wichtiges Werkzeug ist die Gew\u00e4hrleistung der vertrauensw\u00fcrdigen Image-Herkunft. KCS unterst\u00fctzt die Verifizierung digitaler Signaturen. Dadurch verlagert sich der Fokus von der einfachen CVE-Suche auf den Schutz der gesamten Software-Lieferkette eines Unternehmens.<\/p>\n
KCS meldet nicht nur die erkannten Probleme. Es dient auch als umfassende Berichtsquelle. Es kann Berichte \u00fcber Images, akzeptierte Risiken und Kubernetes-Benchmarks erstellen.<\/p>\n
Die generierten Berichte sind in den Formaten HTML, PDF, CSV, JSON und XML verf\u00fcgbar, mit spezieller SARIF-Unterst\u00fctzung f\u00fcr ausf\u00fchrliche Berichte\u00a0\u2013 ideal f\u00fcr die Integration in AppSec-Workflows. Wie bei den bereits genannten SBOMs k\u00f6nnen die Untersuchungsszenarien Artefakte und Ergebnisse im CycloneDX- und SPDX-Format ausgeben\u00a0\u2013 ein weiterer Pluspunkt f\u00fcr die Integration in bestehende Prozesse.<\/p>\n
Einfach gesagt: KCS erg\u00e4nzt unsere Workflows perfekt\u00a0\u2013 nicht weil es jedes einzelne Problem adressiert, sondern weil es sich sehr gut in Entwicklungsszenarien integriert.<\/p>\n
Au\u00dferdem wissen wir zu sch\u00e4tzen, dass das Produktteam unser Feedback umsetzt. Das KCS-Team nimmt unsere Vorschl\u00e4ge aus der Praxis wirklich in seine Entwicklungs-Roadmap auf. Aufgrund unserer praktischen Erfahrungen wurden KCS beispielsweise eine tiefe SBOM-Integration und bestimmte Berichtstypen hinzugef\u00fcgt.<\/p>\n
Fazit: Bei fachgem\u00e4\u00dfer Integration tr\u00e4gt Kaspersky Container Security dazu bei, mehrere Bereiche gleichzeitig abzudecken: von der grundlegenden Container-Untersuchung bis hin zur CI\/CD- und Cluster-Sicherheit. Unserer Erfahrung nach bringt es in einem \u201elebendigen\u201c Container-\u00d6kosystem einen echten Mehrwert. Weitere Informationen \u00fcber die L\u00f6sung findest du auf der offiziellen KCS-Seite<\/a>.<\/p>\n\n","protected":false},"excerpt":{"rendered":" Wie wir Kaspersky Container Security bei Kaspersky einsetzen und warum es f\u00fcr uns viel mehr ist als ein reiner Image-Scanner<\/p>\n","protected":false},"author":2738,"featured_media":33504,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1848,3107,3108],"tags":[4272,3610,4271],"class_list":{"0":"post-33503","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-ci-cd","11":"tag-container","12":"tag-container-security"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/container-security-not-only-a-scanner\/33503\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/container-security-not-only-a-scanner\/30719\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/container-security-not-only-a-scanner\/25770\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/container-security-not-only-a-scanner\/30568\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/container-security-not-only-a-scanner\/41860\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/container-security-not-only-a-scanner\/55771\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/container-security-not-only-a-scanner\/30657\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/container-security-not-only-a-scanner\/36227\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/container-security-not-only-a-scanner\/36120\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.de\/blog\/tag\/container\/","name":"Container"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/33503","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/users\/2738"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/comments?post=33503"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/33503\/revisions"}],"predecessor-version":[{"id":33506,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/33503\/revisions\/33506"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/33504"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=33503"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=33503"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=33503"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}