Common Points I’ve Spoken or Written About
This document catalogs the most frequently discussed topics, themes, and insights from my talks, interviews, and writings across all timeline files. Each point includes frequency indicators showing how often it’s been mentioned, along with supporting quotes from different sources.
Introduction
Over the years, I’ve spoken at numerous conferences, participated in panels, and given interviews on various aspects of information security. This document attempts to capture the recurring themes and common points that emerge across these discussions. The analysis is based on 28 files with AI-generated summaries, transcripts, and other timeline content.
1. Career & Professional Development
1.1 Field Evolution: From Hobby to Profession (Mentioned in 2 talks/interviews)
The information security field has fundamentally transformed from a hobby-driven community to a professional career option.
Quotes:
- “We used to be chased because we were finding bugs” (with court orders) → “Now we are getting paid to find bugs” - BugGyaan Podcast
- “Field has transitioned from hobby to professional career option” - Career in Cybersecurity
- “Evolution: Ethical Hacking → Penetration Testing → Red Teaming → Adversary Simulation/Emulation” - Career in Cybersecurity
- “Hacking vs InfoSec: Hacking is fun and exploration; InfoSec is what you get paid to do” - BugGyaan Podcast
Context: This evolution is discussed across multiple interviews and talks, particularly when explaining how the industry has changed over the past 15+ years.
Evolution: The field continues to mature, but still lacks a defined learning path like MBBS for doctors. The industry is still figuring out structured learning methodologies.
Discussed in:
1.2 Certifications: Value and Limitations (Mentioned in 3 talks/interviews)
Certifications have value but should not be the primary hiring criterion. Organizations should find good people and pay them to get certifications, not hunt for certified people.
Quotes:
- “Don’t take certifications until you’ve applied to 100+ companies and 50+ reject you for lack of certification” - Career in Cybersecurity
- “CISSP is worth doing for keyword visibility, but certifications should only be done if barrier or company paying” - A Day In The Life of an Entrepreneur
- “Companies should find good people and pay them to get certifications, not hunt for certified people” - A Day In The Life of an Entrepreneur
- “Certifications are shortcuts to accelerated learning” - Career in Cybersecurity
- “Certification should prove skills, not replace skill development” - Career in Cybersecurity
- “CEH certification value: Not for practical info, but ensures you’ve heard every keyword in infosec space once” - BugGyaan Podcast
Context: This is a recurring theme, especially in career guidance sessions and discussions about hiring practices.
Evolution: The perspective has evolved from “certifications are essential” to “certifications are useful for keywords/barriers, but skills matter more.”
Discussed in:
1.3 Essential Skills: Patience, Reading, Troubleshooting (Mentioned in 3 talks/interviews)
Core skills for aspiring cybersecurity professionals include patience to read extensively and patience to troubleshoot, along with understanding underlying processes. Troubleshooting isn’t just a bonus skill - it’s survival.
Quotes:
- “Core Skills: Patience to read extensively + patience to troubleshoot” - Career in Cybersecurity
- “Understanding underlying processes, not just tool usage” - Career in Cybersecurity
- “Ability to correlate information and think creatively” - Career in Cybersecurity
- “Tools can take you to 20-30% proficiency. Understanding systems gets you to 70%. Creativity and deep knowledge gets you to 100%” - Career in Cybersecurity
- “Troubleshooting isn’t a bonus skill in tech. It’s survival.” - Troubleshooting: The Survival Skill We Forgot We Needed
- “Everything is solvable if you stay calm and understand what’s actually going wrong.” - Troubleshooting: The Survival Skill We Forgot We Needed
- “Troubleshooting means understanding. And understanding means taking responsibility. If you think you’ve found the cause of a problem, it’s your duty to replicate it, to validate it, and to make sure that if it ever happens again, your system can handle it.” - Troubleshooting: The Survival Skill We Forgot We Needed
- “You don’t need to know everything. But you do need to know enough - and more importantly, you need the confidence that you can figure out the rest when it breaks.” - Troubleshooting: The Survival Skill We Forgot We Needed
Context: Frequently mentioned in career guidance sessions and training discussions. The troubleshooting blog post emphasizes that in a world of abstractions and automation, the ability to dig into problems remains critical.
Discussed in:
- Career in Cybersecurity
- Troubleshooting: The Survival Skill We Forgot We Needed
- Mastering the Essential Skills for the Digital Age - Variable speed reading, fast typing, search skills, and troubleshooting as core digital survival skills
1.4 Mentorship: Don’t Idolize, Ask Questions (Mentioned in 2 talks/interviews)
Don’t idolize people - ask questions when stuck. Do homework first, then ask specific questions. Mentors remove roadblocks, don’t walk the path for you.
Quotes:
- “Don’t idolize people - ask questions when stuck” - Career in Cybersecurity
- “Do homework first, then ask specific questions” - Career in Cybersecurity
- “Mentors remove roadblocks, don’t walk the path for you” - Career in Cybersecurity
- “Don’t idolize people: Everyone has own journey and own life” - Switching from Offline to Online Trainings
- “Be open in saying ‘I don’t know’ - but then go back and figure out what don’t know” - Switching from Offline to Online Trainings
Context: Discussed in career guidance, training sessions, and mentorship testimonials.
Discussed in:
1.5 Building Unique Profile: Leverage Past Experiences (Mentioned in 1 talk/interview)
If everyone learns from same resources, everyone is at same level. What makes you unique? Leverage past experiences. Document everything.
Quotes:
- “If everyone learns from same resources, all of you are at same level - what’s unique about you?” - Career in Cybersecurity
- “What makes you unique? Leverage past experiences” - Career in Cybersecurity
- “Document everything: blog posts, GitHub contributions, community participation” - Career in Cybersecurity
- “Tech is 50% of the job, communication (emails, reports) is the other 50%” - Career in Cybersecurity
Context: Career advice sessions, especially for students and entry-level professionals.
1.6 From SPOF to Linchpin: Growth Without Getting Stuck (Mentioned in 1 blog post)
If you want to grow, at some point you must become a Single Point of Failure (SPOF) - but you cannot stagnate there. The goal is to be a serial SPOF, solving bigger problems each time, then documenting, automating, and training others before moving on.
Quotes:
- “If you want to grow, at some point in your career, you must become a SPOF. You must throw yourself into chaos, take full ownership, and say, ‘Yes, I will run the project, write the code, talk to the client, fix the server, and refill the coffee machine.’” - From SPOF to Linchpin: How to Grow Without Getting Stuck
- “The goal isn’t to hoard problems - it’s to solve and set them free.” - From SPOF to Linchpin: How to Grow Without Getting Stuck
- “If you can’t leave, you can’t grow. If you can’t be replaced, you can’t be promoted.” - From SPOF to Linchpin: How to Grow Without Getting Stuck
- “You don’t aim to never be a SPOF. You aim to be a serial SPOF, solving bigger and better problems each time.” - From SPOF to Linchpin: How to Grow Without Getting Stuck
- “Careers are built by those who dive into fires, yes - but sustained by those who also teach others where the water buckets are.” - From SPOF to Linchpin: How to Grow Without Getting Stuck
Context: Discussed in blog posts about career growth and leadership. The healthier arc: Jump into chaos → Solve problems → Take ownership → Become SPOF temporarily → Document ruthlessly → Automate → Train others → Exit gracefully → Repeat.
1.8 Why Learning to Code Matters More in the Age of AI (Mentioned in 1 blog post)
As AI handles more of the grunt work, it becomes more critical to understand the core logic yourself. Learning to code isn’t about typing faster - it’s about testing assumptions, building small proofs, and keeping your context engine awake.
Quotes:
- “As AI handles more of the grunt work, it becomes more critical to understand the core logic yourself.” - Why Learning to Code Matters More in the Age of AI
- “Learning to code isn’t about typing faster - it’s about testing assumptions, building small proofs, and keeping your context engine awake.” - Why Learning to Code Matters More in the Age of AI
Context: Discussed in blog posts about AI’s role in software development and the importance of maintaining core skills.
1.9 Entry Paths: Multiple Routes into Cybersecurity (Mentioned in 3 talks/interviews)
There are multiple pathways into cybersecurity - from sysadmin background, directly from college, through CTF events, bug bounties, or Google Summer of Code.
Quotes:
- “Earlier: Pathway from sysadmin or other role, eventually moved into security. Now: Can start directly in security from college” - Security Then and Now
- “Recommended pathways: CTF events, Bug Bounty programs, Google Summer of Code” - BugGyaan Podcast
- “Server admins → Security Auditors (leverage server configuration experience)” - Career in Cybersecurity
- “Developers → Secure Coding/Secure Programmers (don’t waste development talent on pen testing)” - Career in Cybersecurity
Context: Career guidance discussions across multiple interviews and panels.
Discussed in:
2. Supply Chain Security
2.1 SBOM is Inventory, Not Security Solution (Mentioned in 3 talks/interviews)
SBOM is fundamentally an inventory, not a security solution itself. Its use in security is just one application. Don’t treat SBOM as a security solution.
Quotes:
- “Don’t treat SBOM as a security solution” - it’s an inventory that can be used for security, but developers need value from it too - Breakpoint Security Podcast
- “SBOM is fundamentally an inventory, not a security solution itself - its use in security is just one application” - Breakpoint Security Podcast
- “SBOM is inventory management, not complete security solution” - Beyond the Code / SBOM: Supply Chain Security
- “SBOM just start - not solution, just knowing what you have” - Security Then and Now
Context: Discussed extensively in supply chain security talks and SBOM-focused interviews.
Evolution: Initially SBOM was touted as a silver bullet, but the narrative has shifted to “SBOM is the starting point, not the solution.”
Discussed in:
2.2 80% of Code is Import Statements (Mentioned in 4 talks/interviews)
About 80% of software products are import statements - you’re importing 100% of library code to use 10% of functionality.
Quotes:
- “About 80%: Of what call software products right now are basically import statements which are calling in stuff other people have done” - Quantifying Defence
- “80% of code is not written by you - but you’re importing 100% of library code to use 10% of functionality” - Beyond the Code / SBOM: Supply Chain Security
- “Stats say about 80% of code is actually import statements - just borrowing code from other people” - You secured your code dependencies, is that enough?
- “80% of code comes from supply chain (import this, import that)” - EP05 - CI/CD, Certs & Open Source Realities
Context: Used to explain why supply chain security matters - most code isn’t written by you.
Discussed in:
- Quantifying Defence
- Beyond the Code / SBOM: Supply Chain Security
- You secured your code dependencies, is that enough?
- EP05 - CI/CD, Certs & Open Source Realities
2.3 Supply Chain Beyond Code Dependencies (Mentioned in 3 talks/interviews)
Supply chain security includes more than just code dependencies - it includes developer environments, IDE extensions, CI/CD systems, containers, AI agents, and more.
Quotes:
- “SBOMs don’t capture the full build process: developer tools, IDE extensions, AI coding assistants” - Breakpoint Security Podcast
- “Supply chain includes more than code - IDEs, SaaS, IAM policies” - Quantifying Defence
- “Beyond code: developer environments, extensions, packages, CI/CD, containers” - You secured your code dependencies, is that enough?
- “Developer machines: AWS credentials in ~/.aws/credentials, SSH keys in ~/.ssh/id_rsa, admin access” - You secured your code dependencies, is that enough?
Context: Discussed in supply chain security talks, especially recent ones focusing on what SBOMs miss.
Discussed in:
2.4 Centralized Dependency Management (Mentioned in 1 talk/interview)
Security teams should provide vetted, audited library “battery packs” to developers. SBOMs can help identify commonly used libraries across an organization.
Quotes:
- “Security teams should provide vetted, audited library ‘battery packs’ to developers” - Breakpoint Security Podcast
- “SBOMs can help security teams identify commonly used libraries across an organization” - Breakpoint Security Podcast
- “Reduces tech debt by identifying problematic dependencies (e.g., npm modules that update daily)” - Breakpoint Security Podcast
Context: Discussed in supply chain security talks as a practical approach to managing dependencies.
3. DevSecOps & Security Culture
3.1 DevSecOps Should Never Have Existed (Mentioned in 2 talks/interviews)
DevSecOps is a term that should never have existed. DevOps should be secure by default. The term came up because security wants their share.
Quotes:
- “DevSecOps is term that should never have existed” - Quantifying Defence
- “DevSecOps should not exist - DevOps should be secure, should be secure by default” - Quantifying Defence
- “DevSecOps: Term that should never have existed but exists” - WeHackPurple Podcast
- “DevSecOps term: Came up because security wants name of their own” - WeHackPurple Podcast
Context: Discussed in DevSecOps talks and interviews, often as an opening statement.
Discussed in:
3.2 Security as Science, Not Art (Mentioned in 2 talks/interviews)
Security professionals consider security as art, not science. Developers should commoditize security, convert it into science - make it automatable, documentable, testable, repeatable.
Quotes:
- “Security professionals consider security as art, not science” - Developer Security Based on 15 Years Experience
- “Security industry doesn’t want to move away from art side to science side” - Developer Security Based on 15 Years Experience
- “Developer community should: Commoditize security, convert it into science” - Developer Security Based on 15 Years Experience
- “Need to move infosec from art to science” - Quantifying Defence
- “More move infosec from art to science, more will be in position to measure something” - Quantifying Defence
Context: Core message in developer security talks and DevSecOps discussions.
Evolution: This has been a consistent theme - the need to move from art to science to enable measurement and automation.
Discussed in:
3.3 Offensive Problems are Technical, Defensive Problems are Political (Mentioned in 2 talks/interviews)
Halvar Flake’s quote: “The offensive problems are technical in nature, the defensive problems are political in nature.”
Quotes:
- “The offensive problems are technical in nature, the defensive problems are political in nature” - Quantifying Defence , attributed to Halvar Flake
- “Offensive problems are technical, defensive problems are political” - EP05 - CI/CD, Certs & Open Source Realities
- “Pentesters find technical problems, say ‘Okay well you need to make these changes in these configurations’ - once ask for permission, someone says ‘Well it works way it is, don’t change it’” - Quantifying Defence
Context: Referenced in multiple talks about the challenges of defensive security and why offense is easier to measure.
Discussed in:
- Quantifying Defence - Referenced Halvar Flake’s quote
- EP05 - CI/CD, Certs & Open Source Realities
3.4 Shift Left is Unavoidable (Mentioned in 1 talk/interview)
With rapid release cycles (40-50 deployments per day), shift left approach is good and unavoidable. Everything has to happen within very short time.
Quotes:
- “Shift left approach: Good, unavoidable - writing code, testing, putting through security assessments, releasing code, all has to happen within very very short time” - Shift Level with CISO’s
- “Releases become so rapid: What call CI/CD pipeline, way things changing” - Shift Level with CISO’s
- “Today: Having release pretty much every week or every day - think will get to point where will have release every hour” - Shift Level with CISO’s
Context: Discussed in DevSecOps panels and shift left strategy talks.
3.5 De-risk Individuals, Focus on Collective Responsibility (Mentioned in 1 talk/interview)
Major problem is culture. Focus on de-risking individuals, focus on collective responsibility. If hack happens, it’s collective responsibility, not one person’s fault.
Quotes:
- “De-risk individuals, focus on collective responsibility” - Shift Level with CISO’s
- “If hack happens: Not one person responsible - does not matter if CISO or junior or intern, it’s collective responsibility” - Shift Level with CISO’s
- “CISO as scapegoat - Equifax example, CISO fired week after breach” - Shift Level with CISO’s
Context: Discussed in panels about organizational security culture and CISO challenges.
4. Android & Mobile Security
4.1 Mobile is Fully Hostile Territory (Mentioned in 2 talks/interviews)
Mobile is “fully hostile territory” - device may be hacked, owner may be hostile. Can’t trust user running app, app running in secure environment, headers from server.
Quotes:
- “Mobile is ‘fully hostile territory’ - device may be hacked, owner may be hostile” - BugGyaan Podcast
- “Mobile apps: No trusted end, hostile environment, can’t trust anything” - WeHackPurple Podcast
- “Can’t trust: User running app, app running in secure environment (might be rooted), headers from server (could be faked)” - WeHackPurple Podcast
- “Every in and out: Has to be validated” - WeHackPurple Podcast
Context: Core principle discussed in Android security talks and mobile security panels.
Discussed in:
4.2 Defense in Depth for Mobile (Mentioned in 1 talk/interview)
Mobile security requires defense in depth approach - SSL pinning → Request signing → Validation layers. Each layer raises attacker skill requirement.
Quotes:
- “Defense in depth approach: SSL pinning → Request signing → Validation layers” - BugGyaan Podcast
- “Each layer raises attacker skill requirement (0-3 → 5-6 → higher)” - BugGyaan Podcast
- “No 100% security, but increase complexity to make attacks harder” - BugGyaan Podcast
Context: Discussed in mobile security talks and Android security training sessions.
4.3 Mobile Security Model: Low-Privileged by Default (Mentioned in 2 talks/interviews)
By default, applications run as low-level privileged user (non-admin mode). Mobile devices do this by default - recommendation on Windows is to use non-administrative user.
Quotes:
- “By default: Applications run as low-level privileged user (non-admin mode)” - WeHackPurple Podcast
- “Recommendation on Windows: Use non-administrative user - mobile devices do this by default” - WeHackPurple Podcast
- “Android/mobile devices: Don’t even give by default root level access to device owner” - Security Then and Now
Context: Discussed in mobile security talks and Android security presentations.
Discussed in:
5. Open Source & Community
5.1 Open Source Philosophy: Do It Because You Want To (Mentioned in 2 talks/interviews)
Don’t do open source expecting returns - do it because you want to. Open source is “medium of expression” - I did something, I want to share it.
Quotes:
- “Don’t do open source expecting returns - do it because you want to” - BugGyaan Podcast
- “Open source is ‘medium of expression’ - I did something, I want to share it” - BugGyaan Podcast
- “Projects are personal - ‘These are my projects, I’m doing them for myself. Want a feature? Fork it.’” - BugGyaan Podcast
- “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” - EP05 - CI/CD, Certs & Open Source Realities
Context: Discussed in multiple interviews when talking about open source projects like Android Tamer, Code Vigilant, and Hacking Archives of India.
Evolution: Earlier open source was simple sharing. Now it’s become a mechanism to game the system for job opportunities, but the core philosophy remains.
Discussed in:
5.2 Code Vigilant: Learning Code Review (Mentioned in 2 talks/interviews)
Code Vigilant started around 2014 when frustrated with code review at work, wanted to learn. Picked WordPress as target, did code review, wrote automation, found bugs, disclosed them.
Quotes:
- “Code Vigilant: Frustrated with code review at work, wanted to learn” - EP05 - CI/CD, Certs & Open Source Realities
- “Started at NULL meets 2014 with Prajal Khar (now CISO at Groww)” - BugGyaan Podcast
- “2014: Found ~300 bugs, reported and got fixed” - BugGyaan Podcast
- “2021: Found another ~100 SQL injections” - BugGyaan Podcast
Context: Discussed when talking about open source projects and learning approaches.
Discussed in:
5.3 Android Tamer/Tamer Platform: Unified Environment (Mentioned in 2 talks/interviews)
Android Tamer started 2011 - unified environment for Android security tools. Problem: Tools fragmented across different languages/versions. Solution: Cohesive environment where all tools coexist.
Quotes:
- “Started 2011 - unified environment for Android security tools” - BugGyaan Podcast
- “Problem: Tools fragmented across different languages/versions (Java 1.7, 1.8, Ruby 1.5, 1.6, etc.)” - BugGyaan Podcast
- “Solution: Cohesive environment where all tools coexist and cooperate” - BugGyaan Podcast
- “Swiss Army knife for Android security” - Android Tamer
Context: Discussed in Android security talks and when explaining project origins.
Discussed in:
- BugGyaan Podcast
- Android Tamer - First public presentation
5.4 Community Involvement: Show Up and Make Presence Felt (Mentioned in 1 talk/interview)
Communities provide collaborative learning and crystallized/distilled information. Important to “show up and make your presence felt” - not just be part of 200-500 people crowd.
Quotes:
- “Show up and make your presence felt” - critical for community involvement - BugGyaan Podcast
- “Communities provide collaborative learning and crystallized/distilled information” - BugGyaan Podcast
- “NULL meets, OWASP meets - hear 3-4 different researchers share learnings” - BugGyaan Podcast
- “Many people hired before graduation because they showed skills in communities” - BugGyaan Podcast
Context: Discussed in career guidance sessions and community-focused talks.
6. Security Research & Methodology
6.1 Hacker vs Adversary: Understanding the Difference (Mentioned in 1 blog post)
Most infosec advice says “think like a hacker,” but infosec fights adversaries with goals, not curiosity. Real defense means blending hacker creativity with adversary realism.
Quotes:
- “Most of the infosec world loves to parrot the cliché: ‘Think like a hacker.’ But let’s be honest – most don’t. Heck, most don’t even think like adversaries.” - Hacker Vs Adversary
- “Most say ’think like a hacker,’ but infosec fights adversaries with goals, not curiosity. Real defense means blending hacker creativity with adversary realism.” - Hacker Vs Adversary
Context: Discussed in blog posts about security research methodology and threat modeling.
6.2 Look at What People Are Not Focusing On (Mentioned in 1 talk/interview)
Way to do quality research: Look at something which no one else is looking at, go big. James Kettle example - looking at HTTP headers, not even reached HTTP body yet.
Quotes:
- “Look at something which no one else is looking at, go big” - Security Then and Now
- “James Kettle (Albinowax) - every year comes out with interesting research, everyone in web application space gaga over it. All he is doing: Looking at HTTP headers - has not even reached HTTP body” - Security Then and Now
- “Find out what people are not focusing on, then deep dive on that” - Security Then and Now
Context: Discussed in research methodology talks and career guidance for researchers.
6.3 Research More Difficult Now Due to Overabundance (Mentioned in 1 talk/interview)
Research now more difficult because there is more vs content than actual content needed. Not BS content - people writing BS content to gain popularity.
Quotes:
- “Research now more difficult: Because there is more vs content than actual content needed” - Security Then and Now
- “Overabundance of content: Same thing explained in 20 different directions by 30 different people” - Security Then and Now
- “Old days: ‘Let me search something, I am not going to find what looking for, will have to make do with whatever can find’” - Security Then and Now
- “Now: ‘I found 200 articles, let me figure out what are they actually talking about’” - Security Then and Now
Context: Discussed in panels about security research evolution.
7. Industry Evolution & Trends
7.1 Security Then vs Now: Fun to Commercial (Mentioned in 1 talk/interview)
2000-2010: Hacking was fun, people doing it because it was exciting. 2010-2022: Established job opportunity, commercial enterprise, nine-to-five for many.
Quotes:
- “2000-2010 Era: Hacking was fun - People were doing it because it was exciting, wanted to experiment” - Security Then and Now
- “2010-2022 Era: Established job opportunity - Has become commercial enterprise, money-making opportunity” - Security Then and Now
- “Nine-to-five: For many, infosec is effectively nine-to-five earning opportunity” - Security Then and Now
- “People here for money: Not because they wanted to be here - changes perspective” - Security Then and Now
Context: Discussed in panels comparing security practices from past to present.
7.2 Industry Does Bare Minimum (Mentioned in 3 talks/interviews)
IT industry does what is bare minimum necessary to get by. If requirement is 80.0000, will not do 80.0001 - just do bare minimum required. We’ve learned to game systems - optimizing for metrics rather than meaning.
Quotes:
- “Collective failure: IT industry does what is bare minimum necessary to get by” - You secured your code dependencies, is that enough?
- “Bare minimum: If requirement is 80.0000, will not do 80.0001 - just do bare minimum required” - You secured your code dependencies, is that enough?
- “People creating SBOM: Very much difference between good quality SBOM vs SBOM someone is creating, but having SBOM does the check mark, people happy with it” - You secured your code dependencies, is that enough?
- “Somewhere along the way, we stopped doing things because they mattered and started doing them because they scored.” - We’ve All Learned to Game It
- “We built platforms, certifications, algorithms, metrics, and audits to measure success. And to be fair, we had to. Systems can’t function without measurement. But somewhere along the way, we stopped asking: ‘Are we measuring what matters, or just what’s easy to measure?’” - We’ve All Learned to Game It
Context: Discussed in supply chain security talks, industry critique sessions, and blog posts about systemic issues.
Discussed in:
- You secured your code dependencies, is that enough?
- We’ve All Learned to Game It
- Why Boring Tools Keep Us Productive - Discussion of how systems reward surface-level wins and optimize for metrics rather than meaning
7.3 Attack Surface Keeps Increasing (Mentioned in 1 talk/interview)
Attack surface keeps on increasing. Resources deployed to help with that keeps on decreasing. More attack surface you have, more vulnerable you are.
Quotes:
- “Attack surface: Keeps on increasing” - Safety Talk #66
- “Resources deployed: To help with that keeps on decreasing” - Safety Talk #66
- “More attack surface: Have, more vulnerable are, more fronts got to defend” - Safety Talk #66
Context: Discussed in talks about security challenges and industry problems.
8. Training & Education
8.1 Prerequisites are Crucial (Mentioned in 1 talk/interview)
Prerequisites are crucial for trainings. Very common prerequisite: Person should be well versed or at least hands-on with command prompt. If have to teach how to open command prompt, then not target audience.
Quotes:
- “Prerequisites are crucial for trainings” - Switching from Offline to Online Trainings
- “Very common prerequisite: Put out is person should be well versed or at least hands-on with command prompt” - Switching from Offline to Online Trainings
- “If have to teach: How to open command prompt in administrative mode or how to open command prompt itself, then not target audience for me” - Switching from Offline to Online Trainings
Context: Discussed in training methodology talks and when explaining training approaches.
8.2 Support Ratio: 15 People Max Per Support Trainer (Mentioned in 1 talk/interview)
Set up ratio - take 15 people at max associated with one support trainer. If teaching class of say 30 people, would have on stage and one more person available.
Quotes:
- “Support ratio: 15 people max per support trainer” - Switching from Offline to Online Trainings
- “If teaching class: Of say 30 people, would have on stage and one more person available” - Switching from Offline to Online Trainings
- “If classes say: Like 170 odd class, would have about 10 support staff available” - Switching from Offline to Online Trainings
Context: Discussed in training methodology talks, especially about online training transitions.
8.3 Full Days Better Than 4 Hours/Day for Online Trainings (Mentioned in 1 talk/interview)
Biggest challenge moving online: Companies wanted 4 hours/day instead of full days. Did couple of runs and basically put foot down - “Nope not doing” because employee is only four hours on training, remaining four hours supposed to work.
Quotes:
- “Biggest challenge moving online: Companies wanted 4 hours/day instead of full days” - Switching from Offline to Online Trainings
- “Problem that comes: With that is because employee is only four hours on training, remaining four hours supposed to work” - Switching from Offline to Online Trainings
- “Which means: Emails are on, Slack is on, never able to focus on training itself” - Switching from Offline to Online Trainings
Context: Discussed in training methodology talks about online training challenges.
9. Philosophy & Principles
9.1 Don’t Idolize People (Mentioned in 2 talks/interviews)
Don’t idolize people - everyone has own journey and own life, everyone working towards own goals. Don’t try to just idolize someone. This principle is closely related to mentorship (see section 1.4).
Quotes:
- “Don’t idolize people - ask questions when stuck” - Career in Cybersecurity
- “Don’t idolize people: Everyone has own journey and own life” - Switching from Offline to Online Trainings
Context: Core principle mentioned in career guidance, training sessions, and mentorship discussions. See also section 1.4 for related mentorship discussion.
Discussed in:
9.2 It’s Okay to Say “I Don’t Know” (Mentioned in 2 talks/interviews)
Be open in saying “I don’t know” - but then go back and figure out what you don’t know. What’s not okay is still saying you don’t know after 6 months.
Quotes:
- “Be open in saying ‘I don’t know’ - but then go back and figure out what don’t know” - Switching from Offline to Online Trainings
- “It’s okay to say you don’t know - what’s not okay is still saying you don’t know after 6 months” - WeHackPurple Podcast
- “If don’t know something just say it out that I don’t know, get back to them with what know” - Switching from Offline to Online Trainings
Context: Discussed in training methodology talks and career guidance sessions.
Discussed in:
9.3 Defense is Hard, Attack is Easy (Mentioned in 1 talk/interview)
Defense is hard, attack is easy. This controversial statement but true. Started looking at “Okay what are options? What are possibilities getting into infosec space?”
Quotes:
- “Defense is hard, attack is easy” - Switching from Offline to Online Trainings
- “True: In this controversial statement but ‘Defense is hard, attack is easy’” - Switching from Offline to Online Trainings
- “Then was far more easier: To start learning how to attack systems because ‘Defense is hard, attack is easy’” - Switching from Offline to Online Trainings
Context: Discussed when explaining journey from defense to offense to purple teaming.
9.4 Under Commit, Overperform (Mentioned in 2 talks/interviews)
The hack - under commit, overperform. If able to do 100 things, claim that able to do 70. Even if finish 80 of them, have overperformed.
Quotes:
- “When comes to hack: Under commit, overperform” - A Day In The Life of an Entrepreneur
- “If able to do: 100 things, claim that able to do 70” - A Day In The Life of an Entrepreneur
- “Even if finish: 80 of them, have overperformed” - A Day In The Life of an Entrepreneur
- “Under commit, overperform (commit 70, do 100-110)” - EP05 - CI/CD, Certs & Open Source Realities
Context: Discussed in entrepreneurship interviews and career advice sessions.
Discussed in:
9.5 Your Mileage Will Most Definitely Vary (Mentioned in 2 talks/interviews)
Use it for any number of things - for DevSecOps pipelines, to software supply chain equations, to entrepreneur journey. Every single person starting in that journey would have different journeys.
Quotes:
- “Your mileage will most definitely vary” - every organization’s SBOM implementation will differ based on their environment - Breakpoint Security Podcast
- “Use it: For any number of things - for DevSecOps pipelines, to software supply chain equations, to entrepreneur journey” - A Day In The Life of an Entrepreneur
- “Every single person: Starting in that journey, even though give same amount of money to start with, same facilities, same location, both would have different journeys” - A Day In The Life of an Entrepreneur
Context: Used as a disclaimer/caveat in multiple talks about implementation approaches.
Discussed in:
- Breakpoint Security Podcast - Applied to SBOM implementation differences
- A Day In The Life of an Entrepreneur - Applied to DevSecOps pipelines, supply chain equations, and entrepreneur journeys
10. Tools & Technologies
10.1 OSQuery for Software Asset Inventory (Mentioned in 2 talks/interviews)
OSQuery is highly recommended for enterprise-wide software inventory and querying. During Log4j crisis, organizations with OSQuery could quickly query for log4j installations.
Quotes:
- “OSQuery is highly recommended for enterprise-wide software inventory and querying” - Breakpoint Security Podcast
- “Example: During Log4j crisis, organizations with OSQuery could quickly query ‘SELECT * FROM computers WHERE application LIKE ’log4j%.jar’’” - Breakpoint Security Podcast
- “OSQuery can spot software installations” - Beyond the Code / SBOM: Supply Chain Security
Context: Discussed in supply chain security talks and software asset inventory discussions.
Discussed in:
- Breakpoint Security Podcast - Highlighted Log4j crisis use case
- Beyond the Code / SBOM: Supply Chain Security
10.2 Semgrep for Code Pattern Analysis (Mentioned in 2 talks/interviews)
Semgrep can identify if vulnerable functions are actually called. Use Semgrep to identify if vulnerable function is actually called - helps prioritize vulnerabilities.
Quotes:
- “Use Semgrep to identify if vulnerable functions are actually called” - Beyond the Code / SBOM: Supply Chain Security
- “2021: Disclosed about 50-60 odd SQL injections in WordPress plugins” - BugGyaan Podcast , about Code Vigilant using Semgrep
- “Current workflow: Semgrep → Defect Dojo → Validate → Report to vendors” - BugGyaan Podcast
Context: Discussed in supply chain security talks and code review discussions.
Discussed in:
- Beyond the Code / SBOM: Supply Chain Security
- BugGyaan Podcast - Code Vigilant workflow: Semgrep → Defect Dojo → Validate → Report
10.3 Why Boring Tools Keep Us Productive (Mentioned in 1 blog post)
Production isn’t a scale - it’s a promise. Boring tools don’t promise the moon, they just promise they’ll run - and they do. Old tech eventually went stable; new tech just moves the goalpost every few weeks.
Quotes:
- “Production isn’t a scale. It’s a promise. If I rely on it, it better not flake out just because someone pushed a minor update.” - Why Boring Tools Keep Us Productive
- “Old tech eventually went stable. New tech just moves the goalpost every few weeks.” - Why Boring Tools Keep Us Productive
- “A simple blog that gets updated beats a perfect one that never ships.” - Why Boring Tools Keep Us Productive
- “Boring tools don’t promise the moon. They just promise they’ll run - and they do.” - Why Boring Tools Keep Us Productive
- “I try a lot of things - but only the ones that earn their place get deployed.” - Why Boring Tools Keep Us Productive
Context: Discussed in blog posts about tool selection, stability, and the value of proven technologies over constantly changing new ones.
10.4 Making Security Tools Accessible: Browser-Native Tools (Mentioned in 1 blog post)
Security tooling today is often overcomplicated and infrastructure-heavy. Browser-native, client-side tools can be minimalist, secure, and surprisingly powerful - just open index.html and go. No servers, tracking, or setup required.
Quotes:
- “We keep bringing bazookas to wrestling matches. Security tooling today is often overcomplicated, infrastructure-heavy, and assumes a technical baseline that leaves many potential users out of the equation.” - Making Security Tools Accessible: Why I Chose the Browser
- “My goal isn’t to build shiny things for the elite few: it’s to make useful tooling accessible to people beyond the traditional developer crowd.” - Making Security Tools Accessible: Why I Chose the Browser
- “Tired of tools that need Docker to read a JSON file? I built browser-native, client-side tools like SBOMPlay and 3ptracer to prove you don’t need servers, tracking, or setup. Just open index.html and go.” - Making Security Tools Accessible: Why I Chose the Browser
Context: Discussed in blog posts about tool development philosophy and accessibility.
10.5 GitHub Student Pack and Free Resources (Mentioned in 2 talks/interviews)
GitHub Student Pack includes GitHub Pro, free domains, compute resources from Digital Ocean/Linode. Use free compute resources to build websites, understand deployment processes.
Quotes:
- “GitHub Student Pack (includes GitHub Pro, free domains, compute resources from Digital Ocean/Linode)” - Career in Cybersecurity
- “Use free compute resources to build websites, understand deployment processes” - Career in Cybersecurity
- “GitHub Student Pack: Register, get free resources” - EP05 - CI/CD, Certs & Open Source Realities
- “free-for-dev: Website listing free resources for developers/students” - EP05 - CI/CD, Certs & Open Source Realities
Context: Discussed in career guidance sessions and learning resource recommendations.
Discussed in:
- Career in Cybersecurity
- EP05 - CI/CD, Certs & Open Source Realities - Also mentioned free-for-dev website
11. Industry Perspectives & Debates
11.1 How Infosec Can Learn from Healthcare and Aviation (Mentioned in 1 blog post)
Infosec can learn from healthcare and aviation industries - adopting checklists, thorough documentation, fixed working hours, and proper handovers. The sector is grappling with staff shortage and disorganized handovers, leading to preventable complications.
Quotes:
- “Every staff member adheres to a fixed timeframe of working hours. Upon completing their shift, they meticulously hand over responsibilities to the next person.” - How Infosec Can Learn from Healthcare and Aviation
- “The adoption of checklists and thorough documentation could be revolutionary for our field.” - How Infosec Can Learn from Healthcare and Aviation
- “Infosec remains more art than science, primarily because there’s a prevailing belief within our community that our work is shrouded in a kind of ‘magical’ complexity.” - How Infosec Can Learn from Healthcare and Aviation
Context: Discussed in blog posts about improving infosec operations through structured approaches from other industries.
11.2 Determinism vs. Non-Determinism: Choosing the Right Tool (Mentioned in 1 blog post)
Determinism builds trust, non-determinism builds discovery. The art lies in knowing when the world needs certainty - and when it needs the unexpected gift of surprise. Not every nail needs a non-deterministic hammer.
Quotes:
- “Determinism builds trust. Non-determinism builds discovery.” - Not Every Nail Needs a Non-Deterministic Hammer
- “Determinism is not the natural order, it is the illusion we laboriously construct to keep chaos at bay.” - Not Every Nail Needs a Non-Deterministic Hammer
- “The question is never ‘which is better?’ It is always ‘where does it belong?’” - Not Every Nail Needs a Non-Deterministic Hammer
- “Determinism without flexibility becomes stagnation. Non-determinism without boundaries becomes destruction.” - Not Every Nail Needs a Non-Deterministic Hammer
Context: Discussed in blog posts about problem-solving approaches, LLMs, and when to use deterministic vs. non-deterministic solutions.
11.3 Reflections on Code and Control (Mentioned in 1 blog post)
Building philosophy: I build because I need to, not for applause. I value decentralization because it’s where control lives. When everything is centralized, all we have are dashboards. When something breaks, we don’t fix - we escalate.
Quotes:
- “I build because I need to. Not for applause. Not for stars. Just because something broke, or didn’t exist, and I thought - maybe I can fix it.” - Reflections on Code and Control
- “I value decentralization. Not for ideological rebellion, but because it’s where control lives. When everything is centralized, all we have are dashboards.” - Reflections on Code and Control
- “I believe in small code. One-liners. Scripts. Half-broken tools that solve real problems.” - Reflections on Code and Control
- “Security isn’t a PDF or an SLA. It’s responsibility – uncomfortable, necessary, real.” - Reflections on Code and Control
Context: Discussed in blog posts about building philosophy, decentralization, and taking responsibility.
12. Industry Perspectives & Debates
12.1 Community vs Industry (Mentioned in 1 talk/interview)
Need both passionate people and people just doing the job. Should not be hostile to people just doing the job - need both to grow industry.
Quotes:
- “Community vs. industry - need both, shouldn’t be hostile to people just doing the job” - Locknote: Conclusions and Key Takeaways from Day 2
- “Some people passionate, not everyone is, and that’s fine” - Locknote: Conclusions and Key Takeaways from Day 2
Context: Discussed in panels about industry growth and community dynamics.
12.2 Generalist vs Specialist (Mentioned in 1 talk/interview)
Generalists needed more than ever - to glue specialists together strategically. Much needed: Having deep generalists in key positions now is much needed.
Quotes:
- “Generalists needed more than ever - to glue specialists together strategically” - Locknote: Conclusions and Key Takeaways from Day 2
- “Much needed: Having deep generalists in key positions now is much needed because we have good specialists” - Locknote: Conclusions and Key Takeaways from Day 2
- “Generalist is way: People should be looking for” - Locknote: Conclusions and Key Takeaways from Day 2
Context: Discussed in panels about career paths and industry needs.
12.3 Centralization vs Decentralization (Mentioned in 2 talks/interviews)
Internet began decentralized, economic models forced centralization. Hope for decentralization - Mastodon example shows it can work when right moment comes.
Quotes:
- “Internet began decentralized: Economic models forced centralization” - Locknote: Conclusions and Key Takeaways from Day 2
- “Decentralization possible but requires effort - Mastodon example shows it can work when right moment comes” - Locknote: Conclusions and Key Takeaways from Day 2
- “Mastodon existed, got the PR when some other disaster happened (Twitter mismanagement)” - Locknote: Conclusions and Key Takeaways from Day 2
Context: Discussed in panels about internet architecture and future of technology, and blog posts about building philosophy and control.
Discussed in:
Conclusion
These common points represent recurring themes across years of speaking, writing, and contributing to the information security community. They reflect both the evolution of the industry and consistent principles that have guided my approach to security, career development, and community involvement.
The frequency indicators show which topics have been most consistently discussed, while the quotes provide direct evidence of how these points have been expressed across different contexts and time periods.