Francesco Cipollone
Appsec Monkey
London, United Kingdom
Actions
Francesco is a seasoned entrepreneur, CEO of the Contextual-based vulnerability management platform from code to cloud Phoenix Security, author of several books, host of multi-award Cyber Security & Cloud Podcast, speaker known in the cybersecurity industry and recognized for his visionary views. He is on the UK&I Cloud Security Alliance Chapter board and is a professor at IANS on application security and cloud security. Previously, Francesco headed HSBC's application and cloud security and was a Senior Security Consultant at AWS. Francesco has been keynoting at global conferences and has authored and co-authored several books and whitepapers; outside of work, you can find me running marathons, snowboarding on the Italian slopes, and enjoying single malt whiskeys in one of my favourite London clubs.
Area of Expertise
Topics
Vulnapocalypse Chill pill Close the Tap, Burn the Backlog: 6 Controls Framework for the Agentic SDLC
Between 30 and 41% of the code shipping at Google, Meta, and Microsoft is now written by AI. PR throughput has gone up by an order of magnitude. The review pipeline has not. Static scanners calibrated for one engineer committing once a day now produce 112,000 findings against a backlog nobody can drain. The agent pulls a package two hours old, copies a pattern from three-year-old training data, and never learns from the last vulnerability it caused. The SDLC running in production today is not the one you secured in 2022, and bolting another scanner on the side of it will not catch you up.
This is the framework. Six controls across two halves. Close the Tap on the left, Burn the Backlog on the right. Five blocking gates across the agentic development lifecycle (ADLC): PRD generation, package install, code generation, PR, CI/CD. Skills bind the agent at the design stage. Scaffolding turns the existing backlog into rules the next session has to follow. Graph-aware scanning runs inside the session, not three sprints later in triage. Malware intel sits on the install hook and refuses the bad package before it lands in node_modules. On the right, aggregation collapses scanner sprawl into one prioritized queue with reachability and ownership attached. Agentic remediation turns twelve Log4j PRs into one.
The argument is structural, not theatrical. If attackers reason, defenders need to reason. Throwing every PR at a frontier model costs more than the breach it prevents, and the math on that is in the talk. A code graph plus a security graph plus an architecture graph compresses the search space by roughly an order of magnitude. That is what makes defensive AI affordable outside a hyperscaler budget. Same primitive the attacker uses, different output. Vendor-neutral throughout: the controls are the same whether you build on Phoenix, Snyk, Apiiro, Endor, or in-house.
Key discussion points
The ADLC, drawn end to end. Where the agent sits, where the gates belong, and why post-PR scanning is downstream of the damage. The five blocking paths, what each one costs to bypass, and why the dev workstation is now the perimeter the program has to defend.
The six controls, each with the metric that tells you it is working. Skills, Scaffolding, Graph-Aware Scanning, Malware Intel, VM Aggregation, Agentic Remediation. The number on the dashboard for each. The number that says the control is off. The number that says the rules are wrong.
Why the knowledge graph is the load-bearing part. Code graph, security graph, architecture graph. The cost of frontier-model spend at PR level without curated context, with the actual token math. Why the same graph that scans the PR also writes the remediation, and why that economics is the only thing that holds up at 400K findings.
The supply-chain layer. Five npm incidents in six weeks. Median compromise-to-impact under an hour. Trusted Publishing did not solve it. Pin-and-audit did not solve it. Where each of the five gates catches what the previous one missed, and which one your program is missing right now.
Takeaways for attendees
A drawn architecture of the agentic SDLC with six controls mapped to five blocking gates, plus the audit checklist for finding which ones your program is missing. The install order depends on the bottleneck: PR velocity, backlog size, agent adoption, supply chain. Pick the right one for your shop, not a generic checklist.
The four metrics that go on a dashboard next week. Prevention rate above 60% on AI-generated PRs by day 90. PR block rate between 5 and 15% (zero means the gate is off, above 15 means the rules are wrong). Backlog burn rate positive. Median package age under two hours at install. Including the metrics that get worse before they get better, so a red board in week six is the program working rather than failing.
The token-cost architecture that makes defensive AI tractable: agent fleets routing easy tasks to cheaper models, prompt caching, RAG against the graph instead of the whole repo, structured JSON in place of prose. Where the tokens go and where they should not.
A diagnostic for the three failure modes every program ends up in. Scanners multiplying without correlating. Backlog growing faster than burn-down. The coding agent treated as a human developer. Plus the open-source skill repository and the public reference architecture to start from on Monday.
The Worm That CI/CD Was Never Built to Stop what last two years of malware has (not) teach us
Between late 2025 and June 2026, TeamPCP ran the most methodically engineered software supply chain campaign on record. Not the noisiest — the most methodical. Across npm, PyPI, GitHub Actions, Docker Hub, and IDE integrations, they refined a single operational insight: the entire DevSecOps toolchain, from lifecycle hooks to OIDC signing to AI coding assistants, can be turned against the developer running it. Zero CVEs were assigned across any wave. Every standard check passed. Packages were signed. Provenance was verifiable. The code was malicious.
This talk is a two-year technical autopsy.
It covers three campaign generations. First, Shai-Hulud V1/V2 — the proof-of-concept npm worm that hit ~700 malicious package versions, 25,000+ attacker-abused GitHub repositories, and 37 organizations in under 24 hours. Then Mini Shai-Hulud and the OIDC pivot — packages published with cryptographically valid Sigstore provenance, with TanStack, Mistral AI, Bitwarden CLI, OpenSearch, and Guardrails AI all hit in the same wave. Then Miasma, released open-source in June 2026: it targets 13 AI coding assistants including Claude Code, Copilot, Gemini CLI, Cursor, and Amazon Q, injects persistence into SessionStart hooks that survive tool reinstallation, and uses prompt injection via instruction files to execute payloads silently. The AI isn't compromised. It's following its own config.
The session traces how TeamPCP's tradecraft changed across waves. Early campaigns used postinstall hooks and GitHub token abuse. Later waves introduced operational polymorphism — filenames, execution engines, and exfiltration channels rotate with each release while the kill chain structure stays constant. That distinction is what makes hash-based detection useless and behavioral detection mandatory. The Mini Shai-Hulud wave showed that OIDC Trusted Publisher configurations can be abused to produce Sigstore-verified provenance for backdoored packages. npm audit signatures returns PASS. SAST returns clean. CVE database: nothing. Miasma went further still — GitHub's public commit search API doubles as a command-and-control channel, no dedicated infrastructure needed.
The technical anatomy section covers polymorphic loaders, credential harvesting depth, four-level exfiltration fallback, GitHub Actions impersonation, the DEADMAN_SWITCH extortion mechanism, and the --ignore-scripts bypass. Then detection and defense — not generic hardening advice, but SIEM queries derived from hardcoded strings in the malware, and controls mapped to specific code locations with implementation effort measured honestly.
The analysis used Phoenix Purple, an AI-powered code intelligence layer that built a semantic graph of the Miasma codebase (14,027 nodes, 17,530 edges) and traced the full kill chain across 60+ source files. The methodology section covers what agentic code analysis adds to malware research — and where it still falls short.
Attendees leave with: a working taxonomy of supply chain techniques that CVE tooling structurally cannot see, SIEM detection rules grounded in campaign source code, and a prioritized hardening checklist verified against the malware.
SAY NOT TO VULN: Scaffolding, Guardrails, and Keeping Vulnerabilities Out of Agentic Code
Two things broke at the same time. AI now writes most of the code your team ships, and most AppSec programs are still optimised for the world where humans wrote it. Median time to exploit is at zero days. Median time to triage is still measured in weeks. The gap is not closing. It is widening every quarter the agent ships more code.
Most of the AI-AppSec talk circuit reaches for the same answer: throw a frontier model at the PR review and hope. That works until the bill arrives. $25 per Opus review across a real engineering org bankrupts the budget before it catches anything you would not have caught with a decent SAST rule. The bigger problem is more boring: nobody knows who owns the asset, where the agent is allowed to run, or which findings actually map to production. You cannot AI your way out of a broken ownership model.
This talk is the field guide for the other half of the problem. The half where AppSec works because the basics work. I will walk through what "doing the basics right" actually looks like in 2026: where the agent should live and where it should not, how to attribute work to a team that can act on it, what a Skill (.mdc, AGENTS.md, .cursorrules) needs to contain to stop a vulnerability before the agent writes it, and what an Allow / Block / Verify gate on the supply chain looks like in production. Then I will show where AI earns its place in the stack: finding the vulnerabilities your scanners miss because they cannot read the graph, generating remediation as a single PR or as a 200-repo campaign, and mapping the threats that actually apply to your stack rather than the ones the CVE feed thinks should worry you.
The thesis fits on one slide. Vibe coding will introduce vulnerabilities. Vibe coding with scaffolding can prevent more vulnerabilities than the agent would have produced. The agent is not the enemy. The agent without a fence is the enemy.
You leave with a buildable scaffolding pattern, four reviewer checks the agent can run before the PR opens, the attribution model that turns 112,000 raw findings into 300 things a team can actually fix, and the 90-day rollout plan with the metrics that show the program working before the dashboard goes green.
Key discussion points
1. Where the agent lives, and where it should not.
The coding agent shares a process with your shell, your credentials helper, your editor, your package manager, and your environment variables. Every subsystem the agent touches is now in scope for the agent's threat model. I will walk the audience through the three places teams put the agent today (IDE plugin, terminal CLI, hosted "agent platform"), what each one inherits in terms of trust, and the architectural checklist for deciding what a coding agent gets to talk to. The recent CVE clusters (IDEsaster's 24 CVEs across 10 AI coding IDEs, the Claude Code TERMINAL injection chain, the Cursor / Cline / Copilot prompt-injection class) all share one root cause: the agent runs with developer privilege but without the developer's safety controls.
2. Attributing work to the right team.
The #1 reason AppSec programs stall is not the scanner. It is that nobody owns the finding. I will show the four-problem model: attribution (which team), lineage (which build), traceability (which deploy), code-and-cloud reachability (does the path actually exist in production). The honest version of this is unglamorous. Most of it is plumbing. Most of it is fixing the CMDB, the SBOM, and the deploy manifest before AI gets near the pipeline. I will show a real example where a 112K-finding queue compressed to 300 actionable items because attribution was fixed first, not because a model rewrote the queue.
3. Doing the basics well, before AI.
The boring controls that work. Secure defaults in the framework. Auth dependency on every route, not most. Validated input at the boundary, not in the controller. Secrets out of localStorage. SBOM at build, not at deploy. Pinned dependencies with a freshness gate (no package under N hours old, no maintainer change in the last 7 days). These are not new. They are the controls that stop the AI-class attacks too. I will pair each control to a specific incident from the last twelve months where its absence was the root cause.
4. Where the Skill / scaffolding layer earns its keep.
A Skill is a versioned, scoped, auto-loaded rules file the coding agent reads before it writes a line of code. 00-meta.mdc defines how rules are written. 10-repo-structure.mdc is the authoritative folder map so the agent does not hallucinate file paths. 11-tech-stack.mdc is parsed from package.json so the agent does not invent libraries you do not use. 21-security.mdc is the security checklist the reviewer agent runs before the PR opens: auth dependency, innerHTML sanitisation, outbound fetch / SSRF, localStorage writes, SQL parameterisation, security headers. I will show a real scaffold from an open-source repo, the diff it forces, and what happens to a "vibe-coded" PR when the scaffold is in place. This is the central buildable artefact of the talk.
5. Where AI earns its place in the stack.
Three jobs, in order of how badly people get them wrong.
Identify vulnerabilities the scanner missed. A frontier model against a code graph compresses 100 static findings to 8 hypotheses, three of which become real bugs. The trick is the graph, not the model. I will show the maths and the failure modes (false positives without triple-pass validation, token costs without graph compression).
Help with remediation, single and bulk. Single remediation as a contextual PR with the patch, the test, and the threat context. Bulk remediation as a Log4j-style campaign across 200 services with one approval gate, ownership-attributed, with a rollback plan. The honest limit: bulk only works when attribution is already clean.
Map threats that actually damage you. CWE to CAPEC to MITRE ATT&CK to known threat actor, anchored to your stack. Not the OWASP Top 10 in the abstract. The five techniques that are exploited against your specific framework, your specific cloud, your specific industry, this quarter.
6. Bonus thesis: vibe coding versus vibe secure coding.
Same agent. Same prompt. Different outcome. With scaffolding, the agent has to consult the rules file before writing the route. Without scaffolding, the agent writes the route the way the training data biases it to. I will run the side-by-side on stage. Same task, no scaffold versus scaffold. The scaffolded version produces fewer vulnerabilities than the median human developer in the team it replaced. That is the line that should make people uncomfortable and the line that should make the OWASP community take this layer seriously.
Takeaways for attendees
A mental model for where the coding agent belongs in your architecture and what it is allowed to touch. With the checklist. With the recent CVEs that show what happens when the checklist is wrong.
A working attribution model. Four problems, one diagram, four sources of truth. The thing that turns the backlog from a triage burden into a queue an engineer can act on without a meeting.
A Skill / scaffolding template you can fork on Monday. Real .mdc examples, real reviewer-agent checks, real before-and-after diffs from a public repo.
The economic argument for graph-based AI in AppSec. Why brute-force LLM review bankrupts the program and what makes context-aware review affordable. The maths, not the marketing.
Three places to put AI in your AppSec stack and three places to keep it out. With the failure modes for each.
The 90-day rollout plan with four metrics a non-security stakeholder can read. Prevention rate above 60% on AI-generated PRs. Block rate 5 to 15% (zero means the gate is off). Malicious packages blocked per month, trending down at steady state. Burn rate positive at day 90 (findings closed per week greater than findings created per week).
A diagnostic for which control to install first based on the bottleneck you actually have. PR velocity, backlog size, agent adoption, or supply chain. Nobody leaves with a generic checklist.
Mythos-Ready: Close the Tap, Burn the Backlog. Six controls for the AI vulnerability storm
In April 2026, Anthropic's Mythos model autonomously produced working exploits against 72.4% of the vulnerabilities it discovered on Firefox's JavaScript shell. Over 99% of those findings are unpatched today. Twelve Project Glasswing companies have that capability. The replication papers are public. Commodity models are six months behind, not five years.
Mean time-to-exploit dropped to seven days last quarter, down 81% from 2025. The fitted decay curve from Phoenix exploit intelligence projects one day by 2028 and one hour by 2032. Forty-one percent of new code on GitHub is AI-generated. The 40,000-finding backlog you remember from two years ago is now 400,000 in most enterprises, and I have personally walked into orgs running four million. Triaging four million by hand takes 8,300 engineer-days a year. Nobody has that headcount, and nobody is getting it. The 30, 60, and 90-day patching SLAs your program runs on were calibrated for the 2018 curve. They are already three orders of magnitude behind the actual speed of exploitation, and the gap widens every quarter.
This keynote is the operational answer.
The Mythos-Ready program, published by the Cloud Security Alliance, SANS, [un]prompted, and the OWASP GenAI Security Project, with the companion playbook from Phoenix Security, has two halves that meet in the middle. Close the tap on the left. Burn the backlog on the right. Six controls. One knowledge graph underneath. No Glasswing budget required.
We walk the architecture left to right, with each control colour-coded so the audience builds the mental map once. Before code merges, Skills bind the coding agent to architectural rules at the design stage, a Secure PRD generator shifts threat modelling to the requirements phase, malware and CVE intelligence acts as an MCP plugin at install time, and graph-aware code scanning runs at the agent and at the pull request. After code merges, ownership attribution routes findings to the team that owns the asset, reachability and threat intelligence drive prioritization, grouped remediation turns twelve PRs into one, and agentic exploit hunting finds the toxic combinations no individual scanner sees on its own.
If attackers have reasoning, defenders need reasoning. Reasoning at scale is only economical against curated context, not the open web. The same code graph, security graph, and architecture graph that lets Mythos chain primitives across files, services, and packages lets your defensive tooling see your own exposure and close it in the same timeframe. Same graph. Same reasoning. Different output. That is the economic foundation that makes defensive AI affordable outside Glasswing.
You will leave with a 90-day deployment plan, four executive metrics reportable to a board without a glossary, an open-source skills repository you can clone on Monday morning, and a direct answer to the question every CISO in the room is asking right now: when commodity models reach Mythos-class capability six months from now, will my program absorb it or react to it?
akeaways for Attendees
* A clear architecture for defending against AI-speed adversaries without an AWS-scale security budget. Six controls, one knowledge graph, composable by design.
* The vocabulary and proof points to take to a CISO and a board on Monday morning. Why CVSS-first is obsolete, why reachability-first is the only viable replacement, and how to frame the metric optics that get worse before they get better.
* Practical implementation guidance for binding security to coding agents at the design and generation stages. The open-source skills repository, the PreToolUse hook pattern, and a working Secure PRD generator you can clone today.
* A working model for grouped remediation that engineering will actually accept. The math behind one PR for twelve fixes, and the customer numbers that prove it.
* A diagnostic framework to identify which of the six controls your program is missing right now, and the install order based on your specific bottleneck, whether that is PR velocity, backlog size, agent adoption, or supply chain risk.
* The Vulnapocalypse-Ready badge audit. Six controls in production means you wear the badge. Anything less means procurement starts now, because the curve does not wait for budget cycles.
Frontier Vulnerabilities, Burning down the backlog with and bridging the gap between vulnerability i
Exploitation timelines have collapsed. Median time-to-exploit for newly disclosed vulnerabilities is trending toward zero. Attackers are weaponizing CVEs the same day they're published — sometimes before a CVE ID exists. CVE volume is past 380,000 records with 40–48K new entries per year. Scan, triage by CVSS, open a ticket: that workflow is dead.
The bigger shift is in the attack surface itself. Threat actors aren't just exploiting known CVEs. They're publishing backdoored packages on npm, compromising maintainer accounts, deploying self-propagating supply chain worms, and running C2 over blockchain infrastructure that nobody can seize. The Axios maintainer compromise, Sha1-Hulud, TeamPCP — all happened in the last six months. All moved faster than any advisory-based workflow could respond.
The vulnerability lifecycle in a world of agentic AI and automated exploitation has fundamentally changed. Threat intelligence and vulnerability management can't keep running as separate disciplines. CTI and malware intelligence need to feed directly into prioritization.
This talk walks through how to do that in practice. I'll cover Phoenix Blue — a free vulnerability intelligence feed aggregating 15+ sources (NVD, CISA KEV, EPSS, Shadowserver, GreyNoise, OpenSSF malicious packages, and more) — and how it powers a threat-centric approach to prioritization. The core of the talk is scoring: how a model that fuses real-time exploitation evidence (honeypot observations, in-the-wild scanning, ransomware associations) with predictive signals (EPSS, Time-to-Exploit cohort patterns, Exploit Acceleration Index) separates the CVEs that are actually burning in production from the ones that just look scary on a report.
We'll dig into reachability analysis — code, library, container, runtime — and why it changes the remediation playbook for containers, where "just upgrade the package" is often wrong, unsafe, or doesn't exist. I'll connect CTI to remediation decisions directly: what's actively dangerous, what's theoretical, what needs compensating controls because patching is slow. And I'll show how agentic LLM enrichment (with dual-model adversarial validation to catch hallucinations) rewrites noisy scanner output into fix-oriented guidance at scale, and how agentic remediation for library upgrades gets dramatically better when you gate it on reachability and production relevance.
The end goal: a CTEM framework on three pillars — ownership attribution, vulnerability attribution, remedy attribution — where every finding is scored by what's being exploited in the real world, not what could theoretically be exploited on paper.
Talk Breakdown:
1. Exploitation timelines collapsing to zero — the data, the cases, what it means for prioritization workflows
2. The attack surface moved: malware, supply chain compromise, and threat actor behavior are the problem now, not just CVE counts
3. Feeding CTI and malware intelligence into the vulnerability pipeline (Phoenix Blue, free, 15+ sources)
4. Prediction vs. evidence: the dual-signal scoring model and how it separates real threats from noise
5. Reachability analysis and code-to-cloud tracing for routing fixes to the right team
6. Container patching: why it's different and how to stop getting it wrong
7. AI-CTI at scale — agentic LLM enrichment with adversarial validation that catches hallucinations
8. Agentic remediation for libraries, gated by reachability
9. CTEM three pillars: right team, right vulnerability, right remedy, right context
What Attendees Walk Away With:
* A clear picture of why time-to-exploit at zero changes prioritization fundamentals, and why CVSS on its own was never going to work.
* How to wire threat intelligence and malware intelligence into vulnerability management instead of running them as parallel programs.
* The prediction-and-evidence scoring model — what's actually burning versus what's noise — with specifics on how the signals compose.
* A method for combining reachability with code-to-cloud tracing so remediation lands on the right team with less alert fatigue.
* How AI-CTI and agentic remediation scale fix generation without producing garbage, and the adversarial validation architecture behind it.
* A CTEM blueprint that turns vulnerability management into measurable exposure reduction.
Navigating the Challenges of Risk-Based Vulnerability Management in a Cloud-Native World
2015 to today we changed the way we build things...containerized environments, and modern software development practices has redefined the landscape of cybersecurity. With this shift, vulnerability management faces unprecedented challenges in terms of scale, complexity, and data consistency. In this presentation, two leading experts delve into the intricacies of adopting a risk-based approach to vulnerability management, focusing on practical strategies and emerging methodologies in the enterprise.
### Key Topics:
- **The Inconsistency of Data**: Fragmented and siloed security data often hampers efforts to prioritize vulnerabilities effectively. The presentation explores strategies to consolidate and normalize data from disparate tools and environments, enabling a unified view that supports informed decision-making.
- **Vulnerability Management at Scale**: Managing vulnerabilities in sprawling, dynamic infrastructures demands innovative approaches. The speakers share insights into automating prioritization and remediation workflows, addressing the unique challenges of containerized and server-less architectures.
- **Reachability Analysis**: Identifying exploitable vulnerabilities through reachability analysis has emerged as a game-changer. The panel discusses how contextualizing vulnerabilities within the software supply chain and runtime environments can help organizations focus their resources on the most critical risks.
### Learning Objectives:
Attendees will gain a deeper understanding of:
- How to overcome the barriers posed by inconsistent data in vulnerability management workflows.
- Best practices for managing vulnerabilities across diverse and rapidly scaling environments.
- The value of incorporating reachability analysis into risk-based prioritization to reduce noise and focus on actionable threats.
This session is addressed to leaders who are looking at scaling vulnerability management in an organization, bringing code, cloud, and traditional attack paths under a single view the session has practitioner-to-practitioner use cases and stories to bring reality.
Let's stop fixing fighting over Vulns : A Threat-Centric View of Application and Cloud Security
Application security vulnerabilities and cloud/infra vulnerabilities have been historically divided. One team talks about MITRE&ATTACK, Threat Actors, and exposure, and the other team (appsec) talks about developer relationships, security-centric approaches, shift left, CWE, etc…
CISOs are confused about how to create metrics and initiatives. Should vulnerability management/exposure management and application security be really separated?
The gap is real! As the organization starts its journey into the cloud and containerized world,d there is a clear divide between development teams and security operations (SecOps) . These two worlds are really part of the same, each critical to the cybersecurity ecosystem, and often struggle to find a common ground for effective communication and collaboration. This talk takes a threat-centric approach to understanding and addressing these challenges, offering actionable insights to align these teams and strengthen your security posture.
Key Discussion Points:
1. The Journey of Application and Cloud Security Teams:
2. The CWE Challenge complexity and completeness
3. The Power of Patterns / Weakness / Threat Impact and Patterns
• How focusing on root causes and recurring patterns in vulnerabilities drives maturity in security practices.
• Using pattern recognition to prioritize critical vulnerabilities and reduce noise.
4. Context is Key
• Moving beyond generic vulnerability management to focus on deployment context:
5. A Path Forward: Threat-Centric Maturity:
• Leveraging threat-centric strategies to unify teams under a shared understanding of risks.
Future peak: Using AI and automated tools to analyze, categorize, and prioritize vulnerabilities in context.
Takeaways for Attendees:
• Understand how a threat-centric view can align development and security operations for better collaboration.
• Learn the importance of focusing on deployment context to prioritize vulnerabilities effectively.
• Discover how AI and pattern recognition can simplify complex frameworks like CWE and drive actionable insights.
• Explore practical strategies to mature application and cloud security programs by bridging gaps between teams.
Data:
CISA KEV: https://phoenix.security/what-is-cisa-kev-main/
Exploit in the wild: https://phoenix.security/what-is-exploitability/
OWASP/Appsec Vulnerability: https://phoenix.security/what-is-owasp-main/
CWE/Appsec Vulnerabilities: https://phoenix.security/what-is-cwe-main/
CWE over the years
https://phoenix.security/cwe-top-25-comparison-dataset/
https://phoenix.security/cwe-top-25-2024-2/
https://phoenix.security/understanding-the-2023-cwe-top-25-most-dangerous-software-weaknesses-and-application-security-patterns-over-the-years/
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top