Code Review là gì? Nó khác biệt gì với Secure Code Review

1. Trọn bộ những thông tin cơ bản về Code Review cho bạn 

1.1. Bạn đã biết code review là gì?

Code review được hiểu đơn giản là đánh giá mã, thông qua việc xem xét, chất lượng phần mềm, xác định các lỗi bảo mật. Việc xem xét mã nhằm xác định các lỗi bảo mật trong ứng dụng liên quan đến các tính năng và thiết kế của nó, cùng với nguyên nhân gốc rễ chính xác. Với sự phức tạp ngày càng tăng của các ứng dụng và sự ra đời của các công nghệ mới, cách kiểm tra truyền thống có thể không phát hiện được tất cả các lỗi bảo mật có trong các ứng dụng. Người ta phải hiểu mã của ứng dụng, các thành phần bên ngoài và cấu hình để có cơ hội tốt hơn trong việc kết hợp các fawx. 

Việc đi sâu vào mã ứng dụng cũng giúp xác định các kỹ thuật giảm thiểu chính xác có thể được sử dụng để ngăn chặn các lỗi bảo mật.  Đây là quá trình kiểm tra mã nguồn của một ứng dụng để xác minh rằng các biện pháp kiểm soát bảo mật và logic thích hợp có sẵn, chúng hoạt động như dự định và chúng đã được gọi ở đúng nơi hay chưa. Xem xét mã - code review - là một cách giúp đảm bảo rằng ứng dụng đã được phát triển để có thể “tự bảo vệ” trong môi trường nhất định của nó. Xem xét mã bảo mật cho phép một công ty đảm bảo các nhà phát triển ứng dụng đang tuân theo các kỹ thuật phát triển an toàn.

Một nguyên tắc chung là kiểm tra thâm nhập không được phát hiện thêm bất kỳ lỗ hổng ứng dụng nào liên quan đến mã được phát triển sau khi ứng dụng đã trải qua quá trình đánh giá mã bảo mật thích hợp. Ít nhất là rất ít vấn đề nên được phát hiện. Tất cả các đánh giá về mã bảo mật là sự kết hợp giữa sự hỗ trợ của con người và công nghệ. Ở một đầu của phổ là một người thiếu kinh nghiệm với trình soạn thảo văn bản.  Ở đầu bên kia của thang đo là một nhóm bảo mật chuyên gia với các công cụ phân tích tĩnh (SAST) tiên tiến.

Thật không may, cần phải có một mức độ chuyên môn khá nghiêm túc để sử dụng các công cụ bảo mật ứng dụng hiện tại một cách hiệu quả. Họ cũng không hiểu dữ liệu động hoặc logic kinh doanh. Các công cụ SAST rất phù hợp cho việc bao phủ và thiết lập đường cơ sở tối thiểu. Các công cụ có thể được sử dụng để thực hiện nhiệm vụ này nhưng chúng luôn cần con người xác minh.  Họ không hiểu ngữ cảnh, đó là nền tảng của việc xem xét mã bảo mật. Các công cụ tốt trong việc đánh giá lượng lớn mã và chỉ ra các vấn đề có thể xảy ra, nhưng một người cần xác minh mọi kết quả để xác định xem đó có phải là vấn đề thực sự hay không, có thực sự có thể khai thác được hay không và tính toán rủi ro đối với doanh nghiệp. Người đánh giá cũng cần thiết để tìm ra những điểm mù quan trọng mà các công cụ tự động không thể kiểm tra.

1.2. Tại sao mã có lỗ hổng?

MITER đã liệt kê khoảng 1000 loại điểm yếu khác nhau của phần mềm trong dự án CWE. Đây là tất cả các cách khác nhau mà các nhà phát triển phần mềm có thể mắc lỗi dẫn đến mất an toàn. Tất cả những điểm yếu này đều tinh vi và nhiều điểm yếu nghiêm trọng. Các nhà phát triển phần mềm không được dạy về những điểm yếu này trong trường học và hầu hết không nhận được bất kỳ đào tạo về công việc về những vấn đề này.

Những vấn đề này đã trở nên rất quan trọng trong những năm gần đây vì chúng tôi tiếp tục tăng cường kết nối và thêm các công nghệ và giao thức với tốc độ cực nhanh. Khả năng phát minh ra công nghệ đã nghiêm túc vượt xa khả năng bảo mật nó. Nhiều công nghệ được sử dụng ngày nay chỉ đơn giản là chưa nhận đủ (hoặc bất kỳ) giám sát an ninh.

