นโยบายการเปิดเผย 90 วันตายแล้ว

 (blog.himanshuanand.com)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การเปิดเผยอย่างมีความรับผิดชอบภายใน 90 วัน สูญเสียประสิทธิภาพในการปกป้อง เพราะ LLM ทำให้ทั้งการค้นหาช่องโหว่และความเร็วในการพัฒนา exploit เพิ่มขึ้น
  • ภายใน 6 สัปดาห์ มีคน 11 คนรายงานบั๊กตรวจสอบการชำระเงินร้ายแรงตัวเดียวกัน เผยให้เห็นการ ค้นพบซ้ำพร้อมกัน
  • diff ของแพตช์ React ถูกเปลี่ยนเป็น exploit ที่ใช้งานได้ภายใน 30 นาที ด้วยความช่วยเหลือจาก AI
  • Copy Fail และ Dirty Frag ลุกลามจาก PoC ที่เปิดเผยสู่การถูกใช้โจมตีจริง ทำให้ embargo พังทลาย
  • ประเด็นร้ายแรงต้องถูกจัดการเป็น P0 ทันที และต้องนำ LLM เข้าไปไว้ใน security pipeline

เบื้องหลังที่ทำให้โมเดลการเปิดเผยอย่างมีความรับผิดชอบ 90 วันพังลง

  • ระยะเวลาเปิดเผยอย่างมีความรับผิดชอบ 90 วัน ถูกออกแบบบนสมมติฐานของโลกที่ผู้ค้นพบบั๊กมีน้อย และการพัฒนา exploit ทำได้ช้า
  • ในช่วง 12 เดือนที่ผ่านมา เครื่องมือที่ผู้ดูแลความปลอดภัย ผู้โจมตี และนักวิจัยใช้ ฉลาดขึ้นในอัตราใกล้เคียงกัน และมีมุมมองว่า LLM ลดเวลาสำหรับการค้นหาช่องโหว่และพัฒนา exploit ลงจนเกือบเป็นศูนย์
  • ในโมเดลแบบปี 2019 ตามสไตล์ Google Project Zero จะให้ผู้ขายเวลา 90 วัน โดยมีสมมติฐานดังนี้
    • แทบไม่มีใครอื่นเจอบั๊กเดียวกัน
    • ต่อให้มีคนอื่นเจอ ก็ต้องใช้เวลา
    • ผู้ขายจะมีเวลานำหน้าเพียงพอในการเขียนแพตช์
    • หลังเผยแพร่แพตช์แล้ว ผู้โจมตีจะต้องใช้เวลาหลายวันหรือหลายสัปดาห์กว่าจะ reverse engineer และสร้าง exploit ที่ใช้งานได้
  • สมมติฐานเหล่านี้ผิดทั้งหมด และกรอบเวลา 90 วันก็กลายเป็นโครงสร้างที่มอบ เวลาออกตัว 90 วัน ให้กับคนที่มีบั๊กอยู่แล้ว มากกว่าจะปกป้องผู้ใช้

