Open Source Summit Korea 2026

You probably heard that SBOMs are helpful, but did you know that an SBOM only addresses a fraction of what can go wrong in your software supply chain? The SLSA (Supply Chain Levels for Software Artifacts) specification identifies 9 distinct threat areas, spanning from source code, all the way to package distribution. Most development teams address one or two of these and call it a day, leaving gaps that real-world attacks like SolarWinds and Log4J have already exploited. We understand that it is difficult to cover all aspects when it comes to the software supply chain.

How about we make this much easier? In this talk, we will present an overview of the modern software supply chain threat model, and show how you can provide integrity throughout the whole process of your software development life cycle. We will introduce an easy-to-setup, end-to-end open source stack, built from frameworks and tools within the CNCF/OpenSSF ecosystem.

Most dev tools die in obscurity because installation friction kills adoption before the first command is run. This talk provides a battle-tested playbook for solving that problem using evnx—a Rust CLI for validating and secret-scanning `.env "files"—as a real-world case study.

Launched in early 2026, evnx achieved thousands of cross-ecosystem downloads within weeks by treating distribution as a first-class engineering concern. The session breaks down a complete distribution matrix:

Registry Packaging: Using crates.io as a source of truth, Maturin for native Python wheels, and npm wrappers for platform-specific binaries.
OS Package Managers: Automating Homebrew formulas via cargo-dist, plus Scoop and Winget submissions.
Developer Integration: GitHub Actions with SARIF output, pre-commit hooks, and lightweight Docker CI images.
Supply-Chain Security: Leveraging PyPI Trusted Publishing (OIDC), provenance attestations, and cosign for signed containers.

Attendees will receive reusable GitHub Actions workflows and manifest templates from the public evnx repo to ship any Rust CLI across ecosystems without sacrificing security or maintainer sanity.

When global AI development being centralized around proprietary "black-box" models, the demand for Sovereign AI has become a national priority for many countries, including South Korea. True sovereignty requires more than just local data or local LLMs; it demands independence across the entire stack—from silicon up to the software services, as well as AI model itself. This panel challenges the misconception that global technology leaders are incompatible with national goals, demonstrating instead how open-source collaboration is the only viable path to technical and data independence as foundation for Sovereign AI.

Over the past decade, many organizations have established OSPOs to manage open source usage and compliance. However, building a sustainable open source culture requires more than policies and processes.

This session shares a 14-year journey of an OSPO that evolved from a contribution-focused group into a broader organization encompassing usage, compliance, and internal enablement.

It explores how open source practices were embedded into engineering culture through project incubation, developer engagement, and internal leadership programs. Over time, these efforts led to a shift where open source activities became self-sustaining, with teams proactively initiating projects and contributions.

The session also reflects on an unexpected outcome: talent mobility. As internal open source leaders grew, many moved on to new opportunities, revealing both retention challenges and the broader impact of cultivating open talent.

Key lessons include the balance between control and autonomy, the role of leadership in cultural change, and how open source can be viewed not only as a compliance requirement, but as a long-term investment in culture and organizational brand.

Artificial Intelligence is reshaping how software is developed and maintained. From code generation to automated reviews, AI tools are increasingly influencing how open source communities collaborate. This also introduces new challenges, including how to handle AI-generated contributions, maintain trust and code quality, and define governance for AI-assisted workflows.

In this session, we share experiences from the openEuler community in integrating AI into development processes, including AI-assisted code review, package maintenance, and community guidelines for AI usage, as well as work on frameworks such as Intelligence BooM.

We will discuss how these changes affect contributor workflows, what challenges maintainers face in practice, and what approaches have worked so far. The goal is to provide practical reference points for other open source communities exploring similar directions.

AI agents like Claude Code, Cursor, and Codex learn libraries via SKILL.md files, but these skills are currently unversioned, ungoverned, and unshared. We solved code dependency management with pip and npm — now it's time to solve it for AI knowledge.
This talk presents an open-source, package-manager-style system for agent skills. Skills are linked to their packages, versioned with semver, declared in skills.toml, and locked via skills-lock.toml — just like regular dependencies.
The CLI (skills add, install, lock, publish) feels native to any developer using pip or uv.
We'll cover:

The SKILL.md open standard (YAML frontmatter + Markdown) — model-agnostic and runtime-agnostic
Manifest format supporting version constraints, inheritance, and monorepo scoping
Resolver that enforces constraint narrowing across org hierarchies
Registry with publishing, discovery, approval workflows, and security scanning
Real cases where this prevented production incidents by keeping agents on correct, up-to-date patterns

Live demo: Add a skill, resolve dependencies, publish it, and watch a new engineer's agent instantly get the right knowledge - no onboarding docs required.

Computer science graduates are facing an increasingly difficult job market. Recent data shows a sharp decline in employment outcomes for computer science majors, highlighting the mismatch between what universities teach and what employers now demand. The traditional model of teaching syntax first and hoping students eventually build something useful is no longer working. In this keynote we argue that programming as we knew it is effectively dead. The future lies in AI-First programming, built on the simple loop of try, learn, and grow. Learners try building code with AI assistance, learn by unpacking the generated code and asking AI for detailed explanations, and grow by testing and extending real applications. This loop not only builds confidence but also ensures we grow the generation of AI engineers that companies are desperate to hire.

AI agents have no memory between sessions. Every conversation starts from zero. Git becomes the only persistent memory an AI agent can rely on. GitAIOps is the pattern built on this principle: Git is the memory, and a 4-layer architecture defines what goes into that memory.

I applied this to a production migration: 15 Helm releases, Kafka ZooKeeper-to-KRaft, Redis-to-Valkey, full observability stack rebuild. The question: what does Git need to contain so any AI session picks up where the last one left off?

The answer is a 4-layer Git structure, each layer born from a production failure.
Layer 1: Human plans in Git (36 files, 23,854 lines). Too verbose for AI.
Layer 2: Distilled AI context in Git (6 files, 1,254 lines). 19:1 compression as a project state dashboard.
Layer 3: Command Guardrails in Git (117 files). Enforced ordering, no AI-generated commands.
Layer 4: Locked values in Git (30 files). Zero interpretation, reviewed like code.

Every AI action reads from Git, executes, and commits back. The loop is closed.

DEV: 2 weeks → 2 days. PROD: 1 week → 1 day. The session covers the architecture, each layer's failure, and real production artifacts.