(MENAFN- Newsfile Corp) Cybeats Provides Highlights from Episode 6 of Its Live Webinar Series; Software Bill of Materials and the Future of Automation in Software Engineering
Toronto, Ontario--(Newsfile Corp. - February 24, 2022) - Scryb Inc. (CSE: SCYB) (OTCQB: SCYRF) (FSE: EIY) ('Scryb'' or the 'Company') is pleased to provide its 6th live webinar episode highlights titled 'State of Cybersecurity Industry: SBOMs Illustrate the future of CI/CD pipelines,' which was moderated by Evegniy Kharma, VP of Cybersecurity Solution Architecture at Herjavec Group. Speakers included Chris Blask - VP Strategy at Scryb, Sanket Panachamia, Lead Architect for Emerging Technologies at Unisys Global, Stuart Phillips, Product Marketing Director at Cyber Interos, and Dragos Ruiu, Ceo of Dragos Tech. Below is highlighted excerpts from 6th Live Webinar:
Q1. What came before SBOMs? What led up to it? How was software inventory previously tracked?
Sanket Panchamia (3:00)
'SBOM's have been here for a while, it's not a new term, but before there was no standard way to share this information to your downstream customer as to what goes inside your package. It's essentially nothing but an ingredient list, we've had readme files and pdf documents as to what goes inside your software. That at the time, and until now, was the current state of SBOMS, until we had this executive order that taught us how we want to share that information and how to create these SBOMS to share with downstream customers. In essence, there was no standardization, just documents being shared before. There was no good way of aggregating or managing those PDF files. Typically, the PDF files were created by people not involved in the entire software development life cycle (SDLC). It was done by folks who deliver the software, so sometimes it could be error-prone or not complete.'
Q2. Where does SBOM need to be generated in CI/CD (Continuous Software Development) pipelines?
Dragos Riui (12:05)
'I think for CI/CD stacks it should, in an ideal world, be built as part of your software and part of your build process. As you update everything, your SBOM should be one of the deliverables of your CI/CD pipeline everytime you release a new build because it's constantly mutating. If you're going to snapshot it at periodic intervals you're almost guaranteed to be out of date and it's probably a process that is going to be error-prone. Automating it in the long term is the final real solution, trying to remove some of the drudgery and tracking from humans and provide tools, so that they can be delivered to their customers and their customers and so on down the chain. I personally think that if you're going to use snapshots you're probably doing more work than you ought to. It really needs a machine approach to the problem.'
Stuart Phillips (7:45)
'Log4j is prevalent in most Java software that has logging and you are able to look at the downloads and information provided, but a lot of the software can be downloaded anonymously. The challenges are [...] trying to figure out which versions are available and which are obsolete. If I had an SBOM and the way that an SBOM is supposed to work, I should be able to very quickly run a simple query across the software and applications that we're using within the organization and know what versions of Log4j are there, if they are the obsolete versions, and be able to prioritize those for patching, updating, mitigation, or replacement. […] It should be very simple to do that and right now it is very difficult.'
Chris Blask (10:30)
'SBOM's are an attestation at a given point in time about a thing [...] a lot of those attestations come down to things that are just operational; 'how can I track the contingencies', 'its taking too long', 'its taking too much time', 'its costing too much.' 'Can I be more profitable, productive, and competitive if I add this system of tracking?' SBOM is the tip of the iceberg we happen to see now, but it's coming for a long time and there's more to it.'
Q3: Do you think Modern DevOps practice should be responsible for creating SBOM?
Stewart Phillips (22:00)
'Well in the recent executive order, they highlight SBOMS directly, so we see that there is a drive to SBOM, in fact if you look at the CISA announcement about Log4j, they said if we had SBOM this would be easier to deal with, so there is definitely a push from the US Federal Government and from other organizations to drive SBOM … if I can't sell to the Air Force, FAA, state or local governments unless I have a SBOM, that's a big driver and it also levels the playing field because now everybody has to do it.'
Dragos Ruiu (27:05)
'I think a distinction should be made about where it lives right now and where it should live, because right now, this kind of material is bread and butter for security audits. Every security audit, one of the standard items is, let's check if you have any outdated versions. Right now, a lot of that responsibility, especially in smaller organizations is going to outside consultants and folks doing the security audits, so when the contract calls for you to ask your vendor if you have done your security audit, part of that is checking your SBOM and looking for vulnerable components, etc - that is going into the auditing function right now. Where should it be - that's a different question, I think you need to bring it into DevSecOps and the mainline workflow of the whole R&D Team.'
Sanket Panchamia (28:15)
'At some point this whole DevOps practice - it's more moving towards the automation side of things. Previously, until September there was no standardization of SBOM and now you have SPDX as one of the formats that's being ISO-certified through which you can create and share SBOMs with your downstream customers. And now, since that standard has come, there's a lot of automation around it. Yes, it's a responsibility of your DevSecOps team to make sure your SBOM is complete, and it does not have vulnerabilities that are known, at least not the high-end critical ones, but many companies are moving towards automating this, so there's not one responsible person, it's a process in place where it's becoming part of their practice, it's something that just happens, you really dont worry or have to think about it. That's how people are thinking about this now, the whole concept of creating SBOMS and the responsibility for it.'
Stuart Phillips (42:10)
'I can know with absolute certainty what versions of software have what versions of Log4j, the way we do it now, most companies in development, they would have to go through and test or look in the logs or have to run some Log4j vulnerability assessment tool against the various versions of software in order to create some sort of reliable rules. So I think using SBOM internally for your own processes could have a significant reduction in costs and a significant improvement in quality and product.'
Q4: How are you looking to tie all these supply chain attestations into the existing CI/CD pipeline?
Sanket Panchamia (47:05)
'Generating SBOMS is one thing which is solving one spectrum of the problem, I think sharing is a completely different game altogether. How do you make sure that you share that information to your customers and in a continuous manner? We are moving towards SAS and continuously evolving software packages, so how do you make sure that the SBOMs that you generate and share are up to date? When we talk about SBOMs, it's not just the software, it's the infrastructure that goes behind it, the environment that you've created it into, and the vulnerabilities associated with those because it matters at the end of the day. When you are looking at vulnerabilities, it's not just what's in the package but even the periphery around it, so it's a make or break for the whole supply chain attestations. There is some serious thought put into it now, ever since I've gotten into this world, the whole concept of SBOMs and sharing attestations was a byproduct of your development cycle, but now that it's gained traction it's become more mainstream, its something that's consciously been looked into as to how do you create these attestations, how do you share them, how do you standardize them, and once you have all of that, how do you put them into your existing CI/CD pipeline. I'm pretty sure most organizations are on the CI/CD pipeline, it's not new for them, so they are trying to automate things, not having to do this manually, but get a process and practice in place, just let it happen and not have to worry about it.'
Q4: What are the benefits software houses are pursuing with CI/CD development?
Dragos Ruiu (50:30)
'Things like Veracode and Static Analyzers, there's a lot of tools that can be built into the CI/CD pipelines that are of high effort and intensity on a one-off basis. Using older and more manual-built processes, I think you can put in a lot of automation for your developers that will save you a lot of security checks down the line, static analyzers being the first and most visible component. But, there's also lots of things that you get fairly cheaply as opposed to doing it by having a separate Q.A. department or by having more older, manual processes, and that to me is the sales pitch that most people will pay attention to […] From my perspective, as an external snapshot of the company, I see almost everybody switching to that philosophy, I don't see many people holding back on that.'
About Cybeats
Cybeats delivers intelligent security applications for software supply chains and IoT connected devices, autonomously detecting and eliminating cyber threats in real-time. Cybeats - Software made certain.
Website:
SUBSCRIBE : For more information, or to SubScryb to the Company's mail list, visit:
About Scryb
Scryb is a platform that powers businesses and technologies with applied intelligence, real-time analytics, and actionable insights. The platform boasts proven adaptability across diverse markets, from digital health and diagnostics to cybersecurity and manufacturing. The cloud-based platform is composed of crucial elements including sensor technology, IoT, predictive analytics, and computer vision.
For more information, please visit our website at:
Contact:
W. Clark Kent
President
Office. 647-872-9982
TF. 1-844-247-6633
Email:
Forward-looking Information Cautionary Statement
Except for statements of historic fact, this news release contains certain 'forward-looking information' within the meaning of applicable securities law. Forward-looking information is frequently characterized by words such as 'plan', 'expect', 'project', 'intend', 'believe', 'anticipate', 'estimate' and other similar words, or statements that certain events or conditions 'may' or 'will' occur. Forward-looking statements are based on the opinions and estimates at the date the statements are made, and are subject to a variety of risks and uncertainties and other factors that could cause actual events or results to differ materially from those anticipated in the forward-looking statements including, but not limited to delays or uncertainties with regulatory approvals, including that of the CSE. There are uncertainties inherent in forward-looking information, including factors beyond the Company's control. There are no assurances that the commercialization plans for the technology described in this news release will come into effect on the terms or time frame described herein. The Company undertakes no obligation to update forward-looking information if circumstances or management's estimates or opinions should change except as required by law. The reader is cautioned not to place undue reliance on forward-looking statements. Additional information identifying risks and uncertainties that could affect financial results is contained in the Company's filings with Canadian securities regulators, which filings are available at .
To view the source version of this press release, please visit
MENAFN24022022004218003983ID1103760453