

About us
OWASP is moving from Meetup to it's own platform to ensure you don't miss out on our community events please follow us over on LinkedIn where we signpost to the new platform once it is ready.
In the interim we will be posting events on LinkedIn Cyber Peterbrough page.
www.linkedin.com/company/cyberpbo
See you on the other side!
# Who is the OWASP® Foundation?
The Open Web Application Security Project® (OWASP) is a nonprofit foundation that works to improve software security. Through community-led open-source software projects, hundreds of local chapters worldwide, tens of thousands of members, and leading educational and training conferences, the OWASP Foundation is the source for developers and technologists to secure the web.
- Tools and Resources
- Community and Networking
- Education & Training
For nearly two decades corporations, foundations, developers, and volunteers have supported the OWASP Foundation and its work. Donate, Join, or become a Corporate Member today.
Upcoming events
6

Cyber Peterborough Presents: A Tech Deep Dive
The Brewery Tap, 80 Westgate, Peterborough, GBWe're buzzing for this one - join us as we ask the questions - what happens when AI actually hits production? Cyber Security meets AI and it's not one to miss!
---
AGENDA_
- 5:30pm: Arrival, social & take seats
- 6:00pm: Welcome to Cyber Peterborough
- 6:15pm: Harry with From Prototype to Production: Building Reliable AI Tools
- 7:00pm: Networking Break
- 7:30pm: Francesco with Vulnapocalypse
- 8:15pm: Networking Break
- 8:30pm: CyberPbo News & Wrap
- 8:45pm-10pm: Social
---
SPEAKERS_
- Harry Wetherald - CEO & Co-Founder @ Maze
- Francesco Cipollone - CEO & Co-Founder @ Phoenix Security
---
SPEAKERS BIOs_
Harry Wetherald - CEO & Co-Founder @ Maze
Talk: From Prototype to Production: Building Reliable AI ToolsEvery week there's a new story about a company replacing a whole workflow with a few
prompts. Building with AI is one of the most exciting things happening in software right now, and
we agree. It's why we built Maze. We knew it would be hard, but some challenges still surprised
us. This session walks through what we learned, so you don't have to learn it the hard way.It's relatively easy to build a tool that works a few times. You prompt an LLM, iterate for a few
rounds until it works, and ship the MVP. That's the 80% almost anyone can reach now.So what does the last 20% look like? This is where most AI builds fall apart, and getting that last
stretch of consistency and reliability right is what separates a demo that impresses from
something your team can run in production. The same question, asked a few different ways, has
to come back with the same answer every time. It has to hold up on inputs you never thought to
test.We'll walk through how Maze's own agents work now versus when we started building,
covering:- How you check whether an agent is even reliable.
- What it costs to run investigations at scale, and how we brought that down.
- The data pipeline behind every agent that nobody warns you about.
- How a newer model can walk in and break results you were sure of.
- The mix of skills a project like this takes.
You will leave with...
You'll leave able to judge your own build honestly, and be clearer on what the right path is for
your team. Bring your questions and your skepticism.---
Francesco Cipollone - CEO & Co-Founder of Phoenix Security
Talk: Vulnapocalypse Chill pill, Close the Tap, Burn the Backlog: 6 Controls Framework for the Agentic SDLCBetween 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 pointsThe 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 is the knowledge graph 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 does the same graph that scans the PR also write the remediation, and why is economics 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.
You will leave with...
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.
---
We're buzzing for this one - see you soon.
Thank you,
Ryan & Mark22 attendees
Past events
41

