Episode 6: The Wall Street/Fintech Perspective of Open Source | ActiveState Podcast

Thanks for tuning in today. Welcome to the Active State Podcast, episode six. We'll, where we'll be talking about the Wall Street FinTech perspective of open doors.

Maybe I'll start by introducing myself and then I'll let Pablo introduce himself as well. My name's Diane Ian. I am the senior product marketing manager here at Active State, and I've worked in the FinTech state space prior to active state for about five years.

So excited to draw my experiences. And I'll pass on to you, Pablo. Right.

I'm Pablo Ble, um, here at Active State Team Lead for tools and Infrastructure. So mostly DevOps, I'd say about, I have about 14 years directly in, uh, investment banking and Wall Street and many other experiences in the financial sector. Awesome.

So you're gonna be a great person to talk to Sure. About Wall Street and FinTech today. So yeah, I think we wanted to kind of kick off the podcast by talking about the challenges faced when you're in a large organization in Wall Street or any large FinTech institution when it comes to managing open source software securely.

So I think there's a lot to unpack there. So maybe we can kick things off by focusing on what the burdens are for people within the FinTech space first and Pablo, maybe you wanna take a first stab at that? Sure.

So one of the particular things about anything that's financial industries is that everything is accounted for by dollar sign. So you, whatever project you do, whatever things happen, there's a dollar sign attached to it. So you can't, if there's a mistake, somebody, there's a data leak or anything there, there will, there will always be either financial, uh, fines or it could be a reputation loss.

So you will get less, less interest in, obviously you're, when you're on Wall Street or any financial industry, your reputation is everything. I mean, I would trust my money, which somebody who, who's got a s****y record or somebody at the corner of the street says they're the wallet inspector, you're not gonna pass your wallet. You, you wanna make sure that whomever's, uh, looking and holding your dollars are, have that, put that the highest importance.

So Wall Street, like any other industry is, uh, very dependent on open source because it's, there's a certain level of maturity. There's also, you don't wanna reinvent the wheel when you're, or any kind of industry. So you, you, you can find talent that has already experienced or whatever tool you're using, whatever language you're using, and that makes it much easier to actually be able to keep your, uh, your operations aclo.

I seen some Wall Street firms develop their own programming languages and obviously trying to find people to actually work on whatever the firm did is surely complex and time, uh, consuming. Mm-Hmm. Yeah, absolutely.

I mean, I definitely have to agree that I think fintech's struggle with building that brand trust. I think whenever you give your personal data over, you think twice about it. So I do think trust is a huge factor, uh, that fintechs or people on Wall Street generally that have to think about, and that is also trust in the tooling that they're using to secure your data.

So I think that's also why looking into the open source software and open source infrastructure that these large institutions are using is also becoming more and more important and more and more interesting for the consumer. So maybe we can speak to that a bit more as well. So open source by default has this, there's the model attached that whatever code gets submitted, there's an oversight from everyone can look at what code you're running.

So it, it makes, it gives a certain transparency that you do get a, an an an enhanced level of trust. I mean, it's not some, it's not security throughout security, but rather through transparency. So if there's something that goes wrong, people can look at it, change things as they go.

And, and it's this community also feedback and feeling that makes the, the open source world progress, uh, comes with its own sets of challenges because of, uh, you're, you're dealing with an open model so everyone can, anyone can, uh, hijack the process in a malicious, uh, way if, uh, you get a bad actor. Um, and we've seen that with the, with some of the recent, recent exploits or like the XE library and there's, it's one of too manys that anyone with a bad intent can actually, can actually hijack the process. So it's, it has this pros and cons.

I personally think it has more pros, but it's, yeah. Yeah, I mean, I think that's, for me, that's a very interesting point to maybe dive down, dive into a bit more. I have a stat right in front of me from Enos, which is the FinTech open source foundation that said that 78% of organizations, um, in the financial services industry reported an increased value in open source compared to last year.

And you just mentioned open source, there's pros and cons. Why do you think there's more and more people within the FinTech space adopting open source? Maybe you can speak to some of the pros that are forcing this.

Of course. So the knowledge base available there is much greater than if you're doing anything that's a private or something that's closed source. So if you're, and it's not just because you, the documentation is out there, but also when you need people to work on these projects and you're in a, in a staff augmentation or any kind of process to actually get, uh, your deliverables done, you have more chances of finding somebody who's touched whatever project you're dealing with, for example, Python.

I mean, it is a common known language and you have a lot an access to a large pool of skill sets that are out there when it comes time to, to implement your project. Yeah, no, I, so I guess the speed to implementation is probably one of the biggest benefits of open source. And I know we've talked about this before, that a lot of financial institutions are heavily regulated.

People work in silos, they just don't innovate as quickly. So do you foresee that still being an issue for teams within the FinTech space to innovate? Oh, of course.

The, I think this is why hip tech and Wall Street, uh, took such a heavy, uh, investment in open source. 'cause it's much easier to innovate when you have a pool of hundreds of people contributing altogether to actually make something great. Uh, versus you and your own company trying to, to make reinvent the wheel.

