OWASP

With almost every transaction being done through the internet, your personal information and finances must be protected at all costs from hackers and scammers. Therefore, cybersecurity is important now more than ever. Leading the charge in keeping the digital world safe and secure is OWASP, a non-profit organization working mainly on software security. Joining this episode is Sam Stepanyan from the OWASP London Chapter who emphasizes why cybersecurity must be accomplished at the start of development, not as an afterthought. He also explains why education on cybersecurity is severely lacking and what should be done to make it a staple subject in schools.

---

The Current State Of Financial Security

Welcome back, everybody. It's before Christmas here in London. I have a fellow Londoner with me. He’s not originally from London, but we have a great opportunity to go down a bit of a security rabbit hole with Sam Stepanyan. Do you want to introduce yourself?

My name is Sam. I'm an OWASP London Chapter Leader. I was also elected to be on the OWASP Global Board for the past year. My OWASP roles are all volunteers. It’s an unpaid position because OWASP is a non-profit charity. In my daytime, I'm a cyber security contractor. I usually work with the financial services sector in the city of London, helping organizations to set up application security programs to secure their software development lifecycle training developers and secure coding, and protecting their web applications using things like web application files. That's me.

You have a pretty long career in financial services. This is the question that my mum would probably want me to ask. Do you think that the general security situation, when I say that, I mean everything from hacking to online fraud to phishing, do you think it's getting worse?

That's an interesting question and I think the answer is always it depends. It depends on where you are. For example in the financial services sector, the situation is not as as bad as it is everywhere else. One of the main reasons for that is regulations because of different regulations and standards. The things which are driving the improvement of cybersecurity and the financial sector, and almost every few years we have a new piece of regulation that the financial services institutions have to comply with.

For example, as January 2025 is almost here, we have a new piece of legislation or regulation called the DORA which is an EU regulation for financial services institutions. I know a lot of companies are spending Lots of money, effort, and resources, trying to comply with DORA. As if that is not enough, we’re going to have another piece of regulation called CRA, which is coming in two years as well, which will introduce even stricter rules.

We had GDPR and I feel that it helped a lot in the past few other pieces of compliance. In the financial services sector, because people always have to comply with regulations, they pay more attention to cybersecurity issues. For example, if we look at let's say startup sector, my experience was startups usually don't want to know about security at all. They are only interested in making a minimum viable product for which they can present to investors and get as much seed investment as possible to move on. I think it depends.

If you also look at the other industries, not necessarily startups. If you look outside of financial services. If you look, for example, at some of the utilities, you'll find very fragmented pictures. We’ve all heard stories of hacking of utility companies every single day. There's a story about the power grid going down and water utility being affected or the Colonial Pipeline in the United States a few years ago when they got hit by ransomware that stopped all the petrol stations across the United States, and then when they started digging, they figured out they had almost zero cybersecurity. They never thought of it like this. It’s like, “We are pumping petrol. Why do we need service security?”

Cybersecurity practices nowadays find it harder to defend automated attacks because they are being cracked by AI.

I find it very fragmented. With things like AI coming into play now, it makes the attacks more sophisticated. A lot of people ask me, “What do you think about AI?” I said, “AI is a double-edged sword.” Defenders can use it to defend, but attackers also use that to attack. Very recently, I was speaking with another colleague. We were discussing things like denial of service attacks and things like captures, for example, and how much more difficult it is nowadays to defend from automated attacks because captures are being cracked by AI.

It’s interesting. The last few that I've done, I've been like there's going to be a modern version of tools that's going to be able to defeat this. Possibly now, I didn't go ahead and get to try it, but it's ironic. I studied AI a long time ago and we started doing tests a lot. Every time one of those pops up, it's a living and breathing insurance test. I think everyone has accepted now that it is a very bad definition of intelligence but it's the thing that is quite often what will let you through onto a service. My gut feeling is that the attackers are going to be better at using it initially than the defenders. That's been proven for many decades. They will see the advantage before the remediation can catch up.

That's right with any new technology.

All About OWASP And What It Does

Let's jump back a little bit. There’s a lot of stuff I want to cover here, especially what you touched on about startups and stuff like that. It is interesting. It does seem to be a function of cost, attention, and energy. It's not like this complicated thing. If companies can afford to spend time money, energy, and effort on this stuff, then they can get secure, and my bank account is secure. I see and feel that. In terms of how arrived at OWASP, for those who don't know, can you give the listeners a brief overview of what OWASP is and why they should know about it if they have anything to do with building platforms or technology?

