Getting started with Platform Engineering security and compliance

Bart Farrell (00:01.315)

So today we’re going to be speaking about the rise of platform engineering. We’ve asked this question many times, is DevOps dead? What is different about the two? Is it a philosophy? Is it a series of technologies that are being used? And then also talking about IDPs, internal developer platforms. So like I said, these are technologies that are coming about for many different reasons. A lot of it making things like when we’re talking about advanced infrastructure, cloud native infrastructure.

making it easier for developers in terms of developer experience. When we look at the numbers as well, Gartner predicts that by 2026, 80% of software engineering organizations will have a platform team. So from a talent perspective, this is something that organizations are concerned about. Today, we want to be thinking about how can IDP, when we’re talking about internal developer platforms, when we’re talking about platform engineering, the role of security and compliance?

And so what to look for when thinking about which development platform is going to be best for a particular organization, considering those concerns around security and compliance. And then also ensuring that the images that are used to deploy these workloads are in sync with any security and compliance requirements that the business may have. Because depending on the business, depending on the regulatory situation of each country, those are things that we’ll have to keep in mind. Before we get into that.

We want to start out with just a couple of warm up questions. We are joined today by Ram and Chris from Cloud Foundry. So Chris, we’ll start out with you. Which historical figure, living or dead, would you trust with your personal data most, and why would you choose that person?

Chris Clark (01:43.862)
Hey Bart, glad to be here. Well, let’s think here. I’m gonna go with Rosalynn Carter.

Not for any particular reason other than that, she seemed particularly trustworthy. She recently passed away. And I think, you know, yeah, I mean, Jimmy, I trust too. But, you know, he’s a rather old man right now. So perhaps not in the current state. Like a younger Jimmy Carter, obviously. Obviously I’m not also talking about Rosalind Carter on her deathbed. You know, a younger, more vibrant Rosalind Carter, I think would be a fine shepherd of my data.

Sylvain Kalache (02:04.828)
Thanks for watching!

Thanks for watching!

Bart Farrell (02:19.967)
Interesting choice. Ram, what about you?

Ram Iyengar (02:24.118)
Hey Bart, hi Sylvain, nice to be here. Going by a lot of the stuff I’ve read in history books, I’d probably trust Ben Franklin, because he has kept a lot of secrets over the years, I guess, and you know, he’d be a good choice, I felt.

Sylvain Kalache (02:26.858)
There we go.

Bart Farrell (02:41.751)
OK, good. Next question, if you’re given a magic wand, Chris, and can instantly solve one data security challenge, which challenge would it be and why?

Chris Clark (02:55.01)
Well, it’s always the next one, right, that you don’t know about yet. That’s the most perplexing, I suppose. So yeah, I would say I’m most concerned about the things I don’t know about.

Bart Farrell (03:11.067)
Very, very good. We don’t know what we don’t know. Yeah, buddy.

Chris Clark (03:13.194)
Well, I’ll also answer it this way too, although this is not exactly, I wouldn’t say this is a data security challenge, but more of a particularly malicious use case for data security challenges. I’m awfully tired of ransomware in the medical field. That’s particularly annoying, isn’t it? Like hacking hospitals and pharmacies. Not very cool.

Bart Farrell (03:37.299)
Not cool at all. Definitely not cool. And I would take that magic wand right after you and echo that. Ram, what about you? An additional data security challenge that you would like to see solved?

Ram Iyengar (03:48.682)
As someone who’s very passionate about open source, some of the recent supply chain security attacks that have sort of threatened the existence and the notion of including open source has been particularly disturbing to me. So if I’m able to make inroads into those in any which way I can, I’d gladly do that. And so that’s what I’d put the magic wand to use for.

Bart Farrell (04:18.491)
Very good. Now for a bit of context, you know, when we’re thinking about managing infrastructure, how are data compliance and security requirements influencing companies when it comes to that very question of how to properly manage their infrastructure? Chris, can we start with you?

Chris Clark (04:37.826)
Well, we’re seeing a lot more sort of top down requirements now, right? Europe sort of was at the fore of this, right? The EU’s had much more stringent requirements for some time now, but now you see the US government in the wake of various hacks and security issues, like coming out with its own prescriptive regulations. And that’s…

