บทที่ 5: Secure Software Implementation

บทนี้พาคุณข้ามจุดเปลี่ยนสำคัญจาก security architecture ไปสู่สิ่งที่ระบบจะทำจริง ใน source code, configuration, dependency integration และ build artifact เป้าหมาย ไม่ใช่การจำรายการ “secure coding rules” แต่คือการรักษาความหมายของ requirement, security invariant และ interface contract จาก บทที่ 4 ให้คงอยู่เมื่อเจอข้อจำกัด ของภาษา runtime, concurrency, library และ build system พร้อมสร้างหลักฐานที่ตาม กลับไปยัง version ของ design ได้

[!IMPORTANT] คู่มือนี้เป็นเอกสารเตรียมสอบที่จัดทำขึ้นเอง ไม่ใช่ official ISC2 material และ ไม่ใช่ exam dump ตัวอย่างทั้งหมดเป็น pseudo code หรือแนวคิดประกอบการเรียนรู้ ไม่ใช่ production-ready code และต้องปรับตามภาษา framework, threat model, approved baseline และบริบทขององค์กรก่อนใช้จริง

ขอบเขตของ Secure Software Implementation ครอบคลุม objective 5.1–5.6 ได้แก่ secure coding, code analysis, implementation controls, risk treatment, component integration และ secure build บทนี้อ้างย้อนกลับไปยัง design allocation ในบทที่ 4 และส่ง negative/failure/concurrency cases กับ implementation evidence ให้ บทที่ 6 ยืนยัน ส่วนการ deploy และ operate จริงเป็น ขอบเขตของ บทที่ 7 และ supplier governance กับ provenance เชิงลึกเป็นขอบเขตของ บทที่ 8

วัตถุประสงค์การเรียนรู้และ exam outline mapping

เมื่อจบบทนี้ คุณต้องแยกได้ว่ากิจกรรมใดสร้าง control ใน implementation กิจกรรมใด เพียงค้นหา weakness และใครมี authority ตัดสิน residual risk ตารางต่อไปนี้ map objective ของ Domain 5 กับความสามารถที่ใช้ตอบโจทย์สถานการณ์

Objective	หัวข้อที่ครอบคลุม	สิ่งที่คุณต้องอธิบายหรือตัดสินใจได้
5.1 Adhere to relevant secure coding practices	Declarative/imperative security, concurrency, validation/sanitization, errors, output encoding, logging, sessions, APIs/libraries, resources, configuration/credentials, tokenization, isolation, cryptography/agility, access-control models/trust zones และ processor extensions	เลือก control placement ที่รักษา design invariant, แยกข้อมูลจากคำสั่ง, บังคับ complete mediation และทำ failure behavior ให้ชัดเจน
5.2 Analyze code for security risks	Static Application Security Testing (SAST), manual review, reuse analysis, Common Weakness Enumeration (CWE), OWASP/SANS-oriented guidance และ malicious/hidden code	ใช้ taxonomy กับเครื่องมือเป็นตัวช่วยค้นหาและจัดกลุ่ม ไม่ใช้ finding หรือ severity score แทน contextual risk decision
5.3 Implement security controls	Authentication/authorization enforcement, data protection, protected evidence, anti-automation, memory/process isolation และ control composition	เปลี่ยน allocation จาก design เป็น code/config evidence ที่ version-matched พร้อมอธิบาย failure mode และ trust dependency
5.4 Address identified security risks	Avoid, mitigate, transfer/share, accept, remediate, compensating control, exception และ re-design	เลือก treatment ตาม risk, requirement และ authority พร้อม trace owner, expiry, verification route และ residual risk
5.5 Evaluate and integrate components	Systems integration, trusted/untrusted API, third-party reuse, Software Composition Analysis (SCA), compatibility, privilege และ failure semantics	ตรวจ trust contract ที่รอยต่อและควบคุม component ในบริบทของระบบ โดยไม่ถือว่า reuse หรือ scan result เท่ากับ secure
5.6 Apply security during the build process	Isolated build, least-privileged identity, compiler/linker safeguards, warnings, anti-tamper, deterministic inputs, immutable artifact identity และ gate evidence	ป้องกัน source-to-artifact path และแยก build integrity จาก supplier provenance และ production release approval

รายละเอียดของ objective เหล่านี้เชื่อมกันเป็นวงจร ไม่ใช่ขั้นตอนเส้นตรง การพบ race condition ระหว่าง code review อาจย้อนกลับไปแก้ design state model; การพบ dependency conflict อาจเปลี่ยน implementation control; และ build gate อาจหยุด artifact ที่หลักฐานไม่ครบ แม้ source code จะ compile สำเร็จ

แนวคิดหลัก

หัวใจของ implementation security คือการทำให้ทุกเส้นทางที่เปลี่ยน security-relevant state รักษา invariant เดียวกัน ภายใต้ input, timing, failure และ dependency ที่ ควบคุมไม่ได้ทั้งหมด ส่วนนี้อธิบายแบบจำลองที่ช่วยให้คุณตัดสิน placement และสร้าง evidence โดยไม่สับสนระหว่าง design intent, code presence และ verified behavior

จาก design allocation สู่ implementation evidence

Design บอกว่า “อะไรต้องจริง” และ “control อยู่ที่ใด” ส่วน implementation ต้อง ตอบว่า code/configuration/build version ใดทำให้สิ่งนั้นจริง การรักษา semantic traceability ใช้สายต่อไปนี้

แผนภาพนี้แยก implemented ออกจาก verified อย่างจงใจ การมี code path, review record และ build artifact ทำให้เราชี้ implementation evidence ได้ แต่ผลว่าควบคุม attack path ได้จริงต้องผ่าน strategy และ test cases ในบทที่ 6 หาก implementer พบว่า invariant ทำไม่ได้ ต้องเปิด change control หรือ exception ตาม governance ไม่ควร ลด semantic scope ใน code เงียบ ๆ

Implementation evidence ที่มีคุณภาพตอบคำถามอย่างน้อยห้าข้อ ได้แก่ code/config version ใด, requirement/design version ใด, control อยู่ path ใด, analysis ใดถูกทำ และ test route ใดจะยืนยันผล Evidence ที่เป็นเพียง screenshot หรือข้อความว่า “reviewed” โดยไม่ผูก version ไม่สนับสนุน traceability ที่เพียงพอ

Declarative security กับ imperative security

Declarative security ระบุ policy ผ่าน metadata, configuration, annotation หรือ framework rule เช่น route policy และ database permission ส่วน imperative security เขียน decision flow ใน code เช่นตรวจ object ownership ก่อน state transition ทั้งสอง แบบมี failure modes ต่างกันและมักต้องประกอบกัน

มิติ	Declarative security	Imperative security
จุดแข็ง	สม่ำเสมอ รวมศูนย์ ตรวจ baseline และ automate ได้ง่าย	แสดง business context, state และ exceptional path ที่ซับซ้อนได้ละเอียด
ความเสี่ยง	Annotation หาย, rule precedence ผิด, default เปลี่ยนตาม framework หรือ route ใหม่ไม่ inherit policy	Logic กระจาย, copy/paste drift, early return bypass และ reviewer มอง path ไม่ครบ
หลักฐาน	Policy/config diff, resolved policy, coverage mapping และ deny-by-default test plan	Code review, control-flow/data-flow analysis, invariant mapping และ negative-path plan
คำถามสำคัญ	Rule ถูกใช้กับทุก entry point และ effective configuration จริงหรือไม่	ทุก state-changing path ไปถึง authoritative PEP หรือไม่

ตัวอย่างที่ดีคือใช้ declarative rule บังคับ authenticated workload และ coarse-grained route scope แล้วใช้ imperative code ตรวจ subject + action + resource + context + transaction_version ที่ authoritative PEP การมีสองชั้นไม่ใช่ defense in depth หาก ทั้งคู่พึ่ง user-controlled claim เดียวกันหรือ framework middleware เดียวกันโดยไม่มี independent check

Complete mediation ใน request-to-commit path

Request ที่ปลอดภัยไม่ใช่ “validate แล้วจบ” แต่เป็นลำดับของ trust decisions ที่ต้อง ผูกกันตั้งแต่ parse จน atomic commit แผนภาพต่อไปนี้แสดง path สำหรับ state-changing request และจุดที่ข้อมูลเปลี่ยนสถานะความน่าเชื่อถือ

การตีความที่สำคัญคือ validation ไม่ทำให้ข้อมูล “trusted” สำหรับทุก purpose Credential ที่ผ่าน schema ยังต้องถูก verify, authenticated subject ยังไม่เท่ากับ authorized action และ authorization ที่ตรวจนอก transaction อาจ stale ก่อน commit ดังนั้น complete mediation ต้องรวม internal worker, batch, admin และ recovery path ไม่ใช่เฉพาะ public controller

Input validation, canonicalization และ sanitization

Input validation ตัดสินว่าค่าตรง contract สำหรับ purpose นี้หรือไม่ Canonicalization ทำ representation ให้เป็นรูปที่ตีความเดียวก่อนเปรียบเทียบหรือ authorize ส่วน sanitization เปลี่ยนหรือลบส่วนของข้อมูลเพื่อลดอันตรายใน context หนึ่ง คำเหล่านี้ไม่ใช้แทนกัน

หลักการสำคัญมีดังนี้

• ตรวจ boundary ที่ข้อมูลข้าม trust boundary และตรวจ business invariant อีกครั้ง ใกล้ authoritative state transition โดยใช้ allowlist ตาม schema/semantics
• จำกัด length, depth, count, range, encoding และ resource cost ก่อน parse ส่วนลึก เพื่อป้องกันทั้ง injection และ resource exhaustion
• Canonicalize เพียงครั้งตาม contract ที่ชัด แล้ว validate representation นั้น หลีกเลี่ยง decode ซ้ำหรือ normalization คนละแบบระหว่าง PEP กับ data store
• แยก data ออกจาก command ด้วย parameterized interface หรือ structured API Validation ไม่ใช่ข้ออ้างให้ concatenate input เข้า SQL, shell, template หรือ LDAP
• ใช้ sanitization เมื่อ requirement อนุญาตให้แก้ข้อมูล และบอกผู้ใช้ถึง semantic change; สำหรับ identifier หรือ financial amount การ reject มักปลอดภัยกว่าการแก้
• ตรวจ derived, stored และ re-imported data เช่นเดียวกับ external input เมื่อมันเข้า sink ใหม่ เพราะ “มาจาก database ของเรา” ไม่ได้แปลว่าปลอดภัยต่อ output context

Validation ต้องผูกกับ destination semantics ตัวอักษรที่ปลอดภัยใน display text อาจ เป็นอันตรายใน URL, HTML attribute, JavaScript, SQL identifier หรือ shell argument จึงไม่มี universal sanitizer ที่ทำให้ค่าปลอดภัยทุก sink

Output encoding และการแยก data จาก executable context

Output encoding เปลี่ยน representation ณ จุดส่งออกให้ data ไม่ถูกตีความเป็นคำสั่ง ใน sink นั้น โดยต้องเลือก encoder ให้ตรง context และทำใกล้ sink หลัง business logic เสร็จ การ encode เร็วเกินไปเสี่ยง double encoding หรือข้อมูลถูก decode ระหว่างทาง

