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

จริง ๆ แล้วแค่ยกเครื่องโค้ดใหม่ทั้งหมดแล้วยังจะให้ดีขึ้นสัก 2~3 เท่าก็เป็นเรื่องยากอยู่แล้ว แต่นี่แค่เปลี่ยนไม่กี่บรรทัดแล้วดีขึ้นได้สูงสุดถึง 400 เท่า น่าทึ่งจริง ๆ ครับ

น่าทึ่งมาก

ถ้าเร็วขึ้น 2 เท่า อาจเป็นเพราะทำอะไรได้ฉลาดขึ้น แต่ถ้าเร็วขึ้น 100 เท่า ก็แค่หยุดทำเรื่องโง่ ๆ เท่านั้น

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

อืม ก็น่าจะเป็นแค่ระดับกระแสตีกลับจากพวกเฮฟวี่ยูสเซอร์ล่ะมั้ง

มีประโยชน์มากครับ 👍👍

ลองแยกเครื่องสำหรับเล่นเกมโดยเฉพาะออกไปดีไหมครับ? ผมแทบไม่เล่นเกมเลยเลยไม่ได้ทำแบบนั้น แต่คนที่เล่นกันส่วนใหญ่ก็มักจะทำแบบนั้นกันครับ

อ๊ะ ผมเรียนสาขาที่เกี่ยวกับคอมพิวเตอร์ จบมาเมื่อเดือนกุมภาพันธ์ปีนี้ และตอนนี้ยังไม่มีงานทำครับ ผมใช้ Linux มาตั้งแต่ปี 2015 ก่อนจะเริ่มเรียนด้านการพัฒนาเสียอีก!

ดูเหมือนว่าความสามารถในการสร้างและให้บริการโครงสร้างพื้นฐานตามที่ Apple ต้องการก็น่าจะมีอิทธิพลอย่างมากต่อการตัดสินใจเลือกเช่นกัน

ถึงท้ายที่สุด แม้บทความนี้จะไม่ได้พูดตรง ๆ แต่ก็เท่ากับยอมรับว่ากลยุทธ์ของ Apple ที่ต้องการสร้างสภาพแวดล้อม AI ในระดับที่ตัวเองต้องการแบบ in-house ภายใน ecosystem ของ Apple นั้นล้มเหลวแล้ว.. (ต่อจาก Apple Car) อดคิดไม่ได้ว่าถ้าเร็วกว่านี้สัก 2 ปีจะเป็นอย่างไรบ้าง

สิริจ๋า...
ฉันเป็นเด็กประถมครับ/ค่ะ

ขอบคุณสำหรับข้อมูลและสรุปที่ละเอียดครับ ตอนแรกผมนึกว่าเป็นอะไรที่คล้ายกับ Capabilities ของ Linux เสียอีก แต่ดูเหมือนว่าจะเป็นแนวทางที่รวมการวิเคราะห์แบบไดนามิกเข้าไปด้วยสินะครับ

น่าคาดหวังจัง..

ผมเลยลองให้ Gemini ช่วยอธิบายดูเหมือนกันครับ ผมเองก็ไม่ได้ดูแลงานด้านความปลอดภัยโดยตรงเลยไม่ค่อยรู้เหมือนกัน

[รายงานเชิงลึก: เทคโนโลยีความปลอดภัยยุคถัดไปที่ PyPI และ OpenSSF กำลังจับตาอย่าง Capability Analysis]

ในช่วงหลังมานี้ การโจมตีแบบ supply chain ที่คุกคามระบบนิเวศโอเพนซอร์สมีความซับซ้อนมากขึ้น ทำให้ PyPI (Python Package Index) และ OpenSSF (Open Source Security Foundation) เร่งผลักดันการนำ Capability Analysis (การวิเคราะห์ความสามารถ/ศักยภาพ) มาใช้ แทนการพึ่งพาวิธีจับคู่แพตเทิร์นแบบเดิมเพียงอย่างเดียว

