Chuyển tới nội dung chính

{/* Trang này được tạo tự động từ SKILL.md của kỹ năng bởi website/scripts/generate-skill-docs.py. Chỉnh sửa nguồn SKILL.md, không phải trang này. */}

Pháp y Oss

Điều tra chuỗi cung ứng, phục hồi bằng chứng và phân tích điều tra cho kho GitHub. Bao gồm việc khôi phục cam kết đã xóa, phát hiện lực đẩy, trích xuất IOC, bằng chứng đa nguồn thu thập, hình thành/xác nhận giả thuyết và báo cáo pháp y có cấu trúc. Lấy cảm hứng từ hệ thống Pháp y OSS hơn 1800 dòng của RAPTOR.

Siêu dữ liệu kỹ năng

NguồnTùy chọn — cài đặt với
`Hermes skills install official/security/oss-forensics
`
Đường dẫn

optional-skills/security/oss-forensics ` | | Nền tảng | Linux, macOS, Windows |

Tham khảo: đầy đủ SKILL.md

thông tin

Sau đây là định nghĩa kỹ năng đầy đủ mà Hermes tải khi kỹ năng này được kích hoạt. Đây là những gì tác nhân coi là hướng dẫn khi kỹ năng được kích hoạt.

Kỹ năng điều tra an ninh OSS

Khung điều tra đa tác nhân gồm 7 giai đoạn để nghiên cứu các cuộc tấn công chuỗi cung ứng nguồn mở. Chuyển thể từ hệ thống pháp y của RAPTOR. Bao gồm Lưu trữ GitHub, Máy Wayback, API GitHub, phân tích git cục bộ, trích xuất IOC, hình thành và xác nhận giả thuyết được chứng minh bằng bằng chứng, và tạo báo cáo pháp y cuối cùng.


⚠️ Lan can chống ảo giác

Đọc những điều này trước mỗi bước điều tra. Vi phạm chúng sẽ làm báo cáo vô hiệu.

  1. Quy tắc ưu tiên bằng chứng: Mọi tuyên bố trong mọi báo cáo, giả thuyết hoặc tóm tắt PHẢI trích dẫn ít nhất một ID bằng chứng ( `EV-XXXX

). Khẳng định mà không có trích dẫn đều bị cấm. 2. Ở TRONG NGÀNH CỦA BẠN: Mỗi đặc vụ phụ (điều tra viên) có một nguồn dữ liệu duy nhất. KHÔNG trộn các nguồn. Người điều tra GH Archive không truy vấn API GitHub và ngược lại. Ranh giới vai trò là khó khăn. 3. Tách sự thật và giả thuyết: Đánh dấu tất cả các suy luận chưa được xác minh bằng

[HYPOTHESIS]

. Chỉ những tuyên bố được xác minh dựa trên các nguồn gốc mới có thể được coi là sự thật. 4. Không bịa đặt bằng chứng: Người xác thực giả thuyết PHẢI kiểm tra một cách máy móc xem mọi ID bằng chứng được trích dẫn có thực sự tồn tại trong kho bằng chứng hay không trước khi chấp nhận một giả thuyết. 5. Bác bỏ cần có bằng chứng: Không thể bác bỏ một giả thuyết nếu không có lập luận phản bác cụ thể, được hỗ trợ bằng bằng chứng. "Không tìm thấy bằng chứng" là không đủ để bác bỏ - nó chỉ khiến một giả thuyết trở nên không thuyết phục. 6. Xác minh kép SHA/URL: Mọi cam kết SHA, URL hoặc mã định danh bên ngoài được trích dẫn làm bằng chứng đều phải được xác nhận độc lập từ ít nhất hai nguồn trước khi được đánh dấu là đã xác minh. 7. Quy tắc mã đáng ngờ: Không bao giờ chạy cục bộ mã được tìm thấy bên trong kho lưu trữ đã được điều tra. Chỉ phân tích tĩnh hoặc sử dụng execute_code trong môi trường hộp cát. 8. Xử lý bí mật: Mọi khóa API, mã thông báo hoặc thông tin xác thực được phát hiện trong quá trình điều tra đều phải được xử lý lại trong báo cáo cuối cùng. Chỉ đăng nhập chúng trong nội bộ.


