Interview with Joel Aviad Ossi, Managing Director at WebSec

As cyber threats continue to evolve, how organizations respond to security research is often just as important as the vulnerabilities themselves. Clear communication, responsible disclosure, and concrete follow-up actions can make the difference between stronger security and unnecessary risk.

In this interview, we speak with Joel Aviad Ossi, Managing Director of WebSec, about how companies should engage with security researchers, turn testing into real security improvements, and move beyond checkbox compliance toward meaningful defense.

Thank you, Joel, for accepting our invitation.

To begin, could you introduce yourself by outlining your background, professional formation, and the path that led you to your current role at WebSec?

Thank you for having me. My interest in cybersecurity began long before my professional career. From a very young age, around eight years old, I was fascinated by computers and particularly by how systems worked, and sometimes how they failed. While my exposure was limited by age, I spent a great deal of time exploring Windows 95, experimenting with its native functionality, and trying to understand how things could be broken or manipulated. This curiosity was already somewhat atypical for a child at that age.

As I grew older, my technical understanding expanded alongside my interest in security. A pivotal moment came around the age of thirteen, when I discovered concepts such as port scanning, NetBIOS, and remote administration tools. This coincided with the early rise of YouTube, at a time when online learning resources, including hacking tutorials, were far less regulated than they are today. The internet was effectively a learning frontier, and it provided an enormous amount of raw, unfiltered material that allowed me to build a strong foundational understanding of offensive security techniques.

These early experiences shaped both my skill set and my mindset. I realized early on that understanding how to compromise systems provided an exceptional level of insight into how to protect them. This realization set me on a clear path toward cybersecurity as a long-term pursuit.

My self-directed learning continued well into early adulthood. Around the age of twenty-two, in 2014, a significant shift occurred in my approach. Rather than being driven purely by technical curiosity, I made a conscious decision to focus on ethics and responsibility. I transitioned from exploration for its own sake to applying my skills in ways that helped organizations improve their security posture.

In 2017, I joined a professional cybersecurity consultancy, where I further refined my expertise through real-world engagements and exposure to enterprise environments. After several years of hands-on experience, I felt confident in my ability to lead and deliver security services at a high level. This ultimately led to the founding of WebSec in 2020, where I now focus on delivering professional, ethical, and effective cybersecurity solutions.

When a company receives a vulnerability report, what are the first signs that show whether it understands ethical security research or not?

The earliest indicators are visible in a company’s initial response and overall posture. Organizations that understand ethical security research typically acknowledge the report promptly, communicate respectfully, and focus on understanding the technical details before drawing conclusions.

It begins with recognizing the intent of the researcher. A vulnerability report submitted in good faith should not be treated as adversarial. Ethical researchers do not demand compensation as part of disclosure, they report issues out of professional responsibility. Any reward or recognition should be optional and at the discretion of the company. Companies that understand this distinction tend to engage constructively rather than defensively.

Mature organizations also appreciate that acknowledging a report carries little downside. Even if the finding is ultimately classified as non exploitable or low risk, respectful engagement allows both sides to align on facts and risk assessment. This willingness to communicate openly is a strong signal of security maturity.

By contrast, early warning signs of misunderstanding ethical research include dismissive or hostile language, failure to acknowledge receipt, disproportionate legal positioning, or treating the report as a threat rather than an opportunity to improve security. These behaviors often stem from fear, lack of internal processes, or insufficient understanding of responsible disclosure norms.

What is the most common mistake companies make when responding to a security researcher for the first time?

The most common mistake is responding defensively instead of proportionally.

Rather than seeking clarification or validating the report internally, some companies default to denial, silence, or legal escalation. This reaction often occurs before the technical merits of the report are properly assessed. Such responses damage trust, discourage collaboration, and can escalate what should be a routine security interaction into a conflict.

Another frequent error is poor communication. Delayed responses, vague statements, or refusal to engage can be interpreted by researchers as avoidance or bad faith, even when that was not the intent. This breakdown increases the risk of misunderstandings and, in some cases, pushes researchers toward disclosure decisions that could have been avoided through dialogue.

A constructive first response does not require immediate confirmation of a vulnerability. It simply requires acknowledgement, openness, and a willingness to investigate. Companies that get this right set the foundation for cooperative disclosure and long term trust with the security community.

Why is having a clear vulnerability disclosure policy so important, and what usually goes wrong when companies don’t have one?