หัวใจสำคัญของเทคโนโลยีนี้คือ การมองทะลุให้ได้ว่าแพ็กเกจ “ทำอะไรได้จริง” ไม่ใช่แค่ “แสร้งว่าเป็นอะไร”

1. Capability Analysis (การวิเคราะห์ความสามารถ) คืออะไร?

ถ้าเปรียบการสแกนไวรัสแบบเดิมเป็นการตรวจเทียบกับ “รายชื่อผู้ต้องหา” (signature ของมัลแวร์ที่รู้จักแล้ว) Capability Analysis ก็คือการตรวจสอบ “ความสามารถในการกระทำ” ของแพ็กเกจโดยตรง

ไม่ว่าแพ็กเกจจะปลอมตัวเป็นยูทิลิตีปกติเพียงใด ถ้าต้องการยึดระบบหรือขโมยข้อมูล ก็จำเป็นต้องใช้ทรัพยากรบางอย่างของระบบปฏิบัติการอยู่ดี เช่น เครือข่าย ไฟล์ หรือโปรเซส เทคโนโลยีการวิเคราะห์นี้จะติดตามว่าเมื่อแพ็กเกจรันโค้ด มันมีการใช้ “สิทธิ์อ่อนไหว (Capabilities)” ต่อไปนี้หรือไม่

• เครือข่าย (Network): สคริปต์ติดตั้งแอบส่งข้อมูลออกไปยัง IP ภายนอก (Exfiltration) หรือพยายามสื่อสารภายนอกหรือไม่?
• ระบบไฟล์ (FileSystem): มีการพยายามเข้าถึงหรือแก้ไขไฟล์สำคัญ เช่น SSH key, AWS credentials, /etc/passwd หรือไม่?
• การรันโปรเซส (Execution): มีการรันคำสั่งเชลล์ (Shell) หรือสร้างโค้ดแบบไดนามิก (eval, exec) เพื่อแตกโปรเซสลูกหรือไม่?

2. การใช้งานจริงและเครื่องมือความปลอดภัยหลักที่คาดว่าเกี่ยวข้อง

ปัจจุบัน ในโครงการของ OpenSSF และกลุ่มวิจัยด้านความปลอดภัย มีการพัฒนาและนำเครื่องมือต่อไปนี้ไปใช้ใน pipeline เพื่อทำการวิเคราะห์ลักษณะนี้

A. OpenSSF Package Analysis (โครงการทางการ)
- ภาพรวม: เป็นโครงการที่ OpenSSF เป็นผู้ผลักดัน โดยจะนำแพ็กเกจจาก PyPI หรือ NPM มาติดตั้งและรันจริงในสภาพแวดล้อม sandbox ที่แยกออกมา
- หลักการทำงาน: ดักจับ system call ที่เกิดขึ้นระหว่างการรันของแพ็กเกจในระดับเคอร์เนล เพื่อเก็บข้อมูลพฤติกรรม เช่น “แพ็กเกจนี้พยายามเชื่อมต่อไปยัง 192.168.x.x ระหว่างการติดตั้ง”
- เทคโนโลยีที่ใช้: ใช้ gVisor (sandbox), Strace (ติดตาม system call) เป็นต้น

B. Packj
- ภาพรวม: เป็นเครื่องมือที่พัฒนาจากงานวิจัยในภาควิชาการ (เช่น Georgia Tech) และเชี่ยวชาญด้านการติดแท็ก “ความสามารถเสี่ยง (Risky Capabilities)” ของแพ็กเกจ
- หลักการทำงาน: ใช้ทั้ง static analysis และ dynamic analysis ควบคู่กัน โดยค้นหา sensitive API call ในซอร์สโค้ด และวิเคราะห์ metadata ของแพ็กเกจเพื่อระบุว่าเป็น “แพ็กเกจที่ถูกทิ้งร้าง” หรือเป็น “typosquatting (ปลอมชื่อเลียนแบบ)” หรือไม่
- จุดเด่น: สามารถตรวจจับชุดสิทธิ์ที่ดูผิดปกติได้ เช่น “แพ็กเกจนี้เป็นไลบรารีเสียง แต่กลับมีความสามารถด้านการสื่อสารเครือข่ายและเข้าถึงสมุดรายชื่อ”