That's quite an interesting journey in my job. Originally, I was an application developer. My journey started with being a developer. Back in 2005, I was working with a team of developers who were working on an e-commerce product, which was taking credit card numbers, then to my horror, I discovered that credit card numbers were stored in my sequel database in plain text and now encrypted.

I was reading one of the computer magazines back then, I think it was Computer Weekly, which said that there's going to be a new standard called PCI-DSS or Payment Card Industry Data Security Standard. That standard required any company, that takes credit card numbers, among lots of other things in securing their infrastructure and their operations, to perform either a secure code review against that list of OWASP Top 10 risks or install a web application firewall.

When I saw the abbreviation OWASP, I had no idea what it was back in 2005. I had to google it and discovered that this stands for Open Web Application Security Project. Back then, that is what this abbreviation meant. Last year, OWASP changed the meaning of W from Web to Worldwide because we are an open web.

It is a non-profit foundation, first of all. It's Incorporated in the United States. It is a charity. This is what they call in the United States as a 501(c)(3) non-profit. It is an educational charity, which aims to improve software security for everyone. OWASP does it through several things. First of all, OWASP is a huge community worldwide that operates through chapters. I've been one of the London chapter leaders for the past nine years, but there are chapters all around the world. In the UK, we have quite a few chapters as well. There's a chapter in Manchester, Bristol, Cambridge, Reading, Birmingham, Newcastle, and Edinburgh. These are just off the top of my head the places I can remember.

That's the community. The community chapters organized chapter meet-ups. You participated in one of the meet-up events. The second big thing is projects. OWASP creates a lot of content through projects. These projects can be standards, guidelines, cheat sheets, but also videos. OWASP creates a lot of video content as well. We also organize global conferences. There are three major global OWASP conferences per year. One usually in Europe area, one in the United States, and one in Asia. For example, last year, we had conferences in Lisbon, San Francisco, and Singapore. In 2025, we're going to have a big OWASP global application security conference in Barcelona in the last week of May and then in Washington DC.

The way how OWASP currently operates in the USA conferences is alternating East Coast and West Coast. When we have a global conference in San Francisco, we capture all the startups and all the new tech. When we had the global conference in Washington DC, we captured the White House and US Government. People from organizations such as NIST, the president's cyber security administration come and attend our conferences. They speak, present, and network with about 1,000 attendees who come to these conferences.

‍

That's generally what our space is. It's a great community. Everything that was produced was free and open-source. To repeat the words of President Biden’s cyber security adviser, the lady who came on stage in Washington, DC. She said, “Thank you, OWASP for saving the world for the past twenty years.” Everything you produce is free and open source. It's a horrifying thought to imagine what the world would be today if everything that OWASP produced had stayed behind a paywall and not accessible to the general public.

Because everything we produce is open source and open to everyone else, we’re open to everyone to collaborate and contribute. That’s what I think makes OWASP quite a unique organization. It's also very friendly. This is what I've discovered because before I joined OWASP, I thought this was some mysterious organization. That was in 2007 or 2008. I was coming as an attendee. When I went to my first OWASP double conference in Hamburg, Germany, I met the board and I met everyone. I was like, “This is such a great community of amazing people who donate free time.”

They volunteer their spare time to work on open-source projects that will make the world more secure. Their main project is dedicated to the security of all the applications. What other people don't realize is that applications are everywhere. It's not just web apps, mobile apps, or cloud apps. We were talking about AI earlier. AI is also a software application. We now have OWASP top 10 for LLM and quite a few new projects on AI. If you are an organization that wants to start to figure out how to do AI security, I urge you to go and check out our OWASP Top 10 for AI open-source projects.

The Rising Concern With Cybersecurity

It’s interesting that you’re talking about that. The XKCD Nebraska Comic comes up on this podcast almost every time we record it. It's interesting because you were talking about petrol stations being taken offline. There was a hack. In the UK specifically, there was a very big one against CNHS relatively recently, the British Library, which is a fairly significant institution. That was obliterated from a digital perspective for many months.

