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 เดือนเต็ม ก่อนถูกตรวจพบ. บริษัทที่ใช้ Codecov ในตอนนั้น = Atlassian, HashiCorp, Confluent, Twilio, Rapid7, Mozilla — รายชื่อทั้งหมดน่ากลัวมาก. Rapid7 (บริษัท security เอง!) ต้องประกาศว่า source code บางส่วนหลุด

บทเรียน — 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 จริง

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

ข้อแรก — 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 ใหม่