Techstrong TV – May 22, 2023

Hello everyone and welcome to Techstrong tv. Today's Monday May 22nd, and I hope you'll having a wonderful day so far. I'm your host, William Willis, and in today's show, we're gonna bring you some fantastic interviews with incredible guests from around the world.

So stay tuned. As always, I'm gonna start off with our tech Strong News recap, filling you in on the biggest tech headlines that are making waves. Then we are gonna head over to Mitch, where he will meet with sits around my Air Vehi Senior Director of Cloud Native Solutions to talk about Kubernetes security.

Mitch will then meet with Platform Con speakers, Brian Douglass of Open Sauce, JPAC of Razor Pay, and Susa TK of humanitech to talk about the upcoming event. Next up, we will air some interviews from the oss North America 2023. Perfect.

First up, Mike Ard spoke with Heather Atkinson, senior product and technology leader at OS Climate, about how the open source collaboration community is revolutionizing global capital flows into climate change, mitigation and resilience. Then Mike spoke with Philip Ahman, open source and embedded iot Linux engineer at Bosch about the enabling Linux and safety applications project. Mike Baard then met with Omkar Raham, general manager of the Open ssf and Brian be Ledor CEO O of open SS F, to talk about the importance of support, collaboration, and cooperation with various stakeholders, including governments and industry partners in the open source community.

Next, Mike sat down with Gabriel Colombo, general manure for the Linux Foundation, Europe, and executive director of phs, where they delved into the significance of open source in the financial services sector. Mike then spoke to Cynthia Coop, CEO O of Dandelion, to discuss the software development for diversity and inclusion. And then to wrap up our coverage for OSS North America for the day, Mike's book, Def Fati Deci, executive director of the CD Foundation, and Andrea Oli open source advocate for IBM about a new report that sheds light on the state of DevOps.

To finish up this broadcast, we'll head over to Mike Rothman, where he meets with IIC AVAs, C E O of N, intro security to discuss the current state of secrets management. And that's what we have coming up for you on this episode of techstrong tv. So without further ado, let's get the show started.

com is the number one online destination for DevOps education and community building. com covers all aspects of DevOps, including DevOps, best practices and tools, DevOps culture, DevSecOps, business impact, continuous testing, continuous delivery, and more. com has the largest collection of original DevOps content featuring breaking news, blog posts, podcasts, and more.

com to learn more. com where the world meets DevOps ops. Hi again, everyone.

Here are the headlines from May 22nd. First up, the Supreme Court ruled in favor of Google, Twitter, and Facebook dismissing lawsuits, holding them accountable for terrorist attacks, but avoided addressing the broader issue of Section two 30, the federal law, protecting social media companies from liability for user content. In the Turkish nightclub case, the court unanimously rejected the lawsuit while in the Paris attack case it returned the case to a lower court with little substance remaining.

The court found claims lacking evidence of aiding the attacks, but raised a question about the platform's immunity under section two 30 that may re-emerge. In other cases, the ruling is seen as a win for the tech industry with concerns of Internet's disruption with companies like Yelp, Reddit, Microsoft, Craigslist, Twitter, and Facebook. Having warned that limiting liability could hinder searches for jobs, restaurants, merchandises, and more on social media platforms.

Next, Montana has signed a groundbreaking bill that bans TikTok from operating in the state. The new regulations in Montana extend beyond the existing TikTok bans in other states, and at the federal level, supporters argue that TikTok being Chinese owned, poses the national security risk. By enabling data harvesting in the spread of Probe Beijing misinformation, the law will prohibit.

TikTok downloads in Montana impose a $10,000 daily fine on app stores in TikTok for each access or download. However, experts are questioning the law's enforceability and Apple, and Google's ability to prevent TikTok. Downloads specifically in Montana is uncertain the battle over the TikTok ban is expected to unfold in court as TikTok has claimed that the law infringes un free speech rights.

In other news chat Chip p t is now accessible as the smartphone app. The free chat chip p t app was introduced for iPhones in the United States late, late last week with plans for an Android version in the near future. The app contains some new features, and most notably, the ability to interact with the chatbot using voice commands dis distinguishing itself from the web version, open ai, the company responsible for chat, G B T has emphasized that the app will provide an ad-free experience ensuring a seamless user interface, and it includes a feature that synchronizes conversation history across different devices.

OpenAI announced the launch of the app in a blog post stating that the initial release is in the United States. It will progressively expand to other countries. The app proudly carries the designation of being the official app by OpenAI on the app store guaranteeing users the authentic chat PT experience.

Zooming out though the app stores become rife with AI chatbot applications and the release of this official chat G P T app could have mixed implications for clone apps attempting to profit from similar technology. Next up, meta unveiled code composed a generative AI coding tool similar to GitHub's co-pilot at an AI infrastructure event. Although it's not publicly available yet, Meta's internal teams are already benefiting from the tools code suggestions and popular ides code compose offers, annotations and import statements, complete lines of code and leverages surrounding code and comments.

7 billion parameters. While meta claims high acceptance rates for its suggestions, it does not address any controversy surrounding code generated AI and copyright infringement. Meta stated that code composed which train using public code under open source licenses too.

While security concerns may have been raised, meta assures developers are not obliged to follow suggestions and that emphasizes its commitment to security. com, we have an article looking at a survey that shows, despite the successes of DevOps software, supply chain security problems still exist. While 82% of respondents have adopted DevOps, 41% say that they still lack visibility in the development process.

com. On digital CX o, we have an article looking at technologies that are reshaping vehicle fleet management. Many companies are looking to modernize their vehicles, and 86% of the ones that have reported a solid return on investment in connected fleet technology.

com. ai. Alan Schimmel gives us a rundown into what to expect with a new site that will cover all things ai.

ai, and that's today's tech shrug news recap. com is the leading resource for news analysis and education on challenges facing spacing. com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more.

com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more. com to learn more. com.

Home of Security Bloggers Network, This is techstrong tv. Well, the great pleasure being joined by Syam Iers. Syam is Senior Director of Cloud Native Solutions at Venafi.

Welcome. Thank you, Mitch. Thanks for having me.

Awesome. Thanks for joining us from Toronto, from the conference, from an adjunct room or hallway, wherever you are. I'm glad you could find some space to be with us.

That is correct. It's better than not sitting on the floor, but that was the, that was the other option. Done that too.

Right? You may do it where you are. Well, please introduce yourself.

Love to learn, uh, some about you, and of course, uh, tell us Venafi for folks who may not know about, uh, Venafi. Absolutely. Thanks.

Thanks for the opportunity, Mitch. Um, I'm Ciara Meyer, like, um, I've been with Venafi for about four years now. A little bit of the context to identify the way we sort of, you know, describe Benefi, uh, essentially, um, sort of, you know, manifests itself in think what thing people do on our daily lives, right?

So you have humans, you have machines, um, and every time human has to access something, so they go and authenticate themselves. Uh, we saw an op huge opportunity purely in the context of machines as well, because that's the one which area which is growing and growing and growing as you can imagine. So machine needs to authenticate themselves as well, and the defacto standard through which machine needs to acc, uh, authenticate themselves is through something that is cryptographically verifiable.

So, um, I sort of, you know, invented this category as we call it machine identity management, uh, which is much broader and bigger than certificate management, so to speak. Mm-hmm. There is the lifecycle aspects of it, there's management aspects of it, there's the automation aspects of it.

Uh, the end of the day, our focus for our, our 600 plus enterprise customers is to be able to help them drive all aspects of machine identity management to obviously avoid any kind of outages or breaches or whatever that might be. Right. So, so that way they are absolutely confident of the fact that, you know, they do have, um, a, a solid platform in place, uh, to help ensure that, you know, all identities that are specific to machines are managed.

Uh, that's the, that's the play. Um, the, the, the market that benies in, um, predominantly as, as, as you may, uh, as you know very well, Mitch, that you know, the, the world has changed. I mean, there's a lot of focus on digital transformation as much as cliched sounds a little bit now.

Um, zero trust, obviously. Um, containerization, which is something that almost every single organization have sort of embarked on. Um, what that has done is, uh, given sort of, you know, uh, a place for these machines to grow exponentially, and sort of back in the day, we probably thought a machine is a physical server, right?

So, but that's not how we see it. Uh, machine could be a physical server, it could be virtual machine, it could be a container, it could be some software, it could be some function. It could be, you know, something that's, um, running in a serverless environment.

It could be running in Kubernetes environments. Um, so, so the, the exponential growth of all of these kind of functions or things all get categorized under a machine for us, you know, so when we say machine identity management, we are not talking about physical machine. We are essentially talking about anything that needs an identity, and we know, um, that anything that, uh, that requires an identity, uh, can be secured, uh, can be cryptographically signed.

Um, and, and, um, and then I'll jump into a little bit about the, the technical aspects of Kubernetes and how that works. Uh, but that's essentially the, uh, the business that we are in, uh, to help, uh, manage machine identities. And you said several things there.

I'd love to unpack. We can't have time for all of it though, but it's, you know, a lot of times when people say machine identity, or at least what they interpret that as, they kind of think of it as a web server virtualized or whatever, as a web server certificate is sort of like the very simplistic starting point, if you will, or maybe security around APIs and things like that. But in a cloud native Kubernetes world, right?

We have workloads that are traversing, you know, many, many different things. Machines, if you will. You know, everything from an IOT device, a serverless application, or multiple components at the edge, microservices that are living anywhere and everywhere in, in whatever number of instances.

And it isn't, you know, kind of one memory space we're protecting or even one set of, um, interactions that are happening across microservices, right? Oftentimes we need to secure individual workloads that are happening anyone at any one time, and like automation comes in, because we're not gonna have a person issue a digital certificate every, every 10 seconds or 10 minutes, or 10 hours, whatever, for all the different things that are happening. So it's so dynamic and happening so fast and changing, you know, you have to, uh, think of security differently in a cloud native Kubernetes world, correct?

Yep. Am I on the track there? The, oh, you're absolutely right.

And actually expand on that ex same, uh, example that you just took. You know, uh, end of the day, every organization, uh, is serving their customers, right? com.

That's an experience for my consumers. Let's say for at, at your organization, you say, you know, anytime somebody comes in, this is their landings place. com landed somewhere.

It's not the end of right. Say it provided you some experience that you are beginning to experience now. Uh, because behind that scenes, you may have hundreds of microservices that are deployed run, because, you know, somewhere sometime you decided that, you know, we need to be an organization that has cloud native architecture, cloud native thought processes.

We are gonna containerize our applications. Everything to be that we build is going to be microservices based, um, architecture. So you build this application that says, all right, so I've got a product service, I've got a catalog service, and I've got a card service.

I've got a payment service, I've got a recommendation services, I've got ad services. You know, all of these are potentially, you know, in an organization built by different teams. They all need to be wired together at some point, which essentially translate to that experience that you land with.

Uh, but when you look at these as individual microservices, they're functional, they're testable, they are scalable, they're all, everything that you think of how it should be in a cloud native world. When you put all of that together, you're providing an experience. Now, you could say that a secure test endpoint that's coming into the service, everything else I want to implicitly trust, or in a more security conscious organization, you'd say, well, that's not the only one thing that we wanna secure.

We want to secure every single line of communication between each of these services because these workload card payment service needs to be secured. This workload card, currency service need to be secured. This workload called card service need to be secured.

Mm-hmm. And when those services talk to each other, they should talk in a mutually authenticated way, because we don't, we don't want payment service to be called by somebody else. We want that payment service to be called only by card service.

I'm making up an example, but you can imagine That's, that is the correct or appropriate or authentic payment service Versus authentic payment service, or we're connecting to one one you're connecting to. Right. You Know, you don't want that.

Yeah. So, so in that case, and because you've gone this cloud native world or the cloud native architecture that you adopted, you have designed it in a way that, you know, this payment service can be upgraded, updated on a daily basis. You've got pipelines in place that are automatically upgrading it.

You've got, you know, development teams that are just focused on writing third without worrying about, you know, how these things are deployed run, because there is a platform engineering team that is managing and running in this context. We forgot one persona, which is the security persona who are essentially accountable from an organization's perspective if something were to go wrong, like, you know, they are eventually the people who are accountable. So from that perspective, they look at it as how are you securing the communication between currency service and the payment service or a card service and the payment service?

Are they mutually authenticated to each other? com, there is a digital identity. That thing was valid for 12 months or three years, or 10 years, or whatever that might be.

Everything else is good, doesn't work these days, because, you know, we want that everything to be, to be identified. Um, you know, simple example that I can take is, you know, um, um, and I'll get into a little bit of a specifics here. Um, these workload identities that we talk about are something that can be derived automatically, right?

So you don't have to work hard to derive an identity for these workloads. Um, and that's where something like, you know, spiffy comes into play. Like, you know, I could say Mitch and me are talking on Zoom.

Can we attach a spiffy ID for it? Spiffy slash slash zoom slash mitch slash sit around slash meeting? That's a spiffy id.

We iden we attached an identity for our own meeting the same way an identity can be attached for the workload. Because when a workload is deployed in Kubernetes, we know where that workload is. So, which means we can derive an identity for it.

The next step, which be to take that identity and cryptographically sign it, which makes it a cryptographically verifiable identity for that workload, then use that workload identity to talk to other workloads. We've been done and gone through the same process of being attested with an identity. Where when I Venafi comes in play here is that, you know, those identities end of the day needs to be signed by somebody.

And that signer is typically an organization within, uh, within the larger organization, a security team who manage, uh, all of the CA infrastructure, all of the PK infrastructure, all of the machine identity infrastructure, as we said, as we just talked about, they're responsible for those cas because those cas are, are, are the crown jewels of the organization, right? If you mis they are, they're typically, you know, sometimes stored in a vault, they're stored in HSMs, you know, they're stored everywhere. Uh, so somewhere you have this one abstracted level, an intermediary or assigning certificate or intermediates that are, is, uh, that are managed by the security team, but then zoomed by the platform engineering team to sign it and validate.

So that's how it all place together from a perspective of how we need to secure it. But end of the day, uh, when we talk zero trusts and architectural patterns around security, it's not just the north south that we wanna secure. We wanna secure all of the EastWest traffic as well.

And that EastWest traffic, uh, also ensures that, you know, how communications happen between services, uh, And you kinda have that fourth dimension to it too, which is time, right? Because time, a lot of these are what they call short-lived, uh, crypto trips, graphic connections, right? I guess Absolutely.

Those workflows. So Our zoom call might last 20 minutes, but that could, it could be a 22nd correct. You know?

Yeah. Yeah. I think, yeah, I think we, we, we also put a lot of emphasize on the exact thing that, and that's a conversation that I have very regularly.

Workloads are highly ephemeral. Mm-hmm. So, which means the identity that is associated with that workload are also highly ephemeral.

In some ways that identity could be an hour long, or an identity could be, you know, 30 minutes or, you know, identity could be seven days. It is not the, the old world of I have a digital certificate that is valid for 10 years, doesn't work anymore because, you know, it's just, you need an identity for a workload. As long as that workload is running, if that workload doesn't exist, there is that identity should be gone.

It shouldn't, it shouldn't exist, um, at all. So that's, that ties into the ephemeral nature of the workloads. I think, I think of it as, um, that's the difference between, um, identity management of environments and, and DL actors within that pupil machines, et cetera.

Um, but workloads are different because, I mean, yes, environments can be ephemeral to degree, you know, be a terraform and things like that. Other things that can dynamically change your environment, but the workloads themselves can change significantly or happen concurrently. Or you, you, you need to tie the, uh, trio graphic, um, identity of a specific workload.

Cuz that's what you need to be able to attest to. Absolutely. The validity of that.

Yeah. Actually, even before that, there is a sub step, right? Say somebody is sitting there and writing code, right?

Mm-hmm. They're writing code every day and they haven't stopped because, oh, that payment service is deployed. We have done with it.

There is always an improvement. There's always some things that they're developing on. So, and from a, from a typical lifecycle perspective, you can almost imagine a developer writing code commits a get, there is already some sort of, um, security aspect tied into it, because most organizations say you cannot commit code unless you have, uh, a developer certificate of origin that says you are who you are.

That is committing code. That code gets compiled, it gets posted into image registry, and that image registry has an, has the image of this payment service, right? Click, click, for example, a docker image.

That image also needs to be signed to ensure that, you know, when we all have this experience, I dunno if you're using a Mac, sometimes you download something and then you double click it says, I cannot open. And then you right click and say, open. This is developed by unknown developer.

Do you trust it? Click open, and then you say open, it becomes trusted. So ideally in a, in an enterprise, we want to ensure that, you know, there is, that code is signed by authority that is managed by the security team.

So once you sign that, that container image that is in the registry is used for deploying that workload that we talked about, like payment service becomes a reality in a container in this one. So at some point, if we sort of, you know, look at, um, look at the, the provenance of this one, we should be able to tie back this, contain this workload that is running in cluster A in aws or Google Cloud has his provenance. That can be tied back to the image that was signed by Extron, which is on registry X with a source code that is available here, signed by these developers, which contribute all back.

So then you have this, you know, almost like a, like a, the, the whole aspect of, you know, all everything that people are doing with supply chain, right? So that's essentially fits into that model. So you can always go back and tie back its provenance back to the code.

Um, and that front time, there is an identity associated with it. Yeah. I'm curious, uh, um, I'm always curious about the intersection of security, engineering, security world, and of course, software and, and the, you know, DevSecOps, yes, there's shift left and all of that.

But I think more importantly is how are, how does security engineers view this aspect of identity management? Because machine identity probably met more machine, you know, machines literally and virtualized. Um, but in a Kubernetes mo uh, uh, Microsoft's world, you know, we're TA having a much different conversation.

Spiffy exa Yep. As a framework for that. Yep.

Um, what kind of security engineers typically are talking to software and software infrastructure, uh, developers and engineers about how we're securing the environment and the workloads? Are people that come outta software, or is it a security engineers that have kind of delved into the Kubernetes software architectural world? What do you see happening with that?

It's a, it's a very interesting question. I think, you know, uh, I'll, I'll tell you cause my experience has been, um, very, very, very, um, so it is a continuous education point because, you know, you can, in some ways, you can look at the, the classic security folks that have been in the organization for the last X number of years, right? So they've been around for a long time.

So there is always a security organization. Platform engineers are somebody who started off what, 5, 6, 7 years ago and mm-hmm. Evolved from VMs to, you know, things like Pivotal to all the, all the various different containerization from Docker to Kubernetes.

So that's, that, that world has sort of, you know, slowly evolved in the past 6, 7, 8 years. Security has always been there. So we go to talk to security and talking to them in the context of workloads and Kubernetes is a hard conversation because it's, it's doesn't sort of, it, it's not in the normal sort of a conversation that they have, right?

So when you talk, oh, ca and p k i and this, that's understood. But the moment you say you need to secure a workload, what's a workload? And then you need to, yeah.

So when sometimes conversation is more educational, but on the other side mm-hmm. Platform engineering. Um, I mean, five years ago, if you asked me to secure that workload, I had an easy way.

I would run open ssl, generate a self sign certificate, attach it to the workload and say, I'm done. Cause I didn't know anything about, uh, compliance and ca policies and organization managed cas and everything. So, so that, that, that security engineering or the security teams and the platform engineering and the developer.

So there's multiple levels of sort of, you know, different conversation to be had about the value that they get for automating and thinking about security. And this has been a constant education thing for us. And we go to security team and say, your security team, you've been managing this aspect of machine identities for 15 years.

Do you have visibility to all of the machine identities in your cloud native environments? Very often the answer is no. And then we talk about, you know, what should they be doing to get that visibility so they can manage, on the other hand, platform engineering, say, well, I didn't, I, I don't know about security.

All I needed was an identity, and going through the route of getting an identity from a security team would take me two weeks. I'm not waiting two weeks. And that's your point about going fast, right?

Our workloads get deployed every day, and I need an identity for it. So I just figured out something on my own and I got an identity for it. On the other hand, developers which are developing the code, they say, I mean, it just needs to fit into my pipeline.

As long as I can automate something, I can consume it. So, so, so most of our education has been around one, to ensure that the security engineering have a good context to ensuring that your workloads span or your, the nature of your workloads have changed. It's not that Apache instance that ran on that VM that you need to secure 10 years ago.

You may have a hundred containers that do the same thing running in Kubernetes clusters. So from a work perspective, you're still accountable for securing those workloads. You do have a set of services, set of machine identity services that you can roll out to your platform engineering team so that they can utilize the platform that you are managing from a ca perspective and still get the best benefit out of it.

And that's where cert manager fits in. Cert Manager, essentially, I see it as that bridge between the platform engineering, which they understand very well. Cert manager, oh, it's a certificate controller runs in Kubernetes.

Great works for me because I live in the world of es mm-hmm. Security teams says, well, we have some consumer called cert manager, which needs identities from the CA platform, or the ca u or my internal PKI infrastructure that ma that, that, that issues certificates. Well, let's connect them both.

