Patrick Sheehan, Phylum | Open Source Summit Europe 2022
Patrick Sheehan, chief revenue officer for Phylum, explains how to secure software supply chains using open source software in real time.
Transcript
This is texturing TV. Hey guys, we're live at the open source Summit in Europe in Dublin. We're here with Patrick Sheehan aptly named good place for him to be Patrick is the chief Revenue officer for filing.
We're going to be talking about open source security. You guys have been at this for a while now, everybody started talking about it in huge amount of conversations about it in the last nine months, but you guys have been at it for longer than that. Yep.
So my question to you is you know, what challenges are there that need to be resolved because it seems like we are putting out calls to solve particular issues. But I sometimes wonder some of the vendors have already solved some of this stuff. Yeah, it's great great point and delighted to be here.
Thank you for having me Mike to your direct question. Yeah, we've been doing this for about two years now. I think someone said it's always good to start a company about a year eight months before an event happens.
We were that way so we started just before the supply chain attack started happening namely the solar winds attack. So we said started identifying the challenges that existed. and then all of a sudden it came to the Forefront with some of the recent attacks, so, you know fundamentally, we believe that in order to secure modern software development.
There's more to look at than licenses and vulnerabilities. So really taking a look at a broader approach to the market, right which is a little differentiated from maybe some of the tools that have been existing in Years Gone by we're purpose built for the problem that we're trying to solve. So it's been an interesting learning experience of last few years.
Is this a platform that I buy and install as if I'm the devops team and how does that get integrated with my workflows? Because you know devops teams are pulling off open source code off the web 19 times a day. Yeah, it's tough.
I mean this is a paradigm shift. What phylum is trying to do is shift the Paradigm. I think the tools that have been out there and the approaches have been good for a period of time.
And now it's a matter of really taking a look at how do we drive successful outcomes for the security organizations that are trying to manage risk and the developers who are trying to keep Pace with the business release Cycles compensation drives behavior, and we're not necessarily aligned we hear about this organizational friction that exists in the marketplace. So one of the things that I think we had a late mover advantage of and again kind of coming into the space a little bit later than maybe some of the existing tools that are out there where an app SEC is we had those two personas in mind when we built the platform. So how do we shift further left so that we are not interrupting?
developer workflow and the same time is allowing the organization namely the absec or devsec Office programs set policy and guardrails about what is acceptable use of the OSS packages that ultimately is fueling Innovation. So with those two types of use cases and failures of the last or challenges that exist over the last two decades have been the space quite a while. The idea is we've got to be integrated into the developer Tooling in order to for them to really adhere to the challenges and the policies that ultimately said by that.
So the way that we're developed to your direct question is we are sitting in line with the into the CID CD. You know, we're developing. Sorry.
We are integrating into all of the developer tools, right and mainly the ci/cd bill process. We also have a deployment mechanism where we're actually even further left than the developer actually doing package installation and we're seeing the developers are actually the targets of most of these malware attacks in the software supply chain. So that deployment mechanism for filing is something that's new and getting a lot of traction with the conversations.
We've been having Who's taking the lead on funding all this stuff because to your point there's not a lot of love lost between cybersecurity people and developers often. They kind of tend to point fingers at each other. So who is it that is taking charge of this funding of these projects because developers don't tend to fund security.
So who but the security guys tend to go. I thought the development team was doing that. Yeah, the great question.
We see typically our entry point is to this security organization product Security application security see so things of that nature they understand that this is the risk that they're trying to ultimately own and they own the budget for maybe some existing tools. Now that being said the mature organizations that have already experienced a lot of that friction during our engagement process. We do proof of values and things of that nature.
They're bringing in the development teams. So mature organizations have a developer experience team. So they're kind of sitting is that hey, let us let before you do anything to the Golden Goose and the revenue Rating, you know machine over here with all your security with bank stuff.
Let's just make sure that it's purpose-built that it's not interrupting. What ultimately is. Innovation and we know being the space a long time, you know Revenue Will trump risk any day of the week.
So we had to balance those to those two use cases, but security is the entry point and there's a lot more collaboration with the developers given the problem that they're both trying to solve. We talk a lot about shifting left, but it's not clear to me that developers really want to know a lot about security. The truth of the matter is security wasn't elective.
Most of them didn't take it. So they just want to write code and do their things. You know, how transparent can we make all this stuff so that you know, we can quote unquote shift left, but it's more like maybe we're leaning left.
Yeah leaning left. This is a true shift left and in the conversations that we're having with the development organizations. It's all changed.
But even the last four months we're seeing that about 90% of the malware attacks that is getting inserted are targeted at the developer workstations. They're quick hits. So they've felt the pain in the issues of credential harvesting or being attacked and being, you know, having that malicious code be downloaded.
So the awareness level of developer whether they like it or not is rising. Coupled with the fact that most organizations are trying to get their arms around acceptable open source use so yes, the developers are people that don't want to be that want to be left alone and we will be conscious of that. But what we're trying to do is this is where the Paradigm Shift comes in if we can actually be deployed before the developer ever pulls down that package.
We're actually alleviating a lot of the remediation gaps this whack-a-mole that we've been facing for 20 years. That paradigm shift is very difficult. Sometimes to people to comprehend because change Management's hard but I will say the developers are more aware of this now, they're actually understanding because they felt the pain of maybe some of these recent attacks that is Shifting the tide in our direction to say why don't we think about this problem differently and bringing those two organizations together for common goals so far so good.
I think that you know, it's still early days a lot of mature organizations are feeling it out. But the developers haven't been pushing back too much because they've actually been more aware of the problems. one of the dirty secrets of our business is that there are Billions of vulnerabilities and existing applications.
They're not all equally lethal, but do you think that as we go along that people will start to replace those applications and we'll see a lot more activity not just building net new applications, but actually going back in to rewrite Legacy applications to go get rid of large swaths of those vulnerabilities great question. I don't know. I mean, I've worked in the financial institutions that still have COBOL, right and they never change that despite, you know, the challenges and lack of people being able to to know those systems.
We're seeing new languages pop up. There's a lot more Technologies where people in containers are using different languages, right? So yeah, there's thousands and thousands of vulnerabilities.
It's not Millions. I think it's a matter of really addressing some of these vulnerabilities as much as you can retroactively but doing it better job of as you're including new packages and new builds making sure that you really have a better hygiene to alleviate the problems moving forward. All right, so get out your Ball, we have this phrase devsecops and everybody kind of trips over it.
So yeah at one point down the road will we just not need the phrase devsecops because people will know security enough that we'll just have devops. I will say we're probably five to seven years away from that. I've been talking about this for quite some time I said, how will we ever going to there's a million jobs available?
But yet you have Network engineers and network security Engineers if security can be ingrained in the fabric of the company big ask Then I think we alleviate a lot of the challenges. Why shouldn't we just do things securely versus doing them, unsecurely and having someone check our work. I think we're probably five to seven years conservatively in that becoming a reality where security is just ingrained in the process.
So maybe someday we could have like security reliability Engineers the way we have sres today exactly and they're part of the whole workflow, but they're not getting in everybody's way. Yeah, I think thinking about this problem differently. It's been a lot of time in this space.
I had a company doing risk advisory previously changes hard and getting the business to really understand that risk Management's important. Let alone Security Management right in cyber and things of that nature that's not just an IT problem that it's actually a business driver and a business to tractor. We'll take some time, but I think the awareness and the attacks and a lot of these things have shifted the board conversation, which ultimately trickles down to the organization over time.
That being said, I think we've got some work to do five to seven years would be my Miss Cleo prognostication. All right folks you're hurting here change is coming Patrick. Thanks for being on the show.
Thank you very much Mike. Thanks for having me. My pleasure.
Hey guys. Thanks for listening and we'll be back in a minute.





