Scryb Inc.: Cybeats veröffentlicht Highlights aus Episode 6 seiner Live-Webinar-Reihe zur ,Software Bill of Materials’ und zur Zukunft der Automatisierung im Bereich Software Engineering

TORONTO, 24. Februar 2021 – Scryb Inc. (Scryb’ oder das Unternehmen) (CSE: SCYB, OTCQB: SCYRF, Frankfurt: EIY) freut sich, die Höhepunkte der 6. Episode seiner Live-Webinar-Reihe mit dem Titel State of Cybersecurity Industry: SBOMs Illustrate the future of CI/CD pipelines zu veröffentlichen. Die Moderation übernahm Evegniy Kharma, VP of Cybersecurity Solution Architecture bei der Herjavec Group. Zu den Rednern zählten: Chris Blask – VP Strategy bei Scryb; Sanket Panachamia, Lead Architect for Emerging Technologies bei Unisys Global; Stuart Phillips, Product Marketing Director bei Cyber Interos; und Dragos Ruiu, CEO von Dragos Tech. Es folgen Auszüge der wichtigsten Themen des 6. Live-Webinars:

Frage 1. Was kam vor den SBOMs? Was führte zu ihrer Entwicklung? Wie wurde der Softwarebestand früher erfasst?

Sanket Panchamia (3:00)
SBOMs gibt es schon eine ganze Weile, der Begriff ist also nicht neu. Früher gab es allerdings keine standardisierte Methode, um dem Kunden Informationen darüber zu geben, was in seinem Softwarepaket enthalten ist. Es ist im Grunde nichts anderes als eine Art Zutatenliste. Bisher wurden Readme-Dateien und PDF-Dokumente verwendet, die Aufschluss darüber geben, was in der Software steckt. Das war damals und bis heute der Stand der Dinge bei den SBOMs, bevor es zu dieser Durchführungsverordnung kam, die uns vorgibt, wie wir diese Informationen mit anderen teilen sollen und wie wir diese SBOMs erstellen können, die dann an die nachgelagerten Kunden weitergereicht werden. Es gab im Wesentlichen keine Standardisierung, nur Dokumente, die weitergegeben wurden. Es gab keine vernünftige Möglichkeit, diese PDF-Dateien zusammenzuführen oder zu verwalten. In der Regel wurden die PDF-Dateien von Personen erstellt, die nicht am gesamten Lebenszyklus der Softwareentwicklung (SDLC) beteiligt waren. Sie wurden von Leuten erstellt, die für die Auslieferung der Software zuständig sind. Sie waren daher bisweilen fehlerhaft oder unvollständig.

Frage 2. Wo muss eine SBOM innerhalb der CI/CD-Pipelines (kontinuierliche Softwareentwicklung) erzeugt werden?

Dragos Riui (12:05)
Ich denke, im Falle von CI/CD-Stacks idealerweise als Teil der Software und des Build-Prozesses. Nachdem alles upgedatet wird, sollte die SBOM jedes Mal, wenn ein neuer Build herausgegeben wird, im Leistungsumfang der CI/CD-Pipeline enthalten sein, da sich ja ständig etwas ändert. Wenn Sie in regelmäßigen Abständen Snapshots erstellen, sind Sie mit ziemlicher Sicherheit nicht auf dem neuesten Stand, und dieser Prozess ist vermutlich fehleranfällig. Langfristig ist die Automatisierung die wirklich ultimative Lösung. Es geht darum, den Menschen die eher mühsamen Dinge und die Nachverfolgung abzunehmen und ihnen Werkzeuge zur Verfügung zu stellen, damit ein Weiterreichen von Informationen an die jeweiligen Kunden und an deren Kunden etc. möglich wird. Ich persönlich bin der Meinung, dass man sich mit Snapshots mehr Arbeit aufhalst als unbedingt nötig. Tatsächlich lässt sich das Problem nur über einen maschinellen Ansatz lösen.