And then you have security team who have the ability to govern and manage certificates or machine identities. And from a platform engineering perspective, all they did was connect to the platform. Um, this is an ideal world, but to get here, to your point, it takes a lot of conversations because mm-hmm.

The value, each one of them sees very different from the perspective of, you know, how they, uh, how they get it. So, so we are, we are in a continuous education board to, to, to, to a short answer to that. And, um, and I think, you know, in some organizations are doing really well on that, you know, in terms of, you know, trying to get, try where, where there is, uh, a good relation or a good working relation between security engineering and platform engineering.

This is an easy conversation mm-hmm. Where security folks have controls that have not sort of, you know, adopted to modern cloud native development. Right.

It is typically a hard conversation. And, and I'm, I'm, I see both and I'm trying to bring, uh, a middle ground is is, is is always a, always a, a conversation. Yeah.

You know, I think some of the, um, some of that middle ground is, is all the things that security teams know about in pki I and certificate management and how you use them, why you use them, you know, using external certificates authority. Yep. Uh, ca for that.

Um, the way I explain it to folks, or at least start the conversation, is essentially what happens in the Kubernetes Cloud native world, the network is inside of all of that instead of the outside that connects to it. That's what all these microservices are talking to each other though. They're, they're over over api.

That's right. Absolutely. They're all being managed through services that are accessible through, uh, digital communications APIs.

And that's what we have to secure. And we're gonna do the same thing we, we do in network elements and communications happening across networks to all these things that are happening and changing a lot inside this Kubernetes world. So while that may look a little mysterious and complex, you know, a lot about already about visual certificates and, and certificate management and why, and what and how, and what we're really doing is applying it to this world, but also with a lot of automation because Absolutely.

Change. Yeah. Or quickly.

And that's then you've got a good starting point for the security engineer to have that conversation with the platform or security or architect about this. Okay. Help me understand.

Okay, great. All right. Let's get into the Z your ca.

Okay. That's where you're going to, that's how we rotate keys. Here's how things, you know, exactly.

Authenticate, here's how they get torn down. All of those things. And attestation for all of that security people go, I know that.

Now I know it. In a new environment. Yeah, yeah.

At attestation is, is specific. I think that's where we start. I mean, I, I, I'll sort of, you know, expand the conversation.

So we were talking about Spiffy a little bit ago, um, a little while ago talking about, you know, how that plays into your role, right? So, but, but there is another, there are other implementers of Spiffy, which is spy, um, and at testers play a huge role. Going back to the same example of, of that card payment currency survey.

And if you sort of, you know, think about it, if you sort of an expand that to say, well, by the way, card service runs in, in my Kubernetes cluster that we are managing in our data center. Payment service actually runs in aws currency service runs in Google Cloud. And now we sort of, you know, think about, you know, how they have to talk to each other from an identity perspective.

We ensure that an identity is issued for each one of these services. Mm-hmm. But that doesn't preclude how you can connect to them because mm-hmm.

Google says, in order to talk to me, you need to have a workload identity, which is a concept. Yeah. Google has AW says, oh, you have to have a proper IAM role and the permissions associated to talk to that workload.

And that's where these Spira testers come into play, which is very powerful concept, essentially to say that, well, this identity that is in Kubernetes in cluster A can be attested using or translated with the workload identity that is for Google Cloud or an IM thing that is for, uh, you know, in, in aws, so there is an AWS tester, there's a Google Cloud, arter, there is a physical something else. Testers and all of these arters play a huge role in the world of Spire, essentially to ensure that each service can authenticate itself to each other while you focus on the primary requirement of providing value to customers. Right?

Don't worry about, you know, how to, how to connect to aws. Well, you have, there are things that you have to do AWS specific to connect to aws. You can't do something generic.

It has to be AWS specific. You have to do something in Google Cloud. You have to do something specific to Google Cloud.

But from a generic identity and, um, authentication perspectives, you want to design something that leverages all of the capabilities. Um, and then even in that spiral, as you attest, there is the at tester, and then there is also the, the workload APIs. Cause each of these workloads themselves need to figure out how to leverage those identities, right?

Like if you say, if you call me aws, you have to identify yourself in some way. If you call it Google Cloud, you have to identify yourself in some ways. So all of that has to be sort of, you know, implemented.

It's a very interesting space because, you know, from our perspective, we also see that, well, if you are going to identify an issue using spy, so we've built an integration into sp uh, SPY has the SP is extremely extensible, pretty awesome tool, obviously. Um, there is an upstream certificate authority plugin, and you can see where I'm going with this. Mm-hmm.

The moment you say a ca plugin. So we can integrate into that, which means you can integrate back into our, back into the security organization and say, and that's the kind of conversations we want to have with Security team as well. You will hear New Terminologist, you'll hear Spiffy, you'll hear Aspire, but they all need an identity that is managed and controlled and governed by you.

So there is integrations available, cuz many times security teams are more focused on, I'll give that one year certificate for that web server and I am good. But we say it's not good enough. You need to be able to enable these teams to be able to sort of, you know, be self-service, have that automation framework in place, you have to have this, um, you know, some sort of assigning certificate mechanism through which you can, uh, allow or facilitate those, uh, workloads to be signed on their own.

So, um, and I'm pretty sure you've encountered this in the past, security teams will never issue an intermediate to somebody and say, Hey, here's an intermediate, go do whatever. That never happens from where we saw an opportunity with the security teams say, that is a basic requirement for workloads that run in cloud native environments. They're not gonna come all the way to a ca for every single workload to get a certificate.

That duration, that latency is just not acceptable. You need to have intermediates where the workloads are. But by the way, security team, we will provide you capabilities and, uh, functions to be able to manage that.

And that's essentially where, um, just as recent, I don't know if you had a chance to look at it, uh, we announced during UHON in Amsterdam, uh, a new sort of a functionality or, uh, a product addon to our, uh, our capabilities that we call Firefly. The idea is that this intermediate is now a managed intermediate from a security perspective. Um, otherwise, typically from a platform engineering perspective, I would just go, can you gimme an intermediate?

And the first answer is no second answer, no third answer, no. So, I mean, every time it'll be a No managed one. Hmm.

Okay. Managed one. It's okay, we can talk.

Yes. Actually that's, I think that's, that's Easier. Easier in hierarchies.

Yeah. Yeah, exactly. In hierarchies for a reason.

Yeah. Yeah. Well, you can create as many hierarchies as you, you can gimme one level above and perfectly fine.

And even then it'll be a no from a security, um, uh, teams. com. Like what stops me from, I mean, it, it won't be usable outside on a browser or anything.

Right? But internally, I can issue certificates. And I think that's where we talk about policies and you know, how you can govern them and, you know, ensuring that, you know, you can only do things at a certain, certain way.

And all of those policy controls that we talk about, I guess that's the difference, uh, between identity management and p policy enforce policy Policy enforcement. Yeah. Yeah.

Well, Unfortunately, we're gonna have to, I, I understand. Keep going. Yeah.

Um, I'll talk to you about an event we've got, hopefully we can, uh, get you back on and, uh, be part of Absolutely. Cloud-native event that's, uh, coming up. This is, Yep.

Absolutely. Been fascinating to talk to you. C uh, thanks for joining us, especially from your, your dynamic travels and, and undisclosed locations, wherever that may be.

Yeah. Wish you safe travels and we'll see you back again. This was, uh, Citra Meyer who is senior director of Cloud Native Solutions, and where can folks go find out about Firefly and check out all of the other great capabilities that vany offers.

com. That's the, that's the quickest way to come and, um, you know, understand, uh, everything about, you know, what we do at Bei, more information about Firefly, how we can help support, you know, all of your communities environments. com.

Uh, It's a great website if you're a security engineer, kind of getting your head around the Kubernetes microservices cloud native world. It's a great site to look at because you're talking all about how you secure identity management working in that environment. So, good resource.

Thank you very much. C good talking with you. Thank you.

We look forward to having Absolutely. Thanks much. Thanks for having me.

Yep. Thank you. You bet.

This is Techstrong Tv. Hi everybody. Welcome to this really special event.

We're talking about Platform Con, what is happening, what's hot in platform engineering, and, uh, we have some very special folks here, uh, talking about the conference in the event Platform Con is happening on June 8th and ninth. com/register, uh, to register for the event, find out more information, check out the agenda, all the great things that's gonna be part of that. My name is Mitch Ashley, I'm CTO with Techstrong Group, the folks that are helping put on this video.

And, uh, we're gonna be kind of doing a little bit of a warmup event here. Uh, and we're talking about some of the topics that are happening, uh, at the conference, some things that we're excited about, talking about, um, maybe wanna learn more about, you know, we're bringing our own expertise and experiences, uh, but we're also coming to Platform Con to, to learn from other people too. Uh, so we're, we have a great panel together.

Um, I'm going to ask each of the folks to introduce ourselves themselves, and then I'll, we'll talk a little bit about what, what do we mean by platform engineering, if that's a relatively new topic, and we'll kind of dive into it from there. So, great. Um, I'm happy to have our panelists introduce themselves.

Uh, SUSE, why don't you introduce yourself first? Yeah, I'm happy to, um, nice to meet you guys. I'm, I'm happy to be here.

Uh, so yeah, my name is Suza. I'm a product manager at Home Tech. Um, among other things, I'm involved with the developer experience aspect.

So essentially trying to get to the bottom of pain points and bottlenecks that developers face in their day-to-day work. And of course, also as part of that, exploring ways of reducing friction, um, along the application delivery lifecycle. Um, so that's my main focus at the moment.

Fantastic developer experience. What a great, what a great topic, title, et cetera. So very cool.

Good to be talking with you. Hey, Brian, how about yourself? Would you, uh, introduce yourself?

Yeah. Yeah. So, Brian Douglas, uh, on the internet, I go by bdu e on places like GitHub and, and Twitter.

And, uh, most recently spent five years working at GitHub, um, helping with their developer experience and developer relations as well. And then, uh, back in September, started running my own company, uh, called Open Source, which we're providing business intelligence in the open source software. And, um, yeah, my talk is actually around this getting to release as fast as possible.

So C I C D has had a lot of evolution in the last few years, and I've come to become a consumer of all this evolution and, um, mostly a front end JavaScript developer, but when I need to choose a platform to help get releases cut, um, always look into to the Lord, knowledge, but also share, uh, my experience, which is, I wouldn't say expertise, I just happened to be a great, a great consumer. It's nice when you're speaking from practical experience as well as knowledge, right? Which I think all us bring to the table.

Very cool. All right, Jay, last but not least, introduce yourself, please. Yeah, sure, sure.

Yeah. Thanks for having Maich. Uh, I'm Jay.

Uh, I'm from India, currently working as a software engineer at, uh, we cater, uh, as one of the largest women gateway, the leading women between India. I work for the platform team, and, uh, basically what we do here is to manage the API gateway for, uh, we have our own, uh, thought of a custom customized API gateway on which we two, uh, are tooling on. Uh, and my talk, uh, for platform is based on similar topic, like how we are managing, uh, the edge at Razor Pay.

So really excited to be here. Uh, eager to learn from all of you. Thanks.

Fantastic. Uh, Susan, I don't know if you mentioned what your talk was about, did you? So I didn't, I didn't actually.

Um, my talk is about configuration drift and how to eliminate it, um, so that it's kind of the problem space I'm diving into. And as part of that, I'm also touching on score, uh, which is an open source project that, uh, aims to eliminate that exact problem Configuration drift, who has not had that problem. Okay.

Exactly. Exactly. Well, you know, um, so platform engineering maybe is a relatively new term, uh, to folks.

It's something, you know, we've talked, been talked a lot more about in the last, you know, couple of years. Uh, Gartner kind of defines it as this idea of, you know, I set of tools, capabilities, process, processes that really helps, I, I think of it as developer productivity and kind of reduce, um, get back to the, the core of how do we support our developers and their productivity and the technologies that they use, cuz things like DevOps and cloud and everything. We have a lot of people involved in our software processes now.

And, uh, platform engineering kind of brings that, that, uh, that focus there. Um, the first platform con, I guess happened in 2022, June. And, uh, you know, uh, we were, at the time we were thinking about, uh, puppet the field cto, uh, Kirsten kind of guy.

The community urged them to come up with sort of a descriptive model of what platform engineering, uh, really entails. And I'm, I'm curious about your thoughts on platform engineering definition. It's like everything, there's multiple definitions, right?

There's rarely one definition to rule them all. Um, but, um, how, how would you put some terms around it? We'll kind of use it as our working definition.

Do you want, do you want to jump in first, Jay? Sure thing. Yeah.

Uh, but I, on, on, on to begin with, like, I totally agree with you, right? Like there is no definitive sort of description around if we can define platform engineering into one or two sentences, right? It varies on the use case that we have, uh, on, on day-to-day basis, right?

Uh, I would like to just quickly give an example. Let's say there can be emerging startups or companies, right? Uh, where they have simple sort of their as instructure defined, and, uh, they have, uh, fairly using any sort of product for the tooling.

Uh, on the other hand, there are large organizations having, uh, you know, like fairly large size of developers. Uh, at the end, uh, according to me, what I would see platform engineering working for both of these cases would be like to create a set of reusable tools or let's say services and infrastructure, uh, which at the end of the day help developers to build and deploy applications more quickly and efficiently. That is what, according to me, platform engineering majorly lies about.

And that is what, uh, we also try to utilize work and cater for the teams that both here Makes a lot of sense to me. Good perspective to take two. How about, uh, how about you, Susan?

Yeah, I mean, I would totally agree with that. It's, um, similar to other terms like DevOps, for example, right? Like if you Google it, there's just, uh, so many, uh, definitions and articles you can read into.

Um, in terms of the, the definition that I usually go by, I'm of course also a little bit biased, uh, coming from hok. Um, we typically describe it as kind of the, the discipline of designing and building internal developer platforms. So that, uh, contains tool chains or workflows that essentially enable self-service, uh, for software engineering organizations and specifically also developers, uh, which is quite a, like, high level, um, definition.

But as you mentioned, uh, Jay, like, once you dive deeper, it's like kind of dependent on the use case. So I feel like to get a basic understanding, it is quite helpful to, to keep it as high level. Yeah.

And Mitch, if I could jump in too, I imagine you're probably gonna go to me next. Um, yeah. You, You read the room, right?

Yeah. Um, so I mean, I've professionally been coding for about nine, almost 10 years. Uh, I've been copying and pasting code for longer than that, but, um, always been able to solve a problem in code.

Uh, and when I started working professionally, I didn't know, you know, all these pipelines and servers and how to orchestrate that. And I've, my career's benefited from platforms and like using tools where I could just focus on like writing the Ruby JavaScript pipeline code. I need to get the job done and not worry about how to orchestrate an entire platform.

So like, uh, we've all touched on this and you'd mentioned, you know, getting us back to, as developers, get developers back to doing what they do best, uh, is how I'd, I would describe this, It's interesting, uh, just my own mental model of this is kinda remember thinking of the world as the IDE and all the plugins and everything that I can access through my id, whatever your favorite, favorite or favorites are, right? In the languages that you're using and today's world that plugs into a whole tool chain workflow platforms that we're, we're doing development on maybe different deployment environments. We're doing this in the cloud, doing it on our computer.

Um, you know, we're multiple things, right? And we have, uh, you know, requirements, documents and GitHubs that help set up our environment. Poof, we're ready to work and go.

It, it's, it's really amazing to me how more productive we can be to bit today with the tools and capabilities we have. But it also can be really daunting if you're like, stepping in and that, and that's not just set up for you to go, I mean, is that, is that anybody else have that experience too? Jump in?

Yeah, it was the same for me. I mean, shortly after my studies, I worked, uh, as a JavaScript developer as well, and our team, we had more of the issue of like classic siloing. So I had absolutely no clue what was going on, um, when it came to actually deploying my code.

Mm-hmm. Not great either. So I feel like bridging the gap there and like making that part accessible, so in terms that I can like self-serve as and understand what's going on, because when something broke, uh, back then I was absolutely lost.

So, um, I mean, we know that siloing is also not the way to go in terms of just throwing code over the wall, um, but kind of like passing it through the fence, uh, is I think what, what platform engineering is, uh, aiming to do. Yeah, I was gonna say that I, I've, I've got a lot of friends who went to school in, in Canada, and, and when you're in engineering Canada, you get the sort of special ring and like a lot of folks already know about the, the story about engineering in Canada and the bridge that fell down, but like that symbolism of the ring, which is like a part of that bridge that fell down, it's like to remember, oh yeah, this is why we do this today. Like, we don't have to understand how bridges work or how pipelines work or how servers work, but this note that someone solved this before you, and that's, that's the, that's what I see as far as like, again, going back to my story, uh, I just want to ship code some code that I know is gonna work.

I don't know how it gets to the cloud or how the cloud works, uh, but I do know that there's a platform I can that's gonna be supporting me, like from, it's supporting me, but also the next engineer and the junior engineer team, they're gonna figure this out without need to know every si single intonation of how this works. Yeah, I mean, uh, we agree with Brian on some points, but, uh, just one point where I would like to back to defer is that, uh, even though there is a lot of tooling available, or let's say we have a use case, we Google it out or we check out like what are the tools available for the same, uh, not doing the internals might can backfire on the problems itself. Let's say, uh, previously while I was working at a different firm, we had two euro sort of an on-prem deployment.

That strategy I cannot utilize sort of utilize on the setup that we have now. So it, Verizon, as I've said earlier, it, Verizon on use case to use, so is good to know, not at least the entire sort of internal structure of the tooling that is available. But, uh, you know, like, uh, if we have the gist of what needs to be used, Ben should be really helpful with the, uh, with the, uh, products that are available right now in the market market.

And I would say that we're, we might be saying the same thing too as well. Like I, I think when there's a team and a structure, like there's definitely no I in team, but there's like a, there's definitely a, there's a me, but there's, there's us. And like if there's someone on the team that does be, that can transfer that knowledge through documentation, uh, and like really good guides, then we could all now solve harder problems.

Uh, and that's like, that's more of my, my statement. It's like, I, I agree, you should know what you're using, um, but we should also like document and be able to move forward and solve, I guess, whatever comes after ai. Mm-hmm.

Well, you know what the, the, the concept of flow comes to mind too, right? It's keeping ourselves in the groove. I mean, it takes a, it takes a lot of work to context shift to get ourselves that cognitive load of getting back into the head space of what we were working on and we're maybe in halfway through understanding it or writing it or whatever.

And those disruptions to that, I mean, they have a big impact and people who are not writing software don't always appreciate it. They may have their own challenges that way, but you know, at, at least for me, you, you really dive into it, you know, mentally and you gotta have your head in there. So in a way, platform engineering is increasing flow, helping people do what they do well, spending their mental cycles working on those things.

And then, and probably along with that, this is something I think you mentioned, Brian, is, is we're software people. So we, we also write things to make things better for ourselves, right? Which is part of, you know, our own world and, and platform engineering seems to be encompasses providing that environment, um, as well as helping us improve it, improve it over time.

What do you, what do you think of as, as tools? I mean, there are literally thousands of people that will be part of, um, platform Con again this year will be part of the livestream. And kinda like, you know, in the DevOps world or SRE world or platform engineering, there's no one tool that says, this is, if you got this and plug this into your id, you got platform engineering.

But how would you put some ideas around what assign some of the capabilities that you can use through tools, open source, commercial, cloud, others? Uh, you wanna start first, Brian? Yeah, I mean, so my, my talk is it's focused around, it's not meant to be a product talk.

I just happen to want experience in GitHub actions. Um, and I see that tool as like a base layer. Like it's, it's a, a great way to get started.

Uh, but it's like not the end all. Like there's now a lot of good evolutions of C I C D where like continuous integrations, it's a bit commoditized now. So, um, I'm seeing tools like Dagger, which gives you a better local environment to test your, your C I C D pipeline if you choose to use get up actions or Jenkins or anything else.

And that flexibility, uh, to be able to say, okay, well it works on my machine, but also works on this cloud and it works on this server. And like you could repeat that experience, um, is again, like it's, I still, I hark on this one, this one notion of like, I remember two jobs ago I sat down and someone showed me what Docker was and they showed me how that touches Kubernetes and this is how we get stuff deployed. And it was just the intro first day on the job, and I never had to look at it again.

I just knew it worked. Um, and that's what I love about like, just figure out the sort of base layer tools so that way we can go reach for a dagger. There's a new tool called Cicada, similar to Dagger.

You can write rust or whatever language you want, and it converts in the web assembly to build out your, your, uh, your pipeline, uh, yourself, so that way the next person doesn't have to worry about all the ins and outs, Web assembly hole. A very cool thing about, um, you know, runtime environment got come. Speaking of your Java background, right?

Sort of the next evolution of maybe that idea for distributor environments. Jay, jump in. I'm be curious your, when you think of kind of tools and the things involved in, in a platform engineering environment, what comes to mind?

