CISSP Domain 8: Software Development Security

Domain 8 ว่าด้วยการลด software risk ตลอดวงจรชีวิต ตั้งแต่การตัดสินใจสร้างหรือซื้อ การกำหนด requirement การออกแบบ การเขียนและทดสอบ code การ build และ deploy ไปจนถึง การแก้ vulnerability และเลิกใช้ระบบ Security จึงไม่ใช่กิจกรรมที่เพิ่มก่อนขึ้น production แต่เป็นคุณสมบัติของ product, development ecosystem และกระบวนการตัดสินใจทั้งหมด

หลักคิดสำหรับข้อสอบ: เริ่มจาก business/security requirement และ risk แล้วฝัง control ใน Software Development Life Cycle (SDLC) ให้เร็วที่สุด พร้อมเก็บ evidence ในทุก gate เครื่องมืออัตโนมัติช่วยเพิ่ม coverage แต่ไม่พิสูจน์ว่า software ปลอด defect และการ release สำเร็จไม่เท่ากับ security validation หรือการอนุมัติ residual risk

1. ภาพรวม Domain และน้ำหนักข้อสอบ

ตาม CISSP Certification Exam Outline ของ ISC2 ซึ่งมีผลตั้งแต่ 15 เมษายน 2024 Domain 8 มีน้ำหนักเฉลี่ย 10% ของข้อสอบ เนื้อหา ทางการแบ่งเป็นการผสาน security ใน SDLC, การใช้ control ใน software development ecosystem, การประเมินประสิทธิผลของ software security, การประเมิน software ที่จัดหา จากภายนอก และการกำหนด secure coding guideline/standard รวมถึง API security

คำว่า “น้ำหนักเฉลี่ย” ใช้จัดสรรเวลาอ่าน ไม่รับประกันจำนวนข้อในข้อสอบแต่ละชุด โจทย์ มักให้สถานการณ์ที่ทีมต้องส่ง feature เร็ว พบ vulnerability ก่อน release หรือจะใช้ component ภายนอก แล้วถามสิ่งที่ควรทำ FIRST, BEST หรือ MOST effective คำตอบที่เลือก scanner หรือ patch ทันทีอาจผิด หากยังไม่ทราบ requirement, data flow, business impact, owner, affected version หรือ authority สำหรับรับ risk

ความสามารถหลักประกอบด้วย

ผสาน security ใน SDLC ตั้งแต่ planning, requirements, design, implementation, verification, release, operation/maintenance จนถึง retirement
ออกแบบและเขียน software อย่างปลอดภัย ใช้ threat modeling, least privilege, secure defaults, input validation, output encoding, parameterized query, error handling, secret management และ cryptographic API ที่ได้รับการยอมรับ
ปกป้อง development ecosystem ครอบคลุม developer endpoint, Integrated Development Environment (IDE), repository, dependency, CI/CD runner, build system, artifact registry, deployment credential และ production interface
สร้าง assurance evidence จาก peer review, unit/integration/security test, Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), Software Composition Analysis (SCA), fuzzing, penetration test และ regression test
จัดการ software supply chain ทั้ง Commercial-Off-The-Shelf (COTS), open source, third-party library, outsourced development, managed service และ cloud
ควบคุม change และ release ให้ version, approval, artifact, configuration, migration, deployment, verification และ rollback/forward-fix trace กลับได้
นำ production feedback กลับสู่ development แปลง incident, vulnerability, near miss และ operational finding เป็น requirement, defect และ regression test

Domain 8 รับ governance และ risk authority จาก Domain 1; รับ classification, retention และ test-data requirement จาก Domain 2; ใช้ architecture, trust boundary และ cryptography จาก Domain 3; พึ่ง secure channel และ segmentation จาก Domain 4; ใช้ Identity, AuthN และ AuthZ จาก Domain 5; สร้าง test evidence ร่วมกับ Domain 6; และนำ incident, patch, change และ recovery lessons จาก Domain 7 กลับมาป้องกันการเกิดซ้ำ

2. แนวคิดหลักพร้อมคำอธิบาย

2.1 Security ต้องอยู่ตลอด SDLC

การพบ defect ตอน requirements หรือ design มักแก้ได้ก่อน code และ dependency จำนวนมาก ผูกกับ design นั้น หลัก shift left จึงหมายถึงทำ security activity ให้เร็วขึ้น เช่น security requirement, misuse case, threat model และ design review แต่ไม่ควรตีความว่า ย้ายทุก control ไปทางซ้ายแล้วเลิก monitoring ใน production

หลัก shift right เติม runtime validation, telemetry, canary deployment, attack simulation และ incident feedback เพื่อเรียนรู้พฤติกรรมจริง ทั้งสองด้านต้องเชื่อมกัน ผล production ต้องกลับไปเปลี่ยน requirement, code, test และ deployment template ไม่ใช่จบที่ ticket ของ operations

2.2 SDLC model ไม่ได้ทำให้ปลอดภัยโดยอัตโนมัติ

Waterfall แบ่ง phase และ gate ชัด แต่ defect อาจถูกพบช้าหาก security review รอท้ายโครงการ Agile ส่งมอบเป็น increment สั้นและรับ feedback เร็ว แต่ backlog ที่ไม่มี security acceptance criteria อาจสะสม debt ได้ DevOps เชื่อม development กับ operations และ automation แต่ pipeline ที่เร็วสามารถส่ง defect หรือ compromised artifact ได้เร็วขึ้น

DevSecOps คือการฝัง security responsibility, control และ feedback ในวิธีทำงานนั้น ไม่ใช่ชื่อทีมใหม่หรือการเพิ่ม scanner หนึ่งตัว Model ใดก็ปลอดภัยได้เมื่อ requirement, role, gate, evidence และ risk decision ถูกออกแบบให้เหมาะกับ cadence และ criticality

2.3 Requirement มาก่อน control และ test

Security requirement ที่ดีต้อง trace กลับ business objective, data classification, law/contract, threat และ architecture เช่น “เฉพาะเจ้าของ invoice และผู้ตรวจสอบที่ได้รับ มอบหมายจึงอ่าน invoice ได้” พร้อม acceptance criteria ที่ทดสอบได้ ข้อความว่า “ระบบต้อง ปลอดภัย” ไม่ระบุ expected result จึงใช้ design หรือ test ไม่ได้

Functional use case บอกว่าผู้ใช้ต้องทำอะไร ส่วน abuse/misuse case บอกว่าผู้โจมตี หรือผู้ใช้ผิดสิทธิอาจพยายามทำอะไร Threat modeling ใช้ data flow, asset, trust boundary, entry point และ attacker capability เพื่อหา threat แล้วเลือก mitigation การใช้ STRIDE ช่วยถามเรื่อง Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service และ Elevation of Privilege แต่ checklist ไม่แทนความเข้าใจ business logic

