Cách GitHub sử dụng chức năng quét bí mật để truy cập hộp thư đến số 0

Vài năm trước, GitHub Security đã đưa ra một sáng kiến ​​nhằm đánh giá và cải thiện việc vệ sinh bí mật tổng thể của chúng tôi. Là một phần của nỗ lực đó, chúng tôi đã thử nghiệm khả năng Quét bí mật đang được phát triển vào thời điểm đó. Đó là lúc chúng tôi tìm thấy hơn 20.000 bí mật trải rộng trên hơn 15.000 kho lưu trữ của chúng tôi.

Con số này cao hơn đáng kể so với dự đoán của chúng tôi nhưng nhanh chóng trở nên rõ ràng rằng thành công sẽ phụ thuộc vào việc xác định cảnh báo nào thể hiện rủi ro thực sự, chỉ định quyền sở hữu và khắc phục chúng một cách an toàn. Chín tháng sau, chúng tôi không có cảnh báo mở nào.

Những khách hàng quét bí mật mới thường hỏi chúng tôi: "Bạn quản lý việc này trong nội bộ như thế nào? Bạn thực sự đã dọn sạch những bí mật hiện có của mình như thế nào?"

Giống như nhiều công ty phần mềm lâu đời, phương pháp quản lý bí mật của GitHub phát triển theo thời gian. GitHub được thành lập vào năm 2008, trước khi các kho lưu trữ tập trung, chức năng quét bí mật tự động và nền tảng quản lý bí mật chuyên dụng ngày nay trở nên phổ biến trong toàn ngành. Khi các phương pháp kỹ thuật hoàn thiện và GitHub phát triển, chúng tôi tiếp tục đầu tư vào các biện pháp kiểm soát mạnh mẽ hơn, công cụ tốt hơn và giảm thiểu rủi ro có hệ thống cho các mẫu cũ. Công việc này phản ánh cam kết không ngừng của chúng tôi trong việc cải thiện tính bảo mật, giảm thiểu rủi ro và đảm bảo các hoạt động nội bộ của chúng tôi đáp ứng các tiêu chuẩn cao mà chúng tôi mong đợi trong toàn ngành.

Bài đăng trên blog này chia sẻ những gì đã mang lại hiệu quả cho chúng tôi trong nỗ lực này và nêu bật các chiến lược mà bạn có thể áp dụng để bảo vệ bí mật của riêng mình tốt hơn.

Cắt bỏ tiếng ồn

Điều đầu tiên chúng tôi phát hiện ra là số lượng cảnh báo hơi sai lệch—tức là 20.000 cảnh báo không có nghĩa là 20.000 vấn đề nguy hiểm như nhau.

Khi tìm hiểu dữ liệu, chúng tôi phát hiện ra rằng chỉ có 5 kho lưu trữ đã chiếm khoảng 18.000 cảnh báo trong số đó và mọi bí mật trong số đó đều không hoạt động: các thiết bị kiểm tra, thông tin đăng nhập bị vô hiệu hóa và các bí mật giả mạo nhưng trông có vẻ hợp lệ được sử dụng để thử nghiệm. (Chúng tôi xây dựng chức năng quét bí mật, do đó, tất nhiên, chúng tôi có các kho lưu trữ chứa đầy các bí mật trông có vẻ hợp pháp trong các thử nghiệm.)

Điều đó để lại hơn 2.000 cảnh báo cần chú ý: thông tin xác thực trực tiếp tiềm năng và hàng nghìn quyết định về rủi ro, luân chuyển và khắc phục.

Bí mật không chỉ tồn tại trong mã

Bí quyết khắc phục cảm động hơn cả mã nguồn. Chúng tôi đã tìm thấy bí mật trong phiếu hỗ trợ (đôi khi khách hàng bao gồm mã thông báo), báo cáo tiền thưởng lỗi (các nhà nghiên cứu tiết lộ những gì họ tìm thấy với bản sao hoàn chỉnh, bao gồm các yêu cầu API có mã thông báo được sử dụng), ghi chú sự cố và trang wiki.

Chúng tôi hợp tác với bộ phận hỗ trợ khách hàng, ứng phó sự cố bảo mật và chương trình tiền thưởng lỗi của chúng tôi để phát triển các cẩm nang chia sẻ. Trong tất cả các quy trình công việc này, chúng tôi phải đảm bảo rằng chúng tôi không tạo ra các vấn đề mới, chẳng hạn như mở các vấn đề hoặc đẩy các cam kết chứa chính những bí mật mà chúng tôi đang cố gắng khắc phục.

Cách tiếp cận theo từng giai đoạn của chúng tôi