Yeah, So first thing that comes to mind is definitely something, you know, like that enhances developer productivity, right? Uh, with, with, with the increase in the number of developers across organizations working on different microservices, right? As we, uh, look at the architecture systems, right?

Uh, every developer has its own set of requirement needs a different, uh, deployment architecture or something like that. Uh, so the tooling around neural kit port or, or something like that where we can have our own micro set up or micro capability set up, that is just said, uh, that replicates the broad environment and helps us out to test the things as well as, you know, like, uh, enhances the confidence of the developer before any sort of deployment. Uh, that is one of the great advancement that I do see in the field of platform engineering, and that is helping us out every day, uh, while we are shipping code, uh, multiple times a day to production.

So yeah, that is one of the things that I do look forward to looking out to some of the interesting talks around the same in the platform com. Very nice. Yes.

Your, your, your thoughts. Yeah, I think those are all great points. I mean, when it comes to tools, I think, um, two big areas are different.

Definitely configuration management and ensuring, uh, like a standardized approach when it comes to that. Um, that also touches on what I'll be talking about, right? Like you don't only have different configuration per environment.

Like you want different d database credentials to be, uh, injected on development, staging and production, but you also have different tech and tools you work with, right? You might be using Docker locally and then you deploy to Kubernetes with Helm, for example. I think, um, having tools kind of focus on the developer experience here and understanding that, like using all of these tools can be quite complicated.

And building these abstraction layers is definitely a trend that we're seeing. I mean, the, the backlash there is that people might feel abstracted, so it's like abstracting without feeling abstracted and finding like the right level there is, I think what we have to have to figure out, right? Um, so that, again, uh, the complexity is compartmentalized in a way that things are actually accessible to everyone while maintaining that flow that you mentioned before.

Um, so yeah, I think that we're, we're seeing, um, like those things emerge across the board. A lot of movement in the open source community. Uh, an example is score, uh, which I'll also be talking about, which, um, aims to do that, put the developer experience first, um, when navigating this like jungle of, um, tooling that teams often work with.

And, um, yeah, I think those are the, the focus areas, uh, when it comes to actually wanting to adopt, uh, according tooling, You know, and, and people have different, what they enjoy doing. Some of us, like, I'm gonna dive into Kubernetes and the depths of it and becoming the expert that I can be in Kubernetes and, and others of us. Like I use Kubernetes, I want to know what I need to know, but in, that's not my thing to be the expert on that.

I'm going to kind of be, be expert at maybe to a reasonable degree on multiple things or maybe pursue something else. So we each have our own interests, right? And, uh, I know there's times that like, I want to go learn that and then I move on to the next thing.

And if, the reason why I bring this up is, I think one of the cool things about platform engineering is that it's not just a, a tool or a set of tools, it's an evolving set of tools. We might use Docker and Kubernetes for a long time, but we also will be introducing new stuff. You know, we've already mentioned, you know, dagger were talking about earlier, Brian, and new tools that come along and we wanna wrap into, and, and of course that's what talks that, uh, platform Con are about right.

To hear about those new things, um, what people are working on and solving some of the toil problems like configuration drift, you know, things that we, we all combat and, and battle for a long time. So, but that's what keeps it interesting, I think, and exciting, exciting for all of us. Um, I'm curious, you know, we're, we're all experienced here, right?

You know, we've been been doing this kind of work for a while. Um, what do you think are some of the positive advancements or improvements that we've made through this focus on platform engineering, uh, in, in relatively short time? It's not like we've called it platform engineering for 20 years.

We may have been doing some of those things, but yeah. What do you see as some advancements or improvements? Um, suse, do you wanna, you know, start first?

Yeah, sure. I mean, I think a first great improvement is that the idea is spreading. So it's like it's trending, it's a hot topic.

Uh, we talk about it, it even has a conference now with Platform Con. So I think that's a, a great first step and, um, that also then the, the next step is logically putting things into practice, uh, which comes with trial and error. And I think having that discussion going on, that experimentation on how to implement things on, like agreeing on that working definition that we talked about initially, um, like this wave of interest and experimentation, I think is, uh, great to see.

And, um, uh, a great first step. And I think, um, we're, we're on the right path there as a community. Very good jump in folks.

Yeah, I, I was gonna say, I made this tongue in cheek, but the centralization around Yammel, uh, is actually, I know a lot of people have like, you know, visceral reactions when you say yammel, but like, just by making a decision that, okay, this is how DevOps tooling will be built around. And I know like Hash Corp has, uh, their own hcl, but like now we can sort of centralize our tooling around similar structures. Uh, it's easier to sort of pick and choose across ecosystems.

So yeah, as Susan was just mentioning, like, this decisions have been made, we can either choose to build a next new thing or we could use whatever the pace layer, which is, for me, it's yammel, uh, and then as long as I have a consistent thing I can go back to, I can build on top of that and it's predictable. Mm-hmm. Yeah.

I also would like to utilize sort of at at few more points earlier on top of what Susan and Brian has said, right? Uh, with, with agreement in adaptivity of platform engineering or platform as a culture, right? Uh, we have been doing a lot more experimentations around tooling, uh, than what we were doing before.

So now, uh, with, with the available number of case studies that we do have on a daily basis, right? I can, you know, like, check out for my use case or maybe, uh, someone can check out what we are doing over here through the means of this conference, right? That we can see.

So, uh, as far as a platform engineering is considered, knowledge is spreading on at a really, you know, like fast pace. And this will not only help us out to solve our problems, but with, it'll also create a reflection to other people on how, uh, challenges can be taken up and solved at a life scale. You know, I, I, one thing I want to kind of bring back up that I mentioned earlier is, uh, the fact that we're focusing this on, uh, as a discipline, uh, and kind of getting back to the pro productivity, efficiency flow, helping people who are creating software, uh, be able to spend time doing what they're doing, that to me in and of itself is a positive huge step.

And sometime having too many options is actually a disadvantage cuz now you can spend all your time figuring out the right way to do it or what way you want to do it and how to make it work, versus just kind of picking up like, okay, we're doing it that way, great, I can do it that way, and maybe I'll help make it better later. Or I'll just, you know, crank on with my job now. But I think that just having it as a discipline and a focus and the fact that, you know, you all independently say, well, you know, I'm focused on developer experience or developer productivity, and that tells me we're working on some good things, some people who can appreciate having that help.

So it's awesome. I, I'd like to dig into a little bit more about your talks. Um, Jay, maybe you could just give us a little bit deeper, kind of richer what you're, what you're gonna, what you're talking about, but I'm also curious why you chose that is what you want to talk about.

Definitely. Sure. Yes.

Uh, as I've mentioned earlier, right, I'm working for the team which manages the API gateway. Uh, I'll be speaking for the topic, uh, at, at repay, uh, which is the API gateway for DTO protected high skill environment, uh, being one of the leading API gateway or, or payment gateway, I'm sorry, payment gateway for the country. It is important for us to ensure availability and also, uh, that should not impact the scalability of the product that we are serving over here to the customers, right?

So that comes up as its own sense of, uh, of challenges, right? So API Gateway being a commonly used tool for API management, right? But the reason is the customization for the learnings that we did faced or, or the challenges that we faced by, you know, like building API gateway, our own set of custom tooling on what whatever the available solutions are, that is the major reason, uh, to, you know, like pick this topic up to share our learnings and also to get feedback upon like what improvements are there, uh, that can be taken up, which can help us at, in, in our future use cases also, right?

Uh, on top of it, like there have been several challenges also that we have, uh, we have purelife product con or achieved, uh, with, with the talk that I'm trying to present over here. So yeah, looking forward to that API security API gateway is all huge, huge, huge important topic. Uh, Susan, how about you?

I wanna hear more about, so what, what, what caused you to get to the front of the keyboard and say, yeah, I gotta I gotta talk about configuration drift? Yeah. Just because, uh, it turns out to be a problem that a lot of developers struggle with.

Um, so maybe it's helpful to clarify what I mean by configuration drift, because it is also one of these buzzwords that can mean a lot of different things depending on, on your context. So, um, I'm talking about configuration drift between environments that run on different platforms. Uh, so what I mentioned before, you might be using Docker composed locally and then deploying to a remote environment that runs on an orchestrator like Kubernetes, for example.

And, um, the problem here again, is to keep configuration in sync, um, across these tools. Um, so what I mentioned before as well, um, making sure that the right, um, values, uh, are injected, but also that, um, for example, resource dependencies are provisioned in the right way. Um, so, uh, dependency on a Postgres database, uh, is resolved differently locally with Docker compared to Kubernetes, where you might rely on a tool like, um, Terraform, for example.

And, um, that's what kind of causes the risk of, of translation gaps, essentially. Um, so that configuration changes essentially don't make it to that next environment that runs on another tool. Um, so working with different environments that run on different platforms is kind of the, the problem space I'm, I'm diving into as part of my talk.

Um, and then against the background of that, do I wanna, um, introduce score this open source project that essentially, um, tries to provide, uh, an, an answer to that problem, um, by essentially introducing a workload specification file, um, that lives with your workload. It's platform agnostic, it's environment agnostic, um, and thereby allows you to kind of generate the configuration you need without being so involved with that exact environment your workload runs on, or that exact tooling, uh, that runs underneath. So, um, I don't want to get into monologuing here, but, uh, that's the, that's the, uh, grand idea.

And, um, I mean, I, I chose the topic because I, yeah, just think it's a problem that affects a lot of developers and teams struggle with it. I also think it's highly relevant for the platform engineering community, uh, simply because it ties directly into the discussions that, that we're having right around configuration management and self-service when it comes to resource provisioning. So, um, I think that's why it's just super interesting to discuss it with that kind of audience.

Um, and then lastly, adopting score or essentially eliminating config drift is, in my opinion, only possible if you have that platform engineering mindset in place already. So there's like that work that has to be done initially. You can't just, um, download score and you're good to go.

Um, as always, there's just like a, a lot of work that has to be done inside of that. Yeah, no, I'll mention my talk, which is, uh, yeah, re repeatable release management, um, uh, started my career as a full stack dev develop developer and increasingly became more of a front end developer more and more as the years gone by. Um, so we in open source, we have a, a build system that we use at every single project.

So repeatable builds, and every time we start a new project, we have the same build system, uh, that's built on top of getup actions to produce a tarball or a zip, uh, for us to go host and and deploy other places. So whether it's a, uh, a, a server side project or M p m package or just a static website, uh, we have the same build system that we were able to reproduce and reuse. Uh, and for, because of time, I didn't actually go into detail on the, all the in ins and outs of, uh, of the tool, but everything that we've done is open sourced and, and viewable within our, our GitHub repo.

Hmm, fantastic. What was great is all of you very passionate about what you're talking about, which is, that makes it easy to have a talk. Um, so just a heads up, I'm gonna ask each of you if there's a topic or a talk, uh, set of talks that you're really kind of previewed and on the agenda, really interested in checking out.

Um, so before you do that, um, just kind with, with the organ organizers, um, of, of the event, uh, Caroline and, and other folks, the ones that kind of stood out, jumped out to me just to name a few. So, you know, some of the things that are happening, there's a talk on platform as code simplifying developer productivity design with reference architectures coming from a couple folks from, uh, McKenzie, uh, a person for Gartner, I'm gonna not mention names cuz I'll, I'll butcher their names. But, uh, how to communicate the business value of platform engineering.

Hey, how to get funding k k a, that'd be my interpretation of that. I talk about building the perfect platform in the midst of everything else. I talk about a journey into internal developer platforms.

So these are all people who are, have gone through going through this process of implementing platform engineering. There's also a couple of other interesting talks, dev DevX, uh, developer experiences, not DevOps, investing in developer enablement to reduce barriers to continuous delivery. Again, I think this is kind of on that theme of getting back to developer productivity, which is another talk dev, uh, DevX, what exactly drives productivity?

com, uh, n dx, a bunch of companies nesto to name a few. So I thought I really liked those that, that we picked out because it's talking about what it's about to, to create the developer and, uh, platform engineering environment to support your developers and also what we mean by developer productivity and and experience. Um, Brian, any thoughts?

Any, any particular topics or you're like, I'm going as a speaker, but I'm going to learn a bunch of stuff and there's a couple. Yeah, that's the, the fun part is like when you're a speaker, you focus on your talk until it's done and then, then you get to relax. Um, so the beauty of a pre-recording all these talks is that I can actually relax from the start.

Uh, but I, at the current, like we're a team of currently four, uh, at Opens sauce. So, uh, the world, this conference is remote, so everything about culture and working with remote teams and handoff and information sharing, like, that's the track that I'll probably spend the, the most of my time with. Uh, cuz I want to be able to grow and scale a team and folks in different time zones.

And I think what's the beauty of this is like, doesn't matter what time zone you're in, um, as long as we can, we overlap sometimes in our asynchronous meetings, uh, or sorry, with our secrets meetings, but how do you build a a really strong asynchronist culture, um, is stuff that I'll be, I'll be looking for on the schedule And be tough to get going. But once you get it going, man, it's awesome. Yeah, great topic.

Uh, how, how about you Jay? Yeah, I'm also looking forward to some of the use cases that you have mentioned, right? Uh, how, uh, platform engineering is evolving as a culture, how different teams are using platform engineering in their, in their org and you know, like what, what are change from the last year or what are the new advancements that has been going on, right?

Ensuring all the, uh, perspectives that are there in from engineering. So, uh, yeah, as, as Brian mentioned right now that we have prerecorded and submitted the talk, uh, it would be, it would be good for us to like focus on all the, uh, all the talks that are being scheduled for the topic. And also we would like to connect with the folks or there at the community.

So, you know, like I can can learn and share my learnings also with that. Yeah. Fantastic.

Suza. Yeah, uh, I mean, I'm excited for, for all of it. It was super fun last year to just like have the stream open on the side and like, uh, click through individual talks.

I think I'm gonna keep, uh, close eye on the cultures and stories track, um, just from a product management perspective. I, I find it super interesting to hear more about like, hands-on experience report and like real life use cases. I feel like, um, specifically when you're involved more of the like, theoretical side of things, you talk about definition and concepts and ideas, um, it's actually super interesting to hear how things play out on the ground.

Um, and like hearing about real life pain points and success stories. Uh, it's a good reality check and of course a, a learning experience also for me. Excellent.

You know, I just, in addition to the sessions that I mentioned earlier, one of the things that I always enjoy is the new people you meet, you've not heard from before, uh, you get to connect with and, uh, I don't know if I can meet all 7,000 plus I can't, but if I could, I would. But there's so many great people that you, you know, more people you, you learn from, connect with say, Hey, I have that problem, can you, let's talk a little bit. I wanna find out more about what you're doing there.

Um, it just, it kind of enriches, enriches our work and just as a whole nother resource for us to learn from each other and grow and share with each other. So it's a way of giving back as well as getting so much from it. So, well thanks to all three of you, uh, for spending this time.

Most importantly, thanks for, for your talks and the topics and the commitment to do that, uh, to share with everybody else at Platform Con. Uh, it's been a real pleasure talking with our global audience here. We were talking before, kinda represented by several places around the world just with this team.

So, um, one, one I'll just close by say, saying to folks, whether you're new to platform engineering or maybe you're, you're trying to build it from scratch or you want to go find out what folks are doing, how can I kind of accelerate my adoption of platform engineering? There's so many reasons why you might attend, uh, platform Con, but please check it out. com slash register.

In this video in the description, we'll also put a link to a, uh, nice Gartner article about the uh, top 10 strategic technology transfer 23, talking a little bit about some, uh, topics relevant to, uh, platform engineering. So thanks to all three of you. Look forward to your talks.

Can't wait to hear the dive in and hear more about it and, uh, we'll see everyone else there. Thank you everybody. Thanks Mitch.

Thanks. Thanks for having us. This is Techstrong tv.

Hello and welcome back to the Open Source Summit in beautiful Vancouver. We're with Heather Atkisson, who's from the Lennox Foundation and we're talking about Climate OS and no, it's not an operating system. Heather, welcome the show.

Thank you. Great to be here, Mike. So it's great to see you guys are doing some stuff around open source and climate, but why don't you walk us through exactly what that is and cuz I don't think most people even think that open source has a role.

Absolutely, yeah. So I work for the, uh, open source climate project for, which is part of the Linux Foundation. And our goal really is to start to unblock the trillions of dollars of investment that need to flow into climate aligned solutions.

And one of the big blockers is that people, whether it's investment, uh, organizations or financial institutions, banks as well as corporations don't have the data, uh, and trustworthy data and transparent data, uh, they need as well as the analytical tools to make the decisions to start shifting those investments. So what os climate is building is really kind of a transformational, uh, data mesh architecture, uh, which is the underlying platform for what, uh, we're creating. And then on top of that, we're also building like key analytical tools to aid in that decision making.

Um, and the great thing about open source right, is it's transparent and people can see, you know, what was the math that was done and what models are being used so that they can have trust and more confidence in the decisions that they're making to, to start to shift those investments. Ah, Interesting. How will that process work?

Am I gonna instrument everything? Is um, am I gonna attach like some sort of agent software to collect all this data or how does that kind of work? Actually, we're using the latest and greatest data mesh architectures and it's was, uh, designed, red Hat is one of our members was designed by Vincent Caldera, who's the CTO at apec, and he's put together this fantastic architecture that manages data as code.

And the whole principle behind it is we're not collecting all the data, we're actually federating with the data. So if there are data sources from NASA or NOAA from like a climate perspective, we're going to have access to that, um, and make that available to our users through something we call the data exchange, uh, where people can come identify the climate models. Maybe you're looking at hazards or vulnerability for your assets, um, in a particular area or region.

And you'll be able to pull that data through the data exchange and then apply it, use our tools or use, you know, your own, uh, uh, in-company tools to, to analyze the data and make good financial decisions, uh, loans, investments, things like that. It's no secret there's a lot of emotions attached to this whole topic. So as part of the goal here to take that out of the equation and maybe just have a conversation about here's what the data actually shows and we've edit the data.

Absolutely. And that's where the transparency really comes into play and where open source comes into play because we want people to understand exactly how you got from A to B and that data scientists can replicate one another's results and there is no one model. That's absolutely correct.

Right? But if you see a series of models and you know, the trajectory is similar, right? For all of them, you can have higher confidence in the decisions that you're, that you're making, not only for your company, uh, like I said, but for financial institutions as well.

What role do you think it people will play in all of this? Because there are issues that stem from the way we write codes a little sloppy, uh, sometimes we leave our virtual machines on other times we, uh, don't pay attention as much to spikes and consumption that we don't need to have happen is do it people appreciate these issues, do they get that and do they understand their role in this whole process as well? I mean, cuz frankly, that's just one more thing that we gotta look at, right?

Right. Absolutely. No, and I, and I think people are, um, I think the, the level of knowledge varies, right?

Depending on where someone is personally in this journey around like understanding climate change and the rest that are in front of us. But yeah, as, as consumers of a lot of energy, right, for these models to run and um, to understand the impacts, uh, yeah, that definitely has a, a big impact and, and what we're going, uh, to, to have to address right as, as a planet effectively, what Role are governments gonna play in all this? Cause will they work with you guys and look at that data and run that through their analysis or how's that gonna play out?

Yeah, Absolutely. Our members are pretty vast and pretty, uh, expansive. We've got academic, uh, institutions that are members of OS climate, not only financial institutions and banks, but we're also working with the nonprofit sector as well as some government entities like the N P R I organization and really to solve the climate challenge, right?

You need a community of, of uh, of a lot of different key stakeholders. You know, no one organization is gonna be able to solve this problem on its own. And our founder and CEO Truman Siemens took a look at, you know, how are big problems been solved in the past, whether it's mapping the human genome or developing the covid vaccine.

A lot of that has come out of open source. And so that's why we went with an open source, uh, approach so that we could bring these communities with expertise and understanding, uh, you know, that that can help inform these tools. And our tools aren't just for right.

Uh, I talked about the financial community, but uh, we just announced this week a Sustainable Africa initiative where we're gonna be taking our platform and our tools, uh, to the country of Nigeria to begin with. But our goal is to, uh, build the platform for all of Africa. And, uh, the plan for that is to basically hal out them the, the, uh, the upscale, if you will, and the tools and the access to the cloud infrastructure as well as the climate models so that they can do their own analysis.

Um, and we're starting with agriculture sector initially, so they can do their own analysis and see what changes they need to make and what adaptation and mitigation strategies they need to focus on. So how big is this community actually? Because it sounds like it's getting fairly large.

Yeah, it definitely is getting very, uh, large. We probably have close to 500 folks that are, uh, part of the community right now. Uh, we're adding new organizations and, and uh, uh, companies each day, earth Daily, uh, has agreed to support us with, uh, satellite information and things like that.

