Reinforcing Cybersecurity Beyond Functional Testing

The Full Transcript

Kavya (Director of Product Marketing, LambdaTest) - Hi, everyone. Welcome to another exciting session of the LambdaTest XP Podcast Series. I'm your host, Kavya, Director of Product Marketing at LambdaTest, and it's an absolute pleasure to have you all with us today. Today's session is all about reinforcing cybersecurity practices beyond functional testing, a crucial topic for software professionals navigating the digital age.

Let me introduce you to today's guest on the show, Olubukola Omotayo, formerly known as Bukola, Director of Software Quality Assurance at HomeTrumpeter. With over 18 years of expertise in software testing across technology, finance, and property management, Bukola is a trailblazer in the QA field.

Today, she will guide us through an engaging discussion on integrating cybersecurity practices into testing. She'll also shed light on why functional testing alone is insufficient and share practical insights for fostering a collaborative cybersecurity culture. So let's jump straight into the heart of today's discussion. Bukola, why don't you share a bit about yourself and your QE journey with our audience?

Olubukola Omotayo (Director of Software QA, HomeTrumpeter) - Hi, Kavya. Thank you so much for having me around. It's a privilege and I say a big thank you for that. Okay, so I got into software testing, and I stumbled into it, actually. I didn't even know there was a career that existed called software testing.

So I had to navigate my way around and read books, and do research until I found out that there was actually something so-called and there was a career path that looked like that. So that's how I started. I started just by testing apps, testing web applications. Just they have something to do and I offer. I can test this because I've always had an eye for detail and I like things to work really well.

So that's how I started, and so my journey from web applications got into API testing, and mobile app testing in different genres. But particularly I have dwelled a lot, a lot of years in the financial sector. Right now I'm in the property management sector, but all in IT. And I've had the privilege of being in different roles and wearing different caps.

I'm very passionate about men entering the next generation of testers and passionate about knowledge sharing, and now I'm very passionate about security and how they can be a fusion between it and software testing.

Kavya (Director of Product Marketing, LambdaTest) - Thank you so much, Bukola, for that wonderful brief about your journey. So let's get started with the questions for you. The very first one, what are some of the most common security vulnerabilities that functional testing might be missing?

Olubukola Omotayo (Director of Software QA, HomeTrumpeter) - Okay, so functional testing like we all know basically it's you want to run through the application end-to-end just trying to verify and check actually if the application of the other system under test works as required or works as prescribed However, when in the bead of doing just functional testing there are certain things that you get to miss out, for example, people are unlikely to miss out on input-based attacks.

For example, you just want to log in into an application, Website, Web, whatever it may be, or even an API. And you're not checking for SQL injections. There can be SQL injections. There can be buffer overflows. There can be cross-site scripting. Those are one of it. People sometimes during functional testing, you do not pay particular attention to authentication and authorization. Are there weak password policies? Is there a way somebody can hijack the session, are there broken access controls?

Also, there can also be configurational flaws, something misconfigured. Are there ways where default credentials have been used for certain of the components? Also, the business logic. Sometimes you do not get to sit down and test the business logic. Is there somewhere along the process flow where someone can bypass certain things? Also, data protection. Are you checking for every data that you impute it protected while in use?

Is it protected in transit? Is it protected at rest in the database? You know, things like that are a few other things. Also compliance issues. Are we looking to ensure that the application confirms to the regulations, regulatory compliance in the country of use, like the PCI DSS when you have card transactions, like the HIPAA in the United States for health, so many things.

Also you could also overlook activity login. Everything I do, or maybe not everything, everything that is critical, is it being logged? Those are the few that I can mention. So those are things that you can actually miss when you just concentrate just strictly on functional testing and you do not have an understanding of certain security features that you need to look out for.

Kavya (Director of Product Marketing, LambdaTest) - Thank you so much, Bukola, for shedding light on that. It is very interesting to know that, particularly because security issues are something that lurk, and it's unexpected a lot of times. And especially that you highlighted about the compliances that are such a big part, especially when it comes to enterprises out there.

