Note: This summary is AI-generated and may contain inaccuracies, errors, or omissions. If you spot any issues, please contact the site owner for corrections. Errors or omissions are unintended.
This comprehensive podcast interview covers career journey, certifications, open source contributions, CI/CD pipelines, DevSecOps, conference paper submissions, AI/LLMs, and research directions in cybersecurity.
Key Topics Discussed
Career Journey:
Started with Linux in 2000 (PC Quest magazine with Red Hat Linux CD)
Joined 20-35 Linux user groups across India (early 2000s)
Server administration → RHCE prep → Linux Academy instructor
First batch: Teaching people with 15-20 years Unix experience (most inexperienced teaching most experienced)
2008: Graduated, joined company as software engineer (did server admin backend work)
2010: Decision point - server admin meant night shifts, 11-12 hour days
Took CEH (Certified Ethical Hacker) - gave all keywords in infosec space at surface level
Career path: Log analyst (Guardian servers) → Automation → Infosys → PA Consulting → Freelancing → Not So Secure (first person, director, led team of 40) → Own company
Security work: Offensive, defensive, consulting, product development
Certifications - Honest Perspective:
General recommendation: “If it is possible, don’t go for any certification”
Certifications are point-in-time snapshots, don’t reflect real-life situations
CEH example: Forgot definition of masquerading = deduction of marks, but in real life you’d just search
OSCP/eJPT example: Forgot specific switch, got stuck = doesn’t mean you’d be stuck in real life
Key insight: “The claim that we mimic the real life can never be true”
Challenges are exceptional edge cases, not run-of-the-mill work
Real pentester life: Excel, PowerPoint, Word docs, communication matter more than technical skills
Communication with peers, superiors, clients, managers matters far more than becoming enterprise admin quickly
When certifications help: Specific barrier to entry (CEH was barrier to entry at that time)
Interviewer perspective:
CEH certificate = knows theory, will ask practical questions
OSCP = assumes you’ve compromised networks, will grill you
Problem with high-grade certificates: Entry-level person with OSCP = “painting a target on your head”
Better approach: Smaller certificate + skill you can demonstrate in interview
General recommendation: “Under commit, overperform” - commit to 70, do 100-110
Open Source Contributions - Evolution:
Earlier days: Simple - “I built something, I wanted to share it with my peers, it was a proud moment”
No obligation, no expectation, no hidden motive
“I wrote something I wanted to show it to the world. If the world gets something out of it, that’s up to the world”
Current state: “We all have learned to game the system” - FOSS has become mechanism to game the system
Inverted logic: “I will do open source to get a job” (like LinkedIn activity = looking for job)
Problem: People do open source till they reach destination, then stop
Perverted utilization: Metasploit contribution = spelling check fix (two letters flipped) - should you brag about it?
Incentives game the system: If interviewer asks for open source contributions, people do it
Core motive for putting code out:
Backup - systems crash, data gone, if in another place it’s safe
Collective improvement - well-wishers find issues, give pull requests
Key point: “I am not doing any of my projects for others. I am doing it because I want to do it and others get benefit out of it”
Problem: People create tools, brag (200 posts), then abandon after 2 months
Social Media and Dopamine:
Gaming the system = hacker quality (making system do things it’s not supposed to do)
Dopamine hit: Following 200 people, even if depressed 360 days, 5 happy days × 200 = 1000 happy moments you see
Constant inferiority complex, FOMO: “I am inadequate”
Solution: Realize everyone is going through struggle, no one is better than where you are
Value: People who call you out when wrong are valuable
Key: Form encouraging circles (WhatsApp groups: childhood friends, college friends, first company friends)
Once you have that group, you don’t seek external validation
Early days of school/college = form golden relationships for life
CI/CD Pipelines and DevSecOps:
College education problem: Programmers write code → Server admins deploy somewhere → QA people (inferior, don’t program)
Real world: Not like that anymore
Evolution: Waterfall model → Agile development → 40 deployments per day (Shopify, Flipkart, Amazon)
DevOps: Startups merged dev and ops into one group
Infrastructure as Code: Terraform, Vagrant - change 2GB to 6GB, run script, everything deployed
CI/CD: Continuous Integration and Continuous Deployment
Tools: Jenkins (old self-deployable), GitHub Actions, Azure, all clouds have their own
GitHub Actions: Blurred line - code repository contains CI elements
Security testing: Part of QA (same domain considered inferior in college)
CI pipeline should include: Source code review, third party library checks, automation around test cases
DevSecOps/DevSecAIOps: Just DevOps where dev and ops merged into single entity
Code Vigilant and Android Tamer Origins:
Android Tamer (2010-11): Lots of Android development, couldn’t track all software, couldn’t build system to use all software
Key: “I was curing my own itch. I was not worried about giving something to others”
Code Vigilant: Frustrated with code review at work, wanted to learn
Partner: Prajal Gulkarni
Picked WordPress as target, did code review, wrote automation, found bugs, disclosed them
Origin: Wanted to learn code security, secure coding
CI/CD vs Audit vs Pen Testing:
Audit: Far bigger than code - environment, accesses, conditions, data treatment
Policy as Code: Can code policies (no MD5, no port 80 listening), validate in CI
CI cannot do 100% audit - audit is company-level
Pen Testing: Black box/gray box = shot in the dark
Throw kitchen sink at input parameters, see favorable response, create POC
Ideal world: With source code access, shouldn’t need pen testing if 100% accurate code review
Reality: 80% of code comes from supply chain (import this, import that)
Problem: Don’t know what’s inside dependencies, don’t want to spend time understanding
Unknown elements: Dependencies might have vulnerable paths your code doesn’t use
Conclusion: Pen testing still required, cannot take it away
Learning CI/CD Security:
Start with dev work, not security
GitHub Student Pack: Register, get free resources
free-for-dev: Website listing free resources for developers/students
Build your own website: Resume, anything - put on GitHub/Codeberg/GitLab
Don’t rely on standard features: Write your own GitHub Action
GitHub Actions: 2000 minutes/month free = 66 minutes/day = 1 hour compute per day
Use cases: Glorified cron job (e.g., Packt free book daily alert)
Key: Solve your own problems, don’t worry about solving world’s problems
Analogy: If you’ve seen elephant with naked eyes, you know what it looks like. Blindfolded, you get different perception depending on which section you touch
Better approach: Understand system first, then rip it apart
Conference Paper Submissions:
Important: If doing something good/interesting, put knowledge out (conferences, white papers, blog posts)
Knowledge buckets:
Learned from others: Blog post or local talk
Something didn’t work as expected: Start of research (XZ bug started with SSH delay, PHP bug started with Nikto delay)
Bug/misconfiguration discovered: Conference material (depending on severity/complication)
Conference selection: Pick relevant conference (India-only software → India conference, not Black Hat USA)
Examples: Nullcon (highly technical) vs CoCon (policies/procedures, Kerala police co-sponsor)
CFP forms: List what they want to accept
Review process: Given 500 papers, pick 5 - how would you evaluate?
Reality: Sometimes margins are 4.88 vs 4.87
“Not selected” vs “rejected”: Careful word choice - not saying you’re bad, saying what we had made more sense
Bsides Las Vegas origin: Black Hat/Defcon too big, good material rejected, created Bsides to give space
Key insight: “Favorite painting is the one I’m making right now. Once done, move to next one”
Don’t be one-trick pony: Move on to next research, keep moving
AI and LLMs:
“Too big to fail”: Massive investments from top giants want technology to survive
Halver Flake quote: “All offensive problems are technical, all defensive problems are political”
Regulations: Will be created so functionalities persist (lobbying ensures money doesn’t go to drains)
Cat’s out of the bag: Proprietary and open source solutions available
Open source definition: Some consider model file out = open source, others need model file + weights
AI vs LLMs: AI has been there long time (tic-tac-toe with all permutations = AI)
“AI as normal technology” paper: AI will go in background, not top of town
Current phase: Experimentation - trying to fit LLM into every place, see if it speeds things up
Use cases will stick: Wherever LLM fits and is better, those use cases will remain
Personal use case: Boilerplate stuff - get to intermediary stage, then decide if want to spend time on remaining 20%
Example: Writing song - LLM gives song, change one word requires conforming to lyrics, changes meaning, now in thick of it, realize it’s hard, decide if want to spend time or find someone else
Summarization problem: AI picks prominent words, makes sentence - not the summary you’d gain reading book
Blinkist: Same problem 4-5 years ago
Key: Every individual has different summary of same book - learnings are personal
Research Directions:
Mobile security: Making life easier for people using Android not by choice (only cheap option)
Supply chain security: SBOM (Software Bill of Material)
Current focus: Way to identify vulnerable packages
Core idea: “Till information security domain keeps SBOM as their stuff, SBOM is not going to fly”
Solution: Change narrative, make SBOM usable for developers, find use cases where SBOM as inventory is useful for developers
Then SBOM becomes useful and security improves as byproduct
AI workflows: Exploring if can make workflows better, more automation
Cloud: Looking at various cloud security topics
Research Advice:
James Kettle example: Looking at HTTP packet line by line, just headers (not body yet), finding bugs for years
Key: Look at things people have already looked at, but give it time, spend efforts understanding the system
HTTP protocol learning: Built minimal web browser and web server, went through RFC line by line
Result: Understand protocol much better than others in circle
Advice: “Take the summarization part aside, start doing the actual work”
Key Insights:
Problem-solving ability more important than ticking boxes
Certifications are point-in-time snapshots, not real-life indicators
Open source should be done because you want to, not to get job
CI/CD security starts with understanding dev work first
Conference submissions: Put knowledge out, but don’t be one-trick pony
AI will go in background, use cases that fit will stick
Research: Look at things people have looked at, but understand deeply
Communication and relationships matter more than technical skills alone
Important Projects and Tools Mentioned:
Android Tamer - VM with Android penetration testing tools
Code Vigilant - Open source security for open source tools
