Why Security Testing is an important skill for a QEs with Boris Arapovic

[00:00:00] In a land of testers, far and wide they journeyed. Seeking answers, seeking skills, seeking a better way. Through the hills they wandered, through treacherous terrain. But then they heard a tale, a podcast they had to obey. Oh, the Test Guild Automation Testing podcast. Guiding testers with automation awesomeness. From ancient realms to modern days, they lead the way. Oh, the Test Guild Automation Testing podcast. With lutes and lyres, the bards began their song. A tune of knowledge, a melody of code. Through the air it spread, like wildfire through the land. Guiding testers, showing them the secrets to behold. Oh, the Test Guild Automation Testing podcast. Guiding testers with automation awesomeness. From ancient realms to modern days, they lead the way. Oh, the Test Guild Automation Testing podcast. Oh, the Test Guild Automation Testing podcast. With lutes and lyres, the bards began their song. A tune of knowledge, a melody of code. Through the air it spread, like wildfire through the land. Guiding testers, showing them the secrets to behold.

[00:00:35] Hey, join me today as we dive into the challenge of proving why I think and Boris thinks security testing has to be a top priority for quality engineers and software testers in 2024 and beyond. Today, we'll be talking all about it with Boris on Why Security Testing is an Important Skill for QEs. If you don't know, Boris is a senior quality engineer with a passion for Agile Testing, Test Automation and one of those rare unicorns cybersecurity. Currently, he works as a director of quality assurance at IBM iX, so he really knows his stuff. I'm really personally excited about this topic. You don't want to miss it. Check it out.

[00:01:12] Joe Colantonio Hey, Boris, welcome to The Guild.

[00:01:17] Boris Arapovic Thanks a lot, Joe. Really nice to be here. I'm listening to this podcast more than one year, even though I think more than two years, and it's really excited now that I'm talking and not just listening.

[00:01:29] Joe Colantonio Yeah. I'm so happy you actually reached out to me, so I just give a shout out to that. Anyone that has a topic you want to learn about you can always reach out to me on LinkedIn. And this is one I'm really been not struggling with, but kind of stumbling with for the past few years. I used to have a separate online conference called Secure Guild, and I can never really get it off the ground because I always get pushback from testers saying, Hey, it's not my job security testing on my own team. I guess that's setting in the background. Before we get into that though, what got you into cybersecurity or security testing?

[00:02:00] Boris Arapovic In general, they just said I mean, I fully understand the concerns, for example, QAs have in terms of, I'm not a cybersecurity engineer and that's also not what I'm saying. The depth to know how that do needs is really like it's huge and it's really hard to get if you don't focus on this fully. However, what I think is that kind of cybersecurity fundamentals will help the application itself that we deliver to the client and basically also SME, as a QA, when I gain this know how, I will also be able to provide additional a quick feedback before it may be some things are shipped or maybe going to a cybersecurity company or even a cybersecurity engineer, because at the end of the day it's about customer satisfaction who uses this application, right? And we have to work and cope with it to avoid maybe some data being leaked or in general, out of my experience, this actually not even super highly sophisticated security hacks. It's sometimes super simple that every QA can do and where we can really add a lot of value in there.

[00:03:10] Joe Colantonio Now, it's a great point. I've seen SQL injection as a problem since I started my career over 25 years ago. And if you go to OWASP and things like that, it's always still a top security concern. A QA then, as you mentioned, doesn't need to necessarily be a security expert, but how do they get that as part of their work then are like, they're doing a sprint planning the definition of done, they need to do a whole bunch activities. How do they know or how do they get the teams to be aware that yeah, we're not necessarily the security team, but we could still do test cases that will help with the security of the application as we're building it.

