From Frustration to Innovation Application Security with Francesco Cipollone

In this episode of the Entropy Podcast, host Francis Gorman speaks with Francesco Cipollone, founder and CEO of Phoenix Security. They discuss the evolution of application security, the challenges faced in the industry, and the innovative approaches taken by Phoenix Security to address these issues. Francesco shares insights on the importance of collaboration between security teams and engineers, the role of AI in enhancing security measures, and the necessity of prioritizing vulnerabilities in a rapidly changing digital landscape. The conversation also touches on the reality of cybersecurity solutions and the need for organizations to adapt to new threats and technologies.

Takeaways

• Francesco Cipollone's journey to founding Phoenix Security.
• The friction between security teams and engineering during cloud transformations.
• The importance of gamifying security objectives at the business level.
• AI can augment human capabilities but cannot replace them in decision-making.
• Organizations must prioritize vulnerabilities effectively to keep pace with threats.
• The need for a comprehensive understanding of application security beyond just tools.
• The obsession with software bill of materials may distract from core security issues.
• Collaboration between security and engineering is crucial for effective vulnerability management.
• The rapid evolution of threats necessitates a proactive approach to security.
• Understanding the fundamentals of security is essential for effective risk management.

Disclaimer: The views and opinions expressed in this podcast are solely those of the host and guests, based on personal experiences. They do not represent facts and are not intended to defame or harm any individual or business. Listeners are encouraged to form their own opinions.

Transcript

Francis Gorman (00:01.008)
I everyone welcome to episode seven of the entropy podcast. I'm Francis Gorman, your host, and I'm joined today by Francesco Cipollone, founder and CEO of Phoenix security. Hi, Francesco. How are you keeping today?

Francesco Cipollone (00:12.492)
Hey Francis, very good. Thank you for having me on the show.

Francis Gorman (00:17.072)
Not at all, not at all. And Francesca, you have a fascinating background that I'd like to explore a little bit. You're obviously, you've had the startup Phoenix Security, you're doing quite well in that space, but how did you get to the point where you identified a gap in the market that you could capitalize on and that Phoenix was born essentially? Where did that come from? Can you talk me through that journey a little bit?

Francesco Cipollone (00:40.706)
Yeah, absolutely. So thank you for having me on the show. I'm Francesco Cipollone, your Frankel friend, I tend to say. I've been in this industry for quite a while and I've seen the world changing quite much. So from back in the days when I started, I started with Cisco and Microsoft as a trainer, first of all, and then interestingly enough,

people start asking me, hey, you teach these things really well. Why don't you start doing things for us or help us with our Cisco appliance or setting up our domain controller and things like that. And that's naturally from training, it became training and consulting. And then we build some product around it. And that was my first company back in the days in Italy that I sold. And I continue doing that consultative dash product.

journey for my whole life. And during my journey, when I helped organizations like Vodafone, first of all, doing their first cloud transformation and application security transformation program, or in general, GRC program back in the days, as it was called, and then nationwide, I started seeing a path of friction where as soon as you do this transformation, you take everything that you have on-prem, you throw it in the cloud.

And you know it as well as I do that everything turns red, everything is on fire, but the program needs to deliver and security is usually left behind or it's not the friendliest talks about, hey, you have 40 million vulnerability. Maybe we should do something about that. Yeah, yeah, yeah. Let's do that when we finish the program. Otherwise, we're not going to make time. And I kept on seeing this friction over the years. I kept on seeing this discussion, not just...

during the program, but also when you start mopping up the program, it was always left out. And as a security team, we had always frustration because when we were talking to engineers, they said, it's not my priority. I have to deliver that, otherwise I get the axe. So if it's not important for your boss, security is never going to be important for you. So sometimes architectural patterns were respected, but most of the time were not. And probably when I hit...

Francesco Cipollone (02:56.738)
The nail on the head is when I was running one of the biggest transformation that I had the opportunity to run that was back in the days in HSBC where Richard called me and said, hey, can you help me off mopping up the disaster that PWC and other consultancy firm have left out because they sold them scanner.

But they didn't solve them solution. They solved them problems, So they, all of a sudden, were doing GCP transformation and other transformation, and they had, I'd say, millions of problems to fix with, and not a clue about who owns which problem, what do they have to tell, and why was important for them. So we started on the journey back in the days to say, hey, let's just talk with engineers. Let's see if we can help them at any point.