กรณีศึกษา 1: ภายใน 6 สัปดาห์ มี 11 คนรายงานบั๊กร้ายแรงตัวเดียวกัน

  • ปลายเดือนเมษายน มีการรายงานบั๊กร้ายแรงไปยังบริษัทแห่งหนึ่ง แต่ทีม triage ตอบว่ามีการรายงานครั้งแรกตั้งแต่เดือนมีนาคม และผู้รายงานคนนี้คือคนที่ 11
  • ลักษณะของบั๊กคือ หลังจากซื้อสินค้าบนเว็บไซต์แล้ว ผู้โจมตีสามารถส่ง response ที่ดัดแปลงเองกลับไปยังเซิร์ฟเวอร์ได้ และเนื่องจากไม่มีการ ตรวจสอบลายเซ็น ของ response เซิร์ฟเวอร์จึงยอมรับมันตามนั้น
    • ตัวอย่างเช่น สามารถซื้อของราคา 5,000 ดอลลาร์ด้วยราคา 0 ดอลลาร์ หรือทำให้ระบบถือว่าซื้อเสร็จสมบูรณ์โดยไม่จ่ายเงินจริง
  • การที่มีคนต่างกัน 11 คนเจอบั๊กร้ายแรงตัวเดียวกันในเวลาประมาณ 6 สัปดาห์ แสดงให้เห็นรูปแบบที่นักล่าบั๊กซึ่งมี LLM ช่วยเหลือกำลังมุ่งไปสู่ช่องโหว่ตัวเดียวกันแทบพร้อมกัน
  • คนรู้จักจาก BlueWater CTF เคยชี้มาก่อนหลายเดือนแล้วว่า workflow ของผู้รายงานที่ไม่เกี่ยวข้องกันกำลังบรรจบสู่บั๊กเดียวกันด้วยความช่วยเหลือของ LLM
  • ฝั่ง triage เองก็สังเกตเห็นปรากฏการณ์เดียวกัน
    • @d0rsky เขียนว่า เมื่อพบช่องโหว่ใหม่ด้วย prompt, skill และ automation ของ LLM รายงานซ้ำที่มีรากสาเหตุเดียวกันจะหลั่งไหลเข้ามาภายในไม่กี่วัน
    • ถ้านักวิจัยทำซ้ำได้เร็วขนาดนี้ ก็ยิ่งน่ากังวลว่า blackhat ก็ทำแบบเดียวกันได้ก่อนมีแพตช์
  • ถ้ามีคนรายงานแล้ว 10 คน ก็อาจยังมีคนที่ไม่ได้รายงานอีก และ LLM ตัวเดียวกันก็ไม่ได้เปิดให้แค่นักวิจัยสายดีเท่านั้น
  • เครดิต CVE และ bug bounty ให้ได้เพียง 1 คน ทำให้อีก 9 คน หรือคนที่ไม่ได้รายงานตั้งแต่แรก ไม่ได้ถูกผูกไว้กับนาฬิกา 90 วัน
  • ในสถานการณ์นี้ กรอบเวลาเปิดเผย 90 วัน ไม่สามารถปกป้องผู้ใช้ได้ และกลายเป็นกลไกที่ซื้อเวลาให้คนที่มีบั๊กอยู่แล้ว

กรณีศึกษา 2: จากแพตช์ React ไปสู่ exploit ที่ใช้งานได้ใน 30 นาที

  • React ออกแพตช์และเผยแพร่บล็อกโพสต์สำหรับประเด็นด้านความปลอดภัยหลายรายการ
  • ใช้เวลา 30 นาที ในการอ่านแพตช์และสร้าง exploit ที่ใช้งานได้กับแอปทดสอบในเครื่อง
  • ประเด็นที่เปิดเผยนั้นเป็นการโจมตีแบบปฏิเสธการให้บริการ (DoS) และ AI จัดการงานส่วนใหญ่ทั้งการทำความเข้าใจ diff, การระบุ code path ที่เปราะบาง และการเขียน PoC
  • ในอดีต การเปลี่ยนแพตช์ที่เผยแพร่แล้วให้เป็น n-day exploit ที่ใช้งานได้ ต้องอาศัยนัก reverse engineer ที่มีทักษะสูงใช้เวลาหลายวันถึงหลายสัปดาห์ และช่วงเวลานี้คือกันชนความปลอดภัยให้ผู้ดูแลระบบอัปเดตได้
  • ตอนนี้บั๊กที่เรียบง่ายอาจใช้เวลาเพียงไม่กี่นาที และบั๊กซับซ้อนก็อาจอยู่ในระดับไม่กี่ชั่วโมง ทำให้นัก reverse engineer ระดับสูงไม่ใช่สิ่งจำเป็นอีกต่อไป
  • จึงต้อง สมมติว่าเมื่อมีแพตช์ exploit ก็มีอยู่แล้วทันที และแนวทางเลื่อนการ deploy ไปจนถึง maintenance window ถัดไปก็ไม่เหมาะอีกต่อไป

