Alan Facey, SCANOSS | Open Source Summit Europe 2022

This is texturing TV. Welcome back to the open source summit. We're back here in Dublin.

And now we're talking with Alan Fosse. Who's the CEO for scan OSS? We're gonna be talking about some scary stuff.

So sit tight because you know, I would argue at least that the word audit is one of the scariest words in the entire English language and everybody kind of hears that and freaks out but it can be a good thing. So, you know walk us through why we're seeing so much more interest in scanning code and auditing it and trying to figure out what's going on inside that code base. And what's the benefit?

So I think you know first and foremost not the hyper focus on the word audit. I mean that is sort of where scanning started maybe 15 years ago. And that was the purpose mainly in the context of m&a due diligence.

So when one company buys another they obviously inherit those software assets and their concerned to know what's in those software assets, you know life has moved on a little bit in the last 15 years. So, yes people do still audit, but actually it's much more about some of the fundamental elements of auditing that have now become automated rather than a classic audit imagine an orders are sitting doing an audit that it still happens, but not quite as much as perhaps it did 15 years ago. And so today the emphasis has shifted a lot actually away from auditing and much more.

By the way, this is driven very much by President Biden's executive order on improving the nation cyber security. But yeah, the emphasis has shifted away a little bit from auditing your code to First really focusing on understanding what's in your code, and it's amazing how many companies don't actually know what's in their code. So this notion of a software bill of materials or a software inventory has become very Central to to this space and scanning is one of the mechanisms not the only one but one of the mechanisms that companies use to build a full and complete.

Inventory or software bill of materials in order to answer the question, you know, you know, where is this piece of code? So if there are security vulnerabilities if there are licensed issues if there are Code quality issues or whatever the issues may be, you know where to go find it. So yeah.

Yeah in a in summary. Our world is actually not so much about auditing. It's mostly about helping companies get software a bit of materials visibility.

So answer the question of what's in my in my code so that they can take action whatever that actually may be a technical or security or legal risk entry. When someone goes to scan their code, is there a difference between all the different tools that are out there that they should be thinking about I mean, there's a lot of ways to scan code. So does it matter how that gets done or is that pretty much a non-differentially?

It's some level. It doesn't really matter how you get to your software building materials. The question really is whether it's complete or not.

You know many of the the technologies that are available today from Google and others will give you a path to a software bill of materials. Unfortunately the way most of those Technologies work. You don't end up with a true truly complete software with the materials you get you get a bill of materials through the lens of Google.

I just I'm picking on Google that's unfair, but you get the idea. and where companies like us differentiate is by taking it one step further is doing what the Googles of this will do, but also looking deeper into the code and finding what we call Undeclared. Components that the to the native tools Miss so it's not a matter of the that everybody can do a can create a software better materials.

Everybody can at some level but the trick is to get a complete software better materials because if you don't have full visibility difficult to know where to take action probably is reason, how is it that all those strain components wind up in software are their best practices that people should be doing to avoid that in the first place because it does seem like there's a lot of it and people are just kind of moving stuff around and you know, how did we get here? Well, I mean, I think it's just the the nature of software development. I mean you can put processes in place and there are organizations like open chain associated with the Linux Foundation that drive standardization around processes and the like and all that all of those are good things.

But you still got people involved and you've got, you know real developers who have urgent needs to get things done. And all it takes is a quick shortcut to cut and paste something from stack Overflow to pick something sort of basic but common and suddenly you're in trouble from from a visibility standpoint because that cut and paste is not going to be tracked. Typically by the the normal tools are using the development process.

So there's a simple illustration of what happens frequently. Just because of how developers develop that because developers aren't thinking all the time. Oh, I got this.

I've got to make sure that I've kept track of this component or this part of a component they sort of assume and hope that the tools they're using provide that framework automatically Unfortunately, they don't and that's where companies like us and make a difference are people also using these tools to find things that you know, zero day vulnerabilities are going to happen no matter what but I don't always know where that piece of software is or the one that's impacted. So am I using your tool to figure out where my stuff is or what I have or maybe do some analysis on How Deeply may I be impacted by some new vulnerability? Yeah.

