DevOps revolution — แล้ว Security ที่หายไปไหน#

ประมาณปี 2010 ขึ้นไป — วงการเปลี่ยนวิธีคิด. DevOps (Development + Operations) = รวมทีม dev (คนเขียนโค้ด) + ทีม ops (คนดูแล server) ให้ทำงานด้วยกัน. แทนที่จะ deploy ปีละ 4 ครั้ง — กลายเป็น deploy วันละ 50-100 ครั้ง (Netflix, Amazon, Google ทำงานแบบนี้)

เครื่องมือสำคัญของ DevOps — CI/CD pipeline — Continuous Integration / Continuous Deployment (สายพานการผลิตซอฟต์แวร์อัตโนมัติ). กดปุ่ม commit → โค้ดวิ่งผ่าน automated test → build เป็น container image → deploy ขึ้น production — ทั้งหมดทำใน 10-20 นาทีโดยไม่มีคนกดมือ

แต่… security ทำตามไม่ทัน. ถ้า security audit ใช้เวลา 1 อาทิตย์ — แต่ทีม dev deploy วันละ 50 ครั้ง — security เป็นคอขวด เกินรับไหวทันที. ทางออกของหลายบริษัท — “ลด security check” → ผลคือ vulnerability หลุดขึ้น production บ่อย

DevSecOps — รวม Security เข้าไปในสายพาน#

ประมาณปี 2015-2016 — วงการตอบโจทย์ใหม่. DevSecOps = Dev + Sec + Ops — รวม security เข้าไปใน CI/CD pipeline เป็น automated step — เหมือน automated test แต่เป็นการทดสอบ security

แทนที่จะให้คน security นั่งตรวจโค้ดตอนจบ — เรา ใส่ security tool ลงใน pipeline ทุก stage:

• ก่อน commit: pre-commit hook scan secrets + lint
• ตอน push: SAST scan โค้ด + SCA scan dependencies
• ตอน build: scan container image หา vulnerability
• ตอน deploy: scan IaC (Infrastructure as Code — Terraform/Helm) หา misconfiguration
• ตอน run: DAST + runtime protection เฝ้าระวัง

ทุก check ทำ อัตโนมัติ + เร็ว (วินาที-นาที ไม่ใช่อาทิตย์). ถ้าเจอ critical issue → pipeline fail → developer แก้ทันที ก่อนปัญหาแพร่ไปไกล

Shift-Left — ทำไม “ซ้าย” ถึงสำคัญ#

ลองวาด pipeline บนกระดาษเป็น เส้นซ้าย-ขวา ดูครับ:

1
[เขียนโค้ด] → [Build] → [Test] → [Deploy] → [Production]
2
   ซ้ายสุด                                       ขวาสุด

ในวงการมีตัวเลขที่อ้างกันบ่อย — เจอ bug ตอนเขียนโค้ด ค่าแก้ $1 / เจอตอน QA$10 / เจอตอน production $100 / ถ้าโดน breach$1,000-10,000+. ทุก stage ที่เลื่อนไปขวา — ค่าแก้แพงขึ้น 10 เท่า

Shift-Left = เลื่อนการตรวจไปทางซ้ายของ pipeline — ใกล้กับ “ตอนเขียนโค้ด” ที่สุดเท่าที่จะทำได้. ตรวจซ้าย = ถูก + แก้เร็ว + ไม่ต้องทุบของที่ deploy ไปแล้ว

ในเมืองที่ของมีค่าของเรา — เปรียบเทียบง่ายๆ:

• ตรวจขวาสุด = ตรวจตอนของขึ้น shelf ในห้างแล้ว — เจอปัญหาก็ต้อง recall ทั้งล็อต (เสียเงิน + ภาพลักษณ์)
• ตรวจกลางทาง = ตรวจตอนของถึงโกดังกระจายสินค้า — เจอปัญหา กักไว้ แต่เสียเวลาขนกลับ
• ตรวจซ้ายสุด = ตรวจตอนสายพานการผลิตในโรงงาน — เจอปัญหา แก้ที่ source ก่อนทำของล็อตถัดไป — ถูก + เร็ว + ป้องกันได้จริง

มุมผู้บริหาร: ถ้าทีม IT ของคุณยังใช้ model “security audit ก่อน go-live เท่านั้น” — ขอให้คุณรู้ว่า คุณตามไม่ทันโลกแล้ว 5-10 ปี. โลกยุค DevSecOps — security ต้อง fold เข้าไปใน workflow ของ dev ตั้งแต่วันแรก. KPI ของ CISO ในบริษัทยุคใหม่ไม่ใช่ “กี่ครั้งที่เรา block release” — แต่เป็น “กี่ % ของ vulnerability ที่เจอ + แก้ก่อนถึง production” (target ดี = 80%+). ถ้าทีม security ของคุณยัง โยนงานคืน + ตำหนิทีม dev ทุก release — คุณไม่ได้มี security culture คุณมี ปัญหาการเมืองภายในที่ปลอมเป็น security

SAST — สแกนโค้ดก่อนรัน#