A clear vulnerability disclosure policy establishes a formal framework for responsible reporting. It defines procedures, expectations, rules of engagement, communication channels, and triage timelines. This ensures that all parties understand what can be reported, how findings should be submitted, whether rewards are offered, expected response times, and who within the organization is responsible for handling reports.

When such a policy is absent, researchers are often forced to improvise. Some may attempt to contact employees through platforms like LinkedIn, searching for a CISO or security leader in order to reach the right person. This approach is inherently risky. Sensitive vulnerability information can end up with individuals who are not prepared to handle it, increasing the likelihood of delays, miscommunication, or unintentional exposure. A well defined policy removes this uncertainty by providing a clear and secure reporting path from the outset.

That said, having a policy documented is only part of the solution. The policy must be actively supported and enforced operationally. An organization needs designated ownership for receiving reports, responding within stated timelines, triaging findings, registering incidents, and triggering incident response where appropriate. This requires real security operations capability.

A common failure point is committing to a policy that the organization cannot realistically uphold. Promising response times or engagement levels without the ability to deliver leads to broken expectations and loss of trust. In practice, this can be just as damaging as not having a disclosure policy at all.

This is where managed vulnerability disclosure programs become valuable. Solutions such as HackerOne or WebSec mVDP provide structured intake, coordinated triage, and consistent communication. By outsourcing or augmenting the operational side of responsible disclosure, organizations can meet their commitments reliably, reduce risk, and maintain a constructive relationship with the security research community.

Without a bug bounty program in place, how can companies realistically tell the difference between ethical researchers and malicious actors?

To answer this properly, it is important to clearly define the difference between a Vulnerability Disclosure Program and a Bug Bounty Program, as the two are often confused.

A Vulnerability Disclosure Program (VDP) is a formal policy and process that allows security researchers to report vulnerabilities safely and responsibly. It defines the scope, rules of engagement, reporting channels, response expectations, and legal safe harbor. A VDP does not require financial rewards. Its primary purpose is to enable ethical reporting, reduce risk, and provide clarity for both the company and the researcher.

A Bug Bounty Program (BBP) builds on top of a VDP by adding financial or non financial rewards for eligible findings. In a BBP, vulnerabilities are triaged and rewarded based on severity and impact. While incentives can increase participation, a BBP is not required for responsible disclosure to function effectively.

Even without a BBP, ethical researchers are distinguishable by their conduct. Researchers acting in good faith typically limit testing to what is necessary to demonstrate impact, provide detailed and well written reports rather than automated scan output, avoid accessing unnecessary data, and refrain from public disclosure or third party sharing. They also report findings promptly through appropriate channels and do so unconditionally, without making disclosure dependent on payment.

When neither a BBP nor a VDP exists, companies face greater uncertainty. There is no predefined framework to assess intent, and researchers may struggle to identify the correct point of contact. However, intent can still be evaluated through communication. Ethical researchers engage transparently, respond to questions, respect boundaries once defined, and adjust their behavior accordingly.

Malicious actors do not seek to disclose vulnerabilities. Their objective is exploitation, not remediation. The greater risk in the absence of a policy often comes from inexperienced researchers who may not understand legal or operational boundaries. Without clear guidance, they may perform intrusive testing such as denial of service scenarios that can cause real harm.

This is why a clear disclosure policy is critical. A VDP establishes boundaries, reduces ambiguity, and protects both sides. When a policy exists and is ignored, reports can reasonably be treated as abuse or bad faith activity, with participation restricted and legal consequences applied where appropriate.

Ultimately, companies distinguish ethical researchers from malicious or irresponsible actors by evaluating behavior, proportionality, and communication. Clear definitions, structured processes, and respectful engagement remain the most effective tools, regardless of whether financial incentives are involved.

Some organizations choose not to respond to vulnerability reports at all. Why is this approach risky from a security perspective?

Organizations that ignore vulnerability reports often demonstrate a lack of ownership over their own security posture. In many cases, responsibility is deflected to software vendors, external developers, or third parties. This may stem from fear, lack of technical understanding, or the belief that remediation is outside their control. Regardless of the reason, this mindset creates significant risk.

Failing to engage with vulnerability reports means vulnerabilities remain unassessed, untracked, and unresolved. Without visibility and ownership of vulnerability management, organizations lose the ability to make informed risk decisions. Security issues do not disappear simply because they are ignored, they remain exploitable.

From a security and business continuity perspective, this approach is dangerous. Unaddressed vulnerabilities increase the likelihood of compromise, which can lead to service outages, data breaches, regulatory consequences, and loss of customer trust. In severe cases, the impact extends beyond technical damage and threatens the viability of the organization itself.