It seems somewhat farcical. There's a Nebraska cartoon element to this in terms of the world relying on people like yourself and your peers to donate their free time and ask for sponsorship and stuff. We have real viruses. We have the World Health Organization and they have these huge palatial-looking offices in international cities. It feels like we're almost at that crossing point or there within the same margin of significance in terms of cybersecurity in comparison to medical healthcare security, especially in the context of COVID. Did you ever pinch yourself? I'm sure the British government and international governments around the world are going, “We need to provide our 0.1% of GDP to the World Health Organization. There isn't a corollary for cybersecurity. Doesn't that seem a little insane?

It is insane. Unfortunately, there isn't. It's true not only about cybersecurity but generally about open source. If you remember, one of the largest cyber security supply chain incidents recently was the whole Log4j, Log4Shell incident. Log4j is a login library. That's when the XKCD cartoon that you mentioned came up. People realized that two dudes in Nebraska were maintaining this library on which hundreds of millions of software applications, and also things in the hardware device and IT devices that they depend upon and they had almost zero funding.

I think it's a problem with open source, not just for cybersecurity. For cybersecurity, you are right. This is why OWASP is there. We are as always trying to fundraise as much money as possible because it's for the common good. For everyone listening to this podcast, if you are using OWASP projects, and I'm sure that you are using all these projects, at least OWASP’s top ten, which is our most popular project listing, the most prevalent vulnerabilities. If you can donate funds, that would be awesome.

One of the things that I started approaching companies and talking to them about is donating the time of the employees because if you’re using any OWASP project, donate one person per week for half a day on Friday afternoon and ask them to work on any OWASP project of their choosing, whatever you want because that will help everyone and not just here.

Does a project have a political agenda in regards to that side of things or does it try and stay out of that world?

‍

Transition From Application Engineer To Security Consultant

There's no political agenda whatsoever. OWASP is a completely vendor-neutral and politically neutral organization. We essentially provide an umbrella for open-source projects to come together and network with like-minded professionals from all over the world. Let's go back to what you are starting to get. What was it specifically that interested you in moving from an application engineer to a security consultant? Was there a specific project or security vulnerability? How did that happen?

That was the PCI-DSS that was a credit card encryption saga because up until 2005, when I was a developer, I wasn't thinking that much about security. I think from 2004 to 2005, we’re probably one of the records in terms of data breaches involving payment card numbers. This is when I realized when I started looking at security aspects and trying to secure the commerce application, how much more attractive is that world to me. I made that a crossover from development to security and never looked back.

Working in cybersecurity allows you to constantly stay updated with new threats, new vulnerabilities, new techniques, new hacks, and new data breaches every single day.

Every day is amazing. We have to learn something new. This is where cybersecurity generally is such an exciting area. You have to constantly stay on the ball. You have to constantly stay updated on new threats, new vulnerabilities, new techniques, new hacks, and new data breaches every day. There isn't a single boring day and it's impossible to learn everything. It's an amazing world. People who are in there are all very passionate. They are very dedicated. Since I made that crossover, I never regretted it.

Do you work a lot with developers?

We try to help them understand security issues because this is our main problem. A lot of people in our industry come from development and engineering. Some people come in from other areas. For example, places like help desks. Some people who work at the help desk trying to answer people's problems are like, “This sounds interesting. I should learn more about it.”

Effective Use Of Security Frameworks

If you're talking to an application development team that wants to improve its security stance, it feels to me that a lot of the problems that application engineers have, I've been guilty of this as well, is that they always see security as not a thing that continues through the lifetime of the projects. It's not something that you necessarily consider at the start of the project. It's not that exciting when you start writing codes, and things like that.

You think of it as maybe tacking it on at the end. If you're making an effort, you might have someone look at doing a penetration test for your application and then take some remediation steps. How do you go about advising teams in terms of the best practices in the most effective way that they can make use of tools at OWASP, make use of security aspects of the frameworks that they're using, and things like that?

What you are describing is exactly the problem because a lot of organizations add security at the end. The problem with adding security at the end is a huge cost because the cost of fixing vulnerabilities discovered by let's say penetration testing before you go into production is huge compared with if you pay attention and start paying attention to security from the beginning. This is why there are concepts such as security by design, which is quite important to make sure that you incorporate security from the very beginning.

