Ngồi xuống và bắt đầu

Chính sách quản trị là một công cụ quan trọng trong bộ công cụ quản lý rủi ro thành phần của bạn. Chính sách quản trị hoạt động như một tuyên bố công khai về khả năng chấp nhận rủi ro của bạn và một bộ hướng dẫn mà những người khác sẽ sử dụng để định hướng việc ra quyết định. Các chính sách quản trị tốt là những chính sách ngắn gọn, có ngôn ngữ đơn giản và khả dụng đối với tất cả mọi người trong tổ chức của bạn.

Nếu bạn chưa có một chính sách quản trị, hãy bắt đầu từ quy mô nhỏ và tập trung. Chính sách quản trị đầu tiên của bạn nên có phạm vi được giới hạn vừa phải, đưa ra các yêu cầu nhỏ và được tính toán, đồng thời chỉ bao gồm các bên liên quan chính. Khi chính sách hoạt động ổn định ở một mức độ nào đó, hãy dần dần tinh chỉnh và thêm vào nhiều nhóm, nhiều yêu cầu lớn hơn. Sẽ là không khôn ngoan nếu bạn thử và thực hiện một chính sách quản trị đầy đủ ngay lập tức – bạn sẽ đốt cháy các nguồn lực và thiện chí gần như ngay lập tức. Chính vì vậy, bạn nên xem xét mô hình crawl/walk/run khi mới bắt đầu.

Khi chính sách của bạn đi vào hoạt động, hãy theo dõi các nút thắt cổ chai và mở các kênh phản hồi để những người khác có thể thông báo cho bạn khi phát hiện nút thắt cổ chai. Những nút thắt này sẽ xuất hiện lần đầu tiên khi việc Phát triển và Vận hành liên quan đến Bảo mật. Giải quyết những nút thắt cổ chai này cũng loại bỏ các vấn đề cản trở khả năng mở rộng và gây ra sự lặp đi lặp lại – đồng nghĩa với việc tự động hoá.

Crawl – SBOM và Đánh giá rủi ro

Trong lần đầu tiên bạn thông qua chính sách quản trị, hãy tập trung vào việc tạo SBOM (Software Bill of Materials – Hoá đơn nguyên vật liệu phần mềm) cho tất cả các ứng dụng mới và ứng dụng hiện có của bạn. Hãy chỉ định trách nhiệm giải trình cho các nhóm phát triển trong việc tạo và lưu trữ SBOM cho mọi bản dựng triển khai ứng dụng. Các SBOM đóng vai trò là bản ghi tại một thời điểm nhất định của ứng dụng. Các yêu cầu pháp lý xung quanh SBOM sắp được triển khai, vì vậy bạn nên sớm lên kế hoạch lưu trữ các SBOM này trong vòng 10 năm trở lên.

Thêm vào đó, hãy tìm cách thực hiện đánh giá rủi ro trên các ứng dụng mới và ứng dụng hiện có. Có khả năng nhóm AppSec của bạn đã chịu trách nhiệm về việc này. Hãy lưu trữ những thứ này cùng với SBOM và thường xuyên xem xét lại chúng trong các cuộc họp nhóm liên chức năng. Ngay cả khi bạn không khắc phục được sự cố, việc nhận thức được rủi ro cũng vẫn là một bước đi đúng đắn. Nếu có điều gì đó không ổn – và khả năng chắc chắn là điều đó sẽ xảy ra – thì việc có các đánh giá rủi ro sẽ giúp giảm thiểu đáng kể thời gian phản hồi của bạn.

Có nhiều công cụ tự động giúp bạn thực hiện công việc này một cách dễ dàng và hỗ trợ khả năng mở rộng, một trong số đó là Lifecycle của Sonatype. Dự án CycloneDX có một số công cụ mã nguồn mở có thể giúp bạn tiết kiệm chi phí ban đầu.

Walk – Khắc phục

Sau khi tổ chức của bạn đã quen với giai đoạn Crawling, hãy cập nhật chính sách quản trị để giải quyết chủ đề về khắc phục. Ở cấp độ vi mô, hãy chỉ định trách nhiệm giải trình cho hành động khắc phục và cho phép những cá nhân đó ưu tiên quản lý rủi ro thành phần. Ví dụ, hãy cấp cho họ quyền tạo và di chuyển ticket trong trình quản lý issue (Jira hoặc Assembla) dành riêng cho công việc khắc phục của bạn.

