Why IT security’s future is more than just AI models

รับมือ Q-day: หมุดหมายที่ควอนตัมพิชิตความปลอดภัยไซเบอร์โลก สี่ขั้นตอนการเตรียมความพร้อมไฮบริดคลาวด์ ตั้งแต่วันนี้

Why IT security’s future is more than just AI models

Article by Chris Wright, Chief Technology Officer and Senior Vice President, Global Engineering, Red Hat
Article by Chris Wright, Chief Technology Officer and Senior Vice President, Global Engineering, Red Hat

Much of the public discussion around AI and its impact on cybersecurity focuses almost exclusively on models, with some arguments calling for a central authority to manage the latest models behind closed doors. There have even been discussions around strictly regulating or outright banning open weights models in the interest of security. But as global regulators mull the future of open AI models, a core question falls by the wayside: How do we actually secure AI systems?

AI security is a software challenge, not just a model issue

An AI agent isn’t just a model but rather a complete software stack. Securing this system requires analyzing the core model, the agentic harness, sandboxing techniques, runtime guardrails, data controls, and a host of other underlying infrastructure layers. Crucially, three of those four components—harnesses, sandboxes, and traditional application layers—are fundamentally rooted in software engineering, not the model.

Trying to secure the AI landscape by fragmenting software behind closed, proprietary boundaries simply shifts risk rather than solving it. Decades ago, when Linux first hit the scene, there was uncertainty and doubt cast around open source as a stable, secure solution for enterprise companies. Naysayers claimed only closed development could offer enterprise-grade reliability. However, time proved the exact opposite: open source software has since become the de facto catalyst powering a vast majority of global enterprise IT where scale and security are non-negotiable.

We are seeing an exact echo of that resistance today. Just as Linux proved that transparency and community collaboration create a more robust operating system, open source AI models, open source agentic harnesses, and transparent sandboxing will prove to be the most secure foundation for the future of computing.

Why open models and transparency are vital for defense

In cybersecurity, transparency is part of how you create secure systems. As the old IT principle goes: security through obscurity is less secure.

Limiting ourselves to a small set of proprietary models for cybersecurity research and threat mitigation introduces serious risks. Defenders have no way to manage what tools attackers choose to use. If researchers and security teams are restricted from accessing and inspecting open defensive models, they risk becoming blind to the tools and vectors exploited by threat actors. Furthermore, concentrating access within a handful of closed providers creates concentrated systemic risk.

 

Broad access to open weights models gives defenders the exact tools needed to build effective mitigation strategies. Open models allow for broad scientific scrutiny, which is vital for identifying and addressing latent vulnerabilities that would otherwise remain hidden inside proprietary “black box” systems.

 

We saw a clear example of this dynamic in action during a recent security incident involving Hugging Face. While the source of the vulnerability involved proprietary models (systems we are told to trust as inherently safe) the actual mitigations and protections were driven by open weights models. Open weights models were critical to resolving the threat. This is why Red Hat signed Microsoft’s letter on Open Weights and American AI Leadership. Broad, open access to defensive tools spreads security pervasively across the software development lifecycle.

 

Advancing state-of-the-art protection through shared learning

With this in mind, Red Hat is doing what we do best to help address the growing need for secure AI: working with the community. Most recently, as part of the Open Secure AI Alliance, Red Hat collaborated with NVIDIA, the Linux Foundation, and other members to develop a Request for Comments (RFC) for the Shared AI Findings Exchange (SAFE) Working Group. 

 

Until now, IT teams have investigated AI security incidents internally, keeping critical operational insights trapped within individual enterprise walls. The SAFE guidelines change that paradigm by creating a neutral framework to confidentially collect, analyze, and distribute findings from AI operational failures without placing blame.

By supporting incident reporting and sharing threat intelligence openly, we advance the state of the art together. Through open collaboration, the entire ecosystem benefits: tools evolve faster, defensive capabilities grow stronger, and critical infrastructure becomes better protected against real-world attacks.

Moving forward together

Whether in base operations, software engineering, or enterprise application delivery, AI tools are advancing at unprecedented speed. A system’s strength relies on a combination of core models and the open source harnesses wrapped around them to safely guide behavior toward intended outcomes.

At Red Hat, we believe open collaboration and transparency remain the best, fastest, and safest ways to evolve technology. By focusing on original, human-driven insights and fostering open ecosystems – across open source software, open weights models, and open agentic harnesses – we can advance security alongside capability.

The full SAFE RFC proposal is available now on GitHub for community review, discussion, and contributions. 

ทำไมอนาคต IT Security ถึงเป็นมากกว่าแค่เรื่อง AI models

รับมือ Q-day: หมุดหมายที่ควอนตัมพิชิตความปลอดภัยไซเบอร์โลก สี่ขั้นตอนการเตรียมความพร้อมไฮบริดคลาวด์ ตั้งแต่วันนี้

ทำไมอนาคต IT Security ถึงเป็นมากกว่าแค่เรื่อง AI models

นายคริส ไรท์ ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยี และรองประธานบริหาร ฝ่ายวิศวกรรมระดับโลก ของเร้ดแฮท
บทความโดย นายคริส ไรท์ ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยี และรองประธานบริหาร ฝ่ายวิศวกรรมระดับโลก ของเร้ดแฮท

การถกเถียงในวงกว้างเกี่ยวกับ AI และผลกระทบต่อความปลอดภัยทางไซเบอร์ มักกระจุกตัวอยู่แค่เรื่องของตัวโมเดล จนเกิดกระแสเรียกร้องให้มีหน่วยงานกลางคอยควบคุมดูแลโมเดลรุ่นใหม่ล่าสุดอย่างลับ ๆ ถึงขั้นเสนอให้กำกับดูแลอย่างเข้มงวดหรือสั่งห้ามใช้โมเดลแบบเปิดเผยค่าน้ำหนัก (open weights models) โดยเด็ดขาด เพื่อเหตุผลด้านความปลอดภัย แต่ในขณะที่หน่วยงานกำกับดูแลทั่วโลกกำลังชั่งน้ำหนักเรื่องอนาคตของโมเดล AI แบบเปิด ประเด็นหลักที่สำคัญที่สุดกลับถูกมองข้ามไป นั่นคือ เราจะคุ้มครองและสร้างความปลอดภัยอย่างแท้จริงให้ AI ได้อย่างไร

ความปลอดภัยของ AI คือความท้าทายด้านซอฟต์แวร์ ไม่ใช่แค่เรื่องของโมเดล 

