Interview with Michelle Mesquita, DevSecOps & AppSec Senior Consultant at EY

The second article of our series of App Sec and DevSecOps experts is now live. 👇

After meeting with Suphi Cankrut from AppSec Santa before Summer, I took my chance to interview Michelle Mesquita, DevSecOps and AppSec senior consultant at EY. Formerly DevSecOps Lead at IBM, she's now sharing her time between her missions at EY and at the Pontifical Catholic University of Parana, sharing her knowledge on code analysis and DevSecOps.

Here's a summary of our discussions:

Here's a summary of our discussions:

💬 Hi Michelle, could you please introduce yourself?

My name is Michelle, I'm a Brazilian girl that loves to talk about DevSecOps/Appsec, new technologies and help the community!

💬 Do you feel that the market is getting more and more mature to switch from DevOps to DevSecOps?

I don't know if I can say more mature, but I can say that now, people are very concerned about security and data protection. In that way, many companies understand that they need to invest time, money and education to make people understand security and how to maintain their applications more secure.

Now, people invest more in that culture and also spend money on these technologies that we can use and integrate into the pipeline. Especially, because now, many apps are exposed on Internet, so everyone can access and can try to find a vulnerability inside it.

So, I think that now, people understand more about DevSecOps and try to use it to have an application more mature.

💬 With your experience, could you list the advantages of an automated step in the security testing, on top of all the manual tests (code review, pentest, etc.)

I think the main advantage is to get time to make specific tests that seem more important.

Because with all automation, at least for vulnerabilities, that could be easy to explore, you don't need to start to test it manually, but of course, you need to verify all tests and check them. All those tests have false positives, it consumes a part of your day too.

Another thing is that if you use automation inside pipelines, it’s easier to get more vulnerabilities in SAST (Static Application Security Testing) than in DAST (Dynamic Application Security Testing) because you are verifying at the beginning, so problems with headers, input validation, secrets are easy to verify in this step than when you need to go to production.

💬 With all the new tools on the market, what would be the best stack?

I think the best stack depends on the kind of app you are developing.

For web applications, you need to use:

• SCA (Software Composition Analysis) for dependencies that developers need to use inside the app,
• SAST for code test,
• DAST to test endpoints and interface.

Now, most of the apps are using microservice architecture, so, we need to verify containers too. Not just the image that may have a vulnerability, but also the way that this container has privileges as well.

Another thing is to have a good monitoring system because we always need to check logs for apps. In that way, we can understand gaps and prevent incidents in the system.

💬 When running security testing on mobile apps, do you prefer the scalability of an emulator or the accuracy of a real device?

For mobile pentest, for example, I prefer to use a real device, especially because the behaviour is better than an emulator.

It was my personal experience when I needed to make some tests like that. It is faster to test it because you don't need to emulate it.

💬 What do you think of the OWASP MASVS? Should it be the security standard in all organisations?

Yes, it's a very good guideline that people can use to verify mobile apps and understand at least the main vulnerabilities that are important and could be easy to explore.

Also, if you understand those vulnerabilities, it will be easier to protect your mobile app.

💬 What are your thoughts when it comes to SAST v. DAST? Any good practice?

I think it's a very good practice to use both SAST and DAST tools because they will help you with some tests inside the application. But you can't just use that. You need to do your own manually tests, using grep functions in code review, for example.

Also, be aware that you will have a lot of false positives, we don't have a tool that will show all vulnerabilities that you have. So, you have to be aware of false positives, to justify and to document why it's not a vulnerability is very important.

Another thing about SAST is: always look for inputs, also for some keywords (like password, path) because you can find more false positives and you need to understand the kind of variable that you are using, for example, with an integer, you won't have XSS or SQL Injection in your app.

Those attacks just happen with string.

For DAST, you always need to look for the request that the app tried to do. Because, it can be an error when the tool tried to test, sometimes DAST can take a long time to test, and the tool can be frozen and you need to rerun again.

Also, verify the cryptography that this tool is saying and the port that is trying to connect. DAST has fewer false positives than SAST because we do SAST before DAST and we can eliminate the same vulnerability that we could verify in SAST.

💬 Interested in eShard's solution for MAST: esChecker. Feel free to request a free trial