Stuart Phillips (7:45)
Log4j ist in den meisten Java-Programmen, die über ein Logging (Protokollierung) verfügen, enthalten, und man kann sich dann die Downloads und die bereitgestellten Informationen ansehen. Aber ein Großteil der Software kann anonym heruntergeladen werden. Die Herausforderung besteht darin herauszufinden, welche Versionen verfügbar sind und welche veraltet. Wenn ich eine SBOM hätte, die auch tatsächlich so funktioniert wie sie soll, müsste ich eigentlich in der Lage sein, sehr rasch eine einfache Abfrage über die Software und die innerhalb der Organisation eingesetzten Anwendungen durchzuführen um zu wissen, welche Versionen von Log4j vorhanden sind, ob es sich um veraltete Versionen handelt, und könnte dann eine entsprechende Priorisierung für Patches, Updates, Schadensbegrenzung oder Austausch vornehmen. [] Das sollte sehr einfach sein, aber im Moment ist es sehr schwierig.

Chris Blask (10:30)
SBOMs sind eine Art Bescheinigung zu einem bestimmten Zeitpunkt über eine bestimmte Sache […]. Viele dieser Bescheinigungen beziehen sich auf Dinge, die einfach nur operativer Natur sind, so etwa Wie kann ich alle Eventualitäten überblicken’, Es dauert zu lange, Es braucht zu viel Zeit, Es kostet zu viel, oder Bin ich profitabler, produktiver und wettbewerbsfähiger, wenn ich dieses Tracking-System hinzufüge? SBOM ist nur die Spitze des Eisbergs, die wir im Moment sehen. Aber das Ganze ist ein langfristiger Prozess und da kommt noch mehr.

Frage 3: Denken Sie, dass die moderne DevOps-Praxis für die Erstellung von SBOMs verantwortlich sein sollte?

Stewart Phillips (22:00)
Nun, in der aktuellen Durchführungsverordnung werden die SBOMs direkt hervorgehoben. Wir sehen also, dass SBOMs propagiert werden. Wenn man sich die CISA-Mitteilung zu Log4j anschaut, dann heißt es dort, wenn wir SBOMs hätten, wäre es einfacher, damit umzugehen. Es gibt also definitiv einen Druck seitens der US-Bundesregierung und anderer Organisationen, SBOMs zu forcieren. Wenn ich nicht an die Air Force, FAA oder staatliche bzw. kommunale Behörden verkaufen kann, weil ich keine SBOM habe, dann ist das ein entscheidender Beweggrund. Außerdem schafft es einheitliche Rahmenbedingungen, weil es nun jeder machen muss.

Dragos Ruiu (27:05)
Ich denke, man sollte unterscheiden, wo sie sich im Moment befindet und wo sie sich befinden sollte, denn im Moment ist dieses Material ein ganz wesentlicher Input für die Sicherheitsprüfung. Bei jeder Sicherheitsprüfung gehört es zum standardmäßigen Prozedere zu überprüfen, ob es veraltete Versionen gibt. Derzeit wird ein Großteil dieser Verantwortung, vor allem in kleineren Unternehmen, an externe Berater und Leute, die für die Sicherheitsprüfungen zuständig sind, abgegeben. Wenn Sie also vertraglich dazu verpflichtet sind, Ihren Anbieter zu fragen, ob Sie Ihre Sicherheitsauflagen erfüllen, dann gehört dazu auch die Überprüfung Ihrer SBOM und die Suche nach anfälligen Komponenten etc. Das alles gehört im Moment zum Audit. Wo es aber tatsächlich angesiedelt sein sollte, das ist eine andere Frage. Aus meiner Sicht sollte es zu den DevSecOps und zum zentralen Workflow des gesamten F&E-Teams gehören.

Sanket Panchamia (28:15)
An einem bestimmten Punkt wird sich diese ganze DevOps-Praxis mehr in Richtung Automatisierung bewegen. Bis September gab es keine Standardisierung der SBOM, und nun gibt es SPDX als eines der ISO-zertifizierten Formate, mit dem man SBOMs erstellen und mit den nachgelagerten Kunden teilen kann. Und jetzt, wo es diesen Standard gibt, ist eine ganze Menge Automatisierung im Spiel. Ja, es liegt in der Verantwortung Ihres DevSecOps-Teams sicherzustellen, dass Ihre SBOM vollständig ist und keine bekannten Schwachstellen aufweist, zumindest nicht die besonders kritischen. Aber viele Unternehmen gehen dazu über, dieses Prozedere zu automatisieren, sodass es nicht mehr nur eine verantwortliche Person gibt, sondern ein Verfahren, das Teil der Praxis wird. Etwas, das einfach passiert, wo man sich keine Sorgen machen oder darüber nachdenken muss. So sehen es die Leute derzeit, das ganze Konzept der Erstellung von SBOMs und die Verantwortung, die damit verbunden ist.

