Secure Development Lifecycle

ระบบโอนเงินรุ่นใหม่อาจผ่าน dependency scan, ไม่มี secret ใน Git และได้ผล penetration test ว่าไม่พบช่องโหว่ร้ายแรง แต่ยังอนุญาตให้ผู้สร้าง payout batch เป็นผู้อนุมัติ batch เดียวกันได้ เพราะ requirement ไม่เคยระบุ separation of duties และ test plan ตรวจเฉพาะ technical vulnerability

Secure Development Lifecycle หรือ Secure SDLC ทำให้ Security เป็นส่วนหนึ่งของการตัดสินใจ ตั้งแต่ requirement จนถึง incident learning ไม่ใช่ประตูตรวจครั้งเดียวก่อน release

Security ต้องอยู่ตลอด Lifecycle#

การแก้ authorization model ตอน design มักเป็นการแก้ diagram, policy และ acceptance criteria แต่ถ้าพบหลังเปิด production อาจต้องย้ายข้อมูล, เปลี่ยน API contract, revoke session และเยียวยาลูกค้า เป้าหมายของ Secure SDLC จึงไม่ใช่ทำให้ bug เป็นศูนย์ แต่คือ:

• พบ design flaw ก่อนต้นทุนแก้สูง
• ทำให้ secure path เป็นทางที่ engineer ใช้ง่าย
• สร้าง evidence ว่า control สำคัญทำงาน
• จำกัด blast radius เมื่อบาง control พลาด
• เรียนรู้จาก vulnerability และ incident อย่างเป็นระบบ

System map

Security review ที่ดีลดความเสี่ยงตามจุด ไม่ย้าย checklist เดียวไปวางทุกขั้น

ใช้ SSDF เป็นโครง ไม่ใช่รายการ Tool#

NIST Secure Software Development Framework (SSDF) 1.1 จัด practice เป็น 4 กลุ่ม:

SSDF เป็น outcome-oriented framework ไม่ได้บังคับว่า repository ทุกแห่งต้องใช้ scanner ชื่อเดียวกัน การนำไปใช้ควรผนวกกับ delivery process ที่มีอยู่ พร้อมระบุ evidence และ owner

เริ่มจาก Security Requirements#

requirement ที่เขียนเพียง “ใช้ encryption”, “รองรับ MFA” หรือ “ผ่าน OWASP” ยังไม่บอก threat, scope, behavior และวิธีพิสูจน์

ตัวอย่าง requirement ที่ตรวจได้มากกว่า:

REQ-AUTHZ-04
ทุกคำสั่งอนุมัติ payout ต้องตรวจที่ backend ว่า:
- actor มีสิทธิ์ payout:approve ใน tenant และ amount band ปัจจุบัน
- actor ไม่ใช่ผู้สร้างหรือแก้ batch รุ่นที่กำลังอนุมัติ
- batch content hash ตรงกับค่าที่แสดงตอนอนุมัติ
- decision ถูกบันทึกพร้อม actor, batch version, outcome และ correlation ID

Negative tests:
- creator อนุมัติ batch ของตนเองไม่ได้
- approval เดิมใช้ไม่ได้หลัง beneficiary หรือ amount เปลี่ยน
- เปลี่ยน batch ID ใน request แล้วต้องถูกปฏิเสธ

requirement ที่ดีมีอย่างน้อย:

• Actor — human หรือ workload ใด
• Action/resource — ทำอะไรกับสิ่งใด
• Context/invariant — เงื่อนไขใดต้องจริง
• Failure behavior — ปฏิเสธ, queue review หรือ degraded อย่างไร
• Evidence — test, log, metric หรือ review ใดพิสูจน์ผล
• Owner — ใครดูแลและใครรับ residual risk

Abuse Stories#

user story อธิบายสิ่งที่ต้องการ ส่วน abuse story อธิบายการใช้ capability ให้เกิดผลเสีย:

As a compromised operations user,
I want to split a large refund into many small refunds,
so that each request stays below the approval threshold.

acceptance criteria จึงต้องตรวจ aggregate limit, velocity, relationship และ alert ไม่ใช่ ตรวจเพียง amount ต่อ request

ใช้ ASVS เป็น Verification Baseline#

OWASP Application Security Verification Standard (ASVS) เป็น catalog ของ requirement สำหรับ web/application security ที่ละเอียดกว่า OWASP Top 10

แนวทางใช้ที่เหมาะสม:

• เลือก requirement ตาม architecture, data และ risk ไม่คัดทั้งเล่มแบบไม่อ่าน
• บันทึก version เต็มกับ requirement ID เช่น ASVS 5.0.0
• map requirement ไปยัง implementation และ evidence
• เพิ่ม business invariant ที่ ASVS ทั่วไปไม่รู้ เช่น double-entry ledger
• ใช้ gap เป็น backlog/risk decision ไม่ใช้เป็นตรา “ผ่าน Security”

Secure Design ก่อนเขียน Code#

design review ควรเกิดเมื่อทางเลือกยังเปลี่ยนได้ โดยใช้ข้อมูลจากThreat Modeling:

• asset และ data classification
• trust boundary และ privileged flow
• authentication/authorization model
• transaction invariant และ concurrency
• secret/key ownership
• dependency failure และ degraded mode
• logging, detection และ recovery path

สร้าง Security Invariants#

invariant คือสิ่งที่ต้องจริงเสมอ ไม่ว่าระบบจะ retry, timeout หรือรันหลาย instance:

• ledger transaction ต้อง balance
• provider event 1 รายการเปลี่ยนสถานะทางการเงินได้ไม่เกิน 1 ครั้ง
• tenant หนึ่งอ่าน object ของอีก tenant ไม่ได้
• approval ใช้กับข้อมูล transaction version ที่แสดงเท่านั้น
• artifact ที่ deploy ต้องมี digest ตรงกับ artifact ที่ผ่าน verification

invariant ควรถูก enforce ใกล้ state boundary เช่น database constraint/transaction หรือ policy enforcement point ไม่ฝากไว้กับ frontend หรือ convention ของ caller

Secure Coding เป็น Paved Road#

secure coding standard ควรสั้นพอใช้จริงและผูกกับ framework/library ที่มีอยู่:

การเขียนเอกสารว่า “ห้ามทำ X” โดยไม่มีทางเลือกที่ใช้ง่ายทำให้แต่ละทีมสร้าง wrapper เองและ เกิด implementation หลายมาตรฐาน Platform/API ที่เป็น secure default ลดภาระได้มากกว่า การหวังให้ทุกคนจำ checklist

Code Review ต้องมอง Data Flow#

review Security ไม่ใช่ค้นหา function อันตรายเท่านั้น ควรตาม input จนถึง side effect:

1. input มาจาก trust boundary ใด
2. parse/canonicalize/validate ที่ไหน
3. identity และ authorization decision ผูกกับ resource อย่างไร
4. data ไหลเข้า query, template, command, URL, file หรือ log ใด
5. concurrent/retry/failure path รักษา invariant หรือไม่
6. error เปิดเผยข้อมูลหรือเปลี่ยนเป็น allow โดยไม่ตั้งใจหรือไม่
7. test มี negative และ abuse case หรือไม่

Review Privileged Changes More Strictly#

ไฟล์ต่อไปนี้ควรมี owner/reviewer เฉพาะและ branch protection ตามความเสี่ยง:

• authentication และ authorization policy
• cryptography/key configuration
• CI/CD workflow และ build script
• infrastructure/network/IAM policy
• migration ที่เปลี่ยน ledger หรือ audit data
• dependency source/registry และ lockfile

จำนวน approval อย่างเดียวไม่พอถ้า reviewer ทั้งหมดไม่มี context หรือใช้ credential เดียวกัน

เครื่องมือแต่ละชนิดเห็นคนละส่วน#

ไม่มีผล “scanner ผ่าน” ที่แปลว่า secure กิจกรรมเหล่านี้ต้องรวม coverage และ evidence ตาม threat model

Test Negative Paths#

happy-path unit test ไม่พิสูจน์ Security control ตัวอย่าง negative tests:

• user ที่ login แล้วอ่าน resource ของ account อื่น
• token ถูกต้องแต่ audience ผิด
• request เดิมถูกส่งพร้อมกันหลายครั้ง
• approval ถูก replay หลัง transaction เปลี่ยน
• dependency timeout หลังทำ side effect แล้ว
• malformed payload ทำ parser ใช้ memory เกิน limit
• log sink ล่มระหว่าง privileged operation

Dependency และ SBOM#

dependency risk เริ่มก่อน CVE:

• package มาจาก registry/source ที่ตั้งใจหรือไม่
• lockfile pin สิ่งที่ build จริงหรือไม่
• maintainer, release key หรือ account ถูกยึดได้หรือไม่
• install/build script รัน code ด้วย privilege อะไร
• transitive dependency และ container base image ถูก inventory หรือไม่
• update ถูก review/test และ deploy ทันเวลาหรือไม่

Software Bill of Materials (SBOM) บอกว่า artifact ประกอบด้วย component ใด ช่วย inventory, impact analysis และ response แต่ ไม่พิสูจน์ว่า component ปลอดภัย, ไม่ยืนยันว่า SBOM ตรงกับ artifact โดยอัตโนมัติ และไม่แทน provenance/signature

สร้าง CI/CD Gates แบบมีเหตุผล#

pipeline ที่หยุดทุก finding จะถูก bypass ส่วน pipeline ที่เพียงรายงานจะถูกละเลย gate ต้องมี severity, confidence, exploitability, asset context และ exception path

security_gates:
  source:
    - secret_scan
    - targeted_sast
  dependencies:
    - lockfile_policy
    - sca_with_exploitability_triage
  artifact:
    - generate_sbom
    - generate_provenance
    - sign_digest
  deploy:
    - verify_signature_and_provenance
    - require_approved_risk_exceptions

หลักสำคัญคือ deploy ต้อง verify สิ่งที่ build สร้าง การ sign artifact โดยไม่มี verification policy ที่ปลายทางเป็นเพียง metadata เพิ่ม