แนวทางนี้ครอบคลุม HTML text, HTML attribute, URL component, structured JSON, JavaScript context และ log/event format ที่ต่างกัน Template auto-escaping ลด risk ได้เมื่อใช้อย่างถูก context แต่ raw rendering, unsafe directive หรือการประกอบ หลายภาษาใน string เดียวสามารถข้าม protection ได้ Parameterized database API เป็น การแยก data จาก command ไม่ใช่ output encoding และต้องเรียกให้ถูกหมวด

Error, exception และ failure semantics

Secure error handling ต้องรักษา security policy พร้อมสร้าง evidence ที่แก้ปัญหาได้ ผู้เรียกภายนอกได้รับข้อมูลเท่าที่จำเป็น ส่วน protected channel เก็บ correlation, operation, decision class และ root-cause context ที่ผ่าน minimization

ทีมต้องแยก failure อย่างน้อยดังนี้

• Invalid input: contract ไม่ผ่าน ต้องไม่มี side effect และไม่สะท้อน parser detail ที่ช่วย enumerate implementation เกินความจำเป็น
• Authentication/authorization failure: ปฏิเสธแบบไม่เปิดเผยว่า resource ลับมี อยู่หรือไม่ เว้นแต่ contract กำหนด response semantics ต่างออกไป
• Conflict/stale version: ไม่ retry แบบ blind เพราะอาจละเมิด user intent หรือ maker/checker binding ต้องกลับไปอ่าน authoritative state
• Transient dependency failure: retry เฉพาะ operation ที่ idempotent หรือมี idempotency key ที่ authoritative store บังคับ พร้อม bounded backoff/budget
• Control unavailable: state change ต้อง fail secure ตาม design; อย่าสลับเป็น allow โดยอัตโนมัติเพื่อรักษา availability
• Internal defect: rollback/contain side effect, return generic response และส่ง protected diagnostic event โดยไม่ log secret หรือ raw Restricted payload

การ catch exception กว้างแล้วคืน success เพื่อ “ไม่ให้ระบบล่ม” ทำให้ integrity และ accountability เสียหาย ส่วนการส่ง stack trace, SQL text, filesystem path หรือ token กลับผู้ใช้ทำให้ confidentiality และ attack discovery แย่ลง

Concurrency, atomicity และ TOCTOU

Concurrency ทำให้ code ที่ถูกต้องเมื่อรันทีละ request ละเมิด invariant เมื่อหลาย actor หรือ worker ทำงานพร้อมกัน ปัญหามักเกิดเมื่อ “check” และ “use” อยู่คนละ atomic boundary เช่นอ่านว่า transaction ยังไม่ถูก approve แล้วอีก thread แก้ version ก่อน commit หรือ worker สองตัวเห็น idempotency record ว่างพร้อมกัน

State model ต่อไปนี้ย้ำว่า decision ต้องผูก actor และ immutable version เข้ากับ authoritative transition ไม่ใช่อาศัยลำดับของ UI หรือ message arrival

แผนภาพนี้ทำให้ race handling เป็นส่วนหนึ่งของ policy หาก payload เปลี่ยนหลัง approval ระบบต้องสร้าง version ใหม่และ approval เดิมใช้ไม่ได้ Lock เพียงอย่างเดียว ไม่แก้ semantic race หาก lock อยู่คนละ process หรือไม่ครอบคลุม ledger commit Implementation เลือกกลไกตาม contextได้ เช่น database transaction กับ conditional update, optimistic concurrency ด้วย version compare, unique constraint สำหรับ idempotency, serialized command stream หรือ lock ที่มี fencing token

ข้อควรพิจารณาเกี่ยวกับ concurrency มีดังนี้

• ทำ invariant ที่สำคัญให้ enforce ที่ authoritative store ด้วย atomic operation เมื่อเป็นไปได้ แทน read-check-write หลายขั้น
• อย่าเชื่อว่า queue ส่ง exactly once; ออกแบบ consumer ให้รับ duplicate, reorder, timeout หลัง commit และ redelivery ได้
• ผูก idempotency identity กับ authenticated subject, operation scope และ semantic payload/version ไม่ใช้ user-chosen short key เดี่ยว ๆ ข้าม tenant
• ใช้ bounded lock wait, retry budget และ resource cleanup เพื่อไม่เปลี่ยน race control ให้เป็น denial-of-service vector
• ตรวจ cache freshness และ revocation semantics ก่อน state change การ invalidate แบบ eventually consistent อาจไม่พอต่อ high-impact action
• ระวัง signal handler, asynchronous callback, shared mutable state, file rename, temporary path และ permission check ที่เกิด TOCTOU นอก database ด้วย

Secure logging และ protected evidence

Logging เพื่อ debug ไม่เท่ากับ protected evidence เพื่อ accountability Event ที่มี คุณค่าต้องผูก actor/workload identity, action, resource reference, result, security- relevant state/version, correlation และ time source ตาม assurance โดยไม่เก็บ data เกิน purpose

แนวปฏิบัติที่สมดุลมีดังนี้

• ใช้ structured event schema และ fixed event type แทนต่อ string จาก untrusted input เพื่อป้องกัน log injection และ parser ambiguity
• Normalize line breaks/control characters หรือเก็บ field ผ่าน serializer ที่ ปลอดภัยต่อ sink; อย่าใช้ “sanitize ทุกอย่าง” จน forensic meaning หาย
• ห้ามบันทึก password, private key, bearer token, session identifier แบบเต็ม, recovery secret หรือ raw Restricted payload หากไม่มี approved purpose
• Tokenize, truncate หรือ pseudonymize identifier เมื่อ correlation ยังทำได้โดยไม่ เปิดเผยค่าต้นฉบับ และควบคุม mapping แยกตาม privilege
• แยก authorization ของผู้เขียน ผู้อ่าน ผู้ดูแล และผู้ลบ evidence ตาม SoD พร้อม integrity protection, retention และ failure behavior ที่ design กำหนด
• ป้องกัน telemetry failure ไม่ให้ exception path เปิด secret หรือทำ business commit แบบไม่มี evidence หาก requirement บังคับ evidence ก่อน/พร้อม transition

Integrity ของ log ไม่ได้ทำให้ event เป็นความจริงทั้งหมด หาก compromised process สร้างข้อมูลเท็จได้ จึงต้องรักษา attribution, independent observation และ reconciliation เท่าที่ risk ต้องการ และส่ง runtime storage/monitoring ไปบทที่ 7

Session และ token lifecycle

Session management เชื่อม authentication กับ authorization decisions ในช่วงเวลา หนึ่ง Implementation ต้องจัดการ issuance, binding, storage, rotation, expiry, revocation และ termination ไม่ใช่เพียงสร้าง random identifier

หลักที่ใช้ร่วมกันได้มีดังนี้

• สร้าง session/token ด้วย approved cryptographic randomness และ length ตาม approved standard ของระบบ ไม่แต่ง threshold ขึ้นเองในบทนี้
• เปลี่ยน session identifier เมื่อ assurance หรือ privilege เปลี่ยน เช่นหลัง authentication เพื่อป้องกัน session fixation และแยก pre-auth state
• ผูก token claims กับ issuer, audience, purpose, subject, scope และ freshness; ตรวจ signature/MAC, algorithm policy และ temporal semantics ก่อนใช้
• ปฏิเสธ algorithm downgrade, ambiguous key selection และ token type confusion อย่าใช้ access token ใน context ที่ออกแบบไว้สำหรับ identity token
• เก็บ bearer token ในช่องทางที่ลด accidental disclosure และ cross-context use; อย่าใส่ token ใน URL, log หรือ error detail
• บังคับ server-side authorization ทุก action แม้ client จะมี role/scope claim เพราะ claim อาจ stale และ resource/context ยังต้องถูกตรวจ
• กำหนด logout, revocation, credential reset, account disable และ administrative termination ให้กระทบ effective session ตาม freshness requirement

Stateless token ลดการ lookup แต่ทำให้ immediate revocation และ claim freshness ซับซ้อน Stateful session เพิ่ม authoritative control แต่สร้าง availability และ state-management burden ไม่มีตัวเลือกใดปลอดภัยสากล ต้องผูกกับ risk, degraded mode และ interface contract

Trusted และ untrusted APIs/libraries

คำว่า trusted หมายถึง component อยู่ใน Trusted Computing Base (TCB) หรือได้รับ authority บางอย่างตาม design ไม่ได้แปลว่า input/output ของมันปลอดภัยเสมอ API ที่ ทีมเขียนเองอาจ compromised หรือมี stale state ส่วน public library อาจมี narrow, well-reviewed interface ที่ลด custom weakness ได้

เมื่อเรียก API หรือ library ให้กำหนด trust contract ต่อไปนี้

• Origin และ identity: เรากำลังเรียก component/endpoint/version ที่ตั้งใจหรือไม่ และ binding นี้ป้องกัน substitution อย่างไร
• Input/output contract: schema, encoding, canonical form, maximum cost, error และ partial-success semantics คืออะไร
• Authority: library รันด้วย privilege ของ process ใด เปิด filesystem/network, reflection, native code หรือ dynamic loading ได้แค่ไหน
• State/concurrency: call thread-safe หรือ reentrant หรือไม่ เกิด callback, global cache, retry หรือ duplicate side effect ที่มองไม่เห็นหรือไม่
• Failure: timeout, cancellation, circuit open, malformed response และ version mismatch เปลี่ยน security behavior อย่างไร
• Lifecycle: update/disable/replace ได้หรือไม่ และ component support/config assumptions ถูกติดตามที่ใด

ข้อมูลจาก internal API ยังต้อง validate ต่อ consumer contract โดยเฉพาะเมื่อ crossing trust zone การ mark library ว่า trusted โดยไม่มีเหตุผลทำให้ attack surface และ TCB ขยายเงียบ ๆ ส่วน supplier claim, pedigree และ provenance ต้องไปวิเคราะห์ต่อในบท 8

Resource management และ denial of service

Memory, CPU, thread, file descriptor, connection, lock, queue, temporary storage และ cryptographic work เป็น security-relevant resources Implementation ต้องจำกัด allocation ก่อนงานแพง ปล่อย resource ทุก exit path และแยก quota ตาม tenant/subject ตาม policy เพื่อควบคุม blast radius

หลักปฏิบัติสำคัญประกอบด้วยการใช้ bounded collection และ queue, streaming เมื่อไม่ ต้อง materialize ทั้ง payload, deadline/cancellation propagation, safe cleanup, connection pool isolation, backpressure และ rate/concurrency control ที่ placement เหมาะสม การ rate limit ที่ edge ชั้นเดียวไม่ปกป้อง expensive internal fan-out และ shared global limit อาจเปิดทาง noisy neighbor ทำให้ tenant อื่น unavailable

Integer overflow ในขนาด allocation, decompression bomb, regex worst-case, recursive parser depth, unbounded deserialization graph และ retry storm เป็นตัวอย่าง ที่ input เล็กสร้าง resource cost สูง Validation จึงต้องพิจารณา computational complexity ไม่ใช่เพียง syntax

Secure configuration และ credential handling

Code ที่ปลอดภัยสามารถถูก configuration ทำให้ fail open ได้ Configuration ต้องมี schema, safe defaults, source precedence, environment binding, integrity, change control และ startup/runtime validation ตาม design ค่า unknown หรือ deprecated ต้อง ถูก reject หรือรายงานเป็น explicit state ไม่ควรถูก ignore เงียบ ๆ