History provides clear examples of this risk. The DigiNotar incident demonstrated how a failure in security governance and incident response can result in catastrophic outcomes, including total loss of trust and eventual bankruptcy.

Ultimately, choosing not to respond to vulnerability reports removes any opportunity for risk mitigation or controlled remediation. Engaging with reports, even when remediation is complex or involves third parties, is essential to maintaining security, accountability, and long term organizational resilience.

Based on your experience, how often do organizations turn pentest findings into real monitoring or detection rules, and what does this reveal about the gap between cybersecurity training and real-world practice?

In practice, the translation of penetration test findings into concrete monitoring or detection rules happens far less frequently than most security training materials suggest. How often this occurs largely depends on the size, maturity, and operational capabilities of the organization.

Large enterprises with established security operations, SIEM platforms, and dedicated detection engineering teams are more likely to convert certain findings into monitoring or detection use cases. This is especially common following red team engagements or infrastructure focused penetration tests, where the objective includes measuring detection and response capabilities in addition to identifying weaknesses. In those environments, findings are often used to improve alerting, correlation rules, and incident response playbooks.

By contrast, in more common engagements such as web application and API penetration testing, it is relatively rare for findings to result in new detection rules. The primary reason is that application level vulnerabilities are generally expected to be fixed at the source, in the code, rather than mitigated through perimeter or monitoring controls. While web application firewalls can sometimes be tuned to detect or log exploit attempts, these measures are supplementary and intended for visibility, not as a replacement for proper remediation.

For small and medium sized organizations, this gap is even more pronounced. Many do not operate a SIEM or have the resources to build and maintain meaningful detection logic. As a result, pentest findings typically lead to remediation actions only, with little or no corresponding investment in monitoring or detection. Detection engineering is usually only observed among enterprise clients with mature security operations.

This reality highlights a broader gap between cybersecurity training and real world practice. Training often emphasizes layered defenses, continuous monitoring, and detection driven security. In practice, most organizations focus on fixing identified issues rather than operationalizing findings into detection logic, either due to budget constraints, tooling limitations, or lack of security operations maturity.

Ultimately, penetration testing is still primarily treated as a risk reduction and compliance activity rather than a direct input into detection engineering. Bridging this gap requires not only better tooling but also a shift in how organizations view the relationship between offensive testing, defensive monitoring, and day to day security operations.

At a baseline, recognized security and quality certifications are strong indicators. Certifications such as ISO 27001 and ISO 9001, and where applicable SOC 2, demonstrate that an organization operates formal information security and quality management systems. For SaaS and PaaS providers in particular, these frameworks typically require regular risk assessments and penetration testing. Organizations that comply with these standards should be familiar with working with security researchers and handling vulnerability findings responsibly. It is important to verify that certifications are issued by bodies accredited by the IAF or another legitimate accreditation authority.

Organizational structure is another signal. Companies that take security seriously often have clear security ownership, such as a CISO or designated security lead. The presence of such roles suggests accountability and the ability to engage meaningfully on topics like penetration testing scope, remediation processes, and disclosure handling.

If the focus is specifically on responsible disclosure, transparency and public posture matter. Organizations that maintain a clear vulnerability disclosure policy, participate in disclosure programs, or publicly acknowledge security researchers demonstrate a proactive attitude toward ethical research. Public recognition can take the form of a Hall of Fame page, blog posts, or social media acknowledgements, all of which signal openness rather than fear of scrutiny.

Some organizations go a step further by offering symbolic or non monetary recognition. For example, the Dutch National Cyber Security Center provides public acknowledgment and lighthearted rewards to researchers who report vulnerabilities responsibly. While the reward itself is not the key factor, this approach reflects maturity, confidence, and respect for the security community.

From your experience, how does TechBehemoths compare to other platforms when it comes to surfacing security maturity and responsible behaviour?

From my experience, it is difficult to make a definitive comparison between TechBehemoths and other platforms specifically in terms of surfacing security maturity and responsible behavior. Most vendor listing platforms, including TechBehemoths, are primarily designed to showcase services, capabilities, and commercial positioning rather than to provide deep insight into security governance or disclosure practices.

Security maturity and responsible disclosure are often not easily measurable through public marketplace profiles alone. Elements such as internal security operations, incident response capability, and day to day engagement with security researchers typically sit behind the scenes and are not always visible in a standardized way across platforms.

