Bảo mật Drupal là một trong số ít mảng của thế giới CMS mã nguồn mở mà quy trình công bố còn tốt hơn tiếng tăm của nền tảng. Đội bảo mật Drupal chạy một lịch công bố cố định, chấm điểm mọi khuyến cáo trên một thang số có tài liệu, và điều phối bản vá cho nhân lẫn hàng chục nghìn dự án đóng góp.

Thành tích ngoài thực địa lại tệ hơn mức quy trình đó xứng đáng. Site Drupal vẫn bị xâm nhập, và nguyên nhân gần như không bao giờ là không ai biết. Khuyến cáo đã được công bố, đúng hẹn, vào một ngày thứ Tư. Bản vá lên production vào tuần kế tiếp. Khoảng trống đó là chủ đề của bài này, còn gia cố, tường lửa và quyền tệp tồn tại để làm cho nó sống sót được hoặc để rút ngắn nó.

Rủi ro của bạn do tốc độ vá quyết định, chứ không do bạn tình cờ chạy mô-đun nào. Khuyến cáo cho nhân rơi vào khung thứ Tư hằng tháng, khuyến cáo cho dự án đóng góp thì mọi thứ Tư, và đều được chấm từ 0 đến 25 trên một thang công khai. Lỗi nhân cực kỳ nghiêm trọng từng bị khai thác chỉ vài giờ sau công bố: sau khuyến cáo SQL injection năm 2014, hướng dẫn chính thức là coi mọi site chưa vá trong bảy giờ là đã bị xâm nhập. Site nào không triển khai nổi bản vá nhân trong một ngày làm việc thì đang gánh gần như toàn bộ rủi ro đang tồn tại.

Quy trình khuyến cáo bảo mật Drupal thực sự vận hành ra sao

Phần lớn người vận hành site Drupal chưa từng đọc các tài liệu quy trình này, và đó là điều đáng tiếc: chúng nói rõ bạn được báo trước bao nhiêu, dưới dạng nào, vào những ngày nào.

Các khung phát hành

Đội bảo mật công bố theo lịch. Khuyến cáo cho dự án đóng góp ra mọi thứ Tư. Nhân có khung phát hành sửa lỗi và tính năng vào thứ Tư đầu tháng, khung phát hành bảo mật vào thứ Tư thứ ba, đúng như tài liệu về thời điểm phát hành bảo mật quy định. Một khung không hứa hẹn sẽ có gì đó ra mắt; nó tồn tại để quản trị viên biết cần canh những ngày nào.

Đôi khi có báo trước. Trước một bản phát hành nhân cực kỳ nghiêm trọng, đội bảo mật có thể đăng một thông báo dịch vụ công, thường vào thứ Hai. PSA-2026-05-18 đã làm vậy cho bản ra ngày 20 tháng 5 năm 2026, nêu rõ khung 17:00 đến 21:00 UTC và yêu cầu chủ site cập nhật lên bản vá mới nhất trên nhánh của mình trước, để các trục trặc nâng cấp lộ ra sớm. Hai ngày là mức báo trước nhiều nhất bạn nhận được.

Khuyến cáo cho nhân và khuyến cáo cho dự án đóng góp

Đây là hai hệ thống với hai mức bảo đảm khác nhau. Khuyến cáo cho nhân bao phủ các nhánh phụ được hỗ trợ, hai nhánh một lúc, bản mới nhất và bản ngay trước đó. Trên thực tế, lịch phát hành nhân nghĩa là 11.4.x và 11.3.x, còn 10.6.x vẫn được bao phủ cho tới khi Drupal 10 hết vòng đời vào ngày 9 tháng 12 năm 2026. Đầu tháng 9 năm 2026, các bản hiện hành là 11.4.5, 11.3.16 và 10.6.15. Drupal 12.0.0 và 11.5.0 dự kiến ra trong tuần của ngày 7 tháng 12 năm 2026, và khi đó hỗ trợ cho 11.3.x và 10.6.x kết thúc.

Phạm vi bao phủ phía đóng góp là tự nguyện và có điều kiện. Khuyến cáo chỉ được phát hành cho các bản ổn định thuộc nhánh chính được hỗ trợ của những dự án mà người bảo trì đã xin và được cấp quyền, theo chính sách quy trình và quyền hạn khuyến cáo bảo mật. Mô-đun đang ở bản alpha, beta hay ứng viên phát hành nằm ngoài hệ thống, mô-đun mà người bảo trì chưa bao giờ đăng ký cũng vậy. Cả hai điều đó đều không hiện ra trên giao diện quản trị khi site chạy bình thường.

