Dependency-Track UAT — Baseline และแผนลดช่องโหว่ 09/09/2026

เอกสารนี้เป็น planning baseline จาก Dependency-Track UAT ณ วันที่ 9 กันยายน 2026 ไม่ใช่ข้อสรุปว่า finding ทุกตัว exploit ได้จริง และไม่ใช่หลักฐานว่า production ได้รับผลกระทบ

ข้อสรุปสำหรับการตัดสินใจ

UAT มี 845 findings ใน 36 projects โดยยังไม่มี finding ใดผ่านการ audit ใน Dependency-Track และมี Critical 16 + High 396 = 412 findings (48.8%) ที่ต้องจัดลำดับก่อน

งานไม่ได้กระจายเท่ากันทั้งระบบ:

• Frontend 3 projects มี 694 findings หรือ 82.1% ของทั้งหมด และถือ Critical 11 จาก 16
• Backend services 21 projects มี 79 findings รวม Critical 5
• backend-package ถูกเก็บเป็น active 12 versions ทำให้มี findings ซ้ำเชิง portfolio 72 รายการ
• 8 projects ไม่มี finding แต่ 2 รายการในกลุ่มนี้ยังนับเป็นหลักฐาน clean ไม่ได้: superapp-user-service ไม่เคย import SBOM และ fx-report-service-uat มี metrics เป็น 0 components

ข้อเสนอคือทำเป็น 3 workstreams คู่ขนาน: กำจัด Critical, ยก dependency ชุดกลางเพื่อลด High เป็นกลุ่ม และ แก้ hygiene ของ Dependency-Track เพื่อให้ตัวเลขรอบถัดไปใช้บริหารงานได้จริง

Snapshot ที่ใช้เป็น baseline

ข้อมูลมาจาก metrics และความสัมพันธ์ component-vulnerability ในฐานข้อมูลของ instance ที่เปิดผ่าน http://localhost:8081 โดยใช้ read-only query สำหรับการทำรายงาน ไม่มี credential หรือ secret ถูกบันทึกในเอกสารนี้

จุดที่ต้องแก้ก่อน: Critical 16

Critical 16 รายการรวมกันเป็น dependency clusters ที่แก้เป็นชุดได้ ตารางด้านล่างใช้จำนวน finding หลังรวม alias ของ vulnerability เดียวกันแล้ว

ข้อสังเกตจาก dependency path จริง

• shell-quote, tar และ websocket-driver อยู่ใน frontend build/dev toolchain ไม่ใช่ direct runtime dependency
• vitest เป็น direct dependency เฉพาะ SuperApp Library UI จึงแยก PR ได้ทันที
• handlebars ของ Host และ Admin ใน local lockfile เป็น 4.7.9 แล้ว แต่ UAT finding Critical เหลือที่ Library UI ซึ่งยังเป็น 4.7.8
• Microsoft.AspNetCore.DataProtection.StackExchangeRedis 10.0.0 เป็น direct package ของ Sentinel Gateway และ User Service
• System.Security.Cryptography.Xml เป็น transitive package จึงควรยกจาก parent dependency หรือ .NET servicing line ไม่ควร pin แบบโดดเดี่ยวโดยไม่ตรวจ dependency graph
• Dependency-Track ให้ CVE-2026-47304 เป็น Critical 9.8 ขณะที่ GitHub advisory จัดเป็น High จึงต้องบันทึกการตัดสิน severity หลัง triage

ลำดับโครงการตามความเสี่ยง

โครงการที่ metrics เป็นศูนย์คือ fxcodex-service-uat, fxcontract-service-uat, fxfile-service-uat, fxorchestrator-service-uat, fxrate-service-uat, fx-report-service-uat, superapp-user-service และ thirdpartyfx-service-uat

High findings ที่ควรแก้เป็นชุด

หลังปิด Critical ให้รวม ticket ตาม dependency family แทนการเปิดหนึ่ง ticket ต่อ CVE:

แผนดำเนินงาน

Wave 0 — ทำ baseline ให้เชื่อถือได้

Owner แนะนำ: Platform + Security

1. ยืนยันว่า port-forward นี้ชี้ UAT instance ที่ต้องการจริง
2. กำหนด naming เป็น {service}-{environment} และ version เป็น release/commit ที่ trace กลับ pipeline ได้
3. Mark รุ่นปัจจุบันเป็น latest และ deactivate/archive backend-package รุ่นเก่า โดยเก็บ 10.31.0 เป็น candidate ปัจจุบันจนกว่า owner จะยืนยัน
4. แก้ backend-package ที่ไม่มี version และ import SBOM ของ superapp-user-service
5. ตรวจ fx-report-service-uat ว่า SBOM มี 0 components จริงหรือ import ผิด
6. แยก tag อย่างน้อย environment:uat, type:frontend|backend|package, owner:<team>