So thank you so much for shedding light on that. Moving on to the next question. Can you share some specific examples of how testers can integrate security practices into their existing testing processes without actually requiring a complete overhaul?

Olubukola Omotayo (Director of Software QA, HomeTrumpeter) - Okay, right. I'll tell testers you do not need to get a cyber security degree in order for you to you know, get involved with security One I would like to see just get involved with security awareness Let testers in the organizations or they personally just seek out security awareness training Also, for example if you are embedded in an organization try and integrate security testing into your test strategy.

Such that it becomes part of the framework through the software development life cycle. They have secure coding practices You are also able to buy static testing. You can use tools that do static testing if you are testing the code while it is not being executed. If you can get involved in dynamic security testing also on the basics you could decide to have a security checklist such that for every application or for every system on the tester that you need to test, you have a checklist.

For example, you can ask yourself, the passwords encrypted while in transit? When it goes through APIs, are the passwords encrypted when they're in the database? For example, let me just do a quick digression. There was an application some years back that I was testing and of course, just looking at it functionally, you could put in your username and password, that was fine.

On the front end, and the password field was maxed, meaning you could actually not see the password. And then you get into the database and you can see that, okay, the database looks encrypted, but by the I was reviewing the logs, I noticed that while that the data was being transmitted via the APIs, voila, the password was right there in real text.

So those are some of the things you can add into your checklist. Check that then, is authentication in place? Is authorization in place? How about your impute validation? Check different kind of things that you, some unusual kind of impute validation. Your database, your login and monitoring, your API securities, don't, security testing, just don't verify that you get the response code and it's fine.

No, why don't you try something different? Try initiating requests with invalid tokens and see that the request gets rejected. You know, those kind of things are ways by which testers can begin to start, you know, little baby steps in order for them to arrive at that part.

Kavya (Director of Product Marketing, LambdaTest) - Thank you so much, Bukola, for those actionable items. I made a note of it. So to sum it up, you need to get involved with security awareness, then integrate security into the test strategy. That in itself seems to be a pretty interesting action item that testing teams and leaders can implement. And, of course, securing the coding practices and checklists for security testing.

Thanks for sharing this. On that note itself, just wanted to understand how did you go about building that checklist for security testing? And especially as a QA leader, how do you approach that?

Olubukola Omotayo (Director of Software QA, HomeTrumpeter) - Okay, all right. This is how that started. There's this OWASP 10 It's available online By the time I started getting interested in security by the way, the essence of security is we want to ensure that Whatever it is that we're doing the data that is involved. There's confidentiality. There's integrity There's availability and now we've even added two more two more has been added.

There's non-repudiation and then there's authorization so by the time I started getting interested and I began to you know read up that's where I got from this OWASP 10 it broke down it always gives the top 10 vulnerabilities in different genres yeah so for example you have for the web application.

So I began to read through, and then when I began to see the top 10 and broke down the different kinds of vulnerabilities from there, I began to drop those kinds of checklists to look out for so it becomes like a playbook so that each time someone is testing you can look through it and okay if what I'm testing falls into this category, these are the kind of things I need to take into consideration while I'm testing for security. I hope that answers your question.

Kavya (Director of Product Marketing, LambdaTest) - Absolutely, it does. Thank you so much. And it's also interesting to see how even small adjustments can create such a significant impact. Great. Moving on to the next question, beyond the technical aspects, how can we foster a collaborative culture within development and testing teams where everyone feels responsible for security?

Olubukola Omotayo (Director of Software QA, HomeTrumpeter) - Hmm interesting. All right one I think they had needs to be training awareness let the entire team get to understand what's at risk and Begin to let us see from real-life examples the impact of not incorporating security into the products that you churn out Just let the team get aware and by the time we can organize security awareness training between the teams.

You could decide to simulate attacks and let them see the impact. You could also have gamification experience is something to make it fun. I like fun while working So for example, you could decide we want to conduct a capture the flag exercise where the developers and the testers are supposed to you know Look around and compete to find vulnerabilities just any way to ensure that they are coming together.

