บทที่ 6: Secure Software Testing

Secure Software Testing เปลี่ยนคำกล่าวว่า “เราเขียน control แล้ว” ให้เป็นหลักฐานว่า work product รุ่นที่ระบุทำงานตรง specification และตอบ risk scenario ที่ตั้งใจจริง บทนี้จึงไม่ได้สอนเพียงการใช้ scanner แต่สอนการออกแบบ assurance argument ตั้งแต่ strategy, test case, environment, data, evidence, finding triage จนถึงการตัดสินใจที่ control gate โดยรักษาสายจาก requirement และ threat model ไปยัง immutable build artifact ที่ทดสอบ

ขอบเขต Domain นี้เริ่มเมื่อทีมกำหนดว่าจะทดสอบอะไร ด้วยเหตุผลใด ภายใต้สภาพแวดล้อม และอำนาจใด แล้วจบเมื่อผลทดสอบถูกวิเคราะห์ จัดประเภท ติดตาม และส่งเป็น evidence ให้ผู้มีอำนาจตัดสินใจ บทนี้ไม่อนุมัติ production operation ไม่บริหาร runtime incident และไม่สรุป supplier provenance รายละเอียดเหล่านั้นอยู่ใน บทที่ 7 และ บทที่ 8 ตามลำดับ

[!IMPORTANT] บทนี้เป็นคู่มือเตรียมสอบที่จัดทำขึ้นเอง ไม่ใช่ official ISC2 material และไม่มี exam dump ตัวอย่างและข้อฝึกทั้งหมดสร้างขึ้นเพื่ออธิบายวิธีคิดเท่านั้น

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

เมื่อจบบทนี้ คุณต้องแยกการค้นหา weakness ออกจากการตัดสิน business risk และเลือก หลักฐานให้เหมาะกับคำถามที่ต้องตอบได้ Mapping ต่อไปนี้ยึดหมายเลข objective จาก master outline ของคู่มือนี้

Objective	สิ่งที่ต้องอธิบายและประยุกต์ใช้ได้	หลักฐานสำคัญ
6.1 Develop a security testing strategy and plan	กำหนด scope, standard, functional/non-functional coverage, known/unknown environment, test harness และช่องทาง bug bounty	Approved plan, environment manifest, entry/exit criteria, role และ schedule
6.2 Develop security test cases	สร้าง positive, negative, boundary, misuse/abuse, attack-surface, failure และ adversarial cases ด้วยเทคนิคที่เหมาะสม	Versioned test cases, oracle, seed/corpus, execution result และ coverage rationale
6.3 Verify and validate documentation	ตรวจความถูกต้อง ความครบ ความใช้ได้ และความสอดคล้องของ security documentation กับ behavior	Review record, trace links, exercised procedure และ discrepancy
6.4 Identify undocumented functionality	ค้นหา hidden, debug, dormant, alternate, legacy และ unintended interfaces หรือ behavior	Attack-surface delta, route/binary/runtime comparison และ disposition
6.5 Analyze security implications of test results	แปลผลจาก observation เป็น finding, exploit scenario, impact, priority และ gate outcome	Reproduction evidence, contextual risk analysis, owner และ build-break decision
6.6 Classify and track security errors	แยก defect, error, weakness และ vulnerability พร้อม deduplicate, assign, remediate และ retest	Defect record, taxonomy, severity input, SLA/expiry และ closure evidence
6.7 Secure test data	สร้าง ใช้ แยก ปกป้อง และทำลาย test data ตาม classification, purpose และ lineage	Data inventory, authorization, transformation/synthetic method, access log และ disposition
6.8 Perform verification and validation testing	เลือก independent/internal V&V, integration และ acceptance evidence ให้ตอบทั้ง specification และ stakeholder need	Independent result, acceptance record, traceability และ residual-risk decision

น้ำหนัก Domain ในข้อสอบไม่ใช่เหตุผลให้แจก effort เท่ากันทุกระบบ ระบบที่มี attack surface, impact, novelty หรือ uncertainty สูงต้องได้รับ depth และ independence สูงกว่า แม้จำนวน requirement จะน้อยกว่า

แนวคิดหลัก

หัวใจของ testing คือการตั้งคำถามที่ตรวจได้ ระบุ oracle ที่ตัดสินผล และรักษา provenance ของ subject under test ไม่ใช่การรวบรวมรายงานเครื่องมือจำนวนมาก

Verification, validation และ assurance claim

Verification ถามว่า “สร้างสิ่งนั้นถูกต้องตามแบบหรือไม่” จึงเทียบ work product กับ approved specification ตัวอย่างเช่น API ต้องปฏิเสธผู้อนุมัติที่เป็น maker ของรายการ รุ่นเดียวกัน ส่วน Validation ถามว่า “สร้างสิ่งที่ถูกต้องต่อความต้องการหรือไม่” จึง ประเมินว่าสิ่งที่ระบุและสร้างขึ้นตอบ stakeholder workflow, misuse scenario และ operational context จริงหรือไม่

ความต่างนี้มีผลต่อ test oracle อย่างชัดเจน:

• Verification oracle มาจาก requirement, interface contract, invariant, design allocation หรือ approved standard ที่ applicable
• Validation oracle มาจาก authorized user need, business outcome, abuse/misuse scenario และ representative operational use
• ระบบอาจผ่าน verification แต่ไม่ผ่าน validation หากสร้างตาม specification ที่ผิด หรือไม่ครบ เช่น ห้าม maker approve ผ่านหน้าเว็บ แต่ลืม batch API
• ระบบอาจดูตอบโจทย์ผู้ใช้ แต่ไม่ผ่าน verification หาก behavior อาศัย undocumented exception หรือไม่ตรงข้อกำหนดที่อนุมัติ

Diagram ต่อไปแสดงวงจรหลักฐานจาก artifact ไปสู่ gate โดยแยก observation, finding และ risk decision เป็นคนละสถานะ

แผนภาพนี้เตือนว่า test pass พิสูจน์ได้เพียง claim ใน scope, version, environment และ oracle ที่ระบุ ส่วน test failure เป็น observation ก่อน ต้องตรวจ repeatability, false positive และผลกระทบก่อนเป็น confirmed finding และ tester ไม่มีอำนาจยอมรับ residual business risk โดยอัตโนมัติ

Strategy, plan และ standard

Security testing strategy อธิบายแนวทางระยะยาวว่า assurance ระดับใดเหมาะกับ risk ชนิดใด จะผสม static, dynamic, manual และ independent evidence อย่างไร และใครมี authority ต่อผล ส่วน security test plan แปลง strategy ให้เป็นงานของ release หรือ scope เฉพาะ ระบุ subject version, objectives, techniques, environment, data, roles, entry/exit criteria, schedule, evidence handling และ escalation

Testing standard กำหนด baseline ที่ใช้ซ้ำ เช่น rule เรื่อง isolation, severity taxonomy, evidence retention หรือ minimum negative cases แต่ plan ต้องทำ applicability และ tailoring ตาม risk ห้ามคัด checklist เดียวใช้ทุกระบบโดยไม่ตรวจ attack surface

Strategy และ plan ที่ดีตอบคำถามต่อไปนี้:

• Why: risk, requirement, threat scenario หรือ assurance claim ใดต้องตอบ
• What: code, API, binary, configuration, dependency integration, document หรือ operational procedure รุ่นใดอยู่ใน scope และสิ่งใด exclude พร้อม rationale
• How: functional, non-functional, static, dynamic, manual, automated, destructive หรือ independent technique ใดตอบ claim ได้จริง
• Where: environment topology, trust boundaries, harness, instrumentation, dependency doubles และ known differences จาก production
• Who: ผู้สร้าง ผู้ execute ผู้ triage ผู้ approve exception และผู้รับผล
• When: entry criteria, sequence, cadence, regression trigger และ exit criteria
• Evidence: result format, artifact identity, timestamps, data lineage, log access, retention และ chain of custody ที่จำเป็น
• Safety: authorization, rules of engagement, rate limit, stop condition, rollback, notification และวิธีไม่กระทบบุคคลหรือระบบนอก scope

Functional และ non-functional security testing

Functional security testing ตรวจ behavior ที่ระบบต้องทำ เช่น ตรวจ authorization ทุก protected action, revoke entitlement แล้ว token เดิมใช้ไม่ได้ตามเกณฑ์ หรือ ปฏิเสธ signature ที่ผิด ส่วน non-functional security testing ตรวจ property, constraint หรือระดับ assurance เช่น ความต้านทาน resource exhaustion, entropy quality, isolation, recovery behavior หรือความครบของ audit evidence

