As part of TechNadu’s International Women’s Day campaign and LeadHer in Security series, we spoke with Aishwarya Gore, Co-Founder of Vulnuris, about the disconnect between compliance, vulnerability management, and real attacker behavior.
Gore brings over eight years of experience across offensive security, GRC, and enterprise risk assessments. She highlights security concerns in that most compliance frameworks focus on having all the controls in place, and not on how they would stop or detect an attack. It also assumes the same importance to all controls, which may lose a grip on attacker tactics as the approach doesn’t consider how attackers operate.
She believes that offensive security rewards curiosity and depth. Gore explains that most compliance frameworks focus on whether controls are documented and present, not whether they would actually stop or detect an attack. They also tend to treat controls as equally important, even though attackers prioritize weaknesses very differently.
Many organizations create processes but fail to follow them consistently. Evidence is prepared ahead of audits, compliance certificates are obtained, yet they fall prey to attacks.
Gore also reflects on the personal weight founders carry in cybersecurity, being trusted with clients’ most sensitive weaknesses. All this while balancing technical integrity with commercial expectations.
For women entering offensive security, she emphasizes strong fundamentals, analytical confidence, and the ability to translate technical risk into business impact. Those qualities, she notes, outlast any single tool or trend.
Read on to explore Gore’s perspective on why attackers think in steps, not severities, and why compliance without validation creates risk.
Vishwa: From your experience in offensive security, what initial access paths are you seeing most often during real-world assessments today?
Aishwarya: Honestly, most compromises we see still start with phishing.
And not the obviously bad kind. It’s usually well-crafted emails that look like normal business workflows:
With modern phishing frameworks, attackers can proxy a real login session in real time. So even when MFA is enabled, users unknowingly hand over valid session tokens. From the outside, it looks like a legitimate login.
In parallel, we still see very basic issues like -
What’s striking is that none of this is particularly advanced. Attackers aren’t breaking in all the time—most of the times, they’re just logging in.
And that usually happens because something was assumed to be “internal,” “temporary,” “unlikely to be found,” or simply forgotten unless found by an attacker.
Vishwa: Application security teams often struggle to prioritize findings. Based on your observations, what signals help distinguish real risk from noise?
Aishwarya: I think prioritization becomes difficult when teams rely too heavily on severity labels without looking at context.
Let me give you two real patterns we see.
What really matters when assessing risk is:
Teams do better when they stop treating findings as isolated items and start asking, “If I were an attacker, what would I do next?” Thinking in terms of attack paths, not individual bugs, changes everything.
Vishwa: Where do you see gaps between scanning results and actual remediation in vulnerability management?
Aishwarya: Most gaps don’t come from negligence—they come from process breakdowns.
A common scenario is this:
Another gap is what I call “fixing the symptom.”
I’m sure many VAPT vendors will agree that they keep getting requests from clients to “Accept” a high-level vulnerability for business reasons.
Another thing often missing is verification. Issues are marked as fixed without checking whether the original exploitation path is actually closed.
Strong vulnerability management isn’t about clearing dashboards. It’s about confirming that the attacker no longer has that option.
Vishwa: Based on your assessments, how do attackers typically chain smaller weaknesses into larger compromises?
Aishwarya: This is where I see a major disconnect.
Many organizations focus only on fixing critical and high-severity findings. Medium and low issues are often deprioritized or ignored altogether. But in real attacks, those are exactly the issues attackers rely on.
An attacker might start with something small—an information disclosure that reveals internal endpoints, or a misconfigured role that grants slightly more access than intended. On its own, it doesn’t look dangerous. But then it gets combined with another oversight, and another.
We’ve seen this pattern clearly in supply chain attacks as well. Seemingly low-impact weaknesses—like excessive trust in third-party components or weak integrity checks—have led to massive downstream impact.
From a testing perspective, it’s often hard to convince clients that these “minor” issues matter. But attackers don’t think in severities. They think in steps. And those small, unresolved findings often form the quiet, invisible path that leads to a major compromise.
Vishwa: From an offensive perspective, which security controls tend to be misunderstood or underused?
Aishwarya: One of the biggest misunderstandings I see is assuming that a control is effective just because it exists.
Controls fail most often not because they’re weak, but because they’re partially implemented or inconsistently applied.
Vishwa: You work across GRC and technical security. Where do compliance frameworks align well with real security outcomes, and where do they tend to fall short?
Aishwarya: Compliance frameworks do a good job of setting foundations. Things like asset identification, access control principles, incident response structure, and accountability are genuinely useful when implemented properly.
Where they fall short is in depth and validation. Most frameworks focus on whether a control exists, not whether it would actually stop or detect an attack. They also tend to treat all controls as equally important, which doesn’t reflect how attackers operate.
In many organizations, processes are created and documented, but no one follows those processes. Evidences are created or taken 1-2 months before an audit, and this is why many “compliant” organizations still fall prey to cyberattacks.
So, in my opinion, the risk gets created when the compliance certificate becomes the goal rather than creating and adhering to baselines. Without technical testing and real-world validation, it’s easy to feel secure while you actually remain exposed.
Vishwa: As a co-founder building a security company, what challenges strengthened your leadership but remain undiscussed?
Aishwarya: One challenge that shaped me deeply was learning to operate in an environment where trust is both your biggest asset and your biggest vulnerability.
In cybersecurity, clients share extremely sensitive information — sometimes about incidents, weaknesses, or internal struggles they haven’t disclosed anywhere else. As a founder, you carry that weight personally.
You’re not just delivering a service; you’re being trusted with someone’s worst-case scenarios and must shoulder the responsibility of changing that to a safe and secure environment. That responsibility can also be emotionally heavy, but it’s rarely talked about.
Another less visible challenge is navigating uncertainty while projecting stability. Teams, clients, and partners look to founders for confidence, even when you’re figuring things out in real time. You learn to absorb pressure without passing anxiety downward, and to make decisions that affect livelihoods, not just business outcomes.
There’s also the constant tension between technical integrity and commercial reality. Our work often reveals uncomfortable truths, and standing by those findings — even when they’re inconvenient or unpopular — requires resilience.
What strengthened my leadership wasn’t a single breakthrough moment, but repeatedly choosing transparency, responsibility, and long-term trust over short-term comfort.
Vishwa: For women entering offensive security, what preparation feels most valuable based on your journey?
Aishwarya: If I look back at my own journey, the most valuable preparation wasn’t learning a specific tool or technique — it was building a strong foundation in how systems actually work. Offensive security rewards curiosity and depth.
Understanding operating systems, networks, identity, cloud models, and application behavior gives you the ability to reason through unfamiliar problems, which is far more powerful than memorizing exploits.
Equally important was developing confidence in my analytical thinking. In offensive security, you’re often the person pointing out uncomfortable truths or challenging assumptions. That can be intimidating, especially early in your career. Learning to trust your observations, validate them carefully, and present them calmly makes a huge difference.
Communication skills are also underrated. Finding vulnerabilities is only part of the job; explaining their impact in a way that decision-makers understand is what actually drives change. Being able to translate technical risk into business terms amplifies your effectiveness enormously.
To summarize it, I would say the best preparation is a combination of strong fundamentals, clear thinking, effective communication, and the confidence to keep going even when things feel unfamiliar or difficult. Those qualities outlast any single technology or trend.