AI agent ไม่ใช่แค่ตัวโมเดลเดี่ยว ๆ แต่คือ ระบบซอฟต์แวร์ที่ประกอบกันแบบครบวงจร (software stack) ดังนั้น การสร้างความปลอดภัยให้ระบบนี้จึงต้องมองให้ครอบคลุมตั้งแต่การวิเคราะห์โมเดลหลัก (core model) ส่วนเชื่อมต่อสั่งการ (agentic harness) เทคนิคการจำกัดพื้นที่ความเสี่ยงหรือพื้นที่จำลองการทำงาน (sandbox) เกราะคุมความปลอดภัยขณะทำงาน (runtime guardrails) การกำกับดูแลข้อมูล ไปจนถึงโครงสร้างพื้นฐานอีกหลายเลเยอร์ที่ทำหน้าที่รองรับระบบต่าง ๆ สิ่งสำคัญคือสามในสี่ขององค์ประกอบเหล่านี้ คือ harnesses, sandbox และเลเยอร์ที่เป็นแอปพลิเคชันแบบดั้งเดิม ล้วนมีรากฐานและยึดโยงอยู่กับวิศวกรรมซอฟต์แวร์โดยแท้จริง ไม่ใช่เรื่องของตัวโมเดล

ความพยายามในการสร้างความปลอดภัยให้ AI ด้วยการแยกส่วนซอฟต์แวร์และกักไว้ในระบบปิดที่เป็นกรรมสิทธิ์ เป็นเพียงการย้ายความเสี่ยง ไม่ใช่การแก้ปัญหาที่แท้จริง หากย้อนกลับไปเมื่อหลายทศวรรษก่อน ตอนที่มีการเปิดตัว Linux ครั้งแรก เคยเกิดความลังเลและข้อสงสัยว่าโอเพ่นซอร์สจะเสถียรและปลอดภัยพอสำหรับการใช้งานในระดับองค์กรหรือไม่ โดยฝ่ายที่ไม่เห็นด้วยมองว่ามีเพียงการพัฒนาแบบปิดเท่านั้นที่จะให้ความน่าเชื่อถือในระดับองค์กรได้ อย่างไรก็ตาม เวลาได้พิสูจน์แล้วว่าซอฟต์แวร์โอเพ่นซอร์สกลายเป็นขุมพลังสำคัญในการขับเคลื่อนการใช้ไอทีขององค์กรส่วนใหญ่ทั่วโลก ซึ่งเรื่องของการปรับขนาดการทำงานและความปลอดภัยเป็นเรื่องที่ไม่สามารถเจรจาต่อรองได้

เรากำลังเห็นแรงต้านแบบเดียวกันในปัจจุบัน โมเดล AI แบบโอเพ่นซอร์ส เครื่องมือควบคุมจัดการ agent แบบโอเพ่นซอร์ส และระบบจำลองการทำงานที่ตรวจสอบได้ จะพิสูจน์ให้เห็นว่าเป็นโครงสร้างพื้นฐานที่ปลอดภัยที่สุดของอนาคตแห่งการประมวลผล เช่นเดียวกับที่ Linux เคยพิสูจน์แล้วว่าความโปร่งใสและการร่วมมือกันในชุมชนช่วยสร้างระบบปฏิบัติการที่แข็งแกร่งมากขึ้น

ทำไมโมเดลแบบเปิดและความโปร่งใสจึงจำเป็นอย่างยิ่งในการป้องกันตัว 

ในโลกไซเบอร์ซีเคียวริตี ความโปร่งใสคือหัวใจของการสร้างระบบให้ปลอดภัย เหมือนหลักการไอทีที่มีมานานว่า ความปลอดภัยที่เน้นแค่การปิดเป็นความลับ ไม่ใช่ความปลอดภัยที่แท้จริง 

การจำกัดการทำงานวิจัยด้านไซเบอร์และการรับมือภัยคุกคามไว้กับโมเดลจากผู้ให้บริการระบบปิดเพียงไม่กี่ราย นำมาซึ่งความเสี่ยงที่ร้ายแรง เพราะทีมที่ทำหน้าที่ป้องกันไม่สามารถไปกำหนดได้ว่าผู้โจมตีจะใช้เครื่องมืออะไร หากนักวิจัยและทีมซีเคียวริตี้ขององค์กรไม่สามารถเข้าถึงหรือสำรวจดูโมเดลที่ใช้ในการป้องกันที่เป็นระบบเปิดได้ ก็เสี่ยงที่จะมองไม่เห็นเครื่องมือและรูปแบบการโจมตีที่แฮกเกอร์นำมาใช้ ยิ่งไปกว่านั้น การพึ่งพาผู้ให้บริการระบบปิดแค่ไม่กี่ราย ยังเป็นการสร้างความเสี่ยงเชิงระบบที่กระจุกตัวอยู่อีกด้วย

การเข้าถึงโมเดลแบบ open-weights ได้อย่างทั่วถึง จะช่วยให้ผู้ทำหน้าที่ป้องกันมีเครื่องมือที่จำเป็นในการสร้างกลยุทธ์เพื่อรับมือภัยคุกคามได้อย่างมีประสิทธิภาพ โมเดลแบบเปิดยังช่วยกระตุ้นให้เกิดการตรวจสอบวิเคราะห์เชิงวิทยาศาสตร์ในวงกว้าง ซึ่งเป็นสิ่งสำคัญต่อการค้นหาและแก้ไขช่องโหว่ซ่อนเร้นที่มักถูกแฝงไว้ในระบบปิดที่เป็นกรรมสิทธิ์ (black box)

เราได้เห็นตัวอย่างที่ชัดเจนของเรื่องนี้จากเหตุการณ์ความปลอดภัยของ Hugging Face ที่เพิ่งเกิดขึ้น แม้ต้นตอของช่องโหว่จะมาจากโมเดลระบบปิด (ระบบที่เรามักถูกบอกให้เชื่อมั่นว่าปลอดภัยในตัวของมันเองอยู่แล้ว) แต่การบรรเทาความเสียหายและการปกป้องระบบจริงกลับต้องพึ่งพาโมเดลแบบ open weights ซึ่งมีบทบาทสำคัญอย่างยิ่งในการคลี่คลายภัยคุกคามในครั้งนี้ ด้วยเหตุนี้เร้ดแฮทจึงร่วมลงนามใน Microsoft’s letter on Open Weights and American AI Leadership เพราะการเปิดให้เข้าถึงเครื่องมือฝั่งป้องกันได้อย่างกว้างขวาง จะช่วยกระจายความปลอดภัยได้อย่างครอบคลุมตลอดทุกขั้นตอนของวงจรการพัฒนาซอฟต์แวร์

ยกระดับมาตรการป้องกันที่ล้ำสมัยที่สุดในปัจจุบัน ด้วยการแบ่งปันและเรียนรู้ร่วมกัน 

