Principal Security Engineer

About Divar. Millions of people use Divar to buy, sell, rent, and hire. We run most of the platform ourselves: bare-metal and virtualized infrastructure across several data centers, Kubernetes, Go and Python microservices, Kafka, a range of SQL and NoSQL databases, distributed storage, and our own CI/CD — plus Android, iOS and web clients. That makes securing it our job too.

How security works at Divar. Each infrastructure and product team owns the security of what it builds and runs. A security chapter — engineers who sit inside the infrastructure, backend, mobile and web tribes — sets the bar with them, helps them meet it, and checks the result. Platform teams turn recurring controls into safe defaults. Specialist work such as incident response retainers, threat hunting, forensics, and red teaming is done with outside partners, under our direction and without standing access.

The role. You're a senior member of the security chapter and the security authority for the part of Divar you join. You sit inside an engineering tribe and work on its real systems. Your tribe lead manages your day-to-day; the head of the security chapter sets the standard you hold the tribe to and reviews your work. You don't manage people; you change what gets built.

What makes a Principal Security Engineer at Divar?

• You go deep. You read the code, the config, and the kernel log. You can find the weakness in a design, prove it, and show the fix.
• You build, not just review. You turn a finding into a control: a CI check, a platform default, a policy as code, a safe library. The best fix is the one no team has to remember.
• You work through the teams. Teams own their systems. You make security part of their design reviews and release gates, and you grow the security champions who carry it day to day.
• You think about risk, not checklists. You fix what reduces real risk first, and you write down what we decide to accept, who owns it, and when we'll look at it again.
• You measure progress. "We're hardened" isn't an answer. "73% of CIS Level 1 controls pass, and every failure has a documented exception" is.
• You're honest about trade-offs. You can tell a tribe lead what a decision costs in risk and capacity, and you can say, "this one can wait."

Your first year

• Month 1: Get to know your tribe's people, systems, and roadmap. Read the security standard and the roadmap underway. Name the top risks in your area.
• Months 2–3: Agree on your priorities with your tribe leads and the security chapter. Write the security acceptance criteria for your area's releases. Get security champions named in your teams.
• Months 4–12: Your area's recurring controls run as platform defaults or CI checks. Every significant design gets a threat review. High and critical findings close within their deadline. You've tested at least one realistic attack path end to end, and the gaps it found are closed.

We'll judge your success by how much risk goes down and how much more resilient we become, not by how many findings you file or tools you introduce.