2.4 Software quality, security และ assurance เกี่ยวข้องแต่ไม่เท่ากัน

Quality เน้นว่า software ทำงานตาม requirement อย่างสม่ำเสมอ Security เน้นป้องกันและ ตอบสนองการกระทำที่ไม่พึงประสงค์ภายใต้ threat ส่วน assurance คือหลักฐานที่สร้างความ เชื่อมั่นว่า control ถูกออกแบบและทำงานตามที่อ้าง Code ที่ไม่มี functional bug ใน test ปกติยังอาจมี authorization bypass และ code ที่ผ่าน scanner ยังอาจมี business logic flaw

ใช้คำจาก Domain 3 ให้สอดคล้องกัน: verification ตรวจว่าผลงานตรง specification และ validation ตรวจว่าตอบ stakeholder needs/use case การ test เป็นแหล่ง evidence หนึ่ง แต่ coverage, tool rule และ environment มีขอบเขต จึงไม่ควรสรุปว่า “ไม่พบ finding” เท่ากับ “ไม่มี vulnerability”

2.5 People, process และ technology ต้องเสริมกัน

Developer ต้องเข้าใจ secure coding ของภาษาและ framework Product/System/Data owner กำหนด requirement และ priority Security ให้ pattern, review และ risk advice QA สร้าง negative/abuse test Operations ให้ production constraint และ telemetry ส่วนผู้มี delegated authority ตัดสิน residual risk

Separation of Duties (SoD) ลดโอกาสที่คนเดียวเขียน อนุมัติ build และ deploy change สำคัญ โดยไม่มีการตรวจ หากทีมเล็กแยกคนไม่ได้ทุกขั้น ให้ใช้ compensating control เช่น protected branch, peer approval, immutable audit trail, time-bound deployment privilege และ post-deployment review ตาม risk Automation ทำให้ control สม่ำเสมอ แต่ service identity ของ automation ก็ต้องมี owner และ least privilege

2.6 Build, buy และ reuse เปลี่ยนผู้ควบคุม แต่ไม่ย้าย accountability

การซื้อ COTS, ใช้ open source หรือสมัคร Software as a Service (SaaS) ลดงานบางส่วน แต่ไม่ยกเลิกหน้าที่ประเมิน fitness, integration, data handling, vulnerability response, support lifetime และ exit strategy Open source เปิดให้ตรวจ source ได้แต่ไม่ได้รับประกัน ว่าจะมีผู้ตรวจ ส่วน proprietary software มี vendor support ได้แต่ผู้ซื้ออาจเห็นภายในน้อย

การตัดสินใจต้องเทียบ requirement, risk, total lifecycle cost, supplier capability, contract, evidence และทางเลือกเมื่อ provider หยุดบริการ Source-code escrow อาจช่วยให้ เข้าถึง source ตามเงื่อนไข แต่ไม่รับประกันว่าจะ build ได้ มี dependency ครบ หรือปลอดภัย

3. เจาะลึกหัวข้อย่อยพร้อมตัวอย่าง

3.1 Secure SDLC ตั้งแต่เริ่มจนเลิกใช้

ชื่อ phase ต่างกันตามองค์กร แต่ security outcome ควรครอบคลุมดังนี้

ภาพนี้เน้น Secure SDLC ที่นำหลักฐานและบทเรียนจาก production ย้อนกลับไปแก้ต้นเหตุ

flowchart LR REQ["Requirement และ abuse / misuse case"] --> DESIGN["Design และ threat modeling"] DESIGN --> BUILD["Implementation และ controlled build"] BUILD --> VERIFY["Verification และ security gate"] VERIFY --> RELEASE["Release และ deployment"] RELEASE --> PROD["Production operation และ monitoring"] PROD --> FEEDBACK["Telemetry / incident / vulnerability"] FEEDBACK --> ROOT["Root-cause analysis"] ROOT --> REQ ROOT --> REGTEST["Regression test และ pipeline rule"] REGTEST --> VERIFY PROD --> RETIRE["Retirement และ disposal"]

Initiation และ planning ระบุ sponsor, owner, purpose, criticality, data class, legal/contract obligation, delivery model, supplier, budget, skill และ risk criteria พร้อมกำหนดว่า evidence ใดต้องมีเพื่ออนุมัติโครงการ
Requirements เขียน functional, security, privacy, logging, resilience, recovery, support และ disposal requirements ให้ trace และทดสอบได้ รวม abuse/misuse case
Design ทำ architecture/data-flow review, threat modeling, trust-boundary analysis, attack-surface reduction, control selection และ design decision record
Implementation ใช้ approved language/framework/library, secure coding standard, peer review, unit test, secret scanning และ reproducible/controlled build เท่าที่เหมาะ
Verification และ acceptance ทดสอบ positive/negative path, AuthZ, interface, dependency, configuration, performance/resource limit, failure mode และ remediation พร้อม trace finding ถึง requirement และ owner
Release และ deployment ระบุ version, content, approval, artifact digest/signature, provenance, configuration, migration, deployment identity, rollback/forward-fix plan, monitoring และ exit criteria
Operation และ maintenance รับ vulnerability report, monitor dependency/EOL, patch, rotate secret/certificate, review log, respond incident และวัด control outcome
Retirement หยุด traffic และ integration, revoke account/key/token, archive record, migrate/export data, sanitize media, terminate license/contract และ update inventory

แต่ละ gate ควรถามว่า requirement ครบหรือไม่, risk เปลี่ยนหรือไม่, finding ถูกแก้หรือมี exception ที่มี owner/expiry หรือไม่ และ evidence เพียงพอต่อ authority หรือไม่ Gate ไม่จำเป็นต้องเป็นการประชุมใหญ่ทุกครั้ง งาน low risk อาจใช้ policy-as-code และ approval อัตโนมัติ ส่วนระบบ critical ต้องเพิ่ม independent review ตามผลกระทบ

ตัวอย่าง: ระบบจ่ายเงินเพิ่ม endpoint คืนเงิน ใน requirements ต้องกำหนดว่าใครเริ่มและ อนุมัติวงเงินใด Design ต้องป้องกัน replay และ race condition Implementation ต้องทำ transaction แบบ atomic Test ต้องยิงคำขอซ้ำและพร้อมกัน Release ต้อง monitor duplicate refund หากพบ incident ต้องเพิ่ม regression test ไม่ใช่เพียงคืนเงินให้ลูกค้า

3.2 Agile, DevOps, DevSecOps และ maturity

ใน Agile ให้ใส่ security requirement ใน product backlog, Definition of Ready และ Definition of Done ตามบริบท Threat model อาจอัปเดตทีละ increment เมื่อ data flow หรือ trust boundary เปลี่ยน Security champion ช่วยทีมใช้ pattern และประสานผู้เชี่ยวชาญ แต่ ไม่รับ accountability แทน Product owner, Risk owner หรือ security function