กรณีศึกษา 3: Copy Fail และ Dirty Frag ที่ปะทุติดกันใน Linux kernel

  • ในช่วง 2 สัปดาห์ที่ผ่านมา มีช่องโหว่ร้ายแรง 2 รายการโผล่ต่อเนื่องใน Linux kernel โดยทั้งคู่มี exploit แบบเปิดเผยสู่สาธารณะ และกระทบกับดิสทริบิวชันหลัก

  • Copy Fail

    • วันที่ 29 เมษายน Xint Code เผยแพร่ Copy Fail
    • Xint Code คือทีมเบื้องหลัง Theori และถูกแนะนำว่าเป็นทีมที่ชนะ DEF CON CTF มา 9 ครั้ง
    • Copy Fail คือ CVE-2026-31431 ซึ่งอธิบายว่าเป็น logic flaw ตรงไปตรงมาใน subsystem ด้าน crypto ของ kernel
    • ระบุว่าสามารถใช้ได้อย่างน่าเชื่อถือ 100% โดยไม่มี race condition และใช้เพียง สคริปต์ Python ขนาด 732 ไบต์ เพื่อยกระดับเป็น root บน Linux distributions ทั้งหมดที่ปล่อยตั้งแต่ปี 2017
    • ดิสทริบิวชันหลักอย่าง Ubuntu, RHEL, Amazon Linux, SUSE ได้รับผลกระทบ
    • ระบุว่าพบช่องโหว่นี้ด้วยการใช้ AI สแกน subsystem crypto/ ของ kernel อัตโนมัติประมาณ 1 ชั่วโมง และเป็นช่องโหว่ที่เปิดให้โจมตีมานาน 9 ปี
    • การวิเคราะห์เชิงเทคนิคอยู่ใน บทความของ Xint
    • มีแพตช์ออกมาใน mainline commit a664bf3d603d และมีมาตรการบรรเทาโดยปิดใช้งานโมดูล algif_aead
    • หลังจากนั้นมีการสังเกตสัญญาณว่าผู้โจมตีจากอิหร่านใช้ช่องโหว่นี้เจาะ Ubuntu servers และนำไปใช้เป็นโหนดในแคมเปญ DDoS
    • ช่องโหว่ยกระดับสิทธิ์ใน kernel ที่ AI ค้นพบ ใช้เวลาเพียงไม่กี่วันจาก PoC สาธารณะไปสู่การถูก weaponize โดยผู้โจมตีระดับรัฐ

  • Dirty Frag

    • ราว 1 สัปดาห์ต่อมาในวันที่ 7 พฤษภาคม Hyunwoo Kim(@v4bel) เผยแพร่ Dirty Frag
    • Dirty Frag เป็นช่องโหว่ที่เชื่อม CVE-2026-43284 กับ CVE-2026-43500
    • มันเชื่อมช่องโหว่สองตัวในโมดูลเครือข่าย IPSec ESP(esp4/esp6) และ RxRPC ของ kernel เข้าด้วยกัน
    • อยู่ในตระกูลบั๊กแบบเดียวกับ Copy Fail และ Dirty Pipe ใช้เทคนิค page-cache corruption แบบเดียวกัน แต่เส้นทางโจมตีต่างกัน
    • Dirty Frag ยังทำงานได้แม้ใช้มาตรการบรรเทา Copy Fail แล้ว
      • ต่อให้ blacklist algif_aead ก็ไม่ช่วย เพราะ Dirty Frag ไม่ได้ใช้โมดูลนั้น
    • ระบุว่าสามารถยกระดับสิทธิ์จากผู้ใช้ที่ไม่มีสิทธิ์เป็น root ได้อย่างแน่นอน และทำงานบน Ubuntu, RHEL 10.1, openSUSE, CentOS Stream, AlmaLinux, Fedora 44 และดิสทริบิวชันหลักอื่น ๆ
    • การคอมไพล์และรันทำได้ด้วยคำสั่งบรรทัดเดียว

  • กระบวนการเปิดเผย Dirty Frag และการล่มสลายของ embargo

    • Hyunwoo Kim รายงานไปยัง [email protected] ในวันที่ 29-30 เมษายน และส่งแพตช์เพื่อเปิดเผยต่อสาธารณะ
    • วันที่ 7 พฤษภาคม มีการประสานงานกับเมลลิงลิสต์ linux-distros และตกลง embargo 5 วัน
    • ในวันเดียวกัน ภายในไม่กี่ชั่วโมง บุคคลที่สามซึ่งไม่เกี่ยวข้องกันได้เปิดเผยข้อมูล exploit โดยละเอียดของช่องโหว่ ESP ทำให้ embargo แตก
    • หลังหารือกับผู้ดูแลดิสทริบิวชัน Hyunwoo จึงเผยแพร่ การวิเคราะห์ Dirty Frag ฉบับเต็ม, โค้ด exploit และ PoC ที่ใช้งานได้
    • ณ ตอนนั้น Linux distributions ที่มีแพตช์พร้อมให้ใช้งานมีจำนวน 0 ราย
    • ตามสถานะปัจจุบัน CVE-2026-43284 หรือฝั่ง ESP มีเพียง mainline fix ส่วน CVE-2026-43500 หรือคอมโพเนนต์ RxRPC ยังไม่มี upstream patch
    • Ubuntu, Red Hat, Tenable ต่างออก advisory ของตนเอง

  • การถูกใช้โจมตีจริงของ Dirty Frag

    • ทีม Microsoft Defender ยืนยัน การถูกใช้โจมตีจริงในวงจำกัดภายใน 24 ชั่วโมงหลังการเปิดเผย
    • ผู้โจมตีได้รับ SSH access, แจกจ่าย ELF binary, ใช้ su เพื่อให้ได้สิทธิ์ root, แก้ไขการตั้งค่าการยืนยันตัวตน, ลบไฟล์ session และทำ lateral movement
    • CTS(@gf_256) สรุปว่า “responsible disclosure is dead🤦”