เร้ดแฮทนำจุดแข็งที่สุดของบริษัทฯ มาใช้ตอบโจทย์ความต้องการ AI ที่ปลอดภัย นั่นคือการทำงานร่วมกับชุมชน โดยล่าสุด ในฐานะที่เป็นส่วนหนึ่งของ Open Secure AI Alliance เร้ดแฮทได้ร่วมมือกับ NVIDIA, Linux Foundation และสมาชิกในกลุ่ม จัดทำ Request for Comments (RFC) for the Shared AI Findings Exchange (SAFE) Working Group ขึ้นมา

ทีมไอทีมักตรวจสอบและแก้ปัญหาเหตุการณ์ละเมิดความปลอดภัยในการใช้ AI กันเองภายในองค์กร ทำให้องค์ความรู้และข้อมูลเชิงลึกในการดำเนินการถูกบล็อกไว้แค่ในองค์กรนั้น ๆ กรอบแนวทางของ SAFE เข้ามาเปลี่ยนวิถีเดิม ๆ นี้ ด้วยการสร้างเฟรมเวิร์กที่เป็นกลางขึ้นมา เพื่อรวบรวม วิเคราะห์ และแชร์ข้อมูลความผิดพลาดจากการใช้ AI อย่างเป็นความลับและไม่มุ่งจับผิดใคร

การสนับสนุนให้รายงานเหตุความปลอดภัยและแลกเปลี่ยนข้อมูลภัยคุกคามอย่างเปิดเผย คือหัวใจสำคัญที่จะช่วยให้เกิดการยกระดับขีดความสามารถด้านการป้องกันไปด้วยกัน ความร่วมมือแบบเปิดนี้ช่วยให้ทั้งวงการได้ประโยชน์ร่วมกันเต็ม ๆ ตั้งแต่การพัฒนาเครื่องมือได้รวดเร็วขึ้น เสริมเกราะป้องกันให้แข็งแกร่งมากขึ้น ไปจนถึงการปกป้องโครงสร้างพื้นฐานสำคัญให้รอดพ้นจากการโจมตีในสถานการณ์จริงได้อย่างรัดกุม

ก้าวไปข้างหน้าพร้อมกัน

เครื่องมือ AI ต่าง ๆ กำลังพัฒนาไปข้างหน้าด้วยความเร็วอย่างที่ไม่เคยมีมาก่อน ไม่ว่าจะเป็นงานปฏิบัติการพื้นฐาน งานวิศวกรรมซอฟต์แวร์ หรือการให้บริการแอปพลิเคชันระดับองค์กร ความแข็งแกร่งของระบบขึ้นอยู่กับการผสมผสานระหว่างโมเดลหลักและเครื่องมือโอเพ่นซอร์สที่ห่อหุ้มอยู่รอบ ๆ เพื่อกำกับพฤติกรรมของ AI ให้เป็นไปตามวัตถุประสงค์และผลลัพธ์ที่ต้องการได้อย่างปลอดภัย

เร้ดแฮทเชื่อว่าความร่วมมือแบบเปิดและความโปร่งใสยังคงเป็นแนวทางที่ดีที่สุด เร็วที่สุด และปลอดภัยที่สุดในการพัฒนาเทคโนโลยี ทุกฝ่ายสามารถยกระดับความปลอดภัยและศักยภาพของเทคโนโลยีให้เติบโตควบคู่กันได้ ด้วยการชูจุดแข็งด้านการคิดวิเคราะห์ของมนุษย์และการผลักดันระบบนิเวศแบบเปิดต่าง ๆ ทั้งกับซอฟต์แวร์โอเพ่นซอร์ส โมเดลแบบ open weights และกลไกควบคุมเอเจนต์แบบเปิด

ปัจจุบัน ข้อเสนอ SAFE RFC ฉบับเต็มได้เปิดให้เข้าถึงแล้วบน GitHub เพื่อให้ชุมชนผู้ใช้งานได้ร่วมอ่าน ตรวจสอบ แลกเปลี่ยนความคิดเห็น และร่วมพัฒนาไปด้วยกัน 

Preparing for Q-day: Four steps to prepare your hybrid cloud today

รับมือ Q-day: หมุดหมายที่ควอนตัมพิชิตความปลอดภัยไซเบอร์โลก สี่ขั้นตอนการเตรียมความพร้อมไฮบริดคลาวด์ ตั้งแต่วันนี้

Preparing for Q-day: Four steps to prepare your hybrid cloud today

Article by: JP Jung, Red Hat

The arrival of a cryptographically relevant quantum computer, often referred to as Q-day, is moving from a distant theoretical mathematical challenge to an urgent timeline that security teams must plan for today. Bad actors are already engaging in harvest now, decrypt later activities. This means they are capturing and storing encrypted enterprise traffic, intellectual property, and data logs today with the intention of running them through quantum hardware as soon as it becomes available.

At Red Hat, we believe taking this threat seriously means acting before the crisis arrives. Rather than viewing post-quantum cryptography (PQC) as a distant compliance box to check, we are actively leading the charge by embedding quantum-safe capabilities directly into the foundational layers of hybrid cloud infrastructure. This approach gives organizations the tools they need to protect their digital assets today while preparing for Q-day in the not-too-distant future.

This urgency is not hypothetical. According to the White House Executive Order 14412, federal agencies are expected to achieve a pilot migration to post-quantum cryptography (PQC) readiness by 2027 and complete full-scale execution by 2029. This aligns with the National Security Agency’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) mandate, which requires quantum-safe algorithms for national security systems, with commercial TLS implementations facing strict enforcement deadlines by 2030. The strategic question is not whether you are 100% sure a cryptographically relevant quantum computer will exist in 2030; the question is whether you are 100% sure it will not. Organizations that wait until quantum computers arrive to begin their migration will find themselves three to five years behind, with their archived data most likely already compromised.

A portfolio built on market-first quantum innovation

Red Hat addresses these urgent challenges through a unified, joint-solution approach that bakes quantum security into the very foundation of your hybrid cloud. Red Hat Enterprise Linux (RHEL) 10 is the first enterprise Linux distribution to ship with NIST-standardized post-quantum algorithms, including ML-KEM and ML-DSA-enabled natively at the operating system level. 

Built entirely on that hardened foundation, Red Hat OpenShift inherits these capabilities. OpenShift does not attempt to build its own cryptographic libraries from scratch. Instead, it positions RHEL as the underlying engine providing the compliance and security math, which OpenShift then operationalizes and scales across distributed environments.

By shifting security from fragmented application layers down to a unified RHEL and OpenShift infrastructure, organizations gain a more secure, compliant, and cost-effective platform. This joint architecture protects your most valuable artificial intelligence (AI) assets from future quantum decryption and regulatory overreach today, all while reducing cloud operational complexity and expenses.

Here are the top four things you can do to be ready for Q-day:

  • Inventory your hidden cryptographic footprint across the hybrid cloud