You can also have joint security exercises reviews and you can simulate a breach and let's all discuss it then also importantly perhaps we can even have shared KPIs, key performance indicators. We could decide that we want everybody involved. So we want security to be part of the KPIs that is shared by everyone.

And also very importantly, in this collaboration between testers and developers there shouldn't be it should be a blameless culture We shouldn't be throwing blames around. Okay was because you didn't do this is because you didn't do that. Let's just collaborate and look for how to learn from security failures and instead of assigning blames Yeah, so those are the kind of tips at least I I can so far for to just bring about collaboration.

Kavya (Director of Product Marketing, LambdaTest) - Thank you, Bukola. That's a fantastic perspective, of course. as we hear a lot of QA leaders speak about this so much that building the testing culture is a shared responsibility. Similarly, incorporating security into testing is definitely a shared responsibility too. Yeah. And you also mentioned about the shared KPIs. If we can double-click on that, right? What do you have any suggestions for QE leaders on what kind of KPIs they should be building, especially for both development and testing teams?

Olubukola Omotayo (Director of Software QA, HomeTrumpeter) - Okay, so, for example, we could decide we want to have certain metrics tied to security, even though it could be quite subjective. But however, it gives everyone on the team a sense of responsibility and accountability because it's part of my KPI. Meaning the developer, if ensuring you incorporate security coding practices that are already given as part of the framework for your organization is part of your KPI, then you know you need to get down to that.

So you could decide to say, okay, we want to, in order for us to reduce the number of vulnerabilities is subjective, honestly, but perhaps maybe for starters, we could decide to say, the metric is tied to the number of vulnerabilities that comes out from a product that you're handling. So perhaps that way it will, you know, encourage each person to live up to expectation same way for the testers.

You could decide for products that go through you are there vulnerabilities? Are there bugs that are tied to security that were missed? So that way everybody gets to understand it's a shared responsibility. All of us have, you know, have a task to ensure that this product we good. It's our customers can be rest assured to use them and they know we're secured. Our data is secured. Our personal information won't get, you know, leaked out through a data bridge or anything.

Kavya (Director of Product Marketing, LambdaTest) - Great, thank you so much, Bukola, for sharing those insights. Moving on to the next question, with the growing adoption of DevSecOps practices, how can testers effectively collaborate with security professionals just to ensure a holistic approach to software security?

Olubukola Omotayo (Director of Software QA, HomeTrumpeter) - Fantastic question. From my experience, not all organizations have security testing embedded within the team of developers. Where in this context I'm referring to developers as the team of the developers and the testers.

Quite a number of organizations probably will have a security team that are dedicated to security However, some of the things we're talking about is how to ensure that from the start Both the developers and the testers already have security built into what they do.

So one is early engagement and which it's it cannot be overemphasized where the entire team put together the developer security operators, even the operations like you mentioned in DevSecOps already have an understanding of security paramount So once we have that early engagement right from the onset from the from the from the moment where you have a business requirement.

For example, you can sit down look through it through the design you can begin to already incorporate security into it before even coding starts so that way and like I said before, can incorporate security into your test strategy. You can incorporate security into your development framework. So that way you are already bringing everybody together. Also from time to time, for example, the experience I've had is, you do your, your product is getting ready.

You probably send it to the security team to help you do vulnerability assessments, to help you do penetration testing and things like that. There has to be collaboration. So part of what I would suggest or just is have regular, cross-functional communication and collaboration with all the teams including the security teams.

Also have use of shared tools. We have tools that bind us together Jira, GitLab, Jenkins, whatever have something where all of us have a view into it so that we all know we own this Then also very importantly is that we can also have a knowledge sharing knowledge exchange between the security team and the development team where they let us know because the developers are going about their developing business, they probably may not know when there are zero-day attacks.

Zero-day attacks refer to vulnerabilities that are new. But when you have knowledge-sharing sessions with your security team, they can begin to let you know something is out there. Going forward, what we used to do this way, or this encryption algorithm that used to work then, is now exploitable. We need to move to something else.