Credential และ cryptographic key ต้องแยกจาก source code, image, example, log และ build output ใช้ scoped workload identity หรือ short-lived credential เมื่อ architecture รองรับ จำกัด purpose/privilege และสร้าง rotation/revocation route Implementation ต้องไม่รวม credential หลาย service เพื่อความสะดวก เพราะเพิ่ม blast radius และทำลาย accountability

การอ้าง secret ด้วย identifier แล้วดึงผ่าน authorized channel ลดการฝังค่า แต่ secret manager ไม่แก้ปัญหาทั้งหมด Process memory, crash dump, child process, debug endpoint, environment inheritance และ error trace ยังเปิดเผยค่าได้ การ mask ใน UI หรือ CI log เป็น defense หนึ่ง ไม่ใช่หลักฐานว่า secret ไม่เคยรั่ว

Tokenization และ data minimization

Tokenization แทน sensitive value ด้วย token ที่ไม่มีความหมายโดยตัวมันเอง แล้วเก็บ mapping หรือ transformation authority ใน boundary ที่แยกออกมา ผลคือ downstream component ไม่ต้องเห็นค่าต้นฉบับและ blast radius ลดลง แต่ tokenization ไม่เท่ากับ encryption และไม่ลบ classification โดยอัตโนมัติ

Token อาจยังเป็น sensitive เมื่อ link กลับบุคคล ใช้ทำธุรกรรม หรือถูก enumerate ได้ Implementation ต้องพิจารณา token uniqueness, domain/purpose binding, collision, format preservation risk, detokenization authorization, mapping availability, logging และ disposal การสร้าง deterministic tokenช่วย correlation แต่เปิด equality pattern; random token ซ่อน pattern มากกว่าแต่ต้องจัดการ mapping/state

Isolation, trust zones และ access-control models

Isolation จำกัด interaction และ blast radius ผ่าน process, memory, container, virtual machine, language sandbox, database schema, account หรือ network boundary แต่ชื่อกลไกไม่พิสูจน์ isolation ต้องดู shared kernel, runtime, identity, storage, administrator, key, IPC และ escape path ที่เป็น common dependency

Access-control model ช่วยจัด policy semantics ที่ PEP ต้อง implement ตัวอย่างสำคัญ มีดังนี้

• Discretionary Access Control (DAC): owner มีอำนาจมอบสิทธิ์ ยืดหยุ่นแต่เสี่ยง permission propagation และ owner error
• Mandatory Access Control (MAC): policyส่วนกลางใช้ label/classification บังคับ flow เหมาะกับ context ที่ต้องจำกัด owner discretion แต่บริหาร label ซับซ้อน
• Role-Based Access Control (RBAC): ผูกสิทธิ์กับ role จัดการ job function ได้ดี แต่ role explosion และ coarse scope ทำให้ least privilege เสื่อมได้
• Attribute-Based Access Control (ABAC): ตัดสินจาก subject, resource, action และ environment attributes ยืดหยุ่นแต่ต้องควบคุม attribute origin/freshness และ policy complexity
• Rule-based/policy-based control: ใช้กฎ condition หรือ relationship บังคับ context เฉพาะ เช่น maker ต้องไม่เท่ากับ checker และ version ต้องตรงกัน

หนึ่งระบบอาจผสมหลาย model เช่น RBAC ให้ capability เริ่มต้น, ABAC จำกัด tenant/time และ business rule บังคับ SoD สิ่งสำคัญคือ default deny, complete mediation และ authoritative attributes ที่ trust zone boundaries ไม่ใช่เลือก acronym ที่ดูดีที่สุด

Cryptography และ cryptographic agility

Cryptography สนับสนุน confidentiality, integrity, authentication หรือ evidence ตาม construction และ key management ที่ถูกต้อง ไม่ใช่ security property โดยตัวมัน เอง Implementation ต้องใช้ reviewed library และ approved algorithm/mode/protocol ผ่าน narrow wrapper แทนสร้าง primitive หรือกระจาย parameters ทั่ว codebase

Cryptographic agility คือความสามารถในการเปลี่ยน algorithm, parameter, key type, provider หรือ protocol suite ตาม authorized policy โดยไม่ลด security semantics และ ไม่สร้าง downgrade path ควรแยก algorithm identifier ที่เชื่อถือได้ออกจาก untrusted message, version ciphertext/envelope, ผูก metadata ด้วย integrity protection และ รองรับ controlled migration/dual-read ตาม decision record

Agility ไม่ได้หมายถึง “เปิดให้เลือก algorithm ใดก็ได้” Allowlist ที่กว้างเกินและ fallback อัตโนมัติทำให้ attacker บังคับ weak option ได้ การ rotate key โดยไม่วาง data re-encryption, rollback, backup และ revocation semantics อาจทำให้ availability หรือ integrity เสียหาย Deployment ของ key และ runtime crypto policy อยู่บทที่ 7

Processor security extensions และ memory-safe implementation

Compiler, operating system และ processor อาจมี safeguards เช่น non-executable memory, address-space randomization support, stack protection, control-flow integrity, pointer/memory tagging, privilege rings, trusted execution หรือ hardware- backed key isolation ความสามารถจริงขึ้นกับ platform, toolchain และ configuration ที่ approved baseline กำหนด จึงไม่ควรอ้างชื่อ feature เป็น assurance โดยไม่ตรวจว่า artifact เปิดใช้และ runtime enforce จริง

Implementation ใช้ memory-safe language หรือ safe subset เมื่อเหมาะสม ลด unsafe block/native interface, ตรวจ bounds/lifetime/ownership และเปิด compiler/linker safeguards ที่ compatibility อนุญาต Hardware extension เป็น defense in depth ต่อ บาง failure mode แต่ไม่แก้ broken authorization, injection, business logic หรือ compromised privileged code และอาจเพิ่ม side-channel/trust assumptions ใหม่

Code analysis: taxonomy, tools และ human reasoning

Code analysis มีเป้าหมายค้นหา weakness และ malicious/undocumented behavior พร้อม สร้าง evidence เพื่อ treatment ไม่ใช่ผลิตจำนวน findings ให้มากที่สุด วิธีต่าง ๆ มองเห็นคนละส่วนและต้อง map กลับ threat model กับ SRTM

วิธี	มองเห็นได้ดี	Blind spots และ trade-offs
SAST	Data/control flow, unsafe API pattern, injection path, memory/resource misuse และ rule violation ใน source/intermediate representation	False positive/negative, framework modeling ไม่ครบ, generated/reflection path และ runtime config อาจหาย
Manual code review	Business invariant, authorization placement, subtle race, hidden bypass, intent mismatch และ suspicious change	ใช้คนและ context สูง, reviewer fatigue และ coverage ไม่สม่ำเสมอ
Compiler/linter warnings	Type, lifetime, uninitialized state, undefined behavior และ unsafe construct ตามภาษา/toolchain	ไม่เข้าใจ business risk และ warning suppression อาจซ่อน defect
SCA	Known component/version/license inventory, dependency tree และบาง configuration/advisory mapping	ระบุไม่ได้ว่า path reachable/exploitable เสมอ, component identification อาจคลาด และไม่พิสูจน์ provenance
Binary/artifact inspection	สิ่งที่เข้า artifact จริง, symbols, embedded secret/config, hardening flags และ unexpected payload	Trace กลับ source/intent ยากและไม่แทน behavioral verification

Common Weakness Enumeration (CWE) ช่วยใช้ภาษากลางสำหรับชนิด weakness ส่วน OWASP และ SANS-oriented guidance ช่วยจัด focus/list แนวปฏิบัติในบางบริบท รายการเหล่านี้ ไม่ใช่ risk register, exhaustive checklist หรือ proof of absence ควรใช้ taxonomy จำแนก root cause แล้วเพิ่ม asset, exploit precondition, reachability, control และ business impact ตามวิธี risk ขององค์กร

Manual review ที่มีประสิทธิผลเริ่มจาก change intent และ attack path แล้วตาม data, identity, privilege, state และ failure จาก entry point ถึง side effect Reviewer ควร ถามว่ามี alternate entry point, feature flag, debug route, test hook, reflection, dynamic loading, generated code หรือ error fallback ที่ bypass PEP หรือไม่

Code reuse และ malicious code

Reuse ลด custom complexity แต่รับทั้ง capability, defect, privilege และ lifecycle ของ component เข้ามา Code ที่ดูสั้นลงอาจทำให้ TCB ใหญ่ขึ้นหาก library รันใน process privileged หรือเปิด dynamic plugin path การ evaluate reuse ต้องพิจารณา fitness, API surface, configuration, transitive dependency, maintenance และ exit path

Malicious code อาจปรากฏเป็น backdoor, logic bomb, credential theft, covert channel, obfuscated loader, dependency confusion hook, build script, compiler/plugin behavior หรือ “temporary” bypass ที่ถูกซ่อน Review ต้องดู high-risk change ด้วย SoD, จำกัด generated/binary blob, ตรวจ unexpected network/process/file capability และเปรียบเทียบ artifact กับ approved inputs ทั้งนี้การพิสูจน์ supplier provenance เชิงลึกเป็นงาน บทที่ 8 ไม่ใช่ conclusion จาก code review เพียงครั้งเดียว

ภัยคุกคาม ช่องโหว่ และความเสี่ยง

การวิเคราะห์ implementation ต้องเริ่มจาก asset/objective และ concrete scenario ไม่ใช่ เริ่มจากชื่อ weakness แล้วสรุป severity ตารางนี้แสดงตัวอย่างสายเหตุผลที่เชื่อม attacker capability, vulnerability, impact, control direction และ residual risk