OWASP has quite a lot of free and open-source projects to help in the journey. We always encourage developers to start from the design phase. We have lots of projects that can help you in this journey. One of the projects that I recommend you take is called OWASP RAT or Requirements Automation Tool. It is a tool that generates security requirements. You describe what you are trying to build and it will tell you what security requirements you need to add. That's number one.

The number two thing that you can use for your security by design is something called OWASP User stories and OWASP attacker or abuse stories. These are the stories that you can inject into your agile backlog. You don't even have to think about it because the problem is when developers are focused on a particular task, let's say you need to code an application which is a login screen. The developers usually will have a requirement. There must be a login screen with a username, a password, and a submit button. If they use the correct password, they should be logged in. If their password is incorrect, there should be a message saying, “Sorry, your credentials are incorrect,” and there's a button to reset the forgotten password.

However, with OWASP abuser stories, some stories can be injected into the backlog saying, “As an attacker, I can grab a database of previously stolen credentials from the internet and run the brute forcing attack or password spraying attack against this login screen.” That instantly makes the developer think, “We don't have any defense against that. What do we do?” Without such stories, developers will not even think about adding security because they have requirements. You push the button to log in if the credentials are correct, or the user cannot log in if the credentials are incorrect. They will never think about any attacks, which can happen on the login screen.

For this, we do have these resources. For example, the attacker stories are coming from another very awesome OWASP project called OWASP cheat sheets. If you are unaware of them, this is a relatively unknown project but it's probably one of the best OWASP projects. We have cheat sheets for every single situation, like how to do authentication, how to do authorization, how to do cryptography, and how to safely work with APIs. There are hundreds of cheat sheets and they are compiled in such a way that they provide advice in a very compressed and compact way so you don't have to read a 100-page guideline document to learn how to log in securely. It answers your specific problems.

The next thing is things like threat modeling. Very few organizations are doing threat modeling and OWASP has a lot of projects designed to help you in your threat modeling journey. Threat modeling is something that developers should be doing as a part of security by design because it focuses the developers' thinking process around security, or what we call the security mindset. Usually, developers don't have it. What the threat modeling tries to answer are four questions. Number one is, what are we building? You need to know exactly what you have.

The second question is what can go wrong with what we're building? Question number three is what are we going to do about it? Are we going to defend if this attack happens? Question number four is to do a good job. That is the threat modeling process and if these four questions are injected, and whatever you build, you always ask them these questions, there are various ways how you can then represent your threat model.

OWASP has quite a few projects that can help you with it, including a very cute visual representation project called OWASP Threat Dragon, which is a threat modeling diagramming too. You will instantly see the return on investment because you realize that these penetration tests that you usually have right at the end will start finding fewer critical vulnerabilities.

Why You Should Invest In Cybersecurity

Is this part of the problem as well that‘s culturally larger? I think it's changing slowly, isn't it? Culturally within large organizations, it's hard for engineering teams to communicate. It's hard for them to communicate a cost that hasn't existed yet. Is that something that you come across? Have you got any recommendations on how engineering teams can try and raise that? You get these issues or these big attacks that come up and then it costs the organization billions of dollars. You roll out encryption standards across a bunch of cashier tools or things like that.

You can understand it from a board level as well like, “We don't want to spend money on that because it hasn't cost us anything at this point.” How do you go about recommending people and encouraging the project funders to put aside money to think about this stuff?

That’s a very tough question. It's not about cybersecurity if you think wider generally about the security of things. This is where companies start to compromise the security. These are interesting things that happen. I always try to make an analogy with a home security system. Imagine in your home that you don't have locks on your doors. If you've never been burgled, it's like, “Why do I need to invest in locks?” The same thing with you can put up fences. If you've never been burgled, why do you want a fence around your house? Similarly, why would you want to install CCTV cameras around your house? These are all the security.

Until the incident happens, people don't realize it. It makes it very similar to the insurance industry. Until you have a car accident, you don't think about insurance. Cybersecurity is very similar because a lot of people have this mentality saying, “Why would I be hacked, Why should I be targeted? The hackers always go after different targets and different organizations. What do I have that might be interesting?” They don't realize that it doesn't matter what you have even if you have any computing resources.