Continuous Integration (CI) คือการรวม change บ่อยและ build/test อย่างสม่ำเสมอ Continuous Delivery ทำให้ artifact พร้อม promote โดยอาจยังมีการอนุมัติ production ส่วน Continuous Deployment ส่ง change ที่ผ่าน gate ไป production อัตโนมัติ ความ อัตโนมัติไม่ยกเลิก authorization แต่เปลี่ยน authorization ให้ฝังใน policy, branch, pipeline และ exception path

Integrated Product Team รวม business, architecture, engineering, security, QA, operations, privacy/legal และ supplier ตามความจำเป็น ทำให้ requirement และ constraint ถูกเห็นก่อนตัดสินใจ Maturity model เช่น OWASP Software Assurance Maturity Model (SAMM) ใช้ประเมิน current state, target และ roadmap ไม่ใช่คะแนนเพื่อประกาศว่าไม่มี risk

ตัวอย่าง: ทีม deploy วันละหลายครั้งไม่ควรส่งทุก commit เข้าคณะอนุมัติเดียวกัน ทีมอาจ กำหนด standard change สำหรับ service ที่ผ่าน test, two-person review, signed artifact, canary และ automated rollback ส่วน schema migration ที่ย้อนกลับยากต้องมี review และ business-specific recovery plan เพิ่ม

3.3 Secure coding guideline และ source-code weakness

Secure coding standard ต้องเฉพาะกับภาษา, framework และ runtime พร้อมตัวอย่างที่ทีมใช้ได้ หลักสำคัญประกอบด้วย

Validate input ที่ trust boundary ตรวจชนิด ความยาว ช่วง รูปแบบ และค่าที่อนุญาต หลัง canonicalization/normalization ที่เหมาะสม อย่าเชื่อ client-side validation
แยก data จาก command ใช้ parameterized query/prepared statement สำหรับ database, safe API สำหรับ operating system และหลีกเลี่ยงการประกอบ interpreter command จาก input
Encode output ตาม context HTML, attribute, JavaScript, URL และ SQL เป็นคนละบริบท การ “sanitize” แบบทั่วไปหนึ่งครั้งไม่ครอบคลุมทุก sink
บังคับ AuthZ ฝั่ง trusted service ตรวจ subject, action, object และ context ทุก request ที่สำคัญ ไม่ซ่อนปุ่มแล้วถือว่า user ทำ action ไม่ได้
ใช้ secure session และ authentication component ที่ยอมรับ ปกป้อง token, กำหนด expiry/revocation ตาม risk, rotate session เมื่อ privilege เปลี่ยน และไม่เขียน protocol เอง
ใช้ cryptographic library ที่ได้รับการยอมรับ กำหนด algorithm, mode, key lifecycle, nonce/IV และ error handling ตาม standard ห้ามสร้าง algorithm หรือเก็บ key ใน source
จัดการ error แบบ fail securely ส่งข้อความทั่วไปให้ client เก็บรายละเอียดที่จำเป็น ใน log ที่ป้องกันแล้ว rollback state เมื่อ transaction ไม่สมบูรณ์ และไม่เปิดสิทธิเพิ่ม
ป้องกัน memory และ concurrency defect ตรวจ bounds, integer conversion, lifetime, resource limit, race condition และ time-of-check/time-of-use ใช้ memory-safe construct เมื่อเหมาะ แต่ยังต้องควบคุม logic, dependency และ configuration
ไม่ฝัง secret ใช้ secret manager หรือกลไก runtime ที่อนุมัติ จำกัด scope/อายุ และเตรียม rotation การลบ secret ออกจาก commit ล่าสุดไม่ลบออกจาก repository history
บันทึก security event อย่างตั้งใจ ระบุ identity, action, object, outcome, time และ correlation โดยไม่บันทึก password, token, private key หรือ personal data เกินจำเป็น

ตัวอย่าง SQL injection: Code ที่ต่อ account_id ลง SQL string เปิดโอกาสให้ input เปลี่ยนโครงคำสั่ง การใช้ prepared statement แยกคำสั่งจากค่า แต่ยังต้องตรวจ authorization ว่า caller อ่าน account นั้นได้ Parameterization แก้ injection ไม่ได้แก้ Broken Object Level Authorization (BOLA)

3.4 Code review และ application security testing

เลือก test ตาม defect class และช่วง SDLC ไม่มีเครื่องมือเดียวครอบคลุมทั้งหมด

Peer review/manual code review เห็น intent, business logic, misuse case และ maintainability แต่คุณภาพขึ้นกับ reviewer, context และ scope
SAST วิเคราะห์ source, bytecode หรือ binary โดยไม่ต้องรัน application เหมาะกับ pattern บางชนิดและ feedback เร็ว แต่อาจมี false positive/false negative
DAST ทดสอบ application ที่กำลังรันจาก interface ภายนอก เห็น behavior และ configuration ของ environment แต่โดยทั่วไปชี้ source location ได้จำกัด
IAST ใช้ instrumentation ระหว่าง application ทำงานเพื่อเชื่อม runtime behavior กับ code path ต้องมี test traffic และการติดตั้งที่เหมาะ
SCA inventory component/dependency และจับคู่ vulnerability/license information แต่ต้องรู้ version, transitive dependency, reachability และ deployment context
Fuzz testing ส่ง input ที่ผิดรูปแบบหรือไม่คาดคิดจำนวนมากเพื่อหา crash, hang, resource exhaustion และ state error โดยต้อง triage และทำ test case ที่ทำซ้ำได้
Unit/integration test พิสูจน์ expected behavior ของ function และ interface รวม negative test, boundary, AuthZ และ failure path
Penetration testing ทดลอง exploit ตาม authorization เพื่อยืนยัน attack path/impact เป็น point-in-time evidence และไม่แทน secure SDLC

Pipeline ควรกำหนด quality/security gate ตาม risk เช่น block เมื่อพบ secret หรือ critical dependency ที่เข้าเงื่อนไขจริง, ส่ง finding ที่คลุมเครือให้ triage และอนุญาต exception เฉพาะเมื่อมี rationale, compensating control, approver และ expiry Metric ที่ดีเชื่อมกับ decision เช่น time-to-remediate ตาม exposure, recurring root cause และ percentage ของ critical flow ที่มี negative test ไม่ใช่นับ scanner run อย่างเดียว

ตัวอย่าง: SAST แจ้ง injection ใน code ที่ใช้ safe query builder ทีมต้อง validate data flow และ mark false positive พร้อมเหตุผล ไม่ควรปิด rule ทั้งองค์กร ในทางกลับกัน DAST ไม่พบ endpoint admin ที่ test account เข้าไม่ถึงก็ไม่ใช่หลักฐานว่า AuthZ ถูกต้อง ควรเพิ่ม role matrix และ explicit authorization test