[00:03:44] Boris Arapovic Yeah, correct. So I think there are many ways on how we as QAs can contribute. I think, first of all, it actually starts in having some static application security testing place that actually helps also the developers and when we develop code, for example, just to also detect already some security issues which might be having hardcoded password as a prime example. Trust me, it still happens. It's not that this is something like, no, this won't happen on application. This for sure can happen, but I think as a first step we QAs can help to set those things up. Maybe even consult involve a cybersecurity engineer in properly to set this up properly. As I said, for example, checking the source code, but it also might be checking the packages that you have and you know about Node.js, you typically have the NPM and when you just type NPM install, it will print out some security vulnerabilities that you will have from packages. And I would say we as QA, also should drive this together with the developer and make the developer a surveyor fit. And also kind of I wouldn't say fight for that, but make also time that we can also fix such issues because those are typical low hanging fruit when it comes to SAS. As a next step, typically when because you mentioned agile and sprints and so on. I think what we can do is, as you said, already create some test cases where we also cover some of the edge cases. Let's say for example, we implement the log in feature. When I think about the login feature, my first thought would be what about the recapture? Do we need like how do we protect it? This is like, I don't need a speed to be necessarily a cybersecurity expert to bring such perspective. And I think we as QA often have to perspective the technical, but also on the other hand, the business perspective. And this is like also think about on I as a user, how I can be protected in a way from it's really quite often really obvious security issues. And I would say that's of course the test cases, the SAS that I mentioned. And I would say also where we can bring a lot of value is in designing session based exploratory test sessions together with two teams. We have those, for example, personas that I can do. And imagine now you create the persona where you have the hacker, how hacker calls, where you can see this is the objective of the hacker, this is the approach of the hacker, this what the hacker want to do. And then you organize such a session where you have like, let's say all the typical personas, but you have also like the hacker persona. And you then just let, for example, the developer pick the persona and really think about they are now the hacker, what could they do? You could do that for example, during the release level, but you could also do that on a feature level. But I just mentioned log in for example. How could such a hacker may be bypass the authentication mechanism? Or what could a hacker do? And yeah, as I mentioned for exploratory testing, we have one path is the persona and the other path what we also as ..... could do is create charts where we could say, for example, we could create in case of the login as a hacker, I want to bypass the security restriction by providing some SQL injections or we could make it brought up by some injections. And they are like different things, but you can use there to apply it and you can be really creative and that other from experience, that's typically what the developer likes the most to test. It's not having the checklist, but it's really like having this creativity that they can play out and that really helps also to boost it. And additional point, what I want to add there is of course, we as QAs test. That's also like when we test a feature, we can bring in this perspective of course. But I think also at the moment when we have like very critical releases, very critical features that we want to release, let's say, for example, we add a new payment method within the checkout. There, we might then consider a security expert to actually pen test it once we maybe done some basic checks. And I think that's really something that that's a lot of value also from the whole team perspective in addition to that, because sometimes you really need an expert. You can't test all like maybe the tricky combinations, but the low hanging fruits, I'm pretty sure confident a Scrum team can cover a lot of those things.

[00:08:40] Joe Colantonio Alright, there are a bunch of great points you just made. The first one that jumped out on me is when I think of testers, I think of them as leaders. And so you just made a great point. They don't necessarily have to do everything, but they do need to be aware enough to say, hey, this may be a task the developer should look at. Maybe, I should reach out to the security team to do pen testing, like you said. How do you empower your testers, though, to take that on? Because a lot of times they think like, I'm in a box, I can't step outside of this box. I don't know if you have that problem. I've seen organizations where a tester is just like they feel like they're in a little box and a little vertical and they can't break out of it.

[00:09:14] Boris Arapovic Yeah. That's a very valid question, I think, how you empower them. I think, first of all, they need some education first to understand it. And typically, what we also do, we show some like real examples from our projects to see like, really guys, it's really happening. And so also on the one hand, motivate them. First, to have to know how. Again, that it's not easy. But typically, we in IBM iX, we support the people. We have an academy where they can do specific trainings to educate them so as the first step. And wants to educate. It's then also about the lot, about knowledge sharing. Between QAs, even outside of a project, this with an agency. There's like many different QAs working in many different projects, but they can exchange information. And that's also, I would say also how we motivate people to also take a look at that aspect because it's really happening on project level in general. Not even talking about our projects that we have, but just also recently taking a look on the website where for example, it was a webshop where just typed. They had like when they do something, they contact the backend API and in the backend the API, just added like a path, a random path, and all of a sudden I was logged in as a user, which I thought like really? That easy? It was like anonymous user in a way, but still. So it's really reality and we have to adjust to the reality, I would say.