Very recently, I think one of the most popular ways of breaching is for the attackers to find any resource in the cloud that they can. What they will do is they will take it over and try to make money out of this resource by running something like a crypto miner. If you have a virtual machine or a computer resource somewhere in AWS, Google Cloud, or whatever you’re using, check out how many incidents happen with attackers not necessarily using it for ransomware but they will try to monetize it by running crypto miners and then you wake up one day, figuring out that you have a massive bill from AWS or whatever cloud provider you're using. You wouldn't have a clue of what's going on.

Even if you say, “I don't have anything interesting for attackers,” you do because again if you have any computer resources they can use it as a proxy to attack other people. Imagine getting a letter from some banks saying, “Your organization has been sending lots of denial service traffic to our service. What are you doing?” They go to court and you are completely unaware that your infrastructure has been breached. The excuse of “I'm not going to get breached” I still see this happening. This lies in education.

By making applications more secure, you will also increase the quality of your product.

More and more decision-makers in organizations are involved in cyber risks. They start thinking about cybersecurity in the same way they think about securing their homes, securing their businesses. I think this is a cultural shift. When you start talking about costs, it also adds up as a technical debt. That security vulnerabilities in your applications, at the end of the day, this is a quality issue. Not all quality bugs are security bugs, but all security bugs are quality bugs. By making your application more secure, you will also be increasing the quality of your product. That's another driver that you can use to encourage people to invest more in security.

Improving Education On Cybersecurity

Is this something that you find is being taught at an undergraduate level at times? I am old enough. When I was at University, Telnet was the way that you connected to other computers and not SSH because HHS didn’t exist. Even 10 or, 15 years later, the concept of teaching security in a software engineering undergraduate degree was unthinkable. Is this something that is happening more on syllabuses for undergrads and things of that nature?

You touched on a very sensitive subject. We speak with a lot of application developers. Unfortunately, still in the vast majority of computer science courses, undergrad or grad, the only security modules that students usually get are cryptography and maybe network security. They talked about firewalls and people getting into a file and cryptography. There's nothing about application-level attacks. If you are lucky, some universities do at least mention OWASP Top 10, which is very good.

You hit the nail on the head because it's the education, which is lacking. For this, OWASP started a security curriculum project, which can be used by universities to teach undergrad computer science students application security issues beyond OWASP Top 10 and explain to them why it's important to do a security design, and why it is important to bake security in from the very beginning of the project rather than sprinkle it on top.

‍

They're talking about the DevSecOps concept. People do the DevOps and then they add security at the end. It's very important to educate the teams that no security should be baked in from the very beginning. If your developers are already aware of how to code securely, they start by designing the products securely, they start with security requirements, and they include the security stories in their backlogs, you will see the difference. You're right that people are not taught this in universities. Going back to places like financial services organizations, that's the place where usually they have the mandate to run secure coding training for the developers. For the rest of the industry, it is still not there yet.

Quite often, regulations and compliance are things that people moan about and don't see any financial benefit from. As far as some financial services are concerned, there's a good reason that they exist. I've been with my bank for 25 years now. If you think about the security surface area that I have with my bank now with face ID, fingerprinting, and a token on my phone, it is a million miles away from reading characters or passwords over the phone to the person on the other end, which now seems comical.

Exploring OWASP’s Top 10

You mentioned that the OWASP Top 10. That's my number one resource from OWASP. For those of you who are interested in learning more about this, I would recommend reading through that OWASP Top 10 list. Sometimes some of the languages can be quite technical. There are these CVE codes and these these codes are all there for a reason.

Reading through that top 10 is such a great eye-opener because some of the application developers are going to go, “That's fine. My web framework does that SQL injection. I'd have to do something crazy stupid in Rails or Django or whatever to make myself vulnerable to a SQL injection. I'd have to go off my path and do something silly, but then there are other things in there that you'd read and there are no guardrails that the framework gives you for that because it logically can't. I've always looked at that. That's updated yearly, right?

OWASP Top 10 is usually updated every 3 to 4 years. There's a joke saying there will be a new OWASP within the presidential administration. It’s there on the OWASP Top 10 web vulnerabilities. If you look at the Top 10 list, the vast majority of vulnerabilities have been the same for the past 20 years. Those SQL injection and visualization are still there. A lot of people are asking me, “How is that list compiled?” It's compiled from data.