And obviously when you're, you're doing and building a public good, I think everybody feels like this is a way that they can help, right? This is the way they can participate and make a difference in, you know, the climate change, uh, problem that we all face. That's an next essential risk, right?

Uh, to humanity. How do I aggregate all that data in a way that doesn't aggravate the climate problem because I'm aggravating massive amounts of data. So is there an intelligent way to go about doing this in this mesh?

Yeah. And so that's where their data exchange comes into play and that sits on top of the data mesh. And like I said, our goal isn't to copy the data, to replicate the data.

Um, our goal is to, to leverage the data. The data is owned by whatever entity, um, has it today. And so we want to connect with that.

And uh, we have a number of folks that are actively building the data exchange to create almost like a shopping cart function, right? If, if you're, uh, you know, someone, uh, in the ag industry in Nigeria and you're interested in your crops, um, you're gonna have the ability to go into the data exchange and with a shopping cart type of function, pick the model that you need, whether it's a hazard, look at the vulnerability for your particular asset. In this case it might be a crop or a field.

And we're working with Linux Foundation ag stacks to understand, you know, the boundaries of those fields and then do the analysis, um, that's required to say, okay, what, what is the chronic level of, uh, drought that this particular field is gonna face and how is this crop gonna, uh, faire and what might need to change when they may need to rotate crops? They need to need to look at different, you know, solutions to, to adapt. But that's the goal is that this data exchange, uh, can provide that ability, uh, and the data is, you know, created and vetted, uh, and owned so that we make sure that it can be trustworthy.

And you, you can see the math, like I said, you can see the process by which, um, you know, the, the outcomes and the impact of the analysis is about it. I'm not marketing whole. How do you convince folks to connect?

Cuz there's probably some entities out there that aren't too excited to understand exactly what they're doing in the climate, or maybe they know what they don't want to know. So, um, you know, how does that conversation go? Yeah, I think, you know, ultimately, uh, you can stick your head in the sand and you can deny um, as much as you want.

But I think, uh, the science is is pretty telling, right? And you see what's happening, you know, we're having a beautiful day in Vancouver, which is not normal, right? And I was talking to some of the folks, uh, at lunch yesterday who are based in Vancouver and, and they don't have air conditioning right in their area.

And you know, now dealing with 80 and 90 degrees summer, um, you can see that the changes, you know, we've seen other areas of, you know, whether it's the US or you see Pakistan with the major flooding. I mean we're, there's example after example, after example that we need to do something. Do you think that to a certain degree, even if we have all the data, there's gonna be some folks who are just never gonna believe and, you know, is that just a part of the life or is there, can we get, you know, facts to convert?

Yeah, I I think there, there will always be the deniers, right? And I think, you know, you have that continuum. We talk about it early adopters, fast followers, you know, uh, get the majority involved.

And then there's some that will, will never get on board, but hopefully, right? Uh, we get the va the vast majority of folks, uh, engaged and that we come up with these adaptation strategies and, and we start making the changes we need. Uh, cuz you know, they're been around for 4 billion years, right?

It's, it's not the the earth that's ultimately gonna be gone, it'll, it's, it's humans at the end of the day. We talked about this in the context of say some entity participating, but we've also seen the emergence of so-called citizen scientists. Um, so can they play a role in these kinds of projects to help collect the data?

Absolutely. We're a truly open source project. Uh, whether it's, uh, individual contributors or corporations, like I said, nonprofits, academic institutions, uh, you know, it's fully open, fully public.

We're creating a public good. We welcome and seek out volunteers, uh, to help us in this journey. org and find out ways you can get involved.

But yeah, we, we welcome everyone into, into the community. It's truly open source. All right folks, you heard in here if you're concerned about the climate, there's a group of folks who are looking for some help and so maybe we can all do this together, would be a change.

That would be awesome. Thank you. All Right, Heather, thanks for being by.

Appreciate it. Have a great day. All right.

And we'll be back in a minute. This is techstrong tv. Welcome back to the open source summit.

We're back here in beautiful downtown Vancouver with Philip Ahman, who's from Bosch and we're talking about embedded Lennox in safety applications, otherwise known as Elisa, right? Right. Yeah.

So we've been putting embedded Lennox in things for years. So what exactly is different here? Why do we need this project?

What makes safety applications somewhat different? Yeah, safety applications are crucial. Maybe cause you need to talk about the threat to human life and which you would like to prevent this, you should need to manage the risk which could happen.

And if you take a anomal embedded system and if you maybe talk about security, we just want to prevent the data get lost, that someone can intrude into the system by here. It's about that the system need to be safe in a way that it cannot harm others. So you need to take a lot of measures.

And for this, they're best practice in place typically with standards, international standards like the ISO 2 62 62 or an ISU 6 15 0 8, which are traditional standards and they are developed by companies for as a best practice of their way of going through processes. But we know that open source is not developed in the same way, like you would do maybe a company based product. And so this is something new, especially when it comes to Linux because Linux brings a very, very large code base and typically the safety applications are trimmed down to the minimal thing which you could do.

Like you don't have configurations normally in a product. This is something where to come from embedded small devices but now use cases get more complexity grows. And by this we are on the way to how can we get safety into an operating system as rich as the Linux or as and that other can benefit from it when building more complex devices going into driving this or uh, robotic use cases, aerospace and so on.

So we can have a scenario where if I'm driving down the road, the operating system crashes and suddenly I crash because I the operating system crash. So yeah, what does it take to actually achieve that level of robustness inside that? Because everything eventually breaks somewhere.

So Yes, exactly. And um, so this is why you really do extensive testing. You write down requirements, you basically make sure you do a lot of risk assessment risk on all of this.

And then when you start to talk about risk, the things just evaluate naturally. So you see all these practices which are written down in the standards and you may want how they do not apply one-on-one. But if you just start in your development and you start talking with another person and I say, oh, okay, when I explain something to you, let me write down a design.

So then I start writing a design and when another one comes and say I just see this design in this perspective, no one sees another perspective, then you add requirements to the whole thing and say okay, we have now a base, we derive things on top and we go forward until we create such a system. And this makes a large chance also opportunity and to make it more robust because you ask what is in there? Let me check, is my testing on a requirements level on design level, implementation level, all satisfied and can I achieve robustness stability over a long lifetime?

And basically this is something which you already have today. A lot of the infotainment system navigation devices, there's Linux based underneath and already 10 years back we had the requirements that the system must not crash and it had to start in two seconds. It had to fulfill a lot of stability and it need to behave today as in 10 years because the car for example, runs for 10 years where you don't throw away your mobile, like your mobile phone and all these things which we have put into the Linux ecosystem for example, we also experience an hour devices.

If you go for an Android phone 10 years back, you had to switch it on, on and off maybe once a day or every other day. And uh, my mother recently asked me, when should I switch on and off my phone? Uh, is there a time where I should bring it up and said yes.

Whoa, when you feel that it doesn't behave us before and said, oh I wonder if you switch it on. I no clue. So I looked into it and it could go to the system saying like was something like 6,500 hours without a reboot for the phone, right?

Like that's a massive amount of time. Howand Android system which has Linux LAN needs, runs stable and all this service and, but this is not enough for safety, right? It's just that you need to add much more checks, much more robustness, freedom from interference, these kind of things and a lot of hours working on it.

And also testing. I would've said to your mother, if you feel like cursing at it, that's the time to reboot it. Right?

Are there different use cases for embedded linnux and all these different vertical industries that we discussed? Is there a common thread in their requirements or is the medical device and the car and the rocket fundamentally different? Yeah, so they, there are differences of cars if you talk about sensors, actuators, but they also share a lot of things.

It's the scheduling. Uh, some have maybe stronger realtime demand than other use cases. We address one use case which May not even need realtime patches in there and still has a safety responsibility.

But it's just that the safety doesn't need to come within a milliseconds or microsecond but a little longer. And, but what you can see for a lot of these use cases is it's often that something goes into a memory and you compare against another memory region and you have to fulfill this in a given amount of time. There's a little bit of oversimplification, but the tel you need to look into how caius are handled, how the memory works, the scheduling guaranteed and is there something which could cause interference?

An example would be, uh, if you think about graphics GPU and if there's a workload on GPU and an embedded device, it may heat up if you play a game on your phone, it's just getting hot and it may go then that the CPU uh, frequency scales down to get lower temperature is not giving full speed anymore. But maybe you had an assumption that I have a guaranteed frequency and that's also which my workload is scheduled on. So the time making sense.

And then you need some kind of watch doc scheduling observation of the system and these kind of things you need to think about. And this is similar from me, from medical devices, aerospace, wherever you go industry you need to have guaranteed timings for your workloads and you need to make sure that the memory is consistent. Because if you cannot trust the memory, you don't know what's going on.

So will people take um, an instance of a Linux that an embedded straight from you guys or are they gonna take the core of it and then customize it and extend it for their use case per se, but then at least they're reducing the total cost of building something because there are those common functionalities? Exactly. And basically they need to do the same thing as we do.

And we also just, we don't provide a safe Linux. This is support the, these is enabling Linux and safety applications. So we look what are tools, what do we have to improve in documentation?

We, we recently figured out that tracing workloads in your system is a crucial element. And for this, uh, there was an upstream in six to three kernel how to do workloads tracing. We see scope and have trace are so that you just see, okay, here are elements in there, this is subsystem which are important.

And if you build your system, you can use this tracing to understand how your system operates. And this can also benefit not only security, uh, safety, it can also be benefit for security or other critical workloads which you run. So this is something which we bring in and where you then get a benefit later on.

Are you looking at security as part of this Exercise? Yeah, we, we always touch point with security. We don't put a focus on it because there's so many security rated projects out there.

But uh, for example looked and trusted execution environment and hardware acceleration for security because security mechanisms which reduce the rights which you have in a system will also benefit in a safety system because you need to make sure that your workload gets isolated and made a difference. Which you have if you say my system is secure, you may look into your little small bubble of it and say my bubble is secure, I protect what's inside. It's much treasure.

Mm-hmm But this is something which doesn't hold true for safety because it could be another system which just how's get impacting, not directly but indirectly as I mentioned like with CPU load or temperature reason or uh, a share resource which is not really going into the worker but you say the same interface and this is where differences come in. But security mechanisms definitely help. Also secure boot to make sure that your system is robust and in a defined state.

And here we use a lot of these security mechanisms as well. Name spaces, C groups will also be something which can be utilized in a safety related system. And we have actually a working group on this which concentrates on Linux features which may benefit in a safety argumentation and they also use mentorship programs from the Linux Foundation, have a mentee, which then also maybe takes more bit more the security side and see how other security apply to safety work.

Right. And what level of skill does someone have to have to build these types of applications? Cuz it seems like, you know, unlike say working in the cloud where I've got some, you know, infinite amount of capacity and amount can be a little bit sloppy feels like in this environment I gotta be really precise.

Yeah. So it's even going that far in the traditional field of uh, safety products, you will not have dynamic memory allocation so you know before which memory amount you will need. And you do aesthetically assign this during the boot up so that there's no swap needed, no dynamic memory allocation at all.

So you need to have a very good system understanding on how the hardware works. We have hardware experts from an invalid field, you need to have Linux understanding or operating system understanding how to control us work, how to, how do my system overall operate. And then this will not help you if you don't get all these safety aspects.

And as well they will ask what the risk, what could go wrong, where are harms, what are the interfaces? And interface does not only mean the interface between two functions or so. It also means how a human interacts with the system so that you have a much wider analysis, analyze fault trees, what could go wrong, what could be a fault in the system.

So get all these kind of things in and I'm healthy that typically will not have one person who could build it. So you need very much size of a team to interact, to cooperate in this. And um, I see this quite often that people approach the laser project and say, so you will build a safe Linux.

I want to build a safety related product, I want to use Linux for it. And then you figure out the people don't bring a strong Linux background, they don't bring a strong safety background and they believe they can get something and we decide that we are not delivering a safety Linux just enabling Linux and safety application. This also means even if a company would provide you with a safe Linux and they are like, uh, sus Red Hat canonical, they all work on this past ours functional safety.

Linux nice to meet you even if you buy it from them. They need to have a sufficient understanding of the system of what it's in there. But uh, but here opensource is a great enabler because we have such a huge amount of experts in there and you have the chance to learn it.

When you take traditional safety operating system, they are often delivered as binaries. So you have no chance to look into it and you need to, you just get the manual and then you need to trust on the behavior which you experience and here you get the chance to really see into and it's related project like Sapphire. Oren also provides, they have a open source coat base, they have a strong community with people contributing to it with various expertise.

And this gives a large strengths, which she may not see in traditional Commercial. You may, you may get surprised in a space where no surprises are kind of crucial. Yeah, right.

That's, but also when you see no players, new players coming in, suddenly they may talk and say, imagine you want to update something and you want to update your break. And that's what I say. I do not want to update my break in the, in the system.

And if I'm in a car, I want to have a functional break at, at the time when it's released it should be safe. It has to be safe because it's the human life threat. If it, my break doesn't work.

But of course if you see connected devices, iot and some the area where we're working, suddenly everything gets connected. You may want to get an update or a new function in your system. It, it could mean that it's not an update for the brake, but it could be a new driving assistance function because the sensors are in there and then it's something where suddenly Linux gets a strong benefit.

And for you have, because there you have a chance of having open source, having update ability. But this is also a challenge which just goes in, Does someone or some entity need to certify these implementations or, and is that a niche vertical industry or is there some way to approach that? So Uh, you need to, you need to certify whenever you build this and you go with certification authorities, you take a choice of the safety integrity standard, which you would like to apply it.

So when the ISO 2 62 62 is this standard for the automotive, you can also argue that you take an IC 6 50 0 8 standard, which is just the upper like say the mother standard of it. You need to convince the authorities that you do the proper thing and the standards help you. It's basically showing you state ofthe art development.

And this is very complex because they say, oh, do you bring a safety culture? Do you have follow the process and so on. This is all in there.

This makes it complicated for using Linux in there, but also if you just do your component development on top, but you have more control if you are in your company and build it in there. And this may also give a benefit for these strong people like just mentioned like canonical Suzy and redhead. They bring a strong background in processes.

They have this, they have industry support or they the indu industrial branches of Linux. And by this they can much easier and enable than maybe a new player, a new kid on the block, which just starts want to develop it. Then I would recommend just better go a little bit smaller.

Don't try too much on it. Right. Don't boil the ocean.

Yeah. So what exactly do you guys need from the people who are watching this? Do you need more contributors?

Do you need more companies to participate? What are you Looking for? What we, we were really looking for were industrial area because we currently see that due to the RT patches going into Linux, there are industrial automation people who ask for Linux and they also have safety standards involved others one which we then we addressed.

So it would be very nice to get some more, uh, visibility also in this industry because it will help us, it gives us a different track and it's what we see. We got a good safety background, but bringing this on the ground, so we, we started with a qm, more emulation. So it's a virtual machine because this was easy to scale, to scale to share, but to bring it to hardware also requires a lot of embedded engineers, kernel engineers.

And we would like to love to get more kernel embedded developers involved where we can help and train them also on what is important for safety. Because we did a lot of these and all of those parts, we've got a good understanding. But to show it more in the, here is the single board computer and you can just see the workload in there.

And we go out having a booth like others on a, on a conference. We were hesitating because we wanted to show more. And for this, my contribution is good.

Also automotive industry, um, driving forces, no going into driver systems systems, right. And we by intention decided for another use case in the beginning we were using the warning signs, which you know, from your car to gear indicator, the check engine or check oil part, they are good because it's easy to explain less sensors, less actuators. But that's not the fancy thing that people want to see, right?

You want to see driving assistance and you, it's something you can sell with marketing ish. You can go out and for this, you would love to see if there's an automotive OEM maybe who comes in and say, I have my use case and I'm willing to openly share ideas, I will do my development maybe in-house, but I share with you concept and maybe even something which is 10 years old because we have driving a system which is 10, 15 years old and they just say that's how we did our analysis, that's how we did the work. And then combined with embedded engineers, we can say, let's try to bring this on Linux and argue why this can be sufficiently be safe in this use cases.

So here, community support, especially from embedded developers, drone engineers, they would be helpful. So everybody wants to be with the cool kids and then kind of focus on Kubernetes or the mainstream Lennox project. So how do we make safety sexy and get people like say, hey, this is the place to be.

I guess where, Where it comes in a little bit is that people talk about the software defined vehicle, uh, and many different, some call it like the smartphone on wheels. As I say it's subscription for your seat heating. But uh, here suddenly also cloud technology comes into picture where you go for digital twins and this is something very good, but I see as a benefit that's not as sexy as the other topic.

That's, it's like you don't, you cannot uh, run fast and fail and just start over because you do need to do it right. But you will get a very good understanding on the software engineering process. You will write better software by it.

You will get a good understanding on things and let you rethink how you do code. And I guess it's a benefit to all industry and it's can even increase kernel stability, reliability, robustness. And you will, I guess it's more the field who really would like to touch something in hardware where they say, I would like to learn a lot.

And there Linux is much nicer. Also other open source projects as many like exact because you can try things out. You can see when you do something suddenly it starts blinking.

You can push a button and something happens and these are the things which are hardly to grab in the virtual space. You see something, it's rendering there. But I get to know this, we were running with Chimo, we had Weems on a pc.

If I go somewhere demonstrated in the industry, they say yes, nice, but how is this a product? We will make a device which runs in millions of cars and or we established from the last generation, the Bosch infotainment, I can say the Linux system, which we made up, ended up in 30 million devices on the road for navigation. And this is something which you can see, you can see and point to something if you go to the cloud, it's like, here's this web store, I did something around it or here's this other part.

But if you build these embedded devices, you can say look like, uh, Chuck Warr was presenting yesterday on the boring part. How they using say, see whenever I enter a Boeing plane, I know something in this plane is there from me, my side. And that's something which is really nice to see.

So that is more impressive I see than something the local. Yeah. All right folks, if you wanna save lives, call Phillip cuz he needs some help and that's a really cool job at the end of the day.

Phillip, thanks for coming by. Yep, thanks a lot. All right.

And we'll be back in a minute. Hello everyone. Here's some of our upcoming tech strong learning events first up on June 1st, join us at the virtual DevOps connect DevSecOps at RS a C 2023 event as we discuss the emergence of security engineers and DevOps.

And explore the role of developer security champions on July 11th. At our cloud native Now virtual event, we will explore the various facets of Cloud native that are essential for a successful digital transformation and enterprise modernization. We hope to see you at all these events.

com. This is techstrong tv. Hello and welcome back to the Open Source Summit in beautiful Vancouver, British Columbia.

We're talking about open source security. We have the new general manager for the Open Source Security Foundation, home Car, Raman NAPman. And then we have Brian Bellor, who is the CTO now, I guess.

Is that how we're gonna do this? All right. Awesome guys, welcome the show.

Thank you for having us. There's been a lot going on in this little foundation of yours that just got started not too long ago. We got a new gm, you got a bunch of projects updates, you got new members, so give us the highlights.

So under Brian's leadership, there's been some great progress over the last couple years. I'm really looking forward to working with the foundation, all of our members in the community with bringing better, more secure practices to our open source foundation and ensuring that we've got a way to help make our software a little more secure for the better of the, for the good of the public. Uh, Brian, did you want to cover some of the highlights under your leadership?

Well, First of all, let me say, you know, um, we've, we've been building an amazing team at the Open ssf, but I also realized, look, there's things I know really well. I've been part of the open source movement for 30 years. Really?

I I, and there's other things that I've not been a part of as much which is enterprise security, right. Uh, the lingo, the, the terminology, the history, uh, I've been a quick study and certainly as it applies to open source code, it's been, it's been a, a great, a great educational experience. But as we were building the team, I realized I really needed someone, uh, to work with me as a peer who really understood, uh, uh, the history of application security, knew how to talk to executives about risk management, knew how to build out infrastructure, uh, and where the open source code could fit into that.

And just as I've been a quick study on security Kar, certainly, no, no, no. Uh uh, no, no. Stranger to open source code as well.

He's been, who was a contributor to, um, power PC Debian, uh, 20 years ago. Gen two, gen two, I'm sorry. Gen two, uh, 20, uh, 20 years ago.

So like, basically this is a partnership that is really gonna be about executing on both the big plans that we have, uh, around securing open source software in the software supply chain, uh, at a, at a business level, working with our stakeholders, making an impact, you know, to boardrooms and the like, as well as on the ground, the technology, identifying the gaps, the missing pieces, and pulling all the tools together to come up with something that is cohesively an answer to addressing many of the security challenges in, in software. It takes a big person to realize that they've reached their level of incompetence. Is that where you're going with this?

Basically, actually three times in my career, I stumbled into starting a thing, or like being a part of, like, growing a thing and then been very great, very much understood. Like, you need to build it. It takes a village, right?

It takes a, a lot of people with different strengths, and I really wanted somebody in that background and also somebody to, to do the kinds of thing. You know, I, let me focus on tech, uh, let you know, focus on, uh, stakeholder man. He could focus on stakeholder management.

