Swapnil Bhartiya: You may think that when it comes to software development, the biggest risk or challenge is what to build next. But in most cases it is what you are still running. End of life open source software can leave enterprises exposed and AI is making it easier to discover and exploit those weaknesses faster than ever. HERO devs knows that and they are helping organizations secure those older versions so they can stay compliant and buy time to migrate safely. And today we have with us Rob Nalen, Chief Operating Officer at HeroDevs to walk us through that. Rob, it’s great to have you on the show.

Robert Nalen: Thank you Swapnil, great to be here.

Swapnil Bhartiya: It’s my pleasure. For those who may not know, and this is the first time actually you and I are talking, so I’m also kind of curious. Talk a bit about HeroDevs. What do you folks do?

Robert Nalen: We provide end of life support for open source software and so started in 2018. Companies are consuming a ton of open source and their ability to stay up to date on that open source is becoming more and more difficult, much in part due to AI, but some other factors and what they find themselves in is a situation where they’re on unsupported versions while they still need to maintain their internal policies as well as compliance with things like PCI, DORA, HIPAA, all of those regulations and compliance standards. So what we do is we bring a drop in replacement that provides CVE remediation and ongoing monitoring for end of life software. So open source software that’s no longer being maintained by the community.

Swapnil Bhartiya: When we look at AI, I initially was trying to build a case that we see two aspects of it, it’s helping maintainers. So when it comes to end, AI can do a lot of things when you don’t have maintainers and all those things, but it can also create unnecessary burden from where you sit. Also I talk to a lot of folks who are in the open source space and they use AI heavily. Sometimes they’re like even I agree, the problem is not with the AI, the problem with the user of AI. Because you can create a prompt like for example, you can ask it to write a blog post. You don’t give clear instruction, clear prompt, you don’t edit it, you don’t audit it and you publish it as it is. It’s not AI’s fault, it’s your fault. So I also want to quickly, before we talk about the end of life and everything from where you sit, how are you seeing impact of AI on open source code base, contribution and maintainers?

Robert Nalen: It’s been the use of AI has been growing exponentially now for, for 20 years. And you can thank Red Hat and other community support for that. What AI has done is it’s put everything into this sort of lightspeed effect. And so the amount of open source being consumed and created has grown to the point where communities are having to try and maintain the same posture they’ve had in the past with these incoming requests. And so we’re seeing situations where large frameworks were getting, you know, 15 to 20 CVEs throughout an entire year, and now we’re seeing 60 plus CVEs in a single week. And so what we’re finding is the communities are in a position of how do we keep up with these requests, how do we enable the community to move forward? And for us, what we want to make sure of is if that sustainability effort is not there, the versions of open source that our enterprises are built on may no longer be safe to use. And so that’s why we’ve partnered with organizations like the OpenJS foundation and most recently the Commonhaus Foundation to find these sustainability methods to enable communities to keep up with the demands.

Swapnil Bhartiya: Now, we are looking at two different things here. One is end of life. You know, end of life means, okay, the maintainers are done, it’s not their problem. Some projects have, they just put it on the archive or attic and they’re done with that. Second problem is that we actually have to deal with security issues. As Linus once told me that security is, I mean, bugs are part of software development process. As long as you’re writing the code that will create some bug and some bugs will become security. So we are talking two different problems. One is sustainability and second is CVEs and everything. So when we talk about CVEs, are you talking about securities and patches of code, which is end of life unmaintained, or you’re talking about active code development as well? I want to make that clear first.

Robert Nalen: So what HeroDevs does is our sort of view on things is we support enterprises with that end of life problem. And so that’s what our business is predicated on. We want to make sure that these companies that have those standards are able to live up to them. They have to be able to pass their PCI compliance audit, they have to be able to align with the DORA regulation out of the EU. Right. So that’s one effort where we’re helping. What we’re also doing though, and that’s how we help out our customers through our partnerships with various open source communities. What we do is two things. Number one, we provide direct sponsorship. So we provide donations and revenue share opportunities so that communities can actually benefit from the work that we’re doing with those enterprises that are stuck on those end of life versions. So that’s one thing that we do. The other thing that we do is we actually provide our team. So we have many of the best engineers in the world, across the multiple languages of Java, JavaScript, .Net and Python. And so we want to help with not only those end of life versions, but we want to make sure that if we find an end of life version that has a CVE, well, let’s make sure this isn’t impacting a current version. And if it is, we want to work with the maintainers to make sure that the current version gets patched as well. And so we view ourselves as sort of wearing two different hats, but for the same goal, which is how do we help open source? And we do that by supporting enterprises, and we do that by supporting the open source communities, whether it’s financially or with assistance. And that’s why you’ll see some CVEs on current versions. There’s actually shout outs to HeroDevs’ engineers helping out with those CVEs, whether it’s identifying them or even helping with the patches.