Threat scenario และ asset	Implementation vulnerability	ผลกระทบที่เป็นไปได้	Control direction และ residual risk ที่ต้องติดตาม
Caller ส่ง payload ที่เปลี่ยน parser/query semantics เพื่อเข้าถึง payroll data	Concatenate input เข้า query, canonicalize ต่างกัน, validate หลัง sink	Disclosure, unauthorized state change และ evidence ambiguity	Structured parser, allowlist semantics, parameterized API, output encoding; business-logic injection และ alternate sinks ยังต้อง review/test
Maker แก้ payload ระหว่าง checker approval กับ execution	Read-check-write แยก transaction, mutable payload, approval ไม่ bind version	SoD bypass และ ledger integrity loss	Immutable version, conditional atomic commit, authoritative invariant; store/PEP common compromise ยังเป็น residual risk
ผู้โจมตี replay command หลัง timeout หรือ queue redelivery	ไม่มี idempotency scope, check อยู่ใน cache, duplicate side effect	จ่ายเงินซ้ำ, accounting mismatch, denial of service	Authoritative idempotency record กับ atomic transition; key collision/retention semantics ต้องกำหนดและทดสอบ
ผู้โจมตีขโมย session/token จาก log หรือ URL	Log raw bearer token, token type/audience ไม่ถูกตรวจ, fixation	Account/service impersonation และ privilege misuse	Redaction, safe storage, issuer/audience/type binding, rotation/revocation; endpoint compromise ยังอาจขโมย token ใน memory
Low-privilege user ทำให้ worker ใช้สิทธิ์แทนตน	API ส่ง caller-controlled resource ไป privileged helper โดยไม่ bind authority	Confused deputy และ cross-tenant access	Narrow capability, resource-scoped authorization ที่ PEP, workload identity; policy/attribute integrity เป็น dependency
Payload ขนาดเล็กกระตุ้นงานแพงหรือ retry fan-out	Unbounded parse/decompress/regex/queue, retry without budget	Availability loss และ resource starvation ข้าม tenant	Early bounds, per-scope quota, backpressure, deadlines, bounded retry; capacity exhaustion ระดับใหญ่ยังเป็น residual risk
Attacker ฝัง control characters หรือ secret ใน event	String-concatenated log, no minimization, weak evidence access	Log forging, disclosure, investigation failure	Structured event, encoding, field allowlist, SoD และ integrity controls; compromised emitter อาจยังสร้าง false event
Component ที่ reuse ส่ง malformed/hostile output หรือถูกเปลี่ยน	Blind trust, excessive privilege, floating version, hidden callback	Code execution, data leak, policy bypass หรือ common-mode failure	Pin approved version/input, wrapper validation, sandbox/least privilege, SCA/review; provenance/support risk ส่งบท 8
Contributor หรือ compromised build plugin แทรก hidden behavior	Weak review SoD, mutable build input, broad build identity, unreviewed script	Backdoor ใน artifact แม้ source หลักดูสะอาด	Protected branch/change review, isolated build, constrained plugin, artifact inspection; build platform compromise ยังต้องจัดการ
Error path เปิด stack trace หรือ fallback เป็น allow	Verbose external error, broad catch, control outage bypass	Information disclosure และ unauthorized action	Generic external response, protected detail, explicit fail-secure behavior; availability trade-off ต้องได้รับ authority
Cryptographic migration รองรับ weak fallback	Algorithm chosen from untrusted header, unauthenticated metadata, key reuse	Downgrade, forgery หรือ confidentiality loss	Policy-controlled allowlist, authenticated envelope, key separation, migration plan; legacy compatibility window เป็น residual risk
Unsafe native/processor interface เขียน memory ผิด	Missing bounds/lifetime check, safeguards disabled, privileged native code	Memory corruption, code execution และ TCB compromise	Memory-safe boundary, safe wrapper, compiler/linker/processor safeguards; logic flaws ไม่ถูกแก้โดย hardening
Feature flag, debug endpoint หรือ admin recovery route bypass PEP	Hidden alternate entry point และ configuration precedence ไม่ชัด	Complete-mediation failure และ accountability loss	Central PEP, inventory/review of all entry points, deny default, build/config gate; undocumented functionality ส่งบท 6 ตรวจต่อ

Injection เป็น boundary mismatch ไม่ใช่แค่ bad characters

Injection เกิดเมื่อ data ถูกตีความเป็น instruction เพราะสองฝั่งไม่ตกลง syntax และ semantics อย่างปลอดภัย การ block quote หรือ keyword บางตัวไม่ครอบคลุม alternate encoding, comment, nested grammar และ sink อื่น Control ที่ดีกว่าคือใช้ typed/ parameterized interface, context-specific encoding และ least-privileged target accountร่วมกัน

Injection ยังปรากฏใน template, expression language, command line, directory query, NoSQL operator, logging, header และ AI/tool call เมื่อตัว model output ถูกนำไปเกิด side effect สำหรับ AI-integrated flow ให้ถือ prompt/context/model output เป็น untrusted หรือ probabilistic input แล้วส่ง action ผ่าน deterministic schema, authorization และ side-effect PEP ตามหลักเดิม

Unsafe deserialization และ dynamic execution

Deserialization ที่สร้าง arbitrary object graph หรือเรียก constructor/hook อาจให้ attacker trigger code, allocate resource หรือแก้ state การตรวจ signature ของ blob พิสูจน์ origin/integrity ภายใต้ key assumptions แต่ไม่ทำให้ object type หรือ behavior ปลอดภัย ควรใช้ simple data schema, explicit type allowlist, bounds และ validation หลัง parse ก่อนใช้

Dynamic evaluation, reflection, plugin loading และ script extension ขยาย attack surface หาก requirement ไม่จำเป็นให้หลีกเลี่ยง หากจำเป็นให้จำกัด origin, capability, API surface, resource และ isolation พร้อมบันทึก lifecycle การ obfuscate string หรือ ซ่อน extension path ไม่ใช่ control ตาม open design

Memory, integer และ lifetime weaknesses

Buffer overflow, out-of-bounds access, use-after-free, double free, uninitialized memory, integer wrap/truncation และ type confusion สามารถเปลี่ยน data defect เป็น control-flow compromise การเลือก memory-safe language ลดบาง class อย่างมีนัยสำคัญ แต่ unsafe FFI, native library, logic race และ resource leak ยังอยู่

ในภาษาที่ต้องจัดการ memory เอง ให้ใช้ safe library/safe subset, bounds-checked API, explicit ownership, checked arithmetic, cleanup discipline และ toolchain safeguards พร้อม focused review การปิด compiler warning หรือ cast เพื่อให้ build ผ่านโดยไม่ พิสูจน์ precondition เปลี่ยน signal เป็น hidden risk

Authorization drift และ alternate paths

Authorization flaw มักไม่ใช่ไม่มี if role แต่เป็น decision ไม่ผูก resource, tenant, action, current state หรือ authoritative attributes หรือบังคับเฉพาะ UI/ gateway ขณะที่ batch, internal API และ recovery path เขียน state ได้ตรง

การรวม policy ช่วย consistency แต่ทำให้ policy service, cache และ identity source เป็น common dependency จึงต้องกำหนด freshness, timeout และ degraded behavior การ copy policy logic เข้าแต่ละ serviceลด central outage แต่เพิ่ม semantic drift Exam scenario มักให้เลือกคำตอบที่รักษา complete mediation และ explicit risk trade-off มากกว่าคำตอบที่สะดวกต่อ developer

Build-path และ component substitution threats

Source ที่ผ่าน review อาจไม่ใช่ artifact ที่ส่งมอบ หาก build ดึง floating dependency, รัน untrusted generator, ใช้ mutable container, include local file หรือเปิด plugin อิสระ Threat จึงครอบคลุม source repository, review decision, dependency resolver, toolchain, worker, cache, signing/attestation key และ artifact store

Hash ของ artifactช่วย identity/integrity comparison แต่ไม่บอกว่า input ดีหรือใคร อนุมัติ artifact นั้น Anti-tamper mechanism ต้อง bind artifact identity กับ approved build context และ protected key/identity ที่เหมาะสม ส่วน pedigree/provenance ของ supplier component ต้องวิเคราะห์ต่อในบท 8

Controls และแนวปฏิบัติที่ดี

Controls ที่ดีต้องอยู่ใกล้ authoritative decision, มี failure behavior ชัดเจน และ สร้าง evidence ที่ตาม version ได้ ส่วนนี้จัด control ตาม objective 5.3–5.6 พร้อม เหตุผลและ trade-off โดยไม่เสนอ checklist ใดเป็นคำตอบสากล

Control matrix สำหรับ implementation

ตารางต่อไปนี้ช่วยแยก placement, rationale, failure mode และ evidence ของ controls ที่มักประกอบกันใน implementation

Control	Placement และเหตุผล	Failure mode/trade-off	Implementation evidence ที่เหมาะสม
Schema/bounds validation	ที่ trust boundary ก่อนงานแพง และที่ domain transition เพื่อรักษา semantics	Duplicate validators drift; strict rejection อาจกระทบ compatibility	Versioned schema, validation function mapping, rejected-path review
Parameterized/typed sink	ใกล้ database/command/template sink เพื่อแยก data จาก instruction	Dynamic identifiers ยังต้อง allowlist; misuse API ยังเกิดได้	Data-flow trace, safe wrapper use, prohibited API finding status
Authoritative PEP/default deny	ทุก state-changing path ใกล้ protected resource	PEP/cache outage กระทบ availability; central compromise เป็น common mode	Route/path inventory, policy/config version, call-site and state transition mapping
Atomic invariant/unique constraint	ที่ authoritative store เพื่อปิด race/replay	Contention, latency และ distributed boundary อาจซับซ้อน	Transaction/constraint definition, concurrency design link, commit result mapping
Context-specific output encoding	ใกล้แต่ละ output sink หลัง logic	Wrong context/double encoding ทำให้ทั้ง bypass และ corruption	Template/encoder configuration, raw-output exception list, review record
Structured minimized events	จุด decision/commit และ protected evidence channel	Event sink failure, cost และ privacy exposure	Event schema, field allowlist/redaction, failure-path mapping
Session/token lifecycle	Issuer/verifier/PEP และ server-side state ตาม model	Revocation versus availability/latency, clock/key dependency	Verification policy, key reference, rotation/revocation code/config mapping
Resource bounds/backpressure	ก่อน allocation และทุก fan-out boundary	Tight bounds ปฏิเสธ legitimate workload; shared bounds cause noisy neighbor	Limit policy/config, per-scope accounting path, cancellation/cleanup review
Isolation/least privilege	Process/account/container/library wrapper ตาม blast radius	Operational complexity, performance และ shared-kernel assumptions	Permission/capability manifest, sandbox profile, denied-path evidence plan
Crypto wrapper/agility policy	Narrow service/library boundary เพื่อลด misuse	Wrapper compromise, migration complexity, downgrade risk	Approved policy reference, allowlist config, envelope/key-version mapping
SAST/manual review	Change/build gate ตาม risk	False results, reviewer fatigue และ ruleset drift	Tool/ruleset/version, triage links, reviewer/commit binding
SCA/component gate	Dependency resolution และ build graph	Advisory noise, identity mismatch, reachability uncertainty	Resolved dependency graph, component disposition, approved baseline diff
Build isolation/hardening	Source-to-artifact environment	Cache/toolchain compromise, reproducibility cost	Worker identity, immutable inputs, compiler flags, artifact manifest/digest

Authentication, authorization และ SoD controls

Authentication verifier ต้องกำหนด accepted credential type, issuer/origin, audience/purpose, assurance context, freshness และ failure semantics จากนั้นส่ง verified identity object ที่ caller แก้เองไม่ได้ให้ PEP Authorization ต้องใช้ verified subject พร้อม action, resource, context และ authoritative state ไม่อ่าน role จาก request body หรือเชื่อ client-side visibility

สำหรับ maker/checker implementation ให้บังคับสิ่งต่อไปนี้ใน atomic state transition

• maker_id และ checker_id ต้องเป็น verified immutable identities ที่ต่างกันสำหรับ transaction version เดียวกัน
• Approval ต้อง bind transaction identifier, immutable version หรือ canonical content identity และ authorization context ที่ design กำหนด
• การแก้ payload ต้องสร้าง version ใหม่และ invalidate approval เดิม ไม่ update approved row โดยคง version
• Execute path ต้อง recheck allowed state, effective authority/freshness และ idempotency ที่ authoritative PEP/ledger
• Admin/recovery path ต้องรักษา invariant หรือใช้ approved exceptional workflow กับ SoD, scope และ protected evidence ไม่เขียน ledger ตรง

การตรวจ SoD ที่ UI เพิ่ม usability แต่ไม่ใช่ authoritative control การตรวจที่ gateway และ serviceอาจเพิ่ม independent barriersเมื่อใช้ identities/state ต่างกัน แต่หากทั้งสองเชื่อ claim เดียวและ ledger ไม่ enforce ผลยังล้มได้จาก bypass path