Khối lượng mới là gánh nặng thật. Thứ Tư ngày 26 tháng 8 năm 2026, đội bảo mật công bố mười khuyến cáo dự án đóng góp trong một ngày, tất cả ở mức nghiêm trọng vừa. Một site chạy sáu mươi mô-đun sẽ bị gọi tên vài lần mỗi năm, và dòng chảy đó theo thời gian tốn kém hơn các đợt khẩn cấp của nhân.

Điểm rủi ro, và vì sao nó không phải CVSS

Mỗi khuyến cáo mang một con số trên thang 25. Thang này dựa trên Common Misuse Scoring System của NIST, tức NISTIR 7864, và được ghi trong trang định nghĩa mức rủi ro bảo mật. Sáu chỉ số nuôi nó: độ phức tạp truy cập, yêu cầu xác thực, tác động tới tính bí mật, tác động tới tính toàn vẹn, có mã khai thác đã biết hay không, và mức phân bố mục tiêu. Các dải chạy từ không nghiêm trọng ở 0 đến 4, ít nghiêm trọng ở 5 đến 9, nghiêm trọng vừa ở 10 đến 14, nghiêm trọng ở 15 đến 19 và cực kỳ nghiêm trọng ở 20 đến 25.

Vì mức phân bố mục tiêu nằm trong điểm số, một lỗi chỉ cắn được cấu hình hiếm gặp sẽ rơi thấp hơn so với dưới CVSS. SA-CORE-2026-005 ngày 17 tháng 6 năm 2026, một lỗi tiêm đối tượng PHP được theo dõi dưới mã CVE-2026-55803, đạt 18 điểm và được xếp nghiêm trọng chứ không phải cực kỳ nghiêm trọng, đúng vì lý do đó.

Khi một mô-đun đóng góp bị đánh dấu không còn được hỗ trợ

Đội bảo mật không thể ép một người bảo trì tình nguyện sửa bất cứ thứ gì. Khi người bảo trì ngừng hồi đáp, quy trình đã ghi thành văn là đánh dấu dự án không còn được hỗ trợ sau nhiều lần liên hệ. Trang dự án khi đó cảnh báo chủ site hãy chọn một giải pháp thay thế đang được bảo trì tích cực, hoặc trả tiền cho ai đó sửa lỗi để mô-đun được phát hành lại.

Lời khuyên ấy đúng và tốn kém, vì đến lúc một mô-đun bị đánh dấu không còn hỗ trợ thì nó thường đã là cấu kiện chịu lực, và thay nó nghĩa là di chuyển dữ liệu, sửa template và một vòng kiểm thử hồi quy đầy đủ. Thời điểm hành động rẻ nhất là bản phát hành ngay trước khi bị bỏ rơi, khi người bảo trì đã im lặng nhưng chưa có gì hỏng, và gần như không ai nhìn vào lúc đó.

Drupal 7 đã hết vòng đời, và hỗ trợ mở rộng không đồng nghĩa với an toàn

Drupal 7 hết vòng đời ngày 5 tháng 1 năm 2025, được xác nhận trong PSA-2025-01-06. Sau ngày đó, đội bảo mật ngừng cung cấp hỗ trợ và khuyến cáo cho nhân Drupal 7 cũng như cho các mô-đun và giao diện đóng góp của nó. Thông báo nói thẳng rằng từ nay lỗi bảo mật Drupal 7 có thể bị công khai mà không cần phối hợp, và lỗ hổng zero day có thể xảy ra.

Có một thị trường hỗ trợ mở rộng thương mại. Drupal Association đã chứng nhận các nhà cung cấp, trong đó có HeroDevs và Tag1 Consulting, theo một chương trình cung cấp hỗ trợ bảo mật mở rộng, và họ thực sự làm ra bản vá. Điều đó tốt hơn không có gì, nhưng không giống với việc được hỗ trợ. Nhà cung cấp vá nhân và một tập mô-đun do chính họ chọn, theo lịch của họ, cho những khách hàng trả tiền. Phần còn lại của hệ sinh thái mà site bạn phụ thuộc nằm ngoài phạm vi.

