Bài 3–4 version 2: SSDLC – Quy trình Phát triển Phần mềm An toàn

1. CIA Triad – Nền tảng bảo mật

CIA là bộ ba nguyên tắc cốt lõi mà mọi hệ thống bảo mật phải đảm bảo:

2. Secure SDLC (SSDLC)

2.1 SDLC truyền thống vs SSDLC

SSDLC không phải một giai đoạn riêng biệt — nó nhúng security vào từng phase của SDLC thông thường.

2.2 Nguyên tắc Shifting Left

3. Security Requirements

3.1 Các câu hỏi cần đặt ra khi thu thập Security Requirements

Trước khi thiết kế, team phải trả lời:

• Hệ thống có xử lý PII (Personally Identifiable Information) hay dữ liệu nhạy cảm không?
• Dữ liệu được lưu trữ và truyền như thế nào?
• Ứng dụng public (internet) hay internal (intranet)?
• Có tác vụ nhạy cảm không (chuyển tiền, mở khóa, vận chuyển thuốc)?
• Có cho phép user upload file không?
• Yêu cầu uptime là bao nhiêu?

3.2 Danh sách Security Requirements điển hình

3.3 Ví dụ – Security Requirements cho Web Application

✅ Mã hóa dữ liệu khi lưu trữ và truyền tải (TLS 1.3+)
✅ Validate tất cả user input phía server
✅ Quét thư viện third-party định kỳ (OWASP Dependency Check)
✅ Hash + salt mật khẩu (bcrypt, Argon2id)
✅ MFA cho tài khoản admin/quan trọng
✅ Chỉ cho phép HTTPS, redirect toàn bộ HTTP → HTTPS
✅ Không hardcode secrets (API key, password) trong source code
✅ Không để thông tin nhạy cảm trong comment
✅ Log tất cả lỗi, đặc biệt security-related errors
✅ Catch exception đầy đủ → fail safe thay vì fail open

4. Secure Design

4.1 Design Flaw vs Security Bug

4.2 Defense in Depth

Defense in Depth = nhiều lớp bảo vệ độc lập. Kẻ tấn công phải phá vỡ tất cả các lớp để đạt mục tiêu. Nếu một lớp thất bại, lớp tiếp theo vẫn bảo vệ.

4.3 Secure Design Concepts

4.4 OWASP Top 10 (2021)

4.5 Case Study: CVE-2021-44228 – Log4Shell

4.6 OWASP SAMM

Software Assurance Maturity Model (SAMM) là framework mở để đánh giá và cải thiện chương trình bảo mật phần mềm của tổ chức, gồm 5 business function:

Mỗi function có các practice với maturity levels (1→3), giúp tổ chức xác định hiện đang ở đâu và cần cải thiện gì.

5. Threat Modeling – Mô hình hóa mối đe dọa

5.1 Tại sao cần Threat Modeling?

Thiết kế phần mềm thông thường tập trung vào “phần mềm cần làm gì” — không phải “phần mềm không nên làm gì”. Threat modeling lấp đầy khoảng trống đó bằng cách nhìn hệ thống từ góc độ kẻ tấn công (evil brainstorming).

5.2 Quy trình Threat Modeling

Output của Threat Modeling:

• Danh sách Threats (các concern đã xác nhận là thực tế)
• Danh sách Risks với mức độ: Cao / Trung bình / Thấp
• Kế hoạch: sửa / loại bỏ / tài liệu hóa / chấp nhận rủi ro

5.3 Các phương pháp Threat Modeling

STRIDE

Do Microsoft phát triển (Loren Kohnfelder & Praerit Garg, 1999):

PASTA

Process for Attack Simulation and Threat Analysis — 7 bước:

1. Define Objectives (mục tiêu kinh doanh)
2. Define Technical Scope
3. Decompose Application (DFD, data flows)
4. Threat Analysis
5. Vulnerability & Weakness Analysis
6. Attack Modeling
7. Risk & Impact Analysis

Đặc điểm: tập trung vào business risk, không chỉ technical threats.

TRIKE