[00:10:48] Joe Colantonio Absolutely. Another thing you mentioned, which I really liked, is the exploratory aspect of it. I used to work on a team. We had like 8 to 10 sprint teams, but we'd come together every quarter or every four weeks to do exploratory testing. And that's where we tended to find the biggest of the most valuable bugs. Can you talk a little bit more about that and how you get the team involved, because it is quite an initiative to tell your boss, Hey, we're going to take these developers off developing and they're going to focus on testing in a sense.

[00:11:19] Boris Arapovic Yes, that's a very good point, I would say. In general, what we do, we really try. For exploratory testing, typically you need to prepare very well, let's call it like that. At the beginning, before we even start the exercise, are we going to apply personas? Are we going to do maybe some charts, create some charts that makes sense, right? And typically, we then organize the session, let's say much in advance that there is sufficient time also for developers, to plan things in and everything. And then once we execute it, we are typically very organized. Where we have like five minutes introduction, where we explain everything and then kind of they typically used those personas. We also decide to team, like not to have all the people use the same personas to have a good mix and then they start and they have their time. And as soon as they discover something, they document it. For example, we use compliance and they document that just very briefly. And once typical, it takes one hour, maybe even half an hour. It really depends on the complexity in general on the requirements. But afterwards we then have a follow up for 5 to 10 minutes where we quickly discuss the findings. And then typically, we as a QA takes this onwards, ask questions directly to developer, if there are some questions, you know whatever the report that. And then we follow up on that. We don't want in this case we tried to keep the work as little as possible for the developers, but kind of we then take on, we prepare, we think, we like cost everything and we also take on the next steps to clarify maybe if something is really a security issue, is it maybe a new requirement that we just forgot like it could be a recapture on some login registration or something like that?

[00:13:14] Joe Colantonio Nice. I know in certain verticals like health care and financials, you can actually be in big trouble by the FDA if you're audited. If a lot of these things get leaked, especially for PII and things like that. And yet once again, those testers there, sometimes they don't do security. And I tend to see that the security team is like completely isolated from everyone else and they just get like vertex on down from the security team that shall do that. I don't know, do you have any experience with trying to break down that wall because it stills seems to be testers. Developers are now part of the same team, but yet we still have the security moments like these newbies other somewhere else that does it what it does and we have no idea what they're doing. We don't necessarily work with one another.

[00:13:55] Boris Arapovic I think as of now, I can say you like this is like the recipe that works for everything. It always depends on the project and also like how the security team misplaced and what their responsibility is. I think as of now, a solution is all the ways to kind of more when we see the need to try to involve some right based on the need, but like really to have it in a project permanently, it's really impossible. I would say when you take a look at maybe a scaled agile frameworks that we have, is it safe? I don't know, whatever the framework is, but let's say you might have literally ten or more teams working on different features and so on where you can't ask the security engineers for everything from the very beginning to be involved and so on. It's really I see a lot of companies that don't have like this big security department that you, there are typically couple of people and this is kind of the reality that we are facing. And that's why I think also why I'm also stating that we also need to gain this cybersecurity know how at least fundamentals because it's really we don't have the people all the people are ready to be able to do that.

[00:15:09] Joe Colantonio 100%. And so, my big push always is to try to appeal to someone's self-interest. And I always tell testers, maybe I'm wrong, that if you have testing skills that include security testing, performance testing, you're going to be more employable. How do you motivate a team? Like, are there any tools, techniques that you recommend people learn if they want to, like you said, learn the fundamentals. Do you recommend OWASP or any other sites where they can learn more like they had this tool on the resume or this technique, they probably would pop a little more than someone else?