We go to all organizations that have vulnerability data and people who run vulnerability scanners. For example, organizations that run Bug Bounty Platforms like Buckcrowd, HackerOne, and others. We asked them to submit as much data as possible so we could understand what are the most prevalent vulnerabilities. It comes from data.

Another thing that would say, since you place the focus on the Top 10 so much, please don't. A lot of people think of OWASP Top 10 as a standard that you can be compliant with, and it’s not. There is an actual standard that you can be and should be complied with. That's called OWASP ASVS or application, security, verification standard. That's the standard, which allows you to verify if you are doing things securely.

OWASP Top 10 is just a list of the top 10 things that can go wrong. For example, in the last Top 10, we injected something that you cannot easily put a checkbox next to it to say you're compliant. That is the Insecure Design. You cannot code your way out of Insecurite Design. You have to go back to the drawing board.

OWASP Top 10 was created for a specific reason. That reason was more of a marketing. That is to bring attention to the board or the management of the organization. They're like, “I don't care about security.” It's like, “Here are the top 10 things you should focus on to be secure.” For a lot of organizations, this is what we keep telling them. OWASP Top 10 is a starting point. If you don't know where to start your security journey, start from OWASP Top 10, but do not end it with OWASP Top 10. It's just a starting point.

For a lot of engineers, that Top 10 is probably the first time they hear the name of the organization. For me, it is interesting because you read through that list and open your eyes to thinking about this stuff. Do you think it's maybe a little bit of a victim of its own success to a degree?

That's right. One of the problems is we have now the top 10 for everything. The new OWASP project has “Top 10” in the name and appears left, right, and center. We were trying to regulate that a little bit because people get too excited with the top 10. Now other organizations are trying to do the top 20 or top 25. I keep telling people that there are more than 10 vulnerabilities.

This is not the end where they say, “I've done this, this, and this. Now I'm secure.” You are never secure. If you haven't paid attention to the 10 most critical things, which most organizations get hacked, maybe you should start from this top 10 rather than saying, “What should we secure ourselves against?” That's the main reason.

I highly encourage you to go and check out OWASP Top 10 for LLM because it is there to help people start from something. It's a starting point. AI is a brand-new technology. A lot of organizations have no clue whatsoever how to secure it, how to approach securing it, and how to implement the securely. This is where OWASP Top 10 is a great starting point. I see quite a lot of international organizations make a lot of references to OWASP Top 10 for AI. There’s a brand new version of OWASP Top 10 in 2025, which has been updated. It's the most recently updated top 10. If you're interested in reading it, please go and check it out.

It’s also fascinating the class of issue. It's so interesting the LLM hacks and the things that were coming out initially that people are using to jailbreak these prompts. For those of you who don't know, there's a sad but hilarious quote that I've seen where someone's asking an LLM to pretend to be his grandmother. He tells the LLM that his grandmother works in a napalm factory. It gets to tell the user the ingredients list and method for making napalm.

That was an early classification of hacks. The large LLM providers are getting better at dealing with that stuff because that seems like a never-ending arms race of more elaborate prompts that end up with the same thing as jailbroken prompts.

That's right. This is exactly what we're trying to address with OWASP Top 10. We’re trying to explain to people what they should be prepared for when they are dealing with LLMs and the techniques that you discussed, prompt injection, and the famous grandmother hack. LLMs can introduce protection against this, but there are lots of other techniques, which people will find how to bypass those guardrails and jailbreak the large language models. It's a never-ending battle.

If you don't have an understanding of how to provide this service securely and how to create those guardrails within your organization, you say, “I'm just going to use this mode.” You've seen some interesting examples of that. I think there was a DHL where the chatbot started swearing and saying some wrong things. Another very famous case was Air Canada, where the customer support chatbot started offering free tickets, and then the regulators said they had to provide these tickets because they came officially from their service.

I saw a classic. A guy managed to get a car dealership to sell him a car for $1 with an elaborate conversation. It's funny. I guess a lot of this stuff at the moment is non-transactional. It's support requests and things like that. It's probably a matter of time before they start involving themselves in transactional workflows.

New technology comes with new risks and threats. Do not rush to implement them.

That's right. Nowadays, you have LLM agents that you can install on your machine. It will do stuff for you. They will open your Outlook and read your emails. They will answer your emails for you. They can click on the cmd.exe on your machine, type “format C,” and then format your hard drive. It can access your information if you're if you're not careful. This is already coming. This is why you have to pay attention to security.