Swapnil Bhartiya: Excellent, thank you. So the main and primary focus is end of life. Now, when it comes to end of life software, there are two things here. The official maintainers are not maintaining anymore. They have moved out, which also means they have created, of course, the next version is out. That’s what they’re working on. Sometimes a lot of things get deprecated because maintaining end of life software is not as easy as. Because you are running in production, you are not running in some code that nobody is using. The goal is to support that software as long as possible. Or the goal is business continuity while they are working on migrating to the latest changes and updates, because that will also become sustainable. Because you cannot rely on code that was taken 30 years ago and somebody is still using it.

Robert Nalen: Yeah, love it. It’s more of the second for sure. It’s how do we give the engineering teams that are already dealing with a myriad of, whether it’s technical restraint, budget constraint, roadmaps that are really difficult, all of the influx caused by AI. How do we give these teams a path to give themselves really clear structure for modernization? And so a great example would be, you know, someone that’s relying on AngularJS. So you have an application. AngularJS is end of life. And it’s no longer supported at all by Google, which means you need to move either from AngularJS to Modern Angular or React. That could take two, three years. And in the meantime, your application still needs to be running, it could be generating revenue for you, it could be extremely mission critical. And so with a HeroDevs subscription, you can make sure that your application, specifically the AngularJS components, are supported throughout your time. And so if you need two years in order to enable your team to make that migration, that’s what we’re here for. We also do it for minor versions or major versions and changes where it’s a large framework and you can’t move over. And so if you’re on, you know, Spring Boot 2.5, for example, a migration to Spring Boot 3.5 may be really difficult. And if you’re in a regulated industry, if you’re dealing with your PCI compliance audit requirements, you can’t simply stay on the legacy version while you’re even working to migrate. And so we give, ideally what we want to give is engineers the control of their roadmap and give them that time that they need while staying in compliance and secure.

Swapnil Bhartiya: Now, I want to bring AI back into the picture. How is AI impacting this support for end of life?

Robert Nalen: Yeah, so from an end of life perspective, what we know is AI is really good at finding CVEs, which is great. It’s also really good at potentially exploiting those CVEs that are found. And then lastly, we know that AI is really good at building things from scratch, but it’s not necessarily really solid at understanding that what it’s building needs to align with a product lifecycle requirement that an institution or an enterprise may have. Right. And so unpack that a little bit. We know that AI is going to increase the number of CVEs, and so organizations that have perhaps been running the risk of running an end of life version, they’re going to be inherently at more risk. This right now is a time where people can go through and find those vulnerabilities and exploit them. And we know that this can have dire consequences. Similar to the Equifax breach in 2017. Right. As far as the creation standpoint, AI is amazing at building things, but it’s certainly not looking at direct dependencies and transitive dependencies and all of the libraries that are being brought in. And so we see time and time again that AI is being used to build an application. But then, unbeknownst to the folks that are working on it. They don’t realize that, you know, three, four, five, six dependencies are using end of life unsupported version of software, many of which may already have CVEs available. And so we’re finding those happen more and more within our customers. And then lastly from the community side, we know that AI is driving security issues and requests. And so I speak with community maintainers all the time who are saying they’re receiving hundreds if not thousands of requests a week and there’s no way for them to be able to keep up with it. And so I visualize it like a race where AI is using any method possible to find CVEs and the would be bad actors have limitless potential as soon as they find it. And open source communities and security working groups and enterprises have to follow all of the standards. And so this race really isn’t an equal race. It’s almost like someone has a head start. And so for us, that’s why we want to make sure that those relying on end of life, they have a supported version and they’re not just completely subject to the risk.

Swapnil Bhartiya: Now there’s one more wrench that is thrown recently which is CRA, which is I think already coming in to be in force. I think September. I mean there is a very tight timeline which also puts a lot of responsibilities on organizations who are either distributing or selling any open source code base. And that could be a big risk. How do you look at CRA and how do you feel HeroDevs is actually well positioned to help those organizations to ensure they will not be fined by the EU?