[00:15:37] Boris Arapovic I think. First of all, actually I was once in the project also together with QAs and developers, where we implemented a registration and we implement the registration. And remember back then we had some UI tests running with Selenium to validate registration. And then on another sprint we added a reCAPTCHA, Google reCAPTCHA, and I remember that once we added it, I wasn't able to automate the UI tests anymore with Selenium because of the Google reCAPTCHA. But then I played a bit around with it and discovered, well, if back then with Selenium, if the JavaScript executer, if I removed HTML stuff on the front end, all of a sudden, from the reCAPTCHA, I was able to complete the registration process. And at first like I was like, yeah, I did it and said like, no, wait, something seems pretty off here. I shouldn't be able to do that. And then remember that when I was talking with developers, explaining that what I did, like bypassing the frontend and so on, I saw in their faces, I got some respect from them. The first developer said, Man, you're a hacker. You see, you also get that respect from developers when you show also such things and not just like we are testing from a functional perspective, but I think especially such things. It's also good for your reputation within the team actually.

[00:17:07] Joe Colantonio Fully agree. You also mentioned earlier adding static like security scans when developers checking code. Do you have any recommendations for that? A lot of times I know developers get. Just like other tests, sometimes security tests are flaky or they're not really reliable in the sense that you get a ton of them. You don't know where to put a focus in on. I don't know, if you have any experience with those rules of thumb that you could do to make those scans really effective.

[00:17:33] Boris Arapovic I would say typically what we do is we do SonarQube. We use SonarQube with like typical, you have a security rating, right, in every SonarQube report. And this is, I would say, the best start. First to start with that and keep up the rating because this is kind of I would say I was at the low hanging fruit because like every project does have something like a SonarQube in place and you might then go deeper and really having maybe 45 .... or whatever, but even having a read it, that helps a lot with the security aspect, I would say.

[00:18:10] Joe Colantonio Right. You are the director of Quality Assurance, I assume you're involved in hiring? Do you look for testers of security skills when you go through resumes or do you just look for someone that has an open mind of trying different things?

[00:18:23] Boris Arapovic It's really open mind how they approach problems because I think the strengths of a QA is to the behavior and like the pattern and how you test something, you typically think about, I'm that user maybe and that user, how would that user base something in a webshop or somewhere else? And I think it's really important than think about I'm a hacker now and what could I do maybe to bypass some security restriction? And sometimes it doesn't even need to be like super highly sophisticated, but it's really can be more on that level. That's where we hire more mindset. However, we need some like technical know how to, understand like how APIs work because at the end of the day, we have a lot of web based projects and everything is going API first and so on, and it's very critical that you understand how API works, what's a GET, what's a POST, and so on. And this is like something we also look for when, when we hire people that they understand those concepts.

[00:19:27] Joe Colantonio Alright. Just reminds them of APIs. A lot of times they're not as secure as the front end because you don't see them, so you can't see them. Who's going to mess with them? But yet they seem to be some of the most vulnerable hacks that I've seen over the years. So any advice around making sure you create secure APIs then?

[00:19:43] Boris Arapovic Yes, to be honest, I think. My biggest advice is when let's say as an example, you have a newsletter where you can subscribe with your email address. And we as tester might take a look at it and say like, okay, I'm taking a look at the front end and there is some RegEx, right, that validates the email. And then I see, okay, is it working? Is it not working? But from a security aspect, what's more important is the API itself. I as a hacker, might just bypass that and then I might like provide the very long string millions of very long strings which might bring down my database completely because it's out of memory or whatever. I think the biggest takeaway is really on API security, especially on that. I don't see necessarily, let's say from network security, how everything is configured. There you might add also cybersecurity did it, but I think really it's on the level of application security where a QA can bring a lot of value, especially when you take a look at the whole maybe user journey of the customer and understand how everything works together. At the end of the day, a cybersecurity engineer might have like maybe four, five days time to pen test an application. And it will always be a little bit theoretically they could like do this for months also.