So those are the kinds of things that we can also they can also be threat modeling, and I really like this a lot because that means you can sit down and let's model a threat from how many angles let's look at it put myself in the from the perspective of a user, from the perspective of a fraud star, from the perspective of someone that wants to initiate an attack.

And let's model the threat so that that way we're able to also pinpoint gaps or vulnerabilities that may exist within the product. And, of course, we also have automation tools for the CI/CD pipeline. You can also do that. Just make sure that everybody comes together in order to do this.

Kavya (Director of Product Marketing, LambdaTest) - Great insights, it was really interesting because you've shared so many actionable tips that I'm sure our listeners would benefit from. Would you also help me understand more about how did you go about the threat modeling aspect of it? What was the framework that you or the structure that you went about designing it?

Olubukola Omotayo (Director of Software QA, HomeTrumpeter) - Okay, so threat modeling actually depends on the product that you are building. could decide, think through it. For example, let's say it's an app that has just been built. It's a financial app. We could decide and let's model what kind of threats, what if we have fraudsters that are trying to intercept?

What can go wrong? where can it go wrong? know, ask yourself some critical questions, and then let's begin to do it. Do SQL injections. Do you use your bop suite and just, you know, perform some dynamic testing, do pen testing, do vulnerability assessments, just put yourself in the shoes, like I said, of different threat actors and just begin to say what can go wrong?

What if it's a mobile app, and your phone gets stolen or misplaced, and somebody picks it up? What is achievable? Is the application of the product secure enough such that if anyone wants to, you know, breach it and their motor authentication such that there are certain things?

Or is it possible for someone to just pick up the app and onboard without anything external to who I am, them being available, different use cases that you can, threats that you can build and then run through it and let's see how that works? Are there vulnerabilities we can identify? If there are, then we can get back to the kitchen to go to fix some of those vulnerabilities.

Kavya (Director of Product Marketing, LambdaTest) - Great. Thank you so much, Bukola. Moving on to the next question, how can we balance the need for early security testing to prevent vulnerabilities with the potential for delaying development timelines?

Olubukola Omotayo (Director of Software QA, HomeTrumpeter) - Hmm. This is always the elephant in the room businesses always want the product to get to the markets, and they don't mind sometimes the shortcuts, but as custodians of quality and now when I talk about custody, I'm talking about the entire team, We cannot afford to have shortcuts a secured product arriving late is better than an insecure one arriving on time.

Because the long-term reputational and financial damage that can be caused by security breaches, it outweighs the benefits of a very fast release that being said, it also does not mean that we need to take into consideration the fact that we need to arrive at the market on time so that the product can have his own fair share of the market.

So what I would prescribe or offer things that we have used is a shift left Shift left tested. I'm sure quite a number of us would have heard that, and it's just pretty means let's start the testing on time do not wait until, of course, that's using the waterfall methodology you have to go through. If it's agile, whatever you know, the methodology it is that is it's been imbibed in your organization, ensure that you shift it left.

So that means you start your testing on time. I have referred to that earlier It means right from the document you are looking through it You are, you know, just scrutinizing i,t and let's see, are there any gaps in here? Then review your architecture when the design is coming up can we have a picture?

I didn't used to like architecture because I felt they were really technical and complex, but over time, I value architectural program designs a lot because by the time you take a look at it, you can actually look and see anywhere where a threat actor can permit so you can do that then also risk-based testing.

That is a perspective. Sometimes you are not able to finish testing because, okay, so the balance or the compromise is let's identify where are the risk-based areas. Let's call the business or call whoever it is that is a product owner. Okay, can we know, have a risk analysis or risk assessment of this product? Where are the risk areas?

Based on interactions also with the product or with the architecture where are the risk areas? Let's focus on that when we focus on that we may decide to look the other way if We need to get a market area because we know we would have tested the really high priority areas Also, we can also decide to run parallel tests Meaning I may decide I do not wait until one phase is over before I start another phase when it comes to security.

I may decide I want to run parallel testing. I may decide, okay, once I'm done, functional, not functional, and the product is good, perhaps we can begin to start our penetration testing or all our security checks side by side. Also, like I said, like the agile methodology, let's increment. Why not do a little now? We put, that out, do a little so that there is the balance of ensuring our system on the test, our product is secured, and it also arrives on time.