SAST = Static Application Security Testing (การทดสอบความปลอดภัยของแอปแบบสถิต) — แปลภาษาคนคือ “อ่านโค้ดตรงๆ โดยไม่รันแอป”. เปรียบเหมือน คนตรวจพิมพ์เขียวก่อนสร้างบ้าน — ดูแบบบนกระดาษว่ามีจุดที่ผิด safety code หรือไม่

ตัวอย่างจุดที่ SAST จับได้:

• SQL injection vulnerability — โค้ดเอาข้อมูลจาก user มาต่อตรงๆ ใน SQL query (ไม่ใช้ parameterized query)
• Hardcoded password — เขียน password ลงในโค้ดตรงๆ
• Insecure crypto — ใช้ MD5 (broken) แทน SHA-256
• Buffer overflow ในภาษา C/C++
• Path traversal — ไม่ validate input ก่อนเปิดไฟล์

เครื่องมือยอดนิยม — Snyk Code, SonarQube, Semgrep (open-source, เร็วมาก), GitHub CodeQL (Microsoft ใช้ตรวจโปรเจกต์ของตัวเอง), Checkmarx, Veracode

ข้อดี — เจอ bug ตั้งแต่ตอนเขียนโค้ด (ซ้ายสุดของ pipeline) ข้อจำกัด — เห็นเฉพาะโค้ดที่คุณเป็นเจ้าของ ไม่เห็น library 3rd party + false positive เยอะ (ต้องจูน)

DAST — สแกนแอปตอนรันอยู่#

DAST = Dynamic Application Security Testing (การทดสอบความปลอดภัยของแอปแบบไดนามิก) — ตรงข้ามกับ SAST. DAST รันแอปจริง + ส่ง attack จริงเข้าไป + ดูว่าแอปตอบสนองยังไง. เปรียบเหมือน มืออาชีพมาทดลองงัดประตูบ้าน — ดูว่ามีจุดอ่อนตรงไหน

ตัวอย่างจุดที่ DAST จับได้:

• XSS (Cross-Site Scripting) — ส่ง script เข้าไปในช่อง input + ดูว่าโดน execute หรือไม่
• CSRF — ทดลองสร้าง request ปลอม
• Authentication bypass — ลองเข้า admin panel โดยไม่ login
• Server misconfiguration — เซิร์ฟเวอร์เปิด port ที่ไม่ควรเปิด
• Sensitive data exposure — แอปตอบกลับ stack trace + error detail

เครื่องมือยอดนิยม — OWASP ZAP (open-source, ฟรี, ใช้กันทั่วโลก), Burp Suite (มาตรฐานของ pentester), Acunetix, Invicti

ข้อดี — เจอปัญหาที่ใช้งานจริงเท่านั้นที่เห็น (เช่น race condition) ข้อจำกัด — ต้องรอจน build เสร็จ + รันได้ก่อน (ขวากว่า SAST) + ครอบคลุมแค่ส่วนที่ scanner เดินผ่าน

SCA — สแกน library 3rd party#

นี่คือตระกูลที่ผมอยากให้คุณ โฟกัสที่สุด. SCA = Software Composition Analysis (การวิเคราะห์องค์ประกอบของซอฟต์แวร์) — สแกน library ของคนอื่น ที่แอปคุณเอามาใช้

ทำไมสำคัญ — ตามที่ผมเล่าตอนต้น — แอปยุคใหม่ 95% เป็นโค้ดของคนอื่น. ถ้า library ไหนมี CVE (Common Vulnerabilities and Exposures — ฐานข้อมูลช่องโหว่ที่รู้กันแล้ว) — แอปคุณก็ติดด้วย — แม้โค้ดคุณเองจะสมบูรณ์แบบ

เครื่องมือยอดนิยม — Snyk Open Source, Dependabot (ฟรีของ GitHub), Mend (เดิม WhiteSource), GitHub Advanced Security, OWASP Dependency-Check (open-source)

วิธีทำงาน — สแกนไฟล์ package.json (Node.js), requirements.txt (Python), pom.xml (Java), go.mod (Go) — เทียบกับฐานข้อมูล CVE — ถ้าเจอ library เวอร์ชันที่มีช่องโหว่ → แจ้งเตือน + แนะนำเวอร์ชันใหม่ที่ patch แล้ว

Real case ที่สอนทุกบริษัท — Log4Shell ปี 2021 (CVE-2021-44228). Log4j คือ library log ของ Java ที่ใช้ในแอป หลายร้อยล้านตัวทั่วโลก — ตั้งแต่ Minecraft ถึงระบบของ Cloudflare. เดือนธันวาคม 2021 — มีคนพบว่าส่ง string พิเศษ เข้าไปใน log → Log4j ดึง remote code มารัน → RCE (Remote Code Execution — รันโค้ดอะไรก็ได้บนเครื่อง) ทันที. CVSS score 10.0 (สูงสุดของ scale). หลายล้านระบบทั่วโลกต้อง patch ใน 48 ชั่วโมง

ตอนนั้นบริษัทที่มี SCA tool ที่ดี → รู้ทันทีว่าใช้ Log4j เวอร์ชันไหน + patch อะไร + ใน app ตัวไหน. บริษัทที่ไม่มี — นั่งสำรวจมือเป็นอาทิตย์ ว่าใช้ Log4j ที่ไหนบ้าง — ในขณะที่โจรกำลังโจมตี