Một CMS không còn được hỗ trợ cũng khó bảo vệ trong bảng câu hỏi đánh giá nhà cung cấp, hay trước công ty bảo hiểm sau một sự cố. Bài viết của chúng tôi về chi phí, lựa chọn và hạn chót khi di chuyển Drupal nêu rõ chi phí thoát ra.

Khuôn mẫu lịch sử: Drupalgeddon và những gì tiếp theo

Ba sự cố đã định hình cách cộng đồng nghĩ về tốc độ vá. Mỗi vụ đều là lỗi tiêm hoặc thực thi mã từ xa trong nhân, và mỗi vụ đều chứng kiến khai thác tự động hàng loạt trong vài giờ hoặc vài ngày.

Cửa sổ bảy giờ của tháng 10 năm 2014

Drupalgeddon đầu tiên là SA-CORE-2014-005, công bố ngày 15 tháng 10 năm 2014. CVE-2014-3704 là một lỗi SQL injection trong lớp trừu tượng cơ sở dữ liệu của Drupal 7, khai thác được bởi người dùng ẩn danh, đạt trọn 25 trên 25. Mọi site Drupal 7 dưới bản 7.32 đều bị ảnh hưởng.

Phần tiếp sau mới biến nó thành cột mốc. PSA-2014-003 nói với chủ site rằng các đợt tấn công tự động đã bắt đầu chiếm quyền những site chưa vá chỉ vài giờ sau thông báo, và rằng họ nên coi mọi site chưa vá trước 23:00 UTC hôm đó, bảy giờ sau khi công bố, là đã bị xâm nhập. Không phải có thể đã bị. Là đã bị. Thông báo cảnh báo kẻ tấn công có thể đã lấy toàn bộ dữ liệu và cài cửa hậu, và chính điều đó biến một bài toán vá lỗi thành bài toán ứng cứu sự cố.

Drupalgeddon 2 và 3

SA-CORE-2018-002, công bố ngày 28 tháng 3 năm 2018, chính là CVE-2018-7600: một lỗi thực thi mã từ xa trải trên nhiều phân hệ của Drupal 7 và Drupal 8, đạt 24 trên 25. Nó ảnh hưởng Drupal 7.0 tới 7.57 và các nhánh 8.x lên tới 8.5.0, và mã khai thác công khai xuất hiện trong khoảng hai tuần.

Bốn tuần sau, SA-CORE-2018-004 đáp xuống ngày 25 tháng 4 năm 2018. CVE-2018-7602 là một lỗi thực thi mã từ xa khác trong phần mã liên quan, đạt 20 trên 25, và khuyến cáo nói rõ nó đã bị khai thác ngoài thực tế. Bài học nằm ở khoảng cách: những site vá hồi tháng 3 rồi thôi để tâm lại phơi mình lần nữa vào tháng 4.

Tháng 5 năm 2026, và những gì chưa đổi

Khuôn mẫu này không phải chuyện quá khứ. SA-CORE-2026-004 được công bố ngày 20 tháng 5 năm 2026: CVE-2026-9082, một lỗi SQL injection ảnh hưởng các site chạy PostgreSQL, xếp cực kỳ nghiêm trọng ở 23 trên 25, bao phủ mọi nhánh từ 8.9 lên tới 11.3.9. Ngày 22 tháng 5 lúc 04:30 UTC, khuyến cáo được sửa lại để ghi nhận các nỗ lực khai thác bị phát hiện ngoài thực tế, chưa đầy 48 giờ kể từ lúc công bố.

Không điều nào trong đó là lời phê phán đội bảo mật. Họ báo trước hai ngày, phát hành đúng khung đã thông báo, và cập nhật khuyến cáo khi bức tranh thay đổi. Chỗ hỏng nằm ở phía vận hành: không có lộ trình đã tập dượt nào đi từ một khuyến cáo tới một site production đã vá.

Bảo mật Drupal thực sự thất bại ở đâu trong thực tế

Nhân chiếm hết tít báo và lại là phần nhỏ nhất. Trong các site chúng tôi kiểm tra, phát hiện đáng kể hiếm khi là một bản nhân chưa vá, vì bản cập nhật nhân hiện lên giao diện quản trị và ai đó sẽ để ý. Rủi ro nằm chỗ khác.

Danh mục mô-đun không ai có