Robert Nalen: Yeah, absolutely. And so the way I think about regulations is it’s a very systematic approach. And right now AI is putting a lot of pressure on protection of personal data and potential vulnerabilities that could expose personal data. And so that’s why you’re seeing all of these regulations start to hit right now. Things like DORA, things like EU CRA, things like NIST 2, CMMC 2.0 in the United States. And so these requirements are so that vendors that are supporting institutions and enterprises in the EU aren’t in a situation that HeroDevs solves. They are looking for making sure that the components that make up that application are supported. And so for us, our goal is to ensure that our products enable an enterprise to comply with any and all of those regulations, whether you’re talking about those that are being created in APAC now, the EU or the United States. And so for us, we enable an institution, whether it’s a vendor or a user in the European Union to say this application that’s running this unsupported end of life version to now be under support. We provide things like VEX statements, we provide letters of attestation, and even through our commercial contracting, we can demonstrate to any third party auditor that they are under support, that they’re continuing to receive that continuous monitoring and updates for those fixes. And so for us, specifically for CRA, if an institution is using an unsupported version of open source, they would run the risk of not being compliant. With a HeroDevs subscription, they would be supported and so they would be able to pass any audit and show and demonstrate that they are supported.

Swapnil Bhartiya: The answer to this question is quite obvious, but I would like to ask you what are some of the biggest security and compliance risks organizations may run into once that software is no longer officially maintained?

Robert Nalen: Yeah, so once something is no longer officially maintained, think of it as that piece of software has stopped moving, but the world around it has continued to move. If you’re using something that has connections to web browsers, for example, those are going to continue to iterate. And so that’s why companies, and specifically HeroDevs, we have folks that are really well versed in this software. We understand that there can be compatibility changes that could give rise to CVEs, there could be situations where modern versions actually create Day Zero events in unsupported versions. So that’s what we’re looking for all the time. I think for me it would be the compatibility changes that have the biggest feature. The other part that I think could really be unknown is SCAs are really good at highlighting what’s in the build. There is a blind spot though to end of life open source software. They’re not looking for things like abandonment. And so we actually have a completely free available solution. It’s called End of Life Dataset. Anyone can run it, you can run it as a CLI. It’s not anything that we’re selling. And this actually gives customers, enterprises a snapshot of what’s within their environment that is end of life. And we found in some of the largest environments that things are actually missing. And so End of Life Dataset has a bunch of heuristics that we’ve built based on our experience in end of life that actually give visibility to our enterprises. And so to me it’s a matter of how are things changing that could impact what you’ve deployed and then what don’t you know is there? And that’s the really scary part is you could have an exposure without even being aware that it’s in your build.

Swapnil Bhartiya: When you talk about in the build, the word that immediately comes to my mind is software bill of materials, the whole software supply chain. Now, you wrote all the code, which is clean, which is healthy, which is hygienic. But with open source, we do know you have a lot of dependency, you use a lot of libraries, and those libraries themselves may have hit end of life. They are not maintained, they’re not supported, they have their own CVEs. Talk about where do dependencies make this challenge even harder for enterprise teams? You can ensure your code hygiene, but if you’re looking at hundreds of dependencies and libraries, that can become a nightmare.

Robert Nalen: Yeah, absolutely. This is where we found an ecosystem. There’s a lot of people that say we support. And when they say that it really means technical support, they’ll answer the phone when you call in the middle of the night. What we’re doing is we’re actually looking at this from a true security perspective. Right. And so if you look at things like our Spring product, we do full rebuilds with all of the direct dependencies included. And so you can know that when you’re looking at your Spring framework installation that we’ve actually gone through to make sure that those direct dependencies are there. From a transitive or indirect dependency, you’re absolutely right. And that’s why it’s important to have that snapshot of what’s in use, so that you can have the knowledge of, hey, this version’s end of life, but luckily it’s just a minor bump that I need to make. And so for HeroDevs, we specifically look at how do we make sure that those direct dependencies are covered. Things like the Angular Translate vulnerability, which weren’t necessarily shipped with AngularJS, we actually covered those as part of a separate subscription to make sure that customers had the coverage that they needed.

Swapnil Bhartiya: Now let’s talk about your partnership with Commonhaus Foundation. Talk a bit about how does this partnership with them help both open source communities as well as enterprises?