3.5 DevSecOps และการปกป้อง CI/CD ecosystem

Development environment เป็น production system ของ software artifact หาก attacker แก้ source, build script หรือ runner ได้ code ที่เขียนอย่างปลอดภัยอาจถูกแทนที่ก่อนส่งมอบ Control สำคัญจึงครอบคลุม

Software-defined security คือการแสดง security policy/control เป็น code หรือ configuration ที่ version, review, test และ deploy ซ้ำได้ เช่น policy-as-code, IaC hardening และ network policy ข้อดีคือ consistency และ traceability แต่ logic ที่ผิด สามารถกระจายกว้างได้เร็ว จึงต้องใช้ change control, test และ least privilege เช่นกัน

ปกป้อง developer endpoint, IDE และ extension ด้วย inventory, patch, allowlist และ credential protection ตาม risk
ใช้ repository AuthN/MFA, least privilege, protected branch, required review, signed/tagged release และ immutable audit log ตาม capability
แยก CI runner ตาม trust, ใช้ ephemeral runner เมื่อเหมาะ, จำกัด network/secret, ไม่ให้ pull request ที่ไม่น่าเชื่อถือเข้าถึง production credential
pin และ verify dependency/toolchain, ใช้ trusted registry/proxy, monitor typosquatting, dependency confusion, maintainer compromise และ End of Support (EOS)
สร้าง Software Bill of Materials (SBOM) และ provenance เพื่อรู้ component, version, source และ build path โดยเข้าใจว่า SBOM เป็น inventory evidence ไม่ใช่ใบรับรองความปลอดภัย
ปกป้อง artifact registry, sign/verify artifact และ promote artifact เดิมข้าม environment ไม่ rebuild source ต่างครั้งโดยไม่จำเป็น
แยก development, test และ production account/network/data/secret ใช้ Infrastructure as Code (IaC) และ policy-as-code เพื่อลด drift พร้อม review change เช่นเดียวกับ code
deploy แบบ least privilege, canary/blue-green ตามความเหมาะสม, health/security check, rollback หรือ forward fix ที่ทดสอบได้ และ monitor หลัง release

ภาพนี้แสดงจุดที่ source, dependency, evidence และ risk decision มาบรรจบกันใน CI/CD

flowchart TD SRC["Source change"] --> REVIEW["Protected branch และ peer review"] DEP["Dependency และ toolchain"] --> DEPVERIFY["Pin และ verify source / version"] REVIEW --> BUILD["Controlled build และ runner ตาม trust"] DEPVERIFY --> BUILD BUILD --> EVIDENCE["Artifact และ evidence: digest / signature / SBOM / provenance"] EVIDENCE --> GATE{"Test criteria และ security gate"} GATE --> PASS["ผ่าน criteria"] PASS --> REGISTRY["Protected artifact registry"] REGISTRY --> DEPLOY["Least-privilege deployment"] DEPLOY --> MONITOR["Production monitoring"] GATE --> FINDING["ไม่ผ่าน criteria / finding"] FINDING --> DECIDE{"Remediate หรือ risk-based exception"} DECIDE --> FIX["Remediate, rebuild และ retest"] FIX --> SRC DECIDE --> EXCEPTION["Exception: owner / approval / mitigation / expiry"] EXCEPTION --> REGISTRY

ตัวอย่าง: Workflow จาก fork ภายนอกรัน build script ที่ผู้ส่งแก้ได้ หาก runner มี cloud credential แบบ long-lived ผู้โจมตีอาจขโมย secret โดยไม่ต้อง merge code แนวทางคือ แยก untrusted job, ไม่ inject privileged secret, จำกัด token ต่อ repository/action, require approval สำหรับ privileged stage และ rotate/revoke เมื่อสงสัยว่ารั่ว

3.6 Database และ data-layer security

Database security เริ่มจาก classification, data minimization และ ownership แล้วจึง เลือก control สำหรับ data at rest, in transit และ in use Application account ควรมี สิทธิขั้นต่ำ แยก read/write/admin role และไม่ใช้ database administrator account ใน connection string ปกติ View, stored procedure, row/column policy และ masking ช่วยจำกัด การเปิดเผยได้ แต่ต้องทดสอบ underlying privilege และทาง bypass

Relational database ใช้ key และ constraint รักษา entity/referential integrity Normalization ลด redundancy และ update anomaly แต่ไม่ใช่ security control โดยตรง Transaction มักอธิบายด้วย ACID: Atomicity ทำครบหรือไม่ทำ, Consistency พาข้อมูลจาก valid state หนึ่งไปอีก valid state, Isolation ควบคุมผลระหว่าง transaction พร้อมกัน และ Durability ทำให้ผล commit คงอยู่ตาม guarantee ของระบบ ระดับ isolation ต่ำอาจสร้าง dirty/non-repeatable/phantom read ตาม model ส่วน lock ที่ไม่ออกแบบอาจเกิด deadlock

NoSQL ไม่ได้ปลอด injection โดยอัตโนมัติ Attacker อาจส่ง operator, document structure, path หรือ expression ที่เปลี่ยน query จึงต้องใช้ typed schema, safe driver/API และ allowlist field/operator เช่นเดียวกับ SQL การ encrypt database at rest ลด risk จาก storage/media บางรูปแบบ แต่ไม่หยุด compromised application ที่ query ด้วยสิทธิถูกต้อง

Inference คืออนุมานข้อมูลที่ห้ามจากข้อมูลที่อนุญาต ส่วน aggregation คือการรวม ข้อมูลหลายรายการจน sensitivity สูงขึ้น Control อาจรวม query restriction, minimum group size, noise/generalization, masking, row/column access, monitoring และ privacy review แต่การจำกัด query มากเกินอาจทำลาย business use จึงต้องให้ Data owner กำหนด requirement

ตัวอย่าง: Analyst ได้สิทธิดูยอดขายเฉลี่ยของทีม แต่ query ทีมที่เหลือสมาชิกหนึ่งคน ทำให้อนุมานเงินเดือนหรือยอดขายรายบุคคลได้ การซ่อนชื่อไม่พอ ต้องกำหนด minimum cohort, ตรวจ repeated/differencing query และจำกัด export ตาม risk

3.7 OWASP Top 10 และการใช้ให้ถูกวัตถุประสงค์

OWASP Top 10:2025 เป็น awareness document สำหรับ web application risk รุ่นปัจจุบันประกอบด้วย

A01 Broken Access Control
A02 Security Misconfiguration
A03 Software Supply Chain Failures
A04 Cryptographic Failures
A05 Injection
A06 Insecure Design
A07 Authentication Failures
A08 Software or Data Integrity Failures
A09 Security Logging and Alerting Failures
A10 Mishandling of Exceptional Conditions

