IRW-PRESS: Scryb Inc. : 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: https://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 https://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!

Die englische Originalmeldung finden Sie unter folgendem Link: 
https://www.irw-press.at/press_html.aspx?messageID=64391
Die übersetzte Meldung finden Sie unter folgendem Link: 
https://www.irw-press.at/press_html.aspx?messageID=64391&tr=1
NEWSLETTER REGISTRIERUNG: 


Aktuelle Pressemeldungen dieses Unternehmens direkt in Ihr Postfach: 
http://www.irw-press.com/alert_subscription.php?lang=de&isin=CA81111V1076

Mitteilung übermittelt durch IRW-Press.com. Für den Inhalt ist der Aussender
verantwortlich.

Kostenloser Abdruck mit Quellenangabe erlaubt.