I could focus on kind of some of the nerdy thing, you know, frankly, like he could focus on the nerdy things too. And I'm certainly gonna also talk to the business types. So we're gonna figure out how this relationship works, but, um, I'm really excited to have, uh, as a, as a partner in this effort, uh, Omkar and, and, and, and move forward with that.

You've had some new companies join, I think SAP is one. Um, what is in it for a company to join this particular foundation? Why should they be looking at this in particular?

I mean, we all know it's an issue, but what motivates Them to actually want to contribute? There's a couple ways that we'd like to think about this. Um, the first is that security doesn't exist in isolation.

We can't hermetically seal a company and say, I am secure unto myself. And especially when we think about the prevalence of open source software, as it's used by industry today, if we don't collectively ban to address security concerns upstream, we're all gonna have to do hand-to-hand combat. Uh, the analog I'd used earlier today was want to get outta swatting mosquitoes.

And that's what it feels like a lot. We're trying to address some of these problems that aren't being properly addressed upstream due to capacity. As I think about our stakeholders, they fall into four different categories.

The folks that produce software are friends at Google and Microsoft, and a number of the other members of our board, the folks that consume software. You may do your own development, but you're relying on a technology company like our friends in the banks, or our friends in other industries. Then there's also the public sector.

So a large amount of addressing this comes from support and cooperation with governments, both in the us overseas in Europe, Canada, across the world. And last but not least, this is open source, our community, and being able to positively affect outcomes within the community. So when it comes to, to get back to your question, the benefit that companies get is being able to collaborate on really assisting with securing our software, our open source software for the greater public good.

And there's benefits abound. Brian, did you want to add anything? I, You know, it's been great to see the support of organizations like Google and Microsoft who came in, uh, not just they, they've been solid participants in so many of our projects, but they also recently came in with two and a half million dollars in support, further support for the Alpha Omega projects, which, uh, has gone from strength to strength.

And we can talk more about that in a bit. But I'm also really happy to see support from small and mid-size companies. I think of a company like C who are building tools, uh, to analyze and understand the software supply chain, small little startup that they're, uh, one of their, one of their technologists, Michael Lieberman, has been really active in defining the salsa specification.

Uh, and, and, and it really takes that whole, the whole spectrum of types of companies out there. We also have a tremendous number of end user organizations. Now.

We recently added Lockheed Martin, for example, as a member of the project, and having them in there participating and, and benefiting from it alongside banks, alongside other very traditional companies, really shows that this is more than just like a cloud problem or an infrastructure or, or a tools maker problem. But even really about the end users, the consumers of all this technology, they want secure software as well. And a lot of great ideas are coming out of that side of the ecosystem.

How have the maintainers been reacting to all of this? Because they're a diverse bunch of folks, and some of them might be, we don't need any help from anybody, we're good. And others may say that, you know, we'll take all the help we can get.

So it all depends what the spectrum is. But as you talk to folks, what are you hearing from them? Do you mean maintainers of the projects at the open sf?

No, the open, just open source software maintainers themselves. Well, The Linux Foundation, you know, regularly runs research and, and does polling of, of developers in particular. Uh, and we really want to understand who are those most critical open source developers and what drives them and, and the like.

And to a t every one of them says they wish they had more time from their employer to be able to work on open source code, to do not just the feature work, but also pay off the technical debt and the security work and all that kind of stuff. The second thing is they, that they say is they want the same kind of developer tools, uh, uh, that they, uh, when they work on open source code that they do when they work on their company's internal proprietary code, because that extra tooling gives them a degree of infrastructure and a degree of rigor and a degree of temporization, that makes it much easier and much more productive for them than the stuff they have to deal with in the open source side. So one of the things we've inculcated from that is the need to make sure that as we come up with tools for signing artifacts like SIG store and, and, and salsa, which is for tracking providence in the software supply chain, they're only successful to the degree that you can get them embedded inside the tool chains of the world and really uplift the open source tooling to, by default lead to better secure software and better more secure software as, as, as, as a product of using those tools.

So, uh, it was really great to see, for example, GitHub recently announced that they had taken these two pieces and some other things and woven them into support in the NPM package ecosystem for Providence traceability, uh, NPM dash providence, uh, uh, is now a flag. It's all opt-in. And so I'm really hoping that we can turn it to an opt out kind of default kind of mode so that the NPM ecosystem can be much more traceable from source code to final delivered product.

But that's a nice example, an illustration of where our, our members, having the right members in place working on the right technologies, but getting this into the tool systems can meet some of what the maintainers are asking for. And back to your original question, no one wants to lift a finger to do an extra amount of security work. What they want is the tools to do the work for them and for the ecosystem as a whole to bend towards more secure software as a result.

I think when you guys first started, you made a call for a, I think it was an estimated 150 million in funding or something like that. Is that enough? It seems like a small number compared to like the billions of dollars that we spend on software.

So We're always willing to get more, I think is the right way to begin that. But to be realistic about it, there's also a planning and execution headwind there. Well, not headwind, but overhead.

So with any amount of money in order to ensure, especially with donations from our generous board of directors and member companies, it's important to be judicious with how that's being allocated, how the progress is being tracked, and the impact that we're making. Not everything can be solved with money. Sometimes there's fundamental structural things that we need to agree on in terms of data formats, things like s bonds, that's not gonna be solved with a check.

So I agree that this is not going to be the last check that's cut in aid of securing software. However, we felt, and Brian, you were there at the time, so I'd love your input as well. But we felt that was a good start.

It was something that was manageable and it was something that we could allocate appropriately to the community in order to secure software for the greater public good. The, the mobilization plan, which is about a year old at this point, um, was devised at a time in kind of the aftermath of the log for j uh, log for Shell, uh, vulnerability at a time when government was looking out there going, well, who's actually gearing up to solve these problems that we've identified as root causes of, of that, of that, uh, the whole disruption? And they turned to us and they said, what are you all doing?

And we've got, you know, we said, we've got all these interesting projects and efforts. And they said, well, really, what does it take, what will it take to apply those to solving the problem? And so for us, that document, which we devised in our community in Rapid, like in basically a two week window with, uh, a whole bunch of experts convened really rapidly around 10 different streams, uh, was intended to represent at that moment in time a true north, right?

Here's where we could go, should the resources apply, here's the kind of impact we could have for what, by some measures, there's a lot of money. It's certainly more than I've ever had on my personal budget. Um, but in some ways is a drop in the bucket compared to the impact of even one of those vulnerabilities, like a log for shell.

So we would, we did that as a, as an example, like here's what's possible. It will be updated this year to represent a new set of true Norths, if you will, a new set of ways to take what we're already doing and apply it to those big problems and how they'll solve it, but also identify, here's some new things to start working on, such as where does artificial intelligence land in that plan, right? This year we should be talking about it, uh, 12 months ago we could be forgiven for not talking about it, right?

G p t hadn't shown up on the, on the, on the map. So, so it serves as basically that top-down map and that top-down kind of view of what's possible, but really all the substance and all the hard work comes bottoms up through the maintainers and through the folks working on standards and, and all those that, that have to come together to, to solve those problems. Now you mentioned the Alpha Omega project earlier, but I'm not sure everybody knows exactly what that is.

So walk us through what that project is, what its scope is. Okay, Sure. So Alpha Omega was like many of the things that we started right when, uh, we got funding for, for, uh, for the Open ssf was based off of a white paper written by Michael Sveta at Microsoft that said, you know, there's these two interesting things we could really do to help, uh, raise the floor on how security is accomplished in the, in the open source landscape.

One of them is go and, and provide directed funding to the most important open source projects, and in some cases, foundations to help them get better at managing security across their foundations. Like the policies and the processes that the Python Foundation or the Rust Foundation or Eclipse or many of these other kinds of orgs could use. A, could use an uplift, right?

It could use somebody helping them get over a hump to be able to demonstrate the value of this work, and then hopefully go back to their own stakeholders and say, now that we've got these engines running, let's continue to get that work, uh, funded as a, as a core part of that project, right? So intended to help boost bootstrap, uh, a lot of stuff that had not been done internally by some open source projects. And so we've been very successful at that front.

We've distributed over three and a half million dollars so far in grants to six different organizations. We have stuff that we've approved and not yet announced that we'll be getting the word out very soon. Um, that'll address memory safety in a number of other ways, but it's about capacity building and just changing a bit of the culture in these important projects.

The second thing Alpha Omega does is we're set standing up infrastructure to go and scan for vulnerabilities in the top. Currently the target is 10,000, but we're looking at expanding that even more widely, the top 10,000 open source projects to go and look for the kinds of vulnerabilities you'll find in a whole lot of them, like really simple kinds of bugs that we know we fi if we go and scratch that, that surface, we will find that in a lot of places, go proactively find them and submit poll requests to try to, in an automated fashion, get those fixed, uh, by thousands of projects at a time, right? So that is an ambitious goal.

It's based off of some research done by somebody we hired named, uh, Michael Lek, uh, to, uh, uh, Jonathan Leu, sorry, uh, to go and automate these processes. We're really excited about it, and I think that'll help, again, raise the floor on security for, uh, the most important open source project because There's a lot of common mistakes that everybody makes, and there are, there you go. Do we need a SWAT team to just go handle all these issues when the zero day vulnerability shows up and is there's, you know, can, can I just call you up and say, you know, Batman, come fix this.

You can, I'm not sure I'm gonna be very helpful though. Jokes aside, uh, the efforts that we've had thus far have been more around securing the software by construction. So coming up with methods of addressing in large swats of open source, some of these common missteps that we've seen developers make unintentionally be they memory safety issues off by one issues, whatever they may be.

I think eventually, as we get our arms around that, there's certainly the opportunity, and I think it's something contemplated in the mobilization plan as well as to how we do come up with, in a product company. We would call them a P cert team that's focused on product security. And to take perhaps a, an example from the not so recent past with the colonel, you know, how something like Spectrum Meltdown was addressed, how the right people were assembled in order to address this, both from the hardware community, the kernel community, the providers themselves, in order to ensure that there was an appropriate response, but also that confidentiality was maintained as we went through this due the severity of the issue.

So I, I'd like to get there, Brian, maybe you can speak to some of the thoughts around that. Uh, part of me joining, Well, you know, there's lots of different kinds of open source projects out there. Some of them have emergency response teams and security teams that are reasonably well advised and resourced when there's a bug in the Linux kernel that requires us all to coordinate that gets done.

But so much of the long tail of open source projects have never been through a major vulnerability disclosure process, have never had to deal with the cbe, and they don't know who to turn to for help. Uh, even some of the foundations could use some help on this front. And so a, uh, an emergency response team, uh, coordination center, that is something that was anticipated in the mobilization plan.

We've started to put some plans, more concrete plans around that for what it would take to coordinate, you know, basically a, a super friends kind of like, you know, DC superheroes, kind of like, kind of like collection. Now you've gotta be careful about how you set those up, and you've gotta have the right kind of volunteers in there. And, but, but doing it right, it's not gonna take a lot of money.

It's gonna take a bit, but not a lot of money to go and get a tremendous amount of impact, uh, in, in reducing the, the kind of like chaos that can come from uncoordinated vulnerability disclosure. Do we fundamentally to address all this, just need everybody to rewrite everything in rust or some other memory safe language, or what's the deal? I wish it was that simple.

Um, we should start there, but I wish it was that simple. Personally, as a, I identify as a software engineer that's been doing security for 20 years, and the way that I like to think about it is we need to ensure that our design patterns, our tools, our languages secure by default. I don't want to have to spend extra calories or cognitive overhead in order to think about making a thing secure, should just be secure.

And one example I've used in the past, there was this anecdote about a factory that was producing a particular part of an automobile. They ran into a quality control issue where a part was being put in, in the wrong orientation. So they added a QC engineer, and then they added another one and another one and another one, and eventually they plateaued in terms of the quality that they were able to achieve through that method.

But when they retooled the part, so it could only fit in, in the correct orientation, that was how they fixed the problem. I think applying that similar thinking to how we're addressing security rather than trying to QC stuff in alone or trying to incident respond to things alone, if we can just make it secure by construction and design, he said simply, we avoid so many of these things in a very efficient way, and by that we really increase the security guarantees that we can provide the public, right? Yeah.

I, uh, um, I hear a lot of the advocacy for, for memory safe languages really ranks the, the CNC plus plus folks out there who are like, you know, or, but, uh, but, you know, go and rest and, and even Java as a memory safe language, right? Uh, are, are actually pretty compelling for eliminating a whole category of vulnerabilities. But look, log for J was written in Java, right?

And it wasn't a memory issue so much as it was about parsing user, user contributed input for format. Oh, format Screen. So like there are bugs of all sort.

Uh, there's, uh, it's been great to see the White House surprisingly prioritize memory safe languages in its cybersecurity strategy as a potential approach to eliminating whole categories of vulnerabilities and that, and we think for a lot of the, you know, baseline libraries that are out there, like Russell's, which is a alternative to open SSL and is gaining a lot more functionality, and eventually it'll be kind of a drop in replacement for open SSL is a really promising area of direction, uh, area of focus. Uh, the Proximo project is looking at memory safe replacements for NTP D and these other forgotten, but still essential components to, uh, the, the how the internet works, right? If something goes wrong there, we run out of sync on time and, and bad things happen that are hard to predict.

Um, uh, so like, there are these interesting targets. I don't think we're ever gonna rewrite everything in rust. We can barely rewrite all the jo all the cobalt code that we have into something more modern, right?

So I don't think that's essential, nor is it, is it sufficient? Um, I, we've gotta be thinking about process, we've gotta be thinking about scanning. We've gotta be thinking about how do we make sure every line of code has more than one person responsible for it and looking at it, right?

All these different factors need to come together in the tooling and in dashboards so that we can go, aha, there is something that's read down in that corner that's under-resourced, it's critical to everything. Maybe we should get a third party audit for it and take it from yellow, from red to yellow, so that our whole risk comes down. And that's, that's where I think it's a, it, there's a really holistic picture around what we've gotta do, of which memory safe languages are certainly helpful by just a piece.

Will AI save us from ourselves? Because, you know, I can now discover the vulnerability. I can then be showing, here's the line of code that you should fix, and then here's the actual fix, and all I gotta do is push the button and install it.

Is it gonna ever get that simple? I hope so. I don't think we're there just yet.

I don't think we're there just yet. And I think similar to how in the very early days we were learning how to develop code that would scale well and be secure on the internet. We're in the very early days of generative ai.

And I hope we get to the point that it's that simple and that we can really leverage leverages large language models in order to automate some of the toil that, or some of the long tail that we're addressing in Omega. I don't think we're there yet. Um, but I do hope that that's some, that's an opportunity that we can look at in the future.

I, I think, I think there's an opportunity for, for it on the defensive side, but I am very worried about new kinds of attacks that AI can enable. So much of what we do in the open source world still depends upon trust between individuals, trust, you know, built at conferences like this trust built over Zoom calls with other maintainers. If, you know, large language models make it possible to have fake developers, uh, you know, inserting themselves into your community or otherwise, you know, like a lot of, a lot of the burden of being an open source maintainer is in bug triage.

You know, if you wanted to flood a project with a lot of fake bug reports that you generate through, I mean, there's a lot of like dark, dark directions that this stuff could take. And so, or if I could, if I could be the, uh, slightly tinfoil hat wearing security guy for a moment, what if you poison the model and you start spitting out code that's got a bunch of memory safety issues, right? It's, we used to call that the watering home attack, but it's, it would be the perfect factor, right?

Yeah. So what type of people are you looking for to help volunteer for this foundation? Is it security people?

Do you need developers, um, kids that could contribute, or is it gotta be somebody who works for Google? What's the spectrum of folks that you're looking for? We've, we love support from all of our board member companies, and we've got great contributions for them, but the answer is everybody can contribute.

There's a number of different work groups from policy to best practices to tooling to anyone can contribute because it's truly democratized. Just because you don't know software engineering or just because you don't know policy doesn't preclude you from helping. We need hands, we need people that are interested.

This is a community effort, like all open source efforts, and we would love anybody to help come, contribute, come learn. Education's a huge work stream as well. And I think that really allows anybody that has the desire to help us be more secure for the public, good to contribute.

But Brian, what are any hotspots? The only thing I'll add is, you know, my first message to folks would be, if you're not already familiar with what we offer, come to the website. But also if you're a developer of any sort, even if it's like visual basic macros, you know, like come and take the, uh, secure software development fundamentals course.

This is not super advanced. This is something that anybody writing code should take that would help them avoid, uh, common mistakes that tend to lead to vulnerabilities, like trusting user contributed input. Um, and or, or at least you know, for format strings, right?

Like, like, here are the patterns that you can learn to avoid even writing that stuff in the first place. Uh, there's other one page sides to this and that, how to be a better consumer of open source code. There's things that, that we think can speak to people at any level, uh, uh, and if they start with that, uh, and if 1% of those people who benefit from them find a bug, uh, find a way, could be improved, come in and engage in a conversation or have an idea for something they've built, or their company is built that wants to come in, that's golden for me.

But it has to start with this like, intrinsic motivator of they've benefited from it, they're familiar with it, they've worked it into their company's practices. That's, that's the real milestone for us. Uh, so that's the, the, the door is open completely to anybody to, to do that.

At the end of the day, are we trying to retrofit a set of DevSecOps workflows into the development of open source software? And we're really asking people to retrain themselves or rethink how they build software. Because in my experience, most developers when they were trained, security was an elective and they never took it.

So, you know, how far back do we gotta go? I agree with you. It's not something that was historically taught or were there standard practices around how to address that.

But if we think back to the late nineties, early two thousands when the internet started taking off and we really started getting into some fundamental new patterns around distributed system design, and we started to write code in different ways and we started to adopt different patterns. I think that's the same kind of apex that we're at right now. So rather than simply continuing to do things the way we did in the past, resulting in even more instant response teams and even more Omega projects and things of that nature, this is what our education team seeks to solve with some of the courseware that Brian's referred to.

But this is also areas we're looking to partner with public sector with higher education to help get some of that to those students that are now learning how to build big, powerful distributed systems who haven't yet had their first job in industry. It's just like, I hope to make my children more secure by teaching them how to cross the street safely. I don't intend on being there every time they cross the street.

Nothing to add. That's great. What is the role of the government in all of this?

Because it seems like we're doing this within the industry. There's a lot of calls for more accountability, more liability. Some people are saying, you know, if you write a line in code, you have to own it for the rest of your life.

What's, what's the right balance here? Right? I think you got some point of views.

Well, yeah. So I do think, look, open source software has always, uh, benefited from actually the same thing the whole software industry has traditionally had in their end user agreements, which is, this code is used at your own risk. You know, if you lose a bunch of money because there is an error in your spreadsheet, you know, Microsoft's not liable and for, you know, just cuz you used Excel, right?

That's a basic principle that we've all kind of like taken for granted. Um, and open source licenses in particular say this is use at your own risk if you happen to use this at a nuclear power plant and cause an accident, you know, because there is a bug in it. It's not on, it's not on the open source developer.

And I think that's the right thing. But I want, I think actually society's response to the log for shell breach to, to the other things that have happened, the log for Shell vulnerability, other things that have happened in the last year have caused them to go, you know, know maybe the Silicon Valley, maybe the, the open source community can no longer, you know, move fast and break things. Maybe it needs to think about owning at least a little bit of the results of their work.

And so you do see very much in the European Union and their, in the regulatory moves that they're considering. And even in the White House cybersecurity policy, a bit of a hint that, you know, we need to look for potentially some of that liability being born by the parties that can bear it right by the publishers of code, or at least the companies that are reselling, reselling, uh, products or services based on this code. Now we think it would be really a bad idea to put that liability upon open source developers who are for the sake of publishing something to GitHub, you know, are making it available to the world.

Much as I would have an orange tree in my front yard and with a sign that says Free oranges, right? Uh, and if you happen to be allergic to oranges and got sick, I mean, like, where does the liability for that lie in Europe? It would be on me.

So we are gonna see a shift in this. Um, it does sound like though the regulators are realizing that there is a standard for due diligence that should be fairly low, should be fairly achievable, should be something that is, is something that developers could hit out of the box that would give them a little bit of an exemption from that liability. Uh, and so in the United States, the, the, what was in that cyber, the cybersecurity, uh, strategy, uh, was basically attaching that to the commercial transaction at the tail end.

If you're a red Hat, you'll, you know, there's a bit of that liability to be expected, but if you're somebody writing a thing that's included into Red Hat, you shouldn't bear any library for that in Europe. They do want to kind of make everybody like accountable and, and, and liable in that. So we'll see which way that goes.

