1
1
1
1
1
0
1
0
0
1
1
1
0
1
1
1
1
0
1
0
0
1
0
0
1
0
0
1
0
1
1
0
1
1
0
0
1
1
1
0
0
1
0
0
0
0
1
0
0
1
0
1
0
0
0
1
0
1
0
1
1
0
0
1
0
0
1
0
0
0
1
1
1
1
0
0
0
0
1
0
1
0
1
1
1
1
1
0
1
0
1
0
0
1
1
0
1
1
0
0
1
1
0
1
1
0
0
1
0
1
1
1
1
0
1
1
0
0
1
1
0
1
1
0
0
0
0
1
1
1
0
0
0
1
1
1
1
1
0
1
0
0
0
1
1
0
0
0
1
1
1
0
1
0
0
0
1
0
1
1
0
0
1
1
1
0
1
0
1
1
0
0
1
0
1
0
1
0
1
0
0
1
1
1
0
1
0
0
1
0
0
0
0
1
0
0
0
1
1
0
0
0
1
0
0
0
0
0
0
1
0
1
0
1
0
1
0
0
1
1
1
0
1
1
1
0
1
1
0
1
1
1
1
1
1
0
1
0
0
0
0
0
0
1
0
1
1
1
1
0
1
1
0
1
0
0
0
0
0
0
0
1
0
1
1
0
0
0
0
1
0
0
1
0
0
1
0
0
1
0
0
0
1
1
0
1
1
0
0
0
0
1
1
1
0
1
1
1
1
1
0
1
1
1
1
1
0
1
0
0
0
1
0
1
1
0
1
0
1
0
0
0
0
1
1
1
1
1
0
0
0
1
1
1
0
1
1
1
1
0
0
1
1
0
1
0
0
0
1
0
1
1
0
0
0
1
0
0
1
0
0
0
0
0
1
0
1
1
0
1
1
1
1
0
1
1
0
0
0
1
0
0
1
0
0
1
0
1
0
1
0
0
1
1
1
1
1
1
1
0
cd ~/dashboard
arafat@xcloud:~
$cat about_me.txt

About Arafat

>

Most production failures don't happen because someone wrote bad code. They happen because systems behave differently under real conditions.

That gap — between "it works" and "it survives production" — is where I work.

Who I Am

core_identity.sh

I'm an Application Security Engineer working at the intersection of product features, infrastructure systems, and real-world operational constraints.

I focus on what happens after deployment. When containers restart, permissions drift, tenants share resources, networks behave unpredictably, and edge cases meet scale.

$ echo $FOCUS

"That's where risk hides."

Current Role

@ xCloud

At Startise, working on a production-grade cloud hosting platform (xCloud), where security isn't abstract — it's operational.

I act as a bridge between development and infrastructure, helping turn complex backend workflows into secure, repeatable "one-click" product features — without breaking tenant isolation, introducing hidden privilege paths, or creating fragile deployment chains.

Production cloud hosting platform

What I Actually Do

$ ./daily_operations.sh --verbose

I analyze how product features interact with real infrastructure. Not in theory. In production-like environments.

Docker Environments

Analyze how application features interact with containerized environments, resource limits, and container orchestration.

Nginx & Networking

Examine networking layers, reverse proxy configurations, DNS behavior, and traffic routing under real conditions.

Permissions & Filesystem

Investigate filesystem permissions, access controls, and privilege boundaries that applications depend on in production.

Multi-Tenant Isolation

Validate isolation boundaries, firewall rules, and resource separation in shared infrastructure environments.

What I Look For

$ ./risk_detection.sh

Assumptions That Won't Hold

Finding where development assumptions break under real production conditions

Isolation Gaps

Detecting boundaries that aren't as airtight as they appear

Over-Generous Permissions

Identifying access that's broader than necessary across services

Silent Deployment Risk

Spotting deployment flows that introduce risk without visible indicators

Escalation Paths

If something can escalate, leak, collide, or fail under pressure — I want to know before users do

Why It Matters

$ diff dev.log production.log
// Most teams test:

"Does it work?"

// I test:

"What breaks when this scales, misbehaves, or partially fails?"

That difference is small in development. It's massive in production.

I routinely catch issues that look fine at the application layer — but become high-impact risks once deployed to real infrastructure.

How I Think

$ ./mindset.sh --systems-perspective

I don't optimize for passing tests. I optimize for:

// Instead of asking:

"Does it work?"

// I ask:

"What breaks when this scales, misbehaves, or partially fails?"

// Instead of asking:

"Is it optimized for passing tests?"

// I ask:

"Is it optimized for reduced operational risk and predictable behavior under failure?"

// Instead of asking:

"Is the security strict enough?"

// I ask:

"Is the security precise enough — strong isolation boundaries, real resilience, not just rigid rules?"

Security isn't about being strict. It's about being precise.

Current Focus & Trajectory

$ ./growth_trajectory.sh

Security alone doesn't solve real-world problems. The world runs on AI, automation, and speed — I'm building at that intersection.

DevSecOps & Automation

I work across the full DevSecOps pipeline — from securing infrastructure to automating complex workflows. Not just security automation. All kinds of automation that make processes faster, repeatable, and reliable.

CI/CD pipeline security
Infrastructure automation
Workflow orchestration
Secure deployment systems

AI, ML & Large Language Models

Actively building with AI, machine learning, and LLMs — not just following the trend. Adapting these tools for real use cases, integrating them into workflows, and exploring how they reshape what's possible in security and automation.

LLM-powered tooling
AI-driven security analysis
Intelligent automation
ML-assisted workflows

Real-World Problem Solving

I don't define myself by a single domain. Security, DevOps, AI — these are tools. The real focus is identifying problems that matter and building solutions that work in production, not just in theory.

Production-grade solutions
Cross-domain thinking
Systems-level debugging
Scalable architecture

I'm not just a security engineer who uses AI. I'm a problem solver who thinks in systems, automates relentlessly, and secures everything I build.

Get In Touch
View Projects