Implementation controls สำหรับ data protection

เริ่มจาก data classification, purpose และ flow allocation จากบท 3–4 แล้วลดการรับ, copy และ retention ใน code path ใช้ field allowlist สำหรับ serialization, แยก privileged data access, tokenize เมื่อ downstream ไม่ต้องเห็นค่า, เข้ารหัสช่องทาง/ storage ตาม threat และควบคุม key แยกจาก ciphertext

Encryption ไม่แทน authorization หรือ minimization ผู้ที่มี decryption authority อาจ เปิดเผยข้อมูลได้ และ compromised application มักเห็น plaintext ระหว่างประมวลผล Controls จึงต้องประกอบกับ least privilege, isolation, query scope, output encoding, logging discipline และ protected evidence

Implementation controls สำหรับ code integrity และ malicious change

High-risk code เช่น authentication, policy, cryptography, deserialization, native interface, build script และ update path ต้องมี ownership/review rule และ SoD ตาม governance Change เล็กไม่เท่ากับ low risk หากแตะ common wrapper ที่ทุก service ใช้

Controls ที่ช่วยได้ประกอบด้วย protected branch/change approval, commit-to-review binding, verified author/workload identity, narrow build script capability, no unreviewed binary blob, generated-code input review, sensitive API diff alert และ artifact inspection อย่างไรก็ตาม colluding reviewers หรือ compromised platform ยัง เป็น residual risk จึงต้องดู independence และ protected evidence ไม่ใช่จำนวนลายเซ็น

Risk treatment เมื่อพบ weakness

Finding ไม่ใช่ risk treatment และการแก้ rule warning ไม่จำเป็นต้องปิด attack path ทีมต้อง enrich finding ด้วย affected asset/version, entry point, precondition, reachability, existing controls, impact, likelihood method, owner และ deadline/gate ตาม governance แล้วเลือก treatment

แผนภาพเน้นว่า developer หรือ scanner ไม่ยอมรับ residual business risk โดยปริยาย Risk owner หรือผู้มีอำนาจตาม governance ตัดสิน acceptance การ transfer/share ผ่าน contract หรือ service boundary ไม่ทำให้ risk หาย ต้องตรวจ coverage, dependency และ residual exposure ขององค์กร

Treatment ที่พบได้บ่อยมีรายละเอียดดังนี้

• Remediate/root-cause fix: เปลี่ยน code/config/component เพื่อลบ weakness และ update regression route เหมาะเมื่อแก้ได้โดยไม่ละเมิด requirement อื่น
• Avoid: ปิดหรือลบ capability/path/component ที่สร้าง risk ต้องตรวจว่ามี alternate path และ dependency ค้างหรือไม่
• Mitigate/compensate: เพิ่ม control ที่ลด likelihood/impact เมื่อแก้หลักไม่ได้ ต้องเทียบ coverage, independence และ failure mode ไม่ใช้ WAF หรือ sandbox เป็น blanket waiver
• Transfer/share: กำหนด responsibility ให้ service/insurer/supplier แต่ owner ยังติดตาม contractual/evidence gap; รายละเอียด supplier อยู่บท 8
• Accept: ใช้ exception ที่มี rationale, compensating control, residual risk, authority, expiry และ review trigger ไม่ใช่ suppress finding แบบถาวร
• Re-design: เมื่อ implementationเผยว่า control placement หรือ invariant ใช้ไม่ได้ ให้ย้อน design/requirements change control ไม่บิด code ให้ดูผ่าน gate

Severity จาก tool หรือ CVSS เป็น input หนึ่ง ไม่แทน business risk ตัวอย่าง library weakness ที่ unreachable ภายใต้ build configuration อาจมี current exposure ต่ำกว่า custom authorization bypass ที่ scannerไม่รู้จัก แต่ unreachable claim ต้องมี version-matched evidence และ re-evaluate เมื่อ call graph/config เปลี่ยน

Evaluate และ integrate components อย่างปลอดภัย

Component integration คือการเชื่อม trust assumptions สองฝั่ง ไม่ใช่เพียงทำให้ API compile ทีมต้องตรวจ component version/feature, runtime privilege, input/output, state, concurrency, error, update และ exit semantics เทียบกับ approved design

กระบวนการที่เหมาะสมมีลำดับดังนี้

1. ระบุ capability ที่ต้องใช้และตัด feature/plugin/transitive dependency ที่ไม่จำเป็น เพื่อลด attack surface และ TCB
2. ระบุ resolved component และ dependency graph ที่ build ใช้จริง ไม่อาศัยชื่อใน manifest อย่างเดียว และผูกกับ configuration/target platform
3. ตรวจ fitness กับ interface contract รวม schema, canonicalization, token/session, thread safety, timeout, retry, partial failure และ resource behavior
4. ประเมิน privilege กับ trust zone ว่า component อ่านไฟล์ network, environment, process, secret หรือ shared memory อะไรได้ และลดด้วย wrapper/isolation
5. ใช้ SCA, code/manual review และ targeted artifact inspection เพื่อค้นหา known weakness, unsafe API, unexpected behavior และ version conflict
6. ตัดสิน remediate, constrain, isolate, replace, avoid หรือ exception ตาม contextual risk พร้อม owner/expiry/evidence ไม่ auto-upgrade หรือ auto-suppress โดยไร้ review
7. Pin/lock approved resolution ตาม build model บันทึก component-to-artifact mapping และส่ง test cases สำหรับ failure, malicious output, downgrade และ incompatibility
8. ส่ง supplier pedigree, provenance, acquisition และ contractual questions ไปบท 8 โดยไม่ประกาศว่า SCA หรือ checksum ปิด supply-chain risk แล้ว

Systems integration และ trust contract

เมื่อเชื่อมระบบผ่าน API, message broker, file หรือ shared database ต้องตกลง identity, authorization, schema version, transaction/idempotency, time, error, retry และ evidence semantics หาก producer ถือ timeout ว่า “ไม่สำเร็จ” แต่ consumer commit แล้ว retry จะสร้าง duplicate หาก consumerตี missing field เป็น default allow ขณะที่ producerคิดว่า field required จะเกิด authorization gap

Adapter หรือ anti-corruption layer สามารถจำกัด external semantics และ validate ใกล้ boundary แต่เพิ่ม code/latency ที่ต้อง review การใช้ shared databaseลด integration work แต่ข้าม service PEP, รวม privilege และ coupling state transition จึงมักทำให้ complete mediation ยากขึ้น ต้องประเมินกับ architecture ไม่ตัดสินจาก convenience

Software Composition Analysis

Software Composition Analysis (SCA) ช่วยระบุ direct/transitive component, version, license metadata และ known weakness mapping ใน resolved dependency graph ตาม ความสามารถของเครื่องมือ ผลต้องผ่าน triage เพราะ package name/versionอาจไม่ตรง binary จริง, advisoryอาจไม่ applicable ต่อ feature/config และ reachability model อาจ ไม่เห็น reflection/native/runtime loading

SCA ที่ดีควรผูก finding กับ artifact target, dependency path, scope เช่น runtime/ build/test, enabled feature และ disposition ที่มี evidence อย่าลบ test/build component ออกจากการพิจารณาอัตโนมัติ เพราะ build script หรือ test toolอาจรันด้วย secret/network authority และแทรก artifact ได้ Supplier provenance, maintainer trust และ contract support ยังต้องวิเคราะห์ในบท 8

Secure build และ source-to-artifact integrity

Build process เปลี่ยน approved source กับ dependency/toolchain inputs เป็น artifact ดังนั้น worker, resolver, generator, compiler, linker, packager, cache และ signing identity เป็นส่วนหนึ่งของ attack surface แผนภาพนี้แสดง gate ที่แยกหลักฐานแต่ละชนิด

Build ที่ isolated ลด cross-job contamination และ credential theft แต่ isolation ต้อง ดู shared host/cache/network/administrator ไม่ใช่เพียงใช้ container Build identity ควรอ่านเฉพาะ approved inputsและเขียนเฉพาะ staging output ไม่มี long-lived production credential การ promotion หรือ deployment อยู่บท 7 ไม่ควรให้ build script deploy ตรงเพียงเพราะ pipelineทำได้

Compiler switches, warnings และ hardening

เปิด compiler/linker/runtime safeguards ตาม approved baseline และ target compatibility เช่น bounds/undefined-behavior diagnostics, stack protection, non-executable memory metadata, position-independent executable support, relocation/read-only protection, control-flow safeguard หรือ safe runtime check ที่ platformรองรับ รายชื่อจริงขึ้นกับ ภาษา, compiler, OS, processor และ version จึงต้องเก็บ resolved switches เป็น evidence แทน copy flag จาก checklist แบบไม่ตรวจผล

Warnings ต้องมี policy เช่น treat security-relevant categories เป็น build break, ห้ามเพิ่ม suppression โดยไม่มี rationale/owner และทบทวน baseline เมื่อ toolchain เปลี่ยน warnings as errors ทุกชนิดอาจสร้าง friction จนทีมปิด warning ทั้งชุด แต่การ ปล่อย warning ทั้งหมดผ่านทำให้ signal สูญ การจัด category/risk และ burn-down debt ตาม governanceสมดุลกว่า

Anti-tamper และ immutable artifact identity

Anti-tamper control อาจใช้ cryptographic digest, authenticated signature/MAC, verified packaging, code-signing identity, measured boot/loading หรือ runtime integrity check ตาม threat model จุดสำคัญคือ verifier ต้องมี trusted reference, key/policy และ freshness และต้องกำหนด behavior เมื่อ verification fail

Artifact signature พิสูจน์ว่า holder ของ signing authority อนุมัติ/สร้าง signature ต่อ bytes นั้นภายใต้ assumptions ไม่พิสูจน์ว่า source ปลอดภัย, reviewerถูกต้อง หรือ build environmentไม่ถูก compromise Signing key ที่ build jobทุกตัวอ่านได้ขยาย blast radius ควรแยก build จาก authorization/signing step ตาม SoD และ bind decision กับ immutable artifact identity

Reproducible/deterministic buildช่วยเปรียบเทียบ output จาก inputs ที่กำหนดและค้นหา ความแปรผัน แต่ต้องควบคุม toolchain, timestamps, locale, ordering, generated input และ environment จึงมี cost และไม่ได้พิสูจน์ว่า input ไม่มี malicious code

Build evidence และ gate semantics

Build record ควรผูก source commit, reviewed change, resolved dependencies, toolchain, configuration, worker/build identity, relevant analysis result, compiler warnings, artifact digest/manifest, exception และ timestamp ตาม assurance อย่าใส่ secret ลง evidence และอย่าถือว่าการมี SBOM หรือ attestation เท่ากับ artifact verified

Gate outcome ใช้ pass, conditional pass, fail หรือ exception required ตาม convention ของคู่มือ Missing scanner result เพราะ tool unavailable คือ evidence missing ไม่ใช่ pass Finding ที่ยืนยันแล้วคือ control/implementation issue ส่วน approved exception ต้องมี authority และ expiry การแยก state เหล่านี้ทำให้ metric ไม่เขียวจากการ suppress แบบไร้เหตุผล

การทำ implementation review แบบ risk-driven

Review ที่ลึกเริ่มจาก diff แต่ไม่หยุดที่ diff เพราะ shared wrapper, configuration, generated code และ transitive dependencyอาจเปลี่ยน effective behavior ใช้ review map ต่อไปนี้เพื่อรักษา breadth