With new technology comes new risks and new threats. You need to understand the threats. This is where everyone is rushing to implement it. Similarly, 25 years ago, web applications were the AI of today. Everyone needed to have a website. Everyone wants to have a web application. Remember how 20 years ago, everyone was rushing to have an e-commerce store? Everyone was going digital. It's a similar thing. This is where OWASP can help you. As a nonprofit, we provide free and unbiased advice and resources on what you should be looking out for and how to approach things securely.

Security Implementation Concerns In 2025

We’re coming up to the end of the year now. What are the things that you are most aware of, concerned about, or in your head for the following year as far as application security is concerned?

The most things that I see out there are there are still lots of hacks happening related to Cloud security and related to API security. These two things are getting more and more prevalent. More and more organizations are going API first or they are moving to the Cloud. No one has an on-premise data center anymore. Everyone is using the Cloud. The problem for example with Cloud-based resources is you lose visibility and you don't know how to secure them. It's very simple for an attacker to get in if there's a misconfiguration, which is one click away.

For example, when you had a physical data center, trying to break into a physical building made out of bricks and properly protected with physical security was very difficult. Nowadays, you can break into someone's Cloud simply by exploiting a vulnerability or exploiting a misconfiguration. Things like hard-coded credentials and passwords and AWS access keys are still all over the place. If you search on GitHub, the breaches of credentials happen every day.

Another very big issue is getting bigger and bigger is the supply chain security. These are the vulnerabilities and dependencies in libraries. The attackers exploit them. There are legit libraries that are being broken into by attackers who plant malicious codes. Some attackers create library names, which are misspelled with typos This is what we call a typo-exploiting attack, which is becoming more and more prevalent. Detecting these is not trivial. It's not easy. I feel like this is still getting bigger and bigger.

We have some regulations coming for the dependencies, ensuring things like software bill of materials. You should be generating a software bill of materials. We have a wonderful OWASP standard called CycloneDX, which is not only a bill of material standards for software but it's also a bill of materials for other things. For example, for your cryptography, things like your SSL certificates.

There is also a machine learning bill of materials, so MLBM. Check it out because there are open-source standards there that can help you. There are lots of open source tools available for you to generate software bills of materials to validate and manage it. These projects are available at OWASP free and open source. There are commercial projects available as well to manage dependencies.

The next one is API security because they are everywhere. The thing with APIs is the visibility is not quite there. When you click on something on the web page, if you have SQL injection in the actual functionality, you could probably exploit it. And things can be visible. When it is an API, you can't see it because it all happens in the background.

When people design APIs, they don't usually pay as much attention to security and vulnerabilities when they do something visible on the web page. You mentioned things like frameworks which are helping a lot. There are a lot of frameworks nowadays that hide the complexity and vulnerabilities. If you use them correctly, they will do things in a safe and secure manner.

There are a lot of people who break through those guardrails. For example, in things like the React framework, things are specifically named unsafe or insecure methods. A lot of people still use it. It makes it easier to catch. If you want to do things in a non-secure way, you still can but the naming of the method will suggest that you are doing something in a secure manner, and you have to provide security by using some other security controls.

Frameworks are helping a lot, but as I said, things like API, Cloud, and now we have all the AI-related stuff, things like model poisoning are becoming more and more prevalent. People do not know how to implement AI securely. It's going to be big in 2025. The decades-old vulnerabilities that I still see are still there. Someone asked me, “Sam, is SQL injection still happening?” I said, “Yes.”

In 2024, we had attacks. We had MOVEit transfer, which was a SQL injection. This is a file transfer system used by a lot of large organizations. We had the Avanti and Citrix VPN too, the largest VPN providers that had SQL injection vulnerability in their appliances, introducing risks to big enterprise sectors. They are still happening.

SQL injection is two out of OWASP Top 10. There are other things like SSRF that are very prevalent in the Cloud. If you look at things like AWS, insecure deserialization is another huge vulnerability that affects the AI world and large language models as well. There's the concept of pickling and unpickling. You unpickle things in a secure manner through the remote code execution by injecting a malicious code into an object.

There were recently a few security issues, which happened with Hugging Face open source models, where people managed to inject malicious code into an open source model. As soon as you install it, the malicious code activates from inside of the large language model.

