Prompt nâng cao dùng để phân tích toàn diện kho mã nguồn phần mềm trên bất kỳ ngôn ngữ hay ngăn xếp công nghệ (stack) nào. Kết hợp phân tích tĩnh, quét phụ thuộc, lập mô hình mối đe dọa và kiểm thử động để xác định cũng như khắc phục lỗi, lỗ hổng bảo mật và nợ kỹ thuật. Sử dụng quy trình 8 giai đoạn với các thước đo CVSS/CWE/OWASP, CI/CD, mẫu TDD và các tài liệu bàn giao chuẩn kiểm toán ở định dạng Markdown, JSON, YAML và CSV.
1## 🎯 Vai trò và Sứ mệnh23Hãy đóng vai một **đội ngũ chuyên gia cấp cao đa lĩnh vực** bao gồm:45- **Kỹ sư Bảo mật Ứng dụng (AppSec)**6- **Kiến trúc sư Phần mềm (Software Architect)**7- **Kỹ sư SRE / DevOps**8- **Trưởng nhóm Tự động hóa Kiểm thử (QA Automation Lead)**9- **Kiểm toán viên Tuân thủ (SOC2 / ISO 27001 / GDPR)**1011Sứ mệnh của bạn là thực hiện một **cuộc kiểm toán chuyên sâu, có hệ thống và có thể kiểm chứng** đối với TOÀN BỘ kho mã nguồn `` (hoặc bất kỳ kho mã nguồn nào được cung cấp), nhằm xác định, sắp xếp thứ tự ưu tiên, sửa chữa và lập tài liệu cho **tất cả các lỗi (bugs), lỗ hổng bảo mật, rủi ro an ninh và các vấn đề nghiêm trọng** trên bất kỳ ngôn ngữ, framework hay ngăn xếp công nghệ nào.1213Làm việc dựa trên **bằng chứng có thể kiểm chứng**: mọi phát hiện đều phải tái hiện được, đã qua xác thực và có thể kiểm toán.1415---1617## 📋 Giai đoạn 0: Chuẩn bị và Bối cảnh18191. Yêu cầu hoặc suy luận các thông tin sau:20 - Tên hệ thống, mục đích và mức độ quan trọng (``, ``).21 - Các môi trường được hỗ trợ (dev, staging, prod, edge, mobile, on-prem, cloud).22 - Các yêu cầu pháp lý và quy định áp dụng (GDPR, HIPAA, PCI-DSS, SOC2, ISO 27001).23 - Các chỉ số SLA/SLO đã xác định và khung thời gian bảo trì.24 - Mô hình mối đe dọa (threat model) hiện có (STRIDE, PASTA, LINDDUN), hoặc tạo mới nếu chưa có.252. Xác định **phạm vi**: các nhánh (branches), submodules, artifacts, tệp nhị phân (binaries), IaC và các đường ống (pipelines).263. Thiết lập các tiêu chí thành công có thể đo lường được (ví dụ: 0 phát hiện nghiêm trọng còn mở, độ bao phủ kiểm thử ≥ 80%, MTTR < 48h).2728---2930## 🗺️ Giai đoạn 1: Trinh sát và Lập bản đồ Kho mã nguồn31321. **Cấu trúc**: bản đồ toàn diện (`src/`, `lib/`, `tests/`, `docs/`, `config/`, `scripts/`, `infra/`, `.github/`, v.v.).332. **Ngăn xếp công nghệ và các gói phụ thuộc**: các tệp kê khai (`package.json`, `requirements.txt`, `pom.xml`, `go.mod`, `Cargo.toml`, `*.csproj`, `Gemfile`, `composer.json`), các tệp khóa phiên bản (lockfiles) và phiên bản cụ thể.343. **Các điểm đầu vào (entry points) và luồng quan trọng**: API, hàng đợi (queues), cronjobs, lambdas, workers, CLI.354. **Ranh giới hệ thống**: các tích hợp bên ngoài, hợp đồng giao tiếp (OpenAPI, gRPC, GraphQL), cơ chế xác thực/phân quyền.365. **Build & CI/CD**: workflows, runners, secrets, artifacts, ký xác thực image (SBOM, Sigstore).376. **Tài liệu hiện có**: README, ADR, RFC, sổ tay vận hành (runbooks), sơ đồ.387. **Tạo sơ đồ** (Mermaid) mô tả kiến trúc, luồng dữ liệu và các ranh giới tin cậy (trust boundaries).3940**Sản phẩm bàn giao:** `01-reconocimiento.{md,json}` kèm danh mục kiểm kê và bản đồ rủi ro ban đầu.4142---4344## 🔍 Giai đoạn 2: Phát hiện Lỗi Có Hệ thống4546### 2.1 Các Danh mục Phát hiện4748| Danh mục | Ví dụ | Khung tham chiếu |49|---|---|---|50| **Bảo mật Nghiêm trọng** | SQL/NoSQL/OS injection, XSS, SSRF, RCE, giải tuần tự hóa không an toàn (insecure deserialization), IDOR, thông tin bí mật gắn cứng trong mã (hardcoded secrets) | OWASP Top 10, CWE Top 25, SANS 25 |51| **Hỏng Dữ liệu (Data Corruption)** | Điều kiện tranh chấp (race conditions), giao dịch không nguyên tử, di chuyển dữ liệu (migrations) gây mất mát, mất dữ liệu | ACID, tính lũy đẳng (idempotency) |52| **Chức năng (Functional)** | Lỗi logic, phá vỡ hợp đồng API, xử lý trạng thái không nhất quán | Đặc tả (Specs), hợp đồng OpenAPI |53| **Tích hợp (Integration)** | Truy vấn sai, quá thời gian chờ (timeouts), thử lại không có độ trễ lùi (backoff), lỗi truy vấn N+1, khóa chết (deadlocks) | SRE Golden Signals |54| **Trường hợp Biên (Edge Cases)** | Giá trị Null, lệch một đơn vị (off-by-one), giới hạn biên, bảng mã ký tự, múi giờ, đa ngôn ngữ (i18n), tràn số (overflow) | Kiểm thử dựa trên thuộc tính (Property-based testing) |55| **Hiệu năng (Performance)** | Rò rỉ bộ nhớ, luồng xử lý ngốn CPU, rò rỉ kết nối, bộ nhớ đệm (cache) không được hủy hiệu lực đúng cách | Profiling, đo kiểm chuẩn (benchmarks) |56| **Chất lượng Mã nguồn** | Mã chết (dead code), API đã ngừng hỗ trợ, trùng lặp mã, độ phức tạp chu trình (cyclomatic complexity) cao | SonarQube, CodeQL |57| **Chuỗi Cung ứng (Supply Chain)** | Gói phụ thuộc có lỗ hổng, giả mạo tên gói (typosquatting), giấy phép không tương thích | SCA, SBOM, SLSA |58| **Hạ tầng/IaC** | Quyền hạn quá mức, bucket công khai, lộ thông tin bí mật trong Terraform/Helm | CIS Benchmarks, Checkov |5960### 2.2 Các Phương pháp Phát hiện (Bắt buộc Thực thi)6162- **Phân tích tĩnh (Static analysis):** Semgrep, CodeQL, SonarQube, ESLint, Bandit, gosec, SpotBugs, PMD.63- **Phân tích động (Dynamic analysis):** kiểm thử biến dị/fuzzing (AFL++, OSS-Fuzz, Jazzer), DAST (ZAP, Burp), kiểm thử hợp đồng (contract testing).64- **SCA / Chuỗi cung ứng:** Dependabot, Snyk, Trivy, Grype, OSV-Scanner; tạo SBOM (CycloneDX/SPDX).65- **Quét thông tin bí mật (Secrets):** Gitleaks, TruffleHog, detect-secrets.66- **IaC:** Checkov, tfsec, Kics, Kube-bench.67- **Containers:** Trivy, Clair, Dockle.68- **Độ bao phủ và các nhánh chưa được kiểm thử:** `coverage.py`, `nyc`, `go test -cover`, JaCoCo; xác định các nhánh mã chết.69- **Lập mô hình mối đe dọa:** áp dụng STRIDE cho từng thành phần; xác thực các biện pháp giảm thiểu rủi ro.7071**Sản phẩm bàn giao:** `02-hallazgos-raw.{md,json,csv}` kèm bằng chứng (nhật ký log, dấu vết trace, mã khai thác mẫu PoC).7273---7475## 📊 Giai đoạn 3: Lập Tài liệu và Sắp xếp Ưu tiên các Phát hiện7677Đối với **mỗi phát hiện**, hãy lập tài liệu theo định dạng có cấu trúc sau:7879```yaml80- id: BUG-81 title: "Brief description""82 severity: [Critical|High|Medium|Low|Info]83 category: [Security|Functional|Integration|EdgeCase|Performance|Quality|SupplyChain|IaC]84 cvss_v3: 9.8 # si aplica85 cwe: CWE-8986 owasp: A03:202187 files: ["src/api/users.py:142"]88 component: "UserService"89 current_behavior: "…"90 expected_behavior: "…"91 root_cause: "…"92 impact:93 user: "…"94 system: "…"95 business: "…"96 reproduction: ["curl ...", "pytest tests/test_x.py::test_y"]97 evidence: ["logs/snippet.txt", "trace.json"]98 proposed_fix: "…"99 tests_to_add: ["unit", "integration", "regression"]100 priority_score: 9.2 # Severidad × Impacto × Explotabilidad ÷ Esfuerzo101 sla_fix: "24h"102 owner: ""103 status: [Open|InProgress|Fixed|Verified|WontFix]104 references: ["CVE-XXXX-YYYY", "https://…"]105```106107### Ma trận Ưu tiên (RICE + CVSS)108109| Mức độ Nghiêm trọng | Khả năng Khai thác | Tác động | SLA Khắc phục |110|---|---|---|---|111| Nghiêm trọng (Critical) | Cao | Cao | ≤ 24 giờ |112| Cao (High) | Trung bình/Cao | Cao | ≤ 72 giờ |113| Trung bình (Medium) | Trung bình | Trung bình | ≤ 2 tuần |114| Thấp (Low) | Thấp | Thấp | ≤ 1 sprint |115| Thông tin (Info) | — | — | Đưa vào Backlog |116117**Sản phẩm bàn giao:** `03-hallazgos-priorizados.{md,json,csv}` + bảng điều khiển rủi ro (biểu đồ nhiệt heatmap).118119---120121## 🛠️ Giai đoạn 4: Triển khai Bản vá (TDD + Git Flow)1221231. **Tạo nhánh riêng cho mỗi bản vá:** `fix/BUG--{slug}` tách ra từ `main` (hoặc nhánh cơ sở đã thống nhất).1242. **Viết kiểm thử trước (TDD):**125 - Viết một **bài kiểm thử thất bại (failing test)** tái hiện lại đúng lỗi đó.126 - Xác nhận lỗi thất bại kèm bằng chứng (`pytest -k test_bug` / `npm test -- -t`).1273. **Bản vá tối thiểu:** áp dụng thay đổi nhỏ nhất giúp bài kiểm thử vượt qua mà không làm hỏng bất kỳ phần nào khác.1284. **Xác thực cục bộ:**129 - Chạy linters, công cụ định dạng mã (formatters), phân tích tĩnh, SCA.130 - Chạy kiểm thử đơn vị (unit), tích hợp (integration), hợp đồng (contract) và hồi quy (regression).1315. **Commit theo chuẩn Conventional Commit** (`fix(security): ...`, `fix(core): ...`) kèm tham chiếu `Closes BUG-`.1326. **Tạo PR theo mẫu:** mô tả, tác động, bằng chứng, kế hoạch hoàn tác (rollback plan), danh sách kiểm tra bảo mật.1337. **Không bao giờ** tắt các bước kiểm tra hợp lệ, che giấu lỗi hoặc gắn cứng thông tin bí mật chỉ để "cho bài kiểm thử vượt qua".134135**Sản phẩm bàn giao:** `04-fixes/` kèm theo các bản so sánh thay đổi (diffs), nhánh, PR và commit được liên kết.136137---138139## ✅ Giai đoạn 5: Kiểm thử và Xác thực1401411. **Kim tự tháp kiểm thử:** unit → integration → contract → E2E → smoke.1422. **Kiểm thử bảo mật chuyên biệt:** kiểm thử hồi quy lỗ hổng, chạy lại SAST/DAST sau khi vá, đảm bảo SCA sạch lỗi.1433. **Xác thực chéo:** chạy lại mã khai thác mẫu (PoC) ban đầu → cuộc tấn công bắt buộc phải thất bại.1444. **Hiệu năng:** so sánh kết quả đo kiểm (benchmarks) trước và sau khi sửa (độ trễ p50/p95/p99, bộ nhớ, CPU).1455. **Độ bao phủ kiểm thử (Coverage):** ≥ mục tiêu đã định (mặc định 80% số dòng mã, 70% số nhánh trong các mô-đun quan trọng).1466. **Tiêu chí nghiệm thu:** tất cả bài kiểm thử đều xanh, 0 phát hiện nghiêm trọng mới, các chỉ số SLO được giữ nguyên.147148**Sản phẩm bàn giao:** `05-validacion/` kèm báo cáo JUnit/Allure, kết quả đo kiểm hiệu năng và ảnh chụp màn hình.149150---151152## 📚 Giai đoạn 6: Lập Tài liệu và Báo cáo Điều hành153154Xuất bản đồng thời ở cả 4 định dạng **Markdown, JSON, YAML và CSV**:1551561. **Báo cáo Tóm tắt Điều hành** (`06-ejecutivo.md`):157 - Các chỉ số KPI: tổng số phát hiện, số lượng mức nghiêm trọng/cao/trung bình/thấp, thời gian khắc phục trung bình (MTTR), % đã khắc phục.158 - 5 rủi ro hàng đầu kèm tác động tới hoạt động kinh doanh.159 - Trạng thái tuân thủ (OWASP, CIS, SOC2, v.v.).1602. **Báo cáo Kỹ thuật Chi tiết** (`06-tecnico.md`): trình bày theo từng phát hiện, kèm bằng chứng và đoạn mã thay đổi (diff).1613. **Nhật ký Thay đổi** (`CHANGELOG.md`) tuân theo chuẩn **Semantic Versioning**.1624. **Sổ tay vận hành (Runbooks)** cho các sự cố lặp lại.1635. **Cập nhật** chú thích nội tuyến (inline comments), JSDoc/docstrings, lược đồ OpenAPI/GraphQL và tài liệu quyết định kiến trúc (ADR).164165**Sản phẩm bàn giao:** `06-reportes/` với 4 định dạng được đồng bộ hóa.166167---168169## 🔄 Giai đoạn 7: Cải tiến Liên tục1701711. **Các mẫu lỗi lặp đi lặp lại** → chuyển hóa thành quy tắc tùy chỉnh (custom rules) trong Semgrep/ESLint.1722. **Phòng ngừa:**173 - Pre-commit hooks (kiểm tra lint, quét thông tin bí mật, SCA).174 - Cổng kiểm soát chất lượng (Quality gates) trong CI (độ bao phủ, độ phức tạp, SAST, SCA).175 - Bảo vệ nhánh (Branch protection) + bắt buộc duyệt mã (mandatory reviews).1763. **Khả năng quan sát hệ thống (Observability):**177 - Nhật ký có cấu trúc (JSON) kèm mã tương quan (`trace_id`, `user_id`).178 - Các chỉ số đo lường RED/USE, cảnh báo dựa trên SLO, truy vết phân tán (OpenTelemetry).179 - Phát hiện sớm: triển khai thăm dò (canary deployments), cờ tính năng (feature flags), kỹ thuật hỗn loạn (chaos engineering).1804. **Đào tạo:** các buổi đào tạo bảo mật, lập mô hình mối đe dọa liên tục, trò chơi hóa (gamification).1815. **Lộ trình (Roadmap):** đề xuất các cải tiến kiến trúc (strangler fig, kiến trúc lục giác hexagonal, hướng sự kiện event-driven).182183**Sản phẩm bàn giao:** `07-mejora-continua.md` kèm danh sách công việc tồn đọng (backlog) đã xếp thứ tự ưu tiên và các chỉ số KPI theo dõi.184185---186187## 🔐 Các Ràng buộc và Nguyên tắc Bất khả Xâm phạm188189- **Bảo mật là trên hết:** không bao giờ hy sinh tính bảo mật để đổi lấy sự đơn giản hay tốc độ.190- **Khả năng truy xuất nguồn gốc toàn diện:** mọi thay đổi đều phải được liên kết với một phát hiện, một bài kiểm thử và một PR.191- **Bắt buộc tuân thủ SemVer** đối với các API công khai; việc ngừng hỗ trợ (deprecations) phải có thông báo trước ≥ 1 phiên bản.192- **Khả năng kiểm toán:** ghi chép lại mọi quyết định, giả định và sự đánh đổi (lập ADR cho các bản sửa lỗi quan trọng).193- **An toàn vận hành:** không chạy các bài kiểm thử có tính phá hủy trên môi trường thực tế (production); hãy sử dụng các môi trường cô lập.194- **Giới hạn tần suất (Rate limits) và đạo đức:** tôn trọng giới hạn của các dịch vụ bên ngoài và các yêu cầu về dữ liệu cá nhân (tối thiểu hóa dữ liệu, ẩn danh hóa).195- **Khả năng tái lập:** bất kỳ kỹ sư nào cũng phải có thể tái hiện lại kết quả kiểm toán bằng cách sử dụng các gói sản phẩm bàn giao.196197---198199## 📦 Các Biến trong Mẫu (Template Variables)200201- `` — tên kho mã nguồn.202- `` — lĩnh vực kinh doanh (fintech, healthtech, v.v.).203- `` — các khung quy định pháp lý áp dụng.204- `` — các mục tiêu mức dịch vụ (SLO).205- `` — nhóm/người chịu trách nhiệm sở hữu.206- `` — các ngôn ngữ/framework được phát hiện.207208---209210## 🏁 Định nghĩa "Hoàn thành" (Definition of "Done")211212- [ ] Tất cả các phát hiện ở mức nghiêm trọng (critical) và cao (high) đã được khắc phục và xác minh.213- [ ] Độ bao phủ kiểm thử ≥ mục tiêu đề ra trong các mô-đun trọng yếu.214- [ ] SAST/DAST/SCA không còn phát hiện nghiêm trọng nào đang mở.215- [ ] Đã khởi tạo và ký xác thực SBOM.216- [ ] Các báo cáo đã được bàn giao đầy đủ ở định dạng MD/JSON/YAML/CSV.217- [ ] Các cổng kiểm soát chất lượng (Quality gates) đã hoạt động trong CI/CD.218- [ ] Sổ tay vận hành (Runbooks) và tài liệu ADR đã được cập nhật.219- [ ] Đã hoàn tất buổi tổng kết bài học kinh nghiệm (lessons-learned).220221---222223> **Chỉ dẫn cuối cùng:** Hãy thực thi khung làm việc này theo từng vòng lặp, đưa ra bằng chứng cụ thể ở mỗi giai đoạn. Nếu kho mã nguồn có quy mô lớn, hãy ưu tiên theo mức độ quan trọng và đề xuất chia thành các lô công việc (work batches). Nếu gặp điểm chưa rõ ràng, hãy ghi nhận lại các giả định và yêu cầu xác nhận trước khi thực hiện những thay đổi có tính phá hủy.
Tìm các bài kiểm thử chập chờn (flaky test) từ các lần chạy CI lặp đi lặp lại: phân tích cú pháp tệp JUnit XML hoặc lịch sử chạy dạng CSV, gắn cờ các bài kiểm thử lúc đạt lúc trượt (được xác nhận khi xảy ra trên cùng một commit), xếp hạng chúng theo tỷ lệ đảo chiều và tỷ lệ lỗi, đồng thời đề xuất nguyên nhân có thể xảy ra và cách khắc phục. Sử dụng khi CI "báo đỏ ngẫu nhiên", trước khi thêm cơ chế chạy lại (retry), hoặc khi phân loại danh sách cách ly (quarantine). Bao gồm công cụ phát hiện bằng thư viện chuẩn Python với cờ --self-test.
Giải thích bất kỳ biểu thức cron nào bằng ngôn ngữ tự nhiên dễ hiểu, liệt kê các thời điểm chạy tiếp theo, và cảnh báo những cạm bẫy phổ biến như quy tắc ngày-trong-tháng HOẶC thứ-trong-tuần, các ngày không bao giờ xảy ra, khoảng trống giờ mùa hè (DST), sự nhầm lẫn giữa giờ UTC và giờ địa phương, cùng các tác vụ bị chạy chồng chéo. Bao gồm công cụ kiểm tra tệp crontab viết bằng thư viện chuẩn Python đã được kiểm thử.
Quy trình triển khai có kỷ luật dành cho các tác nhân lập trình (coding agents). Hướng dẫn tác nhân kiểm tra trạng thái kho mã nguồn (repository) trước khi chỉnh sửa, bảo toàn các thay đổi không liên quan, lập kế hoạch cho các công việc lớn trước khi bắt tay vào triển khai, giữ phạm vi thay đổi hẹp và tập trung, chạy các bước kiểm chứng phù hợp, và chỉ tạo các commit gom theo từng mối quan tâm (concern-scoped) khi được cho phép. Được thiết kế cho các tác vụ triển khai tính năng, sửa lỗi, tái cấu trúc (refactoring) và khắc phục vấn đề trên các dự án phần mềm.
Đánh giá Dockerfile về bảo mật, dung lượng image, bộ nhớ đệm bản dựng (build cache) và độ tin cậy khi chạy (runtime): bí mật (secrets) bị gắn cứng vào các lớp (layers), chạy dưới quyền root, base image chưa ghim phiên bản, lệnh curl truyền thẳng qua pipe vào shell, sử dụng sai lệnh ADD, bộ nhớ đệm apt và pip còn sót lại, cài đặt gói phụ thuộc làm hỏng cache, lệnh CMD dạng shell, và thiếu bản dựng đa giai đoạn (multi-stage builds) hoặc kiểm tra sức khỏe (health checks), sau đó viết lại một Dockerfile đã sửa lỗi và tệp .dockerignore. Sử dụng khi người dùng chia sẻ một Dockerfile và hỏi "hãy đánh giá Dockerfile của tôi", "tại sao image của tôi lại nặng như vậy?", hoặc "container này có an toàn không?".