C. GuardDog
- ภาพรวม: เป็นเครื่องมือ CLI ที่ Datadog เปิดซอร์สไว้ โดยใช้ Semgrep (เอนจิน static analysis) เพื่อตรวจหารูปแบบที่เป็นอันตราย
- หลักการทำงาน: ระบุรูปแบบโค้ดเชิงฮิวริสติก (Heuristics) ที่สะท้อน “ฟังก์ชันอันตราย” เช่น โค้ดที่ถูกทำให้อ่านยาก, สคริปต์ขุดเหรียญ, ตัวดาวน์โหลดไฟล์ปฏิบัติการที่ถูกซ่อนไว้ในแพ็กเกจ

D. Falco & Sysdig
- ภาพรวม: เป็นเครื่องมือด้าน runtime security สำหรับสภาพแวดล้อมแบบ cloud-native
- บทบาท: ใช้เป็นเอนจินสำหรับตรวจจับพฤติกรรมผิดปกติแบบเรียลไทม์เมื่อแพ็กเกจทำงานอยู่ในคอนเทนเนอร์ (เช่น การเปิดเชลล์โดยไม่คาดคิด หรือการอ่านไฟล์สำคัญ)

3. เอกสารอ้างอิงและลิงก์ที่เกี่ยวข้อง

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

• บล็อกทางการของ OpenSSF Package Analysis (ประกาศและอธิบายหลักการ)
  https://openssf.org/blog/2022/…

• GitHub ของ OpenSSF Package Analysis (ซอร์สโค้ดและสถาปัตยกรรม)
  https://github.com/ossf/package-analysis

• GitHub ของ Packj (ดาวน์โหลดเครื่องมือและดูความสามารถโดยละเอียด)
  https://github.com/ossillate-inc/packj

• GitHub ของ GuardDog (เครื่องมือตรวจจับแพ็กเกจอันตรายบน PyPI/NPM ของ Datadog)
  https://github.com/DataDog/guarddog

• รายงานความปลอดภัยของ PyPI (ขั้นตอนการรายงานและจัดการแพ็กเกจอันตราย)
  https://pypi.org/security/

เท่าที่ผมเข้าใจ น่าจะเป็นการดึงแพ็กเกจมารันโค้ด แล้วก็แตกไฟล์หรือทำ static analysis, dynamic analysis อะไรทำนองนั้น เพื่อดูว่าโค้ดนั้นทำอะไรอยู่ เพราะส่วนใหญ่มัลแวร์ก็มักจะแพร่กระจายในลักษณะนั้นครับ

ฉันก็คิดแบบเดียวกันบ้างเป็นบางครั้ง มันไม่มีที่สิ้นสุด

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

จุดร่วมของ skills..

ผมย้ายไปใช้ starship แล้วครับ

มีการพูดถึง Tailscale กันเยอะเลยนะครับ จริง ๆ แล้วก็แทบไม่มีทางเลือกอื่นที่เหมาะสมเท่าไหร่..

ผมคิดว่าการไม่ไว้วางใจแบบหัวแข็งนั้นผิดพอ ๆ กับการเชื่ออย่างงมงายแบบสุดโต่ง
สิ่งสำคัญคือการใช้งานโดยพิจารณาทั้งข้อดีและข้อเสียให้เหมาะสม แต่ผมมองว่าการสร้างบรรยากาศแบบ FOMO อย่างเดียวเป็นกลยุทธ์ทางการตลาดของบริษัท AI

ถ้าตอนนี้คุณยังผสาน AI เข้ากับงานของตัวเองได้ไม่มากพอ การมี FOMO ไว้บ้างก็ดูไม่ใช่เรื่องเสียหาย