การแบ่งนี้ไม่ได้บอกว่า technique ใดเป็นของประเภทเดียว Test case หนึ่งอาจตรวจทั้ง สองมิติ เช่น ส่ง concurrent approvals เพื่อยืนยัน functional SoD invariant พร้อม วัดว่า contention ไม่ทำให้ระบบ fail open ภายใต้ load ที่ approved requirement ระบุ ห้ามแต่ง threshold ขึ้นเอง หากไม่มี threshold ต้องรายงานว่า requirement/oracle gap แทนการประกาศ pass

Known และ unknown test environment

Known environment คือ topology, configuration, identity, dependency, data state, clock, network behavior, toolchain และ instrumentation ถูกบันทึกและควบคุมพอให้ ทำซ้ำและอธิบายผลได้ Unknown environment ไม่ได้แปลว่าไม่รู้อะไรเลย แต่เป็นการ ทดสอบแบบจำกัดความรู้ เช่น black-box จากมุมมอง attacker เพื่อค้น assumptions ที่ ทีมภายในมองข้าม

ทั้งสองแบบมีคุณค่าและข้อจำกัด:

มิติ	Known/controlled environment	Limited-knowledge/unknown environment
จุดแข็ง	ทำซ้ำ แยกสาเหตุ และวัด instrumentation ได้ดี	ท้าทาย discoverability, exposed behavior และ defender assumptions
Blind spot	อาจเหมือน model มากเกินจริงและใช้ privileged knowledge	attribution ยาก coverage มองไม่เห็น และอาจพลาด internal-only path
Evidence	Environment manifest, seed, configuration และ precise oracle	Recon record, rules of engagement, observed surface และ attack narrative
การใช้ร่วมกัน	White/gray-box ยืนยัน control detail	Black/gray-box validate attacker-visible posture

Test result ใช้แทน production assurance ไม่ได้หาก environment ต่างอย่างมีนัยสำคัญ ทีมต้องบันทึก environment delta เช่น identity provider, key store, network policy, clock source, database isolation, compiler flags หรือ third-party behavior แล้วส่ง สิ่งที่จำลองไม่ได้ให้ operational validation ในบทที่ 7

Test harness และ oracle

Test harness คือ tooling, driver, stub, simulator, instrumentation และ evidence collector ที่จัดสภาพและ execute case อย่างควบคุม Harness เป็นส่วนหนึ่งของ TCB ของผลทดสอบ เพราะ harness ที่แก้ response, ใช้ privileged shortcut หรือเก็บ log ไม่ครบ ทำให้ผลลวงได้ จึงต้อง version, review, isolate และทดสอบ harness เองตามความเสี่ยง

Oracle คือกติกาที่ตัดสิน expected result อาจเป็น exact outcome, invariant, metamorphic relation, reference implementation หรือ human review ที่มีเกณฑ์ชัด “ไม่ crash” ไม่ใช่ oracle เพียงพอสำหรับ security เพราะระบบอาจไม่ crash แต่เปิดเผย ข้อมูล ข้าม authorization หรือสร้าง state ผิด

Diagram นี้แสดง trust boundary ของ environment ที่แยก test controller, subject, test data และ evidence store ออกจาก production

การแยกนี้ต้องเป็น effective isolation ไม่ใช่เพียงตั้งชื่อ account ว่า test ต้องตรวจ route, credential, storage, backup, telemetry sink, administrator และ shared service ด้วย หากจำเป็นต้องเชื่อม production service ต้องอนุมัติขอบเขต จำกัด capability และ สร้าง stop condition ที่ชัดเจน

Bug bounty และ coordinated external testing

Bug bounty เปิดให้ผู้วิจัยภายนอกส่ง vulnerability ตาม program scope และ reward rules จึงช่วยเพิ่มความหลากหลายของ attacker perspective แต่ไม่แทน planned testing เพราะ coverage, timing, skill mix และ negative evidence ไม่รับประกัน Program ที่ดี ระบุ in-scope assets, safe harbor ที่ authority อนุมัติ, prohibited techniques, data-handling, duplicate policy, communication, severity triage, remediation และ disclosure coordination

ความเสี่ยงสำคัญคือ scope ไม่ชัด ผู้วิจัยแตะ third party หรือข้อมูลจริง รายงานถูก เปิดเผยก่อนแก้ และทีมให้ reward ตาม score โดยไม่วิเคราะห์ context Bug bounty result ต้องเข้าสู่ defect/vulnerability workflow เดียวกับ internal finding พร้อมรักษา reporter confidentiality และ evidence access ตาม policy

Coverage ไม่เท่ากับ assurance

Coverage เป็นข้อมูลว่าพื้นที่ตาม model ถูก exercise มากน้อยเพียงใด เช่น statement, branch, requirement, route, state transition, threat, abuse case, privilege pair หรือ configuration coverage ส่วน assurance คือระดับความเชื่อที่มีเหตุผลว่า claim จริง ภายใต้ scope ที่กำหนด

Coverage สูงไม่รับประกัน oracle ที่ถูกต้อง, environment realism, absence of hidden path หรือ security property ที่ต้องการ ขณะเดียวกัน coverage ต่ำบ่งบอก blind spot ได้ แต่ไม่บอก business impact จึงต้องรายงาน coverage พร้อม model, denominator, exclusions, oracle quality และ residual uncertainty ห้ามใช้ตัวเลขเดียวเป็น gate สากล

Static, dynamic, interactive และ adversarial techniques

เทคนิคแต่ละชนิดตอบคำถามต่างกันและสร้าง evidence คนละแบบ การเลือกที่ดีใช้หลายวิธี ที่มี blind spot ต่างกันแทนการเปรียบว่าเครื่องมือใด “ดีที่สุด” โดยทั่วไป SAST อยู่ใน implementation analysis แต่ผล SAST มีค่าเป็น input ต่อ test strategy และ regression ด้วย

Technique	มุมมองและเวลาที่ใช้	จุดแข็ง	ข้อจำกัดสำคัญ
SAST	วิเคราะห์ source/intermediate representation โดยไม่ execute	หา data/control flow และ weakness pattern เร็ว ผูกบรรทัด code ได้	ไม่เห็น effective runtime configuration หรือ behavior และ finding ไม่ใช่ proof
DAST	กระตุ้น running application จาก interface ที่มองเห็น	เห็น deployed behavior, protocol และ error จริง	มอง internal path จำกัด attribution ยาก และ coverage ขึ้นกับ crawl/state
IAST	ใช้ instrumentation ภายในขณะ execute test	เชื่อม request กับ internal flow/sink ได้แม่นขึ้น	agent/hook เปลี่ยน timing/behavior และเห็นเฉพาะ path ที่ test exercise
Penetration test	ผู้ทดสอบตั้งสมมติฐานและต่อ attack path ภายใต้ rules of engagement	ประเมิน exploit chain, business logic และ control interaction	เป็น sample ตามเวลา/skill ไม่พิสูจน์ absence และต้องคุมผลกระทบ

DAST ไม่ใช่ automated penetration test เสมอไป และ penetration testing อาจใช้ SAST, DAST, IAST หรือ custom tooling เป็นข้อมูลประกอบ ความต่างหลักคือ penetration test ใช้มนุษย์สร้างและปรับ adversarial hypothesis เพื่อบรรลุ objective ขณะที่ scanner execute rule/crawl ตาม capability ที่กำหนด

Security test case anatomy

Test case ที่ตรวจสอบย้อนหลังได้ควรมี identifier, source requirement/threat, subject version, preconditions, identities/privileges, data classification, steps/input, oracle, expected protected evidence, cleanup, safety constraint, result และ link ไป finding หาก fail สำหรับ non-deterministic behavior ต้องกำหนด repetition, seed หรือ statistical acceptance method จาก approved criterion

ชนิด case ที่ต้องผสมตาม risk ได้แก่:

• Positive case: ยืนยัน allowed behavior ที่ถูกต้องและ evidence ที่ต้องเกิด
• Negative case: ยืนยัน invalid/unauthorized behavior ถูกปฏิเสธอย่าง fail secure
• Boundary case: ทดสอบค่าที่ขอบ syntax, semantics, size, time และ state
• Misuse/abuse case: execute scenario จาก requirement และ threat model
• State/sequence case: ท้าทาย order, stale state, replay, duplicate และ race
• Failure/fault case: inject dependency, clock, storage, network หรือ partial commit failure เพื่อยืนยัน invariant และ recovery semantics
• Regression case: ล็อกพฤติกรรมที่เคยผิดและ adjacent variants หลัง remediation

Attack surface และ undocumented functionality

การทดสอบ attack surface ไม่เริ่มจาก endpoint list อย่างเดียว แต่ inventory data, control, admin, update, telemetry, backup, recovery, debug, worker, batch, callback, file/parser, protocol และ physical/local interface แล้วเทียบสามมุมมองคือ documented design, built artifact และ runtime-observed behavior Delta ระหว่างสามชุดคือพื้นที่ที่ ต้องสืบสวน ไม่ใช่ proof ว่า malicious เสมอไป

Undocumented functionality อาจเกิดจาก debug route, default framework endpoint, dead/dormant code ที่ reachable ด้วย flag, hidden parameter, legacy protocol, test credential, alternate parser, dependency feature, Easter egg, shadow API หรือ maintenance command ความเสี่ยงมาจากการไม่มี requirement, owner, threat analysis, test coverage และ operational monitoring ที่สอดคล้อง

Diagram ต่อไปใช้ set comparison เพื่อค้นหา hidden และ missing behavior

การค้นพบ route ที่ไม่อยู่ในเอกสารต้อง preserve evidence, ตรวจ authorization และ ส่งให้ owner วิเคราะห์ ไม่ควรยิง destructive payload ทันที การลบ function ก็ไม่ใช่ คำตอบอัตโนมัติ เพราะอาจเป็น operational dependency ที่เอกสารตกหล่น ต้องผ่าน change control และ regression

Generated และ mutation-based fuzzing

Fuzzing ป้อนข้อมูลจำนวนมากหรือหลากหลายเพื่อค้น crash, hang, resource exhaustion, parser inconsistency และ invariant violation Generation-based fuzzing สร้าง input จาก grammar/model จึงเข้าถึง deep valid states ได้ดีเมื่อ model ถูกต้อง แต่เสี่ยงพลาด สิ่งที่ model ไม่คิดถึง Mutation-based fuzzing เปลี่ยน seed corpus ที่มีอยู่ จึง เริ่มง่ายและรักษาโครงสร้างบางส่วน แต่คุณภาพขึ้นกับ corpus และ mutation strategy

Fuzz campaign ต้องบันทึก subject build, harness, seed/corpus provenance, generator version/configuration, random seed, timeout, resource limit, sanitizer/instrumentation, crash deduplication และ minimized reproducer Coverage-guided fuzzing ช่วยนำทางเข้า path ใหม่แต่ coverage increase ยังไม่เท่ากับ security impact และ crash count ไม่เท่ากับ จำนวน vulnerability

Simulation และ synthetic transactions

Simulation จำลอง actor, dependency, attack, failure หรือ environment ที่ทดสอบตรง ๆ ไม่ได้ ส่วน synthetic transaction รัน workflow ที่สร้างขึ้นโดยไม่มีธุรกรรมธุรกิจจริง เพื่อยืนยัน end-to-end behavior และ telemetry ใน controlled scope ทั้งสองช่วยทดสอบ rare event และ failure path แต่ model fidelity เป็น assumption ที่ต้องบันทึก

ตัวอย่างเช่น จำลอง identity provider ตอบ stale key, queue ส่ง duplicate หรือ key service timeout แล้วตรวจว่า authorization และ ledger invariant ยังคงอยู่ Synthetic payroll transaction ใช้ employee และจำนวนเงินสมมติ ทดสอบ maker/checker, evidence และ rollback โดยไม่สัมผัสข้อมูลพนักงานจริง

Failure, fault, stress และ break testing

คำเหล่านี้สัมพันธ์กันแต่ไม่เหมือนกัน Fault injection ใส่สาเหตุ เช่น disk full, corrupt response, latency, process kill หรือ clock skew เพื่อดู failure behavior Failure testing ตรวจว่าระบบตอบเมื่อ component/control ล้มเหลวตาม policy หรือไม่ Stress testing ดัน load/resource/state เกินช่วงปกติเพื่อหา degradation และ security boundary ส่วน break testing จงใจผลักจน control หรือระบบแตกเพื่อรู้ threshold, failure mode และ blast radius ภายใต้ authorization ที่เข้มกว่า

การทดสอบเชิงทำลายต้องมี rules of engagement, isolated environment, monitoring, kill switch, rollback และผู้มีอำนาจรับผล ห้ามนำ threshold จาก test environment ไป ประกาศ production capacity โดยไม่วิเคราะห์ topology/configuration delta

Cryptographic validation และ entropy

Cryptographic testing ต้องแยกอย่างน้อยสามคำถาม ได้แก่ implementation เรียก primitive และ mode ตาม approved design หรือไม่, key/nonce/randomness lifecycle ถูกต้องหรือไม่ และ module/algorithm validation evidence ที่ obligation กำหนด applicable หรือไม่ Known-answer test ช่วยตรวจ implementation เทียบ test vector, negative test ตรวจ invalid tag/signature/certificate/downgrade และ interoperability test ตรวจ protocol semantics แต่ทั้งหมดไม่พิสูจน์ key secrecy หรือ entropy ใน production โดยตัวเอง

Entropy testing ใช้ตรวจ health และคุณสมบัติของแหล่ง randomness ตาม approved method ไม่ควรดู sample “สุ่มเหมือน” ด้วยตา หรือใช้ผ่าน statistical suite แล้วสรุปว่า cryptographically secure ต้องประเมิน source, conditioning, seeding/reseeding, failure signaling, virtualization/platform assumptions และ operational monitoring ร่วมด้วย หากเกณฑ์ขึ้นกับมาตรฐานหรือ validation program รุ่นใด ให้ยืนยัน authoritative source ก่อน ไม่แต่ง threshold

Unit, integration, regression และ continuous testing

Unit security tests ให้ feedback เร็วและแยก logic เช่น parser, policy function หรือ state transition แต่ mock อาจปิดบัง trust-boundary behavior Integration tests ตรวจ contract ระหว่าง real components เช่น issuer/audience, retry/idempotency และ database atomicity Regression tests รักษา closure ของ vulnerability เดิมพร้อม variants และ continuous testing ทำชุดที่เหมาะสมทุก change/build/deployment stage

Continuous ไม่ได้แปลว่ารันทุก test ทุก commit ทีมมักแบ่ง fast deterministic gates, risk-triggered suites, scheduled deep scans/fuzzing และ pre-release independent tests โดยต้องรักษา evidence ว่าชุดใดถูกรันกับ artifact ใด ถ้า tool unavailable ให้บันทึก tool unavailable ไม่ปลอมเป็น pass และใช้ preapproved fallback หรือ exception path ตาม break/build criteria

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

Testing เองมี attack surface และสร้างความเสี่ยงได้ ทั้งยังอาจให้ false confidence หาก model, data หรือ evidence ผิด รายการต่อไปเชื่อมเหตุไปยังผลกระทบและ control ที่ต้องคิด