Kavya (Director of Product Marketing, LambdaTest) - Awesome. Thank you so much, Bukola, for that thoughtful answer. It's also pretty reassuring to see and hear how the balance can be achieved without actually compromising on the quality of the test or the speed of releases, for instance. Also, a phrase that stood out for me was how custodians of quality can't afford.

I think this should definitely go onto my LinkedIn post when I put this across because very interesting. Also, thanks for breaking it down so clearly for our listeners. Moving on to the next question, for testers who are new to cybersecurity, what resources would you recommend to help them learn more about essential security concepts and best practices? Of course, you have already spoken about how, you know, testers should be a part of this collaborative effort and so on. But what are the specific resources that they should look into?

Olubukola Omotayo (Director of Software QA, HomeTrumpeter) - Okay, right number one, I would say I have a good understanding of security vulnerabilities. What does that really mean? You do not need to get in-depth and like I said The OWASP top 10 It's a recommendation. It's a deal breaker for me that helped me When I was trying to understand security isn't just for networks.

Excuse me. It's also I was shocked to find out some of the figures and some of the things I read when I began to you know Make this research is to find out that There are actually a lot that I as a tester can actually also contribute to testing so one OWASP top 10. OWASP top 10 is available for different areas. It's available for mobile. It's available for the web. It's available for APIs. It's available and it's free. It's out there.

Just begin to have an understanding. Just begin to read it up. Also, you can also have online platforms that you can begin to take free courses. Udemy, Coursera. then there is this really nice OWASP juice shop that you can use for practice for common vulnerabilities. That's where I got to practice for the first time where I was able to penetrate an application and be able to exfiltrate some data and credentials.

Without even being able to log in into the application so you get hands-on and then one which I'm particularly excited about and I really like is a try hack me Track me is a gamified learning path. It's games but within the phone, it gets to teach you security. So they have different rooms you could learn about penetration testing. You rent from the basics. You've got and you can actually just graduate from beginners to intermediate to professionals.

So I would say try it out and for me the beauty about the Tri-Hack-Me is they also have area where you can practice. So you're just not going to read. Whatever it is you read, you have access to a virtual machine or area where you can go ahead and try out whatever it is you did. So you're beginning to have an understanding. You know, it's one thing for you to read. It's another thing where you begin to practice it.

And with these things, the practice becomes, you know, muscle memory where the time you begin to practice and practice. Also, it's also nice to join communities I've learned a lot by being a member of or by joining communities in the testing communities in the cybersecurity community, it's just that there's just so much out there that sometimes you need to hone your own skills and prove the knowledge.

I'm not in the category of jumping on the bandwagon of everything that comes out. I want to go learn it myself. But joining the community gives you exposure because you have people worldwide right there. Maybe if it's on LinkedIn or in those communities that can begin to give you tips from their own experiences.

Then you can also decide from tools you want to get your hands dirty with some of those tools, you can go ahead. There are free ones where you can exercise. You also have some books. But for me, I started with the OWASP 10, and I think it's the basic place to start and then the TriHackMe.

Kavya (Director of Product Marketing, LambdaTest) - Amazing. Thank you so much, Bukola, for that detailed overview and how definitely all these tips that you've shared would make diving into cybersecurity a lot less intimidating for the testers who are listening in. We are onto the last question of the day, which is, what are some of the biggest challenges software development teams face in implementing a strong cybersecurity posture relatively and how essentially can these challenges be overcome?

Olubukola Omotayo (Director of Software QA, HomeTrumpeter) - Great question. First from where I sit, I think it's an awareness gap. You don't know what you don't know. So if you do not know something exists, there's just no way you're gonna be able to, you know, everything against what exists.

So that's the first one. think many teams lack cybersecurity knowledge, many teams, and that's not to say they need to go get cybersecurity degrees or start, no just the awareness for you to know this exists. It completely changes your perspective and your approach to the way you do things.