Organizations cannot defend what they cannot see, and most enterprises run millions of automated software connections that rely on older, quantum-vulnerable public security algorithms. Security teams need a comprehensive understanding of where data is scrambled and where digital keys are created across distributed environments. This shifts the operational focus toward mapping high-value assets like AI model weights and training logs.

The default system-wide cryptographic policy in Red Hat Enterprise Linux 10 provides next-generation cryptographic settings by enabling advanced, quantum-resistant algorithms. Operators can instantly enable all core host communication to use quantum-safe standards for key encapsulation. This allows teams to test real-world application performance, processing overhead, and latency before moving workloads to production. Security teams should evaluate core software platforms to identify legacy hardcoded or outdated security standards, making sure foundational infrastructure layers provide clear visibility into internal network communications.

  • Test next-generation cryptographic primitives in non-production environments

Transitioning to quantum-resistant security requires evaluating how new mathematical encryption methods affect overall application performance, network response times, and processing overhead. RHEL 10’s system-wide crypto-policy profiles, including the FUTURE policy, allow operators to switch the entire host’s cryptographic posture to quantum-resistant standards with a single command. This makes it practical for security teams to test real-world behavior across the full stack rather than in isolated application experiments.

The newly released Red Hat OpenShift 4.22 delivers quantum-safe key exchange as a generally available, production-ready capability. ML-KEM hybrid key exchange is active by default. That means every TLS handshake between control plane components uses quantum-safe cryptography out of the box, with no configuration required. Workloads running on the platform inherit PQC-capable TLS without any application code changes.

Because RHEL handles the low-level security libraries (like OpenSSL), individual application developers do not have to rewrite code or manage complex algorithm selection. This platform-wide inheritance contrasts with traditional fragmented approaches from other Kubernetes-derived platforms, which lack native, end-to-end, out-of-the-box control plane PQC integration. While full production implementations require ongoing technical validation to determine optimal enterprise configurations, this technology preview provides a valuable mechanism for validating software compatibility and preparing infrastructure teams for the broader migration ahead.

  • Shift security boundaries from the application layer to the platform layer

Expecting individual development teams to manually rewrite every single application to support post-quantum cryptography creates massive operational friction, delays project timelines, and introduces configuration errors.

To understand the business value, imagine every connection your applications make as an encrypted phone call. Adversaries don’t need to understand those calls today, they only need to record them. The tapes are gibberish now, but recordings don’t expire, and the bet is that quantum computers will eventually play them back in the clear. This means that any “information conversation” happening today, whether it’s training data moving to a GPU cluster, model weights replicating between sites, or agents exchanging credentials, is already potentially exposed to this “harvest now, decrypt later” strategy. Red Hat OpenShift changes the encryption on every one of those calls at the platform level, using algorithms designed to resist quantum attack, so that the recordings being made today stay gibberish, without any application team touching its own code.

We believe quantum security is an immediate requirement for protecting AI assets in transit. This moves the conversation away from a theoretical future browser issue to protecting your proprietary training data, model weights, and agent logs from immediate interception. Red Hat customers can benefit from establishing a unified, crypto-agile application platform layer that automatically handles secure handshakes on behalf of the underlying workloads.

Using platform-wide secure networking tools allows organizations to test post-quantum cryptographic connections, instantly shielding container communication from interceptors without requiring changes to application source code. Cryptographic upgrades happen once in RHEL, propagate automatically through OpenShift, and protect every workload running on top. Individual application teams do not need to rewrite TLS code, swap libraries, or manage algorithm selection. The platform handles it.

  • Assert absolute operational control over data placement and execution

True quantum readiness requires more than updated security keys; it demands

complete authority over where data resides and how infrastructure executes workloads. Relinquishing architectural command to a centralized public cloud control plane leaves your organization operationally vulnerable to platform decisions and management policies that are not your own.

Operators can maximize infrastructure control by using isolated platform environments to maintain strict boundaries between computing workloads. This helps verify that data paths never cross into locations where digital cargo can be compromised. Organizations can pair this strategy with hardware-enforced solutions like confidential containers to shield sensitive data while it is actively being processed.

You do not need to wait for Q-day to start preparing. Start by inventorying your cryptographic footprint: know which algorithms, key lengths, and protocols your applications depend on today. Review the RHEL post-quantum cryptography documentation and the OCP 4.22 release notes to understand what is available now. Then talk to your Red Hat account team about a PQC readiness assessment—we can help you map your migration path before the deadlines arrive.

รับมือ Q-day: หมุดหมายที่ควอนตัมพิชิตความปลอดภัยไซเบอร์โลก สี่ขั้นตอนการเตรียมความพร้อมไฮบริดคลาวด์ ตั้งแต่วันนี้

รับมือ Q-day: หมุดหมายที่ควอนตัมพิชิตความปลอดภัยไซเบอร์โลก สี่ขั้นตอนการเตรียมความพร้อมไฮบริดคลาวด์ ตั้งแต่วันนี้

รับมือ Q-day: หมุดหมายที่ควอนตัมพิชิตความปลอดภัยไซเบอร์โลก สี่ขั้นตอนการเตรียมความพร้อมไฮบริดคลาวด์ ตั้งแต่วันนี้

บทความโดย JP Jung, Red Hat

การมาถึงของควอนตัมคอมพิวเตอร์ที่มีศักยภาพสูงพอที่จะใช้ในการถอดรหัส หรือที่มักเรียกกันว่า Q-day กำลังเปลี่ยนผ่านจากการเป็นเพียงความท้าทายทางคณิตศาสตร์เชิงทฤษฎีในอนาคตอันไกล ไปสู่กรอบเวลาที่บีบบังคับให้ทีมความปลอดภัยไซเบอร์ต้องวางแผนรับมือตั้งแต่วันนี้ เนื่องจากกลุ่มผู้ไม่หวังดีเริ่มดำเนินกิจกรรมในลักษณะดักเก็บข้อมูลวันนี้ เพื่อรอถอดรหัสในวันหน้า (harvest now, decrypt later) ซึ่งหมายความว่าพวกเขากำลังดักจับและกักเก็บข้อมูลการรับส่งภายในองค์กรที่ผ่านการเข้ารหัส ทรัพย์สินทางปัญญา และบันทึกข้อมูลระบบ (data logs) เอาไว้ตั้งแต่วันนี้ โดยมีเป้าหมายที่จะนำข้อมูลเหล่านี้ไปประมวลผลผ่านฮาร์ดแวร์ควอนตัมทันทีที่เทคโนโลยีพร้อมใช้งาน