ออกแบบ Exception Path#

finding บางรายการอาจแก้ไม่ทัน release ที่จำเป็น exception ต้องมี:

• finding และ affected asset ชัดเจน
• evidence ว่า exploitability/impact ถูกประเมินอย่างไร
• compensating control
• risk owner และ approver ที่มีอำนาจ
• expiry date ไม่ใช่ waiver ถาวร
• remediation owner และ verification plan

Vulnerability Management เป็น Lifecycle#

System map

Intake and Validation#

รับ finding จาก scanner, researcher, bug bounty, vendor, incident และ internal report ผ่านช่องทางที่ตอบกลับได้ Validation ต้องทำอย่างปลอดภัยและไม่ปิด finding เพียงเพราะ scanner reproduce ไม่ได้ใน environment หนึ่ง

Risk Triage#

CVSS หรือ vendor severity เป็น input ไม่ใช่คำตัดสินสุดท้าย ให้พิจารณา:

• asset และ data ที่เข้าถึงได้
• exposure และ precondition
• code path ใช้งานจริงหรือไม่
• exploit มีอยู่หรือกำลังถูกใช้หรือไม่
• privilege และ blast radius
• detection/recovery capability
• business impact ของการแก้และไม่แก้

Remediation and Verification#

การปิด ticket ต้องมีหลักฐานว่า root cause ถูกแก้, regression test ผ่าน, artifact ใหม่ถูก deploy ครบ scope และ temporary mitigation ถูกถอดเมื่อไม่จำเป็น ถ้า bug class เดียวกันกระจายหลาย service ควรสร้าง shared control หรือ query หา variant ไม่ใช่แก้ instance เดียว

Release อย่างพิสูจน์ย้อนกลับได้#

release ที่น่าเชื่อถือต้องตอบได้ว่า:

• source commit ใดและใคร review
• build รันบน environment ใดด้วย dependency ใด
• artifact digest ใดผ่าน test/scan
• provenance/signature มาจาก identity ใด
• deployment verify policy อะไร
• ใครอนุมัติ exception และหมดอายุเมื่อใด

production credential ควรออกเมื่อ deploy ด้วย workload federation/short-lived identity ไม่เก็บ long-lived cloud key ใน CI secret ถาวร และ build job ไม่ควรมีสิทธิ์แก้ audit evidence ของตนเอง

Operate, Detect, Learn#

Secure SDLC ไม่จบเมื่อ deploy:

• เก็บ security event ที่ตอบคำถาม actor/action/resource/outcome ได้โดยไม่เก็บ secret
• monitor control health เช่น authorization deny, signature failure และ audit delivery
• rotate credential/key และทดสอบ recovery
• patch dependency และ base image ตาม risk
• ทำ incident exercise และเก็บ lesson เป็น requirement/test ใหม่

post-incident action ที่มีเพียง “อบรมให้ระวังขึ้น” มักไม่แก้ system condition ควรถามว่า secure default, isolation, review, detection หรือ recovery ใดทำให้ความผิดพลาดชนิดเดิมเกิดยากขึ้น

Metrics ที่ไม่สร้างแรงจูงใจผิด#

ตัวเลข “จำนวน vulnerability ที่พบ” อาจเพิ่มเมื่อ coverage ดีขึ้น ไม่ได้แปลว่า Security แย่ลง ควรดูชุดสัญญาณร่วมกัน:

• เวลาจาก disclosure ถึง triage/mitigation/remediation ตาม risk
• อายุของ exception และจำนวนที่หมดอายุ
• critical flow ที่มี threat model และ negative tests
• release ที่ verify provenance/signature จริง
• recurring vulnerability class
• detection/control failure ที่พบจาก exercise หรือ incident
• dependency inventory และ patch coverage ของ artifact ที่กำลังรัน

metric ต้องใช้เพื่อปรับระบบ ไม่ใช้ลงโทษทีมจน finding ถูกซ่อน

Review Checklist#

• Security requirement มี actor, action, resource, context, failure และ evidence
• threat model เกิดก่อน design lock และอัปเดตเมื่อ boundary เปลี่ยน
• business/security invariant ถูก enforce ใกล้ state boundary
• secure coding มี paved road ที่ง่ายกว่า ad-hoc implementation
• code review ตาม data flow, authorization, failure และ concurrency
• SAST/DAST/SCA/fuzz/pentest ถูกเลือกตามสิ่งที่แต่ละวิธีเห็นได้
• negative tests ครอบคลุม cross-user, replay, race และ dependency failure
• SBOM ผูกกับ artifact digest และไม่ถูกใช้เป็นคำรับรองความปลอดภัย
• pipeline สร้างและ deploy ฝั่งปลายทาง verify provenance/signature
• vulnerability lifecycle มี owner, SLA, verification และ time-bound exception
• production telemetry และ incident learning กลับไปแก้ requirement/control/test

Further Reading#

• NIST SP 800-218 — Secure Software Development Framework
• OWASP ASVS
• CISA SBOM
• OWASP Vulnerability Management Guide