Tài liệu Redthread

Redthread là một Nền tảng bảo vệ ứng dụng AI-Native (ANAPP), được vận hành bởi Redthread. Nền tảng ưu tiên mô hình không cần agent — không cài đặt gì để mang lại giá trị cốt lõi — và mọi khả năng đều là một module bạn bật theo từng không gian làm việc từ một bảng điều khiển duy nhất.

Redthread bắt đầu bằng việc xây dựng bản đồ — bởi khi bạn chưa biết các tác nhân, mã nguồn, đám mây và hạ tầng của mình kết nối với nhau như thế nào, một danh sách phát hiện cũng chỉ là một danh sách. Redthread tập hợp một đồ thị duy nhất cho toàn bộ hệ thống của bạn — tác nhân, ứng dụng, mã nguồn, tài khoản đám mây, danh tính, các biện pháp kiểm soát bảo mật bạn đang vận hành và dữ liệu mà chúng có thể tiếp cận — và mọi module đều đọc và ghi vào cùng đồ thị đó, nên rủi ro bạn thấy đầu tiên là rủi ro trải qua nhiều lớp, chứ không phải một phát hiện riêng lẻ trong danh sách.

Trên bản đồ đó, nền tảng vận hành dưới dạng các module bạn bật theo từng không gian làm việc:

• Đánh giá rủi ro AI (Đánh giá & Hợp nhất) — cửa ngõ miễn phí, không cần agent: mọi hệ thống AI bạn đang chạy, các tổ hợp độc hại được xếp hạng trước tiên và ánh xạ tới OWASP Top 10 cho ứng dụng LLM và ứng dụng tác nhân; ngoài ra, kết nối không cần agent để nhận điểm tư thế bảo mật, các bề mặt AI chưa được giám sát, và một bản đồ thay thế cho các công cụ hiện có mà một module Redthread có thể thay thế, kèm phép tính dựa trên dữ liệu đầu vào cho ROI hợp nhất.
• Kiểm chứng khai thác (kiểm thử ứng dụng AI) — chứng minh các đường rủi ro cao nhất mà bước đánh giá xếp hạng: các tác nhân tự hành thăm dò chatbot, tác nhân và điểm cuối RAG của bạn theo OWASP LLM Top 10 (ánh xạ tới MITRE ATLAS); mọi phát hiện đều kèm bằng chứng khái niệm có thể tái hiện.
• Khám phá AI ngầm — lập danh mục mọi tính năng dùng AI trong toàn bộ hệ thống của bạn, kể cả những tính năng chưa ai đăng ký.
• Tư thế bảo mật đám mây & hạ tầng — kết nối đám mây không cần agent (không cài đặt gì) để lập bản đồ tài sản, danh tính và dữ liệu, phân loại kho lưu trữ nhạy cảm (DSPM) và làm lộ diện các đường tấn công liên đám mây.
• Dữ liệu đo lường điểm cuối (chỉ phát hiện) — một agent gọn nhẹ, tùy chọn, nằm trong phần lõi, chạy trên các bề mặt an toàn của hệ điều hành và báo cáo danh mục cùng tư thế bảo mật trên máy chủ. Agent không bao giờ chặn; khả năng ngăn chặn theo thời gian thực là tiện ích bổ sung từ đối tác nằm trong lộ trình.
• Agentic Trust & Protection Platform — cấp cho mọi tác nhân/danh tính một SPIFFE id và phát các sự kiện trạng thái tin cậy (safe/unsafe/revoked) có chữ ký, có TTL, dựa trên các khai thác đã chứng minh, để bộ điều phối, gateway và SIEM phản ứng trong vài giây. Xem Agentic Trust & Protection Platform.
• Kiểm soát CI/CD — quét trên mọi pull request và chặn lần merge có thể tạo ra một đường tấn công đã được chứng minh.
• Nền tảng liên tục — đánh giá lại theo lịch, kèm theo dõi sai lệch và xu hướng, để phạm vi bao phủ phản ánh đúng những gì đang chạy trên production trong tuần này.
• Khắc phục & báo cáo — hướng dẫn khắc phục rõ ràng và pull request nháp; Thư chứng thực, báo cáo kỹ thuật đầy đủ và một bản máy đọc được, được ánh xạ tới các khung tiêu chuẩn mà kiểm toán viên của bạn yêu cầu.
• Danh tính & truy cập — SSO, cấp phát SCIM, vai trò và nhật ký kiểm toán cho không gian làm việc của bạn.

Được chứng minh, không phải suy đoán. Một phát hiện là thứ mà công cụ thực sự đã tiếp cận hoặc khai thác được, kèm các bước chính xác để tái hiện; phạm vi bao phủ chỉ được khẳng định ở những nơi đồ thị thể hiện được. Nền tảng không cần agent và ưu tiên phát hiện — mọi hành động ngăn chặn/chặn đều là một ngoại lệ có chữ ký, do khách hàng chủ động bật và sở hữu, không bao giờ là mặc định, và mọi bản cập nhật chúng tôi đẩy tới cảm biến đều được triển khai theo từng giai đoạn qua cổng AI Rollout Safety (vòng canary, tự động dừng).

Tài liệu này bao gồm phần bắt đầu, kiến trúc nền tảng, khái niệm cốt lõi về cách nền tảng hoạt động, các hướng dẫntheo tác vụ, và toàn bộ Tài liệu tham chiếu API để bạn có thể điều khiển mọi module từ CI hoặc script của riêng mình.

Cập nhật mới nhất

31 tháng 10 năm 2026

• Báo cáo white-label. Ở các gói trả phí, chủ sở hữu đặt tên công ty, dòng liên hệ và logo tại Cài đặt → Chung → Thương hiệu báo cáo. Báo cáo tuân thủ và Thư chứng nhận khi đó ghi công ty bạn là bên phát hành, và Redthread được nêu là nền tảng trừ khi bạn chọn ô ẩn đi.
• Cập nhật cảm biến theo giai đoạn đã hoạt động. Bản dựng agent điểm cuối mới được kiểm tra, rồi đưa cho các vòng canary (1% → 10% → 50% → 100% số máy của bạn) và tự động dừng nếu một vòng không hoạt động bình thường trở lại.
• Một tài sản, chỉ nhập một lần. Quét kiểm thử xâm nhập giờ chọn từ các trang đã có trong hệ thống của bạn, và URL mới chỉ được lưu một lần. Quét thủ công một trang đã đăng ký sẽ dùng Tri thức và lịch sử của trang đó. Quét ngay, lịch quét, quét lại khi phát hiện thay đổi và trigger CI đều yêu cầu miền đã xác minh, giống quét thủ công. Quét hạ tầng có thể thêm một đám mây khác và ngắt kết nối riêng một đám mây.
• Lượt quét registry MCP hằng ngày nay bao phủ 53,270 máy chủ. Mỗi máy chủ đều có một khẳng định có chữ ký, và manifest có chữ ký của ngày được neo vào nhật ký Sigstore Rekor công khai. Lượt quét ngày 30 tháng 10 phát hiện 1,489 vụ tráo danh mục (tên nay dẫn tới một domain hoặc chủ sở hữu gói khác), 227 mục danh mục nêu một phiên bản chưa từng được xuất bản, và 35 gói được build từ một repository khác với repository đã khai báo. Xem số liệu trực tiếp.
• Định nghĩa công cụ được lấy dấu vân tay (bộ quy tắc atf-6). Với các máy chủ từ xa phản hồi mà không cần thông tin xác thực (hiện là 20,504), lượt quét ghi lại dấu vân tay sha256 của danh sách công cụ và đánh trượt máy chủ có công cụ thay đổi trong khi phiên bản không đổi, tức kiểu rug-pull. Cổng kiểm soát và các hook sẽ từ chối nó.
• Hook cho Claude Code và Cursor, cùng AIBOM (bản xem trước). atpp hook claude|cursor kiểm tra từng lệnh gọi công cụ MCP với khẳng định có chữ ký của máy chủ trước khi nó chạy. atpp check-config --cyclonedx ghi ra danh mục vật liệu (bill of materials) CycloneDX 1.6 của các máy chủ MCP bạn đã cấu hình.
• Enforce kiểm tra nội dung (bản xem trước). Gateway nay nhìn vào bên trong lưu lượng của agent để tìm chỉ thị prompt injection, bí mật bị gửi ra ngoài trong một yêu cầu, và danh sách công cụ MCP bị đầu độc. Nó chỉ quan sát cho đến khi bạn chuyển một danh tính sang chế độ thực thi, và nó khớp theo mẫu, nên một cách diễn đạt khác có thể lọt qua: đây chỉ là một lớp, không phải đảm bảo.
• Khóa ký của workspace đã được chuyển ra khỏi ứng dụng. Khóa dùng để ký các sự kiện tin cậy của bạn nay nằm trong một dịch vụ ký riêng, được niêm phong bằng một khóa từ Oracle Cloud Vault. Ứng dụng có thể yêu cầu một chữ ký nhưng không thể đọc hoặc sao chép khóa.
• Sổ cái tin cậy không thể bị chỉnh sửa. Các sự kiện tin cậy của agent được lưu trong PostgreSQL, và chính cơ sở dữ liệu từ chối cập nhật, xóa và cắt bớt (truncate) sổ cái, nên đảm bảo này không phụ thuộc vào việc ứng dụng hoạt động đúng.
• Báo cáo tuân thủ và Thư chứng thực mở ngay trong ứng dụng, theo từng tiêu chuẩn. Chọn SOC 2, ISO 27001, ISO 42001, PCI DSS v4.0, GDPR, HIPAA, NIST CSF, NIST AI RMF hoặc EU AI Act, rồi tải xuống (HTML, PDF, JSON) hoặc chia sẻ qua email hoặc Slack. Các chế độ xem này là đối chiếu chéo hỗ trợ kiểm toán, không bao giờ là chứng nhận. Xem Báo cáo & chứng thực.
• Website nhận biết bạn đã đăng nhập. Menu hiển thị Bảng điều khiển thay cho Đăng nhập, và một liên kết tài liệu cần đăng nhập sẽ đưa bạn trở lại đúng mục đó sau khi bạn đăng nhập.
• Dữ liệu tài khoản và phiên được ghi một cách an toàn. Việc ghi mang tính nguyên tử và có bản sao khôi phục, nên một sự cố sập không thể cắt cụt workspace của bạn, và một lần đọc thất bại không thể biến thành một workspace trống.

7 tháng 10 năm 2026

• Oracle Cloud kết nối được trên mọi tài khoản Oracle. Các tài khoản tạo từ năm 2023 dùng identity domain, vốn từ chối người dùng quét của chúng tôi vì người dùng này không có địa chỉ email. Thiết lập một cú nhấp giờ đã gán email cho người dùng đó, và người dùng, nhóm cùng chính sách của nó đều mang tên Redthread.
• Cảm biến endpoint cài đặt chỉ bằng một lệnh. Tạo khóa trong Estate Scan rồi dán một lệnh trên macOS, Linux hoặc Windows. Lệnh sẽ kiểm tra tệp tải về, cài một dịch vụ chạy nền, gửi báo cáo đầu tiên, và màn hình xác nhận khi máy xuất hiện. Lệnh gỡ cài đặt tương ứng nằm ngay trên cùng màn hình.
• Mọi máy đang gửi báo cáo đều được giữ lại trong hệ thống của bạn. Trước đây mỗi báo cáo mới thay thế toàn bộ danh sách, nên chỉ máy báo cáo sau cùng được hiển thị. Giờ mỗi báo cáo chỉ cập nhật đúng máy của nó, và cảm biến vẫn nằm trên đồ thị qua các lần quét lại đám mây.
• Cảm biến trên VM đám mây được gộp vào chính VM đó. Trên AWS, Oracle Cloud, Azure hoặc Google Cloud, cảm biến đọc ID instance của nó, nên một VM mà lần quét đám mây đã tìm thấy sẽ hiển thị thành một nút duy nhất với cả hai góc nhìn.
• VM đám mây hiện có, cài từ chính Cloud Shell của bạn. Một lệnh cho Oracle Cloud, Azure hoặc Google Cloud sẽ cài cảm biến trên mọi VM đang chạy, bằng chính phiên đăng nhập của bạn. Redthread không có quyền truy cập vào các VM của bạn.
• VM đám mây mới, cài ngay lần khởi động đầu tiên. Một script khởi động dành cho trường startup-script của VM sẽ cài cảm biến vĩnh viễn ngay lần đầu VM mới khởi động.
• Số lần quét pentest tăng theo quy mô hệ thống của bạn. Mỗi gói trả phí bao gồm một lần quét pentest mỗi tháng cho mỗi 10 workload (Starter 3, Growth 15, Enterprise từ 15 trở lên). Vượt quá mức đó, hãy dùng gói lượt quét hoặc trả tiền theo từng lần quét. Xem các gói.
• Toàn bộ hệ thống trên một bản đồ. Redthread Flow giờ mở ra với bản đồ hệ thống gồm mọi đám mây, máy và danh tính cùng các liên kết giữa chúng, kể cả liên kết giữa các đám mây. Sự cố đám mây và Đường tấn công có trang riêng trong menu bên trái.
• Mọi đám mây đã kết nối đều được quét. Khi kết nối nhiều hơn một đám mây (ví dụ AWS và Oracle Cloud), Quét hệ thống của tôi giờ quét từng đám mây, và các phát hiện cùng phần đồ thị của mỗi đám mây được giữ riêng, nên quét một đám mây không bao giờ thay thế đám mây khác.
• Máy Mac của bạn hiển thị theo tên. Máy Mac giờ hiển thị theo Computer Name, thay vì địa chỉ mạng.

Hướng dẫn: kết nối toàn bộ hệ thống của bạn

Mục tiêu: kết nối mọi nguồn một lần, để chỉ một lần Quét hệ thống của tôi là lập bản đồ toàn bộ website, mã nguồn, đám mây, máy móc và AI chạy trên đó. Mọi thứ ở đây đều chỉ đọc và kết nối miễn phí. Làm các bước theo thứ tự bất kỳ; mỗi làn trong Quét hệ thống chuyển sang màu xanh khi đã được kết nối.

Trước khi bắt đầu

1. Đăng nhập tại app.redthreadsec.com bằng email công việc của bạn.
2. Nhấp vào liên kết trong email xác minh. Các lần quét sẽ bị khóa cho đến khi bạn xác minh.
3. Mở Quét hệ thống. Đây là trang đầu tiên sau khi đăng nhập.

1. Website & ứng dụng

1. Trong chế độ xem Website & ứng dụng , dán địa chỉ website hoặc ứng dụng chính của bạn rồi thêm vào.
2. Lặp lại cho từng trang công khai. Không cần thông tin xác thực; chúng tôi chỉ đọc các trang công khai.
3. Để chạy pentest trên một trang sau này, trước tiên bạn cần chứng minh mình sở hữu trang đó (cách).

2. Mã nguồn

1. Trong chế độ xem Mã , nhấp Đăng nhập bằng GitHub.
2. Phê duyệt quyền truy cập chỉ đọc. Các kho mã của bạn sẽ được rà soát để tìm framework AI, bí mật và mã hạ tầng.

3. Đám mây & hạ tầng

Mỗi đám mây kết nối chỉ với một cú nhấp, bằng quyền chỉ đọc mà bạn có thể thu hồi ngay trong console của mình. Lần quét đầu tiên tự chạy ngay khi đám mây được kết nối.