But even when we were doing excessive work, almost to the point where we saying, fix these three things, fix these four things, this is the solution, just go and implement it. They said, yes, we'll get to it, let's record a ticket, or prove me that that's actually exploitable, or prove me that that's actually a problem for me in my particular environment. And we were just dying as a team, and we were just on the...

on the low end as well because we had, I think, 32 security engineers against 7,000 developers. So we were, let's say, outpaced, outgunned, and outfatigued.

Francis Gorman (04:31.61)
And I think that that's a key piece. Like, you you're, you've got that kind of the fatigue, the security fatigue, the odd, these guys again, they're creating friction. We just want to run fast than we can in a cloud environment. And all of a sudden, you know, it works. It's not broken, but you've got all of these vulnerabilities. So that's what you're seeing. And you've got different, you know, consultancy agencies coming in, selling point solutions without, you know, they're, they're, they're on for a set piece of working under off the field. And, know, you, you're left behind with, with different issues on, on the back of that. So.

That's definitely an interesting perspective.

Francesco Cipollone (05:04.852)
Yeah, it's easy to scan. It's easy to find problems. You can find one problem, but it's difficult to say, don't fix this, focus on that, or who should do what where. That is the hard part. And that's what we kept on facing in STEMO problem. But most importantly, it wasn't just that. Engineers were not authorized to fix security. So it was just lip service. And the only method that the business had was stick.

This is the SLA that you have to hit and if you don't have to hit and if you don't hit it, you're a bad person. But so what? Nobody ever hit the SLA anytime, nobody get ever fired for not hitting SLAs. Barely anybody get fired for having a bridge these days because that's not the way to convince people. So what we tried to approach with back in the days was I sat down with Rich and I said, look, the thing that we're doing is not working.

It's not working because if it's not important for your boss, it's never going to be important for you. All the engineers are doing is following the direction that comes from the top. We need to set a standard, but a standard that is not fixed SLA. Because if we started working with SLAs, we would have killed anyone and we would have created a matrix that was not delivering any result. When you can measure something, not just because you can't measure something that's going to deliver outcome. We started saying,

I have a method, I've tested it over the years. Why? Let me try it out. Let me try it out here. If we can gamify the problem, not at the engineering level, but at the business level. So let's put all the line of business together. Let's give them objective and target. Let's praise the one that hit the target. Let's not demonize, but let's maybe call out the people that for two or three meetings, they don't hit the targets. And let's work with them to actually maybe making those targets more

achievable or understanding if they're understaffed. Let's do something that is practical, that is not just a blanket SLA because those are not delivering the result. If it doesn't work, you can fire me. I took that stance because I think it wasn't working and I think he appreciated with an executive at that level to say, hey, I'll put my neck on the line, first of all, to prove that this work. He said, okay.

Francesco Cipollone (07:32.032)
I don't, I trust you, but I don't believe you. So just go and do it. So for the next six months, we actually spent time to deciding who do we want to work with? First of all, in terms of line of business, the one that were more proactive building the tool internally. So it was a dashboard that fundamentally communicated from the application security perspective, who owns specific things and what was the risk level where they had to hit.

and then to hit that risk level, how many actions the engineering team needed to do, and how long is it going to take to get to that particular point. And then we gamified that at scale because we actually included all the platform teams and started linking the platform to which application was running on those platforms. And there were teams that were running full stack, you build, you own the platform, or there were teams that were saying...

there is a platform team and there is an application security team. So we created this world risk metrics that were separated but influenced with each other. Because if you just create SLA, the SLA are flat, but the way you solve software problem and the way you solve platform problem, patching problem are very different. They have different impact, they have different people and different psychology. So we created this system called the Phoenix Project at the very beginning.

Then it became AppSec Phoenix and then Phoenix Security in the very end when we launched back in 2021. But basically in HSBC, we created this system to actually have meetings around these are the target that we collectively have to hit. Who can hit this target? Who is hitting this target? How long does it take? And all of a sudden, this became a business problem.

business people started competing with each other because executives are extremely competitive with each other. So they always want to look the one that actually hit the target. is that psychology element that plays around. And our security team, all of a sudden we were dragged into meeting to actually say, hey, you help John to actually achieve his target faster, identifying the path or the things that could achieve those things faster. You know, the library that is deployed in 50 application.