Có nhiều lý do khiến các doanh nghiệp không dành thời gian thích hợp cho việc bảo mật. Cuối cùng, những lý do này bắt nguồn từ một vấn đề tiềm ẩn trong thị trường phần mềm. Bởi vì phần mềm về bản chất là một hộp đen, khách hàng sẽ rất khó phân biệt giữa mã tốt và mã không an toàn mã. Không có khả năng hiển thị này, các nhà cung cấp không được khuyến khích chi thêm efort để tạo mã an toàn. Tuy nhiên, các chuyên gia bảo mật thông tin thường nhận được phản hồi khi họ ủng hộ việc xem xét mã bảo mật, với những lý do (không chính đáng) sau đây để không đưa thêm efort vào bảo mật:

 là một hoạt động đảm bảo chất lượng phần mềm trong đó một hoặc một số người kiểm tra chương trình chủ yếu bằng cách xem và đọc các phần của mã nguồn của nó và họ làm như vậy sau khi triển khai hoặc khi quá trình triển khai bị gián đoạn. Ít nhất một trong những người không được là tác giả của mã. Những người thực hiện việc kiểm tra, không bao gồm tác giả, được gọi là "người đánh giá". 

Kiếm việc làm

2. Sự khác biệt giữa Code Review và Secure Code Review là gì?  

Code Review là đánh giá chất lượng phần mềm còn Secure Code Review là đạnh giá chất lượng mã nguồn.   

Mô hình trưởng thành khả năng (CMM) là một mô hình quy trình được công nhận rộng rãi để đo lường các quy trình phát triển của một tổ chức phát triển phần mềm. Nó bao gồm từ "cấp độ 1" nơi các quy trình phát triển là đặc biệt, không ổn định và không thể lặp lại, đến 'cấp độ 5' nơi các quy trình phát triển được tổ chức tốt, được ghi lại và liên tục cải tiến. Giả định rằng các quy trình phát triển của một công ty sẽ bắt đầu ở cấp độ 1 khi bắt đầu (hay còn gọi là chế độ khởi động) và sẽ trở nên rõ ràng hơn, có thể lặp lại và thường chuyên nghiệp hơn khi tổ chức trưởng thành và cải tiến. Việc giới thiệu khả năng thực hiện xem xét mã (lưu ý rằng điều này chưa xử lý việc xem xét mã an toàn) được đưa vào khi tổ chức đã đạt đến cấp độ 2 (Có thể lặp lại) hoặc cấp độ 3 (Đã xác định rõ). 

Code Review là một sự cải tiến đối với thực tiễn Secure Code Review trong đó cấu trúc của quá trình xem xét đặt các cân nhắc bảo mật, chẳng hạn như tiêu chuẩn bảo mật của công ty, ở vị trí hàng đầu trong quá trình ra quyết định. Nhiều quyết định trong số này sẽ được giải thích và cố gắng đảm bảo rằng quá trình xem xét có thể bao gồm đầy đủ các rủi ro bảo mật trong cơ sở mã, ví dụ đảm bảo mã có rủi ro cao được xem xét sâu hơn, đảm bảo người đánh giá có bối cảnh bảo mật chính xác khi xem xét  mã, đảm bảo người đánh giá có các kỹ năng cần thiết và kiến ​​thức mã hóa an toàn để đánh giá mã một cách hiệu quả.  

Việc làm it phần mềm tại hà nội

3. Làm sao để code review một mã nguồn đảm bảo an toàn?  

Mức độ xem xét mã nguồn an toàn sẽ khác nhau tùy thuộc vào nhu cầu kinh doanh hoặc quy định của phần mềm, quy mô của tổ chức phát triển phần mềm viết ứng dụng và kỹ năng của nhân sự. Tương tự như các khía cạnh khác của phát triển phần mềm như hiệu suất, khả năng mở rộng và khả năng bảo trì, bảo mật là thước đo mức độ trưởng thành trong một ứng dụng. Bảo mật là một trong những yêu cầu phi chức năng cần được tích hợp vào mọi ứng dụng hoặc công cụ nghiêm túc được sử dụng cho mục đích thương mại hoặc chính phủ.