Threat หรือ weakness	Attack/failure scenario	ผลกระทบ	Control direction
Artifact substitution	ทดสอบ debug build แต่ release คนละ digest	ผล pass ไม่ครอบคลุม production artifact	Bind test evidence กับ immutable artifact identity
Harness compromise	Hook ข้าม authorization หรือแก้ response	False pass/false finding และ evidence ไม่น่าเชื่อถือ	Version, review, isolate และ attest harness ตาม risk
Environment drift	Test IdP, key, policy หรือ compiler flag ต่างจาก target	Control ทำงานต่างเมื่อ deploy	Environment manifest, delta analysis และ operational validation
Production-data copy	ใช้ข้อมูลจริงใน test โดยสิทธิ์กว้างและไม่มี lineage	Disclosure, privacy/compliance และ persistence ใน backup	Synthetic/minimized data, approval, isolation และ disposition
Scanner blind spot	Crawl ไม่ถึง batch/admin/recovery route	Hidden attack path ไม่ถูกทดสอบ	Attack-surface inventory, manual exploration และ route diff
Weak oracle	ถือว่า HTTP success หรือไม่ crash เป็น pass	Semantic authorization/integrity failure หลุด	Requirement/invariant-based oracle และ protected evidence check
Test privilege abuse	Tester credential เข้าถึงนอก scope	กระทบระบบ ผู้ใช้ หรือ third party	Rules of engagement, scoped identity, monitoring และ kill switch
Finding suppression	ทีมปิด finding เพื่อให้ build เขียว	Known exposure ถูกซ่อน ไม่มี authority	Immutable workflow, SoD, rationale, expiry และ audit
Metric gaming	เพิ่ม shallow cases เพื่อให้ coverage สูง	ทรัพยากรไหลออกจาก high-risk paths	Multi-dimensional coverage กับ outcome review
Flaky security test	Race test ผ่าน/ตกแบบอธิบายไม่ได้	ทีม ignore signal หรือ block delivery ผิด	Seed/state control, quarantine with owner และ root-cause deadline
Evidence leakage	Report มี token, Restricted payload หรือ exploit detail กว้าง	สร้างเส้นทางโจมตีและ data breach	Minimize, redact, encrypt, access-control และ retain ตาม purpose
Destructive test escape	Stress/fuzz target production/shared dependency	Outage หรือ corrupt state	Network/data isolation, allowlist target และ automatic stop

ความเสี่ยงของ false positive คือทีมเสีย effort และอาจชินกับ alert ส่วน false negative คือ weakness ที่เครื่องมือไม่รายงาน ทั้งสองไม่ควรแก้ด้วยการปิด rule แบบกว้าง ต้องทำ tuning แบบ versioned มี rationale, scope, owner และ regression evidence

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

Controls ของ testing ต้องคุ้มครองทั้ง subject under test, ผู้เกี่ยวข้อง และความน่าเชื่อถือ ของ evidence การมี test จำนวนมากแต่ไม่รู้ว่าทดสอบ artifact ใดหรือใครเปลี่ยน result ไม่ได้สร้าง assurance ที่ใช้ตัดสินใจได้

Risk-based test planning และ traceability

เริ่มจาก asset/objective และ concrete threat scenario แล้ว map ไป requirement, invariant, attack path, implementation allocation และ planned test ใน Security Requirements Traceability Matrix (SRTM) Test priority พิจารณา impact, exposure, attacker capability, change/novelty, control criticality, uncertainty, history และ cost of late detection โดยไม่ใช้ Common Vulnerability Scoring System (CVSS) เป็น business priority เพียงตัวเดียว

Plan ต้องกำหนด entry criteria เช่น approved scope, stable artifact identity, environment readiness, test-data authorization และ rules of engagement ส่วน exit criteria ต้องอธิบาย required evidence, unresolved finding state, coverage gap และ residual uncertainty ไม่เขียนเพียงว่า “all tests pass” เพราะ excluded หรือไม่เคยรัน อาจถูกซ่อนอยู่

แนวปฏิบัติสำคัญมีดังนี้:

• Trace แบบ bidirectional จาก test result กลับไป requirement/threat และจาก critical requirement ไปทุก positive, negative, boundary และ failure route ที่ applicable
• Version-lock requirement baseline, test case, harness, environment manifest และ build artifact เพื่อป้องกัน semantic mismatch
• Review test design แยกจากผู้ implement control สำหรับ claim ที่มี impact สูง เพื่อ ลด confirmation bias โดยยังให้ developer ทำ unit tests ได้
• กำหนด regression trigger เมื่อ code, configuration, dependency, compiler, policy, environment, threat assumption หรือ remediation เปลี่ยน
• บันทึก exclusions และ unknowns เป็น residual uncertainty พร้อม owner ไม่เติม case placeholder แล้วนับเป็น coverage

Layered selection of testing techniques

ใช้ technique ตามคำถามและ lifecycle stage เช่น unit tests ให้ feedback เร็ว, SAST ช่วยหา implementation pattern, integration tests ยืนยัน trust contract, DAST และ IAST ยืนยัน runtime path, fuzzing สำรวจ input space และ penetration testing ต่อ attack path มุมมอง adversary Layering มีค่าเมื่อ failure modes ต่างกัน หากทุกเครื่องมือ ใช้ parser, rule feed หรือ authentication setup เดียวกัน อาจเกิด common-mode failure

Diagram นี้แสดงการจัด portfolio ตามความเร็วและความลึก ไม่ได้หมายความว่าต้องรัน ทุกชั้นทุก commit

ชั้นล่างมักเร็วและ localize cause ได้ดีกว่า ส่วนชั้นบนเห็น emergent behavior และ stakeholder context มากกว่า การเลื่อน security testing ทั้งหมดไปปลาย release ทำให้ การแก้แพงและหา root cause ยาก แต่การมีเฉพาะ unit tests ก็ไม่เห็น deployed boundary

Documentation verification and validation

Objective 6.3 ไม่ใช่การตรวจคำสะกดเท่านั้น Documentation เป็น work product และบาง รายการเป็น operational control interface จึงต้องทำทั้ง verification และ validation โดยเทียบเอกสารกับ approved template/requirement/version แล้วให้ผู้ใช้เป้าหมายทดลอง ทำ procedure ใน representative environment

เอกสารที่ต้องเลือกตาม scope ได้แก่ security test plan, architecture/threat model, interface contract, secure configuration guide, installation/runbook, user/admin guidance, incident/recovery procedure, API specification, data-flow/retention record, release note, known risk และ evidence package

ตรวจอย่างน้อยห้ามิติต่อไปนี้:

• Correctness: ชื่อ field, command, role, route, default, failure behavior และ artifact version ตรงกับ implementation
• Completeness: ครอบคลุม prerequisite, normal/alternate/error/recovery path, warnings, rollback, owner และ escalation
• Consistency: เอกสารหลายชิ้นไม่ขัดกัน และ terminology/configuration baseline สอดคล้องกัน
• Usability: ผู้ใช้เป้าหมายทำตามได้โดยไม่เดา ไม่ต้องขอ privilege กว้างเกิน และ safe path มี psychological acceptability
• Security: ไม่มี secret, live credential, Restricted sample หรือคำแนะนำให้ปิด control ถาวร และ access/retention เหมาะกับ audience

การ review เอกสารเป็น verification ได้ แต่การ exercise runbook, recovery procedure หรือ admin guidance กับ representative user/environment ให้ validation ที่แข็งแรงกว่า หาก document ระบุ procedure ที่ไม่เคย execute ต้องไม่สรุปว่า operationally valid

Undocumented-function discovery controls

ใช้หลายแหล่งเพื่อเทียบ expected กับ actual surface เช่น source route registry, binary symbol/string, API schema, configuration/feature flag, dependency endpoint, network listener, proxy log, runtime instrumentation, UI crawl และ authorization matrix ทำทั้ง authenticated roles และ unauthenticated view พร้อมตรวจ alternate content types, methods, versions และ error transitions

เมื่อพบ delta ให้ดำเนินการตามลำดับ:

1. Preserve subject version, discovery input และ minimal observation โดยไม่ขยายผล เกิน authorization
2. Confirm reachability, privilege, data/control effect และ whether intended
3. หา owner, requirement, design allocation, threat analysis, tests และ monitoring
4. Classify เป็น documentation gap, configuration drift, defect, vulnerability หรือ authorized but untraced capability
5. ปิด exposure, remediate, document หรือขอ exception ผ่าน authority ที่เหมาะสม
6. เพิ่ม regression และ attack-surface reconciliation สำหรับ release ถัดไป

Result analysis: observation, finding และ risk decision

Finding เป็นข้อสรุปเชิงเทคนิคที่มี evidence ว่า behavior หรือ work product เบี่ยงจาก expected security condition ส่วน risk decision พิจารณาว่า finding นั้นกระทบ objective มากน้อยเพียงใดและจะ treat อย่างไร การแยกนี้ป้องกันทั้ง scanner ตัดสิน business risk และผู้ส่งมอบลด severity เพื่อให้ release ผ่าน

ลำดับการวิเคราะห์ที่มีวินัยประกอบด้วย:

1. Preserve: ผูก raw result กับ artifact, case, environment, time และ test data
2. Confirm: ทำซ้ำ ลด reproducer และแยก tool/harness/environment error
3. Characterize: ระบุ affected component, weakness/error, precondition, privilege, reachability, attack path และ impacted security property
4. Contextualize: ประเมิน asset, data classification, exposure, compensating controls, blast radius, likelihood assumptions และ business impact
5. Prioritize: ใช้ technical severity เช่น CVSS เป็น input ร่วมกับ context, exploitability, active exposure, remediation dependency และ policy
6. Decide: apply preapproved build-break rule หรือส่ง risk owner/authority เลือก remediate, avoid, transfer/share หรือ accept ผ่าน exception
7. Verify closure: retest exact reproducer, adjacent variants, regression และ artifact version ใหม่ ไม่ปิดจากข้อความว่า developer fixed

Diagram ต่อไปแสดง state ของ finding และ gate โดยไม่รวม false positive เข้ากับ risk acceptance

False positive หมายถึง tool assertion ไม่ตรงกับ subject behavior หลังตรวจ ไม่ใช่ finding จริงที่องค์กร “รับได้” ส่วน accepted vulnerability ยังคงเป็น vulnerability และ residual risk จน treatment/expiry เปลี่ยน การตั้ง status สองอย่างนี้เหมือนกันจะ ทำให้ governance และ metric หลอก

Prioritization และ build-break decisions

Break/build criteria ต้องกำหนดล่วงหน้าใน governance และปรับตาม applicability เช่น ห้าม artifact ก้าวต่อเมื่อ critical invariant fail, มี exploitable unauthorized path, required evidence ขาด หรือ accepted exception หมดอายุ ผล gate ใช้สถานะ pass, conditional pass, fail หรือ exception required ตาม style กลาง

Priority ไม่ควรเรียงจาก CVSS base score อย่างเดียว CVSS สื่อ characteristics ของ vulnerability ตาม model/version ที่ใช้ แต่ไม่ได้รู้ asset value, data, exposure, control effectiveness, mission timing หรือ risk appetite ขององค์กร ตัวอย่างเช่น medium technical severity บน internet-facing payment authorization path อาจต้องแก้ ก่อน high score ใน disabled unreachable component อย่างไรก็ตามคำว่า unreachable ต้องมี evidence ไม่ใช่ assumption

Build-break อัตโนมัติให้ feedback สม่ำเสมอแต่เสี่ยง false block และการ suppress rule เพื่อเร่งงาน จึงต้องมี triage SLA, scoped suppression with rationale, tool-unavailable state, emergency exception path, expiry และ post-decision review ไม่ลดเกณฑ์เงียบ ๆ

Defect, error, weakness และ vulnerability classification

คำเหล่านี้ทับซ้อนในบางองค์กร จึงต้องประกาศ taxonomy ที่ใช้และไม่เปลี่ยน label เพื่อ ลด priority โดยทั่วไป error คือ human action หรือ incorrect state ที่นำไปสู่ ผลผิด, defect คือ flaw ใน work product ที่เบี่ยงจาก expected result, weakness คือ condition ที่อาจนำไปสู่ vulnerability และ vulnerability คือ weakness ใน context ที่อาจถูก exploit หรือทำให้ control ล้มเหลวจนเกิดผลเสีย

Defect record ที่ใช้ติดตามควรมีข้อมูลดังนี้:

• Stable identifier, source/tool/reporter และ disclosure restriction
• Affected product, component, configuration และ first/last known artifact version
• Minimal reproducer, expected/actual behavior และ evidence location
• Taxonomy เช่น weakness class โดยไม่ใช้ taxonomy เป็น impact analysis
• Preconditions, privileges, attack surface, affected property และ potential impact
• Technical severity input รวม CVSS vector/model version เมื่อองค์กรใช้ ไม่เก็บเพียง score ที่อธิบายไม่ได้
• Contextual priority, owner, target milestone, treatment และ dependency/blocker
• Duplicate/related finding links, root cause และ variants
• Exception authority, compensating controls, residual risk, expiry/review trigger
• Fix version, peer review, exact retest และ regression evidence ก่อน closure

Deduplication ต้องรักษาความสัมพันธ์ ไม่ควรปิด findings หลายรายการเป็น duplicate เพียงเพราะ sink เดียวกัน เพราะ source, privilege หรือ affected tenant อาจต่างกัน Root-cause fix อาจปิดหลาย instances ได้เมื่อ retest coverage ยืนยันจริง

Secure test data lifecycle

Secure test data เริ่มจาก purpose และ data owner ไม่ใช่เริ่มจากการ copy production Data minimization, purpose limitation, classification, lineage และ disposition ใช้กับ test data, fixtures, logs, screenshots, crash dumps, corpus, backups และ derived data ทุกชุด Synthetic data มักเป็นตัวเลือกแรก แต่ต้องทดสอบ semantic edge cases ได้จริง และต้องไม่สร้างจาก pattern ที่ reconstruct บุคคลจริงได้

หาก synthetic data ไม่ตอบ claim และต้องใช้ production-derived data ต้องมี authority, applicability review, minimization, transformation ที่เหมาะสม, re-identification risk assessment, isolated access, retention และ verified disposition การ masking ที่ reversible หรือคง unique combinations อาจยังเป็น Restricted ตาม classification เดิม ห้ามสมมติว่า tokenization/anonymization เป็นคำตอบสากล

วงจรต่อไปทำให้ owner และ disposition ตรวจสอบได้

จุดสำคัญคือ evidence ของการลบต้องครอบคลุม copies และ derived artifacts ตาม data lineage ไม่ใช่ลบ database หลักแล้วประกาศจบ Test account และ entitlement ต้องมี expiry/revocation เช่นเดียวกัน และห้ามใช้ shared admin account เพื่อความสะดวก

Independent, internal V&V และ acceptance

Internal Verification and Validation (V&V) ทำโดยทีมภายในซึ่งรู้ระบบและ iterate ได้ เร็ว ส่วน independent V&V เพิ่ม separation จากทีมพัฒนาและอาจรวม independence ด้าน technical, managerial หรือ financial ตาม governance เป้าหมายคือเพิ่ม objectivity และ challenge assumptions ไม่ใช่ทำให้ผล “ถูกเสมอ” ผู้ทดสอบอิสระยังต้องมี scope, competence, environment access และ evidence ที่เพียงพอ

เลือกระดับ independence ตาม impact, novelty, conflict of interest, obligation, assurance need และ risk tolerance งาน critical อาจใช้ developer unit tests, internal security integration testing และ independent validation ร่วมกัน ส่วน low-risk change อาจใช้ peer-separated internal V&V ตาม approved tailoring

Acceptance testing ตรวจว่าระบบตอบ acceptance criteria และ stakeholder need ใน representative context Security acceptance ต้องรวม unauthorized/misuse/failure behavior ไม่ใช่ให้ business user ทดสอบ happy path อย่างเดียว ผู้รับรอง acceptance ต้อง มี authority ต่อ criteria นั้น และไม่สามารถลบ obligation หรือรับ residual risk ที่อยู่นอก อำนาจของตน

V&V result ที่ดีบันทึก independence, scope, artifact/environment, methods, limitations, findings, unresolved uncertainty และ opinion ต่อ claim โดยไม่ใช้คำว่า “secure” แบบ ไร้ขอบเขต หาก independent tester พบ failure ต้องเข้าสู่ workflow เดียวกัน ไม่สร้าง อีกระบบหนึ่งที่ owner และ status ไม่เชื่อมกัน

Continuous evidence และ configuration discipline

ทุก automated result ต้อง bind กับ source revision, resolved dependencies, build configuration, tool/rule version, harness, environment และ artifact digest เมื่อ นำ test binary ที่ instrumented ต่างจาก release binary ต้องบันทึก delta และเสริม test บน release-candidate artifact ตาม claim ที่สำคัญ

เก็บ raw evidence แยกจาก summary dashboard Dashboard เป็น view ที่สร้างใหม่ได้และ อาจมี stale cache Protected evidence ต้องจำกัด access, minimize sensitive content, รักษา integrity/time/attribution และมี retention ตาม purpose แต่ integrity protection ไม่พิสูจน์ว่า harness หรือ emitter บอกความจริง จึงต้องตรวจ trust chain และ corroborate evidence สำหรับ claim สำคัญ

Pseudo code

Pseudo code ต่อไปสาธิต risk-based selection และ evidence gate โดยจงใจแยก not_run, tool_unavailable, failed, passed และ exception_required ออกจากกัน เกณฑ์และ threshold ทั้งหมดสมมติว่ามาจาก approved policy ไม่ใช่ค่าที่ตัวอย่างแต่งขึ้น