Francesco Cipollone (09:45.462)
or the container that is running maybe 50 times. All of a sudden, our security team didn't have time because we're dragged in in meetings, but it was a different frame. We flipped the script, it was a completely different frame. We weren't asking them to do work on the side of the desk, first of all. It was in the main project. had sprint cycles or specific time assigned for security because it was important for their boss.

And long story short, when the platform started costing too much, I told Richard I go out and I build it and I scale it because I didn't want it to be constrained as well to one specific organization because I saw that everybody else had the same problem. mean, me and you had the same problem back in the days, but it wasn't just about vulnerability. And that's long story short how I started Phoenix because I think it was an important problem to solve.

Francis Gorman (10:35.088)
Yeah, no, no, that- that- that-

That's fascinating.

It is. And yeah, I suppose, I suppose when you talk about, you know, the singular problems, that library that's actually deployed 1500 times, you know, if you, you can fix that, then you're, creating a downstream impact. It's, that's measurable and far more visible than just doing point solution. Maybe off the back of that, then Francesco, what is the application security posture management landscape like right now is what are the players in the game? Who are you competing with? What's it looking like?

Francesco Cipollone (11:11.606)
Yeah, I think from when I started, that's a great question by the way, when I started...

The concept of application and deployment or the concept of cloud and application security was two different concepts. CSPM or cloud security partial management and ASPM, application security partial management, or back in the day was even called ASOC, application security tooling and orchestration was very different. You had a cluster of tool around, you had...

application not living in the cloud so much. The container problem was just starting to appear. And that was 2019. Now, you take it to 2021 is when critical mass of cloud transformation start hitting, COVID start hitting. So a lot of business had to go digital very quickly. And then on the consequence of that, you had more supply chain attacks because everybody started building their application.

in a very low code way, in a very quick way, and that starts showing up with attacks later on. You had solar wind, you had several supply chain attacks as we see in them now. But most importantly, the application security team and the cloud security team start converging, and the converging point was container. And container is a difficult beast because they're built in layer, they usually run by a team.

but build from another team, you need to understand where the application lives and why you can fix inside the container in the layer of the OS layer and why you can need to ask basically the team that maintains that container to actually fix and in their build file where the application get built or in the container declaration file where the container comes from. But you need to trace basically which application runs where. And that's where a lot of organizations right now are stuck and are...

Francesco Cipollone (13:09.23)
trying to handle and that's one of the things that we build with Phoenix that is called reachability analysis. They basically look at what you build and where you run it and try to fix that container problem. I don't think we fix the container problem altogether, but we are approaching critical mass with six or seven techniques to reducing basically the noise and to propose remediation. And I think we're doing some exciting work with agentiK AI to actually create

logical base remediation for the team that actually look at a group of problems.

Francis Gorman (13:44.326)
I was going to ask you, have you gone down the path of AI integration yet? Like the masses have, and are you seeing a value proposition come out there or is it just, you know, great to have in terms of a marketing term?

Francesco Cipollone (13:58.406)
We had AI before AI was cool. So we had AI to profile basically application on the technology stack. We had AI for similarity analysis. And we had, we have AI to actually trace and profile which application get built on the build file. And then we do a matching profile on the container file so that we can do this matching agentless and not touching the container, not touching runtime, because those are very intrusive.

and is very heavy on the machines and you need to handle a lot of data and sometimes you don't want to give all of your data to a third party company that may be secure, maybe sometime it might not be secure at some point. So we try to minimize as well the number of data, the amount of data that we have from our client perspective. Having a security mindset.

Francis Gorman (14:48.722)
Yeah, that is definitely becoming more of a concern for organizations, especially as the different sprawls of AGN and AI pop up in all of the different SaaS platforms that people are consuming. It does bring me to a question around automation and the human element though. How do you, in your view, balance that automation aspect with the human element in the security decision-making that underpins a lot of these things? And you know yourself working in large organizations.

Sometimes people take perfectly good applications and infrastructure and modify them or customize them past any level of recognization that, you know, if you were to make a change, it would fundamentally undermine what that thing is supposed to do. Whereas the automation aspect looks for patterns and, you know, similarities, et cetera. Have you seen any nasties there or is there still a role for the human? Is there some stuff that you can automate seamlessly and other things that need