That’s only going to increase, I think, right? And for a lot of vendors that have governments as their clients, or even just any vendor that wants to operate in a certain space, there’s gonna be more and more prescriptive governmental regulations coming down for these things. So I think everybody is taking this stuff a lot more seriously than they did just a few years ago. And it’s good to see, because obviously there were some serious.

serious vulnerabilities that people weren’t really considering, both in open source and closed source. And those differ quite a bit. But it is nice to see an increased focus on open source security.

Bart Farrell (05:51.191)
Very good. And as you mentioned, more and more awareness around this topic, 137 out of 194 countries do have legislation in place to protect data and privacy. But now, Ram, over to you. Regarding this point, from a technical perspective, where does open source come in? Some people might say, oh, there’s actually additional risk with that. What’s your take on that?

Ram Iyengar (06:14.81)
I think it’s a question of striking a good balance. There is a lot of risk to not taking the open source route versus taking the open source route overall, is my opinion. There are a lot of engineering efforts out there that are very focused on

providing this kind of security as a service. It’s definitely the easy route to take in terms of securing data, securing identities, and securing like all sorts of different entities of a software landscape. But overall, given the amount of control that open source

provides in addition to being feature rich and security capable. I think going the open source route is sort of better provided an organization has the bandwidth to invest in that site.

Bart Farrell (07:29.175)
And you know, Chris, you’re someone who’s well-versed in the importance of foundations as well as community. When it comes to dealing with these issues around security and compliance, what role can community play? Where can it help out for some that might feel overwhelmed, that they lack knowledge, that they lack the expertise, or even talent in their organizations? What role does community play when it comes to responding to these issues?

Chris Clark (07:55.234)
Sorry Bart, one of us is freezing up a little bit, I can’t quite hear everything you’re saying.

Bart Farrell (08:01.243)
It’s all good. So as someone who’s well-versed in foundations and the role that community can play when it comes to open source in general, on this topic related to security and compliance, where can communities step in to add value for people that might be confused or even overwhelmed when it comes to security and compliance?

Chris Clark (08:20.21)
That’s a good question. Yeah, from a community perspective, I mean, having very…

clearly documented and well advertised security protocols.

Chris Clark (08:36.054)
is becoming more important for open source communities and the health of open source projects. Obviously in an enterprise situation, right, there’s gonna be, there are rules and developmental protocols that will be followed at any large enterprise. But in an open source community, those things need to be decided on. And they should be prescriptive and clearly documented, which like, A, makes it easier for the developers to know exactly what needs to be done and what doesn’t need to be done.

It would then be also just to instill confidence in the project or foundation from anyone that might be looking at using it. OpenSSF, the Open Source Security Foundation, which is another Linux Foundation project, I mean, they’ve got some projects in the work that are being developed now. There’s a scorecard and things like that you can clearly kind of see what things are being done in an open source project and what things maybe should be.

Sylvain Kalache (09:08.272)
Thank you.

Chris Clark (09:35.062)
you know, on the short-term roadmap to make things more secure, to make things more transparent. So there’s a lot to be done right now.

Bart Farrell (09:43.831)
Very much agree. And I like what you mentioned about that point about confidence, right? Is that knowing that if you have an issue, that you can get a response much faster than you necessarily would from a vendor. And so really building that consensus-based, agnostic approach towards these challenges is really reassuring for people that might feel that they’re navigating in waters that are relatively murky. In the specific case, Ram, if you could comment on this, in the specific case of Paketo buildpacks in Korifi,

Is there anything in particular that’s caught your attention there that you think our audience should know about?

Ram Iyengar (10:19.12)
So, there is a quote by Eric S Raymond in the book, The

one of his older books, I think Cathedral and the Bazaar or something else that he wrote online where he says, given enough eyeballs, all bugs are shallow. So the power of the community right now is, you know, given a sufficiently large community, all security and compliance issues are, you know, fairly trivial. But in terms of what buildpacks can do.

and what they’ve demonstrated in the past, vis-a-vis security issue is, a few years ago there was a famous vulnerability called Heartbleed, and it was everywhere. So it was in people’s, everybody who had a container-based approach had this problem of taking many man hours or,

to really fix and to mitigate the issue. The folks that were using buildpacks though had a very simplistic approach where they were able to update one image layer in their container registries and because buildpacks were designed to take advantage of a modular approach where you can re-base an image which