Stuart Phillips (42:10)
Ich kann mit absoluter Sicherheit wissen, welche Software-Versionen welche Log4j-Versionen enthalten. So, wie es aktuell gehandhabt wird, müssten die meisten Unternehmen im Bereich der Entwicklung alles durchgehen und testen, oder in den Protokollen nachsehen, oder ein Log4j-Tool zur Schwachstellenbewertung über die verschiedenen Software-Versionen laufen lassen, um so etwas wie zuverlässige Regeln aufzustellen. Ich denke also, dass die interne Nutzung der SBOM für die eigenen Prozesse zu einer signifikanten Kostensenkung und auch zu einer deutlichen Verbesserung in der Qualität und des Produkts führen könnte.

Frage 4: Wie wollen Sie all diese Lieferketten-Bescheinigungen in die bestehende CI/CD-Pipeline einbinden?

Sanket Panchamia (47:05)
Das Erzeugen von SBOMs ist eine Sache, die einen Teilbereich des Problems löst. Bei der Informationsweitergabe spielen wir in einer ganz anderen Liga. Wie kann man diese Informationen in einer kontinuierlichen Form an die Kunden weitergeben? Wir bewegen uns hin zu SAS und sich ständig weiterentwickelnden Softwarepaketen. Wie stellen Sie also sicher, dass die von Ihnen generierten und weitergegebenen SBOMs auf dem aktuellen Stand sind? Wenn wir über SBOMs sprechen, geht es nicht nur um die Software, sondern auch um die dahinterliegende Infrastruktur, die Umgebung, in der sie erstellt wurde, und die damit verbundenen Schwachstellen, denn darauf kommt es am Ende an. Wenn man sich mit Schwachstellen befasst, geht es nicht nur um das Softwarepaket selbst, sondern auch um das ganz Drumherum. Das ist ganz entscheidend für alle Bescheinigungen in der gesamten Lieferkette. Es wird jetzt ernsthaft darüber nachgedacht. Seit ich in diesem Bereich tätig bin, war das ganze Konzept der SBOMs und der Weitergabe von Bescheinigungen ein Nebenprodukt des Entwicklungszyklus. Jetzt hat das Ganze stark an Dynamik gewonnen und ist zum Mainstream geworden. Jetzt schaut man ganz bewusst darauf, wie diese Bescheinigungen erstellt werden, wie man sie gemeinsam nutzt und weiterreicht, wie man sie standardisiert. Und wenn das alles erledigt ist, wie man sie in die bestehende CI/CD-Pipeline einfügt. Ich bin mir ziemlich sicher, dass die meisten Unternehmen mit der CI/CD-Pipeline arbeiten, das ist nichts Neues für sie. Also versuchen sie, Dinge zu automatisieren, damit sie das nicht mehr manuell machen müssen. Sie wollen ein Verfahren und eine Praxis festlegen, es einfach geschehen lassen und sich nicht mehr darum kümmern müssen.

Frage 4: Welche Vorteile wollen die Softwareentwickler mit der CI/CD-Entwicklung erzielen?

Dragos Ruiu (50:30)
Dinge wie Veracode und Static Analyzers – es gibt eine Menge Tools, die in die CI/CD-Pipelines eingebaut werden können, die einmalig einen hohen Aufwand und eine entsprechende Intensität erfordern. Wenn man ältere und manuell erstellte Prozesse verwendet, kann man in der Entwicklung eine ganze Menge von Automatisierungsschritten einführen, die einem in weiterer Folge zahlreiche Sicherheitsprüfungen ersparen. Statische Analysetools sind die erste und sichtbarste Komponente. Aber es gibt auch viele Dinge, die man ziemlich billig bekommt, im Gegensatz zu einer eigenen Abteilung für Qualitätskontrolle oder der Verwendung älterer, manueller Prozesse. Und das ist für mich das Verkaufsargument, dem die meisten Leute ihre Aufmerksamkeit schenken werden […]. Aus meiner Sicht, als externe Momentaufnahme des Unternehmens, beobachte ich, dass fast alle zu dieser Sichtweise wechseln. Es gibt nicht viele Leute, die hier nicht mitmachen.