สิ่งที่ตายไปจริง ๆ

  • กรอบเวลาเปิดเผย 90 วัน ไม่ใช่สิ่งที่แก้ไขปรับปรุงได้อีกต่อไป แต่เป็นโมเดลที่จบสิ้นแล้ว
  • โมเดลนี้เหมาะกับโลกที่ผู้ค้นพบน้อยและการพัฒนา exploit ช้า แต่ LLM ทำให้ผู้ค้นพบมีมากขึ้นและทำให้การพัฒนา exploit เร็วขึ้น
  • เมื่อคนที่ไม่เกี่ยวข้องกัน 10 คนสามารถเจอบั๊กเดียวกันได้ภายใน 6 สัปดาห์ และ AI สามารถเปลี่ยน patch diff เป็น exploit ที่ใช้งานได้ใน 30 นาที กรอบเวลา 90 วันก็ไม่ปกป้องใครได้
  • Copy Fail ขยับจากการสแกนด้วย AI ไปสู่ PoC สาธารณะ และต่อไปถึงการ weaponize โดยผู้โจมตีระดับรัฐภายในไม่กี่วัน
  • Dirty Frag มี embargo พังภายในไม่กี่ชั่วโมงเพราะบุคคลที่สามพบตระกูลบั๊กเดียวกันอย่างอิสระ
  • ในสภาพแวดล้อมที่ช่องโหว่เดียวกันถูกค้นพบซ้ำอย่างอิสระพร้อมกันโดยนักวิจัยหลายคนและเครื่องมือ AI การประสานงานการเปิดเผยจึงรักษาไว้ได้ยาก
  • รอบการออกแพตช์รายเดือน ก็จบแล้วเช่นกัน
    • กรอบเวลา 30 วันระหว่างช่องโหว่กับการแก้ไขตั้งอยู่บนสมมติฐานว่าผู้โจมตีช้ากว่า release train
    • แต่เมื่อ Microsoft พบการถูกใช้โจมตี Dirty Frag จริงภายใน 24 ชั่วโมง maintenance window รายเดือนก็ไม่ได้เป็นกันชนความปลอดภัย แต่กลายเป็นหน้าต่างสำหรับการโจมตี
  • แนวทางรอ advisory ก็จบแล้ว
    • ระหว่างที่ฝ่ายป้องกันกำลังอ่านคำอธิบาย CVE ฝ่ายโจมตีกำลังอ่าน git log --diff-filter=M
    • advisory เป็นผลลัพธ์ปลายน้ำ ส่วน patch diff คือสัญญาณ