And it could be a major clash in Europe between how the open source community works and how the regulators think that it's supposed to work. And we'll see what happens there. Um, my hope is that we come up with tools and, and processes and standards in the open ssf that to whatever degree these start to become more frequently asked for, uh, and, and things that open, properly run open source projects should do, just like we've done on the legal side, just like we've done with dcos and sla, uh, SLAs and things like that, that it becomes a thing that's achievable in a, in a very scalable kind of way.

Um, so that end users can be reassured that at least the due diligence has been done to try to provide secure software and maybe even make choices about what software they use based on that. The only thing that I would add to that would be just to, I think it's important to understand where the impetus comes from, and the impetus comes from scenarios in which we have things like iot devices that don't have any committed updates that are running vulnerable versions of software and have been used for things like distributed denial service attacks. So there's certainly a, we can't swing to either extreme.

There has to be homeostasis in the middle. And I look forward to working with both our private sector and public sector partners with finding where that homeostasis exists. So are we having something that feels like the equivalent of a Ralph Nader moment here, where we're unsafe at any speed and you know, are we building software too fast and we need to slow down?

Or is there another way to think about this? So in my opinion, I believe that none of this, none of this was done with malice or disregard. I think as we are evolving and as the discipline of software engineerings evolved, we're discovering things about how people use software and misuse software.

And we're trying to come up with the right patterns, techniques and tools to ensure that the misuse, the impact of the misuse is minimized and that the right path, the correct path for using the software is maintained. I don't think it's that extreme. I think we we're making incremental progress and we will continue to make incremental prog progress.

I don't think, I think, excuse me, we're past the days in which we could disregard whether a particular bit of software is using proper input sanitization or whether, uh, don't worry about memory safety, don't worry about counting how many bites are left in that buffer. We're past that and we need to be thoughtful about that if the software is going to perform at scale with the kind of surface area we have these days. The other thing I'll note in the nineties when I began working, there was a token ring network, there was a squid proxy and I had no direct access to the internet through my desktop.

PC Light bulbs now have IP addresses. So the surface area is fundamentally different now as well. Yeah, and nothing, nothing to add that.

Alright Gentlemen, thanks for coming by the show. It's great to have you guys. I think what we learned from all of this is that software hygiene matters, we need to start paying more attention to it because if you don't, your software might stink a little.

All right, Thanks so much. We'll be back in a minute. This is techstrong tv.

Welcome back to the Open Source summit. We're here with Gab Colombo from the Lennox Foundation, and we're talking about open source in the financial services sector in particular. There's a whole group dedicated to that particular venue, as they say, I guess, is it Fidelity now that just joined the group?

That was the news from today. All Right. So explain to us what the group does and why do we need a group specifically for the financial services sector?

Is this kind of like a double secret handshake group or what's the deal? Well, Um, we started FNAs actually about seven years ago now. Um, I was selected as the executive director then.

We were not part of the Linux Foundation. And you know, when we started, it was primarily driven by the goal of, uh, improving the talent pool in, in an industry that had certainly over the last 20 years as seen, uh, you know, a lot of the ma major talent move to big tech, moved to the west Coast, you know, historically Wall Street was a, a very sought after and still is to an extent. But, um, you know, developers nowadays, especially in the new generations, want to be able to continue foster, you know, their own personal profile as they, as they work for an organization.

And open source gives a great, you know, way to do so. And so, um, you know, we started six years ago. It started with talent.

It started with, you know, cost reduction, kind of the usual, uh, uh, sort of benefits that, that we all know in the opensource community opensource can bring to, to corporate. Um, over the years, uh, we realized that as a vertical foundation, we are bound to deliver business value throughout the whole value chain of financial service. So if you think about it, you know, most open source foundation are horizontal, are focused around the piece of technology that then gets, you know, applied to different verticals.

We actually cannot start the other way around. We start from business problems that are very specific to financial services. And we've helped this industry, uh, realize that not all they do is effectively competitive differentiator, actually, like in most other industries.

And have, we've seen the innovation that open source has brought over the last 20 years, I would argue that 70, 80% is non differentiating. And so, um, really we've helped over the last few years, uh, improving the interpretability of this, this, um, industry, growing the talent pool and also providing a much more sort of transparent way for, you know, historically very competitive and very conservative industries, you know, to, to collaborate in the open, which is way more effective when you think about idea like many other industries is undergoing, you know, the digital transformation. I mean, I don't love that word, but the reality is that open source is as much as cloud the pillar of any industry that is digitalizing, And it takes a while for those guys to come around and trust something.

I mean, you've been at this for now seven years. Seven years, and Fidelity is just getting on board. Yes.

So, uh, are there other organizations that you're trying to recruit for this? I mean, what do they look like and, you know, what makes them hesitant? It's interesting, uh, because, uh, it is really due to our vertical nature, uh, that we are seeing the foundation really expanding across the value chain in a way, follow the money.

Um, we started with our sort of key sponsorship and membership base coming from the largest investment banks in the world. Uh, so our 12 platinum members were really, you know, the Goldman Sachs, the JP Morgan, Morgan Stanley, cti, Deutsche Bank, you know, globally the largest investment banks. And now we are seeing more and more the, uh, if you follow, for example, the trade life cycle and, and who they collaborate and they transact with.

We're starting now to see a lot of buy side firms, so your typical asset managers, portfolio managers. Last year we added, uh, you know, point 72, which is a, uh, quant, uh, you know, high frequency trading, uh, organization. Um, Wellington now sits on our board.

And so Fidelity is a major addition for us because kind of going back to the previous comment on, on delivering business value, now we can use open source to really interconnect different parts of the industry. We have, you know, the sell side, the buy side. Earlier in the year we announced Discover, and, uh, that's our second car processor, uh, uh, beyond Amex.

So think about really following the whole, uh, uh, life cycle of a trade on one hand. And of course, increasingly we are looking at payments, commercial banking, and sort of the broader financial services. So when you think about which are the firms that, that we are continuing to engage, we continue to see a lot of, of growth potential on the buy side.

They have a lot to gain to really better interpret with their providers. Um, we are seeing more and more technology companies that of course are major providers to this industry. And this is certainly a very sought after industry, um, in terms of, you know, better, uh, uh, matching the needs of, of, uh, you know, a regulated and pretty unique industry.

So, you know, uh, Google joined us last year. We have, you know, uh, the likes of not just, uh, uh, commercial open source vendors, but really a lot of fintechs that are coming, coming to the table. So I expect that in the next, you know, one or two years we'll see pretty much all the cloud service providers joining as you know, uh, all of these, these folks are going through the cloud journey.

Uh, and more and more hopefully, you know, uh, I think FinTech as the FinTech open source foundation should be, uh, sort of the next big, uh, area for us of development. And FinTech is red hot and there's a lot of startup companies in that space, but you're also seem to be saying anybody who provides infrastructure that enables these applications can join as well. Absolutely.

Cloud, you know, cloud compliance, you know, uh, even from a regulatory standpoint, you know, they, uh, there's been in Europe and in the United States, major calls from the Department of Treasury, from the scc, uh, to regulate how these banks go to cloud to prevent cloud concentration risks. I mean, these are systemically important, uh, organizations. And of course, as we all know, this year has been a pretty complicated year for the sector.

Um, but what I'm really pleased to see is that instead of pulling back from open source, uh, they are doubling down in, you know, in times of, of higher sort of market pressure. Um, you are actually seeing these firms, again, doubling down on the understanding that open source can make them more efficient, more lean, more, you know, access to broader talent that, you know, over the last 10, 20 years has been sort of relegated to the West coast, if that makes sense. Um, so it's, uh, it's a very, very exciting time for, uh, for fitness.

Is there a correlation between any kind of downturn and their interest in open source? Do they kind of look at that and go, yeah, we need to save some bucks here? I think you are onto something that we had last year.

The, the fastest growth in terms of members. We added 18 members last year, some really, really cool logos. Um, I, you know, Jim likes to say our executive director, that that open source is counter cyclical.

Uh, because effectively to your point, when, when there is more pressure for efficiency, uh, as long as there is enough understanding and maturity of what open source can, can bring to the table, uh, firms tend to increase their investment. We've add in q1, our highest growth of contributors on record. We, we added, you know, 20% quarter on quarter, we added about 70% year on year.

So, um, you know, this, this level of open collaboration in financial services as much as, you know, 10 years ago it sounded like an oxymoron, uh, easier to stay. Do the people who are in this vertical, a lot of them compete with each other. So how do you establish that level of trust?

Cuz a lot of them are like, I don't wanna be sitting at the table, I don't wanna be seen with that other guy. It's, uh, it's a really, really good question. Um, so I think there's, there's multiple layers here.

The first layer is the baseline of policies that the Linux Foundation provides. As you can imagine, not only these firms are very competitive, but they're also highly regulated. And so even to sit at the table with a competitor or a customer, they need to have from their compliance department, very strong assurances that we have the right antitrust conflict of interest, uh, uh, and, you know, any other really policy that would raise any eyebrows.

And of course, you know, the Linux Foundation has now over 20 years of experiences in refining how competitors can collaborate. So that part, you know, it was hard at the beginning, but when we joined the transition in 2020, it became much more, you know, uh, established and, and, and understood. Um, the second level is, uh, culture.

Um, as you say, these folks not only are very competitive, uh, but they're also very risk averse in general. And so, you know, uh, what I realized over last years is that, of course, if you think about sort of the, the stakeholders that we engage with, uh, at developer level, we got their mind share developers be developers, uh, they want to collaborate with other developers, they want to solve problems that are bigger than what they can do within their firewall. So, uh, you know, they want to be, in a way liberated to be able to develop in the open, like very much any other industry a allow their developers to do.

Increasingly in the last three, four years, we've had the mind share of, of sea levels. Many of my folks, uh, in the board are CTOs or, or CIOs, whether they understand at the very level of detail what open source brings to the table. That is a process of course.

Um, but they, I do understand that open source has delivered basically every piece of innovation in the last 20 years. And so they understand the need of, of jumping onto this bandwagon, let's say. Um, the complex part is what I refer to as the frozen middle.

Uh, the, the, you know, this is a pretty large organization, pretty hierarchical, and of course, they are generally incentivized to be risk averse, to not take risk to continue executing, uh, you know, without getting in trouble. And so, you know, I would say that over the last few years we were able to, going back to that connection to business value through our strategic initiatives, being able to prove the value through quick wins, uh, and then bigger wins. And then, you know, disruptive wins.

Like, you know, open source disrupts and creates markets and commoditize competitors. Um, so I think we are, we are at the cusp of, of a, a pretty strong acceleration where even, uh, sort of the, the middle layers are starting to really understand what open source collaboration can bring to their day by day and to their individual careers, to be honest. Do you think that they're also finding it's easier to recruit developers if they have an open source profile or a commitment there?

Because after all, developers, you know, they want to hang with the cool kids, right? Absolutely. And I would say on two levels.

One, of course, they love to have the logo on our webpage, but that is just the beginning. You know, certainly being open source forward and, you know, one of our strategic initiatives really helping them to be what we call open source ready, you know, have a process, have technology, have policies to allow lic consumption in a safe and, and, you know, compliant way, but also contribution, you know, provision their developers to be able to collaborate and contribute to opensource projects from their very laptop. Until a few years ago, they had to take their personal laptop, go home and do it, you know, from their, their, uh, office or, or garage on the quiet.

Exactly. Mm-hmm. Um, uh, there is definitely one area where, especially with the new generations that are, I would say open source native, um, they really understand how, not just the logo, but a substantial engagement in open source is, is fundamental for talent.

The second bit is really from a technology perspective, meaning many of these organizations, uh, have built their own technology forever, including in the lower layers of the stack. Many of these organization have their own Java virtual machine. They have their own, uh, uh, Linux distribution, they have their own programming languages and, uh, you know, one name names.

But many of these organizations are understanding that, you know, why continue to build on a proprietary language where, for example, there is a Python ecosystem that, you know, every day gets thousands, hundreds of thousands of contributors and people building modules that actually will accelerate your business. And so I think, I think, you know, again, the, the process is irreversible at this point. They're really understanding that talent is gonna come through a process, and Then dozen people that created the original proprietary platform are now retired on a beach somewhere, right?

Exactly. Exactly. Cross pollination is really, we're seeing more and more execs and developers coming from the West coast, and that is certainly also reusing some barriers.

There's a lot of discussion about who's contributing to open source and who's not. Do you think that the financial services companies contribute more because they are organized in a group and they are kind of more cognizant of the issues, and so they are more likely to help out with a patch or do something for a project or a maintainer? Yeah, I mean, look, I, I want paint a, you know, just a happy picture here.

There's much more work, much more penetration that open source, uh, can have in financial services, and it's really about, you know, the maturity of the specific company. But, uh, you know, what I've seen over the last two years is that, especially as we joined the Linux Foundation and we brought all these, you know, very senior, uh, individuals and sort of, um, very highly relevant, uh, financial services organizations, uh, what I've seen is not just an increase in contributions into PHS projects, therefore, you know, almost self-serving, solving their own industry problems better. But we have seen an increased investment in upstream.

Um, for example, open ssf. I think it's a prime example. Uh, you know, uh, firms like Citi, JP Morgan, fidelity, uh, uh, Goldman Sachs, they all have invested and actively lead, uh, security and sustainability is, you Know, Honestly, financial institutions are one of, you know, probably only, probably only second to go lose the most mm-hmm.

Uh, from things like Locke for Shell. Um, so I, I would say to your point, yes, I, I think we are seeing, I wouldn't say that financial institutions are already open source leaders outside of Finos, where of course, they are the main contributors right now. Uh, but we are seeing, uh, again, a almost like a, a metamorphosis where some of these organizations are becoming much more akin to tech companies.

And as that happens, you're gonna see more and more contribution from these organizations. Do you think we'll see other vertical industries follow suit? I mean, can there be others in healthcare or wherever else where there's plenty of other segments?

Right, Absolutely. And, uh, shameless plug here, as you know, I also run UX Foundation Europe, and, uh, one of the, you know, early findings in the last seven months since we launched, uh, is really that vertical industry collaboration is a very high potential, especially in Europe, where of course, there's not as much, you know, big tech if you want as, as as here on the West Coast. Um, but there are already other vertical single foundation, and I expect many more to be a major driver of growth for Europe and hopefully globally.

Um, for example, LF Energy, it's a big Europe strong foundation in dlf, uh, really collaborating, bringing together, again, pretty conservative, generally state owned, uh, power providers. Um, we had, uh, a Linux Foundation healthcare, uh, um, I left public healthcare effort, uh, which was born, you know, in the wake of, of Covid trying to build, you know, uh, COVID apps and again, mutualize and understand that this is, you know, a bigger problem than any of the organizations could solve. Um, so I see a lot of potential, definitely much more in healthcare.

Again, very regulated industry. I argue that it's gonna take even longer than financial services for these folks. Um, you know, just in terms of the technology gap, uh, uh, uh, where they are.

Um, but I see a major potential for more vertical type collaborations. Um, again, primarily in Europe. That's what I'm biased, but I think on a global basis like phs.

All right, folks, you heard it here. When it comes to open source, we have nothing to fear, but fear itself. Hey, gab, thanks being on the Show.

Thank you so much. Thanks for having me. All right.

And we'll be back in a minute. This is techstrong tv. Hello everybody, and welcome back to the Open Source Summit.

We're in Vancouver, British Columbia, and we're with Cynthia Coup, and we're talking about software developed for diversity and inclusion, which she works on that project. So Cynthia, welcome to show. Thank you very much.

I feel like we've been talking about this stuff for a while now, and, uh, I would just ask you straight up, are we making progress and if so, why Aaron? If not, why not? That's a great question.

Uh, so far we haven't made much progress, to be honest. Um, we, this project, the S D D I project started in 2021, so it wasn't very long ago that we started looking at who we have in the tech industry. Um, by that I mean, you know, what percentage of men, what percentage of women, what ethnicities, what ages, and, uh, how about, uh, disabilities as well.

And so we collected a bunch of data in 2021 on that topic, and then Covid hit, uh, we didn't do a whole lot with it, of course, we kept on working with our best practices to get people employed and to try to diversify who we have in the tech force. Um, as we know, it's mostly men and mostly white men and have a certain age demographic as well. Um, Too many people who look like me, I know, like You.

Yeah, I, and a couple that look like me, but, you know, um, and so what we found when we looked at the numbers again, so then everything kind of went on hold. The S D D I project went on hold, and in 2023 we rebooted it. Well, late 2022.

So we recently looked at numbers again, and they were essentially the same. Um, so what we know is that, uh, whatever's been happening hasn't actually been working. So what we're trying to do with our project is say, well, what is working?

Like what have, what have industry companies, software, tech engineering been doing, and then what's not working and what is working, and then how can we create best practices from that, as well as bringing in people from other industries. Because if we're just looking at the tech industry, well, maybe we don't have the answers, but maybe other best practices and other research from other industries can give us more light on what it is that we need to be doing. This is part of a larger issue with how we teach math that goes back all the way to grammar school and the whole process that's involved in all of that.

What does it take to kind of unwind that? Because it's so ingrained in our culture and society that it's difficult for anybody to kind of break in at the high school level, the college level, or even later on. So is there some way to kind of think about this that, um, will enable us to achieve the goal?

Yeah, But you know, realizing that we're dealing with not just, you know, here's my policy for the day, it's Right. 30 years of ingrained behavior. It is absolutely.

I mean, everything, no systems exist alone, right? So the system we're working in, of course it goes back to School, society, family life, you know, anything. Um, in, so we have three s d d I has three working groups.

We have the neurodiversity working group, we have the diversity and inclusion working group, and then Talent Pipeline. And so the talent pipeline is actually kind of addressing this question. We're looking at what do we need to do to recruit farther backwards?

How do we change opinion and information based on, you know, uh, like how can we reach out to people essentially in schools or when they're first beginning to learn about different industries? Can we partner with teachers? Can we partner with universities?

Can we partner with, um, you know, even, uh, what's the word I'm looking for, like internships and get more people interested in what we're doing so that we can create a wider pool to begin with. That's one of the things that we're, we're looking at. We were in Dublin talking about this topic, and one of the things that came up was that, um, when people were reviewing code and they thought it was a male on the other side, they acted differently and they had different assumptions than they did if they knew the other person was female.

Mm-hmm. Do we need to have a more neutral approach to how we do code review and maybe DevOps and everything that goes with that, where maybe we don't know who the person on the other side of it is, because that would just give everybody a more even response. Right?

Absolutely. I mean, that's a fantastic question too. I think, you know, So much of what needs to be changed or what needs to be looked at differently is our own opinions, right?

We really do need to look at ourself and see what, what are we doing? What are we assuming, what assumptions are we making? How can we act differently so that we can have a different outcome?

And some of that might be, uh, making things less, uh, or more neutral, I guess, like you said, you know, um, and some of them might be really looking at what that means, right? Like, uh, with, with neurodiversity, neurodivergency, for example, um, autism, adhd, anxiety, dyslexia, uh, a lot of times we don't know if somebody is neurodivergent, right? It's not obvious by looking at them.

It's obvious by looking at somebody if they're, you know, maybe a particular ethnicity or maybe if they're a female or a male, but you don't know if somebody has autism just by looking at them. Um, and, and the person that has these characteristics might also not know that about themselves, right? So, so how do we create an environment that is inclusive of everybody without having to know that, right?

Kind of like how do you create the environment that, you know, is inclusive of the opinions of a person without them knowing who, who the other person is. So, like, neutralizing what we're looking at. That's a big question.

We live in a development world that prizes speed almost over any everything else, and that's not necessarily a good thing because we are encountering quality issues and security issues. So maybe if we had a more diverse set of minds looking at things, maybe the outcomes would be different. I don't know.

But seems to me like there are attributes of that are positive that people of different backgrounds bring the things. And maybe we should be thinking that through a little bit. Absolutely.

I mean, research is showing us that groups that are more diverse, whether that be, uh, that they have more gender diversity or more ethnic diversity or more, you know, neuro divergent brain diversity, that they are more productive and that the environments create happier people overall. And, uh, obviously more inclusive, but that it, it also changes the opinion of others, right? So like, when women are included in the workforce, positive, uh, outcomes for, for women and, and thoughts about, you know, women and what they're capable of happen.

When we see neurodiversity, neurodivergent workforces working with, uh, neurotypical work, you know, people all working together, uh, outcomes are showing that it's about 30% more productive than if you just had neurotypical. So, and obviously people of different, um, races and ethnicities as well have different, uh, ways of looking at things just because their cultural backgrounds are different, or maybe because how they grew up, what they learned about were different, you know? So, so together all of that, uh, creates a stronger work environment.

Have we created something that feels like a meritocracy that's based on attributes defined by white males? And maybe, you know, we need to actually reexamine what it is that we need software development teams to do in the first place? Absolutely.