• AWS: nhấp Mở AWS và tạo vai trò, đánh dấu xác nhận IAM, nhấp Create stack, đợi khoảng một phút, rồi nhập lại số tài khoản AWS gồm 12 chữ số vào Redthread. Bạn không phải người quản lý AWS? Hãy dùng Lấy liên kết để gửi cho họ.
• Azure: trong mục Không dùng AWS?, chọn Microsoft Azure, đăng nhập bằng Microsoft, phê duyệt Redthread, chọn subscription và nhấp Create.
• Google Cloud: chọn Google Cloud, đăng nhập bằng Google, phê duyệt, rồi chọn project cần quét.
• Oracle Cloud: chọn Oracle Cloud, nhấp Mở Oracle Cloud và tạo quyền truy cập rồi đăng nhập với tư cách quản trị viên. Đánh dấu I have reviewed and accept the Oracle Terms of Use, nhấp Tiếp theo hai lần, đánh dấu Run apply rồi nhấp Create. Quay lại Redthread; việc kết nối sẽ hoàn tất sau vài phút.

Các lần quét sau không chạy theo lịch: nhấp Quét hệ thống của tôi, hoặc Quét trên thẻ của một đám mây, để cập nhật các thay đổi.

4. Cảm biến endpoint (tùy chọn)

Cảm biến theo dõi một laptop, máy chủ hoặc VM đám mây và báo cáo phần mềm, cấu hình bảo mật cùng các công cụ AI đang chạy trên đó. Cảm biến không bao giờ chặn bất cứ thứ gì.

1. Trong chế độ xem Cài cảm biến endpoint , nhấp Tạo khóa đăng ký.
2. Laptop hoặc máy chủ: sao chép lệnh macOS hoặc Linux vào Terminal, hoặc lệnh Windows vào PowerShell. Trên máy chủ, hãy đặt sudo trước sh để cảm biến được cài cho toàn bộ máy. Màn hình sẽ báo khi máy bắt đầu gửi báo cáo.
3. VM đám mây bạn đang chạy: mở VM đám mây hiện có: cài trên tất cả, sao chép lệnh cho đám mây của bạn và dán vào Cloud Shell của đám mây đó. Trong Oracle Cloud, Cloud Shell nằm trong Developer tools ở góc trên bên phải; trong Azure và Google Cloud, đó là biểu tượng Cloud Shell ở đầu console. Lệnh sẽ cài trên mọi VM đang chạy và in ra bản tóm tắt. Trên AWS, hãy dùng lệnh cài đặt trên từng instance.
4. VM đám mây mới: mở VM đám mây mới: tự động cài đặt rồi dán script vào trường startup-script của VM khi tạo VM.
5. Để gỡ cảm biến: chạy lệnh trong mục Gỡ cài đặt trên máy đó.

5. Agent & dịch vụ AI

Không cần nhập gì. Chúng được phát hiện từ các nguồn ở trên và liệt kê trong danh mục AI của bạn.

6. Quét

1. Nhấp Quét hệ thống của tôi. Lệnh này lập bản đồ mọi thứ đã kết nối; không bao giờ trừ vào lượt quét pentest của bạn.
2. Mở đồ thị và Những gì chúng tôi tìm thấy để xem tài sản, AI trên đó và các đường tấn công giữa chúng.
3. Để chạy pentest chứng minh khai thác trên một ứng dụng, hãy bắt đầu một lần quét pentest. Gói Free bao gồm một lần trọn đời; các gói trả phí bao gồm một lần mỗi tháng cho mỗi 10 workload.

Bắt đầu nhanh — trên trình duyệt

Cách nhanh nhất để thấy kết quả. Không cần cài đặt, không cần thẻ.

1. Tạo tài khoản. Truy cập app.redthreadsec.com/app và đăng ký bằng email. Nên dùng email công việc; email cá nhân cũng được. Không cần thẻ.
2. Kết nối hệ thống của bạn. Bạn sẽ được đưa tới trang Quét hệ thống. Kết nối nhiều hay ít tùy bạn — URL website không cần thông tin xác thực, GitHub chỉ một cú nhấp, mỗi đám mây chỉ một cú nhấp, và cảm biến endpoint chỉ một lệnh cho mỗi máy; một kết nối đám mây chỉ đọc là bước tăng độ phủ lớn nhất. Hướng dẫn từng bước: kết nối toàn bộ hệ thống. Việc khám phá trên toàn bộ các nguồn này miễn phí và không giới hạn; thanh đo cho biết phần nào còn chưa được nhìn thấy, và không có gì chặn lần quét.
3. Xác minh email. Nhấp vào liên kết chúng tôi gửi cho bạn. Thao tác này mở khóa tính năng quét chủ động. (Chưa nhận được? Dùng "Gửi lại" trong ứng dụng.)
4. Chạy kiểm thử xâm nhập trên một mục tiêu. Đối với lần quét chủ động nhằm chứng minh khai thác, hãy dán URL staging của ứng dụng — địa chỉ đang chạy thực tế (không phải production). Bạn có thể kéo thả mã nguồn (tệp .zip) để quét sâu hơn. Nhấn Bắt đầu quét.
5. Theo dõi quá trình quét. Lần quét chạy trong một sandbox tách biệt và thường hoàn tất trong vài phút. Bạn sẽ thấy công cụ thăm dò từng hạng mục theo thời gian thực.
6. Đọc các phát hiện. Mỗi lỗ hổng đã được chứng minh đều có mức độ nghiêm trọng, mức độ ảnh hưởng và hướng dẫn khắc phục rõ ràng. Với gói trả phí, mọi phát hiện còn kèm bằng chứng khái niệm hoạt động được và bản khắc phục nháp.

