16 KiB
CASAN — Bộ Q&A cho Team (hiểu sâu hệ thống + before/after tối ưu)
Mục đích: đảm bảo mọi thành viên hiểu sâu hệ thống, biết rõ trước/sau tối ưu đổi gì và VÌ SAO, trả lời được từ cơ bản đến nâng cao trước giám khảo/khách hàng. Nguyên tắc: mọi con số gắn nhãn [đo thật] (đã chạy, thấy exit code) hoặc [dự án tự báo / chưa đo]. Đúng tinh thần CASAN: "điểm = thứ chứng minh được, không bịa". Trọng tâm tối ưu lần này: H4 Security · H5 Governance · H6 AgentOps (đều từng là GAP: 20 / 25 / 30).
PHẦN A — CƠ BẢN: hệ thống là gì
A1. Dự án này thực chất là cái gì? Hai tầng: (1) sản phẩm là app OKR (NestJS + React + Prisma); (2) thứ thật sự được chấm là AI-SDLC pipeline — quy trình để AI tự sinh phần mềm, bao quanh bởi CASAN Harness (7 lớp điều khiển an toàn cho agent). App OKR chỉ là testbed để chứng minh harness chạy thật.
A2. "Harness" nghĩa là gì? Theo Martin Fowler (CASAN trích): "everything in an AI agent except the model itself" — toàn bộ lớp kỹ thuật bao quanh model để AI làm việc an toàn trong doanh nghiệp: ngữ cảnh, công cụ, kiểm định, bảo mật, quản trị, AgentOps, điều phối. Harness là thứ tạo khác biệt, không phải model (ai cũng gọi được cùng model).
A3. 7 harness (H1–H7) là gì?
H1 Context · H2 Tool · H3 Evaluation · H4 Security · H5 Governance · H6 AgentOps · H7 Orchestration. (Xem casan_harness_assessment.md.)
A4. CASAN gồm mấy cấp? 5 cấp: Curious → Augmented → Standard → Automated → Native. Dự án nhắm Level 4 (Automated) chứng minh được.
A5. Quy tắc vàng CASAN mà cả team PHẢI thuộc? (1) "Điểm = thứ chứng minh được bằng tấn công, không phải thứ khai báo" → có file ≠ có năng lực. (2) "Harness thấp nhất quyết định trần" → 1 harness yếu kéo cả pipeline xuống. (3) "Thu hẹp khoảng cách từ demo đến production".
A6. Cách chấm điểm 1 harness? Mỗi harness 0–100. Trung bình 7 harness + không có GAP (<30) → suy ra CASAN Level. Trên 80 và không GAP = Level 4.
PHẦN B — BEFORE/AFTER: tối ưu đổi những gì (casan-old → casan5)
B1. Insight lớn nhất của bản nâng cấp là gì?
Mã ứng dụng gần như KHÔNG đổi — backend 647 LOC giống hệt [đo thật], 8 API endpoint không đổi. Thứ nâng cấp là harness: .specify/scripts từ 3.127 → 4.301 LOC (+37,5%), 22 → 35 script (+13) [đo thật]. Đây là trưởng thành hoá governance, không phải thêm tính năng OKR.
B2. Trước tối ưu, 3 harness trọng tâm yếu thế nào?
Theo casan_harness_assessment.md mục 5: H4=20, H5=25, H6=30 — đều là GAP. H4 không có injection scan; H5 audit chỉ là text file (không bất biến); H6 chỉ có port check, không đo cost/drift.
B3. Nêu 3 thay đổi "chất" nhất (không phải thêm file)?
(1) H4: sửa bug fail-open thật — bản cũ security-check.sh dùng sai cú pháp [:space:] → trên grep hiện đại thoát rc=4, không chặn gì; bản mới chặn cả leetspeak (rc=2) [đo thật]. (2) H5: audit chain ký RSA — sửa 1 ký tự bị bắt AUDIT_HASH_MISMATCH [đo thật]. (3) H6: cost-spike đo token thật, bắt step tốn 3× → COST_SPIKE_DETECTED exit=2 [đo thật].
B4. Ngoài 3 harness trọng tâm, còn đổi gì?
DB SQLite → MySQL (production); frontend "test" từ tsc --noEmit giả → 16 vitest thật [đo thật]; thêm CI/CD (GitHub+Gitea), Docker + Nginx, tách khoá riêng khỏi git, redteam corpus, model-router.
B5. "Fail-open" là gì và vì sao nguy hiểm? Control gặp lỗi thì mở cửa cho qua thay vì chặn. Bản cũ khi grep lỗi cú pháp → thoát rc=4 → injection lọt hết. Nguy hiểm vì môi trường cũ (macOS/BSD) che mất, tưởng an toàn nhưng thực ra thủng. Bản mới fail-closed (lỗi thì chặn).
B6. Điểm trung bình harness đổi thế nào? Dự án tự báo ~81 → ~84 [dự án tự báo]. Tôi tự đo per-item ~83 [đo thật, per-harness ở Phụ lục C báo cáo].
PHẦN C — H4 · H5 · H6 SÂU (trọng tâm thi)
H4 — Security
C1. H4 bảo vệ chống gì? Prompt injection (trực tiếp + gián tiếp), obfuscation (leetspeak/whitespace), rò rỉ secret/PII, jailbreak — bám OWASP LLM01/LLM02/LLM06 + Agentic Top 10.
C2. Vì sao regex không đủ, phải cần model? Regex chỉ bắt câu đã biết. Câu paraphrase mới ("could you set aside the earlier guidance…") không trùng từ khoá → regex lọt (rc=0) [đo thật]. Model phân loại theo ngữ nghĩa bắt được. Đây là nguyên lý Computational × Inferential Blend.
C3. Con số recall thật là bao nhiêu?
Regex trên paraphrase mới = 0.00 [đo thật]. Frontier model (làm judge 30 mẫu) = 1.00 [đo thật phiên này]. ornith:9b ≈ 0.85 [dự án tự báo — đo bằng phase3-redteam-metrics.sh khi có Ollama].
C4. "Indirect injection" (gián tiếp) là gì?
Nhúng lệnh độc vào artifact (spec/plan) mà agent sẽ đọc, không phải input trực tiếp. artifact-scan.sh quét trước khi agent đọc → ARTIFACT_SCAN_BLOCKED reason=injection_detected exit=2 [đo thật]. Đây là loại MAESTRO nhấn mạnh (cross-layer L2→L3).
C5. Chuẩn hoá (normalization) để làm gì? Fold leetspeak (1gn0re→ignore), gộp khoảng trắng TRƯỚC khi match → né bằng biến thể trở nên vô ích.
H5 — Governance
C6. Audit chain hoạt động thế nào? Mỗi bản ghi hash nối tiếp bản trước (SHA-256 hash-chain) + ký RSA vào head. Sửa bất kỳ record nào → hash lệch → verify gãy.
C7. Vì sao cần ký RSA head, hash-chain chưa đủ? Hash-chain tự chứa: kẻ tấn công sửa 1 record rồi tính lại toàn chain thì hash vẫn khớp. Ký RSA head = mỏ neo ngoài kẻ tấn công không có private key → sửa xong không ký lại được → gãy.
C8. Chứng minh H5 bằng tấn công nào? Sửa high→LOW ở record 1 → verify in AUDIT_HASH_MISMATCH line=1 [đo thật]. Chuỗi bình thường → AUDIT_CHAIN_VALID [đo thật].
C9. H5 có cần model không? KHÔNG — toàn mật mã, chạy 100% offline. Đây là điểm quan trọng: H5 mạnh không phụ thuộc AI.
C10. Còn control H5 nào khác? secrets-scan (chặn commit .env/private key, PASS=6 [đo thật]); circuit-breaker-check (no-bypass: cấm --no-verify [đo thật]); tách khoá riêng khỏi git (chỉ public key trong repo).
H6 — AgentOps
C11. Câu hỏi chốt của H6 là gì? "Nếu một step đột nhiên tốn gấp 3 lần token, có ai biết không?"
C12. cost-spike-detect làm gì? Đọc provider-usage.jsonl, tính median total_tokens, flag step > 3× median. [đo thật] seed 4 record (median 220, plan=710) → SPIKE step=plan tokens=710 (>660) COST_SPIKE_DETECTED exit=2. Negative case → COST_SPIKE_NONE exit=0.
C13. Token đo từ đâu (không bịa)? Từ provider telemetry thật: Ollama trả prompt_eval_count + eval_count; OpenAI trả usage.prompt_tokens + completion_tokens. Không ước lượng.
C14. drift-detect là gì? So 2 artifact bằng difflib thật (similarity ≠ 1.0) → phát hiện model đổi hành vi. [đo thật] DRIFT_WARN similarity=0.7692.
C15. Vai trò AI local trong H6? Nguồn dữ liệu: mỗi lời gọi model ghi token thật vào provider-usage.jsonl. Logic cost-spike/drift là deterministic — model chỉ cấp dữ liệu, không quyết định.
C16. H6 còn thiếu gì để full điểm? Cần 1 lần chạy pipeline ≥3 step để có telemetry runtime thật (hiện offline chỉ có data seed). [chưa đo — cần chạy pipeline ở nhà].
PHẦN D — CÁC HARNESS CÒN LẠI (H1/H2/H3/H7)
D1. H1 Context? Đưa đúng artifact vào agent qua pipeline-context.yaml. [đo thật] CONTEXT_VALID checked=24 all referenced artifacts present.
D2. H2 Tool? Gọi tool đúng quyền, có audit + timeout + JSON-schema. [đo thật] TOOL_AUDIT_VALID records=18; validate-tool-input.sh chặn tool sai schema (TOOL_INPUT_INVALID exit=2); tool-exec.sh 2 -- <cmd treo> → TOOL_EXEC_TIMEOUT after 2s.
D3. H3 Evaluation? Gate AND(rule, model): plan thiếu tiêu chí → REJECT trước khi tốn model (fail-before); model trả rác → fail-closed. [đo thật] rule-path PASS=3 (model SKIP khi offline, non-blocking) + vitest 16/16.
D4. H7 Orchestration? Rollback thật (checkpoint→restore, before==after) + drift + fallback. [đo thật] adversarial PASS: H7 rollback genuinely restores the file.
D5. Vì sao H3 không phải trọng tâm lần này? Vì H3 đã tốt sẵn (bản cũ 85). Lần này dồn vào 3 GAP: H4/H5/H6.
PHẦN E — MODEL: local vs cloud, tự chủ
E1. Có OpenAI key thì bỏ được Ollama không? KHÔNG với code hiện tại. model-call.py nhánh cloud là stub: có key vẫn fail("cloud_backend_not_implemented_in_wave1") [đo thật đọc code]. Phải cài thêm ~20 dòng patch (xem CASAN_MASTER_RUNBOOK.md Mục 4).
E2. Còn cần Linux server không? Server chỉ để host Ollama. Có thể cài Ollama ngay trên Mac → bỏ server. Hoặc patch OpenAI → bỏ cả Ollama lẫn server.
E3. Vì sao local AI ghi điểm CASAN? Trụ cột Sovereign AI / Harness tự chủ: red-team corpus, spec, audit, telemetry không rời máy. Và tái lập offline — giám khảo replay không cần API key/mạng.
E4. ornith:9b là "trần" hay "sàn"? Sàn: đủ để thắng regex (0.00) và cấp telemetry thật, nhưng recall (~0.85) thua frontier (1.00). Nói thẳng điều này = đúng tinh thần "honest scope".
E5. Model chạm tới harness nào? Chỉ H4 (recall) và H6 (nguồn telemetry). H5 hoàn toàn không cần model. Phần lớn control là deterministic.
PHẦN F — NÂNG CAO: tấn công, MAESTRO, triết lý
F1. "Cross-layer attack chain" là gì? Chuỗi tấn công xuyên nhiều lớp MAESTRO: injection (L1) → lạm dụng tool (L3) → rò rỉ data (L2) → hành động sai (L4). Framework theo từng lớp riêng lẻ bỏ sót nó. Harness chặn ở nhiều lớp (defense-in-depth): H4 chặn đầu → H2 schema chặn tool → H4 timeout → H5 audit ghi lại.
F2. Stack 6 lớp bảo mật CASAN gồm gì? NIST AI RMF (quản trị rủi ro), OWASP LLM Top 10 + Agentic Top 10 (lỗ hổng ứng dụng), CSA MAESTRO (threat model 7 lớp), MITRE ATLAS (tri thức tấn công), ISO/IEC 42001 (chứng nhận), EU AI Act (pháp lý). Áp dụng tích luỹ theo cấp.
F3. Vì sao "có prompt-filter.yaml" không đủ điểm? Vì file chỉ khai báo ý định. Bản GHCP gốc có file "block jailbreak" nhưng leak private key do lỗi grep → chứng minh "có file ≠ có năng lực". Điểm chỉ tính khi chặn được tấn công thật.
F4. Vì sao "harness thấp nhất quyết định trần"? Vì kẻ tấn công đi vào chỗ yếu nhất. Dù H1/H3 = 90, nếu H4 = 0 (không chặn injection) thì trong production agent vẫn bị chiếm quyền → cả pipeline không thể gọi là Level 4 thật.
F5. L0–L5 (mức uỷ quyền AI) là gì? L0 quan sát → L1 nháp (người duyệt 100%) → L2 đề xuất → L3 thực thi rủi ro thấp → L4 vận hành workflow có hàng rào → L5 tự chủ cao trong vùng governance nghiêm ngặt.
F6. Vì sao app OKR "không đổi" lại là điểm mạnh, không phải điểm yếu? Vì nó chứng minh giá trị nằm ở harness tái sử dụng được cho bất kỳ sản phẩm nào — không phải sửa app cho đẹp. App là testbed cố định để so sánh công bằng.
PHẦN G — THỰC HÀNH / VẬN HÀNH
G1. Chạy full self-scoring bằng gì? bash .specify/scripts/bash/security-gate.sh → kỳ vọng PASS=10 FAIL=0 SKIP=0 (khi có model + node).
G2. Vì sao trên máy sạch harness "FAIL" lúc đầu? Do môi trường: thiếu python (script gọi python không phải python3), BSD grep, thiếu coreutils, hoặc msys fork trên Windows. Không phải control giả — vá xong là xanh. [đo thật: casan4 35/35 sau khi có python].
G3. Chạy pipeline để sinh telemetry H6? node scripts/run-casan-pipeline.mjs (cần model sống). Sinh provider-usage.jsonl + audit chain. Xem CASAN_MASTER_RUNBOOK.md Mục 5.
G4. Môi trường tái lập sạch nhất? Docker node:24-slim + apt python3 openssl git curl jq. [đo thật] đủ chạy 35/35, 43/43, cost-spike, vitest 16.
G5. Muốn secrets-scan sạch (không warning)? Chạy trong git repo thật (git init) — vì nó dùng git ls-files.
PHẦN H — CÂU HỎI BẪY / PHẢN BIỆN (test hiểu sâu)
H1. "Điểm ~84 là bạn tự chạy ra đúng không?" Không hoàn toàn — số gốc là casan5 tự chấm. Tôi tự chạy per-item xác nhận ~83 và ghi rõ cái nào VERIFIED, cái nào chờ Ollama (recall 9B, telemetry H6). Trung thực là tiêu chí.
H2. "adversarial báo 44 PASS mà bạn chỉ ra 43?" Đúng — tôi tự đo 43 PASS offline; 1 chênh là 2 test model SKIP khi không có Ollama (non-blocking). macOS+Ollama mới đủ 44. Không giấu.
H3. "Cost-spike bạn demo bằng data seed, có phải bịa không?" Không — tôi chứng minh LOGIC control hoạt động bằng dữ liệu kiểm soát (positive + negative). Dữ liệu token THẬT đến từ chạy pipeline (Mục G3). Tôi nói rõ đâu là seed, đâu là runtime.
H4. "OpenAI key là chạy được ngay chứ gì?" Sai — cloud backend là stub chưa cài (đọc code). Nói "chạy ngay" là bịa.
H5. "Vì sao không tin 100% điểm của chính dự án?" Vì nguyên tắc CASAN: điểm phải chứng minh được bằng tấn công, không phải trích dẫn. Bản GHCP gốc từng bị thổi phồng (file "block jailbreak" nhưng leak).
H6. "Bản cũ chạy PASS=11 adversarial mà, sao bảo yếu?" Vì PASS=11 của bản cũ là ảo do môi trường cũ dung thứ bug. Trên grep hiện đại, security-check.sh bản cũ fail-open rc=4 — không chặn cả injection kinh điển [đo thật].
H7. "Nếu H6 chưa có telemetry runtime thì Level 4 có thật không?" Logic H6 đã chứng minh (cost-spike/drift chạy đúng). Chỉ thiếu dữ liệu runtime — cần 1 lần chạy pipeline. Theo "harness thấp nhất quyết định trần", H6 (~82) đang là mục cần đóng nốt để chắc trần.
H8. "Khác biệt casan-old vs casan5 trong 1 câu?" "casan-old thắng được một buổi demo; casan5 sống sót trong production" — vì control giờ chặn được tấn công thật, có exit code, không phải "có file".
PHẦN I — CHECKLIST HIỂU BÀI (tự kiểm tra thành viên)
Thành viên đạt nếu trả lời được:
- 3 harness trọng tâm + điểm GAP cũ (H4=20, H5=25, H6=30).
- Bug fail-open
[:space:]của bản cũ và cách bản mới sửa. - Vì sao ký RSA head (chống re-forge chain).
- Câu hỏi chốt H6 + cách cost-spike trả lời (exit=2).
- Regex 0.00 vs model recall — vì sao cần semantic.
- OpenAI hiện là stub, muốn dùng phải patch.
- Vai trò AI local: chỉ chạm H4/H6, H5 độc lập; giá trị lớn là tự chủ dữ liệu.
- Phân biệt [đo thật] vs [dự án tự báo].
Tài liệu này bám bằng chứng đã kiểm chứng trong repo. Nhãn [đo thật] = có exit code thật (Docker node:24-slim + WSL, 2026-07-02). Tham chiếu: CASAN_OLD_vs_CASAN5_Executive_Assessment.md, CASAN_MASTER_RUNBOOK.md, casan_harness_assessment.md, FPT_CASAN_Full.md.