I mean, you know, uh, in the world that we live in, we need as many people that are thinking in different ways as possible, and we need to take out that box that we've created by whoever created it, however it was created, and do something different. Because if we keep on doing the same thing over and over again, expecting different results, The part that I don't quite get is so we're all aware that we're short of skills and talent and people, and yet we're not really going out of our way to make it easier for more people to be part of the process or be included in the whole environment. And there's talents that, um, there may be somebody who has a family and they have children, and they can be great development team for certain hours of the day, but then they got other requirements and other things they gotta take care of.

There are other folks who are living halfway around the world that probably live in cultures that don't promote this kind of education, but if they're exposed to it, they could do all kinds of interesting things. Mm-hmm. So do we need to figure out a way to not, uh, be obsessed with, you know, we're gonna have a sprint nine to five east coast time, right?

And maybe we, and then that's part of why we're not getting more of this inclusion. Yeah, I, I agree with that wholeheartedly. I mean, I really think that, you know, something that Covid has taught the world, if we're willing to look at it, is that when people have a different kind of flexibility, they become more productive, right?

Mm-hmm. I mean, so what we saw in Covid, uh, in schools and in, in workforces was systems sort of falling apart because everybody had to stay home. But when, when we had to keep working or we had to keep going to school, we saw what people were capable of when they had an environment that they also had to fit into, right?

So, for example, maybe we weren't working nine to five anymore because the office was closed, but we were still, and we had the kids at home, but we were still able to create a really productive work environment when we were able to work from, I don't know, 12 to six, because that's what worked out for us. And maybe it was only three days a week, right? Mm-hmm.

So not that, not that we need to go into that kind of system exactly, but looking at what works for the individuals who are working and how can they, because we're all more productive if we're able to work under what's best for us, right? We are seeing a pushback against remote in general, though, because there are managers that wanna have those people around collectively, they feel that there's more, uh, collegial behavior leads to more innovation. Sure.

Um, but I don't know if that works out to be true or not. It seems to me maybe the managers need to adjust rather than forcing all the people back into a system that, as we've seen earlier, that metrics would suggest is not working so well. I agree.

I mean, I think the traditional management system works really well for traditional systems, and we are asking managers to shift a lot. I mean, a lot of the research that I, that I am aware of is like, I mean, if you think of a manager like a teacher, right? Teachers in the classroom are really being asked to do a lot more than they historically used to be asked to do.

Managers in the workforce are asked to be doing the same thing. Well, now you have to manage people that are remote. Now you have to manage people that come from different backgrounds than you.

Now you have to manage people that have different, you know, um, brain needs than you do, right? And so that's a lot to ask of a single manager. So maybe what we'd need to do is even step back and say, well, let's look at our management system.

Is there a different way that we can create a management system? Mm-hmm. Can, because there's a lot of really fantastic managers out there that might not be sensitive to how you work with somebody who's neuro divergent, but there might be somebody else in there that could be like a neuro divergent support manager that helps with that, or mm-hmm.

You know, creates more of an, you know, maybe there's a type of a manager that's better at managing people offsite, or maybe you just don't give all of the traditional rules to a manager because, you know, absolutely. If, if you're asking the structure of the workforce to change, then the structure of management also has to change. There are a lot of folks who are working in systems, they are women, minorities and whatever else, and they manage that and they do some interesting things to make that happen.

What's your advice to folks who are kind of working in those systems today? How do you help change them? How do you kinda become more of that agent for change in a way that is, uh, difficult?

Because it can be frustrating to no end. So, you know, how do you kind of, you know, get up for that game every day? Yeah, That's a great question, isn't it?

I mean, that's it. It comes so down to individuals. I mean, I think that the first one is we have to be willing, you know, we have to be willing to actually change.

We have to be willing to actually look at ourselves and to, to want change. We have to be willing to want something different. And then realize that what that means is changing and, and looking at ourselves too.

You know, what works for us? What doesn't work for us? How can we define ourselves in the way that we work best?

And then see that in our employees as well. So it's, you know, it's not like a, I don't see it as being a specific, you know, here's your rule book, here's, here's the things that you need to do. But it's, it's getting, uh, what's important to an individual and having them understand themselves so that they feel like they want to create an inclusive work environment.

Um, I, I think it's relationship building, really. Mm-hmm. I think a lot of it starts there.

Do you think we need to have a more open and honest dialogue about this thing? Because I think we're asking a lot of people to change who they are Yes. And how they operate mm-hmm.

To fitness system. Yep. And maybe, you know, the system needs to say, Hey, how do we make this work for the people?

Yeah. And then we'll get better results cuz happy people do better work in general. Uh, yeah, absolutely.

I think so. I think we do need to have, uh, you know, we need to change our culture of communication and dialogue and, and what that looks like, because, uh, it's too much for any one person to hold or to understand or have to do on their own, right? Mm-hmm.

So we, we do, we need to have some hard conversations, which hard conversations aren't, you know, meaning that anybody's wrong, but it's just like, let's really look at this and what can, what can we change? What is it that we need and how can we support people that we want to have in our workforces? Of course, there are folks who look like me, who have been working in that system for years, and they're comfortable.

In some ways it's a crutch because there allows them to kind of, you know, just do what they ever do and they heads down and they go, this is my thing. Mm-hmm. How do we get them comfortable with being uncomfortable?

Right? That is the ultimate question, isn't it? I mean, you know, profile.

I think some people are more willing to do that than others, right? So I don't think you're ever gonna capture everybody to be able to do that, but I think that it's done. Um, I think it's done in small ways, and I think it's done with finding the right, maybe the right coach or the right person to come in and actually start those conversations.

I mean, I've seen a lot of, um, industries change through, through repetitive and simple things like, uh, lean in circles where, you know, it's like a group of people that are coming together and they're talking about an issue, and then, you know, eventually they come together and they talk about that enough that like, like maybe you're not changing the manager, but maybe you're changing the culture around the manager, and then the manager understands that something needs to change and is, is willing to look at that in a different way, you know? And so I think it's just having, um, access to understanding and, and growth and having a growth mindset. I mean, uh, we're, we're not ever going to change everybody, but I think that it's just, it's just slow and over time and with the right supports in place, you know, It seems like we're also trying to strike a balance between, um, women, for example, in the workforce, don't want every conversation to be about them being a woman in DevOps.

Absolutely. They also want some recognition though, that there is this kind of, I don't want, I don't wanna call it the old boy school or whatever, but man, there's that vibe. Yeah, Absolutely.

So how do we strike that balance where, you know that every conversation, therefore doesn't become about whether or not you're an ex in DevOps, right? But it's about your knowledge and your skills, right. With some recognition that the system is flaw.

Yeah. Yep. Well, I mean, I do think as Nice to meet you, I think that the, the person also that's entering, so obviously, you know, maybe the, the men that are typically there have to make some changes.

But I think also whenever we as an individual who is a minority are going into a situation where we are a minority, uh, that's a brave position to be in. And we get to understand that we have to hold a different kind of space than we might if we were walking into a majority situation, right? Mm-hmm.

So some of it is just our, ourselves reminding the people who are listening, Hey, it doesn't need to be about that. It could be about this. You know, We're also seeing scenarios where more women and minorities are being promoted into these positions.

But, you know, there's always, you know, let's just face it, 15% of the population is stupid, at least. And, And, but they go to work and they add into some noise into that system. Mm-hmm.

Is it harder for women and minorities and other folks to become managers and deal with that scenario? Because it does exist, Right? I mean, statistically it looks like it's harder for that to happen because we don't see as many women and people who are minorities, uh, becoming managers or getting promoted.

Um, again, you know, the, the area that I work that I am most familiar with is the neurodivergent area. So looking at people who have autism or adhd and why are they not getting promoted and what is happening that's creating that kind of an environment. Um, I think some of it is just being, you know, unaware of the unknown or, um, un This is a bad idea, Unable, you know, it's like, it's just not, not enough training a lot of times and really understanding what that individual is like.

And so, you know, I mean, women, it's not just in the tech industry, it's, it's all over the place that historically this is what happens a lot of times when women are entering, uh, previously dom male dominated workforces, right? Like, it just takes time and patience. And I, I mean, it was a, you know, we can think of like Ruth Bader Ginsburg, right?

Wasn't she like the first or the second female to be in college to become a lawyer? And she had to work twice as hard and, you know, answer every question right? All the time in order to get any kind of recognition or even complete.

But now it's not really unusual for women to become lawyers, right? Like a lot of times there's more female lawyers in a class than there are males. So, uh, you know, over time and consistency, we can, we can make the changes.

It just takes, takes those first headliners to really do it for us. Do women and minorities need to do more for each other to help each other out up through the, up through that system? I think, you know, there's a sense that guys will, you know, they'll go have beers and they'll go play golf, and then they'll kinda lean on their buddy a little bit more.

Yeah. It's not clear to me that that same dynamic works out elsewhere. And maybe, you know, there needs to be a little more of that connection, man.

I think that what's really important is that we see each other's similarities more than our differences. And I think that what happens a lot of times, um, especially when it's something that's obvious, like let's say a woman, right? It's obvious that, you know, a woman looks different than a man.

So then you have, you're looking at what's dissimilar, so then you're going to see other things that are dissimilar. So what I see in workplaces, when individuals are willing to be vulnerable and talk about their own experience, or talk about even what their similarities are, or talk about what their challenges are, you know, I could take somebody who's neurodivergent, for example, and say, well, you know, I have autism, and what that looks like for me is I'm not going to make direct eye contact with you because it's difficult for me. Okay, now you understand something about me and you might change your judgment or your perception.

And so once you know that it humanizes me to you because I've told you something about myself that you'd had a previous judgment about. And so when I see workplaces that have those individuals who are willing to stand up and be a spokesperson or be a model, not only do other people come out and start saying, Hey, I'm like that too, or I understand what you mean, or Can I talk to you about this thing? And then there's more understanding.

You're changing the culture, and the same thing is true for women or other minorities as well. So that's, that's a lot of times what it takes. But it, it often starts with a special person.

You can't say you have to have a spokesperson. You're going to be it because you have autism, right? Or you're going to be it because you're female.

So creating a culture in a workforce where somebody feels comfortable doing that, and then more people feel comfortable doing that, that's where the change happens. We're just humanizing ourselves. And that's, that's really what it takes.

We're finding the similarities rather than the differences. Of course, HR teams are involved on a lot of this discussion, but it's not clear to me that that's an effective route. It just seems that that's more of a, you know, here's a mandate, but it, right, it's gotta happen at the grassroots level.

Absolutely. I mean, I think that it is really, of course, it's really important to have policies and procedures in place and to, you know, have guidelines and all of those structural things are important. We need to have those.

But, but what really changes the culture is having these conversations and what these conversations don't start by themselves generally. I mean, there are probably some really gifted managers out there who understand all of these differences and can support or change that. But that's, that's the kind of work I do.

I come in and I help companies, I help start these conversations so that the culture can change, because that is, that's where it changes. It changes on the one-on-one and the small levels, and then it grows from there. And then you have your structures in place, and then all those things make sense.

But there's no formula for changing the, the culture. You can't say this is what you need to do. What you need to do is you just need to start these conversations with somebody who under, you know, who can come in and be like, okay, well why don't we try this?

Why don't, why don't we finesse this thing? Why don't we, you know, because it's different for everybody. We're we're people.

We're dealing with people. We're talking about changing people. There's no formula for people.

There you go. All right. All you folks that go to work every day to help change the culture, thank you.

All those folks who don't open your hearts. So open your minds and don't be such, uh, you know what I mean? Hey Cynthia, thanks for coming by.

You're welcome. Thank you very much. All right.

And we'll be back in a minute. This is Techstrong tv. Hello and welcome back to the Open Source Summit in Vancouver.

We're here with FA Deci and Andrea Oli from the Continuous Delivery Foundation. I'm happy I didn't trip over all that. There's a lot of vows and things, but we're talking about a new report that these guys have put together and it really dives into the state of DevOps at its core.

On one level, I think the report finds 86% of folks who are involved in some level of DevOps processes. On the other end of it, it says maybe only 22% are going in to end. Yeah.

So what's your sense of the current state of the demos community? So thanks for hearing us, Mike. First of all, original state of city report is the report we published on a yearly basis when we have our, uh, event c dcon.

And this year's report is the 14th series, as you highlighted. The report says the, the OP adoption, the also adoption is on 86%, which makes us feel good. It is happening to organizations are now adopting DevOps principles and practices.

But I mean, look at some other findings in the reports such as if organizations are using contention or content theory. There are some interesting numbers there That transformation settling when it comes to this individual practice. But when we think about end to end view of this contention and content delivery, the adoption rate is pretty low actually.

Yeah. And like this may be explained based on different reasons such as DevOps transformations, not just about technology, but also organizational transformation, cultural transformation and perhaps change in product structure to be able to do DevOps. So I think we left some way to go to make sure the organizations actually increase their adoption to DevOps and they need to look into organizational aspects, cultural mindsets, aspects as well when it comes to jobs.

That's at least what we think when it comes to seeing those numbers and adoption rates. So we need to put some more effort into, you know, getting organizations on board with the IBM move forward with their efforts. So, and Andrea, I think when you guys started, you had four projects, the best known of course as Jenkins.

Yeah. Now you're up to nine I think. So when the goals that he just outlined in mind, how do you determine what projects you're gonna work on?

What are the relationships between these different projects? Give us the tour. Yeah, so, uh, that's a great question.

So we have a new project that joined in the foundation and we really look for a project that can contribute to the, uh, city, uh, um, ecosystem. So that can contribute in different, uh, phases of, uh, an entire continuous delivery starting from when the code is written to when it's, uh, published to artifacts and when to go into production and monitoring. So we look at the elf of the, the community, we look at the, how the community is active and engaging with, uh, with the rest of the, the, the CDF community.

Basically how, how much interest they have in engaging and bringing value to, to the discussion. Um, so we have, um, one of the new projects that we, uh, added to the city foundation, um, the school city events. And it's interest that you ask about, uh, how they collaborate between the project because in fact we, we have a, a problem, uh, in the, in the landscape that we want to solve that is about interoperability.

So we have a lot of project in the city, uh, landscape also beyond the what we have in the city foundation. Um, but there is a great need for interoperability. And one of the projects that we have is actually a standardization type of project is city events where we want to provide a common language, a common data model for all this tool to um, be able to interoperate with each other and also to be able to produce data and evidence for um, the people that are using for our end user using these projects, you know, to collect data consistently across their tool chain.

So to his point, the tool chain is fragmented and we need to do stuff to bring that together. So is it reasonable to expect that so many people would be doing end to end process in the first place? Cuz it's kind of hard to do that on your own and put all that stuff together.

So at the end of the day, is it a question of maturity on the demos teams or is it question of the tools we give them? I think both contribute to this. Like if we look at the ecosystem as Andrea mentioned, like in our landscape we have lot of ci cd technology system and other parts of the open source family.

There are loss of technologies and sometimes it is important to take a step back and look at what's happening within the ecosystem and then see who is doing something about a specific problem for example, and then join the force there. So instead of spin ourselves team, we can come together and collaborate on solving problems together, which in turn could help users, soft open source tools and technologies to actually look at tools that have larger communities with different ideas, different use cases. And then that in turn help organizations to be faster when it comes the opposite adoption.

Because like if the organization start with their DevOps continuously journey they to sort of tool and technology selections, if there are too many tools out there, then it may be difficult for those organizations to understand which tools serve their purpose better. Instead of asking or our users to know favor one or the other, we should actually combine our forces and bring the best part of different, you know, tools, put them together and give that to our users. I think, yeah, it goes both ways.

And the third aspect I think that is important to highlight where project committees we have end user committees. I think those end user organizations, committees, they should also join rfl so they can guide us to, you know, have solving their problems together rather than being pure consumers. They become part of our community and start contributing and becoming maintainers of the projects they're using internally.

Like is that an issue for us in this industry right now? It seems like we're reinventing multiple wheels by different projects and different companies and maybe we need to figure out collectively where are we going to contribute to open source and then what are we gonna compete on above that? Yeah, absolutely.

So that's something that it really come, comes out when we discuss, when we talk with the end users and every time we manage to get different end users of project in the same room and they started discussing and you see that they have, they're having the same kind of issues when they go at scales and they all have this developing their same kind of solution in house to solve those problems. So we different definitely are like really interested in getting this end users talking together more and you know, bringing this knowledge, uh, to the project so we can, you know, collaborate there and finding solutions rather than in-house. It does seem like every organization has written their own scripts, has a lot of manual processes and they're all tweaking the same thing, but they did it individually and maybe we could all have the end users contribute more of what they've done.

So maybe we need to hear more from the people who on the DevOps teams and say, Hey, not just the vendors, but what did you have to do to kind of extend this to make it work? Exactly. Like when we talk about Con Air Foundation, we highlight what kind of personas we have within our community as contributors.

Con Air Foundation has the practitioners from Andrew organizations. And that is a critical aspect. Cause if we can have those people taking part in common conversations as part of our special groups or under our projects, then those people actually could bring their experiences, bring their challenger to our project comments and then make those projects better with kind of like collective effort results on better things.

And that is something I think we discussed yesterday and we bumped into each other. Like I think we need to take a discussion around this, like what is happening, where we are at moment, how we came here and where are we going from here, what we can do to improve. I think that's pretty important conversation to have to, you know, set the future and how the things will evolve.

We need to put everybody in a room and lock the door. Right, exactly. Yeah.

Um, There's this debate going on, I'd love to get your opinion about it. Um, so we've had C I C D forever in a day, but most people are just doing the CI part, very few doing the cd and now the CD people are arguing about whether it's continuous deployment or continuous delivery. Should CI and CD be tightly coupled or loosely coupled or you know, what is the relationship between these two things going forward in your mind?

Yeah, I don't think they should be like tightly coupled. There's a lot of um, also knowledge and experience and specific to building artifacts and testing artifacts that you may have on the CI side and also in deployment in the city side. But I think, um, and different, different users, they have different requirements.

So some tools work better for them. So I think it's good in a way to have like different tools for different scenarios. But I think there needs to be like interoperability between these tools on one side and also reference architectures or like examples of how to combine them for solving specific scenarios to guide the users, uh, to guide like our DevOps practitioners that want to solve certain problems.

You know, how to combine the CI and city tools together. Continuing the philosophical debate. There's everybody walking around saying, oh, I'm a cloud native developer versus a monolithic developer.

Do I need different C I C D kind of platforms for each or can I use one for both? I think The main thing about the tools and technologies that debate when it comes to cic, the infras stress code, I think the organizations as open source companies, we should be using the tools that serves us best. Like if tool X works in both contexts, like monolith versus microservices, there shouldn't be, you know, big push move to at all because it's taught most about, I think that should be the guiding principle.

The tools shouldn't dictate us what we can achieve. We should tick and use the right tools based on what we need. And if one tool search the purpose, then it's good.

And I don't mean we shouldn't try to modernize our infrastructure. If the time comes, then obviously you need to go and look at what is the, what is the next generation tools and technologies that could help us to speed up, you know, delivering new products faster, fixing box faster. Of course that should be done, but I think it's case by case based and you know, up to the organizations.

And I, if I may add what Andre just said about contention, consider cause I have my own perception, like if we think about content interrogation, yes, it is pretty foundational thing and Aaron must be doing that these days. And even continuous delivery, what I think is like continuous delivery is a pretty slip to have continuous, sorry, continuous delegation is a prerequisite slip for continuous delivery. And continuous delivery is enabled of continuous deployment.

Again, they're not tightly coupled to each other, but they are pretty heavily late to each other. You can't actually continuously without conscious delegation. I think that is an important thing the organizations should think like if they are doing their transformations and if they are done the continuous delegation transformation next step, they should be taking that.

And that is going back to their first question, state of CD that highlights like organizations to CI but not playing cd. Maybe that is the thing they should be striving to move toward. There are some folks that say CD was never realistic because every platform was a snowflake anyway.

And it's only now with Kubernetes that we have some common API that we can write to. So is that gonna advance the conversation for adoption of cd? I know.

And is that kind of what GI ops is part of that conversation? How are all these things related in your mind? Yeah, I think there can be different approaches to CD and GIS is definitely a valid, very strong approach.

And there is effort in standardization around gis. Um, I don't think it's a panier for all for everyone. And so you can, I think to what I mean, there are different tools and it's, it's not only about specific tools or specific approaches.

They're tools that works better in different, in different context. Um, I really think it's um, but we should enable people to, to use those tools, uh, provide interoperability with between them, provide guidance, get the end users and we said, um, talking together so that we can bring the, the right features into the tools that, that they need. It's not a one size fits all kind of world.

Coner is common, no common thing regardless of the product structure, right? Deploy the industry. Like we have end users within City Foundation contributing to our projects from finance, telco, Webscale, and some of those, you know, products are going to our phones, some of them are going to radio based stations, some of them are going to, you know, point of sales and some of these things they will never be containerized.