Robert Nalen: Yeah, absolutely. So Commonhaus Foundation is awesome. Aaron is an incredible person to work with. And so Common House is a consortium of a bunch of different open source communities. And so similar to what we did with the OpenJS Foundation is we worked with Common House to sort out how do we help on those two fronts, how do we enable enterprises that are coming to the Common House project pages. So Hibernate, Jackson, Quarkus. And they’re hitting these pages and they’re using versions that are unsupported. And so they’re going to the community and saying, I know I need to modernize, I need to get to the latest version. It’s going to take some time. Who can we work with, who can be trusted? And so that established that partnership to say through the Open Source Sustainability Initiative. Here’s the requirements for what a vendor to participate in the program looks like. And we worked on that with Common House. On the other side is our actual sponsorship and the efforts that we take to help out the communities on the current versions or just their general development. And so that gets into how do we help out those communities with dealing with additional requests. And it may be something like, hey, we can help operate as a CNA, we can help troubleshoot incoming requests. And we’re happy to do that even on current versions because it’s part of our due diligence anyway to see if there’s a current issue on a supported version that may impact a legacy version. And so we’re really partnering on both fronts there to make sure that those projects, which again are relied on by some of the world’s largest companies for very strategic applications and infrastructure, have a place to go to. So we’re really, really excited about the partnership.

Swapnil Bhartiya: You folks are doing all this heavy lifting for organizations as AI adoption continues to grow. What are the risks that enterprises and open source communities need to pay close attention to? I mean, we have seen, I mean some of these, not technology, but personas, cultural changes, DevOps, DevSecOps, SREs, the roles are evolving. And I believe that culture plays a much bigger role. Processes that you have internally play a much bigger role than any tool there. So talk a bit about how organizations, enterprises or even open source communities should look at open source, how they should build a new culture to, instead of fighting back, they embrace that this is the new reality, this is how we should build and maintain things.

Robert Nalen: Yeah, I think the shift that needed to happen, it needs to happen. We’re already starting to see, we’re seeing things through these clearinghouses that are being created. Right. You have Mythos, Glasswing, most recently IBM Project Lightwell and I believe IBM and Palo Alto just announced a partnership under Lightwell. Right. And these types of relationships where enterprises and large organizations are stepping up and saying there needs to be these efforts to support open source, because without them, the communities are not going to be able to deal with the incoming demand. This isn’t a simple of, oh, it’s growing slightly. This is a mountain of CVE and issue requests that are coming in. And communities are comprised of incredible humans, many of which that are donating their time. They have day jobs which may or may not be associated with the project that they’re working on. And so these clearinghouses to me are a demonstration of organizations identifying if there’s not a clear line of sustaining these communities, the issue could be extremely dire. And it could be that the way that security vulnerabilities were dealt with in supported versions of open source software is no longer able to maintain pace. And if that happens, I firmly believe with a position and background of compliance standards and regulatory requirements, that we could see a change. You could start to see some compliance standards highlight that being on a supported version of open source is no longer tenable to be compliant with things like PCI DSS assessment, or EU CRA or DORA or NIST 2. And so it’s extremely imperative for the community’s sake and for the enterprises that have all built amazing technology on open source to be able to ensure that the communities stay active and stay in line with these growing demands. And so that’s what I’m seeing right now, which is really beneficial, is companies stepping up and looking forward and they’re doing similar things to what we’re doing with the Common House initiative. And without sounding the alarm too early, but in my mind, this really could have consequences where open source as we know it today could look completely different without that support.

Swapnil Bhartiya: No. Very well said. Thank you so much. I may also ask, where do you see the biggest gaps today between enterprise dependencies on open source and the resources that are actually available to maintain them? We need a better relationship. I mean, you come from a Red Hat background. Red Hat kind of championed the whole model of commercialization of open source. Talk about this relationship.