• ตาม entry point ทุกชนิดไปยัง identity verification, PEP และ authoritative side effect รวม public, internal, batch, worker, admin, debug และ recovery path
• ตาม untrusted/derived data ผ่าน parse, canonicalization, validation, transformation ไปยัง query, template, command, log, file, network และ AI/tool-call sink
• ตาม privilege จาก caller ไป process/library/dependency และ resource เพื่อหา confused deputy, shared identity และ unnecessary capability
• ตาม state/version/lock/cache/queue เพื่อหา race, stale decision, replay, partial commit และ cleanup failure
• ตาม secret/key/token จาก injection ไป memory, child process, dump, log, error, artifact และ rotation/revocation route
• ตาม error/cancel/timeout/retry path ให้แน่ใจว่า fail secure, bounded และสร้าง protected evidence โดยไม่เปิดข้อมูลเกิน purpose
• เปรียบเทียบ code/config/build evidence กับ requirement/design version และส่ง uncertain behavior เป็น test route ไม่ประกาศ verified จาก review

Pseudo code

Pseudo code ต่อไปนี้แสดง state-changing request flow แบบ end-to-end โดยจงใจแยก size/parsing, canonicalization, validation, authentication, authorization, concurrency/idempotency, output encoding, logging และ error handling ตัวอย่างนี้ไม่ ผูกกับภาษา/framework และไม่ใช่ production-ready code

# PSEUDO CODE — version-bound maker/checker request flow; NOT production-ready

function approve_payroll(raw_request, transport_context):
    correlation = new_nonsecret_correlation_id()
    outcome = "internal_failure"
    subject_ref = "unknown"
    transaction_ref = "unknown"

    try:
        # 1. Bound resource cost before deep parsing.
        require transport_context.is_protected_channel
        require byte_length(raw_request.body) <= POLICY.max_approval_request_bytes
        require transport_context.deadline.is_valid_and_bounded

        # 2. Parse once, canonicalize to the versioned contract, then validate.
        envelope = STRICT_PARSER.parse_without_dynamic_types(raw_request.body)
        canonical = APPROVAL_SCHEMA.canonicalize(envelope)
        require APPROVAL_SCHEMA.validate(canonical)
        require canonical.only_contains([
            "transaction_id", "transaction_version", "approval_intent",
            "idempotency_key"
        ])
        transaction_ref = opaque_reference(canonical.transaction_id)

        # 3. Authenticate credential container; do not trust identity in body.
        verified_identity = IDENTITY_VERIFIER.verify(
            credential = transport_context.credential,
            expected_issuer = POLICY.identity_issuer,
            expected_audience = POLICY.approval_audience,
            expected_token_type = POLICY.workforce_token_type,
            freshness_rule = POLICY.identity_freshness
        )
        subject_ref = opaque_reference(verified_identity.subject)

        # 4. Start an authoritative transaction before policy/state decision.
        with LEDGER.begin_transaction(deadline = transport_context.deadline) as tx:
            current = tx.read_for_conditional_update(
                id = canonical.transaction_id
            )

            require current.exists
            require current.state == "Submitted"
            require constant_time_equal(
                current.immutable_version,
                canonical.transaction_version
            )

            # Complete mediation binds subject, action, resource, state, and version.
            decision = POLICY_PEP.authorize(
                subject = verified_identity,
                action = "payroll.approve",
                resource = current.resource_attributes,
                context = {
                    "maker_id": current.maker_id,
                    "checker_id": verified_identity.subject,
                    "transaction_version": current.immutable_version,
                    "policy_version": POLICY.required_policy_version
                },
                require_fresh_policy = true
            )
            require decision.is_allow
            require verified_identity.subject != current.maker_id

            # Idempotency is scoped and enforced in the same authoritative commit.
            operation_identity = HASH_APPROVED_FUNCTION(
                verified_identity.subject,
                "payroll.approve",
                current.id,
                current.immutable_version,
                canonical.idempotency_key
            )
            prior = tx.find_operation(operation_identity)

            if prior.exists:
                require prior.semantic_payload_hash == hash(canonical)
                outcome = "already_processed"
                tx.rollback_without_side_effect()
                return RESPONSE_ENCODER.for_context(
                    status = "already_processed",
                    transaction = opaque_reference(current.id)
                )

            # Conditional write closes TOCTOU; database invariant also enforces SoD.
            changed = tx.compare_version_and_transition(
                id = current.id,
                expected_version = current.immutable_version,
                expected_state = "Submitted",
                new_state = "Approved",
                checker_id = verified_identity.subject,
                policy_decision_ref = decision.protected_reference
            )
            require changed == 1
            tx.record_operation(operation_identity, hash(canonical))

            # Evidence event contains allowlisted fields, not payroll data or tokens.
            tx.enqueue_protected_event({
                "event_type": "payroll_approval_committed",
                "correlation": correlation,
                "subject_ref": subject_ref,
                "transaction_ref": transaction_ref,
                "transaction_version": current.immutable_version,
                "policy_decision_ref": decision.protected_reference,
                "outcome": "approved"
            })
            tx.commit_atomically()
            outcome = "approved"

        # 5. Encode for the actual output context; never reflect raw input.
        return RESPONSE_ENCODER.for_context(
            status = "approved",
            transaction = transaction_ref
        )

    catch InputOrParseError:
        outcome = "invalid_request"
        return GENERIC_CLIENT_ERROR.with_correlation(correlation)

    catch AuthenticationOrAuthorizationError:
        outcome = "denied"
        return GENERIC_DENIAL.with_correlation(correlation)

    catch StaleVersionOrConflict:
        outcome = "stale_or_conflict"
        return SAFE_CONFLICT_RESPONSE.with_correlation(correlation)

    catch ControlUnavailable:
        # Fail secure for state change; no automatic allow fallback.
        outcome = "security_control_unavailable"
        return SAFE_TEMPORARY_FAILURE.with_correlation(correlation)

    catch UnexpectedError as internal_error:
        outcome = "internal_failure"
        PROTECTED_DIAGNOSTICS.record_reference_only(
            correlation = correlation,
            error_class = allowlisted_class(internal_error)
        )
        return GENERIC_SERVER_ERROR.with_correlation(correlation)

    finally:
        # Structured/minimized attempt event; serializer prevents log injection.
        PROTECTED_AUDIT.emit_if_not_already_atomic({
            "event_type": "payroll_approval_attempt",
            "correlation": correlation,
            "subject_ref": subject_ref,
            "transaction_ref": transaction_ref,
            "outcome": outcome
        })
        release_bounded_resources()

จุดสำคัญของ pseudo code ไม่ใช่ syntax แต่คือ order และ atomic boundary การ parse/ validate มาก่อนงานแพง Authentication แยกจาก authorization PEP ใช้ state/version ปัจจุบัน SoD กับ idempotency ถูกบังคับใน transaction เดียว Output encoder ไม่รับ raw input และ evidence ลดข้อมูล Pseudo code ยังไม่รับประกันความถูกต้อง ต้องส่ง tests เรื่อง duplicate, stale version, parallel checker, policy outage, audit failure, malformed token และ rollback ไปบทที่ 6

ตัวอย่างหรือกรณีศึกษา

กรณีศึกษานี้ต่อยอด payroll maker/checker จากบทที่ 3–4 เพื่อให้เห็นว่า design allocation กลายเป็น code/config/build evidence อย่างไร Identifiers SR-PAY-001, SR-PAY-002, SR-DAT-004 และ SR-REC-008 เป็นเพียงตัวอย่างที่สร้างขึ้นสำหรับ คู่มือนี้ ไม่ใช่ official requirements

บริบทและ implementation baseline

Design กำหนดให้ maker submit immutable payroll transaction version, checker ที่เป็น คนละ identity approve version เดียวกัน, worker execute ผ่าน authoritative PEP และ ledger commit แบบ atomic/idempotent Critical transition ต้องสร้าง protected evidence และ raw Restricted payroll fields ต้องไม่ออกไปใน log

ทีมเลือก typed service runtime, relational ledger, command queue และ policy service จาก approved architecture baseline งาน implementation เริ่มจาก mapping ดังนี้

Requirement/design allocation	Implementation decision	Evidence ที่สร้างในบทนี้	Verification ที่ส่งต่อ
SR-PAY-001: maker/checker ต่างกันบน immutable version	Ledger conditional transition และ constraint ตรวจ identity/version; edit สร้าง version ใหม่	Migration/config diff, transaction function, code review bound to commit	Parallel approval, edit-after-approval, stale version และ direct-write negative tests
SR-PAY-002: complete mediation	Shared policy client ที่ fail secure และ ledger account ไม่เปิด direct write ให้ gateway/batch	Entry-point inventory, workload permission config, call graph/review	Public/internal/batch/admin/recovery path authorization tests
SR-DAT-004: boundary และ log minimization	Field allowlist, tokenized employee reference, structured event serializer	Serialization schema, prohibited-field check, event schema	Output-context, log injection, secret/Restricted-data leak tests
SR-REC-008: protected evidence	Transactional outbox event bind actor/action/version/outcome; separate evidence writer identity	Event producer code/config และ failure mapping	Tamper, duplicate, ordering, sink outage และ reconciliation tests

SRTM เปลี่ยน status ของรายการเหล่านี้จาก allocated เป็น implemented เฉพาะ version ที่ evidence ชี้ถึง ไม่มีรายการใดถูกตั้งเป็น verified เพราะ test execution และ result analysis อยู่บทที่ 6

Finding 1: UI และ gateway ตรวจ SoD แต่ worker bypass ได้

Manual review ตาม alternate entry point พบ batch recovery worker รับ command ที่มี checker_id ใน payload แล้วเขียน ledger ด้วย shared service credential โดยไม่เรียก PEP SAST ไม่แจ้งเพราะ code ไม่มี unsafe API และ type ถูกต้อง แต่ semantic invariant ถูกละเมิด นี่คือ implementation control failure ที่เปิด confused deputy path

ทีมไม่แก้ด้วยการเพิ่ม if maker != checker ที่ workerจาก payload เพราะ identity ยังเป็น caller-controlled แต่เปลี่ยน worker ให้ใช้ scoped workload identity เรียก authoritative PEP, อ่าน maker/version จาก ledger และใช้ conditional transition Permission ของ shared credential ถูก revoke พร้อมเพิ่ม recovery-path review/test

Residual risk คือ policy service/ledger administrator อาจแก้ทั้ง policy และ state ทีมจึงคง SoD ของ administration กับ protected evidence ตาม architecture และส่ง runtime monitoring/incident controls ไปบทที่ 7

Finding 2: Race ระหว่าง approval สอง request

Code เดิมอ่าน state Submitted, ตรวจ checker และ update เป็น Approved แยกคำสั่ง เมื่อ checker สองคนส่งพร้อมกัน ทั้งคู่ผ่าน check และ event สองรายการอ้างว่า approve สำเร็จ แม้ final row มี checker เพียงคนเดียว นี่เป็น TOCTOU และ evidence integrity problem ไม่ใช่แค่ duplicate UI message

ทีมใช้ conditional update WHERE state = Submitted AND version = expected และตรวจ affected row ใน transaction เดียว พร้อม unique operation identity ที่ผูก subject, action, transaction/version และ idempotency key Loser ได้ safe conflict ไม่ retry blind Build reviewบังคับ warning/error handling ของ ignored row-count result