การตอบสนองที่อุตสาหกรรมต้องเปลี่ยน

  • ข้อสรุปคือประเด็นด้านความปลอดภัยร้ายแรงทั้งหมดต้องถูกมองเป็น P0 และแก้ไขทันที
  • ไม่ใช่ “ภายใน 24 ชั่วโมง”, “ใน sprint ถัดไป” หรือ “หลังประเมินผลกระทบ” แต่ต้องถึงระดับหยุดงานที่กำลังทำอยู่แล้วแก้ทันที
  • แม้การ deploy production จะซับซ้อนและมีเหตุผลด้าน change management แต่สภาพแวดล้อมภัยคุกคามไม่ได้รอขั้นตอน change management

  • ผู้ขาย

    • เวลาจะเริ่มนับตั้งแต่วินาทีที่รายงานบั๊กร้ายแรงเข้ามา
    • ไม่ใช่ตอน triage เสร็จ หรือเมื่อทีมวิศวกรรมรับช่วงต่อ แต่เป็นตอนที่รายงานมาถึง
    • ถ้ามีคนหนึ่งรายงาน ต้องสมมติว่ามีอีก 10 คนมีมันอยู่แล้ว และอย่างน้อย 1 คนในนั้นไม่ใช่ฝ่ายมิตร

  • นักวิจัย

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

  • การจัดการช่องโหว่

    • การจัดการช่องโหว่ต้องเป็นแบบเรียลไทม์
    • รูปแบบ “สแกนรายสัปดาห์, triage ใน sprint, ออกแพตช์ตามรอบ” เป็นไทม์ไลน์ที่ผู้โจมตีผ่านพ้นไปแล้ว
    • เวลาตอบสนองสูงสุดใหม่สำหรับประเด็นร้ายแรงไม่ใช่หลายวัน แต่เป็น ไม่กี่ชั่วโมง และแม้แค่นั้นก็อาจช้าเกินไป

ทำไม Blue Team ต้องนำ LLM เข้าไปอยู่ใน defense pipeline

  • ผู้โจมตีได้นำ LLM เข้าสู่ exploit pipeline ไปแล้ว และฝั่งป้องกันก็ต้องเคลื่อนที่ด้วยความเร็วเดียวกัน
  • ต้องบูรณาการ LLM ตั้งแต่จังหวะ code push
    • ทุก pull request, merge และ deploy ควรรัน AI-assisted security review เป็นส่วนหนึ่งของ CI pipeline
    • ควรรันตอน push เหมือน linter และ unit test ไม่ใช่การ audit รายไตรมาสหรือการตรวจย้อนหลัง
    • ถ้ามีช่องโหว่ ต้องจับให้ได้ก่อนถึง production และต้นทุนการแก้ใน PR review ก็ต่ำกว่าการแก้หลัง CVE ถูกเปิดเผยมาก
  • ต้องบูรณาการ LLM ในการวิเคราะห์แพตช์ด้วย
    • เมื่อ upstream dependency ออก security patch, pipeline ควรดึง diff มาอัตโนมัติ วิเคราะห์การเปลี่ยนแปลง ประเมินว่ากระทบ codebase ของตัวเองหรือไม่ และยกธงเตือน
    • ควรเกิดขึ้นโดยอัตโนมัติภายในไม่กี่นาทีทันทีที่แพตช์ขึ้น public repository ไม่ใช่พึ่งให้คนอ่านเมลลิงลิสต์แล้วค่อยเปิด Jira ticket
    • ถ้า Xint Code หา Copy Fail ได้ด้วยการสแกนอัตโนมัติ 1 ชั่วโมง ก็ควรสแกน dependency ของตัวเองแบบเดียวกัน
  • ต้องใช้ LLM กับ dependency scanning ด้วย
    • supply chain แข็งแรงได้แค่เท่า transitive dependency ที่อ่อนแอที่สุด
    • AI-based dependency scanner สามารถติดตามผลกระทบของช่องโหว่ใน dependency tree, ระบุเวอร์ชันที่ได้รับผลกระทบ และเสนอเส้นทางอัปเกรดได้
    • ต้องรันอย่างต่อเนื่อง ไม่ใช่รายสัปดาห์
  • ต้องใช้ AI ทดสอบแพตช์ก่อนปล่อยแพตช์
    • หากในกรณีของ React LLM สามารถเปลี่ยนแพตช์เป็น exploit ได้ใน 30 นาที ฝ่ายป้องกันก็ควรใช้เครื่องมือเดียวกันตรวจสอบก่อนเผยแพร่แพตช์
    • ต้องตรวจว่าแพตช์แก้ปัญหาได้จริงและไม่ได้สร้างปัญหาใหม่
    • ควรใช้กับการสร้าง regression test และตรวจว่ามี pattern แบบเดียวกันอยู่ในจุดอื่นของ codebase หรือไม่
  • หน้าต่างระหว่าง “มีช่องโหว่” กับ “ช่องโหว่ถูกใช้โจมตี” กำลังเข้าใกล้ศูนย์ และฝั่งป้องกันก็ต้องทำ automation ให้เร็วเท่ากับฝั่งโจมตี
  • จะมี zero-day มากขึ้นและถูกใช้โจมตีในสภาพแวดล้อมจริงเร็วขึ้น ด้วยเหตุผลเรื่องเครื่องมือชุดเดียวกัน, อุปสรรคในการเข้าถึงที่ลดลง, จำนวนผู้ค้นพบที่เพิ่มขึ้น และไทม์ไลน์ที่สั้นลง
  • ทีมที่จะรอดจากการเปลี่ยนผ่านนี้ คือทีมที่ทำให้ AI เป็นองค์ประกอบชั้นหนึ่งของ security pipeline ก่อนที่จะถูกบังคับให้ต้องทำ