Thích dùng ứng dụng? Redthread cũng có bản cho Mac và Windows tại trang tải xuống. Đây là cùng một sản phẩm trong cửa sổ riêng; dữ liệu của bạn nằm trên máy chủ, nên ứng dụng và trình duyệt luôn hiển thị cùng một không gian làm việc. Để đăng nhập, nhập email trong ứng dụng và mở liên kết được gửi qua email — trình duyệt sẽ hỏi có mở Redthread không và chuyển phiên đăng nhập sang ứng dụng (liên kết millenniums:// chỉ dùng được một lần và hết hạn sau 15 phút). Bộ cài đặt chưa được ký bằng chứng chỉ của Apple hoặc Microsoft, nên bản tải xuống sẽ bị chặn cho đến khi bạn xác nhận một lần. Trên Mac, lệnh cài đặt một dòng trong Terminal ở trang tải xuống giúp tránh hoàn toàn lời nhắc này; với tệp .dmg, bạn xác nhận một lần qua System Settings → Privacy & Security → Open Anyway. Trên Windows, nhấp More info → Run anyway.

Bắt đầu nhanh — với API

Muốn điều khiển từ terminal hoặc CI? Mọi thao tác của ứng dụng đều là một lệnh gọi REST. token truy cập của bạn được tạo khi đăng ký và hiển thị trong ứng dụng; token này được đặt trong header Authorization: Bearer .

1. Kiểm tra tài khoản

Xác nhận token hoạt động và xem gói cùng hạn mức còn lại của bạn.

curl https://app.redthreadsec.com/api/me \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

{ "tenant": "acme-3f9a2c", "plan": "starter", "plan_display": "Starter", "poc": true,
  "scans_used": 1, "scans_limit": 5, "apps_used": 1, "apps_limit": 1, "verified": true }

2. Bắt đầu quét

Cung cấp tham số target. Có thể thêm source (một repo hoặc đường dẫn) để quét hộp trắng sâu hơn nhiều, và tham số budget làm giới hạn chi phí.

curl -X POST https://app.redthreadsec.com/api/scan \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"target":"https://staging.yourapp.com/chat","budget":10}'

{ "run_id": "20260731-abc123" }

3. Đọc kết quả

Thăm dò lần chạy cho đến khi running là false, rồi đọc các phát hiện.

curl https://app.redthreadsec.com/api/runs/20260731-abc123 \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Đó là toàn bộ vòng lặp: me → scan → runs/<id>. Tài liệu tham chiếu API mô tả mọi trường dữ liệu.

Cách hoạt động

Redthread không cần agent: bạn kết nối một mục tiêu hoặc một đám mây, bật các module mong muốn cho từng không gian làm việc, và mọi thứ chạy từ đám mây của chúng tôi. Nền tảng của mọi module là một ý tưởng duy nhất — đồ thị.

1. Lập bản đồ. Redthread xây dựng một đồ thị duy nhất cho hệ thống của bạn — tác nhân, ứng dụng, mã nguồn, tài khoản đám mây, danh tính và dữ liệu mà chúng có thể tiếp cận — từ bất cứ thứ gì bạn kết nối: một vai trò đám mây không cần agent, một repository, một ứng dụng đang chạy.
2. Đánh giá. Các module bạn đã bật chạy trên bản đồ đó. Các tác nhân tự hành kiểm thử xâm nhập ứng dụng AI của bạn trong một sandbox tách biệt; khám phá AI ngầm lập danh mục mọi bề mặt mô hình; tư thế bảo mật đám mây & hạ tầng cùng DSPM phân loại tài sản và dữ liệu nhạy cảm; phân tích CVE trong thư viện phụ thuộc kiểm tra những gì bạn kế thừa.
3. Chứng minh. Một phát hiện là điều mà công cụ thực sự đã tiếp cận hoặc khai thác được — kèm các bước chính xác để tái hiện. Chỉ kết quả thật mới trở thành phát hiện; các manh mối chưa được chứng minh được giữ riêng. Không có gì là suy đoán.
4. Xếp hạng. Các phát hiện được đưa trở lại đồ thị, nên rủi ro trải qua nhiều lớp — một ứng dụng hướng Internet có thông tin xác thực tiếp cận được dữ liệu đã phân loại ở một đám mây khác — sẽ nổi lên trên danh sách các vấn đề riêng lẻ.
5. Hành động. Mỗi phát hiện đều kèm hướng dẫn khắc phục rõ ràng và, khi bạn cần, một pull request nháp. Cổng kiểm soát CI chặn lần merge có thể tạo ra một đường tấn công đã được chứng minh, và quy trình khắc phục có thể kích hoạt một webhook có chữ ký hoặc mở ticket Jira / ServiceNow.

Sản phẩm cốt lõi không cài đặt gì trên hệ thống của bạn; các module được bật theo từng không gian làm việc từ đám mây (xem sơ đồ kiến trúc). Các agent tùy chọn cho phép đi sâu hơn khi bạn cần: một bộ kết nối gọn nhẹ, chỉ kết nối chiều ra, để quét bên trong mạng của bạn, một cảm biến runtime eBPFcho Kubernetes, và một agent điểm cuối trên từng máy chủ — tất cả đều chỉ phát hiện, không bao giờ chặn. Các lần quét ứng dụng AI chạy trong sandbox Docker tách biệt cho từng lần quét và bị hủy khi lần quét kết thúc.

Công cụ: các tác nhân AI tự hành do các LLM tiên tiến điều khiển, được định hướng bởi bộ kỹ năng lỗ hổng của chúng tôi (OWASP LLM Top 10 2025 + MITRE ATLAS); chấm điểm CVSS 3.1 ; CVE trong thư viện phụ thuộc qua osv-scanner; đồ thị hệ thống được xuất dưới dạng JSON node-link thông thường. Module chủ lực là kiểm thử xâm nhập ứng dụng AI — phần còn lại của mục này mô tả từng module và API đằng sau.

Kiến trúc nền tảng

Khách hàng có thể đọc phần này trong ứng dụng: đăng nhập rồi mở bất kỳ liên kết tài liệu nào.

Cảm biến endpoint: thu thập gì và được dùng thế nào

Mỗi cảm biến chạy trên một máy tính xách tay, máy chủ hoặc VM đám mây. Cảm biến chỉ đọc và báo cáo; không bao giờ chặn, dừng hay thay đổi bất cứ thứ gì. Cảm biến gửi báo cáo khi khởi động và cứ 15 phút một lần; giữa các lần báo cáo, cứ 20 giây nó lại kiểm tra những công cụ AI nào đang chạy, nên cả các lần chạy ngắn cũng được ghi nhận. Để xem chính xác một máy sẽ gửi gì trước khi cài, hãy chạy redthread-agent -print: lệnh này in báo cáo ra và không gửi gì cả.

Nội dung của một báo cáo

Mọi máy có cảm biến đều được tính là đã nằm trong phạm vi phát hiện của Redthread trong Assess. Trong Estate Scan, mục Cài cảm biến endpoint liệt kê từng máy đang báo cáo, kèm nội dung và thời điểm báo cáo.

Những gì cảm biến không bao giờ gửi

Nội dung tệp, thao tác bàn phím, ảnh chụp màn hình, lưu lượng mạng, biến môi trường, mật khẩu hoặc token, ID phần cứng gốc, hay dòng lệnh của tiến trình. Dòng lệnh chỉ được đọc ngay trên máy để nhận diện công cụ AI, sau đó bị loại bỏ.

Tự động cập nhật. Cảm biến tự cập nhật: cứ sáu giờ nó kiểm tra bản dựng mới hơn đã phát hành, xác minh bằng tổng kiểm SHA-256 đã công bố giống như trình cài đặt, thay thế và khởi động lại. Bản dựng không khớp tổng kiểm sẽ không bao giờ được cài. Cảm biến cài trước ngày 7/10/2026 cần chạy lại lệnh cài một lần để có tính năng này; sau đó không cần chạy lại gì nữa. Để tắt cập nhật trên một máy, đặt MAI_AUTO_UPDATE=0.

Đánh giá & Hợp nhất

Khách hàng có thể đọc phần này trong ứng dụng: đăng nhập rồi mở bất kỳ liên kết tài liệu nào.

Agentic Trust & Protection Platform

Danh tính tác nhân + tín hiệu tin cậy liên tục, trên nền SPIFFE.

Trang Tin cậy & Thực thi tác tử. Trong console (Quản trị → Tin cậy & Thực thi tác tử), chủ sở hữu bật hoặc tắt Agent Trust bằng một nút, và đăng ký tác tử bằng cách đặt tên và phạm vi: tên chính xác của công cụ hoặc hành động mà nó báo cáo. Mỗi thẻ tác tử hiển thị trạng thái huy hiệu, chế độ theo dõi hoặc thực thi, danh tính và phạm vi, lần gần nhất cổng quyết định lưu lượng cho nó, và tiến độ chạy thử: số quyết định theo dõi trên 100, số phút theo dõi trên 60, và các quyết định lẽ ra sẽ chặn đang chờ xem xét. Chủ sở hữu xem xét chúng theo nhóm (nên chặn / hợp lệ) và có thể chuyển tác tử sang thực thi khi chạy thử hoàn tất. Cổng và chế độ thực thi được đánh dấu Bản xem trước.

Cổng một lệnh (bản xem trước). Sau khi bạn đăng ký tác tử, Redthread hiển thị một lệnh đã điền sẵn danh tính và khóa. Chạy lệnh trên máy chạy tác tử (macOS hoặc Linux, Python 3.10+): lệnh cài cổng tham chiếu như dịch vụ nền trên 127.0.0.1:8888 và in ra các dòng để khởi chạy tác tử (địa chỉ proxy và chứng chỉ do cổng tạo trên máy đó). Ở chế độ theo dõi, cổng quyết định và ghi lại mọi yêu cầu mà không chặn gì; các quyết định hiện trên thẻ tác tử trong Hoạt động và Chạy thử. Mỗi thẻ tác tử còn có trình chỉnh sửa quyền (máy chủ, phương thức, đường dẫn). Chạy lệnh với --uninstall để gỡ.

Một module tùy chọn cấp cho mọi tác nhân và danh tính được khám phá một danh tính bền vững, có thể kiểm chứng, và phát trạng thái tin cậy — safe / unsafe / degraded / revoked — theo thời gian thực, để bộ điều phối, gateway tác nhân và SIEM có thể phản ứng trong vài giây thay vì chờ ai đó đọc báo cáo. Module này vận hành dựa trên đồ thị và pipeline kiểm chứng khai thác bạn đã có; mặc định tắt và chỉ bổ sung thêm — một không gian làm việc không bao giờ kích hoạt nó sẽ không thấy thay đổi nào.

Module này nằm ở giao điểm của hai hạng mục trong ngành: danh tính phi con người / danh tính workload (cùng bài toán mà SPIFFE/SPIRE giải quyết cho tài khoản dịch vụ và máy móc, mở rộng sang tác nhân AI) và đánh giá quyền truy cập liên tục (mẫu Shared-Signals CAEP/RISC dùng để thu hồi theo thời gian thực trong quản lý danh tính doanh nghiệp). Agentic Trust & Protection Platform là tên chúng tôi đặt cho cả hai nửa này khi hợp thành một mạng lưới — mọi tác nhân đều có danh tính có thể kiểm chứng, và trạng thái tin cậy của nó được truyền trực tiếp tới bất kỳ nơi nào cần.

• Danh tính — SPIFFE/SPIRE. Mọi nút tác nhân/danh tính/AI đều được cấp một spiffe_id. Triển khai engine CNCF SPIRE theo từng tổ chức thuê bao chỉ với một bước Terraform từ bảng điều khiển (nó nhắm tới chính cluster mà tính năng khám phá đang đọc; khóa ký không bao giờ rời khỏi đám mây của bạn), và engine sẽ cấp các SVID ngắn hạn, tự động xoay vòng, được đưa ngược trở lại đồ thị. Cho đến khi bạn triển khai, Redthread gán một SPIFFE id xác định để lớp này hoạt động ngay hôm nay. Không phụ thuộc nhà cung cấp hay mô hình: danh tính được cấp cho workload, không bao giờ cho mô hình bên trong nó.
• Huy hiệu tin cậy trên đồ thị. Khi được kích hoạt, mọi nút trong chế độ xem Redthread Flow đều mang huy hiệu tin cậy (xanh lá safe / đỏ unsafe / hổ phách degraded / xám revoked), lấy từ cùng trường trust_state .
• Trạng thái tin cậy: được chứng minh, không phải phỏng đoán. Một nút chuyển sang unsafe chỉ khi có khai thác đã được chứng minh (không bao giờ dựa trên suy đoán); degraded áp dụng cho phát hiện tiềm ẩn nhưng chưa xác nhận hoặc SVID đã hết hạn; revoked là thao tác ghi đè thủ công của người vận hành.
• Sự kiện có chữ ký, có TTL. Mọi thay đổi trạng thái tin cậy đều được phát dưới dạng sự kiện có thời hạn, ký bằng Ed25519, định dạng theo chuẩn CAEP/RISC, kèm liên kết tới phát hiện đã gây ra nó. Bất kỳ bên thứ ba nào cũng có thể kiểm chứng sự kiện ngoại tuyến bằng khóa công khai của không gian làm việc của bạn — không cần gọi trực tiếp tới Redthread.
• Phân phối. Đăng ký một hoặc nhiều webhook (có thể kèm khóa bí mật dùng chung HMAC); mỗi khi có thay đổi, sự kiện có chữ ký sẽ được gửi tới tất cả. Sổ cái chỉ ghi thêm cho phép bên đăng ký đã bỏ lỡ sự kiện cập nhật lại.
• Khóa và sổ cái. Khóa ký của mỗi workspace do một dịch vụ ký riêng giữ, được niêm phong bằng một khóa từ Oracle Cloud Vault: ứng dụng có thể yêu cầu một chữ ký nhưng không thể đọc hay xuất khóa. Sổ cái chỉ ghi thêm nằm trong PostgreSQL, và chính cơ sở dữ liệu từ chối cập nhật, xóa hay cắt bớt nó.
• Enforce — bản xem trước. Một gateway nội tuyến tùy chọn, quyết định allow / deny / deny-and-pause đối với một yêu cầu đang diễn ra dựa trên một quyền cấp có cấu trúc (host, method, path, kích thước body) trước khi yêu cầu tới đích, thay vì chỉ ghi lại sau đó. Mọi quyền cấp mới đều bắt đầu ở chế độ shadow — quyết định và ghi lại, chuyển tiếp mọi thứ, đúng như hiện nay — và chính API sẽ từ chối chuyển một danh tính sang chế độ thực thi cho đến khi đáp ứng cổng chạy thử: lưu lượng thật được theo dõi dưới đúng quyền cấp đó đủ lâu, và mọi yêu cầu lẽ ra đã bị chặn đều được người vận hành xem xét và đồng ý. Không có cơ chế ghi đè. Từ tháng 10, gateway còn kiểm tra nội dung: chỉ thị prompt injection và bí mật trong một yêu cầu gửi đi, và danh sách công cụ MCP bị đầu độc trong phản hồi ( tools/list ). Đây là khớp mẫu, chỉ quan sát cho đến khi một danh tính được chuyển sang chế độ thực thi, và một cách diễn đạt khác có thể né được. Xem tài liệu API để biết toàn bộ các route.

Mặc định vẫn chỉ là danh tính + trạng thái tin cậy — không phải hệ thống phân quyền/VC, và (trong v1) không phải liên kết danh tính giữa các tổ chức. Enforce, ở nơi một danh tính đã đủ điều kiện, bổ sung một điểm quyết định thực sự trên đường đi của yêu cầu; nó không bao giờ được quảng bá như một sự bảo đảm trước một cuộc tấn công mới không khớp quy tắc nào.

Huy hiệu công khai: hình ảnh chỉ là con trỏ, khẳng định là một tệp có chữ ký

Mọi huy hiệu trong README đều là hình ảnh được tải từ máy chủ của ai đó, và hình ảnh có thể hiển thị bất cứ thứ gì máy chủ đó quyết định. Vì vậy không có khẳng định ATPP nào nằm trong hình ảnh. Khẳng định cấp 1 (nhà phát hành MCP) là một tuyên bố in-toto trong phong bì DSSE, được ký bằng Ed25519 bởi tác vụ quét hằng ngày của chúng tôi (chạy trên hạ tầng riêng của Redthread), có subject là sha256 của đúng manifest registry đã được quét. Kể từ bộ quy tắc atf-5 trở đi, khẳng định còn nêu rõ những gì mục danh mục đó cài đặt: integrity hash của npm, các sha256 của tệp PyPI hoặc digest container đứng sau mỗi tag image, và repository được ghi trong Sigstore build provenance của gói, ở nơi npm hoặc PyPI có lưu. Các máy chủ đứng sau trust.redthreadsec.com chỉ giữ khóa công khai, nên không thể tạo ra một khẳng định kiểm chứng hợp lệ, và sẽ hiển thị huy hiệu màu xám trừ khi chữ ký hợp lệ.

• Huy hiệu ghim (mặc định). Nhà phát hành commit .atpp/badge.svg và .atpp/attestation.dsse.json (tải cả hai tại /v/mcp/<namespace>/<server>). README của họ không tải gì từ chúng tôi; huy hiệu ghi rõ phiên bản và ngày; mã sha256 của nó nằm trong khẳng định có chữ ký.
• Huy hiệu trực tiếp (tùy chọn). /badge/mcp/<namespace>/<server>.svg cập nhật theo mỗi lần quét lại; trên GitHub, độ trễ khoảng 10 phút (bộ nhớ đệm hình ảnh). Chỉ có hình khối và văn bản đơn giản — không có liên kết hay hiệu ứng động.
• Tự kiểm tra. python3 atpp.py verify <namespace>/<server> hoặc một đường dẫn repo, từ github.com/bl014h/atpp: chữ ký so với khóa đã ghim, hash registry trực tiếp, huy hiệu đã commit, thời hạn. Khóa: /.well-known/atpp-keys.json. Manifest có chữ ký hằng ngày của mọi phong bì nằm tại /v/log/latest.json, và hash của nó được commit vào repo công khai đó.
• Kiểm tra những gì bạn đã cài đặt. python3 atpp.py check-config đọc cấu hình MCP của Claude Desktop, Claude Code, Cursor, VS Code hoặc Windsurf trên máy của bạn, tìm mục registry đứng sau mỗi gói hoặc URL, rồi in ra điểm số có chữ ký, phiên bản hoặc digest chính xác cần ghim và bên đã build nó. !! đánh dấu máy chủ không nên tin chỉ dựa vào tên (tráo danh mục, thiếu phiên bản, được build từ một repository khác). Tệp cấu hình của bạn không bao giờ được tải lên.
• Định nghĩa công cụ được lấy dấu vân tay. Kể từ bộ quy tắc atf-6 trở đi, lượt quét gửi bắt tay MCP và tools/list (không gọi công cụ nào) tới mỗi máy chủ từ xa phản hồi mà không cần thông tin xác thực, rồi ký dấu vân tay của các định nghĩa công cụ vào khẳng định. tools-stable thất bại khi các định nghĩa thay đổi mà phiên bản không đổi, tức kiểu rug-pull (OWASP MCP03).
• Hook và danh mục vật liệu (bản xem trước). atpp hook claude (một hook của Claude Code, loại PreToolUse ) và atpp hook cursor kiểm tra từng lệnh gọi công cụ MCP với khẳng định có chữ ký và từ chối tráo danh mục, thiếu phiên bản, nguồn gốc build từ nơi khác, hoặc thay đổi công cụ âm thầm. atpp check-config --cyclonedx bom.json ghi ra AIBOM CycloneDX 1.6 của các máy chủ bạn đã cấu hình.
• Kiểm soát trước khi khởi chạy (bản xem trước). python3 atpp.py gate <namespace>/<server> thoát với mã 0 để cho phép hoặc 1 để từ chối; kiểm tra nào không chạy được thì sẽ từ chối. Dùng nó trước khi khởi chạy, trong CI (GitHub Action atpp với mode: check-config sẽ đánh trượt pull request nào thêm một máy chủ cần xem xét), hoặc đặt trước ToolHive (atf_receipts.py serve --gate). Lệnh này đối chiếu mục danh mục đã công bố và digest của artifact với một lần quét tĩnh; nó không theo dõi những gì máy chủ làm sau khi chạy.
• Chính sách của bạn, do runtime của bạn thực thi. Danh sách cho phép và các digest image đã ghim của một tổ chức nằm trong một tệp do bạn sở hữu: atpp gate --policy org.json từ chối mọi thứ khác, và atpp profile --policy org.json chuyển một mục thành hồ sơ quyền ToolHive (các host outbound được phép và các mount tệp) cho thv run --isolate-network. Khẳng định có chữ ký không bao giờ cấp quyền.
• Đồng ký không dùng khóa. Manifest hằng ngày cũng được ký bằng Sigstore keyless signing bởi một workflow chỉ đọc trong repository atpp công khai (danh tính GitHub, một chứng chỉ ngắn hạn, một mục Rekor). Xác minh bằng sigstore verify identity; các bundle nằm trong thư mục log/ của repository đó.
• Chống quay lui. Manifest hằng ngày cũng được neo vào nhật ký minh bạch công khai Sigstore Rekor, và bộ kiểm chứng xác nhận khẳng định nằm trong manifest mới nhất — nên ngay cả máy chủ bị xâm phạm cũng không thể phát lại một khẳng định cũ có điểm tốt hơn, và một repo không thể mượn các tệp .atpp/ của máy chủ khác (khẳng định phải thuộc về chính repository chứa nó).
• Được giám sát từ bên ngoài. Một bài kiểm tra canary chạy hằng giờ và một bài red team chạy hằng ngày trên GitHub nhắm vào production; kết quả được công khai.
• Thiết kế đầy đủ, dành cho nhà phát triển và lãnh đạo bảo mật: trust.redthreadsec.com/technical.
• Báo cáo sự cố: [email protected] · chính sách công bố lỗ hổng.

So sánh với các nền tảng khác

Vị trí của Redthread về mặt kiến trúc, đặt cạnh các nền tảng mà các đội ngũ đã quen thuộc. Trên trục agent , chúng tôi ưu tiên không cần agent, giống Wiz; điểm khác biệt là chúng tôi chứng minh rủi ro bằng cách khai thác nó, và đồ thị Redthread coi tác nhân AI và ứng dụng là các nút hạng nhất, chứ không chỉ hạ tầng đám mây. Đây là so sánh về kiến trúc — Wiz, Palo Alto và CrowdStrike là các bộ sản phẩm lớn, đa sản phẩm, nên điểm cần so sánh ở đây là hình thái, không phải sự tương đương về tính năng.

Gần nhất với Wiz. Mặc định không cần agent, với đồ thị bảo mật ở lõi biến các phát hiện thô thành đường tấn công và tổ hợp độc hại được xếp hạng. Điểm khác biệt: Wiz suy luận rủi ro từ trạng thái đám mây; chúng tôi chứng minh nó — một bài kiểm thử xâm nhập tự hành thực thi khai thác và đính kèm PoC có thể tái hiện — và đồ thị của chúng tôi coi ứng dụng LLM và tác nhân là các nút hạng nhất (OWASP LLM Top 10, MITRE ATLAS), chứ không chỉ tài nguyên đám mây. Vì vậy, về hình thái, chúng tôi là "một đồ thị CNAPP không cần agent, kèm công cụ kiểm thử xâm nhập ứng dụng AI theo hướng tấn công ở lớp trên."

Khác với Palo Alto. Prisma Cloud + Cortex là chiến lược nền tảng hóa — nhiều sản phẩm và agent (không cần agent + Defender + một AI SOC trải khắp điểm cuối, mạng, đám mây và danh tính). Chúng tôi là một nền tảng không cần agent duy nhất, với các module được bật theo từng không gian làm việc. Palo Alto ngăn chặn và phản hồi tại runtime; còn chúng tôi, theo thiết kế, vẫn là công cụ kiểm thử và đánh giá — cảm biến runtime tùy chọn của chúng tôi chỉ phát hiện.

Khác với CrowdStrike. Tiền đề của Falcon là một agent trên mọi điểm cuối thực hiện EDR runtime. Sản phẩm cốt lõi của chúng tôi không cài đặt gì và không thực hiện ngăn chặn tại runtime. Chúng tôi chỉ trùng lặp ở "các module kích hoạt trên đám mây" và ở việc vận hành một đồ thị tương quan — nhưng Falcon lập đồ thị cho sự kiện điểm cuối, còn Redthread lập đồ thị cho hệ thống của bạn và các đường tấn công đã được chứng minh của nó.

Nên quét mục tiêu nào

Câu hỏi phổ biến nhất, được trả lời ngay từ đầu: bạn cung cấp cho chúng tôi một target, và tùy chọn thêm mã nguồncủa bạn. Hai thứ này không giống nhau.

Staging và production — luôn nhắm vào staging

• Production là ứng dụng thật mà khách hàng của bạn sử dụng, với dữ liệu thật.
• Staging là một bản sao riêng, đang chạy trong môi trường kiểm thử — cùng một ứng dụng, nhưng không có khách hàng hay dữ liệu thật.

Công cụ quét là một kẻ tấn công thực sự: nó gửi dữ liệu đầu vào, có thể tạo bản ghi, kích hoạt các hành động mà ứng dụng của bạn cung cấp, và đẩy chi phí mô hình của ứng dụng lên. Trên staging, điều đó vô hại. Trên production, nó có thể tạo ra dữ liệu rác hoặc tác động thật tới người dùng thật. Chỉ quét production nếu bạn hiểu và chấp nhận điều đó (một tài khoản kiểm thử và thời điểm ít người dùng sẽ có ích).

Làm sao để biết URL của tôi? Một URL staging trông như sau…

Đó chỉ là một địa chỉ web nơi ứng dụng của bạn chạy. Các dạng phổ biến:

• staging.yourapp.com hoặc app-staging.yourapp.com
• Một URL preview từ Vercel hoặc Netlify (mỗi thay đổi được cấp một URL)
• Một *-staging.onrender.com hoặc *.herokuapp.com (địa chỉ ứng dụng)
• Một địa chỉ cục bộ (localhost:3000) được đưa ra Internet bằng tunnel (ngrok, cloudflared)

Cách dễ nhất: để ứng dụng tìm giúp bạn

Trong ứng dụng, dán một liên kết bạn đã biết — địa chỉ website hoặc ứng dụng chính — vào "Chưa biết nên quét gì?" và nhấn Tìm mục tiêu cần quét. Chúng tôi xem xét trang, nhận diện các tính năng AI và điểm cuối API, và kiểm tra hồ sơ công khai để tìm các môi trường khác của bạn (như staging. và app.). Bạn sẽ nhận được danh sách ngắn các mục tiêu được đề xuất — nhấp vào một mục để quét. Không cần đăng nhập hosting, không cần tự đi tìm.

Tự tìm — không cần lập trình viên

Muốn tự làm thủ công, hoặc muốn kiểm tra lại? Bạn không cần người có chuyên môn kỹ thuật. Có hai cách đáng tin cậy:

1. Mở ứng dụng của chính bạn và sao chép liên kết. Dùng sản phẩm như một khách hàng — vào trang có tính năng AI (chat, trợ lý) và sao chép địa chỉ trực tiếp từ thanh địa chỉ của trình duyệt. Địa chỉ đó là mục tiêu của bạn.
2. Lần theo hóa đơn tới tài khoản hosting. Ứng dụng của bạn chạy ở đâu đó, và người có thẻ thanh toán hóa đơn hosting có thể thấy mọi URL. Kiểm tra sao kê để tìm Vercel, Netlify, Render, Heroku, AWS, DigitalOcean, Google Cloud, đăng nhập vào tài khoản đó, và bảng điều khiển sẽ liệt kê các địa chỉ ứng dụng của bạn — production và mọi môi trường staging/preview.

Cách dự phòng: nhà đăng ký tên miền / DNS của bạn (GoDaddy, Namecheap, Cloudflare — nơi bạn mua tên miền) hiển thị các subdomain như staging., app., api.; hoặc hỏi bộ phận hỗ trợ của nhà cung cấp hosting ngay trong tài khoản của bạn.

Tôi không có URL staging — làm sao để có?

• Hầu hết nhà cung cấp hosting cho phép tạo bản sao staging chỉ với một cú nhấp từ tài khoản của bạn — Vercel, Netlify và Render đều cung cấp môi trường preview/staging miễn phí, không cần viết mã.
• Nếu ứng dụng của bạn ở trên GitHub, URL preview thường được tạo tự động cho mỗi pull request.
• Chỉ có production? Bạn vẫn có thể quét — chỉ cần coi đó là một cuộc tấn công thật (chọn thời điểm ít người dùng, dùng tài khoản kiểm thử, chấp nhận có một ít dữ liệu rác). Xem Staging và production ở trên.
• Hoàn toàn không có ai rành kỹ thuật? Một freelancer có thể dựng staging trong một buổi chiều — sau đó bạn dán URL đó vào đây.

Khi đã có URL, hãy làm theo Chạy lần quét đầu tiên. Thêm mã nguồn (tải lên hoặc repo) để quét hộp trắng sâu hơn.

Hộp đen và hộp trắng

Bạn cung cấp cho công cụ quét bao nhiêu sẽ quyết định nó tìm được bao nhiêu.

• Hộp đen — bạn chỉ cung cấp URL hoặc API đang chạy. Công cụ quét tấn công từ bên ngoài, như một kẻ tấn công ẩn danh. Nhanh, không cần thiết lập, nhưng chỉ tìm được những gì tiếp cận được từ cửa trước.
• Hộp trắng — bạn cung cấp thêm mã nguồncủa ứng dụng. Công cụ quét đọc mã nguồn trong khi tấn công, nên hiểu được các công cụ, prompt và đường đi dữ liệu đằng sau điểm cuối. Điều này giúp tăng mạnh cả số lượng lẫn độ sâu của phát hiện.

Hai cách để cung cấp mã nguồn — bạn không cần biết git:

• Tải lên tệp .zip của dự án. Trong ứng dụng, thả tệp vào ô quét; qua API, tải tệp lên và truyền upload_idđược trả về. Mã nguồn của bạn chỉ được giữ cho lần quét đó và bị xóa khi lần quét kết thúc — không bao giờ được dùng để huấn luyện.
• Trỏ tới một git repo — GitHub, GitLab, Bitbucket hoặc Azure DevOps. Dán URL repo vào trường source , hoặc trong ứng dụng, nhấn Kết nối GitHub một lần và chọn repo (kể cả repo riêng tư) từ danh sách thả xuống. Với các nền tảng khác, dán URL; repo riêng tư trên đó dùng cách tải lên tệp .zip .

Quét toàn diện — cả hai lượt, một cú nhấp

Bật Quét toàn diện (ô đánh dấu trên biểu mẫu quét) để tự động chạy cả hai lượt cho một mục tiêu: lượt hộp đen thăm dò các điểm cuối đang chạy, sau đó lượt hộp trắng đọc mã nguồn của bạn và kiểm thử lại bề mặt đã biết. Bạn nhận được một danh sách phát hiện hợp nhất, mỗi thẻ được gắn nhãn theo lượt đã tìm ra nó. Tính năng này cần mã nguồn của bạn (một repo hoặc tệp .zip) và dùng khoảng gấp đôi ngân sách của một lần quét đơn.

Lượt hộp trắng kế thừa các phát hiện của lượt hộp đen và kiểm thử lại từng phát hiện: vấn đề vẫn còn khai thác được sẽ hiển thị là lỗi tái diễn ↻ đã xác nhận lại (chỉ tính một lần, không tính hai lần), và những gì chỉ mã nguồn mới tiết lộ được sẽ được thêm vào dưới dạng phát hiện mới. Ngay cả gói Free cũng có thể chạy Quét toàn diện — giới hạn tổng cộng 520.000 ₫ (260.000 ₫ mỗi lượt).

Những gì được kiểm thử

Mọi hạng mục trong OWASP LLM Top 10, ánh xạ tới MITRE ATLAS:

• Prompt injection
• Tiết lộ thông tin nhạy cảm
• Chuỗi cung ứng
• Đầu độc dữ liệu & mô hình
• Xử lý đầu ra không đúng cách
• Quyền tự quyết quá mức (lạm dụng công cụ & tác nhân)
• Rò rỉ system prompt
• Điểm yếu của vector & embedding (RAG)
• Thông tin sai lệch
• Tiêu thụ không giới hạn (chi phí mất kiểm soát)

Ma trận đầy đủ, kèm ánh xạ tới MITRE ATLAS, được công bố tại Trung tâm tin cậy.

Công cụ: bộ kỹ năng lỗ hổng theo từng hạng mục của chúng tôi, gắn với OWASP LLM Top 10 2025 và MITRE ATLAS v5.6.0 (mã kỹ thuật được đối chiếu với nguồn gốc, không dựa vào trí nhớ). Chuỗi cung ứng có mục riêng.

Phát hiện & bằng chứng khái niệm

Một phát hiện là lỗ hổng mà công cụ quét đã chứng minh được, không phải phỏng đoán. Mỗi phát hiện bao gồm:

Đọc một phát hiện — giải thích các nhãn

Mọi phát hiện đều được gắn các nhãn bảo mật tiêu chuẩn để bạn đánh giá rủi ro và quyết định cần khắc phục gì trước. Dưới đây là ý nghĩa của từng nhãn, cách đọc và lý do nó quan trọng.

OWASP LLM Top 10 — ý nghĩa của từng rủi ro

Giới hạn chi phí & an toàn

Các tác nhân tự hành gọi tới mô hình ngôn ngữ, và việc đó tốn chi phí. Hai giới hạn độc lập đảm bảo một lần quét không bao giờ khiến bạn bất ngờ:

• Giới hạn ngân sách cho mỗi lần quét. Mỗi lần quét nhận một tham số budget (đơn vị đô la Mỹ, mặc định 10). Công cụ sẽ dừng khi chạm mức trần đó.
• Cơ chế giám sát token. Một lớp chặn dự phòng riêng biệt sẽ dừng mọi lần quét vượt quá một số lượng token cố định, kể cả với mô hình tự lưu trữ mà lớp tính giá không nhìn thấy. Nhờ vậy, một vòng lặp mất kiểm soát không thể làm cạn tài khoản của bạn.

Mỗi lần quét cũng chạy trong sandbox tách biệt riêng, và số lần quét đồng thời được giới hạn theo gói để bạn không vô tình khởi chạy cả trăm lần quét cùng lúc.

Ủy quyền & xác minh tên miền

Vì một lần quét là một cuộc tấn công thật, bạn chỉ được quét ứng dụng bạn sở hữu hoặc được ủy quyền kiểm thử. Để điều đó không chỉ là một lời hứa, lần đầu tiên bạn quét một tên miền công khai mới, chúng tôi sẽ yêu cầu bạn chứng minh quyền sở hữu — mỗi tên miền một lần. Điều này ngăn bất kỳ ai dùng chúng tôi để nhắm vào đối thủ cạnh tranh.

Xác minh bằng một trong hai cách (chọn cách bạn có thể thực hiện — chỉ cần một):

• Thẻ meta (dễ nhất). Thêm một dòng vào <head>của trang chủ. Hầu hết công cụ dựng website — Wix, Squarespace, Webflow, Shopify — đều có ô "header code" hoặc "site verification" dành riêng cho việc này:

  <meta name="millenniums-verification" content="YOUR-TOKEN">

• Bản ghi DNS TXT. Thêm một bản ghi TXT tại nhà đăng ký tên miền của bạn:

  millenniums-verification=YOUR-TOKEN

Xác minh tên miền gốc sẽ bao gồm mọi subdomain của nó — xác minh acme.com một lần là bạn có thể quét staging.acme.com, api.acme.comvà các subdomain khác. Bạn cũng sẽ xác nhận một bản cam kết ủy quyền ngắn (rằng bạn sở hữu ứng dụng, hoặc được ủy quyền kiểm thử nó) trước khi lần quét đầu tiên chạy.

Xác minh trong ứng dụng khi được nhắc, hoặc qua API tại POST /api/domains/verify. Việc khám phá (đọc một trang công khai) không cần xác minh — chỉ quét mới cần.

Dữ liệu của bạn

Mã nguồn và kết quả quét là của bạn. Mỗi lần quét chạy trong một sandbox dùng một lần và bị hủy khi lần quét kết thúc, nên chúng tôi giữ mã nguồn của bạn ít nhất có thể và chỉ trong thời gian lần quét cần đến. Chúng tôi không bao giờ dùng mã nguồn hay kết quả của bạn để huấn luyện bất kỳ mô hình nào. Chi tiết đầy đủ, bao gồm các bên xử lý phụ, có tại Trung tâm tin cậy và Chính sách quyền riêng tư.

Báo cáo truy vết

Mỗi lần quét đều tạo ra một báo cáo chuỗi lưu ký bằng chứng để bạn có thể chứng minh — với chính mình, với khách hàng hoặc kiểm toán viên — chính xác điều gì đã xảy ra với dữ liệu của bạn. Đây không phải tuyên bố marketing; mỗi dòng đều được suy ra từ một sự kiện đã ghi nhận trong vòng đời của lần quét.

Báo cáo bao gồm:

• Dòng thời gian có dấu thời gian: tạo lần quét → nhận mã nguồn → khởi chạy sandbox tách biệt → hoàn tất quét → hủy sandbox → (với tệp tải lên) xóa mã nguồn đã tải lên.
• Nguồn gốc mã nguồn: lần quét là hộp đen (chỉ mục tiêu đang chạy), hay hộp trắng từ tệp tải lên hoặc git repo. URL git chỉ được ghi lại theo host — không có đường dẫn hay thông tin xác thực.
• Chứng thực: sandbox tách biệt, sandbox đã bị hủy (được kiểm chứng với runtime của container), mã nguồn tải lên đã bị xóa, giới hạn chi phí đã được áp dụng, và không bao giờ được dùng để huấn luyện mô hình.
• Mức sử dụng: số token và lượt gọi LLM của lần chạy.

Xem báo cáo trong ứng dụng ở bất kỳ lần chạy nào, tại mục Dấu vết dữ liệu — chuỗi lưu ký bằng chứng (kèm tải JSON chỉ với một cú nhấp), hoặc qua API tại GET /api/runs/{run_id}/trace.

Quét liên tục & sai lệch

Chức năng: biến một lần quét tại một thời điểm thành sự bao phủ liên tục. Đăng ký ứng dụng của bạn làm tài sản, đặt lịch quét, và Redthread sẽ quét lại cho bạn — đồng thời kiểm tra lại mỗi khi ứng dụng thay đổi.

Cách thức: hai cơ chế kiểm soát, thiết lập cho từng tài sản trong chế độ xem Liên tục (hoặc qua API):

• Lịch quét — tần suất hằng ngày, hằng tuần hoặc hằng tháng. Các lần quét lại đi theo cùng đường xử lý như một lần quét thủ công, nên hạn mức, giới hạn số lần quét đồng thời và giới hạn chi phí của bạn vẫn được áp dụng.
• Phát hiện sai lệch — bật theo dõi thay đổi và giữa các lần chạy theo lịch, chúng tôi lấy lại dấu vân tay của ứng dụng (ưu tiên đặc tả OpenAPI/Swagger của nó). Một thay đổi đáng kể sẽ kích hoạt lần quét ngoài chu kỳ. Dấu vân tay bỏ qua token CSRF, nonce, dấu thời gian và tham số chống cache, nên trang động không kích hoạt nhầm.

Lý do: ứng dụng thay đổi sau mỗi lần phát hành, và một đợt kiểm thử xâm nhập hằng năm không thể thấy lỗ hổng do lần deploy hôm thứ Ba mở ra. Quét liên tục phát hiện lỗi tái diễn ngay khi chúng xuất hiện; theo dõi sai lệch giúp bạn chỉ tốn một lần quét khi thực sự có thay đổi — giám sát tự động thay vì nhắc lịch thủ công.

Công cụ: cùng công cụ quét, được điều khiển bởi bộ lập lịch theo từng tài sản; lấy dấu vân tay ứng dụng từ đặc tả OpenAPI/Swagger (hoặc thu thập bề mặt đã chuẩn hóa), so sánh giữa các lần chạy, đã lọc nhiễu từ token động.

Bảng điều khiển & xu hướng

Bảng điều khiển chính là nơi đọc rủi ro, không phải nhật ký hoạt động. Trang mở ra với dải rủi ro gồm bốn ô — đường tấn công đã được chứng minh (trên tổng số bao nhiêu rủi ro, từ bao nhiêu phát hiện chưa xử lý), phát hiện chưa xử lý theo mức độ nghiêm trọng kèm chênh lệch mới mở / đã xử lý so với lần quét trước, phạm vi bao phủ (tài sản đã đăng ký, kết nối đám mây, máy chủ điểm cuối, thời gian kể từ lần quét gần nhất), và trạng thái Agentic Trust & Protection Platform (tác nhân safe / unsafe / degraded, hoặc tắt). Bên dưới là ba đường tấn công hàng đầu từ Redthread, được vẽ dưới dạng chuỗi bước nhảy — Internet → web-01 → data-ingest-role → customer-records — mỗi đường được đánh dấu Đã chứng minh · PoC hoặc Tiềm ẩn, xếp hạng theo mức độ nghiêm trọng, đường đã chứng minh xếp trước đường tiềm ẩn. Các lần quét gần đây nằm bên dưới.

Mỗi ô và bảng đều có một dòng mô tả nó đếm gì. Ô Mức bao phủ đếm bao nhiêu trong bốn đám mây (AWS, Azure, Google Cloud, Oracle Cloud) đã được kết nối và ghi tên chúng.

Mỗi ô là một truy vấn đã lưu: nhấp vào sẽ mở chế độ xem đã tạo ra con số đó, đã được lọc sẵn — một thanh mức độ nghiêm trọng mở Phát hiện ở mức đó, một đường tấn công mở rủi ro được xếp hạng mà nó thuộc về, phạm vi bao phủ mở Mục tiêu, ô tin cậy mở Đánh giá. Số phát hiện chưa xử lý được lấy từ lần quét gần nhất của mỗi tài sản đã đăng ký (chạy lại không bao giờ bị tính hai lần); không gian làm việc chưa có tài sản đăng ký sẽ đọc lần quét gần nhất. Các số liệu được lấy từ /api/cloud/risks, /api/overview, /api/cloud/status, /api/endpoint và /api/trust-signal/status.

Bên dưới các đường tấn công là ba bảng khác. Thay đổi kể từ lần quét trước liệt kê từng tài sản đã đăng ký với số mới mở / đã xử lý so với lần quét trước và lần chạy theo lịch tiếp theo — tài sản có phát hiện mới mở được xếp trước, và nhấp vào một dòng sẽ mở lần quét gần nhất của tài sản đó. Hành động tiếp theo được suy ra từ trạng thái bạn đã có: pull request tự động khắc phục sẵn sàng để merge, các ứng viên AI ngầm đang chờ xác nhận, thông tin xác thực bị lộ cần xoay vòng (từ các rủi ro đã xếp hạng), và đường tấn công đã chứng minh cần khắc phục trước tiên. Phát hiện chưa xử lý · 8 tuần là biểu đồ sparkline cộng dồn trên các tài sản đã đăng ký (số phát hiện chưa xử lý mới nhất của mỗi tài sản được chuyển tiếp qua từng tuần, từ /api/assets/<id>/trend), với mũi tên ↑ / ↓ so với tuần trước, cũng được hiển thị trên ô mức độ nghiêm trọng; biểu đồ xuất hiện sau lần quét thứ hai của một tài sản đã đăng ký.

Chế độ xem lãnh đạo. Nút chuyển Chuyên viên / Lãnh đạo ở đầu Bảng điều khiển hiển thị cùng các con số ở một tầm nhìn cao hơn: số đường tấn công đã chứng minh kèm dòng phễu, bản tóm tắt bằng ngôn ngữ dễ hiểu được viết từ trạng thái hiện tại (những gì Redthread lập bản đồ, những gì đã được chứng minh, phát hiện chưa xử lý theo mức độ nghiêm trọng, thay đổi so với lần quét trước, độ tin cậy của tác nhân và hành động tiếp theo), sau đó là phạm vi bao phủ, độ tin cậy, mức độ nghiêm trọng và xu hướng 8 tuần, cùng các đường tấn công hàng đầu. Chi tiết kỹ thuật của lần quét được ẩn đi. Lãnh đạo là chế độ xem mặc định; chế độ xem Chuyên viên chỉ cách một cú nhấp và lựa chọn được ghi nhớ trong trình duyệt.

Chế độ xem đã lưu. Trong mục Phát hiện của một lần quét, các chip mức độ nghiêm trọng / PoC / đã khai thác dùng để lọc danh sách; ＋ Lưu chế độ xem lưu bộ lọc mức độ nghiêm trọng hiện tại và tùy chọn hiển thị mục đã bỏ qua dưới một tên, theo từng không gian làm việc trong trình duyệt của bạn, và các chế độ xem đã lưu xuất hiện dưới dạng chip ★ bên cạnh bộ lọc.

Thanh điều hướng của bảng điều khiển được nhóm theo việc bạn đang làm thay vì theo loại quét: Tổng quan (Bảng điều khiển) · Kết nối (các loại quét; mục tiêu đã đăng ký được quản lý tại Cài đặt → Mục tiêu) · Khám phá (Redthread Flow, Đánh giá & hợp nhất, Trò chuyện, Sự cố đám mây; Tri thức mở từ nút Tri thức trên trang Trò chuyện) · Xử lý (Phát hiện, Rà soát PR) · Quản trị (Đánh giá & Hợp nhất, Cài đặt).

Đây là Liên tục (chế độ xem) — nơi tổng hợp mọi tài sản đã đăng ký tại một chỗ, để trưởng nhóm bảo mật — hoặc hội đồng quản trị — có thể nắm toàn bộ hệ thống chỉ trong nháy mắt và chứng minh nó đang đi đúng hướng. Chế độ xem này được cung cấp dữ liệu hoàn toàn từ các lần quét mà lịch quét và CI của bạn vốn đã chạy; không cần đo đạc thêm gì.

Tổng hợp theo từng tài sản — GET /api/overview. Mỗi tài sản hiển thị trạng thái lần quét gần nhất, phát hiện theo mức độ nghiêm trọng, chênh lệch mới mở / đã xử lý so với lần quét trước, cùng lịch quét và lần chạy tiếp theo. Bạn không chỉ thấy tài sản đang ở đâu, mà còn thấy những gì đã thay đổi kể từ lần trước.

Xu hướng rủi ro — GET /api/assets/<id>/trend. Mỗi tài sản có một chuỗi phát hiện theo thời gian — từng lần quét từ cũ nhất → mới nhất, kèm số phát hiện chưa xử lý cùng số mới mở và đã xử lý tại mỗi bước — để bạn có thể cho thấy rủi ro đang giảm dần qua các tuần, chứ không chỉ một ảnh chụp tại một thời điểm. Đây chính là biểu đồ sparkline phía sau bảng điều khiển.

Xuất dữ liệu — GET /api/overview.csv. Chỉ một cú nhấp để xuất bản tổng hợp toàn tổ chức dưới dạng CSV cho bảng tính, slide QBR hoặc hệ thống BI của riêng bạn.

Khám phá AI ngầm (danh mục AI)

Chức năng: tìm ra những hệ thống AI tổ chức của bạn đang dùng mà bộ phận bảo mật không biết — "AI ngầm". Các repository âm thầm gọi API LLM, các dịch vụ AI được quản lý được bật trong tài khoản đám mây, các máy chủ mô hình tự lưu trữ hoặc giao diện chatbot bị lộ trên tên miền của bạn. Đây là một khả năng khám phá và lập danh mục : nó cho bạn biết AI tồn tại ở đâu, chứ không cho biết AI đó có lỗ hổng hay không.

Cách thức: kết nối các bề mặt bạn muốn rà soát, và mỗi lần chạy sẽ báo cáo chính xác những gì nó đã bao phủ. Mỗi kết quả là một ứng viên do bạn xác nhận — nó không bao giờ tự đăng ký bất cứ thứ gì. Các ứng viên đã xác nhận được hợp nhất vào một Danh mục AI đã loại trùng lặp, kèm biểu ngữ phạm vi bao phủ; hãy bỏ qua những ứng viên đã biết hoặc nằm ngoài phạm vi.

Lý do: bạn không thể bảo vệ hay quản trị AI mà bạn không biết mình có. AI ngầm là nơi ẩn chứa rò rỉ dữ liệu, chi phí mất kiểm soát và lỗ hổng tuân thủ — danh mục là biện pháp kiểm soát đầu tiên. Những gì bạn xác nhận tại đây sẽ trở thành tập hợp được kiểm thử và giám sát. Xem Khám phá & danh mục.

Công cụ: API tổ chức/repo của GitHub + phát hiện việc sử dụng LLM SDK (repo); liệt kê tài nguyên đám mây không cần agent qua boto3 — Bedrock, SageMaker, Lex, Comprehend (đám mây); thăm dò bề mặt HTTP/TLS để tìm máy chủ mô hình và điểm cuối tương thích OpenAI (bên ngoài). Tất cả đều không cần agent.

Chuỗi cung ứng AI

Chức năng: rủi ro đến từ các thành phần AI mà ứng dụng của bạn được xây dựng trên đó — mô hình nền tảng của bên thứ ba, trọng số đã tinh chỉnh hoặc huấn luyện sẵn, tập dữ liệu huấn luyện và RAG, embedding, plugin/công cụ, cùng các thư viện ML/LLM và registry mô hình trong stack của bạn. Một mô hình bị đầu độc, một tập dữ liệu bị cài cửa hậu, một mô hình giả mạo tên (typosquatting) trên hub, hoặc một thư viện phụ thuộc ML có lỗ hổng đều có thể xâm phạm ứng dụng của bạn trước khi bạn viết dòng mã đầu tiên. Đây là OWASP LLM03:2025 Supply Chain.

Cách thức: trong khi quét, tác nhân kiểm tra các thành phần AI trong phạm vi — mô hình và tập dữ liệu đến từ đâu và nguồn đó có đáng tin cậy không, plugin/công cụ được kết nối thế nào và được tin cậy tới mức nào, và cây thư viện phụ thuộc trong stack ML/LLM của bạn. CVE trong thư viện phụ thuộc được phân loại theo khả năng khai thác thực tế (KEV / EPSS) và khả năng tiếp cận, nên bạn thấy những CVE thực sự quan trọng thay vì một bức tường nhiễu.

Lý do: ứng dụng AI của bạn chỉ đáng tin cậy bằng các mô hình, dữ liệu và thư viện mà nó kế thừa — và những thứ đó đến từ bên ngoài codebase của bạn, vượt qua các biện pháp kiểm soát ở cấp ứng dụng. Đó chính là lý do nó có mặt trong OWASP LLM Top 10.

Công cụ: osv-scanner để lập danh mục CVE trong thư viện phụ thuộc, sau đó là phễu phân loại EPSS / CISA-KEV / khả năng tiếp cận (xem CVE trong thư viện phụ thuộc); bộ kỹ năng LLM của chúng tôi ánh xạ phát hiện tới OWASP LLM03 và MITRE ATLAS AI Supply Chain Compromise (AML.T0010).

Hạ tầng & Đám mây

Chức năng: quản lý tư thế bảo mật đám mây (CSPM). Ngoài ứng dụng, nó kiểm tra đám mây của bạn để tìm những điểm phơi nhiễm mà kẻ tấn công săn lùng — bucket công khai, IAM cấp quyền quá rộng, cổng mở ra toàn thế giới, dữ liệu không mã hóa hoặc công khai, và các điểm mù trong nhật ký kiểm toán. Không cần agent, chấm điểm theo CVSS.

Cách thức: kết nối một vai trò không cần agent, chúng tôi đảm nhận vai trò đó, liệt kê tài nguyên ở chế độ chỉ đọc, và chạy các bước kiểm tra xác định — không cần khóa, không có quyền ghi. Một phát hiện chỉ được tạo khi một tài nguyên thực sự không đạt một bước kiểm tra.

AWS chỉ với hai cú nhấp, không cần dòng lệnh. Nhấn Mở AWS và tạo vai trò: nút này mở bảng điều khiển AWS CloudFormation với mọi thứ đã được điền sẵn — công cụ quét của chúng tôi, external ID duy nhất của bạn , và một vai trò chỉ đọc (ReadOnlyAccess + SecurityAudit) có tên millenniums-cloud-scan. Đánh dấu ô xác nhận IAM, nhấp Create stack, chờ khoảng một phút, rồi nhập số tài khoản AWS gồm 12 chữ số của bạn vào ứng dụng. Chúng tôi tự dựng ARN của vai trò và kiểm chứng nó bằng một lệnh gọi chỉ đọc thực tế trước khi lưu bất cứ thứ gì; nếu stack vẫn đang được tạo, bạn sẽ được yêu cầu chờ và thử lại, chứ không nhận về một lỗi. Để thu hồi, hãy xóa stack MillenniumsCloudScan . Đã tạo millenniums-cloud-scan từ trước (ví dụ bằng Terraform)? Stack sẽ báo rằng vai trò đã tồn tại — hãy bỏ qua và chỉ cần nhập số tài khoản; vai trò hiện có vẫn hoạt động miễn là nó tin cậy công cụ quét của chúng tôi với external ID của bạn. Template được công khai và ngắn gọn — hãy đọc trước khi chạy: millenniums-cloud-scan-v1.yaml. Thích dùng Terraform hoặc vai trò của riêng bạn? Trang Hạ tầng vẫn tạo mã Terraform và chấp nhận ARN của vai trò.

Bạn không phải người quản lý AWS? Từ trang Quét hệ thống, Lấy liên kết để gửi cho họ sẽ tạo một liên kết riêng tư mở đúng hai bước đó cho người quản lý AWS của bạn — họ không cần tài khoản. Liên kết chỉ làm được đúng một việc: kết nối AWS cho không gian làm việc của bạn. Nó chỉ hiển thị tên công ty của bạn, không bao giờ hiển thị email hay phát hiện của bạn; nó hết hạn sau 7 ngày; và việc tạo liên kết mới sẽ hủy liên kết trước đó. Làn Quét hệ thống của bạn chuyển sang màu xanh lá khi họ hoàn tất.

Azure, Google Cloud và Oracle Cloud cũng kết nối chỉ với một cú nhấp, không cần sao chép hay dán gì. Azure: đăng nhập bằng Microsoft và phê duyệt Redthread; Azure mở một bản triển khai đã điền sẵn, cấp cho công cụ quét của chúng tôi quyền Reader + Security Reader trên subscription bạn chọn. Mỗi quyền cấp mang một dấu hiệu nhận dạng riêng cho không gian làm việc của bạn, và chúng tôi chỉ kết nối subscription có quyền cấp mang dấu hiệu của bạn. Google Cloud: đăng nhập bằng Google, chọn một project bạn sở hữu, và chúng tôi thêm quyền Viewer + Security Reviewer cho công cụ quét của chúng tôi trên project đó bằng phiên đăng nhập của bạn; token Google của bạn chỉ được dùng cho đúng thay đổi đó rồi bị loại bỏ. Oracle Cloud (OCI): Oracle mở một stack Resource Manager đã điền sẵn, tạo nhóm RedthreadCloudScan và một người dùng chỉ dùng khóa API (có địa chỉ email, điều mà các tài khoản Oracle dùng identity domain bắt buộc), một chính sách chỉ đọc (inspect all-resources, cùng quyền read trên cài đặt bucket, mạng và người dùng — không bao giờ đọc nội dung tệp, database wallet hay đầu ra console của VM) và tải lên khóa công khai của không gian làm việc của bạn, sau đó báo lại người dùng này cho chúng tôi. Trong mọi trường hợp, bạn không giao cho chúng tôi bất kỳ bí mật nào, việc thu hồi chỉ cần một cú nhấp trong bảng điều khiển của chính bạn, và mọi kết nối đều được kiểm chứng bằng một lệnh gọi đọc thực tế trước khi được lưu. Thích dùng dòng lệnh? Mỗi đám mây vẫn có các lệnh thủ công (đăng ký ứng dụng Azure, khóa tài khoản dịch vụ GCP, hoặc OCI Cloud Shell); các bí mật bạn dán vào đó là chỉ ghi — không bao giờ được trả về trên bất kỳ màn hình hay API nào. Kubernetes và mọi danh mục Prowler vẫn có thể được thu nạp trực tiếp. Xem tài liệu API.

Lý do: ứng dụng của bạn có thể hoàn hảo mà vẫn bị xâm phạm qua chính hạ tầng nó chạy trên đó — và tư thế bảo mật bị sai lệch mỗi khi một đội ngũ phát hành. Vì không cần agent, nó đủ an toàn để chạy liên tục, chứ không phải mỗi quý một lần.

Công cụ: liệt kê tài nguyên đám mây không cần agent qua boto3 (AWS) với vai trò do bạn cấp (ReadOnlyAccess + SecurityAudit), sau đó là các bước kiểm tra tư thế bảo mật xác định, chấm điểm theo CVSS của chúng tôi. Có thể thu nạp bất kỳ danh mục định dạng Prowlernào để thay thế, và các bước kiểm tra tương tự sẽ chạy cho GCP / Azure / Kubernetes.

Redthread — đồ thị rủi ro & đường tấn công

Redthread là engine đồ thị của chúng tôi. Đây là lớp nằm bên dưới báo cáo đường tấn công, cổng kiểm soát pull request, trình dựng truy vấn và cảm biến runtime — cả bốn đều đọc và ghi vào cùng một đồ thị, nên chúng không bao giờ mâu thuẫn với nhau.

Chức năng: mọi tài sản, danh tính, tuyến mạng và phát hiện trên các đám mây của bạn, trong một đồ thị chuẩn hóa duy nhất — cùng danh sách xếp hạng các đường tấn công đi qua đồ thị đó. Một phát hiện nói rằng "bucket này đang công khai." Một rủi ro nói rằng "Internet tiếp cận được workload này, workload này giữ một thông tin xác thực, và thông tin xác thực đó đọc được dữ liệu khách hàng của bạn." Đường tấn công chính là sản phẩm.

Cách thức: thuật ngữ riêng của từng nhà cung cấp dừng lại ở bộ thu thập. Một AWS role, một service principal Entra ID và một service account GCP đều trở thành cùng một loại nút, nên một đường tấn công có thể vượt qua ranh giới đám mây. Tám quy tắc chạy trên kết quả — workload bị lộ → dữ liệu nhạy cảm, chuỗi thông tin xác thực, bước chuyển hướng liên đám mây, leo thang đặc quyền, dữ liệu ngầm, tài sản AI bị lộ, và chuỗi xuyên lớp đã được chứng minh. Mỗi quy tắc trả về một đường tấn công, không phải một cảnh báo.

Lý do: các công cụ tư thế bảo mật tạo ra hàng trăm cảnh báo nghiêm trọng mà không có thứ tự ưu tiên. Chỉ xếp hạng theo CVSS không cho bạn biết kẻ tấn công có thực sự tới được đó hay không. Khả năng tiếp cận mới là ưu tiên, và khả năng tiếp cận chỉ tồn tại trong một đồ thị.

Công cụ: Redthread là engine; tệp không phải định dạng độc quyền. Đồ thị được xuất theo định dạng node-link của graphify, nên bạn có thể tự duyệt đồ thị — graphify path "internet" "customer-data" — hoặc tải xuống từ chế độ xem Rủi ro. Không cần vận hành cơ sở dữ liệu đồ thị, và không bị khóa chặt vào nhà cung cấp: nếu bạn rời đi, đồ thị cũng đi cùng bạn.

Kiến trúc & xác thực

Khách hàng có thể đọc phần này trong ứng dụng: đăng nhập rồi mở bất kỳ liên kết tài liệu nào.

Redthread Flow — đọc đồ thị

Redthread Flow là bảng trong bảng điều khiển, nơi bạn đặt câu hỏi cho đồ thị và nhận câu trả lời dưới dạng hình vẽ thay vì danh sách. Bảng này nằm ở thanh điều hướng bên trái, ngay dưới Bảng điều khiển.

Bản đồ hệ thống. Redthread Flow mở ra với toàn bộ hệ thống của bạn dưới dạng một mạng lưới. Mỗi tài sản là một chấm có màu theo nơi nó nằm (cam cho AWS, xanh mòng két cho Oracle Cloud, xanh dương cho Azure, xanh lá cho Google Cloud, tím cho các máy có cảm biến, hồng cho danh tính bên ngoài, đen cho internet) và có kích thước theo loại tài sản, để máy, khối lượng công việc và tác tử AI nổi bật. Các tài sản của cùng một đám mây tụ lại trong một vùng tô nhạt, và đám mây có từ ba tài sản trở lên có một nhãn đánh dấu ở giữa. Các liên kết thông thường là đường xanh dương mảnh; liên kết đi từ đám mây này sang đám mây khác có màu đỏ, và đường tấn công là các đường dày theo màu mức độ nghiêm trọng. Một quyền ký tự đại diện (một vai trò được phép làm mọi thứ trên mọi kho dữ liệu) được vẽ thành một đường tới nút “Mọi kho dữ liệu” của đám mây đó, thay vì một đường cho mỗi kho. Tên được rút gọn (ví dụ aws-ecs) và nằm trên các nhãn trắng nhỏ không bao giờ chồng lên nhau; internet, các nút trung tâm và mọi tài sản nằm trên đường tấn công nghiêm trọng hoặc cao luôn được ghi tên, các tài sản còn lại hiện tên khi bạn phóng to. Tài sản có vấn đề nghiêm trọng hoặc cao có viền đỏ. Bản đồ được vẽ bằng Sigma.js nên hệ thống có hàng nghìn liên kết vẫn mượt, và khi di chuột lên một tài sản, mọi thứ không liên quan đến nó sẽ mờ đi.

Làm nổi bật rủi ro. Bản đồ mở ra với Làm nổi bật rủi ro đang bật: mọi thứ không có vấn đề chuyển sang màu xám nhạt, nên những gì nổi bật là mọi tài sản có vấn đề nghiêm trọng hoặc cao (được ghi tên trên nhãn đỏ) và mọi đường tấn công nghiêm trọng hoặc cao. Bảng bên phải liệt kê các đường tấn công đó; nhấp vào một đường để chỉ hiển thị đường đó và phóng to tới nó, nhấp lại để quay về. Tắt Làm nổi bật rủi ro để xem toàn bộ hệ thống theo màu của từng đám mây.

Cách đọc: cuộn hoặc dùng + và − để phóng to thu nhỏ, kéo nền để di chuyển, kéo một chấm để đặt nó, và Vừa khung để căn lại. Vòng màu và con số đánh dấu vấn đề (vòng là mức nghiêm trọng cao nhất); chấm xanh nhỏ nghĩa là có cảm biến đang báo cáo. Nhấn vào một chấm để mở thẻ chi tiết, vấn đề và liên kết; các tài sản kề nó vẫn sáng, phần còn lại mờ đi. Bạn có thể ẩn danh tính, hoặc chỉ hiện liên kết giữa các đám mây.

Hỏi đồ thị là thẻ thứ hai: chế độ hỏi đáp mô tả bên dưới. Đường tấn công là thẻ thứ ba: các chuỗi đã xếp hạng từ internet tới thứ cần bảo vệ. Sự cố đám mây có trang riêng trong menu bên trái, dưới Trò chuyện, liệt kê mọi lỗi cấu hình trên các đám mây, lọc được theo đám mây.

Cách sử dụng

Bảng mở ra với một đồ thị đã được vẽ sẵn. Nó chạy lần lượt các câu hỏi đã lưu và dừng ở câu hỏi đầu tiên trả về một đường tấn công, đồng thời làm nổi bật câu hỏi đã được chọn — nhờ vậy bạn thấy ngay một câu trả lời thật thay vì một khung trống. Có ba cách để bạn tự đặt câu hỏi:

• Ngôn ngữ tự nhiên. Nhập một câu hỏi — "có thứ gì trên Internet đang giữ một khóa có thể tiếp cận dữ liệu khách hàng ở một đám mây khác không?" — rồi nhấn Hỏi. Một mô hình sẽ chuyển câu hỏi thành truy vấn đồ thị có cấu trúc. Truy vấn đã chạy luôn được hiển thị trong mục "truy vấn tôi đã chạy": mở rộng mục này để xác nhận mô hình đã hiểu đúng ý bạn. Nếu câu hỏi nằm ngoài khả năng biểu đạt của đồ thị, nó sẽ nói rõ và chỉ ra phần còn thiếu, thay vì chạy truy vấn gần nhất tình cờ hợp lệ. Một câu trả lời cho câu hỏi không ai hỏi trông y hệt một câu trả lời.
• Câu hỏi đã lưu. Các nút bên dưới ô nhập là những câu hỏi phổ biến, đã được soạn sẵn: VM bị lộ có khóa bị rò rỉ tiếp cận được PII ở đám mây khác, workload giữ thông tin xác thực tiếp cận được kho dữ liệu, danh tính có thể trở thành một danh tính khác, kho dữ liệu nhạy cảm tiếp cận được từ Internet, và các câu hỏi khác. Nhấp vào một nút để chạy.
• Tự xây dựng truy vấn. Mở rộng Tự xây dựng truy vấn để dùng các danh sách thả xuống: tìm [loại tài sản] trong [đám mây] đang [mức độ phơi nhiễm], được kết nối qua [quan hệ], tới [loại tài sản] đang giữ [phân loại dữ liệu]. Không cần học ngôn ngữ truy vấn.

Số câu hỏi bị giới hạn theo giờ tùy theo gói — 10 với Free, 40 với Starter, 120 với Growth, 400 với Enterprise — vì mỗi câu hỏi bằng ngôn ngữ tự nhiên tốn một lần gọi mô hình. Truy vấn đã lưu và truy vấn tự xây dựng chạy trực tiếp trên đồ thị và không bị giới hạn.

Đọc hình vẽ

Hình vẽ là một luồng phân tầng từ trái sang phải: hướng của mũi tên là hướng của cuộc tấn công. Cột ngoài cùng bên trái là nơi kẻ tấn công bắt đầu — thường là Internet — và cột ngoài cùng bên phải là thứ họ tiếp cận được.

Phá vỡ chuỗi tấn công

Bên dưới đồ thị là danh sách điểm cắt được xếp hạng. Mỗi bước nhảy trong toàn bộ tập kết quả được chấm điểm theo số tuyến bị loại bỏ nếu bạn cắt nó, và mỗi dòng nêu hành động (xoay vòng và gỡ bỏ thông tin xác thực, thu hẹp quyền, đóng điểm phơi nhiễm), lý do hành động đó hiệu quả, và bằng chứng. Con số bên trái là số tuyến bị phá vỡ. Trên một tài khoản AWS thực tế, điểm cắt hàng đầu — xoay vòng một thông tin xác thực trên một vai trò — đã đóng 86 trên 1.382 đường tấn công.

"Không có đường tấn công nào khớp" nghĩa là gì

Kết quả rỗng cũng là một câu trả lời, không phải lỗi. Không có gì trong đồ thị hiện tại kết nối những thứ đó với nhau. Hai lưu ý trung thực: phạm vi bao phủ là bất cứ thứ gì bạn đã kết nối, nên một đường tấn công chúng tôi không thấy không có nghĩa là nó không tồn tại; và việc phân loại dữ liệu không bao giờ dựa trên suy đoán — một kho dữ liệu vẫn ở trạng thái unknown cho đến khi DSPM lấy mẫu hoặc bạn gắn nhãn, nên các câu hỏi lọc theo phân loại sẽ trả về kết quả rỗng một cách chính xác trên tài khoản chưa được phân loại. Hãy chạy một lần quét có bật phân loại và các câu hỏi đó sẽ bắt đầu có câu trả lời.

Phân tích đường tấn công — là gì

Phân tích đường tấn công lập bản đồ các tuyến mà kẻ tấn công có thể dùng để di chuyển trong môi trường của bạn và tiếp cận những tài sản quan trọng. Nó tồn tại vì các lần quét riêng lẻ tạo ra hàng nghìn phát hiện mà không cho thấy phát hiện nào nối chuỗi thành thứ có thể khai thác. Một lỗi cấu hình đơn lẻ hiếm khi dẫn đến xâm phạm; nhưng lỗi cấu hình cộng với một quyền yếu cộng với một máy chủ bị lộ thì có.

Bốn bước, và chúng tôi thực hiện cả bốn:

1. Khám phá tài sản và rủi ro. Khả năng quan sát đầy đủ, không cần agent, đối với workload, danh tính, cấu hình và dữ liệu — cùng với lỗ hổng, bí mật bị lộ, lỗi cấu hình và quyền hạn quá mức. Trên một tài khoản AWS cỡ trung bình, con số này thường là vài trăm tài sản và hàng chục nghìn quan hệ quyền hạn.
2. Lập bản đồ dựa trên đồ thị. Các rủi ro đó được đặt lên một đồ thị duy nhất kết nối các tài nguyên và cho thấy chúng liên quan với nhau thế nào — một workload có IP công khai và một lỗ hổng nghiêm trọng, liên kết với một danh tính có đặc quyền quá mức. Mỗi cạnh mang một mức độ tin cậy: đã chứng minh, trích xuất từ cấu hình, hoặc suy luận.
3. Xác định đường tấn công. Đồ thị được tìm kiếm để phát hiện tổ hợp độc hại — các chuỗi trong đó nhiều vấn đề có mức độ nghiêm trọng thấp khi đứng riêng lẻ nối với nhau thành một tuyến có tác động lớn tới thứ có giá trị. Tám quy tắc chạy trên đồ thị, mỗi quy tắc trả về một đường tấn công thay vì một cảnh báo.
4. Ưu tiên hóa. Các đường tấn công được xếp hạng theo mức độ nghiêm trọng, sau đó đã chứng minh trước lý thuyết, rồi đến mức độ trực tiếp của đường đi, rồi phạm vi ảnh hưởng. Một tuyến dẫn tới tài sản trọng yếu hoặc tới đặc quyền cao được xếp trên tuyến kết thúc ở nơi vô hại.

Một lưu ý về cách hoạt động của việc tìm kiếm, vì nó làm thay đổi câu trả lời. Một phép tìm đường ngắn nhất thông thường sẽ tìm tuyến ngắn nhất tới mỗi mục tiêu — vốn thường không phải tuyến quan trọng. Một bucket có thể đọc công khai tiếp cận được chỉ trong một bước nhảy, và chính bước nhảy đó che khuất chuỗi đánh cắp thông tin xác thực ba bước nhảy cũng dẫn tới cùng bucket đó. Vì vậy, một quy tắc phụ thuộc vào một loại bước nhảy cụ thể sẽ tìm kiếm đi qua bước nhảy đó một cách tường minh, và chuỗi được báo cáo thay vì bị che khuất.

Rủi ro liên đám mây

Chức năng: các đường tấn công bắt đầu ở một đám mây và kết thúc ở một đám mây khác — những đường mà công cụ riêng của mỗi nhà cung cấp đều không thấy, vì mỗi bên chỉ nhìn vào chính mình.

Cách thức: chúng tôi đọc các quan hệ tin cậy thực sự vượt qua ranh giới: một AWS role có trust policy chỉ định một issuer Entra ID hoặc Google, một GCP workload-identity pool tin cậy một tài khoản AWS. Cả hai phía phải khớp nhau thì một cạnh mới tồn tại — chỉ riêng một quyền được cấp thì không bao giờ đủ.

Trên đồ thị: một quan hệ tin cậy xuyên ranh giới đã được xác nhận sẽ trở thành một cạnh can-assume giữa các đám mây, và mọi đường tấn công đi qua cạnh đó được xếp hạng là rủi ro T3 — chuyển hướng liên đám mây trên GET /api/cloud/risks, kèm đường đi đầy đủ theo từng cạnh và bằng chứng, sắp xếp theo thứ tự đã chứng minh trước tiềm ẩn. Vì đồ thị được xuất dưới dạng JSON node-link mở, bạn cũng có thể tự duyệt nó: graphify path "aws-prod" "azure-tenant" --graph graph.json.

Quan hệ tin cậy quá rộng là một phát hiện riêng. Một vai trò có trust policy không có điều kiện sub (subject) sẽ tin cậy mọi danh tính trong tenant bên ngoài đó, chứ không chỉ danh tính bạn muốn — rất dễ vô tình phát hành khi sao chép một đoạn mã OIDC, và tự nó đã là một phát hiện nghiêm trọng ngay cả trước khi có đường tấn công nào được vẽ ra.

Ngoài tin cậy danh tính, còn ba loại liên kết khác giữa các đám mây.

• Mạng: các đường hầm VPN site-to-site trên AWS, Oracle Cloud, Azure và Google Cloud được đọc ở từng phía và ghép theo địa chỉ IP công khai, nên một đường hầm từ AWS tới gateway của Oracle hiển thị thành một liên kết giữa hai mạng.
• Sử dụng thực tế: AWS CloudTrail ghi lại địa chỉ đứng sau mọi lệnh gọi API trong 24 giờ qua; một lệnh gọi đến từ VM ở một đám mây khác đã kết nối sẽ tạo liên kết đã được chứng minh từ VM đó tới danh tính AWS mà nó dùng.
• Khóa dùng từ nơi khác: Các khóa tương thích S3 của Oracle được liệt kê kèm người dùng sở hữu. Khóa đám mây tìm thấy trong mã nguồn, và liên kết đăng nhập Oracle trên tài khoản dùng identity domains, chưa được hỗ trợ.

Lý do: danh tính liên kết là cách các đội ngũ tránh dùng khóa tồn tại lâu dài — và đó cũng là cách kẻ tấn công di chuyển giữa các đám mây của bạn. Cả AWS, Azure lẫn GCP đều không gắn cờ một quan hệ tin cậy do phía bên kia thiết lập, nên đây chính là điểm mù mà các công cụ tư thế bảo mật đơn đám mây bỏ ngỏ.

Công cụ: chính sách tin cậy AWS IAM, Entra ID qua Microsoft Graph, GCP workload-identity federation. Các issuer được nhận diện xác định, không bao giờ phỏng đoán — một issuer không nhận diện được sẽ không tạo cạnh liên đám mây nào, vì gắn nhãn sai còn tệ hơn là thiếu.

Tư thế bảo mật dữ liệu (DSPM)

Chức năng: những gì thực sự nằm trong các kho dữ liệu của bạn — dữ liệu cá nhân, dữ liệu chủ thẻ, dữ liệu sức khỏe, thông tin xác thực — và nơi một bản sao của production đã âm thầm xuất hiện.

Cách thức: hai cấp. Lấy mẫu có giới hạn đọc một mẫu nhỏ, có giới hạn, các đối tượng thông qua chính vai trò không cần agent mà bạn đã cấp — không snapshot, không thêm quyền, không cài đặt gì. Với các cơ sở dữ liệu không được quản lý nằm trên ổ đĩa VM, một snapshot worker tạm thời chạy bên trong tài khoản của bạn, gắn một snapshot ở chế độ chỉ đọc, và chỉ truyền phát hiện — không bao giờ truyền giá trị, nội dung tệp hay một dòng dữ liệu nào — rồi tự kết thúc.

Dữ liệu ngầm: các kho lưu trữ được lấy dấu vân tay theo schema, nên một schema production nằm trong bucket staging sẽ được gắn cờ là bản sao cần xem xét — và được nâng lên mức nghiêm trọng khi bản sao đó còn bị lộ ra Internet.

Lý do: mức độ nghiêm trọng là vô nghĩa nếu không biết điều gì đang bị đe dọa. Một bucket công khai chứa tệp CSS và một bucket công khai chứa hồ sơ khách hàng là cùng một phát hiện nhưng là hai rủi ro hoàn toàn khác nhau. Phân loại chính là thứ tách biệt chúng — và đó là lý do chúng tôi không bao giờ phỏng đoán: một kho chưa được gắn nhãn vẫn ở trạng thái unknown, không bao giờ được mặc định là an toàn hay nhạy cảm.

Công cụ: bộ phân loại theo mẫu + entropy kèm kiểm tra tính hợp lệ (Luhn, cấu trúc SSN), đối chiếu tên cột, và lấy dấu vân tay schema để truy dòng dữ liệu. Có giới hạn theo từng đối tượng và tổng thể; phạm vi bao phủ được báo cáo theo những gì thực sự được lấy mẫu, không bao giờ ngoại suy.

Từ mã đến đám mây — chặn trước khi phát hành

Chức năng: một bước kiểm tra trên mọi pull request, đọc các manifest Terraform, CloudFormation, ARM và Kubernetes của bạn và đánh trượt build khi một thay đổi sẽ tạo ra vấn đề thực sự.

Cách thức: các tài nguyên dự kiến được hợp nhất vào đồ thị rủi ro đang hoạt động của bạn, và chúng tôi báo cáo những gì thay đổi đó sẽ tạo ra — chứ không phải hiện trạng tài khoản của bạn. Phát hiện được đăng lại vào pull request dưới dạng một bình luận duy nhất, được chỉnh sửa ở mỗi lần push, không bao giờ tạo bình luận mới mỗi lần.

Cổng kiểm soát chặn đúng những gì diff của bạn chịu trách nhiệm: một lỗi cấu hình nghiêm trọng mà nó khai báo, một đường tấn công mà nó tạo ra, hoặc một thông tin xác thực mà nó commit. Rủi ro sẵn có của tài khoản không bao giờ chặn pull request — vì đó chính là lý do khiến người ta tắt cổng kiểm soát. Chế độ chỉ báo cáo chỉ cần thay đổi một dòng.

Lý do: thời điểm rẻ nhất để khắc phục một lỗi cấu hình là trước khi nó tồn tại. Mọi thứ sau đó đều là khắc phục, một khung thời gian thay đổi, và một cuộc tranh luận về thứ tự ưu tiên.

Công cụ: một trình phân tích cú pháp HCL thực thụ (không phải so khớp theo dòng), cùng với CloudFormation / ARM / Kubernetes. Tính năng quét bí mật loại trừ placeholder và tham chiếu biến — một công cụ quét gắn cờ password = var.db_password sẽ khiến mọi người quen bỏ qua nó. Có sẵn cho GitHub Actions và Azure DevOps; xác thực bằng khóa riêng cho từng tài sản, không bao giờ dùng token tài khoản của bạn.

Hỏi đồ thị

Chức năng: các câu hỏi đã lưu và một trình dựng truy vấn cho những câu hỏi chúng tôi chưa lường trước — "hiển thị mọi VM bị lộ ra Internet đang giữ một khóa dạng văn bản thuần cấp quyền truy cập vào kho chứa dữ liệu cá nhân."

Cách thức: chọn một loại tài sản, lọc theo thuộc tính của nó, rồi đi theo một quan hệ tới những gì nó có thể tiếp cận. Kết quả là các đường tấn công kèm bằng chứng cho từng bước nhảy, chứ không phải danh sách tên.

Lý do: các câu hỏi của bạn trong một sự cố không phải là những câu hỏi nhà cung cấp đã viết sẵn. Tìm kiếm văn bản tự do không thể biểu đạt "A và B và tiếp cận C" — đó là bài toán quan hệ thành viên tập hợp và khả năng tiếp cận, cần đến đồ thị.

Công cụ: một dạng truy vấn đóng, an toàn — truy vấn là dữ liệu, không bao giờ là mã, với các quan hệ được kiểm tra hợp lệ và giới hạn độ sâu duyệt, nên không thể bị biến thành thực thi mã hay bị treo trên một hệ thống lớn.

Khắc phục & tạo ticket

Chức năng: một webhook có chữ ký khi một rủi ro khớp với quy tắc của bạn — nối vào hệ thống tự động hóa của riêng bạn, hoặc đi thẳng vào Jira hay ServiceNow với đường tấn công nằm trong ticket.

Cách thức: bạn đăng ký một workflow bằng POST /api/workflows — { name, url, kind: "webhook|jira|servicenow", rules: ["T2"], min_severity: "critical", proven_only: false, auth_header }. Một lần gửi chỉ được kích hoạt khi rủi ro khớp với tất cả các bộ lọc của bạn: một trong các quy tắc đồ thị được chỉ định (T1–T8), ở mức bằng hoặc cao hơn min_severity, và — nếu bạn đặt proven_only — chỉ khi đường tấn công thực sự đã bị khai thác, chứ không chỉ là tiếp cận được. Khóa bí mật để ký chỉ được trả về một lần và không bao giờ lặp lại; POST /api/workflows/<id>/test gửi một lần gửi giả lập để bạn kiểm chứng việc kết nối trước khi có sự kiện thật.

Kiểm chứng mọi lần gửi. Mỗi yêu cầu mang một chữ ký HMAC trong header X-Millennium-Signature , tính trên body thô; hãy tính lại bằng khóa bí mật của bạn và từ chối mọi thứ không khớp. Các lần gửi có giới hạn chống phát lại (dấu thời gian + nonce), và đích đến phải là HTTPS phân giải tới một địa chỉ công khai — webhook không bao giờ có thể bị trỏ tới một dịch vụ nội bộ hay một điểm cuối metadata của đám mây.

Ngăn chặn từ thượng nguồn: chính đồ thị rủi ro đó vận hành cổng kiểm soát PR từ mã đến đám mây — POST /api/iac/scan đánh trượt pull request có thể tạo ra một đường tấn công nghiêm trọng trên đồ thị trực tiếp của bạn, nên cách khắc phục rẻ nhất (không bao giờ merge nó) diễn ra trước khi có bất cứ thứ gì cần khắc phục.

Lý do: một nhà cung cấp bảo mật nắm quyền ghi trên toàn bộ đám mây của bạn là một điểm lỗi duy nhất mang tính thảm họa, và là thứ khó vượt qua nhất trong một cuộc rà soát bảo mật. Tách biệt phát hiện khỏi thực thi loại bỏ cả hai vấn đề.

Cảm biến runtime Tiện ích bổ sung Enterprise

Chức năng: phát hiện runtime tùy chọn từ các node Kubernetes, máy ảo Linux và các máy có cảm biến endpoint, được đưa lên cùng đồ thị rủi ro với mọi thứ khác.

Cách thức: một Falco DaemonSet gửi phát hiện thẳng tới Redthread, cùng một sidecar nhỏ gửi tín hiệu nhịp để node yên lặng vẫn hiển thị trực tuyến. Bật trong ứng dụng, thêm cảm biến, rồi chạy ba lệnh được hiển thị. Tắt sẽ thu hồi mọi cảm biến ngay lập tức.

Máy ảo Linux: chạy lệnh được hiển thị sau khi bạn đăng ký cảm biến trên máy ảo, với quyền root. Lệnh cài Falco từ kho gói chính thức falco.org, chọn probe eBPF hiện đại (Linux 5.8 trở lên, không cần module kernel), ghi cấu hình chỉ root đọc được để gửi mỗi phát hiện tới Redthread, và khởi chạy Falco như một dịch vụ tồn tại sau khi khởi động lại. Đầu ra HTTP của Falco không đặt được header, nên khóa cảm biến nằm trong URL của cấu hình đó; khóa chỉ có thể gửi phát hiện. Hỗ trợ Debian và Ubuntu (apt) cùng RHEL, Oracle Linux, Amazon Linux và Fedora (dnf hoặc yum); chạy cùng lệnh với --uninstall để gỡ bỏ.

Mọi máy ảo trong một đám mây: các lệnh Cloud Shell cho cả đội máy cũng cài Falco khi bạn thêm MAI_SENSOR_KEY (Runtime → Thêm cảm biến hiển thị sẵn). Trên Azure (Run Command chạy với quyền root) và Google Cloud (gcloud ssh với sudo), mọi máy ảo Linux đều được cài Falco; trên Oracle Cloud, Run Command chạy bằng người dùng hạn chế nên Falco chỉ được cài trên máy ảo mà thiết lập quản trị một lần đã cấp sudo cho người dùng đó, và bản tóm tắt nêu tên các máy còn lại.

Máy có cảm biến endpoint: cảm biến endpoint cũng kiểm tra các tiến trình đang chạy mỗi 20 giây để tìm trình đào tiền ảo, dấu hiệu reverse shell hoặc chương trình chạy từ thư mục tạm, và gửi phát hiện ngay lần đầu xuất hiện (mỗi giờ một lần cho mỗi kết quả). Không cần quyền kernel và chạy trên macOS và Linux; không thấy được thứ gì ngắn hơn một lần kiểm tra, nên Falco vẫn là lựa chọn đầy đủ trên Linux. Dòng lệnh được so khớp trên máy và không bao giờ được gửi đi: một phát hiện chỉ gồm quy tắc, tên tiến trình ngắn và thời gian. Phát hiện chỉ được nhận khi Runtime đang bật; nếu không, cảm biến ngừng gửi trong sáu giờ.

Lý do: cấu hình bị sai lệch và một workload có thể bị xâm phạm mà không cần một thiết lập nào thay đổi. Nguồn cấp dữ liệu mối đe dọa của nhà cung cấp phát hiện được phần lớn điều đó mà hoàn toàn không cần agent — tính năng này dành cho những đội ngũ đã quyết định rằng khả năng quan sát dưới một phút, ở cấp nhân hệ điều hành, xứng đáng với một DaemonSet có đặc quyền, và đó là quyết định có chủ đích của họ chứ không phải mặc định của chúng tôi.

Phát hiện, không ngăn chặn. Không bao giờ chặn, kết thúc tiến trình hay cách ly. Phần còn lại của nền tảng không cài đặt gì trên máy chủ của bạn; còn tính năng này thì có chủ đích cài đặt, đó là lý do nó là một tiện ích bổ sung riêng và mặc định tắt. Nếu bạn muốn hoàn toàn không dùng agent, các phát hiện từ GuardDuty, Security Hub và Inspector được thu nạp vào cùng đồ thị mà không cần agent nào.

Công cụ: Falco (CNCF) cho probe eBPF và bộ quy tắc. Sidecar tín hiệu nhịp không có đặc quyền và bỏ mọi capability. Lượng tiếp nhận có giới hạn; vượt giới hạn, sự kiện bị bỏ và được đếm lại, không bao giờ bị mất một cách âm thầm.

Kiểm thử xâm nhập mạng — các giai đoạn

Khách hàng có thể đọc phần này trong ứng dụng: đăng nhập rồi mở bất kỳ liên kết tài liệu nào.

Báo cáo tuân thủ & chứng thực

Mỗi lần quét hoàn tất đều tạo ra một báo cáo hỗ trợ kiểm toán dựa trên các tiêu chuẩn mà doanh nghiệp dùng để kiểm thử (PTES, NIST SP 800-115, OWASP WSTG, CREST, CVSS). Báo cáo có ba cấp để mỗi người đọc nhận đúng phần mình cần:

• Thư chứng thực — một trang tóm tắt đã lược bỏ thông tin nhạy cảm, có chữ ký, mà bạn có thể gửi cho các bên liên quan của bạn — khách hàng, bộ phận mua sắm hoặc đơn vị đánh giá rủi ro bên thứ ba. Thư nêu phạm vi, thời gian, phương pháp và số lượng theo mức nghiêm trọng — không có chi tiết khai thác. Lấy thư tại GET /api/runs/{id}/attestation.
• Báo cáo tuân thủ đầy đủ — tóm tắt cho lãnh đạo cùng chi tiết kỹ thuật cho từng phát hiện: Quy tắc thực hiện kiểm thử, bản đồ nhiệt mức nghiêm trọng, lộ trình khắc phục, và ma trận truy vết AI ánh xạ từng phát hiện sang OWASP LLM 2025 → MITRE ATLAS → NIST AI RMF / ISO 42001 / EU AI Act. Đối chiếu chéo với SOC 2, ISO 27001 và NIST CSF. GET /api/runs/{id}/compliance.
• Bản JSON song song — cùng dữ liệu dưới dạng report.json cho Vanta, Drata hoặc Secureframe. GET /api/runs/{id}/compliance.json.

Chấm điểm trung thực. CVSS là điểm khuyến cáo thật cho các CVE trong thư viện phụ thuộc, hoặc vector cơ sở chuẩn của lớp lỗ hổng (được ghi rõ như vậy) — không bao giờ là con số bịa đặt. Các phát hiện về hành vi (jailbreak, prompt injection) đi kèm một Tỷ lệ tấn công thành công — tỷ lệ thành công/số lần thử thực tế — khi bạn đo nó (POST /api/runs/{id}/measure-asr), vì một jailbreak thành công 3 lần trên 100 không giống một jailbreak thành công 90 lần.

Công cụ: CVSS 3.1 để chấm điểm; OWASP LLM 2025 + MITRE ATLAS v5.6.0 để truy vết; đối chiếu khung tiêu chuẩn với PCI DSS 11.4, SOC 2, ISO 27001 / 42001, NIST CSF / AI RMF, EU AI Act; OpenVEX cho các kết luận bị ảnh hưởng/không bị ảnh hưởng; và Tỷ lệ tấn công thành công được báo cáo kèm khoảng tin cậy Wilson 95%. Tùy chọn rà soát bởi chuyên gia có chứng chỉ CREST/OSCP .

SSO, SCIM & vai trò

Chức năng: danh tính doanh nghiệp cho các nhóm — đăng nhập một lần, tự động cấp phát và thu hồiquyền người dùng, phân quyền theo vai trò và nhật ký kiểm toán. Mọi tài sản, lần quét và phát hiện đều thuộc phạm vi không gian làm việc của bạn.

Cách thức: bốn vai trò — chủ sở hữu (toàn quyền, kể cả thanh toán), quản trị viên (quản lý không gian làm việc), thành viên (thực hiện công việc), người xem (chỉ đọc) — cùng với:

• Đăng nhập một lần (OIDC) — nhóm của bạn đăng nhập qua nhà cung cấp danh tính của bạn (Okta, Entra/Azure AD, Google, Auth0); người dùng mới thuộc tên miền email của bạn được cấp tài khoản tự động. Chủ sở hữu cấu hình bằng URL issuer, client ID/secret và tên miền của bạn.
• Cấp phát qua SCIM 2.0 — IdP của bạn tự động tạo và, quan trọng hơn, thu hồi người dùng. Vô hiệu hóa một người trong IdP sẽ cắt quyền truy cập của họ tại đây ngay lập tức: token của họ bị thu hồi, chứ không chỉ là bật/tắt một cờ.
• Nhật ký kiểm toán — ai đã kích hoạt lần quét nào, và ai đã xem hoặc xuất báo cáo nào.

Lý do: ở quy mô nhóm, rủi ro không chỉ đến từ bên ngoài — đó có thể là một nhân viên cũ chưa bị cắt quyền truy cập, hoặc một tài khoản có đặc quyền quá mức. SSO tập trung việc đăng nhập theo chính sách của IdP (MFA, truy cập có điều kiện); SCIM bảo đảm việc thu hồi quyền khi nhân viên nghỉ việc diễn ra tức thì, chứ không phải một ticket mà ai đó quên xử lý.

Công cụ: OpenID Connect (OIDC) cho SSO — Okta, Microsoft Entra ID, Google Workspace, Auth0; SCIM 2.0 để cấp phát/thu hồi quyền; bearer token riêng cho từng tổ chức thuê bao với phép so sánh thời gian hằng định và thu hồi tức thì. Gói Enterprise. Xem SSO & SCIM để thiết lập.

Hướng dẫn: chạy lần quét đầu tiên

Mục tiêu: từ một tài khoản mới đến một phát hiện đã được chứng minh.

Điều kiện tiên quyết

• Một tài khoản đã xác minh (bắt đầu nhanh trên trình duyệt).
• Một URL mục tiêu — một phiên bản ứng dụng đang chạy thực tế mà bạn sở hữu hoặc được phép kiểm thử. Hãy dùng một URL staging, không phải production. Mục này là bắt buộc; riêng mã nguồn của bạn chưa phải là một ứng dụng đang chạy. Chưa có? Xem Nên quét mục tiêu nào.
• Tùy chọn: mã nguồn của bạn — một URL repo git hoặc một tệp .zip tải lên, để thực hiện lần quét hộp trắng chuyên sâu hơn.

Các bước

1. Mở ứng dụng và dán mục tiêu vào ô quét, hoặc gọi POST /api/scan.
2. Nếu bạn có mã nguồn, hãy thêm vào — một URL repo hoặc đường dẫn cục bộ trong trường source . Đây là yếu tố lớn nhất quyết định chất lượng phát hiện.
3. Bắt đầu quét. Ghi lại run_id.
4. Chờ quét xong (trạng thái running → false). Thường chỉ mất vài phút.
5. Mở báo cáo và phân loại từ trên xuống: xử lý mức nghiêm trọng trước.

Khắc phục sự cố

• 403, "verify your email" (hãy xác minh email) — nhấp vào liên kết xác minh, hoặc nhấn "Gửi lại" / POST /api/resend.
• 402, đã hết hạn mức — không còn lượt quét đi kèm gói hoặc lượt trong gói quét. Hãy mua gói quét trong mục Thanh toán (các gói).
• 500, "scan did not start" (lần quét không khởi động được) — công cụ quét không khởi chạy được (Docker hoặc khóa mô hình). Nếu tự lưu trữ, hãy kiểm tra .env; trên ứng dụng do chúng tôi lưu trữ, hãy thử lại.
• Không có phát hiện nào khi chỉ quét URL — cung cấp source rồi chạy lại. Chỉ quét hộp đen thường bỏ sót các đường tấn công đặc thù của AI.

Hướng dẫn: đăng ký mục tiêu

Nếu bạn quét cùng một ứng dụng nhiều lần, hãy đăng ký nó một lần ở thẻ Mục tiêu thay vì dán lại mỗi lần. Mỗi mục tiêu ghi nhớ cài đặt riêng của nó, nên quét lại chỉ cần một cú nhấp vào Quét ngay. Các mục tiêu đã đăng ký cũng chính là thứ mà các gói CI tự động quét trên mỗi pull request.

Ý nghĩa của từng trường

Điều gì xảy ra khi bạn nhấp Quét ngay

1. Cài đặt của bạn được kiểm tra, và mọi thứ không thể hoạt động đều được phát hiện ngay — ví dụ Chỉ các tệp đã thay đổi cần một kho mã, nên bạn được báo trước khi quét bắt đầu thay vì sau khi quét thất bại.
2. Chính gói và mức trần chi tiêu được áp dụng, nên một lần quét không bao giờ vượt ngân sách của bạn (xem Giới hạn chi phí & an toàn).
3. Bài kiểm thử chạy trong một sandbox biệt lập, dùng một lần — mã của bạn không bao giờ được tái sử dụng hay lưu giữ (xem Dữ liệu của bạn).
4. Khi hoàn tất, kết quả hiển thị trong mục Phát hiện Pentest (xem Đọc kết quả quét).

Hướng dẫn: đọc kết quả quét

Khi một lần quét hoàn tất, hãy mở nó từ danh sách Lần quét . Kết quả hiển thị trong mục Phát hiện Pentest, được sắp xếp thành các thẻ để bạn không bao giờ phải cuộn mới tới được một phần.

Các thẻ

Lọc phát hiện

Một lần quét lớn có thể đưa ra hàng trăm phát hiện. Các nút màu phía trên danh sách giúp bạn tập trung — nhấp vào một nút để lọc, nhấp ✕ xóa bộ lọc để xem lại toàn bộ:

1. Nút mức nghiêm trọng — Nghiêm trọng Cao Thấp — chỉ hiển thị phát hiện ở mức đó. Một lần quét lớn mặc định mở ở mức nghiêm trọng nhất, để vấn đề tệ nhất hiện ra trước mắt bạn đầu tiên.
2. ⚡ PoC — chỉ hiển thị các phát hiện có khai thác hoạt động được và đã được chứng minh (những phát hiện có độ tin cậy cao nhất).

Mọi phát hiện cũng được kiểm tra lại theo hướng phản biện trước khi hiển thị: bất cứ phát hiện nào bị công cụ quét đánh giá là có thể là dương tính giả sẽ bị ẩn theo mặc định (một nút bật/tắt cho phép hiện lại để bạn tự xem xét kết luận đó).

Đọc một phát hiện

1. Bắt đầu với mức Nghiêm trọng và Cao — đó là những gì kẻ tấn công tiếp cận được sớm nhất.
2. Mở "Bằng chứng khai thác (PoC)" để xem, theo từng bước dễ hiểu, chính xác lỗ hổng bị khai thác như thế nào. Ở các gói trả phí, mở rộng ▸ Script khai thác để có mã khai thác chạy được thực sự, giúp kỹ sư tái hiện lỗi.
3. Đọc "Khắc phục" — bản sửa cụ thể — cùng các vị trí trong mã.
4. Sửa lỗi (xem hướng dẫn tiếp theo) và quét lại để xác nhận lỗ hổng đã được bịt.

Hướng dẫn: khắc phục những gì lần quét tìm thấy

Ở gói Starter trở lên, khi đã kết nối GitHub, Redthread có thể soạn sẵn bản sửa cho bạn dưới dạng pull request — bạn rà soát và merge; không có gì tự thay đổi. Hai thao tác một cú nhấp nằm ở hàng trên cùng của một lần quét đã hoàn tất.

Trước khi bắt đầu

• Bạn đang dùng gói Starter trở lên.
• Bạn đã kết nối GitHub (thẻ Tích hợp), và lần quét đã dùng một repo GitHub làm nguồn.
• Lần quét đã hoàn tất — lần quét bị dừng sớm có thể được Tiếp tục để chạy đến khi hoàn tất trước đã.

1. Sửa mã của chính bạn — ⚙ Tạo PR sửa lỗi

Dành cho phát hiện ứng dụng — lỗi trong mã của bạn , chẳng hạn kiểm soát truy cập bị phá vỡ hoặc injection:

1. Mở lần quét đã hoàn tất và nhấp ⚙ Tạo PR sửa lỗi ở hàng trên cùng.
2. Công cụ xác định đoạn mã gây ra từng phát hiện, viết một bản sửa tối thiểu, và mở một pull request nháp trên repo của bạn.
3. Nhấp ↗ Xem PR sửa lỗi để rà soát trên GitHub.
4. Bản sửa chưa ổn? Nhấp ↻ Tạo lại và cho biết cần thay đổi hoặc giữ nguyên điều gì (ví dụ "giữ nguyên bước kiểm tra phiên hiện có"). Công cụ thử lại theo hướng dẫn của bạn và cập nhật chính PR đó — không tạo bản trùng lặp.

2. Sửa thư viện có lỗ hổng — ⬆ Cập nhật thư viện phụ thuộc

Dành cho phát hiện về thư viện phụ thuộc — các CVE đã biết trong thư viện bên thứ ba mà ứng dụng của bạn sử dụng:

1. Nhấp ⬆ Cập nhật thư viện phụ thuộc ở hàng trên cùng.
2. Công cụ nâng từng gói có lỗ hổng lên phiên bản đã vá trong các manifest có thể chỉnh sửa của bạn (requirements.txt, package.json) và mở một PR nháp.
3. Các lỗ hổng bị ghim phiên bản trong lockfile (package-lock.json, poetry.lock, uv.lock) không thể chỉnh tay một cách an toàn — PR liệt kê từng lỗ hổng kèm lệnh chính xác cần chạy (ví dụ npm install [email protected]).
4. Rà soát thay đổi, chạy các lệnh lockfile được liệt kê, rồi merge.

Hướng dẫn: quét trên mọi pull request

Từ gói Starter trở lên, một lần quét theo phạm vi sẽ chạy trên mỗi pull request có động đến bề mặt AI của bạn và chặn merge nếu có lỗ hổng mới đã được chứng minh. Các phát hiện lặp lại được loại trùng, nên pipeline luôn yên lặng cho đến khi có vấn đề thật. Từ gói Starter trở lên, một phát hiện đã xác nhận cũng có thể mở một pull request sửa lỗi dạng nháp (và một PR cập nhật thư viện phụ thuộc) để kỹ sư của bạn rà soát — không có gì tự merge. Trạng thái rà soát có tại GET /api/pr-reviews.

Hướng dẫn: quét bằng GitHub Action

Tích hợp việc quét vào bất kỳ pipeline nào bằng GitHub Actionđã phát hành của chúng tôi. Nó quét mỗi lần push và chặn build — hoặc chỉ gửi thông báo.

Cài đặt từ GitHub Marketplace →

1. Lấy khóa kích hoạt. Trong chế độ xem Liên tục , mở tài sản của bạn và nhấp CI để hiển thị khóa kích hoạt riêng của tài sản đó cùng asset id. Khóa chỉ có phạm vi trên đúng một tài sản đó — nó có thể khởi chạy và đọc các lần quét của tài sản đó, không bao giờ truy cập toàn bộ tài khoản của bạn.
2. Lưu nó dưới dạng secret của repo với tên REDTHREAD_SCAN_KEY.
3. Thêm workflow tại .github/workflows/security.yml:

name: security
on: [push]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: bl014h/redthread-scan-action@v1
        with:
          api-key: ${{ secrets.REDTHREAD_SCAN_KEY }}
          asset-id: "abcd1234"
          fail-on: high   # critical | high | medium | low | never

fail-on: never là chế độ chỉ gửi thông báo — nó chạy lần quét và đăng bản tóm tắt job, nhưng không bao giờ làm build thất bại. Bạn có thể xoay vòng khóa bất cứ lúc nào từ cùng bảng điều khiển đó; khóa cũ ngừng hoạt động ngay lập tức.

Hướng dẫn: dùng Redthread trong ChatGPT & Claude

Redthread chạy một máy chủ MCP, nên bạn có thể hỏi trợ lý AI về tình trạng bảo mật bằng ngôn ngữ thường: điều gì đã thay đổi từ lần quét trước, đường tấn công nào đã được chứng minh, dịch vụ AI nào chưa ai xem xét. Nó hoạt động trong ChatGPT, Claude và mọi ứng dụng hỗ trợ máy chủ MCP từ xa với OAuth.

1. Thêm máy chủ. Địa chỉ là https://app.redthreadsec.com/mcp. Trong Claude, mở Settings → Connectors → Add custom connector. Trong ChatGPT, mở Settings → Apps & Connectors và tạo một connector (cần bật developer mode).
2. Đăng nhập và cho phép. Trợ lý sẽ mở một trang Redthread. Đăng nhập, kiểm tra không gian làm việc và nhấn Cho phép.
3. Đặt câu hỏi. Ví dụ: “Những đường tấn công nghiêm trọng nhất của tôi là gì?” hoặc “Cho xem các phát hiện từ lần quét gần nhất của checkout API.”

Trợ lý có thể đọc tổng quan bảo mật, đường tấn công, phát hiện từ các lần quét và danh mục AI ngầm, kiểm tra máy chủ MCP theo các lần quét registry có chữ ký của Redthread, và bắt đầu quét lại (chỉ đọc) các đám mây bạn đã kết nối. Nó không thể kết nối đám mây mới, thay đổi cài đặt, xem khóa hay xóa bất cứ thứ gì.

Hướng dẫn: đặt câu hỏi về một lần quét

Chưa rõ một phát hiện có nghĩa là gì, hay cách sửa nó trong stack của bạn? Hãy hỏi. POST /api/chat nhận vào một danh sách tin nhắn và, tùy chọn, một run_id để câu trả lời bám sát các phát hiện của đúng lần quét đó. Dùng nó để biến một báo cáo thành kế hoạch khắc phục.

Gói, hạn mức & vượt hạn mức

Các gói được báo giá phù hợp với hệ thống và mức sử dụng của bạn — yêu cầu báo giá trên trang bảng giá. Hạn mức và giới hạn của gói hiển thị trong ứng dụng tại mục Thanh toán.

• Thế nào là một lần quét? Một lần chạy trên một mục tiêu. Một lần kiểm tra pull request và một lần quét toàn bộ đều được tính là một lần.
• Lượt quét pentest. Mỗi gói trả phí bao gồm một lượt quét pentest mỗi tháng cho mỗi 10 workload (làm tròn lên; Starter 3, Growth 15). Hạ tầng lớn hơn được thêm lượt quét. Vượt quá mức đó, mỗi lượt quét dùng một gói quét trả trước (5 hoặc 20 lượt, hiệu lực 12 tháng) hoặc, nếu đã lưu thẻ, được tính phí theo từng lượt.
• Gói miễn phí. Một lượt quét pentest trọn đời (không đặt lại) để bạn thấy một phát hiện thực tế trước khi quyết định. Mã khai thác hoạt động và tự động sửa lỗi được mở khóa trên mọi gói trả phí.

Khách hàng hiện tại có thể đổi gói ngay trong ứng dụng, hoặc qua POST /api/billing/checkout. Với gói mới, hãy liên hệ chúng tôi.

Các giai đoạn phát triển

Khách hàng có thể đọc phần này trong ứng dụng: đăng nhập rồi mở bất kỳ liên kết tài liệu nào.

Tài liệu tham chiếu API

Khách hàng có thể đọc phần này trong ứng dụng: đăng nhập rồi mở bất kỳ liên kết tài liệu nào.