มุมผู้บริหาร: SCA = ROI สูงที่สุดในกลุ่ม security tool สำหรับบริษัทขนาดกลาง. ใช้งานง่าย + automate ได้ + ครอบคลุม attack surface ที่ใหญ่ที่สุด (3rd party library). ถ้าบริษัทคุณยังไม่มี SCA หรือ Dependabot — นี่ควรเป็น โปรเจกต์อันดับ 1 ของไตรมาสนี้. ถาม CISO ของคุณ — “เรามี dependency อะไรบ้างที่มี critical CVE เปิดอยู่ตอนนี้?” ถ้าตอบไม่ได้ในที่ประชุม → คุณรู้แล้วว่าต้องทำอะไรก่อน

IAST — agent ฝังในแอปตอนรัน#

IAST = Interactive Application Security Testing — ลูกผสมของ SAST + DAST. ฝัง agent ลงในแอปตอนรัน → agent เห็นทั้งโค้ด + flow จริง ของ request → จับ vulnerability ได้แม่นกว่า DAST + ครอบคลุมกว่า SAST. ข้อเสีย — กิน performance + setup ยุ่ง — เหมาะกับบริษัทใหญ่ที่มีทีม security เฉพาะ

เครื่องมือ — Contrast Security, Synopsys Seeker, Veracode IAST

IaC Scanning — สแกน infrastructure ก่อน deploy#

มาถึงตระกูลใหม่ที่สำคัญสุดสำหรับ cloud + container era ครับ. ใน EP.32-33 ผมพาคุณดู Infrastructure as Code (IaC) ผ่านๆ — Terraform, CloudFormation, Helm chart, Kubernetes manifest. ของพวกนี้คือ โค้ดที่อธิบาย infrastructure (network, server, storage, security group)

IaC Scanning = สแกนโค้ดพวกนี้ก่อน deploy — หา misconfiguration ที่ทำให้เกิดช่องโหว่

ตัวอย่างจุดที่ IaC scanner จับ:

• S3 bucket ตั้งเป็น public (เคส Capital One)
• Security group เปิด port 22 ให้ทุก IP (allow 0.0.0.0/0 → ssh)
• EC2 instance ไม่ encrypt EBS volume
• Kubernetes pod รันด้วย root + privileged: true
• Database ไม่ enable backup

เครื่องมือ — Checkov (open-source ของ Bridgecrew/Prisma), Terrascan, tfsec, Snyk IaC, Trivy (สแกนได้ทั้ง container image + IaC)

ข้อดี — เจอ misconfiguration ตั้งแต่ตอน PR (Pull Request) ก่อน merge → ป้องกัน “bucket public ที่ทำให้ข้อมูลหลุด” — ซึ่งเป็นเคสที่เกิดในข่าวสัปดาห์ละครั้งทั่วโลก

มุมผู้บริหาร: ในยุค cloud — 70%+ ของ breach ในข่าว มาจาก misconfiguration ของ infrastructure ไม่ใช่ vulnerability ของแอป (ตามรายงานของ Gartner + Verizon DBIR หลายปีติด). IaC scanning = ลด attack surface นี้ลงตั้งแต่ก่อน deploy. ถ้าทีม cloud ของคุณยัง click button ใน AWS Console เพื่อสร้าง infrastructure (ไม่ใช้ Terraform/CloudFormation) — แปลว่าไม่มีทาง audit ย้อนหลังได้ + ไม่มีทางสแกนได้. ขอให้คุณคุยกับ CTO เรื่อง IaC adoption เป็นโปรเจกต์ใหญ่ของปีนี้

Pattern คลาสสิคที่บริษัทไทยทำซ้ำๆ#

ทีม dev เร่ง deploy. มี API ใหม่ต้องเชื่อมกับ payment gateway. ต้องใช้ secret key. วิธีที่ง่ายที่สุด = เขียนลงในโค้ดตรงๆ:

1
API_KEY = "sk_live_4eC39HqLyjWDarjtT1zdp7dc"
2
DATABASE_PASSWORD = "P@ssw0rd2025!"
3
AWS_SECRET = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

ทำงานได้ครับ. deploy ได้. แอปทำงานปกติ — บนกระดาษ

ปัญหาคือ — โค้ดนี้ commit ขึ้น Git → ขึ้น GitHub (อาจจะ private repo) → ทุกคนในทีม dev เห็นได้ → ถ้ามี contractor มาช่วยก็เห็นได้ → ถ้า repo accidentally เปลี่ยนเป็น public (เกิดบ่อยมาก!) → ทั่วโลกเห็นได้

แม้แต่ delete commit ที่มี secret ใน Git — secret ยังอยู่ใน git history ตลอดไป — ถ้าไม่ rewrite history (ซึ่งยุ่งและทีมส่วนใหญ่ไม่ทำ)

Real case — Codecov ปี 2021#

เคสที่สอนวงการอย่างเจ็บปวดครับ. Codecov = บริการ code coverage report ที่ใช้ใน CI/CD pipeline ของบริษัทหลายพันแห่งทั่วโลก. มี bash uploader script ที่ dev ดาวน์โหลดมารันใน pipeline เพื่อส่งผล coverage กลับ Codecov