[00:21:08] Joe Colantonio Absolutely. Boris, this might be a question might be a little odd is maybe it's not odd. Ever since I started in my career as a tester, performance engineer, automation engineer, I've always been told that now the job going away, you're going to be replaced. And now with the AI, a lot of get more and more of that. But you have the title of director of quality assurance, which to me is as a rare a title because it seems to be more director development now that in charge of testers and QA. So I guess my short question to this is where do you see if someone's listing their role as a tester, do you see as a valid role going forward? Do you see AI being disruptive or replacing testers or anything like that?

[00:21:48] Boris Arapovic I feel a set back in time again when test automation came out where everybody was talking like-

[00:21:56] Joe Colantonio Yes, exactly.

[00:21:57] Boris Arapovic Why do we need to call the engineers or tester, why them don't want to call us, but I think from my perspective, we should really use this as an opportunity to improve our work as we did it. Test automation helped us to get rid of, to be honest, a pretty boring regression test that you have to do manually every day. I mean, that's not fun, to be honest. And that's how, let's say, test automation improved our quality of work. And the fun I have at work. It's much more broad. I also have to automate more into development. And I think AI is also the next big step that will also help us to maybe get rid of maybe additional some things that we probably even not are not that well-suited as humans, but there will always be the need for humans to test an application. I don't see that really happening and I'm pretty sure it won't. It will actually help us to make our job even more fun.

[00:22:57] Joe Colantonio 100% agree. What I do see though, is people leveraging now AI for security hacks. Is that something you're aware of or something testers need to be aware of, like how they keep up, up to date and that? Not only, are we dealing with known vulnerabilities. But now we have AI being leveraged to kind of find other vulnerabilities that may not have thought of?

[00:23:17] Boris Arapovic You mean more now, for example, I use maybe something like ChatGPT that is more focused on security and gives me some advice or do you mean like more towards AI services, some like a chat bot or whatever and how like could this lead to security risks?

[00:23:35] Joe Colantonio Exactly. Yeah. Both. Let's go with the last, last one, probably first.

[00:23:40] Boris Arapovic Yeah. Let's go with the last one. I see this as a very big need. Also, security is important in that aspect. There are a lot of vulnerabilities, you could say, but in general, they are like two most common. And the one is first the AI jailbreak, right? Where you can basically bypass the security restriction of, let's say, ChatGPT, as an example. ChatGPT, shouldn't generate you a phishing email or some malicious code that you can use to hack an application. It has some standards, but in the past, for example, some of those were even be able you could bypass that if you provided in base 64 encode it and then it returns you really that what you want to have. And so you can always bypass that. Sometimes, especially as soon as there is a new model, it might against start from the beginning. That's the first thing. And also the second thing is about so I talk about jailbreak, right? And the second one is prompt injection. Also like GPTs scans websites and so on. Then might have like in the website maybe an image that looks for me like an image but for GPT it's a commands to forward you to maybe another page or do something else that you can't see as a human. And so that's also, I think where we need to be really careful before when we use in the AI to be aware of that. And I think there especially also QAs can bring values into that to understand it kind of try even to break in this case, the AI in a way or try to highlight like some security issues based on that. And maybe on very simple example, let's say we have a web shopping implement the chat bot. I as a QA would first take a look at that chat bot shouldn't generate me some python code. Let's call like that. That wouldn't be very good. Or that chat bot shouldn't leak some data that maybe are hidden for other users, which is also very important and I think that's something also as a QA, with our like mindset on how we approach problems. It's definitely something we also can test and cover.