Kịch bản ví dụ

  • Kịch bản A: Nhầm lẫn phụ thuộc: Gói độc hại internal-lib-v2 được tải lên npm với phiên bản cao hơn phiên bản nội bộ. Điều tra viên phải theo dõi thời điểm gói này được nhìn thấy lần đầu tiên và liệu có bất kỳ PushEvent nào trong kho lưu trữ mục tiêu đã cập nhật package.JSON lên phiên bản này hay không.
  • Kịch bản B: Tiếp quản người bảo trì: Tài khoản của người đóng góp lâu dài được sử dụng để đẩy

.GitHub/workflows/build.yml ` có cửa sau. Điều tra viên tìm kiếm PushEvent từ người dùng này sau một thời gian dài không hoạt động hoặc từ một IP/vị trí mới (nếu có thể phát hiện được qua BigQuery).

  • Trường hợp C: Buộc ẩn: Nhà phát triển vô tình đưa ra bí mật sản xuất, sau đó buộc phải "sửa" bí mật đó. Điều tra viên sử dụng git fsck và GH Archive để khôi phục SHA cam kết ban đầu và xác minh những gì đã bị rò rỉ.

Quy ước đường dẫn: Xuyên suốt kỹ năng này, SKILL_DIR đề cập đến gốc rễ của kỹ năng này thư mục cài đặt (thư mục chứa SKILL.md này). Khi kỹ năng được tải, phân giải SKILL_DIR thành đường dẫn thực tế — ví dụ:

~/.Hermes/skills/security/oss-forensics/

hoặc tương đương `optional-skills/

. Tất cả các tài liệu tham khảo tập lệnh và mẫu đều liên quan đến nó.

Giai đoạn 0: Khởi tạo

  1. Tạo thư mục làm việc điều tra:
   mkdir investigation_$(echo "REPO_NAME" | tr '/' '_')
cd investigation_$(echo "REPO_NAME" | tr '/' '_')

`

2. Khởi tạo kho chứng cứ:

``` bash
Python3 SKILL_DIR/scripts/evidence-store.py --store evidence.JSON list

`

3. Sao chép mẫu báo cáo pháp y:

``` bash
cp SKILL_DIR/templates/forensic-report.md ./investigation-report.md

`

4. Tạo tệp
`iocs.md
` để theo dõi các Chỉ số Thỏa hiệp khi chúng được phát hiện.
5. Ghi lại thời gian bắt đầu điều tra, kho lưu trữ mục tiêu và mục tiêu điều tra đã nêu.

---

## Giai đoạn 1: Phân tích cú pháp nhanh chóng và trích xuất IOC**Mục tiêu**: Trích xuất tất cả các mục tiêu điều tra có cấu trúc từ yêu cầu của người dùng.

**Hành động**:
- Phân tích lời nhắc người dùng và trích xuất:
- Kho lưu trữ đích (
`owner/repo

)
- Tác nhân mục tiêu (tay cầm GitHub, địa chỉ email)
- Khoảng thời gian quan tâm (phạm vi ngày cam kết, dấu thời gian PR)
- Cung cấp các chỉ số thỏa hiệp: SHA cam kết, đường dẫn tệp, tên gói, địa chỉ IP, tên miền, khóa/mã thông báo API, URL độc hại
- Mọi báo cáo bảo mật của nhà cung cấp được liên kết hoặc bài đăng trên blog`**Công cụ**: Chỉ suy luận hoặc
`execute_code
` để trích xuất biểu thức chính quy từ các khối văn bản lớn.

**Đầu ra**: Điền
`iocs.md
` với các IOC được trích xuất. Mỗi IOC phải có:
- Loại (từ: COMMIT_SHA, FILE_PATH, API_KEY, SECRET, IP_ADDRESS, DOMAIN, PACKAGE_NAME, ACTOR_USERNAME, MALICIOUS_URL, OTHER)
- Giá trị
- Nguồn (do người dùng cung cấp, suy ra)

**Tham khảo**: Xem [evidence-types.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/references/evidence-types.md) để biết phân loại IOC.

---

## Giai đoạn 2: Thu thập chứng cứ song song

Tạo ra tối đa 5 đặc vụ phụ điều tra viên chuyên nghiệp bằng cách sử dụng
`delegate_task
` (chế độ hàng loạt, tối đa 3 đồng thời). Mỗi điều tra viên có một **nguồn dữ liệu duy nhất** và không được trộn lẫn các nguồn.`> **Ghi chú của người điều phối**: Vượt qua danh sách IOC từ Giai đoạn 1 và khoảng thời gian điều tra trong trường
`context
` của từng nhiệm vụ được ủy quyền.