มกราคม 2021 — โจรเจาะระบบของ Codecov ได้ → แก้ bash uploader → เพิ่ม code ที่ exfiltrate environment variables กลับไปยัง server โจร

environment variables ใน CI/CD = secret ทั้งหมดของบริษัท — AWS keys, database passwords, API tokens, deploy keys

โจรเก็บ secret ของบริษัทที่ใช้ Codecov 2 เดือนเต็ม ก่อนถูกตรวจพบ. บริษัทใหญ่ที่ออกมายอมรับว่ามีผลกระทบ = HashiCorp (GPG signing key หลุด), Twilio (อีเมลลูกค้าจำนวนหนึ่งหลุด), Rapid7 (source code + customer credential บางส่วนหลุด), Mozilla (rotate credential ทั้งหมด แม้ไม่พบหลักฐานการ exploit). Atlassian ออกแถลงการณ์ภายหลังว่า “ไม่พบหลักฐาน” ของการถูก compromise. ที่น่ากลัวที่สุด — Rapid7 เป็นบริษัท security เอง — ยังโดน

บทเรียน — secret ใน environment variable ของ pipeline = high-value target ระดับชาติ. โจรจะหา supplier ของคุณ (เครื่องมือที่ pipeline คุณใช้) — เพราะเจาะที่นั่นได้ = ได้ลูกค้า 1,000 บริษัทพร้อมกัน

วิธีถูกต้อง — Secrets Manager#

ห้าม hardcode secret ในโค้ดเด็ดขาดครับ. วิธีถูกคือใช้ Secrets Manager:

• HashiCorp Vault — มาตรฐานของวงการ enterprise. รองรับทุก cloud + on-prem
• AWS Secrets Manager — บริการของ AWS. rotate secret อัตโนมัติได้
• Azure Key Vault — ของ Microsoft
• Google Secret Manager — ของ Google Cloud
• Kubernetes Secrets — ของ K8s (พื้นฐาน + ต้องเปิด encryption-at-rest)

Pattern: แอปตอนรันขึ้นมา → ขอ secret จาก Secrets Manager โดยใช้ identity ของ pod/instance → Secrets Manager ตรวจสิทธิ์ → ส่ง secret ในหน่วยความจำ. Secret ไม่อยู่ในโค้ด + ไม่อยู่ใน config file + ไม่อยู่ใน environment variable static

ข้อดีเพิ่ม — rotate ได้ — เปลี่ยน secret ทุก 30 วันโดยไม่ต้อง redeploy แอป

หา secret ที่หลุดไปแล้ว#

ในเคสที่บริษัทคุณอาจมี secret ใน Git อยู่แล้ว — เครื่องมือสแกน:

• git-secrets (โดย AWS Labs) — pre-commit hook ที่ block ไม่ให้ commit secret
• TruffleHog — สแกน Git history หา secret ที่ค้างอยู่
• GitLeaks — open-source, รวมเข้า CI/CD ได้ง่าย
• GitHub Secret Scanning — built-in ของ GitHub (ฟรีสำหรับ public repo, paid สำหรับ private)

ขั้นตอนถ้าเจอ secret หลุด — rotate secret ทันที (สำคัญที่สุด!) → ลบจาก git history (rewrite) → audit log ดูว่ามีคนใช้ secret นั้นไหม → ถ้ามี → incident response

มุมผู้บริหาร: secret หลุดใน Git = อันดับ 1 ของสาเหตุ breach ของบริษัท startup (Verizon DBIR + GitGuardian). ปี 2024 GitGuardian เจอ secret หลุดใน GitHub 23 ล้านครั้ง — ตัวเลขเพิ่มขึ้น 25% ทุกปี. คำถามที่ผู้บริหารต้องถามทีม IT — “เคย scan git history ของเราหา secret ที่หลุดในอดีตหรือยัง?” ถ้าตอบ “ไม่” = technical debt ระดับ catastrophic ที่ต้องแก้ในไตรมาสนี้

SolarWinds 2020 — เคสที่เปลี่ยนวงการ#

ทบทวนเรื่องที่ EP.02 เคยเล่ากันครับ — แต่คราวนี้เจาะลึกในมุม build pipeline

SolarWinds = บริษัทอเมริกัน ทำซอฟต์แวร์ Orion — เครื่องมือ network management ที่ใช้ในบริษัท Fortune 500 + หน่วยงานรัฐบาลสหรัฐ 30,000+ องค์กร (รวม Pentagon, Treasury, State Department, Microsoft, FireEye)

ธันวาคม 2020 — โลกเปิดเผยว่า SolarWinds โดน hack ตั้งแต่ปลายปี 2019 — ไม่ใช่ network ของพวกเขา — แต่เป็น build server

กลไกการโจมตี:

1. โจร (เชื่อว่าเป็น Cozy Bear / APT29 ของรัสเซีย) เจาะเข้า build server ของ SolarWinds
2. แก้โค้ดในขั้น build — ใส่ malicious code (เรียกว่า SUNBURST) ลงในไฟล์ SolarWinds.Orion.Core.BusinessLayer.dll
3. โค้ดที่แก้ → ถูก compile + sign ด้วย certificate ของ SolarWinds เอง → ดูทุกอย่างเหมือนของแท้
4. SolarWinds ส่ง update ที่ติดเชื้อนี้ไปยัง 18,000 ลูกค้า ผ่านระบบ auto-update — ใช้ supply chain ของ SolarWinds เป็นช่องทาง
5. โจรเลือก target สำคัญ (ประมาณ 100 องค์กร) → activate malware → เข้าไปขโมยข้อมูลในเครือข่ายลูกค้า

ความเสียหายประเมินไม่ได้ — Microsoft, FireEye, US Treasury, US Commerce Department, Pentagon, NIH — ล้วนโดน

บทเรียนสำหรับวงการชัดเจนครับ — build pipeline คือ high-value target อันดับ 1 ของ nation-state. ถ้าเจาะได้ = ขโมยอะไรก็ได้จาก ลูกค้าทั้งหมดของคุณ

SBOM — บัตรประจำตัวของซอฟต์แวร์#

หลังเคส SolarWinds — โลกตื่นตัวเรื่องนี้. Executive Order 14028 ของ Biden (พฤษภาคม 2021) บังคับให้ซอฟต์แวร์ที่ขายให้รัฐบาลสหรัฐต้องมี SBOM. EU Cyber Resilience Act (2024) ขยายไปทั่วยุโรป

SBOM = Software Bill of Materials (รายการชิ้นส่วนของซอฟต์แวร์) — ไฟล์ที่ list ทุก component ในซอฟต์แวร์ — library อะไรบ้าง / version อะไร / license อะไร / มี vulnerability อะไรค้างอยู่

เปรียบเหมือน บัตรรายการชิ้นส่วนของรถยนต์ — ระบุทุก part + supplier + serial number — ถ้าวันหนึ่ง part หนึ่งมีปัญหา → recall ได้แม่นยำ

มาตรฐาน SBOM ที่ใช้กันมี 3 ตัวหลักครับ — SPDX (Linux Foundation), CycloneDX (OWASP), SWID Tags (ISO standard)

เครื่องมือสร้าง SBOM — Syft (open-source, ของ Anchore), CycloneDX CLI, Microsoft SBOM Tool

ตัวอย่างของจริง — เมื่อ Log4Shell ระเบิดปี 2021 — บริษัทที่มี SBOM ของแอปทั้งหมด → search หา log4j ใน SBOM ภายใน 5 นาที → เจอครบ → patch ครบ. บริษัทที่ไม่มี SBOM → ใช้เวลา หลายอาทิตย์ สำรวจมือว่าตัวไหนใช้ Log4j

Sigstore + cosign — ลายเซ็นดิจิทัลของซอฟต์แวร์#

แต่ SBOM อย่างเดียวไม่พอ — เพราะ โจรอาจปลอม SBOM ได้. ต้องมีกลไก verify ว่า artifact (ไฟล์ที่ build เสร็จ) มาจากต้นน้ำที่ถูกต้องจริง

Sigstore = open-source project ของ Linux Foundation ที่ทำให้การ sign + verify ซอฟต์แวร์ทำได้ง่าย. ใช้ cosign (command-line tool) ในการ sign + verify

กลไก — ตอน build artifact (container image, binary, package) → sign ด้วย key ที่ผูกกับ identity ของ developer หรือ pipeline → บันทึก signature ลงใน transparency log (Rekor) ที่แก้ไม่ได้ → ใครก็ตามที่ใช้ artifact นี้ → verify ได้ว่ามาจากที่ตั้งไว้จริง + ไม่ถูกแก้ตอนทาง

ถ้า SolarWinds มี Sigstore + ใช้ cosign → ลูกค้าจะ verify ก่อนติดตั้ง update → เจอว่า binary ไม่ตรงกับที่ developer sign → ไม่ติดตั้ง → ป้องกันได้ในหลักการ

SLSA — ระดับความน่าเชื่อถือของ supply chain#

SLSA (ออกเสียง “salsa”) = Supply-chain Levels for Software Artifacts (ระดับชั้นความน่าเชื่อถือของ supply chain ซอฟต์แวร์) — framework ของ Google ที่กำหนด 4 ระดับ ของความเข้มงวด:

• SLSA 1 — มี build process ที่บันทึก provenance (ที่มา) ของ artifact
• SLSA 2 — build บน hosted CI/CD service ที่ verify ได้ (เช่น GitHub Actions)
• SLSA 3 — build environment hardened + ไม่มีใครแก้ build pipeline ได้โดยพลการ
• SLSA 4 — review 2 คนทุก change + reproducible build (build ซ้ำได้ผลเท่าเดิม)

บริษัทใหญ่ (Google, Microsoft) target SLSA Level 3-4 สำหรับ critical software. บริษัททั่วไปเริ่มที่ Level 1-2 ก็ดีแล้ว