That said, TechBehemoths does provide a structured and professional environment that encourages transparency and credibility. Compared to some other platforms, the emphasis on company verification, detailed profiles, and long term presence creates a better baseline for trust. While this does not directly measure security maturity, it does reduce noise and makes it easier for decision makers to identify serious, established providers.

How would you define WebSec’s role in the offensive security market compared to traditional cybersecurity firms?

WebSec operates beyond the constraints of traditional cybersecurity firms that primarily rely on established standards such as OWASP and the PTES framework. While we actively contribute to the development of these widely adopted methodologies, we do not limit ourselves to them.

In addition to industry standards, WebSec designs and maintains proprietary offensive security frameworks and internal methodologies developed in-house. These frameworks are continuously refined based on real-world attack scenarios and emerging threat landscapes.

What truly differentiates WebSec is our dedicated Research and Development division. Our team actively discovers previously unknown vulnerabilities in widely used libraries, platforms, and applications. These original research findings are directly integrated into our offensive security operations, enabling us to apply novel tactics and techniques that go beyond conventional testing approaches.

As a result, WebSec provides clients with insights not only into known and current security risks, but also into emerging and previously undocumented threats. This approach allows us to help organizations defend not just against today’s attacks, but against the threats of tomorrow.

Why does WebSec put such a strong focus on manual testing and in-house tooling instead of relying mainly on automated scanning?

At WebSec, we deliberately prioritize manual testing because automated scanning is a baseline capability that is widely accessible and requires limited expertise to operate. Running automated scans alone does not reflect the depth of skill, experience, or adversarial thinking required to accurately assess real-world risk, and therefore falls outside the core value we aim to deliver.

Automated scanners are inherently constrained by predefined signatures, update cycles, and known vulnerability patterns. While they can provide useful coverage for certain classes of issues, they lack the contextual understanding required to assess complex attack chains, business logic flaws, and environment-specific weaknesses. A professional penetration test goes far beyond what automated tools can identify, particularly when assessing live, running applications rather than static source code.

With the emergence of AI-driven SAST and DAST solutions, automated code analysis has become increasingly effective, in some cases reducing the need for traditional manual review of source code. However, the majority of real-world security assessments are conducted using grey-box and black-box approaches, where source code access is limited or unavailable.

In these scenarios, no automated scanner or AI system can currently replicate the creativity, intuition, and adaptive thinking of an experienced offensive security professional. WebSec’s consultants apply a true attacker mindset, supported by proprietary tooling and custom-built exploits developed in-house. This combination enables us to move faster, identify deeper and more impactful findings, and deliver consistently high-quality results throughout the entire engagement lifecycle, from initial reconnaissance to final reporting.

Outside of work, what activities help you disconnect and recharge?

Outside of work I take pleasure in traveling with my wife or spending time with friends.

Looking back at your career so far, what is one belief about security that you’ve changed your mind about, and what led to that shift?

Earlier in my career, I believed that achieving 100 percent security was possible. Experience has shown me that this assumption was fundamentally flawed.

Over the years, I have witnessed techniques that once seemed impossible become reality, attackers extracting data through physical vibrations, executing code via RF and Bluetooth channels without user interaction, and exploiting side effects that were never part of the original threat model. Time and again, assumptions about what could not be done have been proven wrong.

This reality reshaped my understanding of security. Absolute security does not exist. What does exist is the responsibility to apply the best knowledge, controls, and defenses available at any given moment, while continuously reassessing risk as technology and attack techniques evolve.

Security is not a fixed state but an ongoing process. The goal is not to eliminate risk entirely, but to stay ahead through constant evaluation, research, and adaptation, because adversaries are always working to gain the next advantage.

What is one piece of advice you would give company leaders to handle security research responsibly, and why is it often overlooked?

My advice is simple, appreciate security researchers. People spend serious time digging into your systems, sometimes days or weeks, finding issues that could genuinely hurt your company.

You do not always need to pay them, recognition alone already goes a long way. A thank-you, a letter, a social media shoutout, a t-shirt, or a small reward shows that you value the effort. That kind of positive communication encourages responsible disclosure instead of silence or abuse.

This is often overlooked because reports are treated like problems instead of gifts. Researchers are still undervalued and frequently get nothing in return. My mindset is straightforward, if someone gives your company something valuable, especially something that helps keep you safe, you should give something back.

Thank you so much, Joel, for sharing your insights and experiences with us today, and wish you the best of luck and inspiration in 2026, and not only!

WebSec is one of the leading companies on TechBehemoths. If you like this interview and think that Joel, and his team can help your business, don't hesitate to contact them via TechBehemoths or discover the agency on social media: LinkedIn.