---

### Điều tra viên 1: Điều tra viên Git địa phương`**RIÊNG GIỚI VAI TRÒ**: Bạn CHỈ truy vấn KHO LƯU TRỮ GIT ĐỊA PHƯƠNG. Không gọi bất kỳ API bên ngoài nào.

**Hành động**:

`
``` bash

# Clone repository
git clone https://GitHub.com/OWNER/REPO.git target_repo && cd target_repo

# Full commit log with stats
git log --all --full-history --stat --format="%H|%ae|%an|%ai|%s" > ../git_log.txt

# Detect force-push evidence (orphaned/dangling commits)
git fsck --lost-found --unreachable 2>&1 | grep commit > ../dangling_commits.txt

# Check reflog for rewritten history
git reflog --all > ../reflog.txt

# List ALL branches including deleted remote refs
git branch -a -v > ../branches.txt

# Find suspicious large binary additions
git log --all --diff-filter=A --name-only --format="%H %ai" -- "*.so" "*.dll" "*.exe" "*.bin" > ../binary_additions.txt

# Check for GPG signature anomalies
git log --show-signature --format="%H %ai %aN" > ../signature_check.txt 2>&1

`
``**Bằng chứng cần thu thập** (thêm qua
`Python3 SKILL_DIR/scripts/evidence-store.py add

):
- Mỗi commit dangling SHA → gõ:
`git

- Bằng chứng ép buộc (reflog hiển thị lịch sử viết lại) → loại:
`git

- Cam kết chưa được ký từ những người đóng góp đã được xác minh → loại:
`git

- Bổ sung tệp nhị phân đáng ngờ → loại:
`git
``**Tham khảo**: Xem [recovery-techniques.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/references/recovery-techniques.md) để biết cách truy cập các cam kết được ép buộc.

---

### Điều tra viên 2: Điều tra viên API GitHub`**RIÊNG GIỚI VAI TRÒ**: Bạn CHỈ truy vấn API GitHub REST. Không chạy lệnh git cục bộ.

**Hành động**:

`
``` bash

# Commits (paginated)
curl -s "https://API.GitHub.com/repos/OWNER/REPO/commits?per_page=100" > API_commits.JSON

# Pull Requests including closed/deleted
curl -s "https://API.GitHub.com/repos/OWNER/REPO/pulls?state=all&per_page=100" > API_prs.JSON

# Issues
curl -s "https://API.GitHub.com/repos/OWNER/REPO/issues?state=all&per_page=100" > API_issues.JSON

# Contributors and collaborator changes
curl -s "https://API.GitHub.com/repos/OWNER/REPO/contributors" > API_contributors.JSON

# Repository events (last 300)
curl -s "https://API.GitHub.com/repos/OWNER/REPO/events?per_page=100" > API_events.JSON

# Check specific suspicious commit SHA details
curl -s "https://API.GitHub.com/repos/OWNER/REPO/git/commits/SHA" > commit_detail.JSON

# Releases
curl -s "https://API.GitHub.com/repos/OWNER/REPO/releases?per_page=100" > API_releases.JSON

# Check if a specific commit exists (force-pushed commits may 404 on commits/ but succeed on git/commits/)
curl -s "https://API.GitHub.com/repos/OWNER/REPO/commits/SHA" | jq .sha

`
``**Mục tiêu tham khảo chéo** (gắn cờ sự khác biệt làm bằng chứng):
- PR tồn tại trong kho lưu trữ nhưng bị thiếu trong API → bằng chứng xóa
- Người đóng góp trong các sự kiện lưu trữ nhưng không có trong danh sách người đóng góp → bằng chứng về việc thu hồi quyền
- Cam kết trong kho lưu trữ PushEvents nhưng không có trong danh sách cam kết API → bằng chứng về việc buộc đẩy/xóa`**Tham khảo**: Xem [evidence-types.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/references/evidence-types.md) để biết các loại sự kiện GH.

