{"$schema": "https://c3voc.de/schedule/schema.json", "generator": {"name": "pretalx", "version": "2026.3.0.dev0", "url": "https://talks.devopsdays.org"}, "schedule": {"url": "https://talks.devopsdays.org/halifax-2026/schedule/", "version": "0.8", "base_url": "https://talks.devopsdays.org", "conference": {"acronym": "halifax-2026", "title": "DevOpsDays Halifax 2026", "start": "2026-09-29", "end": "2026-09-29", "daysCount": 1, "timeslot_duration": "00:05", "time_zone_name": "America/Halifax", "colors": {"primary": "#48bd86"}, "rooms": [{"name": "Volta HQ", "slug": "273-volta-hq", "guid": "6e7b21f2-4a80-5857-847b-05410e23e9ef", "description": "Volta Office 1800 Argyle St Unit 801, Halifax, NS B3J 3N8", "capacity": 390}], "tracks": [{"name": "Quantum Computing", "slug": "225-quantum-computing", "color": "#0A3470"}, {"name": "Open source tools and technologies", "slug": "226-open-source-tools-and-technologies", "color": "#08752F"}, {"name": "Other", "slug": "227-other", "color": "#B9AFAF"}, {"name": "Open Spaces", "slug": "228-open-spaces", "color": "#BEBC14"}, {"name": "Automation", "slug": "216-automation", "color": "#000000"}, {"name": "Cloud Native", "slug": "217-cloud-native", "color": "#2A80D6"}, {"name": "Security", "slug": "218-security", "color": "#E51919"}, {"name": "Monitoring and Observability", "slug": "219-monitoring-and-observability", "color": "#15E0DE"}, {"name": "Testing", "slug": "220-testing", "color": "#71E910"}, {"name": "Collaboration", "slug": "221-collaboration", "color": "#171BEE"}, {"name": "Artificial intelligence (AI) and Machine Learning (ML)", "slug": "222-artificial-intelligence-ai-and-machine-learning-ml", "color": "#830D8B"}, {"name": "Edge Computing", "slug": "223-edge-computing", "color": "#DC6BE3"}, {"name": "Serverless Computing", "slug": "224-serverless-computing", "color": "#6F0D0D"}], "days": [{"index": 1, "date": "2026-09-29", "day_start": "2026-09-29T04:00:00-03:00", "day_end": "2026-09-30T03:59:00-03:00", "rooms": {"Volta HQ": [{"guid": "4de7811c-2efb-5b5c-b6eb-9922944437a1", "code": "HHRBLC", "id": 6477, "logo": null, "date": "2026-09-29T09:30:00-03:00", "start": "09:30", "end": "2026-09-29T10:30:00-03:00", "duration": "01:00", "room": "Volta HQ", "slug": "halifax-2026-6477-design-principles-api-vs-mcp", "url": "https://talks.devopsdays.org/halifax-2026/talk/HHRBLC/", "title": "Design Principles: API vs MCP", "subtitle": "", "track": "Artificial intelligence (AI) and Machine Learning (ML)", "type": "Regular Talk", "language": "en", "abstract": "As adoption of the Model Context Protocol (MCP) accelerates, many teams are building MCP servers using familiar API design patterns - CRUD-style tools, exposed resources, and thin wrappers over existing APIs. While this approach can function, it does not maximize the value MCP is designed to unlock. MCP is not an API replacement; it introduces a different model built around capabilities, constraints, and agent-driven orchestration.\n\nThis talk explains why API-oriented designs limit MCP\u2019s effectiveness, even when they \u201cwork\u201d. We\u2019ll contrast traditional API principles, where deterministic clients orchestrate workflows with MCP design principles, where autonomous agents reason over narrowly scoped capabilities. Using vendor-neutral examples from deployment and operations workflows, I\u2019ll show how to design MCP tools that are minimal, safe, and agent-native, and clarify when MCP provides more value than an API.", "description": "Many organizations are approaching MCP server design by exposing existing APIs through MCP with minimal adaptation. The result is often a collection of CRUD tools, thin API wrappers, and overly broad capabilities that technically function but provide limited value to AI agents.\n\nThis session examines the architectural differences between traditional APIs and MCP and explains why design approaches that work well for human-operated systems frequently become anti-patterns when applied to agent-driven workflows.\n\nThe talk introduces four practical MCP design principles:\n\n- Capabilities, Not Primitives  \n- Intent-Based Interfaces  \n- Minimal Capability Surfaces  \n- Observable Operational Intent\n\nAttendees will see how these principles influence tool design, authorization models, operational safety, and agent reasoning. The session also explores common MCP anti-patterns, including CRUD tools, thin API wrappers, and overexposed power, demonstrating how they increase complexity and reduce the effectiveness of AI agents.\n\nRather than focusing on a specific vendor, framework, or implementation, the talk uses real-world deployment and operations scenarios to illustrate the concepts. Attendees will leave with a practical framework for deciding when MCP is appropriate, how to structure MCP tools effectively, and how to build systems that are both agent-friendly and operationally safe.\n\nThis session is intended for platform engineers, API designers, infrastructure engineers, and developers who are building or evaluating MCP servers and want to move beyond simply exposing existing APIs to creating truly agent-native capabilities.", "recording_license": "", "do_not_record": false, "persons": [{"code": "HKLEFS", "name": "RobBarnes", "avatar": "https://talks.devopsdays.org/media/avatars/L99FEL_vDtxl8N.jpeg", "biography": "Security focused Software Engineer and Developer Advocate from a DevOps background with over a decade of experience spanning multiple sectors. Idea incubator, big picture thinker and security innovator. Builder of OSS tools to empower developers to be secure by default. On a mission to lower developer\u2019s barriers to entry for security, remove passwords from workloads, and enable the next generation of engineers to further advance the security industry.", "public_name": "RobBarnes", "guid": "36598c74-9e24-5acd-ab14-22688b0ff0cc", "url": "https://talks.devopsdays.org/halifax-2026/speaker/HKLEFS/"}], "links": [], "feedback_url": "https://talks.devopsdays.org/halifax-2026/talk/HHRBLC/feedback/", "origin_url": "https://talks.devopsdays.org/halifax-2026/talk/HHRBLC/", "attachments": []}, {"guid": "93a81f20-99f4-5c26-ab77-c02283cd7b4c", "code": "RJFCGA", "id": 6680, "logo": null, "date": "2026-09-29T10:30:00-03:00", "start": "10:30", "end": "2026-09-29T11:00:00-03:00", "duration": "00:30", "room": "Volta HQ", "slug": "halifax-2026-6680-building-a-platform-engineering-cli-tool-with-12-factor-principles", "url": "https://talks.devopsdays.org/halifax-2026/talk/RJFCGA/", "title": "Building a Platform Engineering CLI Tool with 12-Factor Principles", "subtitle": "", "track": "Open source tools and technologies", "type": "Regular Talk", "language": "en", "abstract": "It\u2019s been 14 years since the 12-Factor App methodology emerged to meet the needs of developers and operation teams alike, and yet unlike many other things in our industry, it\u2019s still relevant!. In fact, it\u2019s so fundamental to the \u201ccloud-native\u201d paradigm, you probably don\u2019t even notice your level of adherence on a regular basis. The flip side to this however, is that you also don\u2019t notice how much is skipped over\u2015the realm of Platform Engineering is no exception to this matter. This talk demonstrates embedding 12-Factor design principles into a command line interface (CLI) tool used for Platform Engineering\u2015written in pure Go. We\u2019ll also highlight some imperfections of this strategy.", "description": "Demonstration and building patterns for scalable, production-grade CLI tools with 12-factor app methodology\u2015the demo relates it to cloud-native Platform Engineering. Tooling used (Golang) includes Cobra for the CLI library, Viper as a decoupled configuration solution, and oapi-codegen for generating a client library from OpenAPI 3.0 spec, as to demonstrate some fruits of spec-driven design that don't require LLMs (or even GPUs for that matter).", "recording_license": "", "do_not_record": false, "persons": [{"code": "XQATFH", "name": "Ruckus Voxi", "avatar": "https://talks.devopsdays.org/media/avatars/M9HPYZ_1pOpI5f.webp", "biography": "Ruckus Voxi is a Sr. Developer Advocate for Akamai Cloud. As a passionate open source evangelist, they enable engineers to build and implement portable/cloud-agnostic workloads at scale. In other words, Ruckus is just having fun! They are also a longtime Arch Linux user and vegan, and never knows which to tell people first! Outside of work they dabble with graphic design, film, and Techno music production.", "public_name": "Ruckus Voxi", "guid": "34f91ebc-7542-5cc7-9dcc-f08b559fce42", "url": "https://talks.devopsdays.org/halifax-2026/speaker/XQATFH/"}], "links": [], "feedback_url": "https://talks.devopsdays.org/halifax-2026/talk/RJFCGA/feedback/", "origin_url": "https://talks.devopsdays.org/halifax-2026/talk/RJFCGA/", "attachments": []}, {"guid": "96c23755-0a62-5369-ab74-946af8ac1562", "code": "CPDUYE", "id": 6746, "logo": null, "date": "2026-09-29T11:00:00-03:00", "start": "11:00", "end": "2026-09-29T11:30:00-03:00", "duration": "00:30", "room": "Volta HQ", "slug": "halifax-2026-6746-beyond-configuration-rethinking-ci-cd-with-code-generated-pipelines", "url": "https://talks.devopsdays.org/halifax-2026/talk/CPDUYE/", "title": "Beyond Configuration: Rethinking CI/CD With Code-Generated Pipelines", "subtitle": "", "track": "Automation", "type": "Regular Talk", "language": "en", "abstract": "As CI/CD adoption grows, so does complexity. As companies grow, developers who don't stop to think about managing complexity eventually hit the wall: CI/CD pipelines that support dozens of use cases have become so intricate that changing them without breaking something turns into trial and error. \n\nPipelines must be run to be tested. With enough conditional logic, exhaustively testing every path becomes impossible. In an industry experience, one team I worked with maintained ~1,000 test projects they ran on a 24-runner farm that took a full day to execute, limiting them to one pipeline change per day. This is not the velocity DevOps has promised.\n\nThis talk introduces a different model: generating pipelines programmatically. By treating pipelines as a software engineering problem rather than YAML files, you can unit test pipeline logic, apply TDD, and use regression testing, all without running the CI engine. \n\nI'll explore how we can implement pipeline generators on GitHub and GitLab, and explore \"YAML-less\" pipelines that drop the CI-engine dependency entirely, and connect this to the broader shift seen in tools like Pulumi and Dagger.", "description": "CI/CD pipelines start simple, but as organizations scale, they become sprawling YAML configurations. They become brittle, hard to test, and even harder to change. This is even the case in organizations when templates are used to manage complexity. This talk introduces a different approach: generating pipelines programmatically using a general-purpose programming language.\n\nRather than maintaining hand-written YAML files, a pipeline generator produces CI/CD configurations as an output, the same way a compiler translates source code to machine code. This makes pipeline logic unit-testable, enables Test-Driven Development and opens the door to regression testing without ever running the CI engine. The pipeline generator produces a CI/CD configurations solely from analyzing a software project. For example, the presence of a \"pom.xml\" file indicates the programming language, the build system and the presence of third-party dependencies. \n\nThis approach is part of a broader industry shift already visible in tools like Pulumi (infrastructure as code), Dagger (container builds without Dockerfiles) and Paketo Buildpacks. Real-world adoption in 2018 in a music streaming company has shown up to 2x gains in developer efficiency, with teams better equipped to respond to incidents like Log4Shell through enforced golden paths. This approach has been kept under wraps until now.\n\nAttendees will leave with a concrete mental model and techniques for implementing pipeline generators on GitHub and GitLab, and their own system which doesn't use YAML at all.  Attendees will be left with a new perspective where CI/CD is treated as a software engineering discipline.", "recording_license": "", "do_not_record": false, "persons": [{"code": "H9LG9S", "name": "Alexandre-Xavier Labont\u00e9-Lamoureux", "avatar": "https://talks.devopsdays.org/media/avatars/DJ39BQ_gkI5cWO.webp", "biography": "Alexandre-Xavier Labont\u00e9-Lamoureux is a passionate IT professional and DevSecOps advocate based in Montreal, with over eight years of experience spanning DevOps, system administration, and cybersecurity. At Arctiq, he helps organizations build secure, efficient software by advancing Application Security (AppSec), Developer Experience (DevEx), and Internal Developer Platforms. A long-time open-source advocate, he dedicated over six years to volunteering in technology and science clubs at his university, fostering a culture of curiosity and collaboration among like-minded students. \n\nDeeply engaged in the cybersecurity community, Alexandre-Xavier has designed challenges for UnitedCTF, presented at Montr\u00e9hack, and mentored Canadian student teams at international competitions including the European Cyber Security Challenge (ECSC) and the International Cybersecurity Challenge (ICC). His accolades include the Cybertalent award from \u00c9cole de Cybers\u00e9curit\u00e9, wins at NorthSec and HackQc, and an OCTAS award for leading an innovative domotics project. A lifelong learner currently pursuing a Master's in Software Engineering at \u00c9TS with a focus on Internal Developer Platforms, Alexandre-Xavier holds knowledge sharing and developer experience at the core of everything he does.", "public_name": "Alexandre-Xavier Labont\u00e9-Lamoureux", "guid": "e858879a-3806-5744-bd0c-ab78a5a6c53f", "url": "https://talks.devopsdays.org/halifax-2026/speaker/H9LG9S/"}], "links": [], "feedback_url": "https://talks.devopsdays.org/halifax-2026/talk/CPDUYE/feedback/", "origin_url": "https://talks.devopsdays.org/halifax-2026/talk/CPDUYE/", "attachments": []}, {"guid": "e055b33c-5e2f-599f-b892-a57ebee6b294", "code": "U3QTY3", "id": 6759, "logo": null, "date": "2026-09-29T11:30:00-03:00", "start": "11:30", "end": "2026-09-29T12:00:00-03:00", "duration": "00:30", "room": "Volta HQ", "slug": "halifax-2026-6759-1-000-merge-requests-a-week-and-nobody-clicked-approve", "url": "https://talks.devopsdays.org/halifax-2026/talk/U3QTY3/", "title": "1,000 Merge Requests a Week and Nobody Clicked Approve", "subtitle": "", "track": "Security", "type": "Regular Talk", "language": "en", "abstract": "Container images ship with hundreds of packages you didn't choose, each one a potential vulnerability. When AI-assisted security research began surfacing real CVEs at an unprecedented rate, we had to rethink how our supply chain worked from the ground up.\n\nThis talk is the story of building a fully autonomous container supply chain that monitors upstream releases, detects vulnerabilities before CVEs are published, generates package updates, builds across architectures, runs tests, and ships patched images \u2014 processing roughly 1,000 merge requests per week without a human clicking approve. I'll share the architecture decisions that worked, the ones that didn't, and the surprising non-technical problems we had to solve along the way.\n\nYou'll leave with practical patterns you can apply to your own pipelines: RPM lockfiles for deterministic builds, reproducible builds that let anyone verify your output, policy-driven automation boundaries that separate \"the machine handles this\" from \"a human needs to look,\" and the guardrails that make autonomous merging safe rather than reckless.", "description": "The CVE landscape is changing fast. AI-assisted vulnerability discovery is pushing annual **CVE counts** past **60,000** and accelerating. Firefox fixed 423 security bugs in April 2026 alone \u2014 more than the previous 15 months combined.\n\nTraditional approaches to container patching \u2014 wait for a scanner report, open a ticket, assign someone, review, merge, release \u2014 **cannot keep up with this volume**.\n\n**Project Hummingbird** is **Red Hat's** answer to this problem: minimal, distroless container images with a fully autonomous supply chain. As the Builds and Releases workstream lead, I've spent the past year building the pipeline that makes near-zero CVE images possible at scale. This talk is not a product pitch \u2014 it's the engineering story behind the automation, told through the failures and surprises we encountered.\n\nI'll cover four main areas:\n\n**1. Why autonomous?** The math that convinced us humans-in-the-loop wouldn't scale. How we quantified the gap between CVE discovery rate and our team's patch throughput, and why \"hire more people\" wasn't a viable answer.\n**2. The architecture.** Hermetic builds with pinned RPM lockfiles (think Cargo.lock for containers). Two parallel upstream monitoring systems \u2014 dist-git sync and direct release watching \u2014 that create auto-merge merge requests. A dual-pipeline design where RPM builds feed container builds, each with their own test and validation gates.\n**3. What went wrong.** Reproducible builds sound simple until you discover RPM database journal modes, non-deterministic package installation ordering, OCI annotation sorting, and a dozen other sources of non-determinism that took months to solve. Policy boundaries that were too loose and too tight before we found the right line. The day we learned why you need a modification_status field on every package.\n**4. Patterns you can steal.** Lockfile-based dependency pinning for containers. Policy-driven auto-merge with explicit \"clean\" vs. \"modified\" classification. Reproducible build verification in CI (rebuild and compare on every merge request). SBOM generation as a build artifact, not an afterthought.\n\nThis talk is for anyone running containers in production who's tired of triaging base image CVEs. You don't need to adopt our exact toolchain \u2014 the patterns are portable to any CI/CD system. First-time attendees and experienced practitioners will both find actionable takeaways.", "recording_license": "", "do_not_record": false, "persons": [{"code": "H7V7FD", "name": "Scott Hebert", "avatar": "https://talks.devopsdays.org/media/avatars/LK3FEX_FHme3eR.webp", "biography": "Scott Hebert is a Senior Principal Software Engineer at Red Hat with over 15 years of experience in cloud-native infrastructure, container security, and DevSecOps. He served as an architect on Konflux, Red Hat's open source software supply chain security platform, and currently works on Red Hat Hardened Images and Project Hummingbird \u2014 a next-generation initiative to deliver ultra-minimalist, distroless container images that dramatically reduce CVE exposure in production environments.\n\nScott is passionate about making supply chain security practical and accessible for development teams, and brings a builder's perspective to the intersection of AI infrastructure and software integrity.", "public_name": "Scott Hebert", "guid": "ca72ab66-9c3e-5462-a240-92af4f547ef6", "url": "https://talks.devopsdays.org/halifax-2026/speaker/H7V7FD/"}], "links": [], "feedback_url": "https://talks.devopsdays.org/halifax-2026/talk/U3QTY3/feedback/", "origin_url": "https://talks.devopsdays.org/halifax-2026/talk/U3QTY3/", "attachments": []}, {"guid": "79e2c551-f4b4-5b8a-b51c-de8f7cf4a7ed", "code": "AZJZR8", "id": 6749, "logo": null, "date": "2026-09-29T13:00:00-03:00", "start": "13:00", "end": "2026-09-29T13:30:00-03:00", "duration": "00:30", "room": "Volta HQ", "slug": "halifax-2026-6749-w3c-arrm-a-ready-made-accessibility-roles-responsibilities-map-for-developers", "url": "https://talks.devopsdays.org/halifax-2026/talk/AZJZR8/", "title": "W3C ARRM: A Ready-made Accessibility Roles & Responsibilities Map for Developers", "subtitle": "", "track": "Collaboration", "type": "Open Spaces", "language": "en", "abstract": "Incorporating accessibility into your code and designs? Make it easy. The W3C has released the Accessibility Roles and Responsibility Mapping (ARRM) framework for WCAG 2.2. \n\nARRM breaks down the WCAG success criteria list into individual, plain-language tasks (\"checkpoints\") for Front-end Developers, UX and Visual Designers and Content Authors to do. \n\nIt help teams identify the primary, secondary and contributor owners of web accessibility requirements and best practices by role.  It's an official, ready-made, go-to resource your team can start using tomorrow.", "description": "Join me, a former UX Designer-turned-Accessibility Strategist, as I host a fun, interactive workshop to:\n\n1) introduce the ARRM Checkpoint List and identify the primary, secondary and contributor responsibilities for Front-end Developers (and the others).  \n2) share examples of the ARRM checkpoints and how a Primary owner might work with a Secondary owner to ensure an accessibility fix gets done. \n3) show you how to conduct the \"Role-based Decision Tree\" exercise (together or in teams), if an accessibility issue needs to be fixed, but there's no owner yet. Together we'll review some Issue examples, how to fix them, prioritize the fixes and who should own it (primary, secondary, contributor).  I'll provide an ARRM Spreadsheet Template to take away. \n\nBuild capacity, ownership and clarity about who's doing what, when and how.  Build a cultural comfort level around accessibility and inclusive design. Meet the WCAG 2.2 guidelines.", "recording_license": "", "do_not_record": false, "persons": [{"code": "RYXQLV", "name": "Jennifer Chadwick, CPACC", "avatar": "https://talks.devopsdays.org/media/avatars/LYGRSX_uwyHEjj.webp", "biography": "Jennifer Chadwick, CPACC is an award-winning senior digital accessibility strategist and coach. She works in Canada, UK, Europe and US.  Jennifer works closely with organizations understand the needs of users with disabilities and translates this into tasks that result in inclusive, delightful user experiences.  She develops action plans for product design, customer service, marketing, HR and procurement.\n\nJennifer has spoken at CSUN, AccessU, University of Toronto and the United Nations COSP11 and COSP15.  She co-chairs the W3C Accessibility Roles and Responsibilities Mapping (ARRM) Community Group and contributed to the standards WCAG Silver 3.0 and the Accessibility Conformance Testing Rules (ACT 1.0).", "public_name": "Jennifer Chadwick, CPACC", "guid": "b167d474-d968-5162-90a9-00e78da4925e", "url": "https://talks.devopsdays.org/halifax-2026/speaker/RYXQLV/"}], "links": [], "feedback_url": "https://talks.devopsdays.org/halifax-2026/talk/AZJZR8/feedback/", "origin_url": "https://talks.devopsdays.org/halifax-2026/talk/AZJZR8/", "attachments": []}, {"guid": "4315be92-2e37-5a8a-b0ff-2b4cff5d5842", "code": "ZLMDAB", "id": 7223, "logo": null, "date": "2026-09-29T13:30:00-03:00", "start": "13:30", "end": "2026-09-29T14:00:00-03:00", "duration": "00:30", "room": "Volta HQ", "slug": "halifax-2026-7223-building-effective-sandboxes-for-running-untrusted-llm-generated-code", "url": "https://talks.devopsdays.org/halifax-2026/talk/ZLMDAB/", "title": "Building Effective Sandboxes for Running Untrusted LLM-Generated Code", "subtitle": "", "track": "Artificial intelligence (AI) and Machine Learning (ML)", "type": "Regular Talk", "language": "en", "abstract": "As AI code-generation tools shift from auto-complete to autonomous code execution (code mode agents), platform engineers face a critical challenge: How do you safely execute arbitrary, untrusted code on your infrastructure?\n\nIn this talk, we will analyze the trade-offs of modern sandboxing mechanisms.", "description": "As AI code-generation tools shift from auto-complete to autonomous code execution (code mode agents), platform engineers face a critical challenge: How do you safely execute arbitrary, untrusted code on your infrastructure?\n\nIn this talk, we will analyze the trade-offs of modern sandboxing mechanisms.\n\n- Containers vs. MicroVMs vs. V8 Isolates: Performance, boot times, memory footprint, and security boundaries.\n\n- Deep Isolation:* Exploring Linux security primitives like* seccomp, eBPF, and ptrace-based sandboxes (sydbox).\n\n- Commercial & Open Source Ecosystem: A quick survey of tools like Docker Sandboxes, Apple Containers, E2B, and Daytona.\n\n- Decision Framework: A practical rubric to help platform teams choose the right isolation boundary for their specific latency and security profile.", "recording_license": "", "do_not_record": false, "persons": [{"code": "QNZUMM", "name": "Vagmi Mudumbai", "avatar": "https://talks.devopsdays.org/media/avatars/avatar_oJvuAK0.webp", "biography": "Vagmi Mudumbai is a technical leader, DevOps architect, and platform engineer with over 24 years of experience. He builds efficient distributed systems and platforms for software delivery.\n\nVagmi specializes in providing the architectural clarity and technical guardrails that allow companies to scale without breaking. He is a hands-on practitioner with deep mastery across a diverse stack including Rust, Go, Ruby on Rails, and TypeScript paired with the infrastructure expertise (Kubernetes, Terraform) across multiple clouds required to build resilient, production-ready environments. \n\nHe is currently the CTO at Urai. At Urai, he designed and built microVM and V8 isolate sandboxes for AI code execution engines.", "public_name": "Vagmi Mudumbai", "guid": "cc7a90cc-3b70-55b1-8716-5e17cbf404eb", "url": "https://talks.devopsdays.org/halifax-2026/speaker/QNZUMM/"}], "links": [], "feedback_url": "https://talks.devopsdays.org/halifax-2026/talk/ZLMDAB/feedback/", "origin_url": "https://talks.devopsdays.org/halifax-2026/talk/ZLMDAB/", "attachments": []}, {"guid": "9e88869c-6a29-5294-8348-245aca92f7eb", "code": "TULQWP", "id": 7225, "logo": null, "date": "2026-09-29T14:00:00-03:00", "start": "14:00", "end": "2026-09-29T14:30:00-03:00", "duration": "00:30", "room": "Volta HQ", "slug": "halifax-2026-7225-developing-security-systems-using-network-programmability", "url": "https://talks.devopsdays.org/halifax-2026/talk/TULQWP/", "title": "Developing security systems using network programmability.", "subtitle": "", "track": "Security", "type": "Regular Talk", "language": "en", "abstract": "[Placeholder abstract]\n\nTraditional network security relies on static, perimeter-based controls that struggle to keep pace with dynamic threats and increasingly fluid infrastructure. This talk explores how network programmability \u2014 through SDN controllers, programmable data planes (P4), and APIs exposed by modern network fabric \u2014 enables security teams to build systems that detect and respond in real time rather than relying on periodic rule updates.\n\nWe'll walk through practical patterns: using SDN control planes to dynamically reroute or quarantine suspicious traffic, leveraging P4-programmable switches for line-rate anomaly detection without offloading to slower control-plane processing, and building intent-based security policies that compile down to enforceable network state. A live demo will show an automated pipeline that ingests threat signals, computes a network-level response, and pushes updated flow rules to programmable switches in under a second \u2014 no manual firewall ticket required.", "description": "[Placeholder abstract]\n\nTraditional network security relies on static, perimeter-based controls that struggle to keep pace with dynamic threats and increasingly fluid infrastructure. This talk explores how network programmability \u2014 through SDN controllers, programmable data planes (P4), and APIs exposed by modern network fabric \u2014 enables security teams to build systems that detect and respond in real time rather than relying on periodic rule updates.\n\nWe'll walk through practical patterns: using SDN control planes to dynamically reroute or quarantine suspicious traffic, leveraging P4-programmable switches for line-rate anomaly detection without offloading to slower control-plane processing, and building intent-based security policies that compile down to enforceable network state. A live demo will show an automated pipeline that ingests threat signals, computes a network-level response, and pushes updated flow rules to programmable switches in under a second \u2014 no manual firewall ticket required.", "recording_license": "", "do_not_record": false, "persons": [{"code": "T7JJTN", "name": "Dr. Israat Haque", "avatar": "https://talks.devopsdays.org/media/avatars/7PNUWH_hHi52pS.webp", "biography": "Bio: Dr. Israat Haque is a Professor in the Faculty of Computer Science at Dalhousie University and the Director of the Programmable and Intelligent Networking (PINet) Lab.\u00a0Her work applies network programmability, system-level monitoring, and data-driven techniques to strengthen the security, sustainability, and performance of IoT, 6G, and AI systems, particularly in complex and dynamic environments. Dr. Haque has been recognized for both technical leadership and impact. She was named an ACM/IEEE N2Women Rising Star (2021) and received Digital Nova Scotia\u2019s Thinking Forward Award (2022) for developing highly skilled technology and security talent. In 2024, she received the Alumni Award from the University of Alberta. Dr. Haque has also been named among the 100 Brilliant and Inspiring Women in 6G 2026. She is an active contributor to the IEEE and ACM research communities and has served as an editor for IEEE Transactions on Vehicular Technology and IEEE Communications Magazine.", "public_name": "Dr. Israat Haque", "guid": "36edb193-8880-5093-8354-308924376ae1", "url": "https://talks.devopsdays.org/halifax-2026/speaker/T7JJTN/"}], "links": [], "feedback_url": "https://talks.devopsdays.org/halifax-2026/talk/TULQWP/feedback/", "origin_url": "https://talks.devopsdays.org/halifax-2026/talk/TULQWP/", "attachments": []}, {"guid": "9e56d45a-43e4-5eeb-bba9-f4bbe68f4666", "code": "98ZJQE", "id": 6650, "logo": null, "date": "2026-09-29T14:30:00-03:00", "start": "14:30", "end": "2026-09-29T15:00:00-03:00", "duration": "00:30", "room": "Volta HQ", "slug": "halifax-2026-6650-the-audit-proof-way-to-ignore-a-cve", "url": "https://talks.devopsdays.org/halifax-2026/talk/98ZJQE/", "title": "The Audit-Proof Way to Ignore a CVE", "subtitle": "", "track": "Security", "type": "Regular Talk", "language": "en", "abstract": "Your scanner found multiple vulnerabilities in your base image this morning, and your release is blocked until every one of them is triaged out of the queue. Most of them will never be fixed, and for most of them that is the correct outcome. \n\nThe catch: you work on government code, so you can't hand the problem to the tools built to solve it. \n\nThe agentic CVE-analysis platforms want to embed your source. The good commercial suites cost real money and still phone home. And the rules about AI and sensitive code are only getting tighter. \n\nSo this talk is about a question I had to actually answer on a live government program: how do you supercharge vulnerability triage using the most powerful tools available, without a single byte of privileged code or infrastructure leaving your boundary?", "description": "Most container CVEs on a Debian base aren't scanner errors. Modern scanners already consume the distribution's advisories and map backported fixes correctly. What they faithfully report is a long tail of vulnerabilities Debian has assessed and marked no-dsa: a documented decision not to issue a stable fix. Dismissing those is defensible, but only if you ground it in that decision rather than your gut, and re-check it when the decision changes, because no-dsa doesn't mean safe, it means someone accountable decided it was minor, and that can lag upstream or be wrong.\n\nThe catch on government code is doing all this without sending your images or source to a cloud model. The agentic CVE platforms reason brilliantly about whether your code reaches a flaw, by embedding your code. The good commercial suites cost real money and still phone home. And the rules on AI and sensitive code keep tightening. The insight that makes the problem tractable is knowing what's actually secret. A CVE, its package, and Debian's ruling are all public, so the most powerful tools available can synthesize them freely. What's privileged is the join: the fact that your specific protected image, in your protected GitLab instance, behind your gate, contains that package. That mapping never leaves the boundary. You assemble the affected list locally from data only you can see, enrich each public CVE with the best tooling you have, and stitch the result back onto your private findings at home. The model never sees your image, your repo, or the fact that you're the one affected, and it never makes the call.\n\nThe output is a work order, not a verdict, and it has two halves on purpose. The top half is settled fact: Debian's status with the link, the installed version versus the fixed version, and any place GitLab's stored guidance disagrees with the live source. Every line is independently verifiable, which is what grounds the decision. The bottom half is a tailored exploitability checklist, the right questions to ask before dismissing on exploitability grounds, generated from the public CVE and the generic app context, this is a .NET service on Debian, never from your source. The machine poses the questions; the human answers them inside the boundary. The result is faster triage that never pretends the model determined exploitability, and a structured record that keeps a distribution-grounded dismissal distinct from an internal-judgment one, because an auditor treats those very differently.\n\nThe reasoning is written back into GitLab alongside the human-readable comment, so the same artifact is both the human's prompt and the auditor's record. Then, on a schedule, every past disposition is re-checked against the current decision and the current image, so a finding you dismissed last spring resurfaces the day its basis changes. The dangerous findings aren't the ones in your queue, they're the ones you already cleared and stopped looking at.", "recording_license": "", "do_not_record": false, "persons": [{"code": "RVXZB7", "name": "Charl Cilliers", "avatar": "https://talks.devopsdays.org/media/avatars/3EJV3L_fOtHdyB.webp", "biography": "Charl Cilliers is a technology executive at Foci Solutions. He works in enterprise .NET and platform security, with a long-running interest in the layer where software meets hardware. Outside of work he's a maker and electronics tinkerer: 3D printers, CNC, SDR and a steady stream of microcontroller projects, usually with one of his kids nearby. He has a low tolerance for tools that generate work without reducing it, in roughly equal measure at the office and in the garage.", "public_name": "Charl Cilliers", "guid": "0c7aac71-dd45-5182-8ec3-cc42639b32f2", "url": "https://talks.devopsdays.org/halifax-2026/speaker/RVXZB7/"}], "links": [], "feedback_url": "https://talks.devopsdays.org/halifax-2026/talk/98ZJQE/feedback/", "origin_url": "https://talks.devopsdays.org/halifax-2026/talk/98ZJQE/", "attachments": []}, {"guid": "e0b28ed9-eee2-5614-ab61-f0640d8a1571", "code": "UARNZ3", "id": 7224, "logo": null, "date": "2026-09-29T15:30:00-03:00", "start": "15:30", "end": "2026-09-29T16:30:00-03:00", "duration": "01:00", "room": "Volta HQ", "slug": "halifax-2026-7224-open-space", "url": "https://talks.devopsdays.org/halifax-2026/talk/UARNZ3/", "title": "Open Space", "subtitle": "", "track": "Open Spaces", "type": "Open Spaces", "language": "en", "abstract": "Most devopsdays events are a combination of curated talks and self organized conversations. The self organized content is known as \u201copen spaces\u201d. Open Spaces give attendees the opportunity to talk about anything they\u2019d like. A person might suggest a topic they want to learn about, or one they feel like they can help others with. The topics range widely, from highly technical, to pure culture, to board games for networking.\n\nOpen space is the simplest meeting format that could possibly work.\nIt is based on (un)common sense of what people do naturally in productive meetings.\n\nhttps://devopsdays.org/open-space-format/", "description": "Most devopsdays events are a combination of curated talks and self organized conversations. The self organized content is known as \u201copen spaces\u201d. Open Spaces give attendees the opportunity to talk about anything they\u2019d like. A person might suggest a topic they want to learn about, or one they feel like they can help others with. The topics range widely, from highly technical, to pure culture, to board games for networking.\n\nOpen space is the simplest meeting format that could possibly work.\nIt is based on (un)common sense of what people do naturally in productive meetings.\n\nhttps://devopsdays.org/open-space-format/", "recording_license": "", "do_not_record": false, "persons": [{"code": "8X8WXC", "name": "Everyone", "avatar": null, "biography": null, "public_name": "Everyone", "guid": "29846368-068b-53a7-94bd-daa38c5a790f", "url": "https://talks.devopsdays.org/halifax-2026/speaker/8X8WXC/"}], "links": [], "feedback_url": "https://talks.devopsdays.org/halifax-2026/talk/UARNZ3/feedback/", "origin_url": "https://talks.devopsdays.org/halifax-2026/talk/UARNZ3/", "attachments": []}, {"guid": "f3ad3d51-0f9a-5aef-8526-9c3c86bf6bec", "code": "SKDQMM", "id": 6324, "logo": null, "date": "2026-09-29T16:30:00-03:00", "start": "16:30", "end": "2026-09-29T17:00:00-03:00", "duration": "00:30", "room": "Volta HQ", "slug": "halifax-2026-6324-let-agents-run-wild-inside-deterministic-guardrails", "url": "https://talks.devopsdays.org/halifax-2026/talk/SKDQMM/", "title": "Let Agents Run Wild \u2014 Inside Deterministic Guardrails", "subtitle": "", "track": "Serverless Computing", "type": "Regular Talk", "language": "en", "abstract": "AI agents are non-deterministic. They hallucinate, vary every run, and surprise you. The industry keeps trying to constrain them. I take the opposite approach: let agents run fully autonomous inside deterministic durable function workflows that guarantee the pipeline always completes. You already know how to operate deterministic workflows. Now use that skill to tame AI.", "description": "AI agents in production will hallucinate, take paths you didn't plan for, timeout, contradict themselves, and occasionally return poetry when you asked for JSON. And that's fine. As long as your orchestration is deterministic.\n\nWe stopped fighting non-determinism and started embracing it. We took our AI agents off the leash and wrapped them in durable function workflows that provide the guardrails: checkpoints, retries, timeouts, exactly-once execution. The agent can go wild inside each step. The orchestrator guarantees the pipeline completes.\n\nI walk through a real system where multiple AI agents reason and act autonomously. They take unexpected paths. They fail in creative ways. But the durable function workflow keeps the train on the tracks. It checkpoints state, fans out for parallel work, reconciles results, and recovers from failures automatically.\n\nAI in production is not a new operational paradigm. It's a non-deterministic step inside a deterministic workflow. And you already know how to operate deterministic workflows.", "recording_license": "", "do_not_record": false, "persons": [{"code": "UUBDWG", "name": "Eric D Johnson", "avatar": "https://talks.devopsdays.org/media/avatars/DXHYP8_ltj7CLn.webp", "biography": "Eric Johnson is a Principal Developer Advocate at AWS specializing in serverless and event-driven architectures. With 35+ years in technology and a passion for making the complex understandable, Eric has presented and keynoted at hundreds of tech conferences worldwide. He brings humor, energy, and hard-won production experience to every talk, and has been an early adopter of AWS durable functions for agent orchestration since their launch.", "public_name": "Eric D Johnson", "guid": "4e7e3098-0627-57e6-b97f-7f814caad506", "url": "https://talks.devopsdays.org/halifax-2026/speaker/UUBDWG/"}], "links": [], "feedback_url": "https://talks.devopsdays.org/halifax-2026/talk/SKDQMM/feedback/", "origin_url": "https://talks.devopsdays.org/halifax-2026/talk/SKDQMM/", "attachments": []}, {"guid": "0b25c6bb-3dec-59ba-8ab1-0f126de3df49", "code": "T9KEY3", "id": 6692, "logo": null, "date": "2026-09-29T17:00:00-03:00", "start": "17:00", "end": "2026-09-29T17:30:00-03:00", "duration": "00:30", "room": "Volta HQ", "slug": "halifax-2026-6692-tackling-alert-fatigue-with-slos-automation-and-machine-learning", "url": "https://talks.devopsdays.org/halifax-2026/talk/T9KEY3/", "title": "Tackling Alert Fatigue with SLOs, Automation, and Machine Learning", "subtitle": "", "track": "Other", "type": "Regular Talk", "language": "en", "abstract": "Alert Fatigue is real, and it impacts your team's ability to make decisions about the information they are seeing about your environment. Too many alerts, false positives, alerts that have been over-prioritized, all accumulate and overwhelm already busy teams. Improving your alerts and employing better methods for dealing with real-time information will spare your team and improve customer experience.", "description": "SLOs allow teams to prioritize the more impactful or important aspects of their services. Metrics that center the user experience gives teams focus and goals. Highlighting the metrics that matter most gives teams space to disable alerts that contribute nothing to overall customer happiness.\n\nAutomation gives us more hands to deal with more issues without taking time away from more interesting work. Machine Learning tools group alerts together and help add context when things are noisy and distracting.\n\nThese tools combined help teams tackle a common incident response problem - alert fatigue. Full Service Ownership teams looking to improve the quality of their services can experiment with their SLIs and SLOs to find the work that will benefit their systems the most while also preserving their own sanity. Prevent the stress and anxiety that can arise from unexpected system failures by setting clear expectations and allowing for planned responses to potential issues based on pre-agreed norms.", "recording_license": "", "do_not_record": false, "persons": [{"code": "YLECDC", "name": "Kat Gaines", "avatar": "https://talks.devopsdays.org/media/avatars/8HCMDP_HbVyAjE.webp", "biography": "Kat spent years leading technical support teams on the front lines of incident response before moving to the stage to talk about it. As Senior Manager of Developer Relations at PagerDuty, she leverages over 12 years of experience in the field to help teams communicate clearly when everything is on fire. She speaks and writes on the topics of sustainable incident management practices, cross-functional collaboration, and career development. When she's not wrangling incidents, she's wrangling two rabbits (Lupin and Ginny), a dog named Violet, and an ambitious collection of houseplants.", "public_name": "Kat Gaines", "guid": "d0b8ccf3-a8ad-5d55-9e1c-c714d921658e", "url": "https://talks.devopsdays.org/halifax-2026/speaker/YLECDC/"}], "links": [], "feedback_url": "https://talks.devopsdays.org/halifax-2026/talk/T9KEY3/feedback/", "origin_url": "https://talks.devopsdays.org/halifax-2026/talk/T9KEY3/", "attachments": []}]}}]}}}