เร้ดแฮทเชื่อว่าการรับมือกับภัยคุกคามนี้อย่างจริงจัง หมายถึงการลงมือทำก่อนที่วิกฤตจะมาถึง แทนที่จะมองว่าการเข้ารหัสยุคหลังควอนตัม (Post-Quantum Cryptography หรือ PQC) เป็นเพียงกฎระเบียบที่ต้องปฏิบัติตามในอนาคตที่ยังอยู่อีกไกล เร้ดแฮทกำลังเป็นผู้นำในการขับเคลื่อนเรื่องนี้อย่างจริงจัง ด้วยการฝังขีดความสามารถด้านความปลอดภัยยุคควอนตัม (quantum-safe) ลงในชั้นรากฐานของโครงสร้างพื้นฐานไฮบริดคลาวด์โดยตรง แนวทางนี้ช่วยให้องค์กรมีเครื่องมือที่จำเป็นในการปกป้องสินทรัพย์ดิจิทัลตั้งแต่วันนี้ ควบคู่ไปกับการเตรียมความพร้อมรับมือกับ Q-day ที่กำลังจะมาถึงในอนาคตอันใกล้

ความเร่งด่วนนี้ไม่ใช่เรื่องสมมติ ตามคำสั่งบริหารหมายเลข 14412 ของทำเนียบขาว กำหนดให้หน่วยงานรัฐบาลกลางต้องนำร่องย้ายระบบไปสู่ความพร้อมด้านการเข้ารหัสยุคหลังควอนตัม (PQC) ภายในปี 2027 และดำเนินการเต็มรูปแบบให้เสร็จสิ้นภายในปี 2029 ซึ่งสอดคล้องกับข้อกำหนด Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) ของสำนักงานความมั่นคงแห่งชาติ (NSA) ที่กำหนดใช้อัลกอริทึมความปลอดภัยยุคควอนตัมสำหรับระบบความมั่นคงแห่งชาติ โดยการปรับใช้กับโปรโตคอล TLS เชิงพาณิชย์จะต้องปฏิบัติตามกำหนดเวลาอย่างเข้มงวดภายในปี 2030 คำถามเชิงกลยุทธ์จึงไม่ใช่ว่าองค์กรมั่นใจ 100% หรือไม่ว่าควอนตัมคอมพิวเตอร์ที่ถอดรหัสได้จริงจะเกิดขึ้นภายในปี 2030 แต่คำถามคือ องค์กรมั่นใจ 100% หรือไม่ว่าจะไม่เกิดขึ้นต่างหาก องค์กรที่รอจนกว่าควอนตัมคอมพิวเตอร์ปรากฏขึ้นแล้วค่อยเริ่มย้ายระบบ จะพบว่าตนเองล้าหลังไปสามถึงห้าปี และข้อมูลสำคัญที่เคยจัดเก็บไว้ก็มีโอกาสสูงที่จะถูกเปิดเผยไปเรียบร้อยแล้ว

พอร์ตโฟลิโอผลิตภัณฑ์ที่สร้างขึ้นด้วยนวัตกรรมควอนตัมระดับแถวหน้าของตลาด

เร้ดแฮทรับมือความท้าทายอันเร่งด่วนเหล่านี้ด้วยแนวทางการนำเสนอโซลูชันร่วมแบบรวมศูนย์ ซึ่งฝังความปลอดภัยยุคควอนตัมลงไปในระดับรากฐานของไฮบริดคลาวด์โดยตรง โดย Red Hat Enterprise Linux 10 (RHEL10) ถือเป็นระบบปฏิบัติการ Linux ระดับองค์กรรายแรกที่มาพร้อมอัลกอริทึมยุคหลังควอนตัม ที่ได้มาตรฐาน NIST รวมถึง ML-KEM และ ML-DSA ที่เปิดใช้งานโดยตรงในระดับระบบปฏิบัติการ

Red Hat OpenShift สร้างขึ้นบนรากฐานที่แข็งแกร่ง จึงส่งต่อขีดความสามารถเหล่านี้มาโดยตรง OpenShift ไม่ได้พยายามสร้างคลังซอฟต์แวร์ (ไลบรารี่) สำหรับการเข้ารหัส (cryptographic libraries) ขึ้นมาใหม่ตั้งแต่ต้น แต่เลือกวางตำแหน่งให้ RHEL เป็นกลไกพื้นฐาน ทำหน้าที่คำนวณด้านความปลอดภัยและการปฏิบัติตามกฎระเบียบ ซึ่ง OpenShift จะนำขีดความสามารถเหล่านั้นมาเปิดใช้งานจริงและขยายขีดความสามารถให้ครอบคลุมทั่วทั้งสภาพแวดล้อมแบบกระจายตัว (distributed environments) 

การย้ายงานด้านความปลอดภัยจากชั้นแอปพลิเคชันที่กระจัดกระจาย ลงมาไว้ที่ชั้นโครงสร้างพื้นฐานแบบรวมศูนย์ของ RHEL และ OpenShift ช่วยให้องค์กรได้ใช้แพลตฟอร์มที่มีความปลอดภัยสูงขึ้น ปฏิบัติตามข้อกำหนดได้ดีขึ้น และคุ้มค่ากับงบประมาณ สถาปัตยกรรมร่วมนี้ช่วยปกป้องสินทรัพย์ด้าน AI ที่มีมูลค่าสูงสุดขององค์กร จากการถอดรหัสด้วยควอนตัมในอนาคต และการควบคุมทางกฎหมายที่เข้มงวดเกินไปในปัจจุบัน ทั้งหมดนี้ช่วยลดทั้งความซับซ้อนและค่าใช้จ่ายในการดำเนินงานบนคลาวด์ลงได้อย่างมีประสิทธิภาพ

4 สิ่งสำคัญที่องค์กรสามารถทำได้ตั้งแต่วันนี้ เพื่อให้พร้อมรับมือ Q-Day

  1. สำรวจร่องรอยการเข้ารหัสที่แอบแฝงอยู่บนไฮบริดคลาวด์ทั้งหมด

องค์กรไม่สามารถปกป้องสิ่งที่มองไม่เห็นได้ และองค์กรส่วนใหญ่ใช้งานการเชื่อมต่อซอฟต์แวร์แบบอัตโนมัตินับล้านรายการที่ยังพึ่งพาอัลกอริทึมความปลอดภัยสาธารณะแบบเก่า ซึ่งสุ่มเสี่ยงต่อการถูกโจมตีด้วยควอนตัม ทีมงานที่ดูแลด้านความปลอดภัยจึงต้องมีความเข้าใจอย่างถ่องแท้ว่า ข้อมูลถูกเข้ารหัสไว้ที่ใดและกุญแจดิจิทัลถูกสร้างขึ้นที่ใดบ้างในสภาพแวดล้อมแบบกระจายตัว ซึ่งเป็นการเปลี่ยนจุดโฟกัสการทำงานไปที่การจัดทำแผนผังสินทรัพย์ที่มีมูลค่าสูง เช่น AI model weights และบันทึกการฝึกอบรม