That sounds like a fun thing to try and solve. That's way above my pay grade. You must be bored talking about SQL injections. It's a fairly damning indictment of the industry that 20 years later, there are still massive companies with their most important products being defeated by SQL injection. There are memes and jokes about it. There's a famous one about a guy with a car, and he changed his number plate to “;DROP TABLE CAR.” Those are the memes of 50 years old. We were laughing about those 10 or 15 years ago.

Maybe it's time for everyone to start to log in to their academic institutions. If you get a graduate CV from someone, there's a software engineering graduate without any security training on it. Call up the dean of the Computer Science department and say what you used. I remember it used to be like that for source code control management. I remember we used to get CVs quite recently that didn't have that. You'd ask a graduate about source code control and they didn't know what it was. It's like, “This is what we were doing.”

Kudos to GitHub who manage to make source control. It is so widespread.

One of the other things is having a culture of properly reviewing pol requests within the team. I know a lot of people think about it as this thing that is polish or whatever. I've had so many cases where someone has forgotten to annotate a method with a security annotation. That's been caught by the pol request or they just left it blank for testing or things like that. Poll request, in my experience, is a great way of doing that.

The Best Use Of LLMs

My hope for 2025 is to have something that I can plug into my GitHub pol request and have an AI doing that. That seems like an open goal for a product out there to do that. These LLMs are looking at PRs, but it shouldn't be too hard. I love that. Whoever is out there working on this, I'll pay for that in 2025. Sam, thanks so much for your time. Before we go, where's the best place for people to consume and find out about OWASP? Where's the best place for them to contribute their time?

All the projects that are open source are on GitHub. If you go to GitHub.com/OWASP, you will find all our projects there. Some projects exist outside of OWASP GitHub organizations because they're so big that require their own organization. OWASP Top 10 is a great starting point for learning. We also have an awesome project called OWASP Developer Guide. For all the computer science graduates who have not been educated in security, I would hardly recommend starting from the developer guide.

We have secure coding practices that have now been incorporated into the security coding guide. OWASP cheat sheet is the resource I'm trying to promote the most. Go and look for OWASP cheat sheet and then look at the list. Everything that you want to do is going to be listed. It will have practical advice with examples of how to implement whatever you are trying to do in different programming languages.

‍

Since we started to talk about AI and LLMs, I find that a very good use of LLM is explanation. Don't ask LLM to write a code for you because it will make up statements and constructs over the programming languages that don't exist. Ask LLM to explain SQL injection, process scripting, and deserialization, and give some practical examples in code. I find this as a very good use of AI. In terms of explanation, you can explain this to me like I'm a five-year-old or an eight-year-old. You will find that most AI LLMs including ChatGPT are very well aware of OWASP projects.

It’s interesting. Explain the security of vulnerability to me once I've paid 60,000 pounds for a software engineering degree and never learned about it.

We do need to start from the university, I agree with you. Secure coding education is highly important. The place to educate yourself if you are not educated in software security is OWASP. There are lots of free and open-source projects. Please do and make use of them as always because things become out of date very quickly. If you would like to update them, please join and contribute. Everything is free and open source.

The way the project is structured is we have project leaders or project maintainers. Their names are listed on the OWASP.org/projects website. We have around 20 flagship projects which are the most important projects that are very easily implementable and over 250 lab and incubator projects, which are the projects that have not been through the rigor of maturity validation by the OWASP Project committee. You are more than welcome to collaborate and contribute to any OWASP Project.

What I also suggest to people is if you have a security-related open-source project, don't just keep it in your own GitHub. Bring it to us. Bring it to OWASP because you lose nothing, but you will gain a huge community of over 100,000 volunteers, consuming and eager to help you out, contribute, collaborate, comment, and improve your project.

It's a great show. This is a rare opportunity for those of you working in organizations that maybe don't have a large open source on print to contribute some code that doesn't have a bunch of IP, that's going to freak your legal team out and all this stuff. That's a great point. Sam, thank you so much for your time and thank you also for all the work that you've put into the project. I look forward to seeing what happens in 2025.

Thank you very much for having me. It's been a pleasure.

Important Links

• Sam Stepanyan on LinkedIn
• OWASP - website
• OWASP - GitHub
• OWASP Projects

‍