Nếu môi trường phát triển bao gồm một người lập trình theo sở thích và viết chương trình để theo dõi hoạt động mua sắm hàng tuần của họ bằng hình ảnh cơ bản (CMM cấp 1), thì không chắc rằng lập trình viên đó sẽ sử dụng tất cả các lời khuyên trong tài liệu này để thực hiện các cấp độ mở rộng của  đánh giá mã an toàn. Mặt khác, một tổ chức lớn với hàng nghìn nhà phát triển viết hàng trăm ứng dụng sẽ (nếu họ muốn thành công) sẽ rất coi trọng vấn đề bảo mật, giống như họ coi trọng hiệu suất và khả năng mở rộng. Không phải mọi tổ chức phát triển đều có nhu cầu hoặc nguồn lực để tuân theo và thực hiện tất cả các chủ đề trong tài liệu này, nhưng tất cả các tổ chức phải có thể bắt đầu viết các quy trình phát triển của mình theo cách có thể phù hợp với các quy trình và lời khuyên kỹ thuật quan trọng nhất.

Sau đó, các quy trình đó phải được mở rộng để đáp ứng nhiều hơn các cân nhắc xem xét mã an toàn khi tổ chức phát triển và trưởng thành. Trong một công ty khởi nghiệp gồm 3 người trong một căn phòng tối, sẽ không có 'nhóm đánh giá mã' để gửi mã đến, thay vào đó sẽ là một người trong góc đã đọc một cuốn sách mã hóa an toàn một lần và bây giờ sử dụng  nó để hỗ trợ màn hình của anh ấy. 

Trong một công ty có quy mô trung bình, có thể có 400 nhà phát triển, một số nhà phát triển quan tâm đến bảo mật, tuy nhiên, các quy trình của tổ chức có thể dành cùng một khoảng thời gian để xem xét thay đổi CSS 3 dòng vì nó cung cấp cho thiết kế lại mã xác thực sản phẩm hàng đầu  .  Ở đây, thách thức là nâng cao kiến ​​thức về mã hóa an toàn của lực lượng lao động (nói chung) và cải thiện các quy trình thông qua những thứ như mô hình hóa mối đe dọa và xem xét mã an toàn.  Đối với một số công ty lớn hơn với hàng nghìn nhà phát triển, nhu cầu bảo mật trong S-SDLC là lớn nhất, nhưng tính hiệu quả của quy trình có tác động đến điểm mấu chốt.

 Lấy ví dụ về một công ty lớn với 5.000 nhà phát triển. Nếu một thay đổi được áp dụng cho quy trình dẫn đến việc mỗi nhà phát triển mất thêm 15 phút mỗi tuần để thực hiện một nhiệm vụ, thì đột nhiên, toàn bộ công ty sẽ tăng thêm 1.250 giờ mỗi tuần, điều này dẫn đến việc cần thêm 30 nhà phát triển toàn thời gian  mỗi năm chỉ để đi đúng hướng (giả sử là 40 giờ một tuần).  

4. Tại sao cần phần code review?

Xem xét mã bảo mật có lẽ là kỹ thuật hiệu quả nhất để xác định sớm các lỗi bảo mật trong chu kỳ hệ thống đời phát triển. Khi được sử dụng cùng với kiểm tra thâm nhập tự động và thủ công, mã việc xem xét có thể làm tăng đáng kể tính hiệu quả về chi phí của một efort xác minh bảo mật ứng dụng.

Hướng dẫn này không quy định quy trình thực hiện xem xét mã bảo mật. Thay vào đó, nó cung cấp hướng dẫn về efort nên được cấu trúc và thực thi như thế nào. Hướng dẫn cũng tập trung vào cơ chế xem xét mã đối với các lỗ hổng nhất định. Đánh giá mã an toàn thủ công cung cấp thông tin chi tiết về “rủi ro thực sự” liên quan đến mã không an toàn. Theo ngữ cảnh này, cách tiếp cận hộp trắng là giá trị quan trọng nhất.

Người đánh giá có thể hiểu được mức độ liên quan của một lỗi hoặc lỗ hổng trong mã. Bối cảnh đòi hỏi sự hiểu biết của con người về những gì đang được đánh giá. Với bối cảnh thích hợp, chúng tôi có thể đưa ra một ước tính rủi ro nghiêm trọng giải thích cho cả khả năng bị tấn công và tác động kinh doanh của một vi phạm. Việc phân loại đúng các lỗ hổng giúp ưu tiên khắc phục và kết hợp những điều phù hợp thay vì lãng phí thời gian để tìm hiểu mọi thứ.

Mặc dù việc khám phá trực tiếp các vấn đề về chất lượng thường là mục tiêu chính, việc xem xét mã thường được thực hiện để đạt được sự kết hợp của các mục tiêu: 