It is very beneficial. Now that obviously comes with its own sets of challenges where as, as I was describing earlier, the, the XZ library that is used by SSH. So pretty much every single system out there realize on xz, I mean, you're using a phone, it's probably has it.

So one of the challenges with open source is the level of dependency. So you might be using Python, but underneath Python, there hundreds of dependencies that are, are all linked together in one dependency calls. Another, and another, I'd like to think of this like an iceberg.

So while you might be using Python, that's the tip of your iceberg, but underneath it there is hundreds of other dependencies and it's pretty hard to know which one got altered, which would got modified if you just go and download something up the internet. There's, the XE was a fairly advanced level of, of modification and vulnerability that was introduced, that it just opens the, the discussion to the level and the cautious you have to how cautious you have to be when dealing with open source. Yeah, No, that makes a lot of sense.

And I've heard this term of what is it, gosh, now it's now I've lost my train of thought, but it's citizen developer, a lot of people who are maintaining open source are doing it on the side, and it's not their full-time job. So maybe we could even take a step back and, and speak to what security looks like at a FinTech, what the structure is. 'cause I know at one point we talked about people working in silos and that makes it harder to find or observe threats.

So given all your experience, I wonder if you could talk about the security within, Of course. So the FinTech world is heavily, uh, segregated and it's by design. So you wanna have various levels of controls whenever you introduce a change.

Any change has to be approved by more than one person. So it's a two key term principle that you have in various military designs. So you have one group or one person introducing a change, and obviously you have somebody who's gonna appear that's gonna review it.

And there are different organizations. So that way you ensure that there's always an oversight and there's not a conflict of interest in, in this. There's many cases in Wall Street where this guy or somebody decides to introduce a change that will, we all heard about this story about change, changing the fraction of a payment into a different account.

Mm-Hmm. So that prevents that kind of, that measures, but obviously you, this creates more complexity because you have always have to have some redundancy. The person introducing the change and the person approving, they both have to properly understand what's gonna happen.

So it is, it is a very complex and likely process that results in a lot of red tape. Well, that makes sense. And I think that also makes it harder somehow to actually introduce new tools or introduce a new process because there is a lot of red tape.

So I think yeah, that could cause some issues as well. Maybe I can, so one of the dealing with, in terms of security, the, the gold standard in order to track anything, uh, RCV, the problem with cvs and when you take the approach of the iceberg I was mentioning earlier, is that you will get your CVS for your top binary, but you will not get the CVS for everything underneath that iceberg and all the dependencies because you, you lose track. And that is a very complex problem.

And obviously you, when you have hundreds of dependencies, how do you track that? How do you make sure that everything links together, uh, and you have a, a global overview of what changes you're introducing and what possible changes, uh, might impact your security. And let's be clear that there's no such thing as perfect security.

You, you have, there's always sudden something that, uh, might introduce a possible vulnerability people, but you just have to be aware and then you can go through a regular process of a risk acceptance if your system's pretty isolated or you might just want to have wanna fix that dependency, uh, underneath the iceberg. I absolutely agree. I think it's impossible to achieve a hundred percent risk-free environment, but you know, you hear this term secure by design swirling around more in the ecosystem as well.

'cause I think a lot more organizations are trying to secure themselves at the beginning of the software development lifecycle or within their architecture and take a bit more of a proactive approach now to security and fixing it further down. So it's a great point because by originally security was not introduced. I mean, if you look at the internet, the way it was designed at the first email worm in the eighties was because there was no security by design.

It was, yeah, a couple of universities linking themselves together, putting mail systems and okay, great. I mean, we all trust each other. We all have work in good faith, but it's not the case today.

PXZ library. It definitely showed that very clearly that it's, you can't just go and cross whatever you wrap up the internal net blindly. And it's, it's a very lengthy process to keep everything tied together.

When you said that too, right, there's a lot more bad actors now, which is, which obviously is terrible. But you know, I think there's more and more tools on the market to support people. And also there's a lot more regulations coming down from top down with a cyber resiliency act in the eu and now the White House pushing for anyone that works with the government to have SBOs to show where their software's coming from.

So I do think there's a lot more regulation and compliance coming in to kind of force, force different organizations to take security a bit more seriously. So I don't know, perhaps we can also talk a bit about what active state does and how we focus on security or software supply chain security. So the idea of the icer, or what do we do in terms of open source is that we can provide a global view of your whole iceberg, not just the 10% of the top of the water.

So we can build custom build, develop an environment. Let's take Python for example, and all libraries that are under the water. And, uh, you can select manually which libraries you want and do a risk acceptance depending on the CVEs, on the severity or not anything that's underneath and mm-Hmm.

You can constantly build your own Python environment and use that in our environment. So, and obviously there's traceability. You get your s long with licenses with the provenance and everything is off immutables.

We take, we build from an immutable storage, so whatever code we get, we store it and there's, uh, obviously we, some bad actor can't just come and try to modify it because it is, it is on an immutable system. And maybe too, I mean, could you talk about the difference between active state and maybe an AppSec tool? Because AppSec tools of course catch CVAs, but active state does a lot more than that.