นโยบายการเข้ารหัสเริ่มต้นที่เป็นมาตรฐานทั่วทั้งระบบใน Red Hat Enterprise Linux 10 ให้การตั้งค่าการเข้ารหัสยุคใหม่ โดยการเปิดใช้งานอัลกอริทึมขั้นสูงที่ต้านทานควอนตัม ผู้ดูแลระบบสามารถเปิดใช้งานการสื่อสารหลักทั้งหมดของโฮสต์ให้ใช้มาตรฐานความปลอดภัยยุคควอนตัมสำหรับการแคปซูลกุญแจ (key encapsulation) ได้ทันที ซึ่งเปิดโอกาสให้ทีมงานสามารถทดสอบประสิทธิภาพการทำงานของแอปพลิเคชันจริง ทรัพยากรส่วนเกินที่ใช้ในการประมวลผล (processing overhead) และลาเทนซีก่อนที่จะย้ายเวิร์กโหลดไปใช้งานจริง นอกจากนี้ ทีมความมั่นคงปลอดภัยควรประเมินแพลตฟอร์มซอฟต์แวร์หลักเพื่อระบุมาตรฐานความปลอดภัยแบบเก่าหรือที่เขียนฝังไว้ในโค้ด (hardcoded) พร้อมทั้งกำกับดูแลให้ชั้นโครงสร้างพื้นฐานระดับรากฐานสามารถมองเห็นการสื่อสารภายในเครือข่ายได้อย่างชัดเจน

  1. ทดสอบชุดคำสั่งทางคณิตศาสตร์ของการเข้ารหัสยุคใหม่ ในสภาพแวดล้อมที่ไม่ได้ใช้งานจริง

การเปลี่ยนผ่านไปสู่ระบบความปลอดภัยที่ต้านทานควอนตัม จำเป็นต้องมีการประเมินว่า วิธีการเข้ารหัสทางคณิตศาสตร์แบบใหม่ส่งผลกระทบต่อประสิทธิภาพโดยรวมของแอปพลิเคชัน เวลาในการตอบสนองของเครือข่าย และทรัพยากรส่วนเกินที่ใช้ในการประมวลผล (processing overhead) อย่างไร ทั้งนี้ โปรไฟล์นโยบายการเข้ารหัสที่ใช้กับระบบในวงกว้างของ RHEL 10 ซึ่งรวมถึงนโยบาย FUTURE ช่วยให้ผู้ดูแลระบบสามารถสับเปลี่ยนรูปแบบการเข้ารหัสของโฮสต์ทั้งหมดไปสู่มาตรฐานที่ต้านทานควอนตัมได้ด้วยคำสั่งเดียว ซึ่งช่วยให้ทีมที่ดูแลด้านความปลอดภัยสามารถทดสอบพฤติกรรมการทำงานจริงครอบคลุมทั้งสแต็กแทนที่จะต้องแยกทดสอบแอปพลิเคชันเป็นส่วน ๆ 

Red Hat OpenShift 4.22 ที่เปิดตัวล่าสุด มอบความสามารถในการแลกเปลี่ยนคีย์รหัสที่มีความปลอดภัยในยุคควอนตัม ในสถานะที่พร้อมให้ใช้งาน (generally available) การแลกเปลี่ยนคีย์รหัส ML-KEM hybrid key exchange จะถูกเปิดใช้งานเป็นค่าเริ่มต้น นั่นหมายความว่า ทุกขั้นตอนการสร้างความเชื่อมต่อแบบปลอดภัย (TLS handshake) ระหว่างส่วนประกอบของ control plane จะใช้การเข้ารหัสยุคหลังควอนตัมโดยอัตโนมัติทันทีที่ติดตั้ง โดยไม่จำเป็นต้องตั้งค่าเพิ่มเติมใด ๆ ส่งผลให้เวิร์กโหลดที่ทำงานอยู่บนแพลตฟอร์มจะส่งต่อความสามารถ TLS ยุค PQC ทันที โดยไม่ต้องแก้ไขโค้ดของแอปพลิเคชันใด ๆ

การที่ RHEL เป็นผู้ดูแลไลบรารี่ความปลอดภัยระดับล่าง (เช่น OpenSSL) จึงช่วยให้นักพัฒนาแอปพลิเคชันแต่ละคนไม่จำเป็นต้องเขียนโค้ดใหม่ หรือยุ่งยากกับการเลือกใช้อัลกอริทึมที่ซับซ้อนด้วยตนเอง การส่งต่อคุณสมบัติด้านความปลอดภัยครอบคลุมทั้งแพลตฟอร์มเช่นนี้ แตกต่างอย่างสิ้นเชิงกับแนวทางแบบเดิมที่กระจัดกระจายบนแพลตฟอร์มอื่น ๆ ที่พัฒนามาจาก Kubernetes ซึ่งยังขาดการเชื่อมต่อการเข้ารหัสยุค PQC ในระดับ control plane แบบ native, end-to-end และพร้อมใช้งานทันที แม้ว่าการใช้งานจริงอย่างเต็มรูปแบบยังคงต้องผ่านการตรวจสอบทางเทคนิคอย่างต่อเนื่อง เพื่อหาการตั้งค่าระดับองค์กรที่เหมาะสมที่สุด แต่ฟีเจอร์พรีวิวนี้ก็นับเป็นกลไกทรงคุณค่าในการตรวจสอบความเข้ากันได้ของซอฟต์แวร์ และช่วยเตรียมความพร้อมให้ทีมโครงสร้างพื้นฐานสำหรับการย้ายระบบครั้งใหญ่ที่กำลังจะมาถึง

  1. ย้ายขอบเขตความปลอดภัยจากเลเยอร์แอปพลิเคชันไปสู่เลเยอร์แพลตฟอร์ม

ความคาดหวังให้ทีมพัฒนาแต่ละทีมต้องเขียนโค้ดแอปพลิเคชันทุกตัวใหม่ด้วยตนเองเพื่อรองรับการเข้ารหัสยุคหลังควอนตัม (PQC) นั้น ทำให้เกิดอุปสรรคและแรงเสียดทานอย่างมหาศาลในการทำงาน ส่งผลให้โครงการล่าช้า และเสี่ยงต่อการเกิดข้อผิดพลาดในการตั้งค่าระบบ