ทีมส่ง test cases เรื่อง simultaneous checker, timeout before/after commit, queue redelivery และ idempotency-key reuse ต่าง payload ไปบทที่ 6 เพราะ code reviewเพียง อย่างเดียวยืนยัน scheduler/interleaving coverage ไม่ได้

Finding 3: Logging แก้ incident ง่ายแต่เปิด payroll data

Developer เพิ่ม request body และ bearer token ลง debug log เพื่อวิเคราะห์ timeout SAST secret ruleพบ token patternบางส่วน แต่ custom payroll fieldsไม่ถูก flag การ block log ทั้งหมดจะลด operational evidence ขณะที่เก็บ raw payloadละเมิด minimization และเพิ่ม disclosure risk

ทีมแทนด้วย structured event ที่มี opaque employee/transaction reference, approved field allowlist, decision/result, version และ correlation Token กับ payroll amount ถูกปฏิเสธที่ serializer boundary ไม่ใช่พึ่ง reviewerจำเอง Diagnostic detailเก็บเป็น protected reference ที่ access แยก และ runtime storage/retention ไปบท 7

Finding 4: Component upgrade ปิด advisory แต่เปลี่ยน token semantics

SCA พบ known weakness ใน token library ทีมทดลอง version ใหม่ซึ่งปิด weakness แต่ default verifier ยอม token type หลายชนิดและเปลี่ยน clock-skew behavior การ auto- upgrade จึงอาจสร้าง type confusion/freshness regression แม้ dashboardกลายเป็นเขียว

ทีม pin candidate version, ปิด algorithm/token types ที่ไม่ต้องใช้ผ่าน wrapper, กำหนด issuer/audience/type/freshness explicit และทำ compatibility reviewกับ approved interface contract จากนั้นส่ง negative token/downgrade/expiry cases ไปบท 6 Supplier support/provenance ของ version ถูกส่งต่อบท 8

Finding 5: Build warning ถูก suppress เพื่อเร่ง release

Compiler แจ้ง integer conversion ใน parser ที่คำนวณ decompressed buffer Developer เพิ่ม cast และ suppression โดยไม่พิสูจน์ range ทำให้ warningหายแต่ weaknessยังอยู่ Build gate จึงจัดเป็น fail สำหรับ affected parser ไม่ใช่ accepted residual risk

ทีมเปลี่ยนเป็น checked arithmetic, bound compressed/decompressed size ก่อน allocation และเพิ่ม explicit error path Suppression policyบังคับ owner/rationale/expiryสำหรับ กรณีที่แก้ไม่ได้ Risk acceptanceต้องผ่าน risk ownerตาม governance ไม่ใช่ developer กด ignore จากนั้น build recordเก็บ resolved safeguards/warnings และ artifact digest

Case outcome และ downstream handoff

หลังแก้ ทีมมี implementation evidence ครบตาม version ของ design ได้แก่ code/config commit, ledger constraint, workload permission, event schema, dependency lock, analysis dispositions, build inputs/safeguards และ artifact identity Control gate ให้ conditional pass เพื่อส่ง artifactไป verification โดยมี explicit test obligations ไม่ใช่ production release approval

บทที่ 6 ต้องทดสอบ positive/negative/failure/concurrency/replay และ undocumented functionality บทที่ 7 ต้องดู production configuration, secret/key delivery, telemetry, incident, patch และ runtime protection ส่วนบทที่ 8 ต้องตรวจ supplier provenance, acquisition และ contractual obligations ของ component/toolchain

Exam tips

คำถามเชิงสถานการณ์มักวัดว่าคุณแยก phase, authority และ evidence ได้หรือไม่ ใช้หลัก ต่อไปนี้เพื่อหา “คำตอบที่ดีที่สุด” ตาม risk และ lifecycle context

• เมื่อ design invariant ชัดแล้ว ให้เลือก implementation ที่ enforce ใกล้ authoritative state transition และครอบคลุม alternate paths มากกว่าการตรวจ UI
• แยก validation, sanitization และ output encoding Validationตรวจ contract, sanitizationเปลี่ยนข้อมูลใน contextหนึ่ง และ encodingป้องกัน interpretationที่ sink
• Parameterized interface แยก data จาก command ดีกว่า blacklist bad characters และ least-privileged target accountยังจำเป็นเป็น defense in depth
• Authentication พิสูจน์ identity claim; authorization ตัดสิน action/resource/context อย่าเลือก “authenticated แล้วอนุญาต” หาก resource-level checkหาย
• Race/TOCTOU ต้องแก้ด้วย atomic authoritative invariant หรือ concurrency protocol ที่ถูก scope ไม่ใช่เพิ่ม check เดิมอีกครั้งนอก transaction
• SAST/SCA/compiler warningเป็น inputs Findingไม่เท่ากับ exploitability, risk, treatment หรือ verification แต่การไม่มี findingก็ไม่พิสูจน์ absence
• CWE/OWASP/SANS-oriented listช่วย taxonomy/focus ไม่แทน threat model หรือ business risk assessment
• Risk acceptanceเป็นของ risk ownerหรือ authorityตาม governance Developer, reviewer, scanner และ testerให้ evidence แต่ไม่รับ residual business riskโดยปริยาย
• Reuse ลด custom codeแต่เพิ่ม dependency/TCB ได้ ต้องตรวจ fitness, privilege, configuration, failure และ lifecycle ก่อน integration
• Secure buildต้องคุ้มครอง source-to-artifact path Hash/signatureยืนยัน bytes/origin บางส่วนภายใต้ key assumptions ไม่พิสูจน์ว่า codeปลอดภัย
• ถ้า tool unavailable ให้จัด evidence missing ตาม gate ไม่ตีความเป็น pass และถ้า requirement applicableถูกเบี่ยงต้องใช้ exceptionที่มี authority/expiry
• implemented หมายถึงมี versioned code/config/build evidence ส่วน verified ต้องรอผลตาม test strategy ในบท 6

Common pitfalls

ข้อผิดพลาดต่อไปนี้เกิดจากการจำชื่อ control โดยไม่ตรวจ semantics หรือ placement แต่ละข้อควรย้อนกลับไปถามว่า asset, threat, invariant, authority และ evidenceคืออะไร

• ถือว่า validationทำให้ input trusted สำหรับทุก sink แล้วใช้ค่าเดียวกันใน SQL, HTML, shell และ log โดยไม่ใช้ context-specific control
• ใช้ sanitizationกับ identifier/amountจนค่าถูกแก้เงียบ ๆ และ business integrityเสีย แทนการ reject requestที่ไม่ตรง contract
• Encode ก่อน business processingแล้ว decode/re-encodeหลายชั้น ทำให้ canonicalization ambiguity และ double-encoding defect
• ตรวจ roleที่ controllerแต่ข้าม object/tenant/state/version หรือไม่ตรวจ worker, batch, admin และ recovery path
• เชื่อ queueว่า exactly once หรือใช้ idempotency keyใน cacheคนละ transactionกับ side effect ทำให้ timeout/replayจ่ายซ้ำได้
• Catch exceptionทั้งหมดแล้วคืน success หรือ allowเมื่อ policy serviceล่ม ซึ่งแลก integrityกับ availabilityโดยไม่มี authorized decision
• Log raw request/token/secret เพื่อ debugging หรือ redactionด้วย regexหลัง string ถูกสร้างแล้วจน copyหลุดไป sinkอื่น
• ฝัง secretใน source/config example/build argument หรือรวม shared credentialเพื่อลด operational effort ทำให้ blast radiusและaccountabilityแย่ลง
• เรียก component “trusted” เพราะเขียนเองหรือ vendorมีชื่อเสียง โดยไม่ตรวจ output, privilege, version, failure และ transitive behavior
• ใช้ SCA advisory severityเป็น business riskทันที หรือ suppressเพราะ pathดู unreachableโดยไม่มี version/config evidence
• เปิด auto-upgradeเพื่อปิด vulnerabilityโดยไม่ตรวจ compatibility, changed defaults, token/crypto semantics และ test obligation
• ใช้ containerเป็น isolation conclusionโดยไม่ดู shared kernel, admin, cache, secret, identity และ network capability
• สร้าง cryptographic primitiveเอง หรือรองรับ algorithm fallbackกว้างเพื่อ “agility” จนเกิด downgrade
• Copy compiler flagsจาก checklistโดยไม่ตรวจ target/toolchain หรือปิด warningทั้งชุด เพราะ legacy codeมี debt
• เซ็น artifactแล้วประกาศ secureโดยไม่ bind approved source, dependencies, toolchain, review และ protected signing authority
• เปลี่ยน SRTMเป็น verified หลัง code reviewหรือ build pass ทั้งที่ negative/failure behaviorยังไม่ถูกทดสอบ

ข้อฝึกทบทวน

คำถามต่อไปนี้เป็นข้อฝึกที่สร้างขึ้นเองเพื่อทบทวนแนวคิด ไม่ใช่ข้อสอบจริงของ ISC2 เลือกคำตอบที่ดีที่สุดหนึ่งข้อ เว้นแต่โจทย์ระบุเป็นอย่างอื่น

ข้อ 1

Payroll API ตรวจว่า callerมี role checker ที่ UI และ gateway แต่ internal worker เขียน ledgerได้โดยใช้ shared credential วิธีแก้ใดดีที่สุด

A. ซ่อน worker endpointจากเอกสาร API

B. เพิ่ม validationว่า checker_id ใน messageไม่เท่ากับ maker_id

C. ให้ทุก state-changing pathผ่าน authoritative PEP และ ledgerบังคับ identity/ version invariantแบบ atomicด้วย scoped workload identity

D. เพิ่ม SAST ruleหาคำว่า checker

ข้อ 2

ทีมต้องป้องกัน SQL injection สำหรับ queryที่รับค่าจากผู้ใช้ แนวทางใดดีที่สุด

A. Blacklist quoteและคำว่า SELECT

B. HTML-encodeค่าก่อนต่อ SQL string

C. ใช้ parameterized query, allowlistเฉพาะ dynamic identifiersที่จำเป็น และใช้ database privilegeขั้นต่ำ

D. Encrypt request bodyก่อนส่งเข้า query builder

ข้อ 3

Workerสองตัวอ่านข้อความเดียวกันและทั้งคู่จ่ายเงินเพราะ timeoutทำให้ queue redeliver Controlใดปิด riskหลักได้ดีที่สุด

A. เพิ่ม random delayก่อน workerทำงาน

B. เก็บ idempotency keyใน memoryของแต่ละ worker

C. ทำ operation identityที่ scopeถูกต้องและบังคับ duplicate checkกับ side effectใน authoritative atomic transaction

D. ตั้ง queueให้ส่ง exactly onceแล้วไม่ต้องเปลี่ยน consumer

ข้อ 4

SCAรายงาน library severityสูง แต่ featureที่มี weaknessถูกปิดใน resolved build ทีม ควรทำสิ่งใดต่อเป็นอันดับแรก

A. ปิด findingถาวรเพราะ featureไม่เปิด

B. ยอมรับ riskโดย developerเพื่อให้ buildผ่าน

C. Validate component/version/config/reachability, ประเมิน contextual risk และ บันทึก treatment/evidenceกับ triggerเมื่อ configurationเปลี่ยน