Một site Drupal cỡ vừa điển hình chạy từ bốn mươi đến tám mươi mô-đun đóng góp, mỗi mô-đun một người bảo trì và một nhịp riêng. Câu hỏi gần như không ai trả lời ngay được là mô-đun nào còn người bảo trì hoạt động, mô-đun nào thuộc phạm vi chính sách khuyến cáo, và mô-đun nào đã hai năm không có commit nào. Lập danh sách đó mất một buổi chiều.

Mô-đun tùy chỉnh không ai nhận

Phát hiện nghiêm trọng hay gặp nhất là một mô-đun tùy chỉnh do một nhà thầu đã rời đi viết ra. Nó thường làm việc mang dáng dấp tích hợp: một luồng dữ liệu CRM, một trình xử lý biểu mẫu riêng, một callback thanh toán. Nó được viết cho một API cũ hơn, không có kiểm thử, và không ai trong đội nói được nó kiểm tra những gì. Mã tùy chỉnh nằm ngoài hệ thống khuyến cáo theo đúng định nghĩa: sẽ không có email thứ Tư nào báo rằng nó chứa lỗi SQL injection, còn báo cáo trạng thái vẫn hiện mọi thứ đã cập nhật. Nó cần đúng kỷ luật rà soát như mọi công việc phát triển phần mềm khác.

Tầng bên dưới Drupal

Drupal là PHP, và các phiên bản PHP hết vòng đời theo lịch riêng. Một site có thể đã vá đầy đủ ở tầng CMS mà vẫn chạy trên một bản PHP đã ngừng nhận bản sửa bảo mật từ một năm trước, vì hạ tầng lưu trữ chưa bao giờ được đưa vào câu chuyện bảo trì. Hướng dẫn về quyền tệp và quyền sở hữu đặt trên nguyên tắc rằng máy chủ web không được phép ghi vào chính những tệp nó thực thi, thế mà nhiều site vẫn chạy với thư mục mã ghi được, chỉ vì như thế thì một kịch bản triển khai nào đó đơn giản hơn.

Một site Drupal đáng lẽ phải được vá như thế nào

Câu trả lời buồn tẻ, và chính vì thế mà nó không được làm. Không công cụ nào xóa bỏ nhu cầu có một lộ trình đã tập dượt từ khuyến cáo tới production, và dựng nó một lần rẻ hơn lần khẩn cấp đầu tiên.

Quy trình Composer

Mọi thứ từ Drupal 8 trở đi đều là dự án Composer. Cập nhật các gói nhân cùng phụ thuộc của chúng, rồi áp dụng cập nhật cơ sở dữ liệu và dựng lại bộ nhớ đệm:

1composer update "drupal/core-*" --with-all-dependencies
2drush updatedb
3drush cache:rebuild

Có thể thay Drush bằng update.php. Hãy xem báo cáo trạng thái trước và sau. Điều quan trọng không phải mấy câu lệnh, mà là chúng chạy ở một nơi khác production trước đã.

Staging thực sự là một bản sao

Môi trường staging chỉ hữu ích khi nó phản chiếu production: cùng bộ mô-đun, cùng phiên bản PHP, một bản cơ sở dữ liệu gần đây đã làm sạch. Một staging cũ kỹ cho ra kết quả xanh chẳng nghĩa lý gì, và như thế còn tệ hơn không có staging, vì nó chế tạo ra sự tự tin.

Trình tự là kéo production xuống staging, áp dụng cập nhật, chạy cập nhật cơ sở dữ liệu, đi hết những trang và biểu mẫu làm nên giá trị thương mại của site, rồi mới triển khai. Với một quy trình chạy được thì mất 45 đến 90 phút. Không có thì mất một ngày rưỡi.

Tự động hóa, và giới hạn của nó

Cập nhật phụ thuộc tự động giúp nhiều nhất ở dòng mô-đun đóng góp, tức đầu nhiều việc và ít nghiêm trọng. Một con bot mở một pull request cho mỗi lần cập nhật mô-đun, với kiểm thử chạy cho từng cái, biến đợt quét thủ công hằng tháng thành một hàng đợi rà soát. Nhân cũng đang đi theo hướng đó: công việc Automatic Updates được xây trên mô-đun Package Manager, mô-đun này đi kèm nhân nhưng vẫn còn thử nghiệm.

Ngân sách thời gian thực tế