Ram Iyengar (11:50.646)
entire image through a rebuild. The architectural decision that went into the design of the build pack combined with the community’s awareness to update all of these individual registries with the patch fairly quickly pushed all buildpacks users to fix this in a matter of minutes as opposed to taking weeks and close to months for those with like a Docker based build approach.

buildpacks demonstrated this capability both in terms of design and architectural technical one plus the community really coming together and updating the specific image layers very quickly to mitigate that issue demonstrated both how you need a good technical plus a non-technical.

push to resolve security and compliance issues very quickly.

Bart Farrell (12:50.935)
And one thing to add to that as well, Ram, is if we’re talking about open source solutions, apart from things like security and compliance in the context of internal developer platforms, the topic of interoperability, could you comment on that really quickly? Advantages, things that people may not be aware of when it comes to interoperability.

Ram Iyengar (13:17.746)
So it’s never a single tool or a single approach that you can continue to harp about. So I’ll borrow a story from the Cloud Foundry evolution over the years to really highlight this. So back in the day, Cloud Foundry was designed as a very opinionated standalone platform as a service.

As they were starting to work on how best to deploy immutable artifacts, they stumbled upon these things known as containers and Cloud Foundry had the ability to start generating containers. Now they were called droplets within the Cloud Foundry community and they had a very opinionated way in which these droplets were created and deployed. And along came Docker.

Docker grew by leaps and bounds and brought this notion of containerization and really democratized it for the world. And the Cloud Foundry community did not, you know, block them off and instead allowed Docker based containers to be deployed through Cloud Foundry as well. This was going on for a few years. And like I said, Cloud Foundry had its own way of doing containers.

And consequently, it also had a container orchestrator. So this was almost pre Kubernetes era. And as Kubernetes started to pick up and become more popular and become what it is today, the Cloud Foundry community decided to borrow the Kubernetes orchestrator for its orchestration and really, you know, rediscovered and rebuilt the

project to take advantage of Kubernetes of the cloud native ecosystem and the landscape to replace a lot of the tooling internally that they did for stuff like load balancing, for managing storage, for doing deployments and so many other things in light of Kubernetes now. And so the community has always maintained interoperability with popular technology as part of its fundamental ethos. So

Ram Iyengar (15:39.194)
The aim is to always make the tool work with the tool chains that are popular and that are most efficient to work with. And so in that regard, I think the Cloud Foundry story is one that’s really important to tell in light of interoperability. And if you look at like past Cloud Foundry summits and things like that, back in 2019, if I recall, there was a

major announcement they did with like the OpenShift community where CloudFoundry was able to work with OpenShift. And the idea is to not try and reduce every problem into an A versus B kind of thing. So it’s not CloudFoundry versus Kubernetes. It’s not CloudFoundry versus Docker. It’s not Docker versus PaaS. So it’s, I think it’s about, you know, making technologies work harmoniously together as much as possible.

And I think the Cloud Foundry community is a great case study in this regard.

Bart Farrell (16:38.715)
All right, good. And like you said, that balance is something that doesn’t come overnight and has to be achieved in different ways with different actors. But it’s something that I think can’t be overlooked and can’t be left out of the story if a successful outcome is desired. In terms of, OK, so going into this further about IDP, internal developer platforms.

Let’s get further into the foundational elements, particularly the images that are used to provision servers. So Chris, what significance do these images hold when it comes to ensuring data compliance and security?

Chris Clark (17:18.122)
Well, I mean, they’re a core building block of any sort of software deployment.

Chris Clark (17:27.542)
Yeah, there can also be a significant challenge in building to compliance with new regulations and to current security requirements. So automation is kind of essential there, right? If you’re gonna have to have protocols in place for any sort of enterprise or even smaller organization, you’re gonna have to have a strategy for…

for how you construct images. And you’re gonna need to automate that, right? Like you’re not gonna have individual developers writing Docker files at this point, or at least you shouldn’t be, right? That’s great for small open source projects or for MVPs and things like that. But having an automated build cycle that has these security features like SBOMs (Software Bill of Materials) built in out of the box.

is, should be sort of seen as required these days, I think. And there’s a number of ways to do that. I think buildpacks is one of the more elegant user-friendly approaches, right? But there are other ways, obviously, that buildpacks aren’t the only solution here, but I do think they’re one of the more powerful, elegant solutions. And we’re not seeing, I think, a lot more people adopting them in their own internal platforms for that reason. So.