เพื่อให้เข้าใจถึงคุณค่าทางธุรกิจ ลองจินตนาการว่าทุกการเชื่อมต่อของแอปพลิเคชันเปรียบเสมือนการโทรศัพท์แบบเข้ารหัสไว้ กลุ่มผู้ไม่หวังดีไม่จำเป็นต้องเข้าใจสิ่งที่คุยกันในวันนี้ พวกเขาแค่ดักบันทึกเสียงเหล่านั้นเก็บไว้ แม้ไฟล์บันทึกในปัจจุบันจะฟังไม่รู้เรื่อง แต่ข้อมูลที่บันทึกไว้ไม่มีวันหมดอายุ และพวกเขากำลังเดิมพันว่าควอนตัมคอมพิวเตอร์จะสามารถเล่นไฟล์เหล่านี้ให้อ่านได้อย่างชัดเจนในท้ายที่สุด นั่นหมายความว่า “การสนทนาที่เป็นข้อมูล” ทั้งหมดที่เกิดขึ้นในวันนี้ ไม่ว่าจะเป็นข้อมูลการสอนที่ส่งไปยัง GPU Cluster, น้ำหนักของโมเดล (Model Weights) ที่ถูกคัดลอกข้ามไซต์ หรือ Agent ที่กำลังแลกเปลี่ยนข้อมูลรับรองรหัสผ่าน (Credentials) สุ่มเสี่ยงที่จะตกเป็นเป้าหมายของกลยุทธ์ “ดักเก็บข้อมูลวันนี้ เพื่อรอถอดรหัสในวันหน้า” (Harvest now, decrypt later) เรียบร้อยแล้ว Red Hat OpenShift เข้ามาเปลี่ยนวิธีการเข้ารหัสของการเชื่อมต่อเหล่านั้นในชั้นแพลตฟอร์ม โดยใช้อัลกอริทึมที่ถูกออกแบบมาเพื่อต้านทานการโจมตีด้วยควอนตัมโดยเฉพาะ ส่งผลให้ข้อมูลที่ถูกดักบันทึกไว้ในวันนี้ยังคงเป็นข้อมูลที่ไม่สามารถอ่านได้ตลอดไป โดยที่ทีมพัฒนาแอปพลิเคชันไม่จำเป็นต้องเข้าไปแตะต้องหรือแก้ไขโค้ดของตนเองเลย

เร้ดแฮทเชื่อว่าความปลอดภัยยุคควอนตัมเป็นสิ่งจำเป็นเร่งด่วนที่ต้องทำทันทีเพื่อปกป้องสินทรัพย์ AI ระหว่างการรับส่งข้อมูล แนวทางนี้เปลี่ยนมุมมองจากเดิมที่เคยมองว่าเป็นปัญหาด้านเบราว์เซอร์ในอนาคตในเชิงทฤษฎี ไปสู่มุมมองในการปกป้องข้อมูลที่ใช้ในการฝึกอบรมที่เป็นกรรมสิทธิ์ขององค์กร ปกป้อง model weights และบันทึกการทำงานของเอเจนต์ จากการถูกดักจับข้อมูลได้ในทันที ลูกค้าของเร้ดแฮทจะได้รับประโยชน์จากการสร้างเลเยอร์แพลตฟอร์มแอปพลิเคชันแบบรวมศูนย์ที่มีความยืดหยุ่นคล่องตัวด้านการเข้ารหัส ซึ่งสามารถจัดการขั้นตอนสร้างความเชื่อมต่อแบบปลอดภัยให้กับเวิร์กโหลดพื้นฐานได้โดยอัตโนมัติ

การใช้เครื่องมือเครือข่ายความปลอดภัยแบบรวมศูนย์ที่ครอบคลุมทั้งแพลตฟอร์มช่วยให้องค์กรทดสอบการเชื่อมต่อการเข้ารหัสยุคหลังควอนตัม ปกป้องการสื่อสารระหว่างคอนเทนเนอร์จากการดักจับข้อมูลได้ทันที โดยไม่ต้องแก้ไขซอร์สโค้ดของแอปพลิเคชัน การอัปเกรดระบบเข้ารหัสจะเกิดขึ้นเพียงครั้งเดียวใน RHEL จากนั้นจะกระจายอัตโนมัติไปยัง OpenShift เพื่อปกป้องเวิร์กโหลดทุกรายการที่ทำงานอยู่บนระบบ ทีมงานด้านแอปพลิเคชันแต่ละทีมจึงไม่จำเป็นต้องเขียนโค้ด TLS ใหม่ ไม่ต้องเปลี่ยนไลบรารีหรือจัดการเลือกอัลกอริทึมด้วยตนเอง เพราะแพลตฟอร์มนั้น ๆ จะจัดการทั้งหมดให้เอง   

  1. ควบคุมการทำงานของตำแหน่งจัดเก็บและการประมวลผลข้อมูลอย่างเบ็ดเสร็จ

การเตรียมความพร้อมสู่ยุคควอนตัมอย่างแท้จริงต้องการมากกว่าแค่การอัปเดตคีย์ความปลอดภัย แต่ต้องอาศัยอำนาจสิทธิ์ขาดในการกำหนดจุดจัดเก็บข้อมูลและกำหนดได้ว่าโครงสร้างพื้นฐานจะประมวลผลเวิร์กโหลดอย่างไร การมอบอำนาจการสั่งการทางสถาปัตยกรรมให้แก่ระบบควบคุมศูนย์กลางของพับลิกคลาวด์ จะทำให้องค์กรเสี่ยงต่อการดำเนินงานที่อาจเกิดจากนโยบายบริหารจัดการและการตัดสินใจของแพลตฟอร์มที่คุณไม่ได้เป็นเจ้าของเอง

ผู้ดูแลระบบสามารถควบคุมโครงสร้างพื้นฐานได้อย่างสูงสุด โดยใช้สภาพแวดล้อมแพลตฟอร์มแบบแยกส่วน (isolated platform environments) เพื่อแบ่งขอบเขตระหว่างเวิร์กโหลดการประมวลผลอย่างเข้มงวด วิธีนี้ช่วยให้มั่นใจได้ว่าเส้นทางเดินข้อมูลจะไม่ปะปนไปยังจุดที่อาจทำให้ข้อมูลดิจิทัลรั่วไหลหรือถูกโจมตี นอกจากนี้ องค์กรยังสามารถใช้ควบคู่กับโซลูชันความปลอดภัยระดับฮาร์ดแวร์ เช่น การรันคอนเทนเนอร์ในพื้นที่ประมวลผลที่ถูกเข้ารหัสและปกป้องอย่างแน่นหนาในระดับฮาร์ดแวร์ (confidential containers) เพื่อสร้างเกราะปกป้องข้อมูลสำคัญในระหว่างการประมวลผลได้อย่างมีประสิทธิภาพ 