# PSEUDO CODE — risk-based security test selection and evidence gate

function plan_and_evaluate(release, approved_policy, trace_matrix):
    assert release.artifact.identity_is_immutable
    assert release.requirements.version == trace_matrix.requirements_version

    selected = empty_set()
    for claim in trace_matrix.security_claims:
        context = {
            impact: claim.business_impact,
            exposure: claim.attack_surface_exposure,
            novelty: release.change_affects(claim),
            uncertainty: claim.known_evidence_gaps,
            criticality: claim.is_security_invariant
        }

        required_routes = approved_policy.select_test_routes(context)
        selected.add_all(bind_each(required_routes,
                                   claim,
                                   release.artifact.digest,
                                   release.environment_manifest.version))

    results = execute_in_isolated_environment(selected)

    for result in results:
        preserve_raw_evidence(result)
        if result.tool_status == "unavailable":
            result.gate_state = "tool_unavailable"
        else if not result.was_executed:
            result.gate_state = "not_run"
        else if result.oracle_detects_deviation:
            result.gate_state = "failed"
            open_or_update_finding(result, owner=lookup_control_owner(result))
        else:
            result.gate_state = "passed_for_scoped_claim"

    gaps = required_evidence(selected) - valid_version_matched_evidence(results)
    failures = confirmed_failures(results)
    expired = expired_exceptions(release)

    if violates_break_criteria(failures, gaps, expired, approved_policy):
        return GateDecision("fail", evidence=results)
    if requires_authorized_exception(failures, gaps, approved_policy):
        return GateDecision("exception_required", evidence=results)
    if has_approved_unexpired_conditions(release):
        return GateDecision("conditional_pass", evidence=results)
    return GateDecision("pass", evidence=results)

จุดสำคัญคือ algorithm ไม่แปลง tool outage หรือ unexecuted test เป็น pass ไม่ให้ tester accept risk เอง และรับเฉพาะ evidence ที่ version ตรงกับ artifact/environment Claim ที่ pass ยังจำกัดอยู่ที่ test route และ oracle ที่เลือก ไม่ได้พิสูจน์ absence ของ vulnerability ทั้งหมด

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

กรณีศึกษานี้สืบทอดระบบ payroll maker/checker จากบทก่อนหน้าเพื่อแสดงว่า test ต้อง ยืนยัน semantic invariant และ alternate path ไม่ใช่เพียง endpoint หลัก Requirement IDs เป็นตัวอย่างที่คู่มือนี้สร้างขึ้น ไม่ใช่ official requirements

บริบทและ assurance claims

ระบบรับ batch payroll รุ่นหนึ่งจาก maker แล้วให้ checker อนุมัติ โดยมี requirement สำคัญดังนี้ SR-PAY-001 ห้าม actor เดียวเป็น maker และ checker ของ transaction version เดียวกัน, SR-PAY-002 การแก้ไข payload หลังอนุมัติต้องสร้าง version ใหม่และ approval เดิมใช้ไม่ได้, SR-DAT-004 จำกัดการใช้ Restricted payroll data และ SR-REC-008 ต้องสร้าง minimized protected evidence สำหรับ state transition สำคัญ

Build candidate มี immutable digest, API gateway, worker queue, authorization PEP, authoritative ledger, transactional outbox และ evidence sink ทีมต้องยืนยันว่า implementation จาก บทที่ 5 รักษา invariant ข้าม concurrency, replay, failure และ alternate interface

Strategy และ environment

ทีมใช้ risk-based strategy ดังนี้:

• Developer รัน unit tests กับ policy/state transition ทุก change รวม misuse cases
• CI รัน SAST, component, mutation-based parser fuzzing และ deterministic regression
• Integration environment ใช้ real database transaction, test IdP และ queue simulator ที่ inject duplicate, reorder, timeout และ redelivery ได้
• Pre-release environment รัน DAST, IAST บน selected attack paths, generation-based API fuzzing, failure/stress tests และ manual penetration test ตาม rules of engagement
• Independent reviewer ตรวจ threat-to-test coverage, test harness, selected evidence และ acceptance scenario สำหรับ high-impact approval path

Test zone ใช้ synthetic employees, accounts และ amounts ที่ครอบคลุม boundary โดยไม่มี production data Identities แยก maker, checker A, checker B, auditor, worker และ admin พร้อม expiry Evidence store รับ minimized transaction ID, actor, action, immutable version, decision, timestamp และ correlation ID แต่ไม่รับ raw payroll payload

Test matrix ที่เน้น attack path

ตารางนี้เป็นบางส่วนของ SRTM ไม่ใช่ checklist ครบทุกระบบ แต่แสดงเหตุผลและ oracle ของแต่ละ case

Case	Stimulus หรือ interleaving	Expected oracle	Risk ที่ตอบ
T-SOD-01	Maker เรียก approve ผ่าน public API	ปฏิเสธที่ authoritative PEP, ledger ไม่เปลี่ยน, evidence ไม่เผย payload	Direct SoD bypass
T-SOD-02	Maker ส่ง message ตรง worker queue	Worker re-authorizes และปฏิเสธ ไม่เชื่อ gateway	Alternate-path bypass
T-SOD-03	Checker A และ B approve version เดียวพร้อมกัน	Atomic transition เดียวสำเร็จ อีกคำขอได้ idempotent/conflict result ตาม contract	Race/double approval
T-VER-04	แก้ payload หลัง Checker A approve แล้ว replay approval	Version binding ทำให้ approval เก่าใช้ไม่ได้	Stale approval reuse
T-IDEM-05	ใช้ idempotency key เดิมกับ payload ต่างกัน	ปฏิเสธ mismatch ไม่คืนผลของธุรกรรมอื่น	Cross-request confusion
T-FAIL-06	Evidence sink ล่มหลัง ledger commit	Business state และ outbox reconcile ตาม design; ไม่ rollback แบบสร้าง double effect	Partial failure/gap
T-TOK-07	ใช้ token ที่ entitlement ถูก revoke แล้ว	Effective authorization ปฏิเสธตาม freshness criterion	Stale authorization
T-DOC-08	Operator ทำ recovery ตาม runbook	กู้ state/version โดยไม่ข้าม SoD และขั้นตอนตรง build	Documentation validation
T-HID-09	เปรียบ API schema กับ runtime listener/routes	Debug/admin route ทุกเส้นมี owner, requirement และ control หรือเปิด finding	Hidden functionality
T-DATA-10	จบ campaign และทำ data reconciliation	Fixtures, logs, dumps, cache และ access ถูก retain/dispose ตาม approval	Test-data persistence

ตัวอย่าง execution narrative

ในการทดสอบ T-SOD-03 harness ใช้ barrier ปล่อย Checker A และ B พร้อมกัน 2 เส้นทาง คือ public API กับ queue callback ทีมรันซ้ำด้วย deterministic scheduler หลาย interleavings และบันทึก random seed ผลแรกพบทั้งสอง response เป็น success แต่ ledger มี approval เดียว Weak oracle ที่ตรวจเฉพาะจำนวน ledger row จะให้ pass อย่างไรก็ตาม interface contract ระบุว่าผู้แพ้ race ต้องได้รับ idempotent/conflict result ไม่ใช่ success เพราะ success response ผิด accountability semantics

ทีมจึงเปิด defect เชื่อม requirement และ artifact version วิเคราะห์ว่า response ถูก emit ก่อน authoritative compare-and-set result Weakness อาจทำให้ downstream เริ่ม payment ซ้ำหากเชื่อ response จึงมี integrity impact หลังแก้ response ordering ทีม retest exact seed, alternate callback path, timeout before/after commit, duplicate delivery และ mismatched payload แล้วจึงปิด finding บน artifact digest ใหม่

Finding-to-gate decision

DAST ต่อมาพบ /internal/debug/replay ที่ไม่อยู่ใน API schema และใช้ admin token ได้ ทีมไม่สรุปจากชื่อว่าเป็น vulnerability ทันที แต่เทียบ build route, runtime config, authorization และ network exposure พบว่า endpoint ถูก enable ใน release candidate, admin role กว้าง และ replay payload ไม่ bind transaction version Finding จึงเชื่อม attack path ที่ privileged compromise อาจทำ payment transition ซ้ำ