---

### Điều tra viên 3: Điều tra viên Wayback Machine`**ROLE BOUNDARY**: Bạn CHỈ truy vấn API CDX WAYBACK MACHINE. Không sử dụng API GitHub.

**Mục tiêu**: Khôi phục các trang GitHub đã xóa (README, sự cố, PR, bản phát hành, trang wiki).

**Hành động**:

`
``` bash

# Search for archived snapshots of the repo main page
curl -s "https://web.archive.org/cdx/search/cdx?url=GitHub.com/OWNER/REPO&output=JSON&limit=100&from=YYYYMMDD&to=YYYYMMDD" > wayback_main.JSON

# Search for a specific deleted issue
curl -s "https://web.archive.org/cdx/search/cdx?url=GitHub.com/OWNER/REPO/issues/NUM&output=JSON&limit=50" > wayback_issue_NUM.JSON

# Search for a specific deleted PR
curl -s "https://web.archive.org/cdx/search/cdx?url=GitHub.com/OWNER/REPO/pull/NUM&output=JSON&limit=50" > wayback_pr_NUM.JSON

# Fetch the best snapshot of a page
# Use the Wayback Machine URL: https://web.archive.org/web/TIMESTAMP/ORIGINAL_URL
# Example: https://web.archive.org/web/20240101000000*/GitHub.com/OWNER/REPO

# Advanced: Search for deleted releases/tags
curl -s "https://web.archive.org/cdx/search/cdx?url=GitHub.com/OWNER/REPO/releases/tag/*&output=JSON" > wayback_tags.JSON

# Advanced: Search for historical wiki changes
curl -s "https://web.archive.org/cdx/search/cdx?url=GitHub.com/OWNER/REPO/wiki/*&output=JSON" > wayback_wiki.JSON

`
``**Bằng chứng cần thu thập**:
- Ảnh chụp nhanh được lưu trữ về các vấn đề/PR đã xóa cùng với nội dung của chúng
- Phiên bản README lịch sử hiển thị các thay đổi
- Bằng chứng về nội dung có trong kho lưu trữ nhưng bị thiếu ở trạng thái GitHub hiện tại`**Tham khảo**: Xem [GitHub-archive-guide.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/references/GitHub-archive-guide.md) để biết thông số API CDX.

---

### Điều tra viên 4: Lưu trữ GH / Điều tra viên BigQuery`**RIÊNG GIỚI VAI TRÒ**: Bạn CHỈ truy vấn GitHub ARCHIVE qua BIGQUERY. Đây là bản ghi chống giả mạo về tất cả các sự kiện công khai trên GitHub.`> **Điều kiện tiên quyết**: Yêu cầu thông tin xác thực Google Cloud có quyền truy cập BigQuery (
`gcloud auth application-default login

). Nếu không có, hãy bỏ qua phần điều tra này và ghi chú vào báo cáo.

**Quy tắc tối ưu hóa chi phí** (BẮT BUỘC):
1. LUÔN chạy

--dry_run
` trước mỗi truy vấn để ước tính chi phí.
2. Sử dụng
`_TABLE_SUFFIX
` để lọc theo phạm vi ngày và giảm thiểu dữ liệu được quét.
3. Chỉ CHỌN các cột bạn cần.
4. Thêm GIỚI HẠN trừ khi tổng hợp.

``` bash

# Template: safe BigQuery query for PushEvents to OWNER/REPO
bq query --use_legacy_sql=false --dry_run "
SELECT created_at, actor.login, payload.commits, payload.before, payload.head,
payload.size, payload.distinct_size
FROM \
`GitHubarchive.month.*\

WHERE _TABLE_SUFFIX BETWEEN 'YYYYMM' AND 'YYYYMM'
AND type = 'PushEvent'
AND repo.name = 'OWNER/REPO'
LIMIT 1000
"
# If cost is acceptable, re-run without --dry_run

# Detect force-pushes: zero-distinct_size PushEvents mean commits were force-erased
# payload.distinct_size = 0 AND payload.size > 0 → force push indicator

