Volume 12 · Security & Authentication
Volume 3-10 บันทึก security finding ของแต่ละ repo แยกกันในบทของตัวเอง (ปกติเป็นบทสุดท้ายชื่อ *scorecard*.md) — Volume นี้ทำ 2 อย่างที่ไม่มี volume ใดทำ: (1) รวบรวม ทุก Critical finding เข้าตารางเดียวเพื่อดู severity สูงสุดของทั้งแพลตฟอร์มพร้อมกัน (2) วิเคราะห์ auth mechanism และ trust boundary ในระดับ cross-service ที่การอ่านทีละ repo มองไม่เห็น
Volume นี้ไม่ทำ security audit ใหม่ — ทุก finding อ้างอิงกลับไปที่ scorecard ต้นทางใน Volume 3-9 ยกเว้นจุดที่ต้อง cross-check ข้าม repo (เช่น "secret เดียวกันใช้ที่ไหนบ้าง") ซึ่งจะ cite เพิ่มเมื่อ verify เอง
โครงสร้าง Volume 12
Volume 12 · Security & Authentication
├── 12.1 Auth mechanisms inventory ทุก mechanism ที่พบ ข้าม 25 repo
├── 12.2 Shared trust boundaries secret/apiKey/JWT ที่ blur boundary ข้าม service
├── 12.3 Critical findings summary ตาราง Critical (SEC-/CRIT-) ทุกตัวจาก Volume 3-10
├── 12.4 Scorecard meta-pattern เชิงระบบ (ไม่ซ้ำ finding รายตัว)
└── 12.5 Critical addendum (Deep Redo) finding ใหม่หลัง V1-depth scorecard redoทำไมต้องมี Volume แยก
อ่าน scorecard ของ benefit-api อย่างเดียวจะไม่รู้ว่า secret ที่หลุดตัวเดียวกันอยู่ใน .env ของ recruitment-api, ai-recruitment-api, pms-api, และ (ตามที่พบใหม่ใน Volume 11) แม้แต่ vtrc-api ด้วย — ถ้า incident response team เห็นแค่ scorecard เดียว จะประเมิน blast radius ผิดทันที
Volume นี้จึงมีหน้าที่เดียว — เป็น "single pane of glass" สำหรับถามคำถามระดับ CISO เช่น "ทั้งแพลตฟอร์มมี Critical finding กี่ตัว", "ระบบใช้ auth mechanism กี่แบบ", "ถ้า secret ตัวหนึ่งรั่ว อะไรพังพร้อมกัน" — คำถามหลังอยู่ที่ Volume 11.4 ซึ่งเป็นบทคู่กันของ Volume นี้ (Volume 11 = data-model lens, Volume 12 = auth/security lens ของ evidence เดียวกัน)
สรุปข้อค้นพบหลัก (executive summary)
- 48 Critical-severity security finding ยืนยันแล้วจากการอ่าน scorecard ทั้ง 27 ไฟล์ใน Volume 3-9 — กระจายอยู่ใน 21 repo จาก 25 repo ที่มี backend/frontend code จริง (ไม่นับ placeholder repo ที่ยังไม่มีโค้ด) ดูรายละเอียดที่ 12.3
- Pattern ที่ซ้ำมากที่สุดคือ ".env production commit เข้า git" — พบใน ≥ 15 repo เป็น root cause ของ Critical finding อย่างน้อย 20 ตัวจาก 48 ตัว
- JWT/apiKey trust ไม่มี central verification — ทุก service verify JWT ด้วย secret ของตัวเอง (บางกลุ่มแชร์กัน) ไม่มี JWKS/central auth service ที่ signature-verify แบบ rotate ได้ ดู 12.1
- Backdoor/bypass credential ที่ hardcode ในซอร์สพบ ≥ 4 จุด ใน
2way-api,2way-vtrc-api,cu-central-api(และcentralize-api's ที่@Public()ทุก route เท่ากับ bypass ทั้งระบบ) — ดู 12.2 - ไม่มี repo ใดใช้ secret manager (Vault/AWS Secrets Manager/k8s Secret) — ทุก secret อยู่ใน
.envแบบ plaintext ทั้งแพลตฟอร์ม
Evidence source
Volume นี้สังเคราะห์จาก ทุกไฟล์ *scorecard*.md/*-debt.md ของ Volume 3-9 (27 ไฟล์ทั้งหมด):
- Volume 3:
vtrc-api/10-scorecard.md,cu-central-api/04-integrations-scorecard.md,centralize-api/03-auth-crosscutting-debt.md - Volume 4:
vtrc-backoffice/04-scorecard.md,vtrc-backoffice-new/04-scorecard.md,vtrc-rc-backoffice/03-state-security-scorecard.md,vtrc-web/03-state-security-scorecard.md - Volume 5:
2way-api/04-scorecard.md,2way-batch/02-scorecard.md,2way-line-service/02-scorecard.md,2way-meeting-backoffice/04-scorecard.md,2way-vtrc-api/04-scorecard.md - Volume 6:
benefit-api/06-scorecard.md,recruitment-api/06-scorecard.md,ai-recruitment-api/06-scorecard.md,pms-api/06-scorecard.md,chat-center-api/04-scorecard.md,job-scheduler-api/04-scorecard.md,sso-api/04-scorecard.md,vtrc-common/04-scorecard.md,workflow-api/04-scorecard.md - Volume 7:
meeting-backoffice-new/04-scorecard.md,meeting-backoffice/04-scorecard.md,meeting-vtrc-api/04-scorecard.md - Volume 8:
new-vtrc-mobile/02-scorecard.md,vtrc-application-front/02-scorecard.md,vtrc-mobile/04-scorecard.md - Volume 9:
recruitment-web/03-scorecard.md,report-log/03-scorecard.md,vtrc-ocr-api/03-scorecard.md
ร่วมกับบท auth-specific ที่เขียนไว้ก่อนหน้า: vtrc-api/03-auth-session.md, cu-central-api/02-auth-ldap-directive.md, centralize-api/02-rest-service-entities.md, และทุกไฟล์ */04-auth-integrations.md ของ Volume 6
- 12.5 Critical addendum — Deep Redo — backdoor/secrets/SQLi clusters หลัง deep scorecard
ไปเริ่มที่ 12.1 Auth mechanisms inventory →