Một site Drupal được bảo trì tốn khoảng nửa ngày mỗi tháng cho cập nhật mô-đun thường lệ, cộng một đến ba giờ cho mỗi bản phát hành bảo mật nhân có liên quan. Thêm dự phòng cho một hoặc hai bản cực kỳ nghiêm trọng mỗi năm phải làm ngay tối hôm đó. Đó là con số mà phần lớn đội nội bộ chưa bao giờ đưa vào ngân sách, và vì thế công việc bị trễ.

Gia cố ngoài việc vá lỗi

Gia cố không thay thế việc vá. Nó giảm số lỗ hổng đã công bố có thể khai thác được trên bản cài đặt của bạn, và mua thời gian khi bản vá chưa thể đi ngay. Các hạng mục riêng của Drupal thì rẻ và có tính lâu dài.

Máy chủ tin cậy và hệ thống tệp

Hãy đặt mẫu máy chủ tin cậy. Drupal dùng cơ chế trusted host của Symfony, cấu hình qua thiết lập trusted_host_patterns trong settings.php dưới dạng biểu thức chính quy khớp các tên miền mà site trả lời. Yêu cầu mang bất kỳ Host header nào khác sẽ bị từ chối với mã 400. Không có nó, kẻ tấn công có thể đầu độc liên kết đặt lại mật khẩu và các URL tuyệt đối đã lưu đệm bằng một header giả.

Hãy dùng hệ thống tệp riêng tư cho mọi thứ không nên đọc được công khai, và bảo đảm PHP không thể chạy bên trong thư mục tệp công khai. Drupal kèm sẵn một tệp .htaccess chặn thực thi dưới Apache, nhưng nginx không có tệp tương đương chỉ việc thả vào, nên quy tắc phải được viết tay vào cấu hình máy chủ. Những site chuyển từ Apache sang nginx nhiều năm trước thường mất lớp bảo vệ đó mà không hay.

Rồi áp dụng mô hình quyền sở hữu: thư mục ở 750, tệp mã ở 640, thư mục tệp chỉ máy chủ web ghi được, và settings.php chỉ chủ sở hữu đọc được.

Quyền hạn, đường dẫn quản trị và lượt rà soát

Hãy hạn chế các đường dẫn quản trị. Không có lý do gì để đường đăng nhập và đường quản trị của một site mà biên tập viên làm việc từ ba văn phòng lại mở cho cả Internet, và một danh sách IP cho phép hay một proxy có xác thực sẽ gạt bỏ cả một lớp tấn công vào thông tin đăng nhập.

Sau đó hãy soát lại bảng phân quyền. Nó phình ra theo mỗi mô-đun được cài, và phát hiện gần như luôn cùng một hình dạng: một vai trò biên tập có quyền quản trị bộ lọc văn bản, hoặc một vai trò có thể chạy PHP tùy ý. Cả hai đều biến một mật khẩu biên tập viên bị đánh cắp thành thực thi mã từ xa, nên một email lừa đảo trở thành một máy chủ bị chiếm.

Hãy chạy mô-đun Security Review trước khi tranh luận bất cứ điều gì khác. Nó tự động hóa những kiểm tra làm tay rất mệt: quyền hệ thống tệp, định dạng văn bản không an toàn, PHP hay JavaScript trong nội dung, lộ báo lỗi, phần mở rộng tải lên, đăng nhập thất bại, quyền nguy hiểm và cấu hình máy chủ tin cậy. Bản 3.1.3, phát hành tháng 1 năm 2026, hỗ trợ Drupal 10.3 trở lên bên cạnh Drupal 11.

Tường lửa mua được gì và không mua được gì

Tường lửa ứng dụng web là một bản vá ảo, và đó chính là cách Drupal Association định vị Drupal Steward, dịch vụ trả phí mà tổ chức này vận hành cùng đội bảo mật. Nó áp dụng biện pháp giảm nhẹ ở tầng mạng cho một số lỗ hổng nhân cực kỳ nghiêm trọng, che chở site trong khoảng trống giữa khuyến cáo và triển khai. Giá công bố là dưới 20 đô la Mỹ mỗi tháng cho một site phục vụ 1 triệu yêu cầu HTTP, và dưới 100 đô la Mỹ khi vượt 10 triệu.