Chúng tôi sẽ không kết thúc 20.000 cảnh báo bằng cách yêu cầu một vài kỹ sư bảo mật xử lý từng cảnh báo một. Chúng tôi xử lý nó giống như bất kỳ hoạt động tồn đọng nào khác: ngừng nợ mới, sau đó giải quyết những gì đã tồn tại bằng quy trình làm việc có thể lặp lại, có thể đo lường được và không phụ thuộc vào kiến ​​thức tổ chức của một người.

Giai đoạn 1: Kích hoạt mọi nơi, ngừng tích lũy

Trước khi dọn dẹp những bí mật hiện có, chúng tôi phải ngăn chặn những bí mật mới chồng chất.

Chúng tôi đã kích hoạt tính năng quét bí mật và bảo vệ đẩy trên tất cả các doanh nghiệp và tổ chức của mình. Nhờ cài đặt cấp tổ chức của GitHub Advanced Security, đây không phải là công việc khó khăn theo từng kho lưu trữ trên 15.000 kho lưu trữ. Chúng tôi đã thực thi cài đặt này để các nhóm và kho lưu trữ riêng lẻ không thể lặng lẽ chọn không tham gia.

Bảo vệ đẩy đã chặn các bí mật mới tại nguồn. Điều đó giúp cho lượng tồn đọng không tăng nhanh đến mức chúng tôi có thể đốt hết.

Giai đoạn 2: Hiểu và phân loại

Chúng tôi đã chia nhỏ hơn 20.000 cảnh báo theo kho lưu trữ, loại bí mật và độ tuổi để có thể tách tiếng ồn khỏi công việc.

Khi tìm hiểu sâu hơn, chúng tôi phát hiện ra rằng chỉ có 5 kho lưu trữ đã chiếm khoảng 18.000 cảnh báo trong số đó và mọi bí mật trong số đó đều không hoạt động: các thiết bị kiểm tra, thông tin đăng nhập bị vô hiệu hóa và các bí mật trông giả mạo nhưng có vẻ hợp lệ được sử dụng để thử nghiệm. (Chúng tôi xây dựng chức năng quét bí mật, do đó, tất nhiên, chúng tôi có các kho lưu trữ chứa đầy các bí mật trông có vẻ hợp pháp trong các thử nghiệm.)

Đối với các cảnh báo số lượng lớn, rủi ro thấp, chúng tôi đã phát triển các tiêu chí để đóng hàng loạt. Nếu một bí mật nằm trong kho lưu trữ thử nghiệm chuyên dụng, chưa từng hoạt động và khớp với mẫu thử nghiệm đã biết thì chúng tôi có thể tự tin đánh dấu là nó đã được giải quyết. Chỉ trong vài ngày, chúng tôi đã xử lý được khoảng 18.000 cảnh báo.

Những câu hỏi khó

Chúng tôi phải đưa ra những quyết định mang tính chiến lược về cách khắc phục các bí mật. Khi một bí mật tồn tại trong một vấn đề, bạn có chỉnh sửa nội dung (và có khả năng xóa lịch sử sửa đổi) hay giữ lại dấu vết kiểm tra không? Khi một bí mật được đưa vào kho lưu trữ, bạn có viết lại lịch sử git không? Bất kỳ ai đã thử viết lại lịch sử git trên quy mô lớn đều biết điều gì sẽ xảy ra tiếp theo: lực đẩy phá vỡ các yêu cầu kéo mở, làm mất hiệu lực các SHA cam kết và thường làm gián đoạn các nhà phát triển.

Một câu hỏi phổ biến là: “Chúng ta có thể xóa kho lưu trữ nếu nó không còn được sử dụng nữa không?” Câu trả lời của chúng tôi nói chung là không. Kho lưu trữ đã xóa sẽ mang theo dấu vết kiểm tra của nó. Nếu một bí mật trong kho lưu trữ đó từng bị rò rỉ hoặc kho lưu trữ đã từng bị xâm phạm, bạn sẽ mất hồ sơ điều tra mà bạn cần trong quá trình ứng phó sự cố. Xoay bí mật, lưu trữ kho nếu thích hợp nhưng giữ lại lịch sử.

Bất cứ khi nào có thể, chúng tôi sẽ luân chuyển hoặc thu hồi bí mật bị lộ trước. Câu hỏi khó hơn là liệu rủi ro còn sót lại có đảm bảo việc viết lại lịch sử git hay liệu một bí mật đã bị thu hồi trong lịch sử có thể được giữ nguyên một cách an toàn hay không. Đây là các loại câu hỏi và quyết định xuất hiện trong mỗi cảnh báo mà các nhóm bảo mật sản phẩm phải vật lộn.

Giai đoạn 3: Xác thực những gì thực sự đang hoạt động