Yeah. So you can, if you stand in binary, you get, usually it's the tip of your iceberg. You will not go down under the water.

And that, that's, that's a lack of, you will not get the full perspective. And it's not that, it's not that the tool is not a good tool, it is just that the complexity is tremendous. You can't, keeping the links and everything that goes under the iceberg is huge.

This has been attempted before. There is a various, various open source projects, like if you look at the free BSD system where you can build everything a binary custom made and compile everything, all the dependencies, and you can select which dependencies you want. But again, all of those binaries, uh, all those that source code, um, which we do with, with as the, the active state tool platform, they're all downloaded from the internet versus us that we store, keep this in an immutable storage.

So yeah, it's great. You can have ways to compile your own binaries and, and know what you're putting, but you still don't have, you can still get some injection or some malicious actor modified what you're getting off the internet. And that is the danger.

It's the same thing as you downloading any binary from the internet. You still don't have to pull provenance and you're, you're be able to scan the tip of the iceberg, but you don't know what's underneath. Mm-Hmm.

That makes a lot of sense. I mean, we were kind of talking about this the other day and you used a chocolate analogy. I don't know if you wanna share that, but I thought that was really great.

Oh, go ahead. I Oh yes. Yeah.

Um, I was thinking probably you go, you have a kid, normally a kid will, will see a chocolate on the street, will pick it up and try to eat it because well, it's sweet and uh, it's there, it's free. So, but probably most of the time nothing will happen. But there might be a time where you might catch something or there might be something unusual and it, it's a bad idea.

Generally it's a bad idea too. But I mean, the dangers most people are used to do because there hasn't been any consequences. But it's something to be aware of.

Uh, most of the time there's no consequences. But if you think about other ways this, some industries have tried to put some mechanisms to prevent this from happening. You have, uh, Microsoft that signed some of their binary.

So you, you have a bit of a, some assurance of where your binary comes from, that there's some company that looked and, and has some building process, but still you, it's not a bulletproof mechanism. That's the reason behind the s bombs because you, whenever you implement anything, you have a, the whole story, the whole picture of your iceberg, not just a tip versus if you grab a sign binary, okay, fine, you some Microsoft sign your binary. But mm-Hmm.

You still have the full story. Yeah. I think like we put in implicit trust right now in open source, which is, I guess the issue because there's more and more malicious or bad actors out there Mm-Hmm.

Who are using it for the wrong reasons, unfortunately. And that's just the state now that's changed. Open source used to be safe, but it no longer is safe.

So it's something that every organization, especially within the FinTech world or within Wall Street, where you're, you have more personal customer data at risk that you need to start thinking about securing your supply chain. Oh, of course. It's a fairly complex problem.

There is, wall Street has invested a huge amount of money and effort because they've seen this for some time already, that the, anything that affects their software supply chain might have a, a bigger impact. But in terms of reputation, and again, money loss, but when we look at the, the amount of money, it's tremendous trying to replicate what, again, it's Wall Street. They have, there is a, the, your financial backing is much bigger than most companies, and there's a complexity also to maintain such systems.

I was describing, for example, the free BSD system that that does something similar again to back in the days and under Linux. But it's, you still are grabbing things of, so it's a complex problem with multiple dimensions. There's no perfect solution.

We took an approach that tries to, to successfully deliver some of the, a lot of the check marks on, on making sure that whatever is not loaded, whatever's used, there's, has been whatever artifact has vetoed, has been stored, and it's an immutable storage. That's an important thing. No one can come and modify it at, at will.

02, uh, might have been Right. Somebody goes and changes a bad actor and then it propagates across, across the, the, the world and anyone that's using it becomes suddenly vulnerable. Mm-Hmm.

Yeah. And I think we touched upon this a couple times. There's no perfect solution, but I think it's just important to start acting or making some moves forward versus staying complacent and hoping that you're not one of those people that's gonna get hacked.

Yeah. You don't want to be, uh, the Sonys of the Sony when they have wasted issue. I mean, and it's a broad, it's a broad problem that I think needs to be looked and taken more seriously and be the new regulations prove the point that if people are not willing to take action, well, you have to get on law to actually have some consequences.

And it's, let's say, I would've hoped to have maybe more consciousness on the problem before you get a love. Because at the end of the day, if your company or anyone gets a vulnerability and it gets exploited, you end up having a loss of reputation. Mm-Hmm.

That's equates to dollar signs loss. So it's not a, what you're delaying today, um, might cost you way more in the future. So the idea of that's future be problem that uh, it just doesn't cut it now, hey, you have a lot that tells you to do it, but I, I think it's a, by design, we should be taking it at this more a, in a serious and aggressive manner than just being passive about it.

Absolutely. I think it's, this is a future for me problem. I love that.

'cause I think it's so preventative, right. And so that's something to keep in mind. I, I do think we're running out of time.

Maybe I'll go ahead and wrap this up. If anyone has any questions for us, feel free to reach out and yeah, thank you so much for chatting with me and thanks to everyone for taking the time to listen and learn more about active state and yeah, open source security within the FinTech and Wall Street space. Thank you.