Über Cybeats
Cybeats liefert intelligente Sicherheitsanwendungen für Software-Lieferketten und IoT-vernetzte Geräte, die Cyber-Bedrohungen autonom in Echtzeit erkennen und eliminieren. Cybeats – Software made certain.

Webseite: www.cybeats.com

ABONNIEREN: Weitere Informationen und die Möglichkeit, sich in die Mailingliste des Unternehmens einzutragen, finden Sie unter: www.scryb.ai

Über Scryb
Scryb ist eine Plattform, die Unternehmen und Technologien mit angewandter Intelligenz, Echtzeitanalysen und umsetzbaren Erkenntnissen unterstützt. Die Plattform bietet bewährte Anpassungsfähigkeit in verschiedenen Märkten, von digitaler Gesundheit und Diagnose bis hin zu Cybersicherheit und Fertigung. Die Cloud-basierte Plattform besteht aus entscheidenden Elementen, darunter Sensortechnologie, IoT, Predictive Analytics und Computer Vision.

Weitere Informationen finden Sie auf unserer Webseite unter www.scryb.ai.

Kontakt:
W. Clark Kent
President
Büro. 647-872-9982
Gebührenfreie Rufnummer: 1-844-247-6633
E-Mail: info@scryb.ai

Bernhard Langer
EU Investor Relations
Office: +49 (0) 177 774 2314
Email: blanger@scryb.ai

Vorsorglicher Hinweis bezüglich zukunftsgerichteter Informationen
Abgesehen von Aussagen zu historischen Tatsachen enthält diese Pressemitteilung bestimmte zukunftsgerichtete Informationen im Sinne der einschlägigen Wertpapiergesetze. Zukunftsgerichtete Informationen erkennt man häufig anhand von Begriffen wie planen”, erwarten”, prognostizieren, beabsichtigen, glauben, vorhersehen, schätzen und an anderen ähnlichen Wörtern oder Aussagen darüber, dass bestimmte Ereignisse oder Bedingungen eintreten können oder werden. Zukunftsgerichtete Aussagen basieren auf den Meinungen und Schätzungen zum Zeitpunkt der Äußerung dieser Aussagen und unterliegen einer Reihe von Risiken und Ungewissheiten sowie anderen Faktoren, die dazu führen könnten, dass sich die tatsächlichen Ereignisse oder Ergebnisse erheblich von jenen in den zukunftsgerichteten Informationen unterscheiden. Dazu zählen unter anderem auch Verzögerungen oder Unsicherheiten bei den behördlichen Genehmigungen, wie z.B. durch die CSE. Zukunftsgerichtete Informationen enthalten typischerweise Unsicherheiten, wie etwa auch Faktoren, auf die das Unternehmen keinen Einfluss hat. Es gibt keine Gewähr dafür, dass die in dieser Pressemeldung beschriebenen Vermarktungspläne für die Technologie tatsächlich zu den hier dargelegten Bedingungen und in dem hier dargelegten zeitlichen Rahmen in Kraft treten werden. Das Unternehmen ist nicht verpflichtet, zukunftsgerichtete Informationen zu aktualisieren, falls sich die Umstände oder die Schätzungen oder Meinungen des Managements ändern sollten, es sei denn, dies wird in den entsprechenden Gesetzen gefordert. Den Lesern wird empfohlen, sich nicht vorbehaltslos auf zukunftsgerichtete Aussagen zu verlassen. Weitere Informationen über Risiken und Unsicherheiten, welche die Finanzergebnisse beeinflussen könnten, sind in den Unterlagen enthalten, die das Unternehmen bei den kanadischen Wertpapierbehörden einreicht und die unter www.sedar.com veröffentlicht werden.

Die Ausgangssprache (in der Regel Englisch), in der der Originaltext veröffentlicht wird, ist die offizielle, autorisierte und rechtsgültige Version. Diese Übersetzung wird zur besseren Verständigung mitgeliefert. Die deutschsprachige Fassung kann gekürzt oder zusammengefasst sein. Es wird keine Verantwortung oder Haftung für den Inhalt, die Richtigkeit, die Angemessenheit oder die Genauigkeit dieser Übersetzung übernommen. Aus Sicht des Übersetzers stellt die Meldung keine Kauf- oder Verkaufsempfehlung dar! Bitte beachten Sie die englische Originalmeldung auf www.sedar.com, www.sec.gov, www.asx.com.au/ oder auf der Firmenwebsite!