Thông tin xác thực nằm trong kho lưu trữ có thể đã được luân chuyển nhiều năm trước hoặc nó vẫn có thể mở khóa các hệ thống sản xuất. Bạn không thể ưu tiên nếu không biết sự khác biệt.

Vào thời điểm đó, tính năng quét bí mật không có tính năng kiểm tra tính hợp lệ gốc nên chúng tôi đã xây dựng phương pháp của riêng mình. Mục tiêu rất hẹp: xác định xem thông tin xác thực có còn hoạt động hay không và khi thích hợp, thu thập đủ siêu dữ liệu để định tuyến cảnh báo hoặc thông báo cho chủ sở hữu phù hợp.

Ví dụ: đối với mã thông báo GitHub, kiểm tra đại diện có thể thực hiện một yêu cầu được xác thực duy nhất tới điểm cuối có tác động thấp như GET /user:

response="$( curl -sS -w '\n%{http_code}' \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/vnd.github+json" \ -H "X-GitHub-Api-Version: 2022-11-28" \ https://api.github.com/user )" status="${response##*$'\n'}" body="${response%$'\n'*}" case "$status" in 200) login="$(jq -r '.login // empty' <<< "$body")" echo "token appears active for GitHub user: $login" ;; 401) echo "token appears invalid or revoked" ;; 403|429) echo "unable to determine validity; rate-limited or blocked" ;; *) echo "unable to determine validity: HTTP $status" ;; esac

Hãy nhớ rằng mục tiêu của chúng tôi là trả lời những nhóm câu hỏi hữu ích nhỏ nhất: thông tin xác thực này có còn hiệu lực không và ai cần biết về nó? Chúng tôi coi các phản hồi không rõ ràng là không có kết luận và chúng tôi tránh các yêu cầu tiếp theo tới các kho lưu trữ, tổ chức hoặc các tài nguyên riêng tư khác.

Điều này đòi hỏi sự hợp tác chặt chẽ với các nhóm pháp lý và quyền riêng tư của chúng tôi. Ngay cả việc kiểm tra tính hợp lệ “chỉ đọc” cũng có thể có tác động khi bạn chạm vào thông tin xác thực mà bạn có thể không sở hữu.

Khi chúng tôi thực hiện việc này một cách thủ công, nhóm sản phẩm của chúng tôi đã xây dựng giải pháp một cách tự nhiên, giúp công việc còn lại nhanh hơn nhiều. Kiểm tra tính hợp lệ hiện được tích hợp vào tính năng quét bí mật của GitHub.

Giai đoạn 4: Tìm ra ai sở hữu cái gì

Công việc đa chức năng đó cũng bộc lộ vấn đề về quyền sở hữu: ngay cả sau khi chúng tôi biết thông tin xác thực đang hoạt động, chúng tôi vẫn phải tìm ra ai có thể xoay vòng thông tin xác thực đó.

Chúng tôi hợp tác với bộ phận hỗ trợ khách hàng, ứng phó sự cố bảo mật và chương trình tiền thưởng lỗi của chúng tôi để phát triển các cẩm nang chia sẻ về các bí mật được báo cáo bên ngoài mã. Điều đó bao gồm việc sắp xếp lại các giá trị bí mật trước khi định tuyến công việc cho các nhóm, xác định xem thông tin xác thực thuộc về GitHub hay khách hàng và thông báo cho khách hàng hoặc nhà nghiên cứu bị ảnh hưởng để họ có thể luân chuyển mã thông báo dưới sự kiểm soát của họ. Trong tất cả các quy trình công việc này, chúng tôi phải đảm bảo rằng chúng tôi không tạo ra các vấn đề mới, chẳng hạn như mở các vấn đề hoặc đẩy các cam kết chứa chính những bí mật mà chúng tôi đang cố gắng khắc phục.

Đối với thông tin xác thực do GitHub cấp như mã thông báo truy cập cá nhân, chúng tôi đã làm việc với nhóm sản phẩm của mình để hiển thị siêu dữ liệu bí mật trực tiếp trong cảnh báo: ai đã tạo mã thông báo, thời điểm và phạm vi của nó. Điều đó có nghĩa là chúng tôi không cần sử dụng mã thông báo để tìm ra nó thuộc về ai.

Đối với mọi thứ khác, quyền sở hữu khó khăn hơn và điều này bộc lộ một vấn đề sâu sắc hơn: không phải tất cả các kho lưu trữ đều có chủ sở hữu rõ ràng.