proper intervention or a man in the middle type of a lens to validate that the decisions being made don't create operational impacts.

Francesco Cipollone (15:55.246)
I'm going to always answer this question with one answer. Use a tool like a tool otherwise you become the tool. So long story short, I don't think machines can replace human, but human with machine will replace human without machine and automation. So your security engineers with LLM or augmented information,

or refined set of information will be 10x, the engineers that actually do everything by hand, want to build his own dashboard, still work with spreadsheet. If you work in 1999 with spreadsheet land, then you're to be replaced by the junior engineers that work with LLMs and work with optimization. That's the kind of profile of person that we're working for our agentic module to not replace the human.

but augment the human and give them very refined information because what machines are great at is dealing with tons of information, tons of correlation. But what machine is not good is painting a picture from a risk perspective, convincing the executive, talking and understanding the challenges that an engineer has at that particular point in time. No machine can replace that. So I think the next era is going to be maybe losing a little bit this hype that machines can solve all of the problems.

and will be really mentionized this problem and saying, hey, let's use technology to actually augment our capabilities and deliver a program with our human aspect enhanced by technology, enhancing by these agentic module to resolve a problem, not just having this module to do the work for ourselves. Because I think I've seen a recent study that machines and LLM modules are wrong 80 % of the time.

So you need to use, and we are a massive user. So every workflow inside Phoenix is AI augmented, either with external tool or with our own tool. So a massive believer on agentics and modules, but not with a blindfolded way. And I start seeing this creeping up because LLM or automated code generators are now proliferating and I'm a user of it. So, but I'm a user with...

Francesco Cipollone (18:15.534)
criteria. So I see what the suggestion they give us and then I apply it and I'll ask specific prompt of like, can you generate a particular piece of code securely? I understand that then that particular code needs to be deployed and it's to have compensating control. What a code generator can give you is a perfectly safe system to operate in, is a way to deploy securely, is a way to remove things. They can produce a piece of code.

But is that code secure? Is that particular code will be run securely in a secure environment and with security principle? Any other than won't be able to give you that. So we still see in the new generation of no coder or vibe coding or YOLO coder, as I call them, of like taking a piece of code, committing it somewhere because AWS and any other cloud provider right now want to capitalize on people.

using their service because they don't care if the service is secure or not secure. They just want you to run more things in the cloud and spend more money in the cloud. So if you can remove the friction and saying, hey, you can just write a prompt and it give you a perfectly safe website, that's probably not the case. You can get there by using the LLM to say, can you generate me a front end? Can you prevent me from the top 10 OS attack? Can you prevent me from buffer overflow? Can you give me instruction?

on how to handle identity, but you need to understand how a system work. You can't just ask those question out of a spreadsheet or out of a YouTube guide module that says build your website in three days and get it bridged in the sixth.

Francis Gorman (19:54.96)
Yeah, this is the second, and this has come up on the podcast series around the knowledge gap. Chris Davis on, he's the chief hacking officer for River Security, a couple of episodes back. And he was speaking about, you can run a tool and you get root and you're delighted, but why are you root? Do you understand the fundamentals of how you got there or did a tool just do everything for you? And I think that kind of encapsulates where we are with agent-based AI at the moment.

people are creating all sorts of things, but they fundamentally don't understand what underpins that creation that they've made, know, the code, you know, as you said, the logic, the backend, the parameters that allow you to integrate with downstream systems or whatever. So I do think we have an interest in a couple of years in the security world ahead as, you know, people take maybe shortcuts to, you know, deal with the friction. The new guys come in and he's all geared up when he's AI stuff. Maybe I'll...

do a bit of acceleration myself, know, before he replaces me. And all of a sudden we might start seeing different types of Frankenstein code or applications appearing in enterprise environments if we're not careful. So, yeah.

Francesco Cipollone (21:06.83)
We start seeing that already. We're seeing, well, the next generation of SaaS application, think, why Combinator said 25 or 30 % of their new generation of startup has 95 % of code completely vibe generated, so completely automated and generated. That might have been a marketing statement, but we start seeing the user LLM or malicious LLM to actually generate exploit, to actually explore.