รายการนี้ช่วยสร้าง awareness, training, coding guideline, threat checklist และ test coverage แต่ไม่ใช่ security requirement ครบชุด ไม่ใช่ risk ranking ของทุกองค์กร และ ไม่ใช่มาตรฐานรับรองว่า application ปลอดภัย ควรใช้ร่วมกับ threat model และ requirement เฉพาะระบบ หากต้องการ control/verification ละเอียดอาจใช้ OWASP Application Security Verification Standard (ASVS) แล้ว tailor ตาม context

ความต่างที่ข้อสอบชอบใช้คือ Insecure Design ต้องแก้ model/requirement/architecture ไม่ใช่เพิ่ม input filterท้ายทาง ส่วน Injection มักแก้ด้วยการแยก data จาก command และ safe API Broken Access Control ต้องตรวจสิทธิฝั่ง server ทุก object/action และ Security Misconfiguration ต้องแก้ hardening/configuration lifecycle ไม่ใช่ source code เพียงอย่างเดียว

3.8 API security

API เป็น trust boundary ที่เปิด data และ business capability ให้ human หรือ non-human subject Security เริ่มจาก inventory ของ endpoint, owner, version, consumer, data class และ lifecycle API เก่าที่ไม่มีใน inventory อาจยังเปิดอยู่แม้เอกสารรุ่นใหม่ปลอดภัย

ภาพนี้แยก AuthN ออกจาก AuthZ และแสดงจุดบังคับสิทธิก่อนเข้าถึง data หรือ downstream API

flowchart LR CLIENT["Client / workload"] --> EDGE["TLS และ API endpoint"] EDGE --> AUTHN{"AuthN: validate token / credential"} TOKENRULES["Issuer / audience / signature / expiry / claim criteria"] --> AUTHN AUTHN -->|pass| AUTHZ{"AuthZ: subject + action + object + context"} AUTHN -->|fail| DENY["Deny และบันทึก outcome"] POLICY["Role / ownership / tenant / policy"] --> AUTHZ AUTHZ -->|pass| APP["Business logic และ input validation"] AUTHZ -->|fail| DENY APP --> DATA["Database / downstream API"] DATA --> RESPONSE["Authorized response และ output encoding"] RESPONSE --> CLIENT DENY --> LOG["Audit event: identity / action / object / outcome / time / correlation"] APP --> LOG

แนวทางสำคัญ ได้แก่

แยก AuthN จาก AuthZ ตรวจสิทธิระดับ function, object และ object property ทุก request
validate issuer, audience, signature, algorithm, expiry และ claim ของ token ตาม protocol/context อย่าใช้ OAuth 2.0 เป็นคำพ้องของ authentication หรือ decode JWT แล้ว เชื่อทันที OpenID Connect (OIDC) เพิ่ม identity layer บน OAuth 2.0 ตาม flow ที่กำหนด
ใช้ schema/type/size/content-type validation และ parameterized backend query
จำกัด rate, concurrency, payload, pagination, query depth, timeout และค่าใช้จ่ายต่อ consumer/operation เพื่อป้องกัน resource exhaustion และ business abuse
ป้องกัน Server-Side Request Forgery (SSRF) ด้วย destination policy, URL parsing, DNS/IP validation, network egress control และไม่ตาม redirect โดยไม่ตรวจ
ใช้ TLS พร้อม peer/certificate validation สำหรับ external และ internal API ตาม risk
กำหนด idempotency, anti-replay และ transaction state สำหรับ operation ที่ทำซ้ำไม่ได้
ส่ง error ที่ไม่รั่ว stack/secret เก็บ audit event พร้อม correlation และ alert path
treat response จาก third-party API เป็น untrusted input พร้อม timeout, size limit, schema validation และ allowlisted redirect/destination

OWASP API Security Top 10:2023 เน้น BOLA, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, SSRF, Security Misconfiguration, Improper Inventory Management และ Unsafe Consumption of APIs รายการนี้เสริม OWASP Top 10 ทั่วไป ไม่ได้ แปลว่า injection หรือ vulnerable component หายไปจาก API

ตัวอย่าง BOLA: GET /invoices/123 ใช้ token ที่ authenticate สำเร็จ แต่ service คืน invoice ตามเลขโดยไม่ตรวจว่า subject เป็นเจ้าของ การซ่อนเลขหรือใช้ UUID ทำให้เดายาก ขึ้นแต่ไม่ใช่ authorization control ต้องตรวจ relationship ระหว่าง subject, action และ object ที่ trusted service และมี negative test ข้าม tenant/owner

3.9 Malware ในบริบท software development

Virus เกาะ host file/program และแพร่เมื่อ host ทำงาน ส่วน worm แพร่ตัวเองผ่าน network หรือช่องทางอัตโนมัติ Trojan ปลอมเป็นสิ่งที่ผู้ใช้ต้องการ ransomware ทำให้ข้อมูล/ระบบใช้ไม่ได้และอาจขโมยข้อมูลก่อน logic bomb ทำงานเมื่อเงื่อนไขเกิด backdoor สร้างทางข้าม control ปกติ rootkit ซ่อนหรือคง privileged presence และ spyware เก็บข้อมูลโดยไม่ได้รับอนุญาต Malware แบบ fileless อาจใช้ memory และ เครื่องมือที่มีอยู่ จึงไม่จำเป็นต้องมี executable file ใหม่บน disk

ใน Domain 8 สนใจการป้องกัน malware เข้าสู่ source, dependency, build และ update channel ใช้ repository protection, peer review, dependency verification, isolated build, artifact signing/verification, secure update, least privilege, secret protection และ reproducible evidence ตามความเหมาะสม Code-signing บอก integrity/origin ตาม key และ process ที่เชื่อถือ ไม่พิสูจน์ว่า code ไม่มี malware หาก signing key หรือ build ถูกยึด

ตัวอย่าง: Library ที่ถูก maintainer account ยึดอาจผ่านชื่อ package และ signature ปกติของ registry การตรวจ hash เพียงอย่างเดียวพิสูจน์ว่าดาวน์โหลดตรงกับ artifact ที่ถูก เผยแพร่ ไม่พิสูจน์ว่า artifact นั้นดี ต้องใช้ version pinning, supplier/project review, behavior test, provenance, monitoring และ response plan ร่วมกัน

3.10 Acquired software และ software supply chain

ก่อนซื้อหรือ reuse ให้กำหนด security requirement ใน Request for Proposal (RFP), contract หรือ service agreement ตาม leverage ที่มี ประเด็นที่ควรประเมิน ได้แก่ secure development practice, architecture/integration, data location/handling, AuthN/AuthZ, logging, encryption/key responsibility, vulnerability disclosure, patch/support period, incident notification, subcontractor, assurance report, test right, SBOM/provenance, business continuity, termination, data return/destruction และ exit assistance