# Check for deleted branch events
bq query --use_legacy_sql=false "
SELECT created_at, actor.login, payload.ref, payload.ref_type
FROM \
`GitHubarchive.month.*\

WHERE _TABLE_SUFFIX BETWEEN 'YYYYMM' AND 'YYYYMM'
AND type = 'DeleteEvent'
AND repo.name = 'OWNER/REPO'
LIMIT 200
"

`
``**Bằng chứng cần thu thập**:
- Sự kiện Force-push (payload.size > 0, payload.distinct_size = 0)
- Xóa sự kiện cho các nhánh/thẻ
- WorkflowRunEvents để tự động hóa CI/CD đáng ngờ
- Sự kiện đẩy đứng trước "khoảng trống" trong nhật ký git (bằng chứng về việc viết lại)

**Tham khảo**: Xem [GitHub-archive-guide.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/references/GitHub-archive-guide.md) để biết tất cả 12 loại sự kiện và mẫu truy vấn.

---

### Điều tra viên 5: Điều tra viên làm giàu IOC`**Ranh giới VAI TRÒ**: Bạn CHỈ làm phong phú thêm các IOC hiện có từ Giai đoạn 1 bằng cách sử dụng các nguồn công cộng thụ động. Không thực thi bất kỳ mã nào từ kho lưu trữ đích.**Hành động**:
- Đối với mỗi cam kết SHA: thử khôi phục qua URL GitHub trực tiếp (
`GitHub.com/OWNER/REPO/commit/SHA.patch

)
- Đối với từng miền/IP: kiểm tra DNS thụ động, bản ghi WHOIS (thông qua
`web_extract
` trên các dịch vụ WHOIS công cộng)
- Đối với từng tên gói: kiểm tra npm/PyPI để tìm báo cáo gói độc hại phù hợp
- Đối với mỗi tên người dùng diễn viên: kiểm tra hồ sơ GitHub, lịch sử đóng góp, tuổi tài khoản
- Khôi phục các cam kết bị ép buộc bằng 3 phương pháp (xem [recovery-techniques.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/references/recovery-techniques.md))

---

## Giai đoạn 3: Củng cố bằng chứng

Sau khi tất cả các điều tra viên hoàn tất:
1. Chạy
`Python3 SKILL_DIR/scripts/evidence-store.py --store evidence.JSON list
` để xem tất cả bằng chứng được thu thập.
2. Đối với mỗi bằng chứng, hãy xác minh hàm băm
`content_sha256
` khớp với nguồn ban đầu.
3. Nhóm bằng chứng theo:
- **Dòng thời gian**: Sắp xếp tất cả bằng chứng được đánh dấu thời gian theo trình tự thời gian
- **Diễn viên**: Nhóm theo địa chỉ GitHub hoặc email
- **IOC**: Liên kết bằng chứng với IOC mà nó liên quan
4. Xác định **sự khác biệt**: các mục có ở nguồn này nhưng không có ở nguồn khác (các chỉ số xóa chính).
5. Gắn cờ bằng chứng là

[VERIFIED]
` (được xác nhận từ hơn 2 nguồn độc lập) hoặc

[UNVERIFIED]
` (chỉ một nguồn duy nhất).

---

## Giai đoạn 4: Hình thành giả thuyết

Một giả thuyết phải:
- Nêu rõ một yêu cầu cụ thể (ví dụ: "Diễn viên X bị buộc phải chuyển đến CHI NHÁNH vào NGÀY để xóa cam kết SHA")
- Trích dẫn ít nhất 2 ID bằng chứng hỗ trợ nó (
`EV-XXXX

,
`EV-YYYY

)
- Xác định những bằng chứng nào có thể bác bỏ nó
- Được dán nhãn

[HYPOTHESIS]
` cho đến khi được xác nhận`**Mẫu giả thuyết chung** (xem [investigation-templates.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/references/investigation-templates.md)):
- Thỏa hiệp của người bảo trì: tài khoản hợp pháp được sử dụng sau khi tiếp quản để tiêm mã độc
- Nhầm lẫn phụ thuộc: ngồi xổm tên gói để chặn cài đặt
- Tiêm CI/CD: quy trình làm việc độc hại thay đổi để chạy mã trong quá trình xây dựng
- Đánh máy: nhắm mục tiêu sai chính tả tên gói gần giống nhau
- Rò rỉ thông tin xác thực: mã thông báo/khóa vô tình được xác nhận sau đó bị buộc phải xóa

Đối với mỗi giả thuyết, hãy sinh ra một tác nhân phụ
`delegate_task
` để cố gắng tìm bằng chứng bác bỏ trước khi xác nhận.

---

## Giai đoạn 5: Xác thực giả thuyết

Tác nhân phụ của trình xác thực PHẢI kiểm tra một cách máy móc:
1. Đối với mỗi giả thuyết, trích xuất tất cả ID bằng chứng được trích dẫn.
2. Xác minh từng ID tồn tại trong
`evidence.JSON
` (lỗi cứng nếu thiếu bất kỳ ID nào → giả thuyết bị từ chối vì có khả năng bịa đặt).
3. Xác minh từng bằng chứng

[VERIFIED]
` đã được xác nhận từ hơn 2 nguồn.
4. Kiểm tra tính nhất quán về mặt logic: dòng thời gian được mô tả bằng bằng chứng có ủng hộ giả thuyết không?
5. Kiểm tra các cách giải thích khác: liệu mẫu bằng chứng tương tự có thể phát sinh từ một nguyên nhân lành tính không?

**Đầu ra**:
-
`VALIDATED

: Tất cả các bằng chứng được trích dẫn, xác minh, nhất quán về mặt logic, không có lời giải thích hợp lý nào khác.
-
`INCONCLUSIVE

: Bằng chứng ủng hộ giả thuyết nhưng vẫn tồn tại những giải thích khác hoặc bằng chứng không đầy đủ.
-
`REJECTED

: Thiếu ID bằng chứng, bằng chứng chưa được xác minh được trích dẫn là sự thật, phát hiện sự không nhất quán về mặt logic.

Các giả thuyết bị loại bỏ sẽ phản hồi lại Giai đoạn 4 để sàng lọc (tối đa 3 lần lặp).

---

## Giai đoạn 6: Tạo báo cáo cuối cùng

Điền
`investigation-report.md
` bằng cách sử dụng mẫu trong [forensic-report.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/templates/forensic-report.md).

**Phần bắt buộc**:
- Tóm tắt điều hành: phán quyết một đoạn văn (Thỏa hiệp / Sạch sẽ / Không thể kết luận) với mức độ tin cậy
- Dòng thời gian: xây dựng lại theo trình tự thời gian của tất cả các sự kiện quan trọng với trích dẫn bằng chứng
- Các giả thuyết đã được xác thực: mỗi giả thuyết đều có trạng thái và ID bằng chứng hỗ trợ
- Cơ quan đăng ký bằng chứng: bảng gồm tất cả các mục
`EV-XXXX
` có nguồn, loại và trạng thái xác minh
- Danh sách IOC: tất cả các Chỉ số Thỏa hiệp được trích xuất và làm phong phú
- Chuỗi hành trình sản phẩm: bằng chứng được thu thập như thế nào, từ nguồn nào, vào thời điểm nào
- Khuyến nghị: giảm nhẹ ngay lập tức nếu phát hiện có sự xâm phạm; khuyến nghị giám sát`**Quy tắc báo cáo**:
- Mọi khẳng định thực tế phải có ít nhất một trích dẫn

[EV-XXXX]

- Tóm tắt điều hành phải nêu rõ mức độ tin cậy (Cao/Trung bình/Thấp)
- Tất cả bí mật/thông tin xác thực phải được biên tập lại thành

[REDACTED]

---

## Giai đoạn 7: Hoàn thiện
1. Chạy số bằng chứng cuối cùng:
`Python3 SKILL_DIR/scripts/evidence-store.py --store evidence.JSON list

2. Lưu trữ toàn bộ danh mục điều tra.
3. Nếu thỏa hiệp được xác nhận:
- Liệt kê các biện pháp giảm thiểu ngay lập tức (xoay thông tin đăng nhập, băm phụ thuộc pin, thông báo cho người dùng bị ảnh hưởng)
- Xác định các phiên bản/gói bị ảnh hưởng
- Ghi chú nghĩa vụ công bố thông tin (nếu là gói công cộng: phối hợp với cơ quan đăng ký gói)
4. Trình bày
`investigation-report.md
` cuối cùng cho người dùng.

---

## Nguyên tắc sử dụng có đạo đứcKỹ năng này được thiết kế để **điều tra bảo mật phòng thủ** — bảo vệ phần mềm nguồn mở khỏi các cuộc tấn công chuỗi cung ứng. Nó không được sử dụng cho:
- **Quấy rối hoặc theo dõi** người đóng góp hoặc người duy trì
- **Doxing** — liên kết hoạt động GitHub với danh tính thực nhằm mục đích xấu
- **Thông tin cạnh tranh** — điều tra các kho lưu trữ độc quyền hoặc nội bộ mà không được phép
- **Cáo buộc sai** — công bố kết quả điều tra mà không có bằng chứng xác thực (xem các biện pháp bảo vệ chống ảo giác)

Các cuộc điều tra phải được tiến hành với nguyên tắc **xâm phạm tối thiểu**: chỉ thu thập bằng chứng cần thiết để xác nhận hoặc bác bỏ giả thuyết. Khi công bố kết quả, hãy tuân thủ các biện pháp tiết lộ có trách nhiệm và phối hợp với những người bảo trì bị ảnh hưởng trước khi tiết lộ công khai.

Nếu cuộc điều tra cho thấy có sự xâm phạm thực sự, hãy làm theo quy trình phối hợp tiết lộ lỗ hổng:
1. Trước tiên hãy thông báo riêng cho người bảo trì kho lưu trữ
2. Dành thời gian hợp lý để khắc phục (thường là 90 ngày)
3. Phối hợp với các cơ quan đăng ký gói (npm, PyPI, v.v.) nếu các gói đã xuất bản bị ảnh hưởng
4. Nộp CVE nếu thích hợp

---

## Giới hạn tỷ lệ API

API GitHub REST thực thi các giới hạn tốc độ sẽ làm gián đoạn các cuộc điều tra lớn nếu không được quản lý.

**Yêu cầu được xác thực**: 5.000/giờ (yêu cầu
`GitHub_TOKEN
` env var hoặc
`gh
` CLI auth)
**Yêu cầu không được xác thực**: 60/giờ (không thể sử dụng để điều tra)

**Các phương pháp hay nhất**:
- Luôn xác thực:
`export GitHub_TOKEN=ghp_...
` hoặc sử dụng
`gh
` CLI (tự động xác thực)
- Sử dụng các yêu cầu có điều kiện (tiêu đề
`If-None-Match
` /
`If-Modified-Since

) để tránh sử dụng hạn ngạch đối với dữ liệu không thay đổi
- Đối với các điểm cuối được phân trang, hãy tìm nạp tất cả các trang theo trình tự — không song song với cùng một điểm cuối
- Kiểm tra tiêu đề
`X-RateLimit-Remaining

; nếu dưới 100, hãy tạm dừng cho dấu thời gian
`X-RateLimit-Reset