Giới hạn do chính dự án nêu ra: không phải vấn đề nào cũng giảm nhẹ được theo cách này, và cơ chế chỉ bao phủ những lỗ hổng bị khai thác qua một yêu cầu tới máy chủ web. Tường lửa không làm gì được với một mật khẩu quản trị bị đánh cắp, một bản cập nhật mô-đun độc hại hay một lỗi trong chính mã của bạn. Hãy coi nó là bảo hiểm cho cửa sổ vá lỗi, chứ không phải lý do để nới rộng cửa sổ đó, và đó cũng là quan điểm chúng tôi giữ trong danh sách kiểm tra gia cố bảo mật WordPress.

Một vụ xâm nhập tốn bao nhiêu và phục hồi trông ra sao

Phục hồi sau một vụ xâm nhập Drupal không phải là một bản vá. Một khi kẻ tấn công đã thực thi được mã, giả định làm việc là tệp đã bị ghi, thông tin đăng nhập đã bị lấy và một cơ chế trụ lại đã được cài, đúng như điều đội bảo mật nói với chủ site Drupal 7 năm 2014. Dọn dẹp tại chỗ một site bị xâm nhập là phỏng đoán khoác áo khắc phục.

Cách làm đứng vững được là dựng lại mã nguồn từ hệ quản lý phiên bản lên một máy chủ mới, chỉ khôi phục nội dung và tệp tải lên sau khi đã soi kỹ, xoay toàn bộ thông tin đăng nhập mà site từng giữ, và bảo toàn ảnh đĩa bị xâm nhập thay vì xóa nó. Bước cuối là bước người ta hay bỏ qua khi bị dồn ép, và nó là bằng chứng duy nhất về những gì đã xảy ra.

Chi phí thương mại hiếm khi nằm ở phần dựng lại. Nó nằm ở thời gian ngừng hoạt động, công việc pháp chứng, việc thông báo cho khách hàng và thủ tục pháp lý. Dựng lại trong điều kiện sự cố thường tốn 5.000 đến 20.000 bảng công kỹ thuật, và thường là khoản nhỏ nhất trong tổng số.

Nghĩa vụ bảo vệ dữ liệu tại Anh

Nếu dữ liệu cá nhân đã hoặc có thể đã bị truy cập, đồng hồ UK GDPR bắt đầu chạy từ lúc bạn biết, chứ không phải từ lúc bạn điều tra xong. Hướng dẫn về vi phạm của ICO yêu cầu một vi phạm phải báo cáo thì phải báo không chậm trễ quá mức và không muộn hơn 72 giờ kể từ khi biết, và nếu lâu hơn thì bạn phải nêu lý do. Khi vi phạm có khả năng gây rủi ro cao cho quyền và tự do của cá nhân, bạn còn phải thông báo cho chính những cá nhân đó, cũng không chậm trễ quá mức.

ICO nói rõ rằng bức tranh chưa đầy đủ không phải lý do để lỡ hạn: hãy báo cáo những gì bạn biết rồi bổ sung sau. Không thông báo khi buộc phải thông báo có thể dẫn tới mức phạt lên tới 8,7 triệu bảng hoặc 2 phần trăm doanh thu toàn cầu.

Chính đồng hồ đó khiến câu hỏi pháp chứng trở nên quan trọng. Một site không có nhật ký và không có hồ sơ về phiên bản đang chạy thì không thể nói dữ liệu nào đã bị truy cập, nên cuối cùng phải khai báo theo tình huống xấu nhất. Đó là lý lẽ cho việc làm một đợt kiểm tra bảo mật website trước sự cố chứ không phải sau.

Một hợp đồng bảo trì bảo mật Drupal nên gồm những gì

Một hợp đồng chỉ hứa áp dụng bản cập nhật thì không đáng mua, vì áp dụng cập nhật là nửa dễ. Thứ bạn trả tiền là lộ trình phản ứng vào ngày một khuyến cáo cực kỳ nghiêm trọng đáp xuống, và sản phẩm chứng minh nó chạy được là một buổi diễn tập.

Phạm vi đáng trả tiền bao gồm việc theo dõi luồng khuyến cáo cho đúng bộ mô-đun của bạn, một chu kỳ vá hằng tháng có staging, kiểm thử và kế hoạch quay lui, một khung phản ứng ngoài giờ đã thỏa thuận cho các bản nhân cực kỳ nghiêm trọng, một đợt rà soát hằng quý các mô-đun bị bỏ rơi kèm dự toán cho phương án thay thế, việc theo dõi phiên bản PHP và nền tảng, cùng một đợt soát cấu hình hằng năm.