unexploited vulnerabilities and produce code. So we need to understand that as well. We are not the only one who have access to LLMs, but also the attacker have access to LLMs and they are augmenting their capabilities because they have financial and monetary interest to actually create damage. So they're going to use every single possible methods to actually make that cash going and they're around somewhere going, shortening the attack framework. So

prioritizing your work and using technology like Phoenix or like any prioritization technology is not any more nice to have. It's a must have if you want to survive because I think we're seeing a tag being implemented, exploited in three days, in three minutes sometimes. So I think that was one of the CI-CD tool, IntelliJ. The exploit got, from the time it got published,

To exploitation, took three minutes. And right now it's taking 295 days to fix a critical vulnerability.

Francis Gorman (22:37.212)
Yeah.

Francis Gorman (22:41.596)
So let's talk about that. So the length of time it now takes. that is a stark reality. If someone can create and publish something in minutes, but operationally it takes days, months, years for an industry to get on top or an enterprise to get on top of a vulnerability and attach it. means prioritization, a critical aspect of enterprise security.

A lot of enterprises have geared up threat intelligence teams, know, they do threat hunting, et cetera. This is an abstract lens that even sits below that. Again, it's pulling out those libraries that can be exploited. how do you, in terms of prioritization, how do you believe companies should think about risk in that context of that new world, that speed to market for a bad actor versus the ability of an organization to get ahead?

Francesco Cipollone (23:35.662)
That's a great question. And I love the fact that you bring up threat intelligence because as an industry, we are obsessed with the latest threats, but 85 % of attacks are using all threats like expose. We still have VLOG4J. We still have VLOG4J spread across, Spring4Shell, Heartbleeds. You don't need to go and explore the latest threats. Yes, maybe it's to hit the news. You can fix it immediately.

Francis Gorman (23:51.782)
We do.

Francesco Cipollone (24:05.778)
I think today the Kubernetes cluster things hit the news. You have tons of Kubernetes exploited and exploitable, but you still have unpatched Windows. You still have Windows 95 running. You still have system 200, Windows 200 running with remote code execution, unauthenticated access that is widely exploitable and widely weaponizable. So let's try to get to the low-hanging pro. That's one of the mission that we have in Phoenix to actually reduce at scale

the attack surface so that fundamentally the things that you need to cover is the crown jewel. And there you can focus on the new method of attacks because an attacker is not going to exploit a zero days for you unless you are Coinbase like we've seen with the latest TJ action to be exploited at scale or you are a system that is implemented in a lot of other system like SolarWind attack where those things...

the attack at burn a zero day because a zero day costs million because nobody has access to it and it's still hidden in the wild. You have a good chance, but it's sold for millions. As a nation state, you have the cash to actually do that, but you're to do that to actually get the money for your next missile launch attack or things like nuclear reactors are doing. You're not going to waste it to a lot of organization unless you can weaponize.

So we have a threat intelligence module in Phoenix that understand the likelihood of ransomwareness of a specific attack by, and that's where we apply the agentic module, where we understand the characteristic of your vulnerable. And we say, these things have remote code execution, zero access methods. So the likelihood of something like this to be exploited by specific threat actor is this one. So maybe instead of shift left, can patch left.

Francesco Cipollone (26:02.402)
Can lose the camera?

Francis Gorman (26:04.05)
Makes it makes a lot of sense. So does Francesca makes a lot of sense. So in terms of that, you touched on something there, which is the software aspects. How many organizations do see to have a software building materials in place? Is that a gap that we really need to start prioritizing across different organizations?

Francesco Cipollone (26:24.34)
I hate the pillow material.

I had the of material question because I think it's an obsession by industry that... Let me explain a little bit. I have a podcast with Steve Springer that is one of the creators of the bill of material, but the purpose of the bill of material was to gather asset inventory and software asset inventory. All of a sudden, it became the obsession of...

creating SBOAM because there was a regulation behind. But the objective of the Bill of Material was to say, you have this library, you can take this library, you can risk assess some of them, that's why the VEX was created, all the vulnerability exchange Bill of Material version that says, you have this library, this is not applicable for me, this is not reachable, and so on. But then you start seeing CBOAM or PBOAM,

or any BOM really. So, Bill of Materials or Asset Inventory was the things that we were trying to solve with Bill of Materials as an industry. Which part of this software is running in your application? How do you define an application? So, I think we're beyond Bill of Materials. We should understand how applications are composed. And with Phoenix, we have automation and suggestion tool to actually give you, you have this repository that is touched by these people.