- BigQuery có hạn ngạch riêng (bậc miễn phí 10 TiB/ngày) — luôn chạy thử trước
- API CDX của Wayback Machine: không có giới hạn tốc độ chính thức, nhưng phải lịch sự (tối đa 1-2 req/giây)

Nếu tỷ lệ bị giới hạn ở giữa cuộc điều tra, hãy ghi lại một phần kết quả vào kho bằng chứng và ghi lại giới hạn đó vào báo cáo.

---

## Tài liệu tham khảo
- [GitHub-archive-guide.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/references/GitHub-archive-guide.md) — Truy vấn BigQuery, API CDX, 12 loại sự kiện
- [evidence-types.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/references/evidence-types.md) — Phân loại IOC, loại nguồn bằng chứng, loại quan sát
- [recovery-techniques.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/references/recovery-techniques.md) — Khôi phục các cam kết, PR, sự cố đã xóa
- [investigation-templates.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/references/investigation-templates.md) - Mẫu giả thuyết dựng sẵn cho mỗi loại tấn công
- [evidence-store.py](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/scripts/evidence-store.py) - Công cụ CLI để quản lý kho lưu trữ JSON bằng chứng
- [forensic-report.md](https://GitHub.com/NousResearch/Hermes-agent/blob/main/optional-skills/security/oss-forensics/templates/forensic-report.md) — Mẫu báo cáo có cấu trúc