Ngày 18: Quiz Tổng Kết Tuần 3 — Secrets, Crypto & Supply Chain | Security

Bạn vô tình git push file .env chứa AWS access key lên public GitHub repo. Hành động ĐẦU TIÊN cần làm là gì?

A.Chạy `git filter-repo` để xoá `.env` khỏi historyB.Force push để overwrite remoteC.Rotate/deactivate AWS access key trong IAMD.Thêm `.env` vào `.gitignore`

Cặp .env + .env.example có vai trò khác nhau như thế nào?

A.`.env.example` là backup của `.env`B.`.env.example` được commit (template không có secret), `.env` chứa secret thật và bị gitignoreC.`.env` cho dev, `.env.example` cho productionD.Cả hai đều phải commit để team sync

Dynamic secret của HashiCorp Vault khác static rotation của AWS Secrets Manager ở điểm cốt lõi nào?

A.Dynamic nhanh hơn về API latencyB.Dynamic secret được tạo on-demand mỗi lần app request, có TTL ngắn (phút/giờ), mỗi instance có credential riêngC.Dynamic chỉ hỗ trợ database, static hỗ trợ mọi loại secretD.Dynamic miễn phí, static có phí

TLS 1.3 nhanh hơn TLS 1.2 trong handshake chính vì điều gì?

A.Dùng cipher suite ngắn hơn nên CPU tính nhanh hơnB.Giảm số RTT (round trip) từ 2 xuống 1 trước khi client gửi được application dataC.Bỏ certificate verification để tiết kiệm thời gianD.Dùng HTTP/3 thay vì HTTP/2

"Forward secrecy" trong TLS có nghĩa là gì?

A.Browser luôn forward request lên server gần nhấtB.Nếu server long-term private key bị compromise trong tương lai, traffic đã ghi lại trước đó vẫn không decrypt đượcC.Session key được forward giữa các connection để cacheD.Server forward client cert lên CA để verify

mTLS (mutual TLS) khác TLS thường ở điểm nào, và phù hợp nhất cho use case nào?

A.mTLS nhanh hơn TLS thường, phù hợp cho public websiteB.mTLS chỉ encrypt một chiều, không phù hợp cho productionC.mTLS yêu cầu CLIENT cũng có cert để server verify; phù hợp cho service-to-service trong microservice/zero-trustD.mTLS chỉ dùng được với TLS 1.0

Vì sao thực tế dùng "hybrid encryption" (asymmetric + symmetric) thay vì chỉ asymmetric?

A.Asymmetric không an toàn bằng symmetricB.Asymmetric quá chậm và không encrypt được data lớn; symmetric nhanh nhưng có vấn đề key distribution — hybrid kết hợp ưu điểm cả haiC.Hybrid là yêu cầu của FIPS 140D.Chỉ hybrid mới support forward secrecy

Trong envelope encryption với AWS KMS, "DEK" và "KEK" là gì?

A.DEK = Default Encryption Key, KEK = Key Exchange KeyB.DEK = Data Encryption Key (mã hoá data thực tế), KEK = Key Encryption Key (mã hoá DEK, không rời KMS)C.DEK và KEK là hai version của cùng một keyD.DEK dùng cho dev env, KEK dùng cho production

Tại sao dùng AES-ECB mode là sai lầm cơ bản trong cryptography?

A.ECB chậm hơn các mode khácB.ECB encrypt mỗi block độc lập — cùng plaintext block → cùng ciphertext block → pattern trong dữ liệu lộ raC.ECB không support AES-256, chỉ AES-128D.ECB không có integrity check (authenticate)

"Dependency confusion attack" hoạt động dựa trên cơ chế nào?

A.Attacker hack vào private registry của công tyB.Attacker publish package public cùng tên với internal package, dùng version cao hơn → resolver chọn version public (malicious)C.Attacker phishing maintainer để chiếm accountD.Attacker dùng homograph (Unicode lookalike) trong tên package

Vì sao npm ci được khuyến nghị trong CI thay vì npm install?

A.`npm ci` nhanh gấp 10 lầnB.`npm ci` strict với lockfile: fail nếu lockfile out-of-sync với package.json, không tự update lockfile → reproducible buildC.`npm ci` skip `node_modules` để tiết kiệm diskD.`npm ci` không kiểm tra integrity hash, không cần internet

Sigstore "keyless signing" khác với GPG signing ở điểm nào?

A.Sigstore dùng symmetric key thay vì asymmetricB.Sigstore không sign artifact, chỉ log timestampC.Sigstore dùng ephemeral key (sống vài phút) liên kết với OIDC identity, không cần maintain long-term private keyD.Sigstore chỉ hoạt động với container image

SPDX và CycloneDX khác nhau ở focus chính như thế nào?

A.SPDX dùng XML, CycloneDX dùng JSONB.SPDX focus mạnh vào license compliance (ISO standard), CycloneDX focus security/vulnerability (native VEX support)C.SPDX chỉ cho commercial software, CycloneDX cho open sourceD.Cả hai giống nhau, chỉ khác tên

Severity (CVSS score) và exploitability của một CVE trong app cụ thể của bạn khác nhau ra sao?

A.Severity và exploitability luôn giống nhauB.Severity là worst-case impact nếu exploit thành công (không biết context); exploitability là khả năng thực sự exploit được trong app của bạn (dựa vào call graph, input flow)C.Severity tính bởi vendor, exploitability tính bởi NVDD.CVSS score 10.0 luôn nghĩa là phải patch ngay trong giờ

Pattern --ignore-unfixed trong Trivy có ý nghĩa gì, và đánh đổi là gì?

A.Ignore mọi CVE, bỏ scan hoàn toànB.Ignore CVE chưa có version fix nào → giảm alert "noise actionable"; trade-off: phải background scan định kỳ để bắt khi fix có sẵnC.Ignore CVE đã fix trong code → chỉ báo CVE mớiD.Chỉ scan critical, ignore high