Break criteria กำหนดให้ undocumented state-changing interface และ critical invariant failure เป็น fail ทีม security tester ไม่มีอำนาจลดเป็น accepted risk Release หยุด, owner ปิด feature ที่ build configuration, ลบ route จาก release artifact, เพิ่ม route-diff regression และให้ independent reviewer ยืนยัน artifact ใหม่ ส่วนคำถามว่า production network/identity configuration ป้องกัน exposure จริงหรือไม่ถูกส่งต่อเป็น operational validation ในบทที่ 7

บทเรียนจากกรณีศึกษา

กรณีนี้แสดงหลักสำคัญห้าประการ:

• Test oracle ต้องตรวจ semantic response, authoritative state และ protected evidence พร้อมกัน ไม่ใช่ดูเพียง crash หรือ status code
• Concurrency และ failure test ต้องครอบคลุม interleaving และ alternate route ที่ threat model ระบุ ไม่ใช่เพิ่ม load แบบไร้ state model
• Immutable artifact binding ทำให้ closure ใช้ได้เฉพาะ build ใหม่ที่ retest แล้ว
• Undocumented function ต้องเทียบ design, build และ runtime surface แล้วผ่าน owner/ change control
• Test result สร้าง evidence ให้ gate แต่ risk owner หรือ authority ตาม governance เป็น ผู้ตัดสิน residual risk

Exam tips

ข้อสอบเชิงสถานการณ์มักให้ controls หลายอย่างที่ “มีประโยชน์” แต่ถามสิ่งแรกหรือ สิ่งที่ดีที่สุด ให้เลือกคำตอบที่รักษา scope, authority, traceability และ risk logic

• หากถาม verification vs validation ให้ดู reference: specification/work product คือ verification; stakeholder need/intended use คือ validation
• หากพบ scanner alert ให้ยืนยัน artifact, reproduce และ contextualize ก่อนตัดสิน treatment อย่าข้ามจาก raw alert ไป risk acceptance
• หากถามวิธีเพิ่ม assurance ให้เลือก complementary methods ที่ blind spots ต่างกัน และ trace ไป requirement/threat มากกว่าซื้อ scanner เพิ่มโดยไม่รู้ coverage
• หาก coverage สูงแต่ oracle อ่อน คำตอบที่ดีที่สุดคือปรับ claim/model/oracle ไม่ใช่ ประกาศระบบ secure
• หาก CVSS สูง ให้จำว่าเป็น technical severity input ไม่ใช่ organization-specific business risk หรือ release decision ทั้งหมด
• หาก tool ล่ม ผลคือ evidence missing หรือ tool unavailable ไม่ใช่ pass; ใช้ preapproved fallback หรือ exception ตาม authority
• หากต้องใช้ production data ใน test ให้เริ่มจากตรวจว่า synthetic/minimized data ตอบ claim ได้หรือไม่ แล้วจึงขอ data owner/applicability authorization
• หาก independent test พบ issue ให้เข้ากระบวนการ classify/track/retest เดียวกัน ความเป็นอิสระไม่ทำให้ finding ข้าม evidence discipline
• หากถาม bug bounty ให้มองว่าเสริม attacker diversity แต่ไม่แทน planned coverage, internal V&V หรือ remediation governance
• หากเอกสารผ่าน review แต่ operator ทำตามไม่ได้ นั่นอาจผ่าน document verification บางส่วนแต่ไม่ผ่าน validation

Common pitfalls

ข้อผิดพลาดเหล่านี้มักเกิดเมื่อทีมใช้ activity หรือ tool output แทน assurance claim ที่มี scope ชัดเจน

• นับ test cases, scanner count หรือ code coverage เป็น proof ว่าไม่มี vulnerability
• ทดสอบ build แบบ instrumented/debug แล้วปล่อย artifact อื่นโดยไม่ทำ delta analysis
• ให้ tester หรือ scanner owner accept residual business risk แทน risk owner
• แก้ test/oracle ให้ตรง behavior ที่ผิดเพื่อทำ pipeline ให้เขียว
• ใช้ DAST, IAST และ penetration testing เป็นคำพ้อง หรือถือว่า tool เดียวแทนกันได้
• ทดสอบเฉพาะ happy path และ public UI แต่ไม่ตรวจ worker, batch, admin, debug, recovery และ dependency callback
• ปิด finding เป็น false positive ทั้งที่จริงเป็น accepted vulnerability หรือ unreachable assumption ที่ไม่มี evidence
• ใช้ CVSS score เดี่ยวกำหนด business priority โดยไม่ดู asset/exposure/control
• Copy production database ไป test แล้วเรียกว่า anonymized โดยไม่ประเมิน lineage, reversibility, aggregation และ derived artifacts
• Inject fault หรือ stress ใน shared/production environment โดยไม่มี authorization, kill switch และ rollback
• ใช้ mock ทุก dependency จนไม่เคยทดสอบ real trust contract และ atomic boundary
• ถือว่า bug bounty ที่ไม่มีรายงานหมายถึงไม่มี vulnerability
• ปิด defect เมื่อ code merge โดยไม่ retest fix artifact และ adjacent variants
• คิดว่า independent V&V ทำให้ไม่ต้อง trace requirement หรือเปิดเผย limitation
• ตรวจ document ด้วยการอ่านอย่างเดียว ทั้งที่ runbook หรือ recovery procedure ต้อง exercise เพื่อ validate usability และ operational fit

ข้อฝึกทบทวน

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

ข้อ 1

ทีมยืนยันว่า authorization module ตรง approved interface contract ทุกข้อ แต่ผู้ใช้ ฝ่ายธุรกิจยังสามารถอนุมัติรายการที่ตนสร้างผ่าน batch workflow ที่ requirement ไม่เคย กล่าวถึง สถานการณ์นี้อธิบายได้ดีที่สุดอย่างไร

A. Verification และ validation ผ่านทั้งคู่

B. Verification ของ scoped module อาจผ่าน แต่ validation ของ intended SoD outcome ล้มเหลวและ requirement/attack-surface coverage มี gap

C. เป็น false positive เพราะ interface contract ผ่าน

D. เป็น supply-chain provenance issue เท่านั้น

ข้อ 2

DAST scanner รายงาน injection severity สูงใน release candidate สิ่งแรกที่เหมาะสม ที่สุดคือข้อใด

A. ให้ scanner accept risk เพราะรู้ severity แล้ว

B. หยุดระบบ production ทันทีโดยไม่ตรวจ scope

C. ผูกผลกับ artifact/environment ทำซ้ำ หา minimal evidence และวิเคราะห์ context ตาม break criteria

D. ลด severity หาก SAST ไม่พบตำแหน่ง code

ข้อ 3

ทีมมี statement coverage สูงมากจาก unit tests ข้อสรุปใดถูกต้องที่สุด

A. พิสูจน์ว่าไม่มี undocumented functionality

B. พิสูจน์ non-functional security properties ทั้งหมด

C. เป็น coverage signal หนึ่ง แต่ assurance ยังขึ้นกับ oracle, relevant paths, environment, threats และ independence

D. ทำให้ DAST และ integration testing ไม่จำเป็น

ข้อ 4

องค์กรต้องทดสอบ payroll workflow แต่ synthetic data ที่ออกแบบอย่างดีตอบ boundary, format และ business-rule cases ได้ครบ ทางเลือกใดเหมาะสมที่สุด

A. ใช้ production copy เสมอเพราะสมจริงกว่า

B. ใช้ synthetic data ที่ classified, versioned และ isolated พร้อมบันทึกข้อจำกัด

C. ใช้ข้อมูลพนักงานจริงแต่เปลี่ยนชื่อไฟล์

D. ให้ tester ดาวน์โหลด production data ส่วนตัวเพื่อไม่รบกวนทีม

ข้อ 5

ข้อใดอธิบาย SAST, DAST, IAST และ penetration testing ได้แม่นที่สุด

A. ทั้งสี่คำหมายถึง scanner แบบเดียวกัน

B. SAST execute production, DAST อ่าน source, IAST ไม่ต้องรัน test และ penetration test เป็น code coverage

C. SAST วิเคราะห์ code โดยไม่ต้อง execute, DAST กระตุ้น running interface, IAST instrument runtime path และ penetration test ใช้ adversarial hypothesis ต่อ attack path

D. Penetration testing พิสูจน์ว่าไม่มี vulnerability ที่ไม่พบ

ข้อ 6

Security gate กำหนด required test แต่ tool ไม่พร้อมในวัน release ระบบควรบันทึกผล อย่างไร