มุมผู้บริหาร: Software supply chain security = เรื่องที่ board ทุกบริษัทต้องคุยกันในปี 2026 เป็นต้นไป — เพราะลูกค้า enterprise จะเริ่มถามหา SBOM ในสัญญา + ขายในยุโรป Cyber Resilience Act บังคับใช้แล้ว + cyber insurance ถาม SBOM ในแบบฟอร์มแล้ว. คำถามที่ผู้บริหารต้องถามทีม IT — “สำหรับซอฟต์แวร์ที่ส่งให้ลูกค้า เรา generate SBOM ได้ไหม?” ถ้าตอบไม่ได้ = เริ่ม pilot project ในไตรมาสนี้

ทำไม build pipeline คือเป้าหมาย#

ลองนึกภาพดูครับ — ใน CI/CD pipeline ของบริษัทเราจะมี:

• Source code ทั้งหมดของบริษัท (ผ่าน git clone)
• Secrets ที่ใช้ deploy (AWS keys, database passwords, signing keys)
• Network access ไปยัง production
• Permission ในการ push container image ขึ้น registry
• Permission ในการ apply Terraform → แก้ infrastructure จริง
• Permission ในการ deploy app ขึ้น production

นี่คือ อำนาจสูงที่สุด ในระบบ IT ของบริษัท. ถ้าโจรได้ — โจรเป็น god mode ของระบบเรา. ทำอะไรก็ได้ — ไม่ต้อง bypass firewall, ไม่ต้อง phish admin — เพราะ build pipeline มีสิทธิ์มากกว่า admin ทุกคน

Hardening build environment#

หลักการในการ harden build pipeline มีดังนี้ครับ:

1. Ephemeral build agents — build agent (runner) ที่รัน build → ใช้ครั้งเดียว ทิ้ง — ไม่ใช่ VM ที่ค้างเปิด. ป้องกัน malware persistence. GitHub Actions, GitLab CI default ทำแบบนี้

2. Isolated network — build agent ไม่ต้องเข้า production directly — push artifact ลง registry → ระบบ deploy แยกอ่าน registry ไป deploy

3. Signed commits — บังคับให้ developer sign commit ทุกครั้ง ด้วย GPG key หรือ SSH key — ป้องกันคนปลอมเป็น developer คนอื่น

4. Branch protection — main branch ต้องผ่าน:

• Pull Request review จากคน 2 คน (อย่างน้อย)
• Status check ผ่านครบ (SAST + SCA + IaC scan)
• ไม่อนุญาต force push
• ไม่อนุญาต merge โดยไม่ผ่าน CI

5. Least privilege สำหรับ pipeline — แต่ละ job ขอสิทธิ์ เฉพาะที่ต้องใช้ — job test ไม่ต้องมี deploy permission. job deploy ไม่ต้องเข้า database. ใช้ OIDC (OpenID Connect) แทน long-lived access key

6. Reproducible builds — build เดียวกัน 2 ครั้งต้องได้ binary ที่ byte-for-byte เท่ากัน → verify ได้ว่าไม่มีคนแอบใส่อะไรเข้ามาตอน build

7. Audit log ทุกอย่าง — ใครกดอะไร / ตอนไหน / merge อะไร / deploy อะไร — เก็บใน SIEM อย่างน้อย 1 ปี

PyPI / npm typosquatting — supply chain ผ่าน package registry#

อีก threat ที่เกิดบ่อยครับ — typosquatting ใน package registry

Pattern: โจรอัพโหลด package ที่ชื่อคล้าย package ดัง — เช่น reqeusts (ผิด - ที่ถูก requests), colourama (ผิด - ที่ถูก colorama), python-mysql (ผิด - ที่ถูก mysqlclient). developer พิมพ์ผิด → ติดตั้ง package ของโจร → malware ทำงาน

ใน npm — มีเคส event-stream (2018) — package ดังที่มีคนใช้หลายล้าน. maintainer คนเดิม “ส่งต่อ” สิทธิ์ให้คนแปลกหน้าเพราะไม่อยาก maintain แล้ว. คนแปลกหน้า = โจร → ใส่ malicious code เพื่อขโมย Bitcoin wallet ของแอปชื่อ Copay → กว่าจะรู้คือมีแอปเป็นล้านที่ติด

วิธีป้องกัน:

• ใช้ lockfile เสมอ (package-lock.json, requirements.txt แบบ pin version) — เพื่อให้ตอน build install เวอร์ชันเดิมเสมอ
• ใช้ internal registry mirror สำหรับ enterprise — copy เฉพาะ package ที่ approve ไว้
• SCA tool ที่ detect typosquatting pattern — Snyk, Socket.dev ทำได้
• Code review ทุก dependency update

มุมผู้บริหาร: ถ้าผู้บริหารของคุณคิดว่า “security คือเรื่องของทีม security” — นี่คือ mindset ของยุค 2010. ยุค 2026 — security ถูก embed ใน workflow ของทุกคน — developer ต้องเขียนโค้ด secure, ops ต้อง config infra secure, manager ต้อง approve PR ที่ผ่าน security check. CISO ในยุคนี้ไม่ใช่ตำรวจ — แต่เป็น coach ที่ enable ทีมอื่น. KPI ของบริษัทที่ทำ DevSecOps สำเร็จ — mean time to remediate (MTTR) ของ critical vulnerability < 7 วัน, % of build with security scan = 100%, % of secret in code = 0%. ถ้า KPI พวกนี้ไม่อยู่ใน dashboard ของผู้บริหารคุณ — แปลว่ายังไม่ได้ทำ DevSecOps จริง