Yeah, I mean, you can’t get away from the importance of how you construct your images. And I think cloud native buildpacks are one of the better options out there for that.

Sylvain Kalache (19:09.68)
Yeah, I want to jump in on that because I think what’s truly unique about, I mean, one of the truly unique points about buildpacks is that it’s compatible with pretty much any stack of our modern framework. So you do have like a bunch of, as Chris said, ways to create, you know, properly secured images, but usually you need to rely on a bunch of different tools.

Sylvain Kalache (19:39.614)
in the trend of platform engineering, mixed with security, you definitely want to standardize. And so if you have one tool to package whatever application or stack, this ensures that the standard that you’ve put in place are the same for all the images. And as Chris said, the Buildpack CLI allows developer to get an SBOM.

out of every images that are being generated by build back. So security team can definitely, you know, look at everything that’s in there and make sure that there is no.

no dependency or libraries that is an issue. So I think Buildpack is great if you have a team that can handle this and look at SBOM. But actually there is another project that I’d like the audience to know about RAM. Can you tell us about Paketo Buildpacks and why it could help the platform engineering team?

to ensure that the image that they use are optimized and secure.

Ram Iyengar (20:58.498)
Sure, I’m happy to expand about that, Sylvan. So, Paketo is a project that’s a collection of open source production ready buildpacks. So, like Chris and Sylvan mentioned, it’s available for teams to take advantage of irrespective of what kind of language or framework you’re using. And what it will do is,

provide this very homogeneous uniform build process. So you’re not managing like different Docker files for different remote staging environments. You’re not using a different build process for creating artifacts for a different environment. So it’s, there’s no, so it used to be, it works on my machine before, and then it became, it works with this Docker file now, and then, you know, buildpacks really eliminates both of those cases.

And then what I enjoy about what the community has built is it’s, buildpack give you this way of composing things. So let’s say you have a React application of which you want five front end instances and you have a backend written in Python. And then you want a build pack to deploy all of these into a single container image. You can.

do that with buildpacks where you have a node JavaScript based build pack for your front end. And then you can say, give me five instances of that image and then give me one instance of the Python backend image. And so buildpacks allow you to sit 100% feature parity with what Docker based containers can do as well. So if you have a.

major complex Docker based workflow right now for testing and deployment to production and things like that, buildpacks can continue to serve those needs. What I mean by that is if you create containers and images using buildpacks, you can use Docker based deploy and Docker based run workflows right now. So it can upload to your Docker hub container registry. It’s helpful in being compliant in every which way possible. And the other interesting aspect about buildpacks that I’ve enjoyed experimenting with is, buildpacks like Docker images work with these entities called builders and base images and run images. And so you can swap out these images for, let’s say, one of these lower CVE tiny sort of image. So you can use Undistros, you can use smaller versions of the Linux base in order for better security and better compliance and things like that. And there’s really a ton of different customization options that buildpacks provides with very little that you need to do in terms of configuring.

your builders and your workflows to take advantage of.

Sylvain Kalache (24:29.272)
Yeah, that’s the thing. I think it’s like staying on top of, you know, like your security strategy.

especially if you are a large organization with a wide spectrum or if you have limited resources, like you need a lot of resources and security oftentimes is not a priority because it’s not really providing direct value on the product. And so outsourcing this to the community definitely makes sense. And what’s pretty cool with the Paketo community is that the stocks

Sylvain Kalache (25:08.782)
they’re stuck to ensure that the package are up to date. And if there is a major, like important CVE patch that’s made available, I think the turnaround is like 48 hours. So, it’s pretty quick and you don’t need to think about it. And if it’s not fast enough for you, guess what? You can update it yourself, right? Because it’s all open source.

And so I think this gives the power of like, this open source project gives the power of one, you can benefit from the community and you can do it to yourself if ever it’s not fast enough.

Bart Farrell (25:54.891)
OK, good. Well, we’re just about towards getting to the home stretch of the episode. Chris, I want to ask you, moving forward from the Cloud Foundry perspective, looking at the growth of this trend of platform engineering and internal developer platforms, what are the things that you want to know about more? What are the things that are piquing your curiosity when it comes to platform engineering, but also keeping in mind security compliance? You mentioned earlier about SBOMs.

