Tinkering with product security pt. 2

Credits : Microsoft Gemini generated AI image

Welcome back to the second installment in this series, let’s carry the momentum of what we learned in the previous blog. If not you can pause here and read the pt.1

Let’s play Mario ?

I’m sure many of us have played this game at least once in our childhood.

I was always amazed by having so many levels in altogether diverse settings and maps, sometimes the character would be drowning inside the water, fighting with the fishes and on somedays we made the poor guy pass through those green pipes. Not to forget the dragon fights and the steels bars going up and down, and also those annoying monkeys.

The way I look at product security is almost similar to a video game like Mario .

You have many maps to play (here you can relate it to different domains like Cloud, Mobile Apps , Web Apps, Containers, APIs etc.)

You have different levels to climb on ( for instance take an example of setting up some AWS alerts, level 1 could be you know a simple alert from the managed service itself, but a level 5 could be setting up the alerts using, let’s say a lambda function and similarly a level 10 could be setting up alerts using IaC, maybe terraform or whatever you like )

You have different villains to fight with (like an application vulnerable to RCE due to an outdated Java or Apache dependency, or any sensitive API left public, or even maybe cost sometimes.)

It won’t be same all the time.

To become better at product security, you will have to adapt to different roles and requirements on a changing basis while delivering value for all of them.

An efficient and systematic product security engineer knows to wear different hats, like to be able to perform the basic web application security assessments, perform SCA & SBOM analysis, or setup SAST/DAST.

On some days you will be debugging AWS error logs or end up into a myriad of K8s cluster, or on some days you’d be performing security checks on mobile apps. It might seem overwhelming in the starting, but hang on there mate.

All of these aren’t achieved in a single day, it’s a continuous journey.

Where to start ?

It’s always an easy and efficient way to approach your web applications first or even mobile applications.

1. If it’s a public facing application then you can start testing right away using Burp & all your application testing methodologies. If not setup the applications with their required dependencies (if any).
2. Enumeration shall never be enough if it’s not backed with any further actionable. “So what if you got to an WordPress admin page, what damage you can do after reaching there defines the impact.”

In the next blog we’ll look how can we build a secure SDLC pipeline and start getting technical, until then, see you.

If you liked reading it, please don’t forget to give a clap and follow.