เกณฑ์ผ่าน: active portfolio สะท้อนเฉพาะ scope ที่ทีมตั้งใจบริหาร, ทุก project ระบุ version/owner และ projects ที่อ้างว่า clean ต้องมี SBOM ล่าสุดจริง

Wave 1 — ปิด Critical

Owner แนะนำ: Frontend Platform, Sentinel Gateway, User Service, Workflow Service

1. เปิด ticket ตาม 7 dependency clusters ในตาราง Critical
2. Frontend แก้ direct dependency ก่อน (vitest) แล้วค่อยยก parent toolchain/override สำหรับ transitive dependencies
3. Backend ยก .NET servicing line และ Data Protection package โดยทดสอบ backward compatibility ของ key material
4. Build, unit/integration test และ security smoke test ให้ผ่าน
5. สร้าง SBOM ใหม่จาก commit ที่แก้แล้ว อัปโหลดเข้า project/version ที่ถูกต้อง และรอ vulnerability analysis จบ
6. เปรียบเทียบกับ baseline นี้และ audit alias/false positive ใน Dependency-Track พร้อมเหตุผลและหลักฐาน

เกณฑ์ผ่าน: Critical = 0 ใน official project metrics, ไม่มี finding ถูก suppress เพื่อให้ตัวเลขสวยโดยไม่มีหลักฐาน และ UAT smoke test ผ่าน

Wave 2 — ลด High แบบ shared upgrade

Owner แนะนำ: Frontend Platform + Backend Package maintainers

1. Frontend ทั้ง 3 workspaces ยก Angular/Nx/tooling ให้อยู่ใน compatible line เดียวกัน
2. Backend สร้าง shared upgrade set สำหรับ caching, OpenAPI, OpenTelemetry และ SQLite native package
3. backend-package แก้เฉพาะ current version ก่อน แล้วให้ consumer services ยก package ตามลำดับ
4. หลังแต่ละ batch ให้ rescan ก่อนเปิด batch ถัดไป เพื่อวัดว่า shared upgrade ปิด findings ได้กี่รายการจริง

เป้าหมายชั่วคราว: ลด High จาก 396 ให้ต่ำกว่า 100 ภายในรอบแรก เป้าหมายนี้ต้องปรับอีกครั้งหลัง Wave 0 เพราะ portfolio ปัจจุบันรวม package versions เก่า

Wave 3 — Triage Medium/Low และ policy violations

Owner แนะนำ: Security + service owners

• Audit findings ที่เหลือเป็น Exploitable, In Triage, Not Affected หรือ Resolved พร้อม evidence
• แยก runtime dependencies ออกจาก build/dev dependencies แต่ยังคงติดตาม supply-chain risk ของ CI tooling
• Review policy violations 1,181 รายการ โดยเริ่มจาก Fail 481 และปรับ policy ที่สร้าง noise ก่อนใช้เป็น release gate
• ตั้ง SLA: Critical 48 ชั่วโมง, High 1 sprint, Medium 30 วัน, Low ตาม maintenance window
• ทำ weekly snapshot โดยเก็บ trend: new, resolved, reopened, suppressed และ overdue แทนการดูยอดรวมอย่างเดียว

Definition of Done ต่อ remediation ticket

• ระบุ project, component, advisory, current version, dependency path และ target version/range
• ถ้าเป็น transitive dependency ต้องระบุ parent package ที่จะแก้ ห้ามแก้ lockfile อย่างเดียวโดยไม่มี manifest/override ที่ทำซ้ำได้
• Restore แบบ frozen lockfile ผ่าน และไม่มี unexpected dependency drift
• Build, unit test, integration test และ smoke test ที่เกี่ยวข้องผ่าน
• สร้าง SBOM ใหม่จาก commit เดียวกับ artifact ที่ deploy UAT
• Dependency-Track analysis เสร็จ และ finding เดิมหายหรือถูก triage พร้อม evidence
• Ticket บันทึก before/after metrics และ link ไปยัง SBOM/project version

ประเด็นที่ต้องตัดสินใจใน review

1. ยืนยันว่า instance นี้คือ UAT แม้ชื่อ Kubernetes context เป็น aks-SupperApp-dev
2. จะนับ dev/build dependencies เป็น release blocker ระดับเดียวกับ runtime dependency หรือใช้ SLA แยกกัน
3. backend-package รุ่นใดคือ current และต้องเก็บ historical versions กี่รุ่นใน active portfolio
4. ใครเป็น owner ของ Frontend Platform upgrade และ Backend shared dependency upgrade
5. ยอมรับเป้าหมาย Wave 1 ว่า Critical ต้องเป็นศูนย์ก่อน UAT sign-off หรือไม่
6. จะเปิด policy Fail 481 เป็น release gate ตั้งแต่รอบนี้ หรือ clean policy noise ก่อนหนึ่งรอบ

Snapshot สำหรับเทียบรอบถัดไป