Các tiêu chuẩn kỹ thuật nội bộ của chúng tôi (chương trình Cơ bản về Kỹ thuật) thực thi quyền sở hữu lâu dài đối với các dịch vụ và chúng tôi duy trì sự liên kết giữa các dịch vụ và kho lưu trữ, nhưng không phải tất cả các kho lưu trữ đều ánh xạ rõ ràng tới một dịch vụ. Nỗi đau mà chúng tôi trải qua đã dẫn đến sáng kiến ​​quyền sở hữu kho lưu trữ rộng hơn (sử dụng Thuộc tính tùy chỉnh của GitHub), cộng với nỗ lực song song nhằm đảm bảo tất cả bí mật trong trình quản lý thông tin xác thực của chúng tôi đều có chủ sở hữu lâu dài. Bạn không thể xoay bí mật nếu không tìm được chủ sở hữu.

Giai đoạn 5: Phân loại thủ công cho đuôi dài

Ngay cả với xác thực và siêu dữ liệu, một loạt cảnh báo dài vẫn cần có sự phán xét của con người. Đối với mỗi người: quyền truy cập này cấp quyền truy cập vào cái gì, nó đã được luân chuyển chưa, ai sở hữu hệ thống được kết nối và lộ trình khắc phục là gì?

Đối với mỗi cảnh báo mà chúng tôi loại bỏ, chúng tôi đảm bảo rằng xử lý chính xác (ví dụ: đã thu hồi, được sử dụng trong thử nghiệm, dương tính giả) đều được ghi lại, cùng với nhận xét chứa ngữ cảnh có liên quan, chẳng hạn như liên kết đến vấn đề khắc phục hoặc ngoại lệ bảo mật đã được phê duyệt.

Giai đoạn này yêu cầu sự hợp tác chặt chẽ giữa các nhóm để xác định chủ sở hữu hệ thống, xác thực trạng thái khắc phục và đánh giá rủi ro còn sót lại khi chỉ có tín hiệu tự động là không đủ.

Giai đoạn 6: Hệ thống hóa và thúc đẩy trách nhiệm giải trình

Khi các mẫu xuất hiện, chúng tôi đã làm cho công việc có thể mở rộng được:

• Chúng tôi đã chuyển cảnh báo đến nền tảng quản lý lỗ hổng nội bộ của mình để theo dõi và báo cáo tập trung.

• Thông tin xác thực khác nhau cần các bước khắc phục khác nhau. Chúng tôi ghi lại các vở kịch theo loại bí mật để các đội có thể tự phục vụ.

• Chúng tôi tự động hóa thông báo, định tuyến cảnh báo đến đúng nhóm dựa trên quyền sở hữu kho lưu trữ.

Phần cuối cùng là trách nhiệm giải trình. Chúng tôi đã gắn biện pháp khắc phục bí mật với chương trình Nguyên tắc cơ bản về kỹ thuật của GitHub, biến chương trình này thành một nền tảng bảo mật cơ bản mà các nhóm được đo lường dựa trên. Chúng tôi đặt ra những kỳ vọng rõ ràng và cung cấp cho các nhóm thông tin rõ ràng về trạng thái. Khi vệ sinh bí mật là một phần trong cách đo lường tình trạng kỹ thuật, nó sẽ trở thành trách nhiệm chung trong toàn tổ chức.

Chín tháng sau khi bắt đầu, chúng tôi nhận được hộp thư đến số 0.

Bài học kinh nghiệm

Điều này có ý nghĩa gì với bạn

Bạn không cần phải phát minh lại hầu hết những gì chúng tôi đã xây dựng. Nhiều giải pháp thủ công của chúng tôi, bao gồm kiểm tra tính hợp lệ, nhận dạng quyền sở hữu và phân loại hàng loạt, hiện là các tính năng gốc trong quét bí mật.

Nếu bạn bắt đầu ngay hôm nay:

• Kích hoạt và thực thi chức năng quét bí mật và bảo vệ đẩy ở mọi nơi.

• Phân loại tồn đọng theo kho lưu trữ và loại bí mật; đóng hàng loạt những gì bạn có thể chứng minh là tiếng ồn.

• Xác thực những gì đang hoạt động trước khi bạn chuyển lên cấp cao hơn.

• Định tuyến cảnh báo cho chủ sở hữu và theo dõi việc khắc phục giống như bất kỳ công việc kỹ thuật nào khác.

Sẵn sàng để bắt đầu? Tìm hiểu cách bật tính năng quét bí mật và bảo vệ đẩy bằng GitHub Advanced Security.

Sắp ra mắt: Cách chúng tôi giải quyết vấn đề quyền sở hữu kho lưu trữ trên quy mô lớn và tại sao quyền sở hữu lâu dài đối với các kho lưu trữ và bí mật lại là nền tảng mà mọi thứ khác đều phụ thuộc vào.

Bài đăng Cách GitHub sử dụng chức năng quét bí mật để tiếp cận số 0 hộp thư đến xuất hiện đầu tiên trên Blog GitHub.