องค์กรไม่จำเป็นต้องรอให้ถึง Q-day แล้วค่อยเริ่มเตรียมตัว แต่สามารถเริ่มต้นได้เลยด้วยการสำรวจระบบและโครงสร้างการเข้ารหัสทั้งหมดขององค์กร (cryptographic footprint) เพื่อให้ทราบว่า แอปพลิเคชันในปัจจุบันขององค์กร ใช้งานอัลกอริทึมใด ใช้คีย์ที่ใช้ในการเข้ารหัสข้อมูลที่มีขนาดหรือความยาวเท่าไร และโพรโทคอลรูปแบบใดบ้าง และสามารถศึกษารายละเอียดเพิ่มเติมได้จาก RHEL post-quantum cryptography documentation และ OCP 4.22 release notes เพื่อดูว่ามีฟีเจอร์และขีดความสามารถใดที่พร้อมใช้งานแล้วในปัจจุบัน รวมถึงปรึกษาทีมดูแลลูกค้าของเร้ดแฮทเพื่อประเมินความพร้อมด้าน PQC และวางโรดแมปการย้ายระบบอย่างเป็นขั้นตอนล่วงหน้าก่อนที่เส้นตายจะมาถึง

Securing the enterprise software fabric: A blueprint for open source

พิมพ์เขียวความปลอดภัยซอฟต์แวร์องค์กร: ใช้โอเพ่นซอร์สอย่างมั่นใจ

Securing the enterprise software fabric: A blueprint for open source

Lately, headlines dominated by AI-driven zero-day vulnerabilities have raised a question: Is open source software becoming too risky for the enterprise? With open source comprising more than three-quarters of the average enterprise codebase, the question matters. But the answer is clear: open source software remains inherently safe, structurally resilient, and fundamentally secure.

Open source effectively serves as the foundation for all of modern technology, not just enterprise IT, and this is about much more than just Linux. Application servers, databases, network routing, developer environments, and all of the other invisible components that make up our technological fabric are fueled by open source projects in some way, shape, or form. 

The alternative to open source, in short, is that there isn’t one. Proprietary software comes closest, which is owned and controlled by a single company, but it lacks the sheer scale, variety, and ubiquity of open source. With proprietary software, the source code is a black box. Only the vendor decides what gets fixed and when. When a vulnerability is found, it may stay secret, known only to the attackers who discovered it. That model might feel secure, but the risk has only moved out of sight and become an unknown. Proprietary software allows vulnerabilities to breed in darkness.

Open source changes this by making the code available to everyone, highlighted by the mantra of “Given enough eyeballs, all bugs are shallow.” When anyone can read the code, anyone can find and report problems, and this now includes AI massively amplifying the inspection of the code. And because so many groups depend on open source software, there is a great collective motivation to resolve vulnerabilities. 

No software development method guarantees perfectly secure software, but the transparent, crowd-sourced nature of open source has distinct advantages over proprietary models when combating modern threats. Enterprises have always been, and will continue to be, vigilant to vulnerabilities as they are discovered. What has changed is the velocity. The number of published CVEs has grown by more than 520% since 2016. AI-powered scanning tools now discover critical zero-day vulnerabilities in hours, not months, and fewer than one percent of AI-discovered vulnerabilities have been patched. The challenge is now the enterprise’s operational ability to consume and deploy fixes fast enough. 

This problem is compounded by a coordination failure. Every major institution depends on the same core open source packages — Spring Framework, Jackson, Log4j, Pandas, OpenSSL — yet without coordination, each institution independently discovers the same vulnerabilities, develops patches in isolation, and maintains private forks that no one else benefits from. The result is redundant effort at enormous cost and uneven quality, while the broader ecosystem remains exposed. To stay secure, organizations must contribute to upstream communities, accelerate their operational baselines, and they must do it together.

What enterprises can do to get started today

Open source remains the safest foundation for innovation, but closing the threat window requires immediate action. Here are simple, actionable steps enterprises can take to protect their supply chains today:

  • Choose platforms backed by responsible vendors: Your infrastructure is the foundation everything else runs on. Make sure the vendors that support it are active contributors to the open source projects they ship. A vendor with a long track record of upstream contributions, security backports, and responsible disclosure is invested in keeping the community healthy, not just keeping your business.
  • Build a complete dependency inventory: Begin by auditing your application portfolios to map your baseline. Identify every open source library, transitive dependency, and pinned version currently running in production.
  • Define your patch-to-production cycle time: Measure your current reality. How long does it actually take for an upstream patch to navigate your internal security scans, testing, change advisory boards, and deployment pipelines? Once defined, set aggressive targets to shrink this window.
  • Automate rebuild and redeploy pipelines: As the threat window shrinks from months to hours, manual updates fail. Prepare your environment for frequent, deterministic, and automated application rebuilds so you can safely consume secure packages at velocity.
  • Use active security offerings: Adopt active supply chain solutions that provide zero-CVE baselines and runtime protection, such as Red Hat Hardened Images, Red Hat Trusted Libraries, and OpenShift Advanced Cluster Security, to move more quickly.

Accelerating change with Project Lightwell

As you automate your pipelines to consume fixes faster, IBM and Red Hat are building a remediation engine designed specifically to supply them. We recently introduced Project Lightwell, a joint $5 billion commitment backed by a global force of more than 20,000 engineers to redefine software supply chain security for the AI era.

Project Lightwell scales Red Hat’s proven, two-decade-long methodology of backporting enterprise-grade security patches. We are extending this rigorous engineering discipline above the operating system layer to the broader application framework and dependency landscape starting with Maven/Java and expanding to PyPI, npm, and beyond. By combining AI for high-volume threat ingestion with expert human engineering, we execute surgical fixes on the exact stable versions enterprises run in production, eliminating the need to blindly upgrade and break systems.

Without a mechanism to get fixes accepted upstream, every backport an enterprise develops on its own creates a permanent private fork, one that must be carried forward through every subsequent vulnerability, update, and dependency change. This increases an organization’s costs and risks. Project Lightwell breaks this cycle: Red Hat develops the fix, delivers it to the enterprise, and contributes it to the originating open source project. The fix becomes part of the public codebase.

Working together to protect your enterprise and all of open source

Securing the software supply chain is a collective industry challenge, one that no single enterprise can solve alone. Through Project Lightwell, we are collaborating with a premier cohort of financial and critical infrastructure leaders to establish a secure enterprise clearinghouse.

This collaborative intelligence network provides three capabilities that no enterprise can build independently. First, members share novel vulnerability findings and receive coordinated patches before public disclosure — turning isolated discovery into shared defense. Second, every patch is delivered production-ready: cryptographically signed, with machine-readable SBOM and security advisories to address compliance requirements. Third, and crucially, Project Lightwell operates on an upstream-always mandate. Every fix we develop is submitted back to the originating open source projects. By working together in this clearinghouse, we are not just protecting individual enterprises; we are systematically returning security advancements to the community, keeping open source safe for everyone.

Open source built the modern enterprise. Coordinated vigilance and Project Lightwell help this code remain secure by fixing it faster, as one community, in the open.

Article by Chris Wright, Chief Technology Officer and Senior Vice President, Global Engineering, Red Hat