So for that one, I would say one way to overcome that challenge would be conduct mandatory tests. I'm sorry, not test, training sessions. Conduct mandatory training sessions for the team. Let them get aware, let them sit down. Give real life examples, data breaches that have happened, the reputational damage, financial losses that came to those organizations. It was very shocking for me each time I hear some of the data breaches or some of the things that have been done by hacktivists, whoever, and I mean, or these exist So you really do not know if you are not aware.

So that's the first one is that when awareness gap also there could also be resource constraints now we're learning that this exists. How do we approach it? We do not have the resources in-house, for example, even small teams in small organizations, I go it could even be a big organization, but who ether to have never considered or prioritized security. Let me just not have so in that case.

They can start if it's, for example, a small team that does not have they can start using free tools, get aware, and then begin to see how with time, even though that may be a long time or in the immediate term, how can you get to recruit security professionals or how can you if that is something available, how do I educate my resource that I also have? Also, another challenge that I see, which we have also talked about, is time pressure.

That always exists. There are always tight deadlines. The product always ought to have been ready two weeks ago. It always, no, this should have gone live two months ago. No, this should have, face one should have gone live two months ago. There's always the time pressure. And with time pressure comes the temptation to just push security by the side. Push it to the back burner.

And so one of those challenges is I believe that an organization or a person that is big or considers security a priority needs to have a balance you cannot afford under whatever to put an insecure or non-qualitative product out there, like I mentioned earlier on, the reputational damage, think, is just, it outweighs you get into the market on time. And that also, like I said, you can also adopt a risk-based approach.

If we really do have to go to market, okay, is it possible for us to have minimum viable products that we can get to the market on time? Can we reassess the entire product and look at if there are some parts that you feel right now I need to get to the market? Okay, can we move that to phase one?

Make sure we spend time on it qualitatively and move it out. Then also it's also possible that some organizations may have legacy applications or legacy systems that when they were written, are not able to support modern security practices so in that case what do you do you just have to now that you are aware and you've seen that there is a flaw in the legacy system I have, what are the compensating controls that we can put into place?

How can we mitigate what it is in the interim until maybe you want to face it out? Although sometimes those legacy systems may not be in a position to be faced out. So what are the mitigation or compensating controls that can be put in place? So those are the few things that comes readily to mind right now.

Kavya (Director of Product Marketing, LambdaTest) - Thank you so much, Bukola. So you've really highlighted the crux of the issue, the challenges as well as the solutions. And I'm sure that our listeners would find it as very valuable advice. Thank you so much for that fantastic session. A huge thank you to Bukola for sharing her invaluable insights on weaving cybersecurity into the fabric of software testing.

I'm sure that your strategies and real-world examples have provided our listeners with tools to elevate both the security and quality of software. Bukola, any parting words before we wrap up the session?

Olubukola Omotayo (Director of Software QA, HomeTrumpeter) - Parting word would like to case studies out there are proof positive that security should be considered and taken really into consideration as a priority and Like all the things we've mentioned thus far, putting time out for qualitative products it file outweighs the reputation of damage that having to cut corners or having short cuts will gift war so that we can derive from it.

And I also like to just let testers know you can do it. There is nothing too unachievable about incorporating security tests. Just devote some time, take baby steps what you want to do and like I always like to say wherever it is you find yourself always Look for how to get better, keep learning and do the best with what it is that you are given.

If all you have is just something so small, do it so well that everybody wants to look at it and is like, if she's got her name on it, she must have done something thorough about it. Wherever you find yourself with whatever it is that you are given, do it excellently such that you proven yourself and you're in a position to take or handle bigger tasks. Thank you very much.

Kavya (Director of Product Marketing, LambdaTest) - Thank you so much, Bukola. And to our audience, thank you for your participation. Don't forget to stay tuned for more enriching episodes of the LambdaTest XP Series, where we continue to explore groundbreaking ideas in the world of testing in QA. Until next time, take care and happy testing. Thank you once again, Bukola. Have a great day.

Olubukola Omotayo (Director of Software QA, HomeTrumpeter) - Yes, thank you. Thank you. Thank you, Kavya. Bye.