D. ลบ SCAออกเพราะเกิด false positive

ข้อ 5

ข้อใดอธิบาย cryptographic agilityได้ถูกต้องที่สุด

A. ยอมรับ algorithmจาก token headerทุกแบบเพื่อ compatibility

B. แยก crypto policyผ่าน narrow interface รองรับ controlled migrationด้วย authenticated metadataและป้องกัน downgrade

C. เขียน cipherเองเพื่อเปลี่ยน algorithmได้เร็ว

D. ใช้ keyเดียวทุก algorithmเพื่อลด migration complexity

ข้อ 6

Build scannerไม่ทำงานเพราะ service unavailable แต่ deadlineใกล้ถึงแล้ว Gate state ใดแม่นยำที่สุดก่อนมี authorityตัดสินเพิ่มเติม

A. Pass เพราะไม่พบ finding

B. Conditional passโดย developerคนเดียว

C. Evidence missing หรือ exception requiredตาม break/build criteria

D. Verified เพราะ sourceผ่าน review

ข้อ 7

ข้อใดแยก secure loggingจาก protected evidenceได้ดีที่สุด

A. Logปริมาณมากที่สุดย่อมสร้าง accountabilityสูงสุด

B. Protected evidenceต้องรักษา attribution, integrity, time และ accessตาม assurance พร้อม minimization ขณะที่ debug logอาจไม่มีคุณสมบัติเหล่านี้

C. Encrypt logแล้วทุก eventจะเป็นความจริง

D. ห้าม log security eventเพื่อป้องกัน privacy risk

ข้อ 8

ทีมพบว่าค่า transaction thresholdใน approved requirementทำไม่ได้กับ selected component Implementerควรทำอย่างไร

A. ลด thresholdใน codeให้ระบบทำงานได้และแก้เอกสารภายหลัง

B. เพิ่ม commentว่า known limitationแล้วตั้ง status implemented

C. เปิด requirements/design change control หรือ exceptionตาม governance พร้อม impact/residual risk ไม่ลด semantic scopeเงียบ ๆ

D. ให้ SASTตัดสิน acceptance

ข้อ 9

ข้อใดเป็นตัวอย่าง declarativeและimperative securityที่ประกอบกันอย่างเหมาะสม

A. Route annotationบังคับ authentication และ service codeเรียก PEPด้วย subject, action, resource, contextก่อน atomic state transition

B. UIซ่อนปุ่มและ commentใน codeบอกว่าห้าม unauthorized user

C. Middleware allowทุก requestเมื่อ policy service timeoutและ serviceไม่ตรวจซ้ำ

D. Annotationกับ codeตรวจ roleจาก request bodyเดียวกัน

ข้อ 10

ทีมเซ็น artifactด้วย protected keyหลัง build ข้อสรุปใดถูกต้องที่สุด

A. Signatureพิสูจน์ว่า sourceไม่มี malicious code

B. Signatureพิสูจน์ว่า artifactผ่าน testingทุก attack path

C. Signatureช่วย bind bytesกับ signing authorityภายใต้ key/policy assumptions แต่ ต้องมี evidenceอื่นสำหรับ source review, build integrity, testing และ provenance

D. Signatureทำให้ไม่ต้องใช้ immutable artifact identity

ข้อ 11

การใช้ containerเพื่อ isolate parserที่รับ untrusted documentควรประเมินอะไรเพิ่มเติม เป็นอันดับสำคัญ

A. ชื่อ container imageสั้นหรือไม่

B. Shared kernel, capabilities, filesystem/network, identity, resource bounds และ escape/common dependencies

C. จำนวนไฟล์ sourceใน parser

D. UI themeของ service

ข้อ 12

หลัง code reviewและ secure buildผ่าน SRTM statusใดเหมาะสมที่สุดก่อน security test รันจริง

A. Allocated เท่านั้น เพราะ codeไม่มีค่าเป็น evidence

B. Implemented พร้อม version-matched evidenceและ planned verification route

C. Verified เพราะ compilerไม่มี warning

D. Accepted riskโดยอัตโนมัติ

เฉลยข้อฝึกทบทวน

เฉลยต่อไปนี้อธิบายทั้งเหตุผลของคำตอบที่ถูกและเหตุผลที่ตัวเลือกสำคัญอื่นไม่เหมาะ เป้าหมายคือฝึก decision logic ไม่ใช่จำตัวอักษรคำตอบ

เฉลยข้อ 1: C

ข้อ C รักษา complete mediation, verified identity, immutable version และ atomic invariantที่ authoritative boundary ครอบคลุม worker path ข้อ Bยังเชื่อ fieldใน messageและไม่ปิด shared-credential confused deputy ข้อ Aเป็น obscurity และข้อ Dช่วย ค้น patternได้แต่ไม่ implement control

เฉลยข้อ 2: C

ข้อ C แยก dataจาก query grammarด้วย parameterized API จำกัด identifierที่ parameter ไม่ได้ และลด impactด้วย least privilege Blacklistในข้อ Aไม่ครอบคลุม grammar/ encoding ข้อ Bใช้ encoderผิด context และข้อ D encryptionไม่หยุด serverตี plaintext เป็นคำสั่ง

เฉลยข้อ 3: C

ข้อ Cทำ duplicate decisionกับ side effectใน atomic authoritative boundary จึงรับ timeout/redeliveryได้ ข้อ Bมี stateแยกต่อ workerและหายเมื่อ restart ข้อ Aไม่สร้าง correctness และข้อ Dไม่ควรเชื่อ delivery guaranteeแทน idempotent consumer/ledger

เฉลยข้อ 4: C

ข้อ Cแยก tool severityจาก contextual riskและทำ unreachable claimให้มี evidence/ review trigger ข้อ Aปิดถาวรโดยไม่รองรับ config change ข้อ Bให้ authorityผิด role และ ข้อ Dทิ้ง detection sourceเพราะ findingหนึ่งต้อง triage

เฉลยข้อ 5: B

ข้อ Bรองรับการเปลี่ยนอย่างมี policy, integrityและ downgrade protection ข้อ Aเปิด attacker-chosen downgrade ข้อ Cละเมิดหลักใช้ reviewed primitive และข้อ D key reuse ทำลาย separationและเพิ่ม blast radius

เฉลยข้อ 6: C

เครื่องมือไม่พร้อมหมายถึงหลักฐานขาด ไม่ใช่ไม่มี weakness Gateต้องใช้ criteriaและ authorityเพื่อหยุดหรือ exception ข้อ Aตี absence of evidenceเป็น evidence of absence ข้อ Bให้ developerตัดสินลำพัง และข้อ Dสับสน review/buildกับ verification

เฉลยข้อ 7: B

ข้อ Bระบุคุณสมบัติของ protected evidenceและ minimizationครบ ข้อ Aเพิ่ม disclosure/ noiseไม่เท่ากับ accountability ข้อ C encryptionไม่รับประกัน truthของ emitter และข้อ Dละทิ้ง detection/accountabilityแทนการออกแบบ field/accessที่เหมาะสม

เฉลยข้อ 8: C

ข้อ Cรักษา authorityและsemantic traceabilityเมื่อ implementationไม่ตอบ approved requirement ข้อ A/Bสร้าง silent scope reduction ส่วนข้อ Dให้ scannerทำ decisionที่ ต้องอาศัย business/governance authority

เฉลยข้อ 9: A

ข้อ Aใช้ declarative ruleสำหรับ consistent coarse gateและ imperative policy decision สำหรับ resource/contextใกล้ transition ข้อ Bไม่ใช่ authoritative enforcement ข้อ C fail open และข้อ Dทำสองชั้นพึ่ง untrusted claimเดียวจึงไม่เพิ่ม assuranceที่แท้จริง

เฉลยข้อ 10: C

ข้อ Cจำกัด claimของ signatureอย่างถูกต้อง Signatureไม่พิสูจน์ source intent, review, build environment, test resultหรือ supplier provenance จึงทำให้ข้อ A/Bผิด ข้อ Dผิดเพราะ verifierยังต้องระบุ immutable bytesที่จะตรวจ

เฉลยข้อ 11: B

ข้อ Bตรวจ effective isolationและcommon dependenciesที่กำหนด blast radius ชื่อ image, source countและ UIไม่ตอบว่า parserเข้าถึง resourceหรือ escape boundaryได้ อย่างไร

เฉลยข้อ 12: B

ข้อ Bสะท้อนว่ามี implementation evidenceแต่ยังรอ verification ข้อ Aลดค่าของ versioned code/config/build evidence ข้อ Cใช้ warning absenceแทน security test และ ข้อ Dไม่มีเหตุผลหรือ authorityสำหรับ automatic acceptance

สรุปบท

Secure Software Implementation คือการรักษา requirementและdesign semanticsใน code, configuration, componentและ build path แล้วสร้าง evidenceที่ traceกลับ versionได้ แก่นสำคัญมีดังนี้

• แยก data, identity, authority, state และ output context ตลอด request-to-commit flow; validationไม่แทน authorizationและ encoding
• บังคับ complete mediation, SoD, immutable version, replay/idempotencyและ concurrency invariantใกล้ authoritative state transitionแบบ atomic
• จัดการ error, session/token, resource, logging, credential, tokenization, isolation, cryptographyและprocessor safeguardsตาม explicit threat/failure model
• ใช้ SAST, manual review, compiler analysis, SCAและtaxonomyอย่าง CWE/OWASP/SANS เป็น complementary evidence ไม่ใช้ tool resultแทน contextual riskหรือ assurance
• Treat findingด้วย avoid, remediate, mitigate, transfer/share, acceptหรือ re-design ภายใต้ authority, expiry, residual riskและverification route
• Integrate componentด้วย trust contract, least privilege, failure/concurrency semanticsและresolved dependency evidence พร้อมส่ง provenanceไปบท 8
• ป้องกัน source-to-artifact pathด้วย isolated build, least-privileged identity, compiler/linker safeguards, warning policy, anti-tamperและimmutable artifact identity
• เติม SRTMเป็น implemented เมื่อมี version-matched evidence และไม่ใช้คำว่า verified จนบทที่ 6ยืนยัน behavior

เชื่อมโยงไปยังบทถัดไป

บทที่ 6: Secure Software Testing รับ handoffจากบทนี้ ในรูป implementation version, artifact identity, SRTM status implemented, finding dispositions, residual-risk assumptions และ planned evidence routes โดยต้องแปลงเป็น security test strategy/casesที่ครอบคลุม positive, negative, boundary, failure, concurrency, replay, recoveryและ undocumented functionality

บทที่ 6ต้องยืนยันโดยเฉพาะ maker/checker same-version SoD, all-path complete mediation, atomic idempotency, stale policy/session/token, malformed inputและ output contexts, resource exhaustion, log/evidence minimization, component failure/ incompatibility, compiler/build safeguardsและ artifact-to-test binding การผ่าน SAST, reviewหรือ build gateในบทนี้ไม่ใช่ substituteสำหรับ verification/validation

เรื่อง production installation, configuration drift, secret/key delivery, continuous monitoring, incident response, patchingและ runtime protectionยังคงส่งให้บทที่ 7 ส่วน supplier pedigree/provenance, acquisitionและ contractual evidenceยังคงส่งให้บทที่ 8 เพื่อรักษา Domain boundariesและไม่ประกาศ assuranceเกินหลักฐานที่มี