• Phương pháp mã nguồn mở, nhìn từ góc độ quản lý rủi ro
• Dùng Data Flow Diagram (DFD) mô phỏng luồng dữ liệu
• Mô hình CRUD: Create, Read, Update, Delete — ai được làm gì?
• Gán risk value cho từng threat, sau đó ưu tiên biện pháp kiểm soát theo risk value

VAST

Visual, Agile, and Simple Threat — thiết kế cho môi trường doanh nghiệp lớn:

• Tự động hóa threat modeling
• Tích hợp vào toàn bộ SDLC và DevOps tools
• Cộng tác đa bên: developer, architect, security team, executives

DREAD

Dùng để scoring/rating mức độ nghiêm trọng của threats:

Mỗi tiêu chí chấm 1–10, tổng điểm = mức độ ưu tiên xử lý.

OCTAVE

Operationally Critical Threat, Asset, and Vulnerability Evaluation:

• Xác định tài sản CNTT quan trọng
• Đánh giá threats đến CIA của các tài sản đó
• Xác định risk tolerance của tổ chức
• Ưu tiên và lên kế hoạch giảm thiểu

5.4 Công cụ Threat Modeling

6. Secure Code – Lập trình an toàn

6.1 Lựa chọn Framework và Ngôn ngữ

6.2 Untrusted Data – Nguyên tắc xử lý input

Mọi dữ liệu đến từ bên ngoài (user input, API response, file upload…) đều phải coi là không tin cậy.

Ứng dụng:

• Reflected XSS / URL Redirect: Validate input + verify redirect URL trong approved list
• SQL Injection: Dùng parameterized queries / prepared statements
• Stored XSS: Output encode khi render dữ liệu từ DB ra UI

6.3 Các vấn đề Secure Code quan trọng

HTTP Methods

Disable mọi HTTP method không sử dụng. Nếu chỉ dùng GET/POST, thì PUT, DELETE, PATCH, TRACE… phải bị block ở WAF hoặc server config.

Identity Management

• Không tự xây authentication system từ đầu nếu có thể dùng giải pháp có sẵn (Active Directory, Keycloak…)
• Nếu cần custom: dùng OAuth 2.0 / OpenID Connect
• Không bao giờ implement crypto hay auth protocol tự chế

Authentication & Authorization

Authentication: "Bạn là ai?" → verify identity
Authorization:  "Bạn được làm gì?" → enforce permissions

Hai thứ này phải luôn làm phía server, không thể tin client.

Session Management

• Session ID phải đủ entropy (128+ bits)
• Regenerate session ID sau khi login (chống session fixation)
• Session timeout hợp lý
• Invalidate session khi logout hoàn toàn phía server

Bounds Checking

• Với C/C++: luôn kiểm tra buffer size trước khi write
• Với bất kỳ ngôn ngữ nào: validate array index, string length trước khi thao tác

Error Handling, Logging & Monitoring

• Fail safe: khi lỗi xảy ra → từ chối truy cập, không phải cho phép
• Không expose stack trace ra ngoài (information disclosure)
• Log đủ thông tin để audit: timestamp, user, action, result
• Alert cho SIEM khi phát hiện anomaly

6.4 CWE Top 25 (2022) – Các lỗi phổ biến nhất

6.5 Secure Coding Baselines

Ví dụ baseline rule (Java):

// ❌ VULNERABLE - Dùng Random cho security-sensitive context
Random rnd = new Random();
String sessionId = String.valueOf(rnd.nextLong());

// ✅ SECURE - Dùng SecureRandom
SecureRandom rnd = new SecureRandom();
byte[] bytes = new byte[16];
rnd.nextBytes(bytes);
String sessionId = Base64.getEncoder().encodeToString(bytes);

java.util.Random dùng thuật toán linear congruential — có thể predict được output. java.security.SecureRandom dùng CSPRNG (Cryptographically Secure Pseudo-Random Number Generator).

6.6 Secure Coding Standards & Resources

OWASP Secure Coding Checklist bao gồm: Input Validation · Output Encoding · Authentication & Password Management · Session Management · Access Control · Cryptographic Practices · Error Handling & Logging · Data Protection · Communication Security · System Configuration · Database Security · File Management · Memory Management

7. Phân tích mã nguồn: SAST vs DAST

7.1 So sánh

7.2 Công cụ SAST phổ biến