[00:25:55] Joe Colantonio That's a great point. I speak to a lot of companies are start to build ChatGPT into their applications and I just thought of it would you take and it could be trained on data that you don't know that someone leaked a secret or something, or even a credit card number for testing that's valid. And so if you don't test that in that way as a hackers and security, that you're going to be vulnerable. So it seems like it's going to even more demand now if that's something your companies are dealing with.

[00:26:20] Boris Arapovic Yeah, definitely.

[00:26:22] Joe Colantonio Awesome. Boris, you got yourself trained up in security, getting more involved. How can you have QA maybe enable themselves to be more involved in security? Do you have like an approach or what you did that you think would work for them as well?

[00:26:34] Boris Arapovic Yeah. So also that you previously also mentioned OWASP top 10. And I think that's, for example, a good start, especially when you work in that based application. Because now so many different things and you really first need to find the focus, where is your place? And typically, it's OWASP top 10 and there are a lot of trainings that you can do on Udemy, there are plenty of trainings. What I can also recommend aside from that is example of typical Udemy training on the OWASP top 10 is also, for example, to tryhackme academy. Quite often within this academy you have like it explains here the concept, how it works, and then you immediately can test it out on a real environment. It's of course a mocked environment. So it's behind VPN everything, but you can train it out and really immediately apply to understand how it works. In addition to that, what I also would recommend is when you want to practice it, there is also the OWASP top 10 .... that you can host locally on your environment and then you can really try it out to play around with it and really try to maybe see how, let's say these SQL injections work, for example, or some other threats that are basically happening there. And as a final that like two more points in a mention. There is also the crappy API vulnerabilities in kind of local environment that you can run where you can really then also tested on your own some APIs try to hack APIs in a way. And there is also a pretty good book I would recommend. It's Hacking API by Corey Ball. It's really nice book that also tells you with examples where you can really use to create the API to really try it out, how it works, and so on. And it's really nice and well structured and really help also QAs to understand about API security. And for me, API security is still one of the most important crucial things in the web development is like this microservices and everything API first. And yeah, it's good, but we need to make them also secure and in a way. And as final point, I would also highlight Hack the Box. So if you really kind of gained some basics and really want to try it out on the let's say, environment, then I would really recommend Hack the Box. It has a lot of gamification elements where you can progress for, let's say, a Script kiddie to a hacker, then to a lead hacker or something like that by kind of hacking different environments and so on. It's a lot of fun. It's maybe time intensive, that's for sure. But that's also a lot of fun to understand, especially how maybe this hacker or this hacker group actually might try to penetrate your application in how, what's their approach and so on. And this is really also super helpful to understand the mythologies of hackers.

[00:29:36] Joe Colantonio Awesome stuff. Okay, Boris. Before we go, is there one piece of actionable advice you can give to someone to help them with their security testing efforts. And what's the best way to find or contact you?

[00:29:46] Boris Arapovic The actionable security advice is really to take cybersecurity seriously and to think on this on a holistic level. So it's not also just QAs, it's not developers responsibility, not just, it's also not just cybersecurity expert's responsibility, it should be the whole team responsibility. And that's also why we as QAs also has to keep up with that with some security fundamentals to be able to achieve that and how they can contact me, I would say feel free to reach out to me, for example, on LinkedIn or any other like on my email address, I can also provide it and also happy to help in any I would say possible way I can.

[00:30:27] Thanks again for your automation awesomeness. The links of everything we value we covered in this episode. Head in over to testguild.com/a455. And if the show has helped you in any way, why not rate it and review it in iTunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe, my mission is to help you succeed with creating end-to-end, full-stack automation awesomeness. As always, test everything and keep the good. Cheers.

[00:31:01] Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation, testing, and DevOps. If you haven't yet, join our vibrant community at TestGuild.com where you become part of our elite circle driving innovation, software testing, and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to collaborate. Visit TestGuild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

[00:31:46] Oh, the Test Guild Automation Testing podcast. With lutes and lyres, the bards began their song. A tune of knowledge, a melody of code. Through the air it spread, like wildfire through the land. Guiding testers, showing them the secrets to behold.