let’s say a year and a half ago wasn’t so much of a thing. It seems like more and more companies are adopting, and even more should be catching up with this. But what are the things that are, like I said, that are piquing your curiosity that you’re interested in exploring further in Cloud Foundry and beyond?

Chris Clark (26:38.57)
Well, I think open source security right now is in a very, very dynamic place. A lot of these initiatives are still quite young, right? Like, yeah, I mean, Log4j wasn’t that long ago. Before that, this was all, lots of this was just taken for granted in ways that it, like in hindsight, of course, shouldn’t have been. So looking forward, I’m just, well, actually, let me back up and approach this more of just a platform engineering in general, right? Like,

Since Kubernetes sort of won the container orchestration wars, that sort of left a lot of enterprises in this sort of interesting area where they know Kubernetes is sort of what we think is going to be the medium term future standard. And so you have to have a strategy there. And it makes a lot of sense to be using Kubernetes if you’re a larger enterprise. But building your own platform is a lot of work, a lot of overhead.

Chris Clark (27:37.138)
And open source software and open source automation tools like Paketo Buildpack or other cloud native buildpacks can really reduce your technical debt and, and assist you being in compliant with security protocols, you know, now, as opposed to having to build all those things out yourself. But I guess what I’m interested to see in the future is just sort of how this gels and if there’s a real standardization in

in internal development platforms, right? Like, you know, PaaS is, you know, I don’t think we’re necessarily gonna go back to the days of PaaS exactly like that, but what sort of commonalities we see, what sort of frameworks we see come out that sort of unify internal development platforms that we don’t see right now. Because right now it still kind of feels like the Wild West and everyone’s building their own things. And that’s frankly very inefficient. And there’s gotta be some increased efficiencies there.

where we see just more common tools for building your own platform. And this will probably lead to a larger part of people’s platform stacks being open source, I would think. But seeing where these tools go in the next few years, I think…

Bart Farrell (28:53.487)
Absolutely. And I think, like you said, the Wild West, it’s like Kubernetes seem to be Wild West enough as it is. And then we add another Wild West in addition to that, where everyone’s kind of running in different directions, needing that standardization, coming to terms with the technologies and what they’re able to provide the dilemma around build versus buy. And also what we talked about in the very beginning, making community part of it. So building in the open, sharing that experience.

Chris Clark (29:02.274)
Right. Yeah.

Bart Farrell (29:20.823)
best practices being something that are more readily available. I think that’s something that what we’ve seen in other instances, like we were speaking about earlier about SBOMs, is something that we can hopefully continue to see when it comes to platform engineering. Ram, is there anything that you would like to add before we wrap up?

Ram Iyengar (29:43.114)
Yeah, the whole notion of platform engineering is very crucial both for the cloud foundry community and apparently it’s important for the Kubernetes community as well. At Amsterdam, I think was the first time somebody publicly admitted on the keynote stage that Kubernetes is a bit complex. So it was very interesting for us to note.

And obviously the community has been hard at work. And there’s so many different aspects of keeping an application running on production that developers really shouldn’t have to be tasked with and operators shouldn’t have to toil about. And so if platform engineering can bring that kind of efficiency and reduce wastage and get people to focus more on some of the core app development work. I think overall it’s imperative that we invest in platform engineering to create a better world to live in, so to say.

Bart Farrell (30:57.231)
a lot. Good. So anything you’d like to add before we finish?

Sylvain Kalache (31:01.712)
No, yeah, like the one last episode that we did with the data defender forum, one of our guests spoke about how we could perhaps, Chris spoke about standardization and the idea was to perhaps expose some type of API for every part of your stack that would return a kind of a state

of the software that could allow the auditor to check for, you know, compliancy of security or other, you know, data regulations that you have to obey to. And, you know, I think like the question of like, hey, like we are at the same time, we want the community centralizing, but at the same time it’s splitting up into like the platform engineering and IDPs really, but assembling a bunch of different pieces together.

So yeah, there might be a need for the community at some point to come up with some type of standard that all the pieces can leverage to really provide a unified experience at the end of the day for platform engineering teams.

Bart Farrell (32:18.555)
Great. Well, thank you all very much for sharing your time with us today and looking forward to future conversations.

Chris Clark (32:22.798)
Thanks all, it was a lot of fun to be here.

Ram Iyengar (32:25.494)
Thanks Bart, thanks Sylvain, it was a pleasure.

Bart Farrell (32:28.667)
Pleasure.