Gitleaks: quét bí mật trong git và tình huống cho công ty bảo trì thang máy
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Gitleaks đã hoàn thiện tính năng: dùng được việc gì và nên dừng ở đâu
Gitleaks là một công cụ dòng lệnh viết bằng Go, dùng để phát hiện mật khẩu, khóa API và token nằm trong kho git, trong tệp hoặc trong dữ liệu đưa vào qua stdin (luồng nhập chuẩn của tiến trình). README mô tả nó là công cụ phát hiện chứ không phải công cụ xử lý sự cố: nó chỉ chỉ ra chỗ nghi ngờ, còn việc thu hồi khóa và dọn lịch sử vẫn là việc của con người. [1]
Có một thông tin phải nói ngay từ đầu. Ở đầu README, tác giả ghi rằng gitleaks đã hoàn thiện tính năng, sẽ không nhận thêm tính năng mới, các bản phát hành sau chỉ là bản vá bảo mật, và công sức của ông chuyển sang một dự án khác tên Betterleaks. Chính sách bảo mật cũng chỉ hỗ trợ bản mới nhất. [1][3] Vì thế gitleaks phù hợp với đội muốn một công cụ nhỏ, ổn định, dễ gắn vào pre-commit hoặc CI. Nó không phù hợp với đội chờ đợi các tính năng mới như xác minh khóa còn sống hay tích hợp nhiều nền tảng.
Khuyến nghị của bài là thử gitleaks ở quy mô nhỏ trên một vài kho mã có rủi ro lộ khóa rõ ràng, đo tỷ lệ cảnh báo giả, rồi quyết định giữ hay chuyển sang công cụ khác dựa trên kết quả đó.
Khóa API nằm lại trong lịch sử commit: bài toán gitleaks nhắm tới
Lập trình viên thường dán thử một khóa vào tệp cấu hình để chạy cho nhanh, commit, rồi xóa ở commit sau. Tệp hiện tại sạch, nhưng git vẫn giữ nguyên bản cũ trong lịch sử. Bất kỳ ai có quyền đọc kho đều xem lại được. README của gitleaks mô tả đúng phạm vi này: công cụ quét mã quá khứ lẫn hiện tại để tìm bí mật. [1]
Bài toán thứ hai là quy mô. Một kho có hàng nghìn commit không thể được rà bằng mắt, và rà thủ công lại không lặp lại được mỗi tuần. Cần một cơ chế máy móc, có quy tắc rõ, cho ra danh sách cụ thể gồm tệp, dòng, commit và tác giả để người phụ trách xử lý. Mẫu kết quả trong README gồm đúng các trường đó: mã quy tắc, entropy, tệp, dòng, commit, tác giả, ngày và một dấu vân tay (fingerprint) định danh duy nhất mỗi phát hiện. [1]
Bài toán thứ ba, thường bị bỏ qua, là quản lý ngoại lệ. Kho nào cũng có khóa thử nghiệm cố ý để lại hoặc chuỗi trông giống bí mật nhưng không phải. Gitleaks giải quyết điểm này bằng allowlist trong cấu hình, chú thích nội dòng và tệp bỏ qua, nội dung được trình bày ở các phần sau. [1]
Một tệp thực thi, ba chế độ quét và một tệp cấu hình TOML
Về hình thức, gitleaks là một chương trình dòng lệnh duy nhất với ba chế độ quét: git cho kho git, dir cho thư mục hoặc tệp, và stdin cho dữ liệu truyền qua đường ống. Hai lệnh cũ là detect và protect đã bị đánh dấu lạc hậu từ phiên bản 8.19.0, vẫn dùng được nhưng bị ẩn khỏi trang trợ giúp. [1]
Phần quy tắc nằm trong tệp cấu hình TOML. Mỗi quy tắc có mã định danh, mô tả, biểu thức chính quy theo cú pháp Go (không hỗ trợ lookahead), nhóm bắt chứa bí mật, ngưỡng entropy tối thiểu, biểu thức đường dẫn, danh sách từ khóa dùng để lọc nhanh trước khi chạy regex, và các thẻ để phân loại. [1] Cấu hình có thể mở rộng cấu hình mặc định hoặc một tệp khác, tắt từng quy tắc được kế thừa, và chuỗi kế thừa tối đa hai tầng. [1]
Thứ tự ưu tiên khi nạp cấu hình cũng được ghi rõ: tham số dòng lệnh, rồi biến môi trường trỏ tới tệp, rồi biến môi trường chứa nội dung TOML, rồi tệp .gitleaks.toml trong thư mục đích, cuối cùng mới là cấu hình mặc định tích hợp. [1]
Từ git log -p đến báo cáo SARIF: đường đi của một lần quét
Với chế độ git, gitleaks gọi lệnh git log -p bên dưới để lấy các bản vá, và người dùng có thể truyền thêm tùy chọn qua log-opts, ví dụ giới hạn trong một khoảng commit. [1]
Theo phần mô tả cấu hình, quy tắc có từ khóa sẽ so khớp chuỗi nhanh trước, nên regex tốn kém chỉ chạy khi từ khóa xuất hiện; ngưỡng entropy được kiểm tra trên nhóm bắt chứa bí mật, còn allowlist loại bỏ những phát hiện khớp điều kiện ngoại lệ. [1] Allowlist có thể khớp theo commit, đường dẫn, từ dừng hoặc regex, và tính năng này cho phép chọn đối tượng đối chiếu là chính bí mật, toàn bộ đoạn khớp hoặc cả dòng. [1]
Đầu ra có thể là JSON, CSV, JUnit, SARIF hoặc một mẫu do người dùng tự viết bằng template của Go, có thể dùng thêm thư viện sprig. [1] Thư mục report_templates còn có sẵn các mẫu để sinh một trang HTML đọc kết quả. [5] Mã thoát mặc định là 0 khi không có rò rỉ, 1 khi có rò rỉ hoặc lỗi, 126 khi sai cờ, và giá trị khi gặp rò rỉ có thể đổi bằng cờ exit-code. [1]
Những gì README ghi nhận: giải mã, kho nén, rule ghép và baseline
Gitleaks có các cờ bật tùy chọn, mặc định đều tắt. Cờ max-decode-depth cho phép giải mã đệ quy các đoạn mã hóa trước khi áp quy tắc; các dạng được liệt kê gồm percent, hex từ 32 ký tự trở lên và base64 từ 16 ký tự trở lên. Phát hiện từ văn bản đã giải mã mang thẻ decoded và decode-depth. [1] Cờ max-archive-depth cho phép mở các kho nén lồng nhau, với đường dẫn bên trong được nối bằng dấu chấm than, dựa trên thư viện archives của mholt. [1]
Baseline là tính năng đáng chú ý cho kho cũ. Người dùng tạo một báo cáo rồi truyền làm baseline; các lần quét sau chỉ báo những phát hiện mới. [1] Đi cùng là chú thích gitleaks:allow trên dòng chứa khóa thử nghiệm và tệp .gitleaksignore dùng fingerprint, trong đó README ghi tính năng .gitleaksignore là thử nghiệm và có thể thay đổi. [1]
Quy tắc ghép (composite) ra mắt từ phiên bản 8.28.0: một quy tắc chính cộng một hoặc nhiều quy tắc phụ bắt buộc, với ràng buộc gần nhau theo số dòng hoặc số cột. README tự mô tả đây là tính năng thử nghiệm. [1] Ngoài ra, README nêu gitleaks chỉ xét phần thêm vào trong lịch sử git, nghĩa là bí mật chỉ bị xóa đi sẽ không được báo ở phía đó. [1]
Ai nên cân nhắc, ai nên chọn công cụ khác
Đối tượng đầu tiên là đội phát triển nhỏ và vừa muốn có hàng rào cơ bản chống đẩy khóa lên kho. Công cụ chạy cục bộ, không cần máy chủ riêng, có thể gắn vào pre-commit, Docker hoặc GitHub Action. Cách cài đặt được README liệt kê gồm Homebrew, Docker, Go, bản nhị phân trên trang phát hành và hook pre-commit. [1]
Đối tượng thứ hai là đội bảo mật cần một bộ quy tắc minh bạch, chỉnh sửa được. Vì quy tắc là tệp TOML và regex Go, đội có thể thêm quy tắc cho định dạng khóa riêng của công ty, ví dụ tiền tố token nội bộ, và đưa chúng vào kiểm soát phiên bản như mã khác. [1][4]
Ngược lại, tổ chức cần xác minh khóa còn hoạt động, quét Slack, Jira hay kho đối tượng, hoặc muốn một lộ trình tính năng đang phát triển, nên xem các công cụ khác. README không mô tả bước xác minh khóa với dịch vụ gốc, và tác giả đã nói rõ không nhận tính năng mới. [1]
Tình huống giả định: đội phần mềm của một công ty bảo trì thang máy
Đây là một đề xuất giả định, không phải trường hợp đã triển khai. Hình dung một công ty bảo trì thang máy tại Đà Nẵng với khoảng hai trăm thang đang quản lý theo hợp đồng. Công ty có một nhóm bốn đến sáu kỹ sư tự viết ứng dụng di động cho kỹ thuật viên hiện trường, một cổng web cho ban quản lý tòa nhà báo sự cố, và vài kho mã nhỏ cho bộ thu thập dữ liệu gắn tại tủ điều khiển.
Rủi ro cụ thể nằm ở các kho này. Bộ thu thập thường cần thông tin kết nối tới máy chủ tin nhắn, khóa của dịch vụ gửi SMS cảnh báo, khóa bản đồ để định vị tòa nhà, và tài khoản cơ sở dữ liệu của hệ thống phân công. Khi gấp rút xử lý một sự cố kẹt người, kỹ sư dễ dán thẳng các giá trị này vào tệp cấu hình để thử trên thiết bị thật, rồi commit. Mã còn có thể được chia sẻ cho nhà thầu phụ viết firmware.
Đề xuất là đặt gitleaks ở hai điểm: pre-commit trên máy mỗi kỹ sư, và một bước CI chặn merge khi có phát hiện mới. Cấu hình mở rộng cấu hình mặc định, thêm quy tắc cho tiền tố token nội bộ và allowlist cho thư mục dữ liệu mẫu của thiết bị mô phỏng. [1] Một lần quét toàn bộ lịch sử ban đầu tạo ra baseline, sau đó chỉ phát hiện mới mới chặn quy trình. Mọi khóa tìm thấy trong lịch sử cần được thu hồi và cấp lại, vì gitleaks không làm việc đó thay con người.
Gắn gitleaks vào pre-commit và CI mà không làm nghẽn lập trình viên
Hook pre-commit là con đường README mô tả chi tiết nhất: cài framework pre-commit, khai báo kho gitleaks và phiên bản trong tệp .pre-commit-config.yaml, rồi chạy lệnh cài hook. Có thể bỏ qua tạm thời bằng biến SKIP. Ví dụ trong README ghim một phiên bản cụ thể, nên cần cập nhật định kỳ bằng lệnh autoupdate của framework. [1]
Với CI, README nêu hai lựa chọn: chạy bản nhị phân hoặc ảnh Docker chính thức, hoặc dùng gitleaks-action, một kho riêng. [1] SECURITY.md lưu ý gitleaks-action có kênh báo lỗ hổng riêng, một dấu hiệu rằng đây là sản phẩm tách biệt về quản lý. [3] Để giữ thời gian chạy hợp lý, nên quét theo khoảng commit của pull request thay vì toàn lịch sử, dùng tùy chọn log-opts. [1]
Nhật ký quét chứa bí mật nên bật redact trong môi trường CI dùng chung, để khóa không tự rò rỉ qua log của chính hệ thống build. [1] Cuối cùng, cần một người sở hữu danh sách ngoại lệ; allowlist không ai rà soát sẽ dần trở thành lỗ hổng.
Bảo mật và quyền riêng tư của một công cụ chạm vào bí mật
Gitleaks đọc nội dung nhạy cảm nên bản thân nó cần được đặt trong môi trường tin cậy. README mô tả công cụ chạy cục bộ trên nguồn được chỉ định; các tài liệu đã đọc không nêu việc gửi dữ liệu quét tới dịch vụ bên ngoài. [1] Dù vậy, đây là điều đội triển khai nên tự kiểm chứng ở giai đoạn pilot bằng cách theo dõi lưu lượng mạng của tiến trình, vì bài này không chạy phần mềm.
Báo cáo đầu ra là điểm yếu dễ bị bỏ quên. Nếu không che bằng redact, báo cáo JSON chứa nguyên giá trị bí mật; tệp đó khi được lưu làm artifact CI hoặc gửi qua chat sẽ tạo thêm một bản sao của khóa. [1] Cần xử lý báo cáo như dữ liệu mật: quyền truy cập hạn chế, thời hạn lưu ngắn.
Về chính sách an ninh của dự án, SECURITY.md chỉ ghi bản mới nhất được hỗ trợ và yêu cầu báo lỗ hổng riêng tư qua tính năng của GitHub, không mở issue công khai. [3] Kết hợp với việc chỉ còn bản vá bảo mật, tổ chức cần có quy trình cập nhật nhanh khi có bản vá, vì không còn nhánh cũ nào được hỗ trợ song song. [1][3] Dữ liệu cá nhân trong kho (email tác giả commit) xuất hiện trong báo cáo, nên cũng thuộc diện bảo vệ dữ liệu của công ty. [1]
MIT nhưng ranh giới nằm ở những thứ MIT không bao phủ
Tệp LICENSE tại commit đã ghim là giấy phép MIT, ghi bản quyền năm 2019 của Zachary Rice. [2] Bài này không phải tư vấn pháp lý, và bộ phận pháp chế nên đọc văn bản gốc.
Cần phân biệt phạm vi. Giấy phép nằm trong kho gitleaks và áp dụng cho mã của kho tại commit này. Nó không tự động áp dụng cho gitleaks-action, vốn là kho khác với trang bảo mật riêng, cho các thư viện Go mà gitleaks phụ thuộc, hay cho Betterleaks, dự án mà tác giả chuyển sang. [1][3] Bộ quy tắc mặc định nằm trong cùng kho, nhưng các tài liệu đã đọc không nêu thư mục nào mang giấy phép khác, và tập này không có tệp giấy phép phạm vi bổ sung.
Về đóng góp, tài liệu CONTRIBUTING mô tả quy trình issue và pull request, nhưng không nhắc tới thỏa thuận CLA trong phần đã đọc. [4] Với việc dùng nội bộ để quét mã của chính công ty, giấy phép MIT không đặt thêm nghĩa vụ chia sẻ lại mã, nhưng nếu đóng gói gitleaks vào sản phẩm bán ra thì phải giữ thông báo.
Chi phí và nguồn lực: nhẹ về hạ tầng, tốn công ở khâu xử lý cảnh báo
Về phần mềm, không có phí cấp phép vì giấy phép là MIT. [2] Về hạ tầng, gitleaks là chương trình chạy một lần rồi thoát, nên tài nguyên chủ yếu là thời gian CPU của máy phát triển và runner CI, cộng dung lượng lưu báo cáo. Bài không đưa ra mức tiêu thụ cụ thể vì không có số liệu được trích; README chỉ nói riêng giải mã chỉ làm tăng nhẹ thời gian quét. [1]
Giả định lập kế hoạch cho tình huống trên: một kỹ sư phụ trách một phần thời gian trong tháng đầu, dành thêm thời gian định kỳ cho rà soát ngoại lệ, và một khoản dự phòng cho việc xoay vòng khóa.
So sánh theo cách tiếp cận: bộ quét nhẹ, bộ quét có xác minh, kiểm soát từ nền tảng
Cách thứ nhất là bộ quét dựa trên quy tắc chạy cục bộ như gitleaks: nhanh, dễ hiểu, kết quả giải thích được vì mỗi phát hiện gắn với một quy tắc cụ thể. Điểm yếu là cảnh báo giả khi quy tắc chung chung, và việc không xác nhận khóa còn sống. [1]
Cách thứ hai là bộ quét có bước xác minh với dịch vụ gốc, như TruffleHog, hướng tới giảm cảnh báo giả bằng cách thử khóa. Đổi lại công cụ phải gửi yêu cầu ra ngoài. Cách thứ ba là tính năng quét bí mật có sẵn của nền tảng lưu trữ mã như GitHub hoặc GitLab, tiện nếu đã dùng sẵn nền tảng, nhưng phụ thuộc gói dịch vụ và vị trí kho mã. USERS.md nhắc rằng GitLab nằm trong danh sách tổ chức khai báo dùng gitleaks, nhưng không mô tả cách dùng cụ thể. [6]
Cách thứ tư là không dùng công cụ mà thay đổi cách làm việc: quản lý bí mật tập trung để mã không chứa khóa ngay từ đầu.
Hạn chế và những tình huống không nên dùng
Hạn chế lớn nhất là trạng thái dự án. README ghi rõ không nhận tính năng mới, chỉ vá bảo mật. [1] Nếu một dịch vụ mới phát hành định dạng khóa riêng, không có cam kết rằng quy tắc mặc định sẽ được thêm; đội phải tự viết quy tắc theo hướng dẫn trong cấu hình. [1][4]
Hạn chế thứ hai là bản chất phát hiện bằng mẫu. Regex Go không hỗ trợ lookahead, và entropy chỉ là gợi ý, nên cảnh báo giả và bỏ sót đều có thể xảy ra. [1] Bí mật bị mã hóa theo cách ngoài percent, hex, base64, hoặc nằm trong tệp nhị phân không nằm trong phạm vi các tính năng được mô tả. Phần quét kho nén và giải mã tắt theo mặc định, nên nếu không bật thì sẽ không được quét. [1]
Không nên dùng gitleaks như lớp bảo vệ duy nhất. Nó không thu hồi khóa, không viết lại lịch sử git, không quét hệ thống chat hay tài liệu ngoài kho, và cờ bỏ qua hook cho phép bất kỳ ai tắt kiểm tra cục bộ. [1] Do đó bước CI phía máy chủ mới là chốt cuối.
Kế hoạch thử nghiệm sáu tuần với tiêu chí đo được
Giai đoạn một, tuần một và hai: chọn ba đến năm kho đại diện (ứng dụng di động, cổng web, firmware bộ thu thập). Chạy quét toàn bộ lịch sử ở chế độ chỉ báo cáo, lưu báo cáo đã che bí mật. Mục tiêu đo: số phát hiện, tỷ lệ phát hiện thật sau khi con người phân loại, thời gian quét từng kho.
Giai đoạn hai, tuần ba và bốn: tạo baseline, viết quy tắc cho token nội bộ, thêm allowlist, bật pre-commit cho nhóm tình nguyện. Tiêu chí đề xuất: không quá năm cảnh báo giả trên một trăm commit sau khi chỉnh cấu hình, và thời gian hook không làm kỹ sư phàn nàn đến mức tắt hook. Ngưỡng này là mục tiêu thử nghiệm do đội đặt, không phải số liệu từ nguồn.
Giai đoạn ba, tuần năm và sáu: bật bước CI chặn merge ở một kho, thử quy trình thu hồi khóa trên một khóa giả, kiểm tra xem báo cáo CI có để lộ bí mật không. Tiêu chí thoát thành công: bắt được tất cả khóa giả loại đã định nghĩa, không có khóa thật mới lọt qua CI trong thời gian thử, và đội đồng ý duy trì. Tiêu chí dừng: cảnh báo giả vượt ngưỡng mà không giảm được bằng cấu hình, hoặc cần tính năng mà dự án đã tuyên bố không phát triển. [1]
Chỉ vá bảo mật: quản trị rủi ro bảo trì khi tác giả đã chuyển hướng
Câu trong README về Betterleaks là tín hiệu quản trị, không chỉ là thông báo kỹ thuật. [1]
Đề xuất quản trị gồm ba việc. Thứ nhất, ghim phiên bản và ghi vào sổ tài sản phần mềm của công ty để biết đang chạy bản nào. Thứ hai, đặt lịch rà soát quý về bộ quy tắc riêng, vì phần này đội kiểm soát được. Thứ ba, ghi sẵn điều kiện chuyển đổi: nếu bản vá bảo mật ngừng xuất hiện hoặc kho bị lưu trữ, đội đánh giá lại công cụ thay thế.
Bằng chứng về mức quan tâm của cộng đồng chỉ nên dùng ở mức giới thiệu bối cảnh. Trong kho lưu trữ GitHub Trending được dùng làm nguồn, gitleaks xuất hiện 18 lần quan sát, lần đầu ngày 9 tháng 1 năm 2026 ở vị trí thứ 9 của danh sách Go. [7] Đó là tín hiệu thu hút chú ý, không phải thước đo chất lượng hay bảo trì.
Kết luận
Gitleaks là một công cụ quét bí mật gọn, cấu hình bằng TOML, có đủ các tính năng thực dụng như baseline, allowlist, giải mã và quét kho nén, giấy phép MIT dễ chấp nhận. [1][2]
Với công ty bảo trì thang máy trong tình huống giả định, giá trị nằm ở hàng rào rẻ và rõ ràng ngay trước khi mã rời máy kỹ sư, cộng một chốt CI. Giá trị đó chỉ thành hiện thực nếu có người sở hữu cấu hình, quy trình thu hồi khóa, và kế hoạch thay thế khi công cụ không còn theo kịp.
Hành động tiếp theo hợp lý là chạy pilot sáu tuần ở trên, đo trên kho thật của đơn vị, rồi quyết định bằng dữ liệu của chính mình thay vì dựa vào lời giới thiệu của bất kỳ bài viết nào, kể cả bài này.
Nguồn và phương pháp
Đây là nghiên cứu tại bàn, không phải công bố khoa học được bình duyệt. Tác giả không cài đặt, không chạy, không đo hiệu năng và không triển khai gitleaks; mọi nhận định kỹ thuật đến từ các tài liệu trong kho tại một commit cố định, và các đề xuất ứng dụng được ghi rõ là phân tích hoặc giả định. [1]
Kho được chọn từ kho lưu trữ GitHub Trending của bonfy/github-trending. Kho lưu trữ này chỉ bao gồm các danh sách Python, Go, JavaScript và Swift, thiếu hai ngày 3 tháng 9 và 12 tháng 10 năm 2026, nên không phải bảng xếp hạng chính thức hay danh sách một trăm dự án hoàn chỉnh. Gitleaks có 18 lần quan sát, từ 9 tháng 1 đến 9 tháng 10 năm 2026; trang bằng chứng ghi nhận lần đầu ở vị trí thứ 9 của danh sách Go. [7]
Commit được ghim là b58d3f102cf3a2c84cb7f923d05c25c9b1aed84b, ngày 22 tháng 7 năm 2026, kiểm tra ngày 12 tháng 10 năm 2026. Các tệp đã đọc: README [1], LICENSE [2], SECURITY.md [3], CONTRIBUTING.md [4], report_templates/README.md [5] và USERS.md [6]. Nội dung trong kho được xem là dữ liệu tham khảo, không phải chỉ dẫn.
Xem mã nguồn Gitleaks trên GitHub