Tại Anh, thỏa thuận chỉ theo dõi rơi vào khoảng 250 đến 450 bảng mỗi tháng. Một hợp đồng gồm cả staging, kiểm thử và triển khai cho một site cỡ vừa thì gần hơn với 600 đến 1.500 bảng mỗi tháng, co giãn theo số mô-đun và khối lượng mã tùy chỉnh, vì cả hai quyết định mỗi chu kỳ cần bao nhiêu kiểm thử hồi quy. So với mức ngày công 600 đến 900 bảng của các công ty dịch vụ, đầu trên của dải đó mua được chừng hai ngày kỹ sư. Ghi chú của chúng tôi về mức phí và cách thẩm định lập trình viên Drupal có các con số.

Khép lại khoảng trống

Drupal cho bạn nhiều cảnh báo trước và nhiều cấu trúc hơn gần như mọi nền tảng tương đương. Khuyến cáo chạy theo lịch và các bản cực kỳ nghiêm trọng đến kèm hai ngày báo trước. Không điều nào giúp được một site mất hai tuần mới triển khai nổi một bản vá một dòng.

Mecanik xử lý việc vá và gia cố Drupal như một phần của kiểm tra bảo mật website và công việc phát triển phần mềm thường xuyên. Lần hợp tác đầu tiên thường là một đợt kiểm kê chứ không phải một lần sửa, vì phần lớn site không nói nổi mô-đun nào của mình còn được hỗ trợ. Nếu bạn đang cân nhắc chính nền tảng này, hướng dẫn phát triển web Drupal 2026 của chúng tôi bàn về điều đó.

Câu hỏi thường gặp

Drupal phát hành bản cập nhật bảo mật thường xuyên đến mức nào? Khuyến cáo cho dự án đóng góp được công bố mọi thứ Tư, còn nhân Drupal có khung phát hành bảo mật vào thứ Tư thứ ba hằng tháng, dù một khung không bảo đảm sẽ có bản phát hành. Các bản nhân cực kỳ nghiêm trọng thường được báo trước khoảng hai ngày bằng một thông báo dịch vụ công nêu rõ ngày và khung giờ.

Điểm rủi ro bảo mật Drupal 20 trên 25 nghĩa là gì? Drupal chấm mọi khuyến cáo từ 0 đến 25 bằng một hệ thống dựa trên Common Misuse Scoring System của NIST, kết hợp độ phức tạp truy cập, yêu cầu xác thực, tác động tới tính bí mật và tính toàn vẹn, việc có mã khai thác đã biết hay không, và bao nhiêu site bị ảnh hưởng. Bất cứ mức nào từ 20 đến 25 đều là cực kỳ nghiêm trọng, nghĩa là phải vá ngay trong ngày.

Chạy Drupal 7 trong năm 2026 còn an toàn không? Không. Drupal 7 hết vòng đời ngày 5 tháng 1 năm 2025 và đội bảo mật Drupal không còn phát hành khuyến cáo cho nhân, mô-đun đóng góp hay giao diện của nó, nên lỗi có thể bị công khai mà không có bản sửa được phối hợp. Hỗ trợ mở rộng thương mại chỉ bao phủ một tập mã xác định theo điều kiện của nhà cung cấp, hữu ích trong lúc di chuyển nhưng không giống với việc được hỗ trợ.

Kẻ tấn công khai thác một lỗ hổng Drupal nhanh đến mức nào? Trong vài giờ, ở những trường hợp tệ nhất. Sau khuyến cáo SQL injection tháng 10 năm 2014, đội bảo mật Drupal nói chủ site hãy coi mọi site chưa vá trong bảy giờ là đã bị xâm nhập. Tháng 5 năm 2026, các nỗ lực khai thác nhắm vào một lỗi SQL injection cực kỳ nghiêm trọng trong nhân bị phát hiện ngoài thực tế chưa đầy hai ngày sau khi công bố.

Tường lửa ứng dụng web có khiến việc vá Drupal thành không cần thiết không? Không. Một tường lửa như Drupal Steward cung cấp bản vá ảo cho một số lỗi nhân cực kỳ nghiêm trọng bị khai thác qua yêu cầu web, nhờ đó mua thêm thời gian trong cửa sổ triển khai. Nó không giúp được gì với một mật khẩu quản trị bị đánh cắp, một mô-đun bị xâm nhập hay một lỗi trong chính mã của bạn, nên nó giảm rủi ro của khoảng trống chứ không khép khoảng trống lại.