Ở giai đoạn vĩ mô, hãy thiết lập một lộ trình khắc phục lý tưởng. Thông thường, cách tốt nhất để khắc phục là cập nhật thành phần lên một phiên bản không dễ bị tổn thương. Nếu điều đó là không thể, hãy mô tả những cách khắc phục khác nên được thử nghiệm. Nếu không thể khắc phục, hãy tài liệu hoá các nỗ lực giảm thiểu hoặc cách tạm thời loại bỏ rủi ro cho đến một thời điểm nào đó trong tương lai.

Run – Thiết lập mục tiêu và thực thi

Khi quá trình khắc phục đã trở nên quen thuộc, bạn có thể bắt đầu giai đoạn Run. Trong giai đoạn này, hãy cập nhật chính sách quản trị của bạn để thiết lập mục tiêu của tổ chức trong việc quản lý rủi ro thành phần. Mục tiêu này sẽ phát triển khi tổ chức của bạn phát triển. Do đó, các mục tiêu của bạn nên được xem xét lại một cách thường xuyên và được chuẩn bị sẵn sự linh hoạt ở một mức độ nhất định.

Ví dụ, bạn có thể bắt đầu bằng cách không cho phép triển khai các ứng dụng nếu chúng chứa rủi ro bảo mật thành phần ở một mức độ nghiêm trọng nhất định. Sau đó, bạn sẽ cập nhật chính sách để thêm vào một quy tắc mới, chẳng hạn như quy tắc về giấy phép thành phần.

Giai đoạn này cũng là lúc bạn bắt đầu thực thi các mục tiêu của mình bằng cách chủ động chặn các bản dựng, triển khai và tải xuống các gói có mức độ rủi ro không thể chấp nhận được. Thực thi luôn là một chủ đề phức tạp – chúng ta sẽ thảo luận thêm về vấn đề này sau – nhưng bạn cũng có thể chuẩn bị để thành công bằng việc tự động hoá quá trình thực thi này. Lý tưởng nhất là tự động hoá việc ngăn chặn dựa trên điểm số do một công cụ đánh giá, đồng thời gửi phản hồi trực tiếp đến những người có liên quan. Đừng dựa dẫm vào bản năng của ai đó trong nhóm AppSec của bạn – những sơ suất do con người tạo ra sẽ chỉ mang đến nỗi thất vọng.

Nhận thức mâu thuẫn giữa chính sách và sự đổi mới

Luôn có một mâu thuẫn giữa việc đưa ra các quy tắc và khuyến khích đổi mới. Điều này đặc biệt đúng trong trường hợp thực thi chính sách quản trị. Bạn có thể giảm bớt mâu thuẫn đó bằng một số cách như sau.

Đầu tiên, hãy làm rõ rằng việc quản lý rủi ro thành phần là nỗ lực của toàn bộ công ty chứ không phải “lỗi” của bất kỳ cá nhân hay nhóm nào. Đó cũng là lý do chúng ta nên dùng từ “trách nhiệm giải trình” thay vì “trách nhiệm”. Việc giao trách nhiệm cũng giống như quy trách nhiệm, còn trách nhiệm giải trình chỉ giống như một yêu cầu giải thích và trình bày về một vấn đề nào đó.

Thứ hai, hãy tránh tâm lý soi xét và mắng mỏ. Việc đặt ra các quy tắc chống lại các nhà phát triển của bạn sẽ chỉ dẫn đến vấn đề triển khai chậm, sự phức tạp và cảm giác khó chịu của tất cả mọi người.

Thứ ba, hãy làm rõ những gì sẽ bị chặn, khi nào và như thế nào, đồng thời vạch rõ lộ trình để được bỏ chặn. Việc tự động hoá chặn và bỏ chặn sẽ giúp bạn nâng cao cả tốc độ và khả năng dự đoán.

Cuối cùng, hãy nhận thức mâu thuẫn một cách đơn giản! Một chính sách quản trị sẽ không loại bỏ những ý tưởng mới hoặc làm chậm quá tình phát triển, mà cần đảm bảo rằng các ứng dụng có chất lượng cao, ổn định và đổi mới, đồng thời tạo ra một kênh để nhận phản hồi. Giống như bất kỳ nỗ lực DevOps nào, chính sách quản trị của bạn cần là sự hợp tác.

Và, có thể bạn đã biết, việc xã hội hoá chính sách quản trị của bạn sẽ trở thành một chìa khoá chiến lược!

Theo Sonatype

Bài đăng này là một phần trong series chia sẻ Những thực hành hay nhất trong việc quản lý thành phần nguồn mở của Sonatype.

Hãy phát triển chính sách quản trị bằng cách sử dụng framework Crawl/Walk/Run nhằm mở các kênh phản hồi, theo dõi các nút thắt cổ chai, tự động hoá tốc độ và khả năng dự đoán của bạn.