ทำไม default install = attack surface เปิดกว้าง#

Linux หรือ Windows ที่ลงเสร็จจาก ISO ครั้งแรก ไม่ได้ออกแบบมาให้ secure ครับ แต่ออกแบบมาให้ ใช้งานง่ายและทดลองได้เร็ว. ผลคือ default config มีปัญหาอยู่หลายข้อ

• Service ที่ไม่จำเป็นเปิดเอาไว้ — telnet, FTP, print server, X11 forwarding เปิดอยู่แม้ไม่มีคนใช้
• Port เปิดเกิน บาง port listen อยู่ทั้งที่ไม่มี firewall block
• Default account — Administrator ใน Windows, root ใน Linux ทุกคนรู้ชื่อ โจรเดารหัสได้ตรงเป้า
• Password policy หลวม ตั้งรหัส 6 ตัวก็ผ่าน
• Audit log ปิดหรือ verbose ต่ำ เกิดอะไรขึ้นก็ไม่รู้
• Kernel parameter default บาง parameter ไม่ได้ tune เพื่อ security

ถ้า server เข้า production ในสภาพ default ผู้ตรวจสอบจะถามทันทีว่า “คุณมี secure baseline ไหม?” ตอบไม่ได้ก็จบ

CIS Benchmark กับ STIG — secure baseline ที่มีชื่อ มีมาตรฐาน#

วงการไม่ได้ให้แต่ละบริษัทคิด baseline เองครับ มี framework กลางที่ใช้กันทั้งโลก

CIS Benchmark ออกโดย Center for Internet Security องค์กรไม่แสวงกำไรของสหรัฐ. แต่ละ benchmark คือไฟล์ checklist หลายร้อยข้อที่บอกว่าต้อง config อะไรยังไง ครอบคลุมตั้งแต่

• OS — Linux (Ubuntu, RHEL, Debian, Amazon Linux), Windows (Server, Desktop), macOS
• Cloud — AWS, Azure, GCP, Oracle Cloud (ระดับ account-wide config)
• Database — MySQL, PostgreSQL, MongoDB, MS SQL, Oracle
• Container + orchestration — Docker, Kubernetes
• Network device — Cisco, Juniper

CIS Benchmark ดาวน์โหลดฟรีเป็น PDF เป็นมาตรฐานที่ commercial product อย่าง Tenable, Qualys, Rapid7 เอามาใช้เป็น scan profile

STIG ย่อจาก Security Technical Implementation Guide เป็น version ของ DISA (Defense Information Systems Agency) ของกระทรวงกลาโหมสหรัฐ. เข้มกว่า CIS แล้วก็ บังคับสำหรับ DoD contractor ใครรับงานทหารสหรัฐต้องผ่าน STIG. ถ้าบริษัทคุณไม่ได้ขายให้กองทัพ ใช้ CIS ก็พอแล้ว

Secure baseline ก็คือ config ขั้นต่ำที่ระบบต้องผ่านก่อน deploy ขึ้น production บริษัทควรเลือก benchmark ที่เหมาะกับ workload แล้วกำหนดเป็น internal standard ให้ทุก server ต้องตาม

Hardening tasks ที่ทุก baseline เน้น#

ไม่ต้องจำทุกข้อใน CIS รู้หมวดใหญ่ก็พอ

• Disable unused services + ports ปิดทุกอย่างที่ไม่ได้ใช้ ถ้าไม่ใช้ FTP ก็ uninstall ทั้ง package ไปเลย
• Rename / disable default account ปิด Administrator กับ root direct login ใช้ named account + sudo แทน
• Password policy + MFA บังคับ ≥12 ตัว + complexity + MFA สำหรับ admin access
• Audit log enabled + forward to SIEM ทุก login ทุก privilege escalation บันทึกแล้วส่งออกนอกเครื่อง (โจรลบ log ในเครื่องไม่ได้)
• Patch management automated ใช้ unattended-upgrades (Ubuntu), WSUS (Windows), dnf-automatic (RHEL) patch security วันที่ออก ไม่ต้องรอคน approve
• Kernel parameter tuning — sysctl บน Linux: ปิด IP forwarding, เปิด ASLR, จำกัด core dump
• Mandatory Access Control เปิด SELinux (RHEL/Fedora) หรือ AppArmor (Ubuntu/Debian) เพิ่มชั้น MAC ทับ DAC ปกติ

Automation — apply + audit ที่ scale ใหญ่#

ทำ hardening ด้วยมือบน 1,000 server เป็นไปไม่ได้ครับ ต้องใช้ tool 2 ฝั่ง

ฝั่ง Apply ตอน provision:

• Ansible / Chef / Puppet เขียน playbook ที่ apply CIS Benchmark แล้ว run บนเครื่องใหม่อัตโนมัติ
• หลายทีมใช้ DevSec Hardening Framework (open-source Ansible role ที่ implement CIS ไว้แล้ว)

ฝั่ง Audit ตรวจของที่มี:

• Lynis open-source Linux audit tool รันแล้วได้คะแนน hardening + list สิ่งที่ต้องแก้
• OpenSCAP เป็น standard ของ NIST + DoD รัน profile ของ CIS หรือ STIG ได้ report XCCDF ที่ใช้ส่งผู้ตรวจสอบได้เลย

มุม IS auditor#

ผู้ตรวจสอบที่เข้าไปประเมิน IT general control จะถาม 3 คำถามใหญ่

1. “บริษัทมี secure baseline document ไหม?” (เลือก CIS Benchmark version ไหน, customize อะไร, อนุมัติเมื่อไหร่)
2. “ทุก server ที่ขึ้น production ผ่าน baseline ไหม แล้ว log การ deviation ยังไง?” (ใครอนุมัติให้ deviate, มี compensating control ไหม)
3. “Audit จริงล่าสุดเมื่อไหร่ แล้ว report อยู่ที่ไหน?” (ขอ OpenSCAP report ของ critical server)

ตอบครบ 3 ข้อ + มี evidence = control นี้ผ่าน. ตอบไม่ได้ข้อใดข้อหนึ่ง = finding

มุมผู้บริหาร: ถ้าทีม IT deploy server แบบ “ลงเสร็จก็ใช้เลย” แปลว่าระบบของคุณ run อยู่บน config ที่ผู้ผลิต OS ไม่ได้ออกแบบมาให้ secure. ข่าวดีคือ CIS Benchmark ดาวน์โหลดฟรี + DevSec Hardening Framework ก็ open-source ใช้ได้เลย. ROI ของ project นี้สูงมากครับ ลด attack surface ได้ 60-70% โดยลงทุนแค่เวลา engineer 2-3 อาทิตย์ในการ setup automation รอบแรก. คำถามที่ผู้บริหารต้องถาม CIO/CISO คือ “บริษัทเรา harden server ตาม CIS Benchmark version ไหน แล้ว audit ครั้งล่าสุดเมื่อไหร่?” ถ้าตอบไม่ได้ในที่ประชุม นี่คือโครงการที่ต้องเริ่มไตรมาสนี้

สิ่งที่ผู้นำต้องจำ#

ข้อแรก — Shift-Left = ลงทุนน้อย ป้องกันได้มาก

ในกราฟค่าใช้จ่ายในการแก้ bug — เลื่อนซ้ายของ pipeline 1 stage = ลดค่าใช้จ่าย 10 เท่า. นี่ไม่ใช่ marketing claim — เป็นข้อมูลของ IBM Systems Sciences Institute + NIST ที่อ้างกันมา 20 ปี

แต่จะเลื่อนซ้ายได้ — ต้อง ใส่ tool ใน pipeline + train ทีม + เปลี่ยน workflow. หลายบริษัทไทยติดที่ “ทีม security ยังถือ veto power ตอนจบ” — แทนที่จะ enable ทีม dev ให้แก้เองตั้งแต่ต้น

โปรเจกต์ ROI สูง 3 ตัวที่บริษัทขนาดกลางควรเริ่มในไตรมาสนี้:

• 1) เปิด Dependabot / Snyk Free ใน repo หลัก — automated SCA ฟรี
• 2) เปิด secret scanning ใน GitHub/GitLab — ป้องกัน secret หลุด
• 3) ตั้ง branch protection + require PR review ใน main branch — ลด human error

3 ข้อนี้ใช้เวลา setup รวม น้อยกว่า 1 อาทิตย์ + ค่าใช้จ่าย $0-500/เดือน — ป้องกัน 70-80% ของ supply chain risk ที่บริษัทขนาดกลางเจอ

ข้อสอง — Build pipeline = อาวุธนิวเคลียร์ ที่ต้องเฝ้าระวังที่สุด

บทเรียนของ SolarWinds + Codecov — โจรยุคใหม่ไม่ได้พยายามเจาะลูกค้าทีละราย — เจาะ supplier ของลูกค้า. ถ้า supplier นั้นมีลูกค้า 30,000 ราย → เจาะครั้งเดียว = ได้ทั้งหมด

สำหรับบริษัทคุณ — ถามตัวเองคำถามนี้: “ถ้าคนภายนอกได้สิทธิ์ในการแก้ build pipeline ของเรา 30 วัน โดยไม่มีใครรู้ — เกิดอะไรขึ้น?”. ถ้าคำตอบคือ “เขาสามารถใส่ malware ลงในซอฟต์แวร์ที่เราส่งให้ลูกค้าได้” — แสดงว่า build pipeline ของคุณคือ เป้าหมายระดับ nation-state

วิธีจัดการ — treat pipeline ด้วยมาตรฐานเดียวกับ production database:

• MFA บังคับสำหรับทุกคนที่เข้าถึง pipeline
• access ผ่าน PAM (EP.17) — มี audit log + session recording
• separation of duty — คน build ≠ คน deploy ≠ คน approve
• regular pen test ของ pipeline itself

ในเคสบริษัทขนาดกลางที่ pipeline ถูก hard — มัก reduce supply chain risk ลงได้ 60-80% โดยไม่ต้องลงทุน tool เพิ่มมาก — แค่จัดระเบียบ workflow ใหม่