สำหรับ COTS ต้องประเมิน configuration, privilege, exposed service, update channel และ End of Life (EOL) สำหรับ open source ต้องรู้ maintainer health, release/signing process, dependency tree, license และช่องทางแก้ vulnerability สำหรับ SaaS/PaaS/IaaS ให้ทำ shared-responsibility mapping ว่า provider และลูกค้าควบคุม identity, configuration, data, log, key, patch และ recovery ส่วนใด

ไม่ควรเชื่อ vendor questionnaire หรือ certification อย่างเดียว Evidence ต้องสัมพันธ์ กับ service, scope, version และช่วงเวลาที่ใช้ และองค์กรยังต้อง validate configuration/ integration ของตน Finding ที่ supplier ยังแก้ไม่ได้ต้องมี mitigation, contractual escalation, replacement plan หรือ formal risk acceptance โดยผู้มี authority

3.11 Change, configuration, release และ deployment management

Software Configuration Management (SCM) ควบคุม identification, version, baseline, change และ status ของ source, dependency, build script, schema, configuration, documentation และ artifact ส่วน change management ประเมิน risk และ authorization Release management จัดกลุ่ม capability/version เพื่อส่งมอบ และ deployment management ย้าย artifact/configuration เข้า environment เป้าหมาย คำเหล่านี้สัมพันธ์แต่ไม่เหมือนกัน

เส้นทาง change ที่ตรวจสอบได้ควรมี request/issue, impact และ dependency analysis, security/privacy review ตาม trigger, approval, implementation, test result, release artifact, deployment record, post-deployment verification และ closure Emergency change ลดขั้นตอนหรือเวลาได้ตาม defined authority แต่ยังต้องบันทึก, test เท่าที่ทำได้, มี recovery option และ retrospective review

Database migration และ distributed service อาจ rollback ตรง ๆ ไม่ได้ จึงต้องทดสอบ backup/restore, backward compatibility, staged migration หรือ forward fix ตาม design คำว่า “มี rollback plan” หมายถึงมี recovery path ที่เป็นจริง ไม่ใช่เพียงปุ่มย้อน version

ตัวอย่าง: ทีมแก้ critical vulnerability ด้วย emergency change ผู้อนุมัติตาม on-call authority ตรวจ impact และ test evidence จากนั้น deploy signed artifact แบบ canary, monitor error/security signal และบันทึกผล วันถัดไปทำ independent review และเพิ่ม test ป้องกัน recurrence การเร่ง patch ไม่ใช่เหตุผลให้ใช้ shared admin account หรือข้าม audit

3.12 Application logging และ production feedback

Application รู้ business context ที่ network device อาจไม่รู้ จึงควร log authentication, authorization denial, privileged/business-critical action, validation failure, state change, administrative configuration และ security control failure ตาม use case Event ควรมี actor/service identity, action, target object, outcome, timestamp, source/context และ correlation identifier โดยปกป้อง integrity, access และ retention ตาม requirement

อย่า log password, session/access token, private key, full payment data หรือ personal data เกินวัตถุประสงค์ Error detail สำหรับ developer ควรแยกจากข้อความให้ client และ production debug logging ต้องมี authorization/expiry เพราะอาจเพิ่มข้อมูลอ่อนไหว

เมื่อเกิด incident ทีมต้องระบุ affected version, commit, component, build, deployment และ configuration แล้วแปลง root cause เป็น requirement/design/code fix พร้อม regression test และ pipeline rule ที่เหมาะ การเพิ่ม alert โดยไม่แก้ source อาจลดเวลา detect แต่ไม่ ใช่ corrective action ครบวงจร Closure ต้องมี deploy evidence, retest/monitoring และ residual-risk decision เช่นเดียวกับ Domain 6 และ 7

4. กรอบมาตรฐานที่เกี่ยวข้อง

4.1 NIST

NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1 เสนอ outcome ระดับสูงที่นำไปผสานใน SDLC แบบใดก็ได้ แบ่ง practice เป็น Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) และ Respond to Vulnerabilities (RV) จุดสำคัญคือเตรียมคน/process/technology, ปกป้อง code และ artifact, ลด vulnerability ใน release และใช้ root-cause feedback ป้องกัน recurrence ผู้ซื้อยังใช้ vocabulary นี้สื่อ requirement กับ supplier ได้

NIST SP 800-161 Rev. 1 ให้แนวทาง Cybersecurity Supply Chain Risk Management (C-SCRM) สำหรับ system และ organization ช่วยเชื่อม supplier, component, service และ lifecycle risk ส่วน NIST SP 800-53 Rev. 5 มี control families เช่น SA (System and Services Acquisition), CM (Configuration Management) และ SI (System and Information Integrity) ที่ใช้เป็น catalog แล้ว tailor ตามระบบ ไม่ใช่ checklist ที่ต้องใช้ทุก control ระดับเดียวกัน

4.2 ISO/IEC 27001

ISO/IEC 27001:2022 กำหนด Information Security Management System (ISMS) แบบ risk-based โดย Annex A เชื่อมกับ software lifecycle ผ่าน A.8.25 secure development life cycle, A.8.26 application security requirements, A.8.27 secure system architecture and engineering principles, A.8.28 secure coding, A.8.29 security testing in development and acceptance, A.8.30 outsourced development, A.8.31 separation of development/test/production, A.8.32 change management และ A.8.33 test information

Control ต้องมาจาก risk treatment และบันทึกความเหมาะสมใน Statement of Applicability (SoA) ไม่ใช่ใช้ Annex A แบบไม่ดู context ISO/IEC 27002:2022 ให้ implementation guidance สำหรับ controls แต่การรับรอง ISO/IEC 27001 ของ supplier ไม่พิสูจน์ว่า product ทุกชิ้น ไม่มี vulnerability ต้องตรวจ scope, integration และ product evidence เพิ่ม

4.3 COBIT

COBIT เชื่อม software delivery กับ enterprise governance, decision right, process outcome และ accountability วัตถุประสงค์ที่เกี่ยวข้องชัด ได้แก่ BAI02 Managed Requirements Definition, BAI03 Managed Solutions Identification and Build, BAI06 Managed IT Changes, BAI07 Managed IT Change Acceptance and Transitioning, BAI10 Managed Configuration, APO10 Managed Vendors, APO13 Managed Security และ MEA04 Managed Assurance

COBIT ช่วยตอบว่าต้องกำกับ outcome และความรับผิดรับชอบอย่างไร แต่ไม่แทน language-specific coding standard, threat model, test case หรือ CI/CD implementation

4.4 ITIL

ITIL 4 practices ที่สัมพันธ์ ได้แก่ Information Security Management, Software Development and Management, Service Validation and Testing, Change Enablement, Release Management, Deployment Management, Service Configuration Management, Incident Management และ Problem Management