So so the short answer is yes, you use us first and foremost to gain that 100% visibility as to you know, what components what open source components. Do I have in my code estate and where and where are they? If you think of its over in from a process standpoint, the the first step is to get that visibility.

So get a software bill of materials in place. And then we call it decorate that software bill of materials with intelligence about those components. So I'll be obvious things that you were decorate your your software bill of materials or inventory with is yeah license information that's sort of a classic use case in the open source space people care about open source licenses and being compliant, you would decorate that software building materials with known security vulnerabilities.

You would decorate that software of the materials with Um indicators of bad coding bad code quality or bad code practice and the list and the list goes on. So so our goal is number one to create that software bill of materials and make sure it's accurate and complete unlike this for most of the Native tools and then decorate it. So that companies have full visibility developers have vulnerability and then companies from a management standpoint have the full visibility as well.

And that's and that's how we lower risk and make the whole journey of using open source less frictionful. That's to say a more frictionless experience. So I create this s-bomb and then I share this s-bomb with my customers or whatever that may be what happens after that.

Am I gonna get to continually message from people going? Hey, we saw this change or we no longer want to use this component and this becomes some sort of ongoing supply chain dialogue. Is that how this is gonna play.

I think that's that's the the friction part in the sub blockchain that hasn't been figured out yet. You know, there's various initiatives underway across the world to try and bring more structure and more more of a deliberate approach that the software supply chain and President Biden's executive order. Yeah pushes people in that direction because it focuses specifically on this specifically on security but it also drives the homeless notion of a software bit of materials being the the artifact if you will that should flow up and down the the supply chain.

I think the industries there yet. I mean, we as a vendor kindly not there yet either we have lots of ideas and inventions and suggestions as the how you might effectively follow or track a software building materials and the components within the software building materials through the supply chain some people in the audience here talk about about blockchain Technologies as one of the ways. To to maintain an immutable.

Understanding of how components have transitioned through the through the supply chain, but it hasn't been figured out yet. And that's probably the next big Frontier is figuring out how you know, all of these Technologies such as the one the which sensors the ones that we have. Will ultimately all seamlessly knit together and provide that transparency down the supply chain, but we're not there yet.

And I think it's a few years off. To be honest. I think it was Ronald Reagan who once said hi this scary and English language is hi.

I'm here from the government and I'm here to help. So we have the Biden. Right regulations or not regulations, but requirements for federal agencies and other people will adopt that at some point there will be some sort of compliance mechanism applied to this and we will see you know Regulators looking at this stuff and saying are you within compliance of this?

We'll see Insurance folks. I imagine will want to see this stuff. So as we look forward the whole process of building software seems like it's going to become a little more bureaucratic.

So how do we deal with all that without necessarily killing all the joy? That's a good question. I'm not sure it's going to be that bureaucratic.

I think it's I think it's going to be a matter of Software vendors like odds and you know the big guys like the ghouls and the the githubs of this world. Figuring out the right combination of tools and capabilities that make all of that, you know, supply chain stuff frictionless and just automatic so it becomes invisible to the the developer because I don't think it's in anybody's interest not least the individual developer to have people looking over their shoulder all the time kind of auditing them come back and coming back to your original concept. So I I think in the next years this is going to get figured out and part of it's going to be driven by organizations like openshine which I mentioned earlier because it requires some degree of standardization some degree of understanding as to how how you manage a supply chain.

Both in terms of process and then the tools to support it. And yeah, we're just not there yet. So I I'm I'm optimistic that we're not going to end up with a with a bureaucratic process.

I think I don't think companies will let that happen. I don't think I don't think developers will let that happen is just not in their nature of the creative people. So it'll be a bit of a push and shove I think.

All right. Well the vendors will get us there. I think and some of my friends say from your lips to God's here.

It works out. But the next thing that we kind of look at and all this is how automatic can it get so if I have a message from somebody that says that this component needs to be upgraded. Will I automatically upgrade that component or you know when I talk to a lot of developers they're hesitant to upgrade components because they're afraid the whole thing will break right.

