EP05 - CI/CD, Certs & Open Source Realities

AI Generated Summary

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:
  1. Backup - systems crash, data gone, if in another place it’s safe
  2. 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:
  1. Learned from others: Blog post or local talk
  2. Something didn’t work as expected: Start of research (XZ bug started with SSH delay, PHP bug started with Nikto delay)
  3. 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
• GitHub Student Pack - Free resources for students
• free-for-dev - List of free developer resources
• GitHub Actions - CI/CD automation (2000 minutes/month free)
• Terraform, Vagrant - Infrastructure as Code
• Jenkins - Self-deployable CI environment

Actionable Takeaways:

1. Don’t go for certifications unless specific barrier to entry
2. Under commit, overperform (commit 70, do 100-110)
3. Do open source because you want to, not to get job
4. Build your own website, write GitHub Action, understand CI/CD from ground up
5. Solve your own problems first, don’t worry about world’s problems
6. Put knowledge out (blog, local talk, conference) but move on to next research
7. Pick relevant conference for your research (geography, focus area)
8. Understand systems deeply before trying to break them
9. Look at things people have looked at, but give it time and effort
10. Communication and relationships matter more than technical skills alone