A. Pass เพราะไม่มี failure

B. False positive

C. tool unavailable หรือ evidence missing แล้วใช้ fallback/exception ตาม approved governance

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

ข้อ 7

ทีมพบ debug endpoint ที่อยู่ใน binary และ runtime แต่ไม่อยู่ใน design หรือ API documentation ขั้นตอนถัดไปที่ดีที่สุดคืออะไร

A. ลบทันทีจาก production โดยไม่เก็บ evidence หรือทำ impact analysis

B. Preserve discovery, ยืนยัน reachability/authority/effect แล้ว classify และส่ง owner ผ่าน change/risk workflow

C. ถือว่า secure เพราะต้องใช้ admin token

D. เพิ่ม endpoint ลงเอกสารอย่างเดียว

ข้อ 8

ข้อใดเหมาะสมที่สุดสำหรับปิด vulnerability finding หลัง developer ระบุว่าแก้แล้ว

A. ปิดทันทีเมื่อ pull request merge

B. เปลี่ยน label เป็น false positive

C. Retest minimal reproducer และ adjacent regression กับ artifact version ใหม่ แล้ว บันทึก closure evidence

D. รอ penetration test ปีถัดไปเสมอ

ข้อ 9

องค์กรจ้าง independent V&V สำหรับระบบ impact สูง ข้อใดถูกต้องที่สุด

A. Independent tester รับ residual risk แทน business owner ได้

B. Independence ลด confirmation bias แต่ยังต้องมี scope, competence, traceability, environment และ limitation ที่ชัด

C. Developer ไม่ควรทำ unit security tests อีก

D. Independent result ไม่ต้องเข้าระบบ defect tracking ภายใน

ข้อ 10

เอกสาร recovery ผ่าน peer review และตรง template แต่ operator ทำตามแล้วต้องขอ privilege กว้างเกินจำเป็นและกู้ระบบไม่ได้ ข้อสรุปใดดีที่สุด

A. Document verification บางส่วนผ่าน แต่ validation/usability และ least-privilege outcome ล้มเหลว

B. Documentation V&V ผ่านเพราะ peer review เสร็จ

C. เป็น testing data issue เท่านั้น

D. ให้เพิ่ม disclaimer โดยไม่แก้ procedure

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

เฉลยต่อไปนี้อธิบายทั้งเหตุผลของคำตอบและเหตุผลที่ตัวเลือกสำคัญอื่นไม่เหมาะ เพื่อให้ คุณฝึกแยก scope, evidence และ authority

เฉลยข้อ 1: B

Verification อาจผ่านเฉพาะ module และ contract ที่กำหนด แต่ batch workflow แสดงว่า system-level intended SoD outcome ไม่ถูก validate และ attack surface/requirement ไม่ครบ A ขยาย claim เกิน evidence, C เรียก behavior จริงว่า false positive และ D โยนปัญหา ไป supply chain ทั้งที่เป็น requirement/testing gap

เฉลยข้อ 2: C

Raw scanner result ต้องผูก version, reproduce และ contextualize ก่อนเป็น confirmed finding/risk decision จากนั้นจึงใช้ break criteria A ให้ tool ใช้อำนาจผิดบทบาท, B อาจ จำเป็นภายหลังแต่ข้าม scope/evidence และ D ใช้ blind spot ของ SAST ลบผล DAST ไม่ได้

เฉลยข้อ 3: C

Statement coverage บอกเพียง statement ตาม instrumentation ถูก execute ไม่บอกว่า oracle ถูก, state/attack paths ครบ หรือ deployed behavior ปลอดภัย A และ B ประกาศ assurance เกิน model ส่วน D ตัด complementary evidence ที่เห็น trust boundary และ runtime ออก

เฉลยข้อ 4: B

เมื่อ synthetic data ตอบ claim ได้ ควรลด exposure ด้วยข้อมูลสมมติที่ยังจัดการ classification, version และ isolation อย่างมีวินัย A เพิ่ม risk โดยไม่จำเป็น ส่วน C และ D ไม่เปลี่ยน nature ของข้อมูลจริงและละเมิด least privilege/data governance

เฉลยข้อ 5: C

C แยกมุมมองและการทำงานของสี่ technique ได้ถูกต้อง A และ B สลับความหมาย ส่วน D เข้าใจ penetration test เป็น proof of absence ทั้งที่เป็น sample ตาม scope เวลาและ ความสามารถผู้ทดสอบ

เฉลยข้อ 6: C

Tool outage คือ state ของ evidence ไม่ใช่ test pass หรือ false positive Governance ต้องกำหนด fallback, delay หรือ authorized exception A เปลี่ยน absence of evidence เป็น evidence of absence, B ใช้ taxonomy ผิด และ D ให้ tester accept business risk เอง

เฉลยข้อ 7: B

การ preserve และ characterize ก่อนช่วยคุม safety และตัดสินว่าเป็น vulnerability, configuration drift หรือ documentation gap A อาจทำลาย evidence/operation, C สมมติว่า admin token ไม่ถูก compromise และ D แค่ document capability โดยไม่จัดการ risk

เฉลยข้อ 8: C

Closure ต้องอาศัย version-matched retest ของ reproducer และ variants/regression A ถือ merge เป็น verification, B ซ่อน finding จริง และ D ช้าเกินจำเป็นและไม่รับประกันว่า future penetration scope จะครอบคลุม

เฉลยข้อ 9: B

Independence เพิ่ม objectivity แต่ไม่ได้แทน competence หรือ evidence discipline A ย้าย risk authority ผิด, C ทิ้ง fast feedback/defense in depth และ D ทำให้ finding หลุด ownership, prioritization และ closure workflow

เฉลยข้อ 10: A

Peer review และ template สนับสนุน verification บางส่วน แต่การ exercise พบว่าขั้นตอน ใช้ไม่ได้และละเมิด least privilege จึงไม่ผ่าน validation B สับสน document presence กับ effectiveness, C ไม่ตรงสาเหตุ และ D ไม่แก้ control failure

สรุปบท

Secure Software Testing สร้าง assurance ได้เมื่อทุกผลมี claim, oracle, subject version, environment, data, method และ limitation ที่ตรวจสอบได้ Strategy ต้องผสม functional, non-functional, static, dynamic, interactive, fuzzing, failure, manual และ independent techniques ตาม risk ไม่ใช่สะสม tool output

Verification ตรวจ work product เทียบ specification ส่วน validation ตรวจ intended use และ stakeholder need Coverage บอกพื้นที่ตาม model ที่ exercise แต่ไม่เท่ากับ assurance Finding เป็นข้อเท็จจริงเชิงเทคนิคที่ยืนยันแล้ว ส่วน contextual risk treatment และ acceptance ต้องอยู่กับ risk owner หรือ authority ตาม governance CVSS ช่วยสื่อ technical severity แต่ไม่แทน business priority

Test environment, harness, data และ evidence เป็นส่วนหนึ่งของ trust chain จึงต้อง version, isolate, minimize และจัดการ lifecycle เช่นเดียวกับ production asset การปิด finding ต้อง retest artifact ใหม่และ variants ไม่ใช่ปิดเมื่อ code merge ผลลัพธ์สุดท้าย ของบทนี้คือ evidence package และ unresolved uncertainty ที่พร้อมให้ deployment และ operations ตัดสินใจต่อ

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

บทที่ 7: Secure Software Deployment, Operations, Maintenance รับ immutable artifact และ test evidence จากบทนี้ไปยืนยัน effective production configuration, release/install integrity, approval to operate, monitoring, incident, patch, vulnerability management, runtime protection และ continuity

สิ่งที่บทนี้จำลองได้ไม่ครบต้องส่งต่ออย่างชัดเจน ได้แก่ production identity/key/secret delivery, network policy, real dependency behavior, telemetry routing, capacity, failover/recovery และ operational privilege Test pass ใน isolated environment ไม่ใช่ production approval และ finding ที่มี exception ต้องส่ง authority, compensating controls, expiry และ monitoring trigger ไปด้วย

ส่วน component supplier pedigree, provenance, acquisition evidence และ contractual obligation ยังคงเป็นขอบเขตของ บทที่ 8: Secure Software Supply Chain ผล SCA, signature, fuzzing หรือ penetration testing ต่อ component ไม่พิสูจน์ provenance หรือ supplier governance โดยตัวเอง