Change Enablement ทำให้ change บรรลุผลด้วยการประเมิน risk, authorization และ schedule ที่เหมาะ ไม่ได้กำหนดว่าทุก change ต้องเข้าคณะเดียว Release Management เน้นทำ service/ feature พร้อมใช้ ส่วน Deployment Management เน้นเคลื่อน component เข้า environment การแยกคำช่วยไม่ให้ “deploy สำเร็จ” ถูกใช้เป็นหลักฐานว่า release ตอบ business/security requirement แล้ว

4.5 OWASP

OWASP Top 10 ใช้สร้าง awareness, OWASP ASVS ใช้เป็นฐาน requirement/verification สำหรับ web application, OWASP API Security Top 10 เน้น risk เฉพาะ API และ OWASP SAMM ใช้ ประเมิน/ปรับปรุง software assurance program SAMM จัดกิจกรรมใน business functions Governance, Design, Implementation, Verification และ Operations

เอกสาร OWASP เป็นแหล่งเปิดและใช้งานได้จริง แต่ต้องระบุชื่อและรุ่น เพราะรายการเปลี่ยนได้ และแต่ละ project มีวัตถุประสงค์ต่างกัน Top 10 ไม่แทน ASVS, ASVS ไม่แทน threat model เฉพาะระบบ และ maturity score ไม่เท่ากับ product assurance

4.6 ใช้กรอบร่วมกันอย่างไร

องค์กรอาจใช้ ISO/IEC 27001 เป็น ISMS/control context, COBIT เป็น governance และ accountability, ITIL เป็น service/change/release practices, NIST SSDF เป็น secure development outcome และ OWASP เป็น application-specific requirement, test guidance และ maturity roadmap จากนั้น map requirement และ evidence ชุดเดียวเพื่อลดงานซ้ำ

กรอบทั้งหมดต้องถูก tailor ด้วย business impact, data classification, threat, technology, supplier และ risk appetite กรอบไม่ควรถูกใช้แทน law, contract, architecture semantics, professional judgment หรือ authority สำหรับ residual risk

5. คำศัพท์สำคัญพร้อมนิยาม

SDLC: วงจรตั้งแต่ริเริ่ม กำหนด requirement ออกแบบ สร้าง ทดสอบ ใช้งาน ดูแลจนเลิกใช้ระบบ
Secure SDLC: การฝัง security requirement, control, evidence และ feedback ตลอด SDLC
Shift left: ทำ security activity ให้เร็วขึ้นใน lifecycle เช่น requirement/design review
Shift right: ใช้ runtime, production telemetry และ operational feedback ยืนยัน/ปรับ control
Threat modeling: วิเคราะห์ asset, data flow, trust boundary, threat และ mitigation อย่างเป็นระบบ
Abuse/misuse case: สถานการณ์ที่อธิบายการใช้ระบบโดยผู้โจมตีหรือในทางที่ไม่พึงประสงค์
Attack surface: จุดที่ attacker อาจโต้ตอบหรือส่งผลต่อระบบ
Secure coding standard: ข้อกำหนดการเขียน code ที่ปลอดภัยเฉพาะภาษา/framework/context
Input validation: ตรวจ input เทียบชนิด รูปแบบ ช่วง ความยาว และค่าที่อนุญาต
Output encoding: แปลงอักขระให้เป็น data ที่ปลอดภัยตาม output context
Parameterized query: ส่งโครงคำสั่งแยกจากค่าข้อมูลเพื่อลดการเปลี่ยน query structure
SAST: วิเคราะห์ source/bytecode/binary โดยไม่ต้องรัน application
DAST: ทดสอบ security ผ่าน interface ของ application ที่กำลังรัน
IAST: ใช้ instrumentation วิเคราะห์ระหว่าง application ทำงานกับ test traffic
SCA: inventory dependency/component และจับคู่ vulnerability/license information
Fuzz testing: ส่ง input ที่ผิดรูปแบบหรือไม่คาดคิดเพื่อหา failure และ weakness
Regression test: test ที่ยืนยันว่า change ไม่ทำให้ behavior ที่แก้แล้วหรือเดิมเสีย
DevOps: แนวทางเชื่อม development และ operations ผ่านความร่วมมือ/automation/feedback
DevSecOps: การฝัง security responsibility, control และ feedback ใน DevOps workflow
CI: การรวม change บ่อยพร้อม build/test อย่างสม่ำเสมอ
Continuous Delivery: ทำ artifact ให้พร้อม promote โดยอาจมี production approval
Continuous Deployment: deploy change ที่ผ่าน gate ไป production อัตโนมัติ
CI/CD pipeline: workflow อัตโนมัติสำหรับ integrate, build, test, package และส่งมอบ/deploy
SCM: การระบุ version, baseline, change และ status ของ software configuration items
Software-defined security: การแสดง security policy/control เป็น code/configuration ที่ควบคุม version และทดสอบได้
SBOM: รายการ component และข้อมูลประกอบของ software ตามรูปแบบที่กำหนด
Provenance: ข้อมูลแหล่งที่มาและกระบวนการที่สร้าง artifact
Software supply chain: คน process tool component และ service ที่สร้าง/ส่งมอบ software
BOLA: API ตรวจ object-level authorization ไม่เพียงพอจนเข้าถึง object ผู้อื่นได้
SSRF: server ถูกชักให้ส่ง request ไป destination ที่ผู้โจมตีมีอิทธิพลกำหนด
ACID: Atomicity, Consistency, Isolation, Durability ของ transaction
Inference: อนุมานข้อมูลที่ห้ามจากข้อมูลที่ได้รับอนุญาต
Aggregation: รวมข้อมูลจนเกิด sensitivity หรือ impact สูงขึ้น
Virus: malware ที่เกาะ host และแพร่เมื่อ host ทำงาน
Worm: malware ที่แพร่ตัวเองผ่าน network/กลไกอัตโนมัติ
Trojan: malicious software ที่ปลอมเป็นสิ่งที่ดูถูกต้องหรือมีประโยชน์
Logic bomb: malicious logic ที่ทำงานเมื่อถึงเงื่อนไขหรือเวลา
Backdoor: ทางเข้าที่ข้าม authentication/control ปกติ
Code signing: digital signature เพื่อยืนยัน integrity/origin ตาม key และ process
COTS: software สำเร็จรูปเชิงพาณิชย์ที่ซื้อหรือ license มาใช้
Security gate: จุดตัดสินจาก criteria/evidence ว่างานเดินต่อได้หรือไม่
Risk-based exception: การยกเว้น control ที่มีเหตุผล owner, approval, mitigation และ expiry