They have these common characteristics, so maybe you want to put them together. You have these applications that are running maybe on this system because we can identify container image so we can trace which container get run from where or which repo get run in which container. So it's understanding who needs to solve what that was the original purpose of the build material and unpack this beast of application to actually have asset inventory. And Steve is an asset inventory guy.

Francis Gorman (28:15.792)
That's brilliant. I love that. I kind of want to ask you what else in the cybersecurity world needs a conversation that we need to peripherate out to the media now based on the back of that. Anything else spoken outside of software builds and materials?

Francesco Cipollone (28:33.706)
Aside from software and material, think, well, we haven't solved the asset inventory problem, first of all. We still have a problem with inventory, with understanding who needs to do what where. That hasn't gone away. We have very advanced clients that have brought two or three blogs in our website to say how we solve this with Phoenix at scale, how we ask engineers to produce

their bill of material, their product bill of material in a file and include that as part of a gating process as a not security quality, but as an engineering practice quality. Tell me who is touching this particular set of code or this repo, who is maintaining. Do asset inventory from a software perspective, but without bugging them on, you need to log in service now, you need to declare every single thing because those things weren't built for software.

and you kill engineers if you do that. So we build, for example, an integration with Backstage to track, to go where engineers actually track this information. We built what we call AutoConfig that is basically a declarative YAML-based CMDB where you can embed those things inside your repo. You can declare it as an engineer. You don't even have to touch Phoenix. You can just provide that or a link to that particular element.

And as a security team, you can say, if you don't have the Phoenix declarative YAML file, you're not going to pass a security gate in your CI-CD pipeline. So it's trying to meet engineers where they are to remove the friction and basically have them declaring what is the problem. Sorry, what do they own? And then we can attach all of the vulnerability that are linked to those things and say,

You own this particular set of vulnerabilities. Now, let me suggest what are the vulnerabilities that you need to address. As an industry, we've been selling silver bullets. Unfortunately, every vendor on earth comes to you and say, have the magic one that can give you everything for free. Unfortunately, as a practitioner, we know very well that that's not happening. We say, we have technology and AI that's going to help you accelerating, but you need to do a little bit of work.

Francesco Cipollone (30:59.278)
to get all of the work done and you can collaborate with engineers. Call me mad, but I still believe they're not going to sell to everybody the magic wand that's going to give them the asset inventory, but we have a way to automate and with a little bit of work, you can get the problem solved because we solved it at scale with several of our clients with I think 2000 to 3000 application running on service and reducing. I think we started with some of them with 13 million vulnerability. We ended up

with sub million vulnerabilities to solve and 100 critical rather than millions of critical. So.

Francis Gorman (31:36.55)
Yeah, I think if everything worked like the vendor demo, life would be so much easier. I think it brings me back to analogy I heard years ago when we got sent to a marriage course before we got married, myself and my wife. And the guy there, he said, said, he said, there's only one thing I need you to know. And he said, there's your expectations of what married life is. And then there's the reality. And I think you can apply that to cybersecurity vendor world as well.

Francesco Cipollone (31:50.311)
Hahaha!

Francesco Cipollone (31:59.982)
I love that I'm gonna steal that.

Francis Gorman (32:04.144)
My expectation of what this thing is going to do when I actually deploy it, what it does is always two different things. So look, Francesco, it was a really interesting conversation. Thanks for coming on the show. I think we're up on time, so we'll leave it there. But I really appreciate having the chat and it was really wonderful to talk to you.

Francesco Cipollone (32:23.258)
And Francis, thank you very much. And everybody, if you want to know more, we have podcasts, episodes running, we do a lot of knowledge sharing and knowledge base. So visit phoenix.security. I'm on LinkedIn as well. So hit me up on LinkedIn. I'm quite chatty and quite active and quite opinionated. But we also share a lot of threat intelligence.

Francis Gorman (32:41.45)
We'll make sure people check it out.

Excellent. Thanks, Francesco. look, if anyone wants to tune in over to Phoenix and get a look at the content over there. Take care.

Francesco Cipollone (32:52.674)
Brilliant. Thank you very much, Francis. And stay safe out there.