7.3 Khi nào dùng SAST trong CI/CD

2 cách tích hợp:

1. IDE Plugin: Feedback real-time khi code, giống spell-check
2. Daily/CI scan: Chạy tự động, tạo báo cáo, block deploy nếu critical issue

7.4 Tiêu chí chọn công cụ SAST

8. Các lỗi thường gặp (Common Pitfalls)

8.1 CSRF – Cross-Site Request Forgery

Phòng tránh:

• CSRF Token: Token ngẫu nhiên trong form, verify phía server
• SameSite Cookie: SameSite=Strict hoặc Lax
• Re-authentication cho giao dịch quan trọng

8.2 SSRF – Server-Side Request Forgery

Ví dụ: App cho phép fetch URL từ user input. Attacker gửi http://169.254.169.254/latest/meta-data/ → lấy AWS instance metadata, credentials.

Phòng tránh:

• Whitelist các domain được phép fetch
• Disable unnecessary URL schemes (file://, gopher://)
• Network segmentation

8.3 Insecure Deserialization

Serialization:   Object → Bytes (để lưu/truyền)
Deserialization: Bytes → Object (để dùng lại)

Vấn đề: Nếu attacker kiểm soát được dữ liệu serialized (cookie, request body…) và app deserialize mù quáng → RCE, privilege escalation.

Ví dụ (Java):

// ❌ VULNERABLE
ObjectInputStream ois = new ObjectInputStream(request.getInputStream());
Object obj = ois.readObject(); // Deserialize trực tiếp từ user input!

// ✅ SAFER - Validate type trước
ObjectInputStream ois = new ObjectInputStream(request.getInputStream());
Object obj = ois.readObject();
if (!(obj instanceof ExpectedClass)) {
    throw new SecurityException("Unexpected type");
}

Phòng tránh tốt nhất: Dùng JSON/XML thay vì native serialization khi có thể. Nếu phải dùng: chỉ deserialize từ nguồn tin cậy, validate type.

8.4 Race Condition

Xảy ra khi hai tiến trình/thread cùng truy cập shared resource mà không có synchronization đúng.

Ví dụ kinh điển – TOCTOU (Time-of-Check to Time-of-Use):

// Thread A:
if (balance >= 100) {       // Check: balance = 200 ✓
    // ← Thread B chen vào ở đây và rút 150
    balance -= 100;         // Use: balance = 200 - 100 = 100 (sai! phải là 50)
}

// Kết quả: overdraft!

Phòng tránh: Mutex/lock, atomic operations, optimistic locking với version check trong DB.

9. Secure Testing & Deployment

9.1 Các loại kiểm thử an toàn

9.2 White Box vs Black Box Testing

9.3 Security Testing trong SDLC

9.4 Phạm vi kiểm thử

• Kiểm thử mã nguồn (source code)
• Kiểm thử ứng dụng (application layer)
• Kiểm thử hạ tầng (infrastructure/OS/container)
• Kiểm thử cơ sở dữ liệu
• Kiểm thử API và Web Services
• Kiểm thử tích hợp
• Kiểm thử mạng

10. SSDF – Secure Software Development Framework

NIST SP 800-218 — framework để giảm thiểu rủi ro lỗ hổng phần mềm, gồm 4 nhóm practice:

PO – Prepare the Organization

• Định nghĩa security requirements rõ ràng cho toàn tổ chức, update ít nhất hàng năm
• Bảo mật và hardening build systems như production systems
• Training developer về secure coding

PS – Protect the Software

• Code signing: Ký digital signature lên executable để đảm bảo integrity
• Dùng Certificate Authority đã được thiết lập để verify release integrity
• Chia sẻ SBOM (Software Bill of Materials) — danh sách đầy đủ các component

PW – Produce Well-Secured Software

• Tái sử dụng established, well-secured libraries thay vì tự implement
• Thực hiện clean builds trong môi trường build được kiểm soát chặt chẽ
• Áp dụng principle of least privilege cho mọi component

RV – Respond to Vulnerabilities

• Thiết lập vulnerability disclosure program
• Monitor vulnerability databases (NVD, CVE, vendor advisories)
• Có sẵn security response playbook
• Phân tích root cause và record vào wiki
• Deliver remediations có automation

11. DevOps & DevSecOps

11.1 DevOps là gì?

DevOps = Development + Operations — văn hóa làm việc kết hợp team phát triển và vận hành, tập trung vào:

Lợi ích:

• CI/CD: tự động hóa build, test, deploy
• Phát hiện và sửa lỗi nhanh hơn
• Rollback nhanh khi có vấn đề
• Monitoring liên tục

11.2 DevSecOps

DevSecOps = tích hợp Security vào toàn bộ DevOps pipeline:

CI (Continuous Integration) → build, SAST, unit test
CD (Continuous Delivery)    → deploy to staging, DAST, integration test  
CI (Continuous Inspection)  → ongoing security scanning, monitoring

Gartner DevSecOps Toolchain:

11.3 Continuous Inspection – Java Security Example

SAST Tools:

SpotBugs + Find Security Bugs → static analysis
PMD                           → code quality + security
SonarQube                     → comprehensive dashboard

DAST Tools:

OWASP ZAP → scan running web app
            → discover exposed endpoints
            → test OpenAPI/REST/WebSocket
            → intercept browser traffic

Dependency Analysis:

OWASP Dependency Check → map dependencies to CVE database
                       → CVSS score cho từng vulnerability
                       → tích hợp Maven/Jenkins/SonarQube

Container Security:

Anchore Engine → analyze Docker images
               → check OS packages, libs trong container
               → policy enforcement trước khi deploy

Câu hỏi thảo luận & Trả lời

Câu hỏi trắc nghiệm

Câu 1. CIA Triad trong bảo mật thông tin bao gồm những thuộc tính nào?

• A. Confidentiality, Integrity, Authentication
• B. Confidentiality, Integrity, Availability
• C. Confidentiality, Identity, Authorization
• D. Control, Integrity, Availability

Câu 2. Nguyên tắc “Shifting Left” trong SSDLC có nghĩa là gì?

• A. Chuyển toàn bộ security testing sang team DevOps
• B. Đưa security vào giai đoạn cuối của SDLC để kiểm tra tổng thể
• C. Tích hợp security càng sớm càng tốt trong vòng đời phát triển
• D. Giảm số lượng security requirements để tăng tốc độ phát triển

Câu 3. Sự khác biệt cơ bản giữa Design Flaw và Security Bug là gì?

• A. Design Flaw do hacker tạo ra, Security Bug do developer gây ra
• B. Design Flaw là lỗi kiến trúc/logic cho phép hành động không được phép; Security Bug là lỗi implementation cho phép dùng app độc hại
• C. Design Flaw nghiêm trọng hơn Security Bug về mọi mặt
• D. Security Bug chỉ xảy ra ở backend, Design Flaw chỉ ở frontend

Câu 4. STRIDE là phương pháp threat modeling, trong đó chữ “T” đại diện cho mối đe dọa nào?

• A. Trust Violation
• B. Tampering
• C. Token Theft
• D. Threat Escalation

Câu 5. CVE-2021-44228 (Log4Shell) là ví dụ điển hình của loại lỗ hổng nào trong OWASP Top 10 2021?

• A. Broken Access Control
• B. Cryptographic Failures
• C. Insecure Design
• D. Injection

Câu 6. Phương pháp DREAD được dùng để làm gì trong threat modeling?

• A. Mô tả kiến trúc hệ thống
• B. Xác định các tài sản cần bảo vệ
• C. Đánh giá và cho điểm mức độ nghiêm trọng của threats
• D. Tạo Data Flow Diagram

Câu 7. “Parameterized queries” được dùng để phòng chống loại tấn công nào?

• A. Cross-Site Scripting (XSS)
• B. SQL Injection
• C. Cross-Site Request Forgery (CSRF)
• D. Path Traversal

Câu 8. Trong input validation flowchart, khi user input được dùng để render ra màn hình, bước bắt buộc phải thực hiện là gì?

• A. Mã hóa input bằng AES
• B. Output encoding trước khi render
• C. Hash input bằng SHA-256
• D. Lưu input vào DB trước

Câu 9. java.util.Random không nên dùng cho mục đích security-sensitive vì lý do gì?

• A. Nó quá chậm so với SecureRandom
• B. Nó không có sẵn trong mọi JVM version
• C. Output của nó có thể được dự đoán (predictable)
• D. Nó không hỗ trợ seed

Câu 10. SAST khác DAST ở điểm cơ bản nào?

• A. SAST chỉ test security, DAST test cả performance
• B. SAST phân tích code không chạy, DAST test ứng dụng đang runtime
• C. SAST do external team thực hiện, DAST do internal team
• D. SAST dùng cho web app, DAST cho mobile app

Câu 11. Defense in Depth là gì?

• A. Chỉ dùng firewall mạnh nhất để bảo vệ hệ thống
• B. Triển khai nhiều lớp bảo mật độc lập để nếu một lớp thất bại, các lớp khác vẫn bảo vệ
• C. Mã hóa tất cả dữ liệu với nhiều thuật toán khác nhau
• D. Backup dữ liệu theo nhiều chiều

Câu 12. Nguyên tắc “Least Privilege” trong Secure Design có nghĩa là gì?

• A. Người dùng phải có ít nhất một quyền để sử dụng hệ thống
• B. Mọi account/service chỉ được cấp đúng quyền tối thiểu cần thiết để thực hiện công việc
• C. Admin có ít quyền hơn user thông thường
• D. Không ai được phép có quyền admin

Câu 13. CSRF token hoạt động như thế nào để phòng tránh CSRF attack?

• A. Mã hóa toàn bộ request
• B. Server tạo token ngẫu nhiên nhúng vào form, verify khi nhận request — site khác không biết token này
• C. Token xác thực danh tính user
• D. Token là session ID được hash

Câu 14. SSRF (Server-Side Request Forgery) nguy hiểm vì điều gì?

• A. Tấn công trực tiếp vào database của server
• B. App thực hiện request đến internal resource với quyền của server, bypass firewall
• C. Inject script vào response của server
• D. Giả mạo identity của server

Câu 15. Insecure Deserialization có thể dẫn đến hậu quả nghiêm trọng nhất là gì?

• A. SQL Injection
• B. Remote Code Execution (RCE)
• C. Session Hijacking
• D. XSS

Câu 16. Race condition là gì và TOCTOU là dạng cụ thể nào?

• A. Lỗi mã hóa xảy ra đồng thời; TOCTOU là lỗi timeout
• B. Lỗi đồng bộ hóa khi nhiều thread dùng shared resource; TOCTOU là Time-of-Check to Time-of-Use
• C. Điều kiện chạy đua trong mạng; TOCTOU là giao thức TCP
• D. Lỗi timing trong crypto; TOCTOU là loại timing attack

Câu 17. OWASP Dependency Check làm gì trong CI/CD pipeline?

• A. Kiểm tra code style của developer
• B. So sánh các thư viện third-party trong project với cơ sở dữ liệu CVE đã biết
• C. Scan network traffic của ứng dụng
• D. Kiểm tra certificate của HTTPS endpoints

Câu 18. Trong DevSecOps, “Continuous Inspection” khác với “Continuous Integration” như thế nào?

• A. Continuous Inspection chạy sau khi deploy production
• B. Continuous Inspection tập trung vào security scanning liên tục (SAST, DAST, SCA) xuyên suốt pipeline
• C. Continuous Inspection chỉ do security team thực hiện, không tự động
• D. Chúng là cùng một khái niệm

Câu 19. SonarQube hỗ trợ điều gì trong quá trình phát triển phần mềm?

• A. Tự động deploy ứng dụng lên production
• B. Phân tích code tĩnh để phát hiện bugs, lỗ hổng bảo mật và “code smell”
• C. Quản lý project và assign task cho developer
• D. Tự động generate unit test

Câu 20. OWASP SAMM là gì?

• A. Công cụ scan lỗ hổng tự động
• B. Framework đánh giá maturity của chương trình bảo mật phần mềm trong tổ chức
• C. Danh sách top 10 lỗ hổng web application
• D. Chuẩn mã hóa cho ứng dụng web

Câu 21. Threagile khác với Microsoft Threat Modeling Tool ở điểm nào nổi bật?

• A. Threagile chỉ hỗ trợ Windows
• B. Threagile mô hình hóa bằng file YAML, tích hợp DevSecOps, sinh report tự động
• C. Microsoft Threat Modeling Tool miễn phí hơn
• D. Threagile chỉ dùng cho microservices

Câu 22. “Never Trust, Always Verify” (Zero Trust) trong Secure Design áp dụng như thế nào?

• A. Không tin tưởng bất kỳ vendor bên ngoài nào
• B. Mọi request đều phải được authenticate và authorize, kể cả từ internal network
• C. Không sử dụng bất kỳ third-party library nào
• D. Không tin tưởng kết quả của SAST tools

Câu 23. Tại sao production data không nên dùng trong môi trường development/testing?

• A. Dữ liệu production quá lớn, làm chậm môi trường dev
• B. Vi phạm privacy (PII exposure), rủi ro lộ dữ liệu thật nếu môi trường dev kém bảo mật
• C. Data format khác nhau giữa các môi trường
• D. License không cho phép dùng production data ở nơi khác

Câu 24. CWE-416 “Use After Free” là lỗi phổ biến trong ngôn ngữ nào và gây ra vấn đề gì?

• A. Python — gây memory leak
• B. Java — gây NullPointerException
• C. C/C++ — dùng pointer sau khi đã free() bộ nhớ, có thể gây RCE
• D. JavaScript — gây prototype pollution

Câu 25. NIST SSDF (SP 800-218) bao gồm mấy nhóm practice chính?

• A. 3
• B. 4
• C. 5
• D. 7

Câu 26. Trong SSDF, SBOM (Software Bill of Materials) thuộc nhóm practice nào?

• A. PO – Prepare the Organization
• B. PS – Protect the Software
• C. PW – Produce Well-Secured Software
• D. RV – Respond to Vulnerabilities

Câu 27. Phương pháp PASTA khác STRIDE ở điểm nào cơ bản?

• A. PASTA chỉ dùng cho web application
• B. PASTA tập trung vào business risk và attack simulation; STRIDE tập trung vào threat categories kỹ thuật
• C. PASTA ít bước hơn STRIDE
• D. STRIDE do OWASP phát triển, PASTA do Microsoft

Câu 28. Anchore Engine trong DevSecOps pipeline có chức năng gì?

• A. Scan source code tìm security vulnerabilities
• B. Phân tích Docker container images để tìm vulnerabilities và enforce policy
• C. Monitor runtime behavior của containers
• D. Tự động patch vulnerabilities trong containers

Câu 29. Lý do cần disable các HTTP methods không sử dụng là gì?

• A. Tăng performance của web server
• B. Giảm attack surface — các method như PUT, DELETE, TRACE có thể bị khai thác
• C. Giảm log size của server
• D. Tuân thủ RESTful API standards

Câu 30. “Security through obscurity” là gì và tại sao không đủ để bảo mật?

• A. Mã hóa code bằng obfuscation — đủ nếu thuật toán đủ phức tạp
• B. Giữ bí mật implementation để tránh bị tấn công — không đủ vì attacker vẫn có thể reverse engineer
• C. Dùng port không phổ biến thay vì 443/80 — hoàn toàn hiệu quả
• D. Không công bố API documentation — biện pháp bảo mật tốt nhất

Câu 31. CWE Top 25 là gì và ai duy trì?

• A. OWASP duy trì, top 25 lỗ hổng web application phổ biến nhất
• B. MITRE duy trì, top 25 software weakness phổ biến và nguy hiểm nhất
• C. NIST duy trì, 25 CVE có CVSS score cao nhất
• D. SANS Institute, 25 attack technique phổ biến nhất

Câu 32. Session fixation attack là gì và cách phòng tránh?

• A. Attacker đoán session ID; phòng tránh bằng cách dùng ID dài hơn
• B. Attacker ép victim dùng session ID do attacker chọn; phòng tránh bằng regenerate session ID sau login
• C. Attacker steal session cookie; phòng tránh bằng HTTPS
• D. Attacker tạo nhiều session đồng thời; phòng tránh bằng rate limiting

Câu 33. Trong quy trình threat modeling, sau khi xác định được threats, bước tiếp theo là gì?

• A. Viết code để fix ngay lập tức
• B. Đánh giá khả năng xảy ra và mức độ ảnh hưởng, sau đó ưu tiên và lập kế hoạch giảm thiểu
• C. Báo cáo cho management và đợi quyết định
• D. Publish danh sách threats lên public để cộng đồng giúp fix

Câu 34. Công cụ nào sau đây là DAST tool?

• A. SonarQube
• B. SpotBugs
• C. OWASP ZAP
• D. Bandit

Câu 35. Tại sao không nên tự implement hệ thống authentication từ đầu?

• A. Vì các framework authentication đã được patent
• B. Vì authentication tự implement thường có nhiều edge cases security chưa được test kỹ, dễ có lỗ hổng nghiêm trọng
• C. Vì authentication library quá phức tạp, developer không thể hiểu
• D. Vì license các thư viện authentication đắt hơn

Câu 36. MobSF (Mobile Security Framework) chuyên dùng để làm gì?

• A. Scan vulnerabilities trong network của mobile device
• B. Static và dynamic analysis cho Android APK và iOS IPA
• C. Monitor mobile app performance
• D. Quản lý certificates cho mobile apps

Câu 37. Trong DevSecOps Gartner Model, RASP là gì và hoạt động ở giai đoạn nào?

• A. Remote Application Security Protocol — giai đoạn Planning
• B. Runtime Application Self-Protection — giai đoạn Deploy/Operate, bảo vệ app trong runtime
• C. Rapid Application Scanning Platform — giai đoạn Testing
• D. Risk Assessment Security Policy — giai đoạn Requirements

Câu 38. False positive rate cao trong SAST tool gây ra vấn đề gì?

• A. Bỏ sót nhiều lỗ hổng thật
• B. “Alert fatigue” — developer bắt đầu ignore alerts, có thể bỏ qua lỗ hổng thật
• C. Làm chậm build pipeline đáng kể
• D. Tốn quá nhiều storage cho logs

Câu 39. Trong CI/CD pipeline, “Quality Gate” của SonarQube hoạt động như thế nào?

• A. Tự động sửa code khi phát hiện lỗi
• B. Block merge/deploy nếu code không đạt threshold đã định (ví dụ: không có Critical security issue)
• C. Gửi email cho developer khi có lỗi
• D. Tự động tạo ticket Jira cho mọi issue

Câu 40. OCTAVE khác các phương pháp threat modeling khác ở điểm nào?

• A. Chỉ dùng cho hệ thống military
• B. Xuất phát từ góc độ tổ chức/business — xác định assets quan trọng, threats ảnh hưởng đến operational objectives
• C. Tự động hoàn toàn, không cần human input
• D. Chỉ phân tích network threats

Câu 41. Tại sao cần re-authentication khi thực hiện giao dịch quan trọng trong mobile banking?

• A. Để tăng thời gian xử lý, tránh double-spending
• B. Phòng tránh CSRF và session hijacking — verify user thực sự đang thực hiện giao dịch, không phải attacker dùng session đã chiếm
• C. Để log thêm thông tin cho audit
• D. Yêu cầu của ngân hàng trung ương

Câu 42. Lỗ hổng “Insecure Design” (A04:2021) là mới trong OWASP 2021. Điều này phản ánh vấn đề gì của ngành?

• A. Ngành đã giải quyết xong tất cả lỗi implementation
• B. Nhiều lỗ hổng nghiêm trọng bắt nguồn từ thiết kế sai về mặt security, không chỉ code bugs
• C. OWASP cần thêm category để đủ 10
• D. Các tools SAST đã phát hiện được hết implementation bugs

Câu 43. Trong Secure Code training, tại sao nên dùng case studies/ví dụ code có lỗ hổng thay vì chỉ liệt kê rules?

• A. Rules viết quá phức tạp, developer không đọc được
• B. Ví dụ thực tế giúp developer hiểu context, impact, và nhớ lâu hơn các rule trừu tượng
• C. OWASP yêu cầu phải dùng case studies
• D. Rules không cover được mọi trường hợp

Câu 44. Tại sao khi chọn framework, nên ưu tiên “phiên bản mới nhất hoặc mới-thứ-hai”?

• A. Phiên bản mới luôn có nhiều tính năng nhất
• B. Cân bằng giữa có security patches mới nhất và stability — phiên bản quá mới có thể chưa ổn định
• C. License của phiên bản cũ hơn đắt hơn
• D. Community support chỉ có cho 2 phiên bản mới nhất

Câu 45. Output encoding khác với input validation như thế nào?

• A. Output encoding diễn ra phía client, input validation phía server
• B. Input validation kiểm tra/từ chối input không hợp lệ; output encoding transform data khi render để browser không interpret là code
• C. Chúng là cùng một kỹ thuật với tên khác nhau
• D. Output encoding chỉ cần thiết khi dùng database

Câu 46. Trong STRIDE, “Elevation of Privilege” attack nào sau đây là ví dụ điển hình?

• A. Gửi nhiều request để làm server quá tải
• B. Modify cookie hoặc JWT token để đổi role từ “user” thành “admin”
• C. Chặn traffic giữa client và server
• D. Inject script vào trang web

Câu 47. “Evil brainstorming” trong threat modeling có nghĩa là gì?

• A. Brainstorm các tính năng xấu cần loại bỏ khỏi sản phẩm
• B. Team nhìn hệ thống từ góc độ kẻ tấn công để tìm ra các attack vector tiềm ẩn
• C. Mời ethical hacker từ bên ngoài vào brainstorm
• D. Tạo ra các user story cho evil users

Câu 48. CWE-352 (CSRF) được phòng tránh chủ yếu bằng cơ chế nào?

• A. Input validation
• B. CSRF token + SameSite cookie attribute
• C. Parameterized queries
• D. Output encoding

Câu 49. Trong DevOps pipeline, giai đoạn nào phù hợp để chạy Penetration Testing?

• A. Code commit
• B. Pre-production / Staging environment, trước khi deploy production
• C. Production environment sau khi deploy
• D. Planning phase

Câu 50. Khi một developer phát hiện vulnerability trong third-party library đang dùng, theo SSDF quy trình nên là gì?

• A. Xóa ngay library đó và tự implement lại
• B. Monitor vulnerability databases → assess impact → patch/update hoặc workaround → test → deploy với automation
• C. Chờ vendor tự fix rồi update
• D. Ẩn thông tin vulnerability để tránh bị exploit trước khi có patch

Câu 51. Path Traversal (CWE-22) tấn công như thế nào và phòng tránh ra sao?

• A. Inject SQL qua URL path; phòng tránh bằng parameterized queries
• B. Dùng ../ trong input để truy cập file ngoài phạm vi cho phép; phòng tránh bằng canonicalize path và whitelist
• C. Traverse toàn bộ DOM tree để tìm sensitive data; phòng tránh bằng CSP
• D. Enumerate users qua timing attack; phòng tránh bằng constant-time comparison

Câu 52. Tại sao Secret Management tool (Vault, AWS Secrets Manager) tốt hơn environment variables thông thường?

• A. Environment variables chậm hơn khi đọc
• B. Secret Manager cung cấp: audit log, rotation tự động, fine-grained access control, encryption at rest, short-lived tokens
• C. Environment variables không support Unicode
• D. Secret Manager miễn phí hơn

Câu 53. Trong user story của Secure Design, tại sao cần ghi cả “flaw có thể xảy ra”?

• A. Để có thêm documentation
• B. Để team awareness về risk ngay từ requirements phase, tích hợp security thinking vào design, tránh design flaws sau này tốn kém để sửa
• C. Để compliance với ISO 27001
• D. Vì OWASP yêu cầu trong security checklist

Câu 54. Tại sao OWASP Top 10 2021 đưa “Broken Access Control” lên vị trí #1 từ #5?

• A. Các loại tấn công khác đã được giải quyết hoàn toàn
• B. Dữ liệu CVE và penetration test reports cho thấy tần suất và impact của access control failures tăng đáng kể
• C. OWASP thay đổi methodology đánh giá
• D. Broken Access Control mới được phát hiện gần đây

Câu 55. “Code signing” trong SSDF PS group bảo vệ gì?

• A. Mã hóa source code để bảo vệ intellectual property
• B. Đảm bảo integrity của executable — verify rằng binary không bị tamper sau khi build
• C. Ký code review approval của developers
• D. Encrypt credentials trong code