And, and that requires us as the CD foundation to look at this important more broadly. It's not just cloud native gives us common, you know, API and standardization array, but what about the other things that are not contentized or that will never be contentized. So that is an important message we've been trying to pass.

Like if you are working with content delivery, we can have those conversations here. We, we are kind of agnostic, stick to type of thought. This is a common need for everyone.

Let's work together and if there are differences we address them as well as part of our road force. One of the big issues here at the show course is security. Where does that fit in the context of your foundation and um, you know, what do you think ultimately is gonna be required?

Do I need to make the existing projects more secure or do I need to add other projects or what's your thought? I think both and even more, like if you think about software supply chain, what goes through that software supply chain? You take open source packages, you put them into your products and then you do stuff with them and then you ship them to your customers.

And the backbone of that supply chain is actually your five mine, your production systems. It's pretty important to, you know, work with the continuous delivery both from practices perspective to secure that part. So you also supply chain becomes more secure and it comes to what should we be, we be working with, of course our projects must be secure as well, like Jenkins spin Tecton in addition, that our projects should provide their users to run their pipelines in a secure manner.

On top of that, we must make sure what's happening at any given time in our pipelines are also not possible to temper it and it's always observed and they are doing what they're supposed to. So what was those pipelines also don't, you know, cause transfer for our reserve. So I don't see supply chain and countries way to far function.

They're actually pretty closely related without one, the other one doesn't really become secure except You cannot walk down the street today without somebody jumping out and telling you about their great new AI thing. Where will AI fit in the whole DevOps workflow and you know, what's real and what's not or what's possible? Yeah.

Oh yeah, yeah, that, that's a great question. So I think, um, to the point Fati was mentioning, I mean it's important to collect data, you know, and know what's going on in in your pipeline. And we have more and more points in the pipeline in the workflow where we can emit data.

And that's one of the things also that we are really talking about in the context of the city events project. Like every, every tool producing data. And so when we collect all this data in an event storage, you start having a lot of data that you can use to take decisions based on policies or algorithm, but you can also start using this data to build data models and take AI driven decision eventually.

So, you know, take branches in your workflow, take decisions whether you want to promote a certain artifact farther in your pipeline based on, uh, AI or machine learning models. So I think that's, that's a good, great opportunity in that space. More research to come.

Um, what's your sense of, if I look at the world today, and we talked about multiple architectures, but there's code running up in the cloud all the way out to some flavor of a network edge and everything in between. Is the weight of this getting too heavy for us to sustain or you know, can we really handle where all the places we want to put all this software? Or do we even think about this?

I think like, this is really interesting topic because like I was having a conversation with one of our community members and like, okay, all this, you know, Cloud based environments, exercise and so on, the number of place, the number of target environments are exporting. And I think we also need to take a step back from continus now within the domain to think like pipelines, the traditional pipeline approach doesn't really scale. It help us, support us moving forward.

Maybe we should take a different look into how this ecosystem should evolve, how the contents theory practice should evolve. And I think one of the reasons Cary Foundation exists to actually looking into far future as well, not just working today's technologies, but look at emerging trends, look at upcoming challenges and try to find answers to some of these difficult questions. And your questions very difficult to answer.

But I think there are different things. Like for example, one of topics we discussed in the community is intent-based pipelines. Again, pipeline already is there because we don't know what else to use.

Like intent. Like what I want to, what is my intention that may relate to AI as well, okay, I want this container which to be built using this core base and should be deployed to this data center should be deployed to this edge. And I state my intention and the CD framework, whatever that thing is, is to do that.

It's without me needing to go and put really declarative instructions, it should be based on my intention. I want that product to be shipped there. You do that part based on what Right one to happen.

So it's kind of, I think that's why I like our community a lot. I mean there since the very early days and this type of conversations, if you're not part of the community, it's not possible to be part of those conversations. Even aware of those conversations.

But they are happening. Do we need to lighten up then on what we think of as DevOps? Because in some ways DevOps is like water, it just finds its own level inside an organization.

And maybe we shouldn't be beating up everybody about exactly how many processes and procedures they're using. They're using what makes sense for them. Exactly.

I think this is like tools selection. Like if you don't have to use all the tools available, you use what you need to use. You don't have to maybe stick to the book, follow the book one by one.

You just take ones based on where you are and you build from there. No, it's good. Like ambitions and so on.

But sometimes it might, you know, slow things down cause you might feel, oh, we are not doing this right. No, you are doing it. You've already started.

Just take your time and move based on your means and your pace. Pull a couple of chapters from different books and build your own, right. Yeah, yeah.

Um, one of the issues that does come up in this complex world is when we talk about continuous deployment all the time, but a lot of the folks I talk to say, you know, the only thing harder than deploying software is rolling it back. Can we make any easier to roll it back? Yeah, yeah.

I mean we can, I mean there is, um, a lot of automation and there are interesting, uh, projects happening in, uh, in this, in the space and basically to, to react, uh, to issues in production that you might have in production to detect what, what it might, um, have went wrong. But I think it's, uh, to enable this automation, again, the important thing is to have the data and to send the right signal. So to have all the data about, um, a release that was made, a deployment that happened, a configuration that was changed, a certain metric, a certain test that you execute to validate your services that are failing.

And so with all this data you can basically take, um, automatic decision about solving this kind of issues and having like remediations that won't take, uh, won't need even human intervention. So they could happen in, in the matter of, uh, of uh, yeah. Seconds or minutes.

So what's on your wishlist for here? I mean, you've got the report ad you're kind of still early days in the whole foundation. What's next up on the list?

Yeah, The first two years of the foundation was covid. You know, they shouldn't talk about it anymore, but we have to in CDF context. So we are four years old.

I think Monday we made out of announcements. Like our projects are doing lot of great stuff like cd, France is one of them. Tech is the other.

And Tel is another project we have. I think this like we are on this up force trajectory, I think, and I hope we will impact people's lives positively. Like when you ask this question, I mean I ask like impacting people's lives positively.

What is the relation between 20 zero and people's lives? Like if you can't have, There's no world peace in there too, well Hunger and, but if you think like we're all humans, open source is a big family and we are all, you know, fighting for the greater good and if something we do within our community, perhaps someone somewhere, then that makes me personally happy. Cause I know that is used by someone and that person appreciates that.

I don't know that, but it's happening. I think the community, our community and other open source communities, if you could continue on this path and ate them closely, then it'll make everyone's lives better, our lives better, our teammate's lives better. Whoever is using the software that flows through these pipelines, their lives should be better.

So that is like, again, maybe wishful thinking, but Hopes springs eternal. What's your best advice to folks who are watching this and what's that one thing you see people doing in the land of DevOps that kind of just makes you shake your head and go, Hey, I think we could be better than that. Hmm.

Well, I think, I think one, one thing that I would recommend, if you're doing changes to your DevOps setup, don't do it. Don't do it. Do them for the sake of it.

So, you know, measure what you're doing, you know, talk to the people and see where changes needed and do changes in the direction to improve. You know, like the environment for the people and the results that you can measure. So that would be my recommendation.

All right folks, you're heard in here. I think there's an old saying about measure twice cut once still applies to software as well. Guys, thanks for being on the ship.

Thank you very much for Hearing us. Thank you. Thank you so much.

We'll be back tomorrow. We'll be back tomorrow. This is our last interview for the day.

And we hope to see you all again in 24 hours. Hiring great DevOps and cyber talent is a huge challenge for technical teams. Cloud transformation is driving demand higher.

You've tried doing it yourself job boards, LinkedIn didn't work. Recruiters are an option. But who do you trust and not waste your time and money?

com, security Boulevard, container Journal and more. We sit right in the middle of the hottest positions in dev sec and ops and the brightest minds in the field. If you are looking for a great position or the talent to fill it, we can help you.

Trust us risk free. This Is Techstrong tv. Hi everybody.

Mike Rothman here, general Manager of Techstrong Research for another Techstrong TV interview. Uh, I am joined today by IT Alva. Hopefully I got that right.

I didn't butcher too much good stuff. Uh, company called Intro Security and uh, they're into the secrets business, right? And, and I think that's actually a very important, you know, thing to dig into because it's one of these kind of behind the scenes capabilities and really requirements, uh, that you don't really know, you haven't done well with until your stuff is all over the place and you have no idea, you know, who has access to what and, and, and what kind of API keys and, and, and database credentials and, and all sorts of other machine to machine and application oriented, uh, types of, of credentials and, and secrets are, are kind of out there and, and really unmanageable at this point.

So that's what Intro is, is focused on. But don't let me tell its story. He can tell it himself.

So it's a welcome to the show. Great to see you. Uh, why don't you just introduce yourself a little bit and tell us, uh, about Intro and, you know, again, kind of correct all the stuff that I'm sure I screwed up.

No, you got it. You got it. Correct.

Uh, thanks Mike for having me. And, and yeah, I'm, it kba, the co-founder of Enter Security. I spent the last two years building enter security.

Uh, and today we are the first and only end-to-end Secret Security. Uh, we are helping CISOs and security teams to claim control over their secrets and also helping organization at the point they have hundreds or thousands of secrets, uh, to secure them. Uh, I actually started my career as a software engineer at one of the intelligence units, uh, of the idf.

Uh, after that I was a cso, I was responsible for the security and the DevOps under Microsoft Defender Azure. Um, and now I'm the co-founder, uh, n c O of, uh, of security. And I've seen how secrets are the building blocks of any application and cloud applications and the power that secretive, um, and how they are being created and then without any security oversight.

That's right. And, and, and let's kind of dig in cuz I'm, I, you know, some folks may not be as familiar with kind of the integral role that secrets play in, uh, a lot of these new modern applications, right? So, you know, in the old days everything was, you know, kind of big and monolithic and, and we had, you know, kind of R P C and, and other mechanisms to communicate between all these different application components.

But as we've, you know, really kind of broken up and, and, uh, you know, kind of disintermediated a lot of these different application components as we've embraced microservices, right? You know, kind of a lot of, and, and paths and, and a lot of cloud aspects, right? You know, we're not building these monolithic applications.

What we're doing is assembling a whole mess of different components. And all of those components really communicate via APIs. And in order to know that the component is, you know, both what they say it is, and that's the authentication piece of it, as well as the authorization piece of it, meaning you can actually do this stuff, uh, within the context of that application is all driven by secrets, right?

So within that context, you, you know, you understand secrets can be, you know, pretty important, uh, underlying, again, foundational aspect of that. So, you know, when you're working with some of these customers, I mean, do they even have any idea where a lot of their secrets are, uh, from that standpoint? Or are they just kinda like, well, I don't know.

Right? You know, and then, uh, when they have some kind of issue, they realize that they have a secret problem. So, so what tends to be the catalyst for folks to want to get their arms around this, uh, problem on an enterprise basis, Right?

So you touched many points and, and I agree, I I get going like a runaway train. Sometimes it's, you know, that happens. I, I fully agree with, with all of them.

I mean, CS have been with us forever, right? Even, even within, um, old applications or monoliths and, and et cetera, they needed to authenticate against their databases or storage. And in order to do that, they needed a secret.

So essentially, uh, secrets are programmatic access keys. So every application that is being developed within any organization needs to use other services today, cloud services such as databases or storage accounts and et cetera. And in order to do that, they need a key.

And those keys are secrets. They can be API keys, access tokens, connection streams. Um, so, so yeah, secrets have been with us, uh, for a long while, but you are fully correct with the cloud services, the rise of the cloud services, different cloud services, and then microservices.

And each one of them requires at least one key. Today's small organization have at least 500, uh, different, different keys. And I've asked, I think at least 300 CISOs if they know how many secrets they have, and none of them have any idea how much secrets or how many secrets they have, and where are they stored.

So that's, that's, that's a real issue, right? Because those are the keys to your kingdom. Um, so yeah, it's, it's a great question.

And organization don't, or security teams don't really have any idea about how many stickers they have, where are they, what are the risks that are associated with them, what cloud services they can access, and most crucially how to protect them. You bet. So, so let, let's kind of start to, you know, kind of unpack that a little bit bit, right?

So yeah, customer says, yeah, you know, all these applications are happening and, and obviously they're using secrets because they have to, right? You know, in this, you know, kind of cloud base and, and microservices driven, uh, environment, how do they get started, right? I mean, it's, do I do it for one application and try to get my arms around those secrets and then go to the next one, go to the next one.

Do I kind of try to get an inventory of everything that's happening in my aw w s or my Azure, my G C P, uh, on that front, and then kind of aggregate all that information and then do risk analysis? I mean, what tends to be the most effective means to get going, right? Because if you go to a typical customer and go, you've got 10,000 secrets, and you have no idea where any of them are, their head goes pull, right?

And, and, and they dunno where to start, right? So, so how do we get started with trying to get your arms around the, the, the, the, you know, size and depth of this problem, Right? So, so the problem name is actually Secrets Pole are in which secrets are scattered around the organization.

And the the problem is that the teams that are creating those secrets are not responsible to secure them. So you have the DevOps teams and developers, so r and d teams are, that are creating secrets. So, so on from your DevOps will go to a database instance for an example, and, and it will create a secret key over there, and then it will store it somewhere and the application will fetch it, uh, and use it to authenticate to that, to the database.

But the problem is that today, uh, the RD teams are placing, storing or scattering those secrets, uh, everywhere. So they're using vaults and vaults are basically storages in which you can store your secrets. But then if you have a main vault solution such as aw, secret manager or vault, uh, which is great, you probably need one for each environment, uh, or for each region engine.

So you have a lot of different worlds. Uh, if you're using Kubernetes, you probably have Kubernetes Secrets. If you're using Jenkins or other c cd, you have Secret Store over there, uh, GitHub Secret Store over there.

So you have many world solutions, uh, at least five per organization. And then as, as you correctly, a lot of different, uh, uh, secrets out there. Uh, so yeah, security teams have no oversight about their secrets and where are they?

Uh, and, and even if, if you ever seen a secret, it's basically a long stream. So even if you find a secret, you have no information about it, you can really tell me which application are using it, uh, what cloud service it can access, what are the privileges of that secret within the cloud service? What are the risks that are associated with that secret?

Uh, so to your question, it's, it's a, it's a, it's a big challenge. Um, but yeah, organization must have a secret inventory to know how many secrets they have, where are they? And because you want to enable the business and enable r d, you want to let them use as many secret stores they need, or place the secret wherever they or the application is.

Uh, so what you should do is try to integrate to different places and compose the list and then to enrich that list with data. So you can say which application are using what secret to authenticate, to what cloud service and other vital data around the secret in order to protect it. So let, let's kind of think like an attacker for a sec, right?

Because you, you know, again, and I'll just play devil's advocate for a sec, right? So, you know, this thing's a big long string. I don't really understand what it goes to.

I don't have the context. I don't, you know, obviously it's called from within an application. So the application knows, you know, which secret it needs to hit on and it's got a, you know, unique, uh, an ARN and, you know, a w s lingo or, you know, kind of a, a, a, you know, resource ID in, in Azure.

Um, right? So, so, uh, this thing's laying on the floor, you know, what can I do with it if I'm an attacker, right? Why am I concerned about this?

I mean, besides just, you know, kind of, we like to have a tidy closet, right? You know, you don't wanna open the door and, you know, you get dumped on by a bunch of stuff, but what, what's the real risk of, of these things lying around without proper security? Right?

So those are the keys to your infrastructure, to your cloud services, to your data, to your customers data. What is the risk? If you lose your house key, uh, someone can use it to access your, your home, right?

So someone can use it in order to access your databases storage, uh, and, and et cetera, and, and extract all of the data from there. But not only that, you can use it to create more keys, more permissions, and you will keep reaching your organization in endless way. So if you lost a key, or if you an attacker owns one of your keys or your secrets, it's game over.

Yes. Uh, also I will just say that according to recent research organization are leaking at least 6 million different secrets every year. And according to IBM and Verizon are secret targeted, the tax vector, Saudi, and the most destructive, uh, archit to an organization.

4 million per one breach. And then again, they're getting more secrets and keep breaching that organization, Right? And and, you know, just to put a plug into why we wanna deal with this problem sooner rather than later, is it's not like we're gonna have less secrets tomorrow, right?

We have new applications, we've got new data sources, we've got new, so we're gonna keep, you know, kind of mushroom, ru, mushrooming, uh, in terms of the number of these secrets. So, you know, getting ahead a bit early and, uh, and, and often in continuously, right? I mean, that's the key thing.

So let's kind of, so once we figure out where all these things are, right? You mentioned in Richmond, and you mentioned context to understand what applications and, and what they're doing. One of the things we were talking about earlier is, you know, the idea of least privilege, right?

And making sure that the keys have the right permissions to only be used for what they're supposed to be used for. So, so how do you go about doing that? Is it a, you know, a big brain machine learning thing?

Do you have a whole bunch of, you know, folks in the back room, you know, checking out stuff? Uh, what, what's, I, I probably, it's probably not that, um, that seems like a very 1950s type of thing, but, uh, how, how do you guys take, take the approach of, of figuring out what the appropriate privileges are for those secrets and then, you know, applying that, you know, to the specific policies that would govern. Right.

So NTO does a lot of, a lot of different stuff around, uh, secret Security, and, and one of them is, as you mentioned, uh, the list privileged principles. So we are using a API course and we are leveraging access logs. Um, and, and we are able to not only discover all of the secrets within your environment and say how many secrets you have and where are they.

We are then classifying and enriching each secret. So we are integrated to all places in which secrets can be stored or exposed by data because they, they are committing secrets into code. They're sending them through Slack messages or other collaboration.

They are saving them within Confluence manuals, uh, and then vault solutions and cloud services solutions and et cetera. Uh, so we are able to find all of the secrets within the organization, and then we are able to visualize a map around them and basically to enrich them with context or to classify them and create a secret lineage map of which application is using what secret in order to authenticate to what cloud service and other vital data around that secret, such as what are the privileges of that secret? Yeah.

Uh, who created it, when, who is using it? What are the risks that are associated with it? Uh, and then we are constantly monitor those secrets for any abnormal behavior or anomaly detection around that secret.

So we, your secrets are being used, uh, from China or Russia, or any country in which you don't have business in, uh, we will let you know. Uh, so we are, we are continued continuously monitor those secrets for any abnormal behavior. And that give us a lot of, a lot of insights that one of them, to your question is the list privilege.

So let's say you have an application which is using a secret with right permission in order to authenticate against the database, and that database is only doing read operation, but the secret is a right permission. You can and probably should decrease the permission over that secret, but it's also a great mitigation step. So let's say we found an exposed secret within your code, and it's, it's a challenge to remove it from there because of many reasons.

Okay. At least in the meantime, decrease the permission of that secret and remove it from the code, from the exposure location afterwards. Yeah.

Yeah. Well, good. So we kind of went through visibility and discovery and making sure that you understand where all these secrets are across your entire environment, cloud platforms, Kubernetes, environment, C I C D, content sharing, right?

You know, kind of Jira, confluence, you know, those kind of things. Talk a little bit about, um, the importance of, of actually having policies to, you know, control the use of those and, and, and really to continuously monitor that environment. Because again, it's always changing.

It's very dynamic. Developers do what developers do, right? Which is, uh, try to get their job done.

So they're going to, and they don't view it as a shortcut, right? They don't view it as cutting corners. They don't view it as doing the wrong thing, right?

What they do is take action to get their job done right. And sometimes it means over permission, over permissive policies on that front because they're just trying to get stuff done. And that, you know, what happens in Dev tends to follow winter to test and then into pr, and then all hell breaks loose on that front.

So keeping track of it, I think is, is pretty important. Uh, on that front. Uh, it's, thanks for giving us a, an overview, uh, of secrets.

I think it is an important and, and emerging, you know, kind of concern that, that folks have to worry about if they wanna learn more about secrets or, or intro, you know, how do they get in touch with you guys Easily. Umto, security, https, auto security, you can reach us, you can reach me on LinkedIn or you can just look it up on Google. Well, great.

So, uh, it's Galvas. Thanks so much for being here. Uh, co-founder and c e o intro security.

We were talking about secrets and the importance of really the foundational aspect, uh, of secrets within the environment. Uh, so with that, let's send it back to the studio for our next interview. Discover the cutting edge insights of our new show, AI Times, a series that explores the limitless potential of artificial intelligence sponsored by the AI Infrastructure Alliance.

The AI Times is at the forefront of the AI revolution, tackling the crucial questions of how we can leverage AI for the betterment of humanity. Stay ahead of the curve as this show delves into all things surrounding ai, including trends, pressing concerns, and the positive impact AI is making around the globe AI times. Hi again, everyone.

I hope y'all enjoyed today's episode of Techstrong tv. We had some amazing interviews with industry experts to give you the latest in the tech world. We'll be back again tomorrow, so we hope to see you then.

In the meantime though, if you want more tech strong TV content, be sure to check out some of our podcasts or download our mobile app. Thank you so much for watching, and I hope you have a wonderful rest of your day. As always, stay strong tech strong.