คำย่อที่ควรจำ: API = Application Programming Interface; ASVS = Application Security Verification Standard; AuthN = Authentication; AuthZ = Authorization; BOLA = Broken Object Level Authorization; CI = Continuous Integration; CI/CD = Continuous Integration/Continuous Delivery หรือ Deployment ตามบริบท; COTS = Commercial-Off-The-Shelf; C-SCRM = Cybersecurity Supply Chain Risk Management; DAST = Dynamic Application Security Testing; EOS = End of Support; EOL = End of Life; IAST = Interactive Application Security Testing; IaC = Infrastructure as Code; IDE = Integrated Development Environment; OIDC = OpenID Connect; OWASP = Open Worldwide Application Security Project; RFP = Request for Proposal; SAMM = Software Assurance Maturity Model; SAST = Static Application Security Testing; SBOM = Software Bill of Materials; SCA = Software Composition Analysis; SCM = Software Configuration Management; SDLC = Software Development Life Cycle; SoA = Statement of Applicability; SSDF = Secure Software Development Framework; SSRF = Server-Side Request Forgery

6. Exam Tips: จุดที่ข้อสอบชอบหลอก

เริ่มจาก requirement และ risk ก่อนเลือก scanner, WAF, language หรือ vendor
Security ต้องอยู่ทุก phase การ penetration test ก่อน go-live ไม่แทน secure SDLC
Shift left ไม่ยกเลิก shift right production monitoring และ feedback ยังจำเป็น
Agile/DevOps ไม่ปลอดภัยหรือไม่ปลอดภัยโดยตัวมันเอง ดู control, evidence และ cadence
DevSecOps ไม่ใช่ security team หรือ scanner ใหม่ เป็น shared responsibility และ workflow
Verification ไม่เท่ากับ validation ตรง specification อาจยังไม่ตอบ business need
ไม่พบ finding ไม่เท่ากับไม่มี vulnerability ทุก tool/test มี scope และ false negative
SAST ไม่ต้องรัน application, DAST ทดสอบระบบที่รันอยู่ ส่วน IAST ต้องมี instrumentation
SCA รู้ component/dependency แต่ไม่พิสูจน์ exploitability ทุกกรณี ต้องดู context
Peer review ยังจำเป็น automated test อาจไม่เข้าใจ business logic และ abuse case
Parameterized query แก้ injection ไม่ได้แก้ AuthZ ต้องตรวจสิทธิ object แยก
Client-side control ไม่ใช่ trusted enforcement ซ่อนปุ่มหรือ validate ใน browser ข้ามได้
Authentication success ไม่ให้ authorization อัตโนมัติ ตรวจ function/object/property
OAuth 2.0 เน้น delegated authorization OIDC เพิ่ม identity/authentication layer
UUID ไม่แทน object-level authorization เดายากขึ้นแต่ยังต้องตรวจ owner/tenant
Encryption at rest ไม่หยุด compromised application หาก application มีสิทธิอ่านข้อมูล
Normalization ลด redundancy ไม่ใช่ security control โดยตรง และ NoSQL ก็เกิด injection ได้
Stored procedure ไม่ปลอดภัยอัตโนมัติ dynamic query และ excessive privilege ยังเสี่ยง
OWASP Top 10 เป็น awareness document ไม่ใช่ checklist รับรองหรือ requirement ครบชุด
Insecure Design มักต้องแก้ requirement/architecture ไม่ใช่เพิ่ม filter ตอนท้าย
SBOM เป็น inventory ไม่ใช่ใบรับรองความปลอดภัย ต้องมี monitoring และ response
Digital signature พิสูจน์ตาม trust ของ key/process ไม่พิสูจน์ว่า content ไม่ malicious
Open source ไม่ปลอดภัยเพราะมองเห็น source และ proprietary ไม่ปลอดภัยเพราะมี vendor
ซื้อหรือ outsource ไม่ย้าย accountability ผู้ใช้บริการยังประเมิน integration และ residual risk
Source escrow ไม่รับประกัน buildability หรือ security ตรวจ dependency, skill และ right เพิ่ม
Continuous Delivery ต่างจาก Continuous Deployment อย่างแรกอาจรออนุมัติ production
Automation ไม่ยกเลิก SoD/authorization ให้ฝัง policy และ protected workflow
Emergency change ยังต้องมี control defined authority, record, test, recovery และ review
Release success ไม่เท่ากับ security acceptance ต้องมี evidence และ authority
Rollback อาจไม่ง่ายสำหรับ schema/distributed state ต้องมี recovery path ที่ทดสอบได้
Log มากไม่เท่ากับ detect ได้ ต้องมี event design, protection, correlation และ alert owner
อย่า log secret เพื่อ investigation เก็บข้อมูลเท่าที่จำเป็นตาม classification/retention
Incident fix ต้องย้อนเข้า SDLC เพิ่ม requirement, root-cause fix และ regression test
Security champion ไม่รับ risk แทน Risk owner และ developer ไม่ควรอนุมัติข้อยกเว้นตนเอง
Risk owner หรือผู้มี delegated authority รับ residual risk tool, tester และ supplier ทำแทนไม่ได้

7. Cross-reference ไป Domain อื่น

Domain 1: Security and Risk Management สำหรับ governance, policy/standard, risk appetite, legal/contract, supplier risk, professional ethics, accountability และ authority สำหรับ residual risk
Domain 2: Asset Security สำหรับ inventory, classification, Data owner, data lifecycle, minimization, retention, test information, masking, backup protection และ sanitization เมื่อเลิกใช้ software
Domain 3: Security Architecture and Engineering สำหรับ security architecture, trust boundary, attack surface, defense in depth, fail securely, cryptographic API/key lifecycle, assurance และ resilience
Domain 4: Communication and Network Security สำหรับ TLS/mTLS, certificate validation, segmentation, API gateway/WAF, service mesh, container/workload communication, egress control และ CI/CD network path
Domain 5: Identity and Access Management สำหรับ Identity, AuthN, AuthZ, OAuth/OIDC, least privilege, SoD, service/workload identity, secret/credential lifecycle, PAM และ object-level authorization
Domain 6: Security Assessment and Testing สำหรับ test strategy, criteria/evidence, SAST/DAST/IAST/SCA, code review, penetration testing, coverage, finding, false positive/negative, remediation tracking และ retest
Domain 7: Security Operations สำหรับ application logging/monitoring, vulnerability/patch/change operations, incident, malware response, deployment, backup/restore/recovery, exception และ lessons learned

ภาพรวมวงจรคือ Domain 1 กำหนด governance/risk; Domain 2 ถึง 5 ให้ data, architecture, network และ identity requirements; Domain 6 ประเมินและสร้าง evidence; Domain 7 เฝ้าระวัง ตอบสนองและกู้คืน; Domain 8 ฝังทั้งหมดลง product และ development ecosystem แล้วนำ production feedback กลับไปลด defect ที่ต้นเหตุ วงจรปิดเมื่อ change ถูก verify/validate และ residual risk ถูกส่งให้ผู้มี authority ตัดสินใจ