- Chất lượng mã tốt hơn  - cải thiện chất lượng mã nội bộ và khả năng bảo trì (khả năng đọc, tính đồng nhất, dễ hiểu, ...)

- Tìm lỗi  - cải thiện chất lượng về các khía cạnh bên ngoài, đặc biệt là tính đúng đắn, nhưng cũng tìm ra các vấn đề về hiệu suất, lỗ hổng bảo mật, phần mềm độc hại được tiêm vào, ...

- Học tập - Chuyển giao kiến ​​thức  - giúp chuyển giao kiến ​​thức về cơ sở mã, các phương pháp tiếp cận giải pháp, kỳ vọng về chất lượng, v.v.; cho cả người đánh giá cũng như tác giả

- Tăng cường tinh thần trách nhiệm lẫn nhau  - nâng cao ý thức làm chủ tập thể và tinh thần đoàn kết

- Tìm kiếm các giải pháp tốt hơn  - tạo ra các ý tưởng cho các giải pháp mới và tốt hơn và các ý tưởng vượt qua mã cụ thể trong tầm tay.

- Tuân thủ các nguyên tắc QA  - Việc xem xét mã là bắt buộc trong một số bối cảnh.

Định nghĩa đánh giá mã đề cập ở trên phân biệt nó với các kỹ thuật đảm bảo chất lượng phần mềm lân cận nhưng riêng biệt: Trong phân tích mã tĩnh, việc kiểm tra chính được thực hiện bởi một chương trình tự động, trong kiểm tra tự động chỉ tác giả kiểm tra mã, trong kiểm tra việc thực thi mã là một phần không thể thiếu và lập trình cặp được thực hiện liên tục trong quá trình thực hiện và không phải là một bước riêng biệt.

Tìm việc làm it văn phòng

5. Quy trình đánh giá mã theo đúng tiêu chuẩn 

Có nhiều biến thể của quy trình xem xét mã cụ thể bao gồm các quy trình sau:

5.1. Kiểm tra chính thức 

Quá trình xem xét mã đầu tiên trong lịch sử đã được nghiên cứu và mô tả chi tiết được nhà phát minh Michael Fagan gọi là "Kiểm tra". Việc kiểm tra Fagan này là một quy trình chính thức bao gồm việc thực hiện cẩn thận và chi tiết với nhiều người tham gia và nhiều giai đoạn. Đánh giá mã chính thức là phương pháp đánh giá truyền thống, trong đó các nhà phát triển phần mềm tham dự một loạt cuộc họp và xem xét từng dòng mã, thường sử dụng các bản in của tài liệu. Việc kiểm tra chính thức là cực kỳ kỹ lưỡng và đã được chứng minh là có hiệu quả trong việc tìm ra các khiếm khuyết trong mã đang được xem xét.

5.2. Đánh giá mã dựa trên thay đổi thường xuyên 

Trong những năm gần đây, nhiều nhóm trong ngành đã giới thiệu một loại đánh giá mã nhẹ hơn. Đặc điểm chính của nó là phạm vi của mỗi bài đánh giá dựa trên những thay đổi đối với cơ sở mã được thực hiện trong một vé, câu chuyện người dùng, cam kết hoặc một số đơn vị công việc khác. Hơn nữa, có các quy tắc hoặc quy ước nhúng nhiệm vụ đánh giá vào quá trình phát triển (ví dụ: "mọi phiếu phải được xem xét"), thay vì lập kế hoạch rõ ràng cho mỗi lần xem xét. Quá trình xem xét như vậy được gọi là "xem xét mã thường xuyên, dựa trên thay đổi". 

Có nhiều biến thể của quá trình cơ bản này. Một cuộc khảo sát trong số 240 nhóm phát triển từ năm 2024 cho thấy 90% nhóm sử dụng quy trình đánh giá dựa trên các thay đổi (nếu họ sử dụng đánh giá hoàn toàn) và 60% sử dụng đánh giá mã dựa trên thay đổi thường xuyên. Ngoài ra, hầu hết các tập đoàn phần mềm lớn như Microsoft, Google, và Facebook đều tuân theo quy trình xem xét mã dựa trên thay đổi.

Nhìn chung Code Review là một quy trình quan trọng trong quá trình làm việc của các lập trình viên. Hy vọng rằng, những chia sẻ trên đã giúp bạn nắm vững được những thông tin về Code Review cùng vai trò quan trọng mà nó đảm nhiệm.

Tìm việc làm lập trình viên php