So how do I kind of balance that need to quickly fix issues and come into some sort of guideline and the fact that I don't want the software to break. Yeah, this is where my own lack of development expertise. Although.

I was a developer back in Fortran days that dating myself, right but I I guess I don't know. I don't have a straight answer on that. I I find it difficult to imagine how that's going to work to be honest.

Don't have a good don't have an answer. Sorry, so somebody's gonna always have to be involved and say yes, I'm gonna check this box really upgrade but they're still gonna have to deal with if things break kind of thing in the whole analysis that goes with that. So it's not like s bombs are gonna magically make software development, you know automated and simpler.

It's just that we're gonna have essentially a list of ingredients that we can see what went into this thing and have a better understanding of what our issues are. We just exactly that we can have a better understanding of proven answer better understanding of How we got to where we were in order to be able to take the appropriate remedial action? I think actually it'll turn out that eventually all of this this movement around gaining transparency in this the supply chain will get figured out.

The more tricky part is exactly what you said, which is okay. We found an issue be a security issue a licensed issue something called quality issue what next? And that's not something that scanner assesses likely to be trying to trying to attack.

I think that's for others but That's where the rubber hits the road right the rest of it's all just trying to smooth the process and make it a little bit less friction and full. Once you're invest advice to folks about how to get started because there's multiple s-bomb formats that people need to think about there are ways to get engaged with that. So, where do I kind of start this journey?

Well, I I think from a selfish step I would say the obvious thing to do is to start with a free and open source tool like scanner OSS. I mean, there's this absolutely zero barriers to entry You can go to our website and download our scanning tool. even in auditing tool God forbid so we have those capabilities.

They're all free and open source, and there's there's absolutely nothing preventing a individual developer or a company of any size. Generating a software materials. This is no barriers to enter anymore.

You don't have to spend a dime. To make that happen. So that problem has been solved it's available and we're trying very hard to make software building materials generally accessible to everybody because it's just such a foundational item.

so I I don't think there's I don't think there's too much to be concerned about just go to a website click on the button and you're Off to the Races. Now the more tricky part tends not to be you know, the tool associated with your generating a software bit of materials. It's where does that software build a materials live in my organization?

Does it live part of the it's part of the code? Does it live somewhere separately? How do we manage all those offerable materials?

I mean that's more of a process question and I'll come back to open chain. You know, that's the type of Standards based. Or standard Centric organization that will help companies to figure out how to manage those software and materials.

But actually the active creating a software been a materials these days is as English people say cheapest ships just do it. It's it's essentially free do I just drop this tool into my devops workflow or where does it sit? Does it sit out at the developer?

And in the IDE or where is that? Yes, and yes, and yes, it really depends on on the company. You know, I I picked up on your audit word a bit earlier because I don't like it and it bugs me that people still do Audits and there are still most small armies of people doing audits in very very large companies who are otherwise fairly sophisticated it kindly blows my mind a little bit in this day and age, they're still small armies of all of those auditing code.

But but that does exist. So we provide tools for Auditors so you can do the classic things that that you may be familiar with with from vendors like synopsis previously black dark flux era and others. There are a whole bunch of we call them Legacy tools out there that that allow you to do all it's quite effectively.

Yeah, we offer the same for free. At the other end of the spectrum you could wire it into your cicd process have it be entirely invisible and and automated. So the older thing is happening on the fly every single time a developer cut some Pace a piece of code.

It's audited quote unquote. Behind the scenes in an automated fashion all of that technology exists. It's all free in free and and open source from scanner SS and various other open source projects which have grown up over the years.

So there's really no excuse these days for not having control over your your inventory of Open Source. I mean that problem has been solved explicitly by us. But also by a few others in the past.

All right, folks. You heard it here first. It's kind of like not doing your homework.

Just generate the s-bomb. It's gonna be required. We're not entirely sure what's gonna happen Downstream from here.

But hey, we'll be check come back next year and find out Alan. Thanks for being on the show. Thank you.

Good to speak to you. All right and guys, we'll be back in about five or 10 minutes.