บทสรุป

  • ความจริงใหม่คือผู้ดูแลระบบที่กำลังอ่าน advisory ของ Dirty Frag ต้องเผชิญกับสถานการณ์ที่ยังไม่มีแพตช์, exploit ถูกเปิดเผยแล้ว, Microsoft รายงานการถูกใช้โจมตีจริงแล้ว และมาตรการบรรเทาคือปิดโมดูล IPSec ขณะที่ต้องไปแตะเซิร์ฟเวอร์ 400 เครื่อง
  • นโยบายเปิดเผย 90 วัน, รอบการออกแพตช์รายเดือน, และ สมมติฐานว่ามีเวลาอยู่ระหว่างการเปิดเผยกับการถูกใช้โจมตี ล้วนตายแล้ว
  • สิ่งที่ยังเหลืออยู่คือความสามารถในการเคลื่อนที่ให้เร็ว ทำ automation ให้หนัก และปฏิบัติต่อบั๊กร้ายแรงราวกับเป็นเหตุฉุกเฉินจริง
  • คลื่น AI ที่ทำลายโมเดลเดิม ก็ทำให้โมเดลใหม่อย่างการออกแพตช์ที่เร็วขึ้น การสแกนอัตโนมัติ การข่าวกรองภัยคุกคามแบบเรียลไทม์ และ AI-assisted code review เป็นไปได้พร้อมกัน
  • เครื่องมือมีอยู่แล้ว ประเด็นสำคัญคือฝ่ายป้องกันจะใช้มันก่อนฝ่ายโจมตีหรือไม่ และในตอนนี้ฝ่ายโจมตีกำลังนำอยู่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Lobste.rs

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

  • นโยบาย การเปิดเผยอย่างมีความรับผิดชอบ เดิมทีก็เป็นเรื่องแต่งที่ผู้คนแค่แสร้งทำเป็นเชื่อกันตามมารยาทอยู่แล้ว ตั้งแต่แรกมันก็เป็นแค่การทำตามบรรยากาศ และเครื่องมือค้นหาช่องโหว่ที่อิง LLM ก็แค่เปิดโปงความจริงนั้นออกมา

  • รู้สึกค่อนข้างน่าขันเหมือนกันที่ตัวบทความนี้เองก็ มีกลิ่นว่า LLM เขียน

    • ก็ฟังขึ้นนะ ถ้ามีไอเดียต้นฉบับก็ต้องรีบเผยแพร่ก่อนที่คนอื่นจะทำ การคิดเชิงวิพากษ์และการทบทวนตนเอง ตายไปแล้ว และถ้าไม่โพสต์ลงบล็อกภายใน 39 นาทีหลังคิดอะไรออก ก็จะมีคนอื่นทำก่อน :P
    • สำหรับฉันดูไม่เป็นแบบนั้น สไตล์การเขียนแบบนี้มีอยู่ใน บทความเทคโนโลยีก่อนยุค LLM มานานแล้ว และ LLM หลัก ๆ ก็มักเขียนต่างจากบทความนี้อยู่เล็กน้อย
    • อ่านเหมือนโฆษณาที่ปลุกปั่นความกลัว
    • ไม่ว่าจะดีหรือร้าย ตอนนี้ก็ดูเหมือนอะไร ๆ จะไหลไปทางนี้แล้ว

  • บางทีสิ่งที่ตายไปอาจเป็นยุคของ โปรแกรม C แบบบูติกงานคราฟต์ทำมือ ที่ใช้ในสถานการณ์ภารกิจวิกฤตก็ได้