Robert Nalen: Yeah, so I think what’s happened over time, and the way I visualize it, is open source was this incredible toolbox that you could go and pull things from. And when you picked one or two tools from that toolbox, it was really easy to keep up to date on those things and keep them going. We’re at a place now where that toolbox is the size of a home and the average application has roughly 1,000 open source dependencies. And so the thing that we’ve built now within our enterprises, which are all using open source, is built on this entire open source structure. And without the ability to keep that up to date, we’ve now found ourselves with a new problem statement. And it used to be, oh, I can keep these two pieces up to date, no issue. It’s really hard to say I’m going to keep a thousand pieces up to date. And it’s impossible to say I’m going to keep these thousand pieces up to date while still trying to build great features, while trying to maintain a business and while dealing with the influx of security vulnerabilities and issues caused by AI. And so that to me is where I don’t know if it’s a disconnect as much as a changing environment. Right. Like one day there was no street lights and then another day there were streetlights because there were so many cars. For me, what I see, and I view HeroDevs as sort of like a Red Hat 2.0, is that support on that long tail of open source is going to be imperative because enterprises are always going to be pulling in the latest and greatest open source and then they’re going to be using that build for quite some time. And so this to me is a new pillar that needs to be sustained and built up within their infrastructure.

Swapnil Bhartiya: There are a lot of organizations who are relying on end of life open source software. What should they be doing right now to reduce security and compliance risk while they modernize? Of course they work with you. That is the easiest answer. But in general, how they should also internally prepare before talking to you folks.

Robert Nalen: Yeah, I think the biggest piece that they can do is get to that level of identification. And this is where for the longest time there really hasn’t been a central hub of open source. And again, this is where I think the world’s changing. You’re starting to see more titles where it’s open source leader, Director of Open Source, because folks are starting to realize this is a major element of what we’re doing. It’s just not under engineering, it’s not under application development, it’s its own entity. And so the first piece is identification. Pull together all of your teams, understand what is the big landscape, where’s the low hanging fruit, where can we do minor bumps to get to supported versions to make sure that we don’t have to make a drastic change in order to remain compliant with internal standards or with those compliance and regulatory requirements that we highlighted. Getting that visualization is always the best thing to do. And then with someone like HeroDevs, we can say great, these versions here, these packages, these dependencies that you’re relying on, these are very easy to update. Here’s what you should do and you don’t need it. These large frameworks though, this is two years, this is a year and a half, this is going to be extremely, extremely detrimental if there’s a CVE exposure. This will also prohibit you from being able to pass a PCI audit or deal with DORA, CRA or NIST 2. Those ones is where you should be focusing your time on getting a subscription, getting that coverage day one, deploying the drop in replacement and then working towards that modernization. So the first key piece is identifying the issue.

Swapnil Bhartiya: You mentioned that some trend you’re seeing is that more and more organizations will actually have dedicated open source offices. But the trend I am seeing in that space is kind of opposite where we are seeing a lot of even big established companies laying off their whole open source program officers and offices because they have started to take open source for granted. Open source is actually powering this world. This may not be reflection of the entire industry. Do you feel that depending on what kind of industry you’re operating with, some industries are very, very sensitive, could be regulated, could be financial, where they don’t have room and when they do engage with open source they have to ensure that relationship is mutual beneficiary, not just of one way consumption. So what exactly are you seeing? Because at one end we are seeing a lot of layoffs are happening where a lot of open source folks are waiting to be let go. But at the other end you are saying that organization should actually hire more people who understand open source. Which one is it?

Robert Nalen: Yeah, it’s a great question. What we’re seeing and where we sit is a lot of our customers and we have a thousand plus customers. They’re in heavily regulated industries that are generally laggards as you get into the software and IT modernization. So these are folks that we’re working through and so we’re talking financial services, healthcare, fintech organizations that have predominantly been on premise, very reluctant to sort of even get into the cloud space. And so in those types of environments we’re finding a dedicated person starting to emerge that’s working with their engineering team, their CISO organization and their CTO organization in order to identify where’s open source being used. But it’s certainly not across the board in general. And I agree with you, there’s certainly a myriad of layoffs where it’s certainly interesting as to what was the driver for that. And it could certainly be this assumption that open source is just completely fine and there’s no risk. And I think over time and if people are following the news with these clearinghouses, they’re going to see that there certainly are some major developments and that’s why these organizations are being formed and they’re donating massive amounts of time and effort. I think IBM had mentioned something to the effect of 6 billion dollars and 20,000 engineers. And so this is certainly a big effort and how we view the path forward.

Swapnil Bhartiya: Rob, thank you so much for joining us and sharing these insights on open source sustainability, the risk that enterprises may run into if they rely on end of life code and that code is not maintained, and more importantly, impact of AI both sides in a good way and a bad way. I really appreciate your time and for those folks who are watching, please make sure to check out HeroDevs and solve your end of life software problem. Once again, Rob, thank you so much and I look forward to chat with you again.

Robert Nalen: Thank you, thank you so much.