Nghiên cứu tổng hợp công cụ phát hiện lỗi phần mềm để giảm cảnh báo sai

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LÊ THẾ HUY

NGHIÊN CỨU TỔNG HỢP CÁC CÔNG CỤ PHÁT HIỆN LỖI PHẦN
MỀM ĐỂ GIẢM CẢNH BÁO SAI

Ngành: Công nghệ thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 8480103.01

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS. TS. TRƯƠNG ANH HOÀNG

Hà Nội - 2020


1

MỤC LỤC
DANH MỤC HÌNH ẢNH .............................................................................................3
DANH MỤC BẢNG BIỂU ...........................................................................................4
DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT ..................................................5
LỜI CẢM ƠN ................................................................................................................6
LỜI CAM ĐOAN ..........................................................................................................7
Chương 1. GIỚI THIỆU ĐỀ TÀI VÀ CÁC CƠNG CỤ SỬ DỤNG PHÂN TÍCH
MÃ NGUỒN ...................................................................................................................8
1.1. Giới thiệu đề tài ................................................................................................8
1.2. Các công cụ được sử dụng trong nghiên cứu ................................................8

1.2.1.

Cơng cụ phân tích SonarQube ...............................................................8

1.2.2.

Cơng cụ phân tích HuntBugs ...............................................................12

1.2.3.

Cơng cụ phân tích PMD [6] .................................................................12

1.2.4.

Cơng cụ phân tích IntelliJ IDE ............................................................14

1.2.5.

Cơng cụ phân tích VCG [11] ................................................................18

1.2.6.

Cơng cụ phân tích SpotBugs [8] ..........................................................19

1.2.7.

Cơng cụ phân tích Infer .......................................................................19

1.3. Đánh giá hiệu suất ..........................................................................................21
1.4. Bộ thử nghiệm (Test Suite)............................................................................21

1.5. Các lớp yếu điểm(CWE) ................................................................................22
Chương 2. PHƯƠNG PHÁP VÀ TIẾN HÀNH THỰC NGHIỆM .........................23
2.1. Phương pháp nghiên cứu ..............................................................................23
2.1.1.

Chiến lược nghiên cứu .........................................................................23

2.1.2.

Phương pháp tạo dữ liệu ......................................................................23

2.1.3.

Phân tích dữ liệu ...................................................................................24

2.2. Tiến hành thử nghiệm ...................................................................................24
2.2.1.

Bộ dữ liệu kiểm thử Juliet phiên bản 1.3 ............................................24


2
2.2.2.

Q trình chạy cơng cụ ........................................................................28

2.2.3.

Tổng hợp dữ liệu ...................................................................................31

2.2.4.

Viết cơng cụ phân tích dữ liệu .............................................................32

2.2.5.

Thực hiện phân tích dữ liệu .................................................................33

Chương 3. KẾT QUẢ VÀ ĐÁNH GIÁ ......................................................................43
3.1. Kết quả ............................................................................................................43
3.1.1.

Phân tích khơng theo tiêu chuẩn CWE ...............................................43

3.1.2.

Phân tích theo từng danh mục chuẩn CWE .......................................43

3.1.3.

Phân tích tổ hợp cơng cụ khơng theo chuẩn CWE .............................45

3.1.4.

Phân tích tổ hợp theo chuẩn CWE ......................................................45

3.2. Đánh giá ..........................................................................................................48
3.2.1.

Phân tích khơng theo chuẩn CWE ......................................................48

3.2.2.

Phân tích theo chuẩn CWE ..................................................................49

Chương 4: KẾT LUẬN ...............................................................................................50
Tài liệu tham khảo .......................................................................................................51


3

DANH MỤC HÌNH ẢNH
Hình 1.1: 4 thành phần chính của SonarQube [1] ...........................................................9
Hình 1.2: Các ngơn ngữ SonarQube hỗ trợ ...................................................................10
Hình 1.3: Cách thức hoạt động của SonarQube ............................................................11
Hình 1.4: Lỗi NullPointer trước khi sửa ........................................................................15
Hình 1.5: Lỗi NullPointer sau khi sửa ...........................................................................15
Hình 1.6: Mã nguồn khơng được sử dụng (mã “chết”) .................................................16
Hình 1.7: Mã nguồn trước khi xử lý chuỗi ....................................................................16
Hình 1.8: Mã nguồn sau khi xử lý chuỗi .......................................................................16
Hình 1.9: Lỗi đặt vi pham quy tắc đặt tên biến .............................................................17
Hình 1.10: Vi phạm đặc điểm kỹ thuật EJB ..................................................................17
Hình 1.11: Sau khi đã sửa vi phạm kỹ thuật EJB ..........................................................18
Hình 2.1: Cấu trúc mã nguồn ........................................................................................25
Hình 2.2: Phương thức bad() .........................................................................................26
Hình 2.3: Lỗi SQL Ịnjection ..........................................................................................26
Hình 2.4: Phương thức goodG2B() ...............................................................................27
Hình 2.5: Phương thức goodB2G() ...............................................................................27
Hình 2.6: Các tiêu chí của SonarQube ..........................................................................28
Hình 2.7: Các tiêu chí của HuntBugs ............................................................................29

Hình 2.8: Các tiêu chí của PMD ....................................................................................29
Hình 2.9: Các tiêu chí của IntelliJ IDE..........................................................................30
Hình 2.10: Các tiêu chí của VCG ..................................................................................30
Hình 2.11: Các tiêu chí của SpotBugs ...........................................................................31
Hình 2.12: Các tiêu chí của Infer...................................................................................31
Hình 2.13: Chuẩn hóa dữ liệu đầu vào ..........................................................................32


4
Hình 2.14: Cú pháp lệnh trong Java. .............................................................................32
Hình 2.15: Tệp dữ liệu đầu vào của cơng cụ SonarQube ..............................................33
Hình 2.16: Ví dụ xác thực và kiểm sốt truy cập ..........................................................34
Hình 2.17: Ví dụ chất lượng mã nguồn .........................................................................35
Hình 2.18: Ví dụ quản lý luồng kiểm sốt.....................................................................35
Hình 2.19: Ví dụ mã nguồn có lỗi khơng mã hóa thơng tin mật khẩu ..........................36
Hình 2.20: Ví dụ mã hóa và tính ngẫu nhiên .................................................................36
Hình 2.21: Ví dụ xử lý lỗi..............................................................................................37
Hình 2.22: Ví dụ xử lý tệp tin ........................................................................................37
Hình 2.23: Ví dụ lỗi rị rỉ thơng tin ................................................................................38
Hình 2.24: Ví dụ khởi tạo và đóng tài ngun ..............................................................38
Hình 2.25: Ví dụ Injection .............................................................................................39
Hình 2.26: Ví dụ phần mềm độc hại..............................................................................40
Hình 2.27: Ví dụ phần mềm độc hại..............................................................................40
Hình 2.28: Mã nguồn gây ra lỗi NullPointer .................................................................41
Hình 2.29: Ví dụ xử lý con trỏ và tham chiếu ...............................................................41
Hình 2.30: Ví dụ trùng bản ghi của SonarQube ............................................................42
Hình 2.31: Ví dụ trùng bản ghi của HuntBugs ..............................................................42

DANH MỤC BẢNG BIỂU
Bảng 2.1: Bảng mẫu dữ liệu chuẩn hóa .........................................................................23

Bảng 3.1: Bảng dữ liệu phân tích đơn cơng cụ .............................................................43
Bảng 3.2: Bảng phân tích đơn cơng cụ theo chuẩn CWE .............................................43
Bảng 3.3: So sánh phân tích đơn cơng cụ và phân tích tổ hợp cơng cụ ........................49


5
Biểu đồ 3.1: Biểu đồ tính hiệu suất của từng công cụ ...................................................43

Từ viết tắt

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT
Thuật ngữ tiếng anh
Thuật ngữ tiếng việt

API

Application Programming Interface

Giao diện lập trình ứng dụng

DFA

Data Flow Analysis

Phân tích luồng dữ liệu

CWE

Common Weakness Enumeration

Liệt kê điểm yếu chung

OWASP

Open Web Application Security
Project

Là tổ chức phi lợi nhuận và
đưa ra chuẩn OWASP phục
vụ cho công việc pentest hiệu
quả và chi tiết

MISRA

Motor Industry Software Reliability
Association

Hiệp hội Độ tin cậy Phần
mềm Công nghiệp Động cơ

Abstract Syntax Tree

Cây cú pháp trừu tượng

AST


6
LỜI CẢM ƠN
Trước tiên học viên xin dành lời cảm ơn chân thành và sâu sắc đến thầy giáo,

PGS. TS. Trương Anh Hoàng và PGS. TS. Nguyễn Đức Anh – Hai thầy đã hướng dẫn,
chỉ bảo nhiệt tình và tạo điều kiện tốt nhất từ khi bắt đầu thực hiện đến khi kết thúc
cơng việc của mình.
Học viên xin dành lời cảm ơn chân thành đến các thầy cô khoa công nghệ thông
tin, trường Đại học Công Nghệ, ĐHQGHN đã tận tình đào tạo, cung cấp cho các kiến
thức vơ cùng quý và bổ ích trong suốt thời gian hai năm học tại trường. Các thầy cô
luôn đồng hành và tạo điều kiện cho tất cả học viên được nghiên cứu và học hỏi theo
nguyên vọng của bản thân.
Đồng thời học viên cũng dành lời cảm ơn chân thành đến gia đình, bạn bè, đồng
nghiệp ln động viên và bên cạnh trong suốt thời gian qua.


7
LỜI CAM ĐOAN
Học viên xin cam đoan rằng luận văn thạc sĩ công nghệ thông tin “Nghiên cứu
tổng hợp công cụ phát hiện lỗi phần mềm để giảm cảnh báo sai” là cơng trình nghiên
cứu riêng của bản thân khơng sao chép của người khác. Trong toàn bộ nội dung của
luận văn, những điều đã trình bày hoặc là của chính cá nhân học viên hoặc là tổng hợp
từ nhiều nguồn tài liệu. Tất cả các nguồn tài liệu tham khảo đều có xuất xứ rõ ràng và
hợp pháp.
Học viên xin chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho
lời cam đoan này.
Hà Nội, ngày ……tháng…..năm 2020
Học viên thực hiện

Lê Thế Huy


8

Chương 1. GIỚI THIỆU ĐỀ TÀI VÀ CÁC CÔNG CỤ SỬ DỤNG PHÂN
TÍCH MÃ NGUỒN
1.1. Giới thiệu đề tài
Hiện nay, chất lượng sản phẩm công nghệ ngày càng được yêu cầu cao cả đối
với nhà phát triển và người sử dụng. Đối với người sử dụng họ muốn một sản phẩm
trơn tru hạn chế lỗi hết mức có thể và đặc biệt phải thật sự bảo mật để đảm bảo an tồn
thơng tin của người sử dụng.
Cịn đối với nhà phát triển, họ quan tâm đến sản phẩm của mình làm ra đã thực
sự tốt chưa, đã kiểm soát được các vấn đề phát sinh như bảo mật, hiệu suất,… Bên
cạnh đó là sản phẩm đó có dễ dàng bảo trì và phát triển thêm module có dễ dàng
khơng? Để có thể trả lời cho các vấn đề trên thì nhà phát triển đã đưa vào phân tích mã
nguồn tĩnh trong từng giai đoạn để có thể nắm được các phát sinh. Vậy họ phân tích
mã nguồn tĩnh như nào để biết rằng trong các mã nguồn của mình có các sơ hở về bảo
mật, mã nguồn của mình đã đảm bảo tăng hiệu suất xử lý chưa, mã nguồn đã đạt các
chuẩn theo quy ước để dễ dàng bảo trì cho sau này chưa? Hiện nay có rất nhiều cơng
cụ hỗ trợ phân tích mã nguồn tĩnh để giúp các nhà phát triển có câu trả lời cho những
vấn đề trên. Trong phạm vi nghiên cứu luận văn có đề cập đến một số công cụ phổ
biến sau: SonarQube, SpotBugs, PMD, IntelliJ IDE, VCG, HuntBugs, Infer. Trong
luận văn sẽ phân tích kết quả của các cơng cụ đưa ra trên một số tiêu chí và từ đó đưa
ra đánh giá công cụ nào hiện nay đáp ứng tốt nhất để có thể giải quyết được các vấn đề
nêu trên của nhà phát triển. Khi sử dụng các công cụ độc lập thì sẽ đưa ra kết quả như
nào và khi kết hợp các cơng cụ lại thì chất lượng kiểm tra sẽ có cải thiện nhiều hơn
khơng? Trong phạm vi nghiên cứu các câu hỏi trên sẽ được trả lời và sẽ đưa ra những
gợi ý cho những người phát triển khi xây dựng một phần mềm.

1.2. Các công cụ được sử dụng trong nghiên cứu
Trong nghiên cứu 7 công cụ sau được lựa chọn: SonarQube, HuntBugs, PMD,
IntelliJ IDE, VCG, Spotbugs, Infer là các công cụ mã nguồn mở dùng để phân tích mã
nguồn tĩnh – Tức là phân tích mã nguồn đang ở trạng thái khơng hoạt động để từ đó
đưa ra các lỗi để khắc phục trước khi đưa ứng dụng vào chạy thực tế. Các công cụ này

ngoài việc sử dụng các chức năng được cung cấp người dùng có thể tích hợp các
plugin do chính mình phát triển để cải thiện hiệu suất phát hiện lỗi và phù hợp với
từng dự án thực tế. Các công cụ trên đều đang được sử dụng bởi các doanh nghiệp
hoặc là những cơng cụ đã đã có những thành tích nhất định trong sự phát triển phần
mềm của các doanh nghiệp từ các năm trước đây. Sau đây luận văn sẽ giới thiệu và đi
vào chi tiết từng cơng cụ.

1.2.1. Cơng cụ phân tích SonarQube
SonarQube (trước đây là Sonar) là một nền tảng nguồn mở được phát triển bởi
SonarSource để kiểm tra chất lượng mã nguồn đó thực hiện các đánh giá một cách tự
động. SonarQube sử dụng phương pháp phân tích tĩnh (static analysis of code) để phát
hiện lỗi, mã nguồn thừa khơng có tác dụng và lỗ hổng bảo mật trên 20 ngôn ngữ lập


9
trình. Là một nền tảng mã nguồn mở giúp nhà phát triển có thể kiểm tra chất lượng mã
nguồn của dự án.
SonarQube được viết bằng java nhưng hỗ trợ các ngôn ngữ khác nhau: PHP,
Ruby, Java (bao gồm cả Android), C#, JavaScript, TypeScript, C/C++, Kotlin, Go,
COBOL, PL/SQL, PL/I, ABAP, VB.NET, VB6, Python, RPG, Flex, Objective-C,
Swift, CSS, HTML, và XML và hỗ trợ các cơ sở dữ liệu để lưu trữ kết quả: MySql,
Postgresql.
SonarQube hỗ trợ trong dự án việc đánh giá mã nguồn theo các tiêu chuẩn của
từng ngôn ngữ có trong dự án. Bên cạnh đó có thể thực hiện những việc sau:
• Phát hiện lỗi: phát hiện mã nguồn khơng dùng đến, các mã nguồn bị trùng
lặp.
• Tính toán độ bao phủ của mã nguồn theo kiểm thử đơn vị (Unit test - Unittest coverage) – Đó là cách tính tốn trong kiểm thử hộp trắng đảm bảo rằng
tất cả các trường hợp trong mã nguồn đều được đảm bảo chạy qua khi chạy
thực tế.
• Tính tốn trong việc các mã nguồn được sử dụng mang tính tạm thời không

được tối ưu để sử dụng lại và dễ bảo trì mã nguồn của hệ thống (Technical
Debt) – Nghĩa là giải quyết vấn đề một cách nhanh chóng khơng theo quy
chuẩn chỉ quan tâm đến kết quả. Giả sử đúng ra một giá trị phải khai báo là
hằng số để sử dụng chung cho các trường hợp khác nhưng khi sử dụng lại
dùng luôn giá trị chứ không khai báo biến hằng số. Ví dụ đoạn mã nguồn như
sau: if (message == “Nhập thiếu thông tin”) {} thay vào đó có thể khai báo
một biến là hằng số trong một lớp java như là Constant.java: public static
final String MESSAGE = “Nhập thiếu thông tin”; Như vậy ở bất kỳ đâu cần
sử dụng biến MESSAGE đều có thể sử dụng và khi thay đổi giá trị chỉ cần
thay đổi ở một chỗ thay vì phải vào nhiều đoạn mã để thay đổi.
• So sánh chất lượng mã nguồn so với các lần kiểm tra trước.
• Phát hiện lỗ hổng bảo mật.
• Kiểm tra độ phức tạp của mã nguồn.
Sonar gồm 4 thành phần [1]:

Hình 1.1: 4 thành phần chính của SonarQube [1]
➢ Một máy chủ SonarQube bắt đầu với 3 tiến trình chính:
• Máy chủ web cung cấp giao diện người dùng sử dụng và quản lý các phiên
bản phân tích mã nguồn.


10
• Máy chủ tìm kiếm dựa trên Elasticsearch để sao lưu các tìm kiếm từ giao
diện người dùng.
• Máy chủ phụ trách xử lý các báo cáo phân tích mã nguồn và lưu chúng
vào cơ sở dữ liệu của SonarQube.
➢ Một cơ sở dữ liệu để lưu trữ:
• Cấu hình của SonarQube (bảo mật, cài đặt plugin,...).
• Ảnh chụp nhanh chất lượng của dự án, chế độ xem,...
➢ Nhiều plugin SonarQube được cài đặt trên máy chủ, có thể bao gồm ngơn

ngữ, SCM, tích hợp xác thực và quản trị.
➢ Một hoặc nhiều SonarScanners chạy trên máy chủ tích hợp liên tục và xây
dựng để phân tích dự án.
SonarQube Scanners là các plugin sẽ được chạy ở phía người dùng. Giúp thu
thập thông tin từ dự án, sinh các “thuộc tính" cho việc phân tích. Sau đó nó sẽ chạy bộ
phân tích SonarQube dựa trên các “thuộc tính” này. Tương ứng với mỗi công cụ quản
lý dựng (build management), sẽ có một Scanner tương ứng.
SonarQube Plugins bao gồm các plugin về ngơn ngữ lập trình, quản lý phiên
bản mã nguồn hoặc thậm chí là các plugin cho các cơng cụ phân tích mã nguồn khác
như PMD, FindBugs, jDepend, Android Lint, CheckStyle, WebDriver, ... Xem thêm
tại đây: />SonarQube hiện tại hỗ trợ cho 26 ngơn ngữ lập trình, do vậy sẽ có 26 plugin
tương ứng để phân tích mã nguồn cho loại ngơn ngữ đấy. Sau đây là hình ảnh minh
họa – hình 1.2:

Hình 1.2: Các ngơn ngữ SonarQube hỗ trợ
Một số kỹ thuật phân tích mã nguồn tĩnh bậc cao được sử dụng như: khớp mẫu
(pattern matching), phân tích luồng dữ liệu, thực thi tượng trưng. SonarQube công bố
các luật (rules) cho các ngôn ngữ này dựa theo các chuẩn nổi tiếng như CWE, SANS,
OWASP, MISRA, CERT. Các luật cho từng ngôn ngữ được định nghĩa ở trang
.


11
Cách thức hoạt động của SonarQube:

Hình 1.3: Cách thức hoạt động của SonarQube
• Sau khi các thơng tin dự án được quét, thu thập, xử lý ở máy khách (client).
• SonarQube Scanner sẽ gửi những thông tin này ở dạng tệp nén lên máy chủ
(server) thông qua các API mà máy chủ cung cấp. Ngay khi máy chủ nhận
được yêu cầu xử lý này, việc đầu tiên là SonarQube sẽ nạp toàn bộ mã nguồn

và các tệp đi kèm nhờ plugin ngôn ngữ. Sau mã nguồn được nạp xong, các
bộ phân tích sẽ lần lượt quét qua mã nguồn và tạo ra chỉ số đo lường hoặc
phát hiện các vấn đề. Các bộ phân tích được chia làm hai loại là sensor và
decorator. Sensor là các bộ phân tích có thể tự tạo ra và cập nhật các chỉ số từ
mã nguồn. Decorator là các bộ phân tích sử dụng chỉ số từ các sensor để
phân tích sinh ra các chỉ số ở mức cao hơn.
• Trong tồn bộ q trình, dữ liệu phân tích sẽ được lưu vào cơ sở dữ liệu ở
các bước: sau khi nhập bởi plugin ngơn ngữ, sau khi sensor phân tích, sau khi
decorator phân tích. Lúc này người dùng có thể kiểm tra kết quả phân tích
trên giao diện web.
Thay vì sử dụng trực tiếp các mã lỗi từ đã được định nghĩa sẵn từ các nguồn mở
như CWE, OWASP,... SonarQube đã tạo ra những mã lỗi của riêng mình bằng cách tự
tổng hợp lại từ nhiều nguồn khác nhau. Sau đó, các bộ lọc, bộ kiểm tra (luật) sẽ được
viết ra dựa trên các mã lỗi riêng như vậy. Các luật của Java được triển khai tại
org.sonar.java.checks.
Để kiểm tra các lỗi có trong một tệp dữ liệu, SonarQube sẽ có hai phương pháp
để thực hiện điều này [5]:
• Sử dụng cú pháp cây và API cơ bản (Using syntax trees and API basics):
Trước khi chạy bất kỳ quy tắc nào, SonarQube Java Analyzer phân tích tệp


12
Java đã cho và tạo ra cấu trúc dữ liệu tương đương: cú pháp cây (Syntax
Tree). Mỗi cấu trúc của ngơn ngữ Java có thể được biểu diễn bằng một thành
phần cụ thể cú pháp cây (Syntax Tree), chi tiết từng đặc điểm của nó. Mỗi
cấu trúc này được liên kết với một giao diện riêng mô tả rõ ràng tất cả các
đặc tính của nó. Khi tạo ra một luật, lớp IssuableSubscriptionVisitor sẽ được
thực thi, nó cung cấp các phương thức hữu ích để làm rõ các vấn đề cũng như
xác định chiến lược sẽ sử dụng khi phân tích một tệp. Nó dựa trên cơ chế
đăng ký (subscription mechanism), cho phép chỉ định loại cây mà luật này sẽ

phản ứng với. Các nút mà cần đảm bảo sẽ được duyệt được chỉ định bởi một
phương thức là nodesToVisit(). Từ đó SonarQube sẽ có được các thơng tin
để bắt đầu xác định các lỗi có trong mã nguồn hay thực thi các luật.
• Sử dụng API (Using semantic API): Ngoài việc thực thi các luật dựa vào dữ
liệu được cung cấp bởi cú pháp cây (syntax tree), thì SonarQube cung cấp
càng nhiều thông tin hơn liên quan đến mã nguồn thơng qua một mơ hình
ngữ nghĩa của mã. Tuy nhiên mơ hình này hiện chỉ hoạt động với mã nguồn
Java. Mơ hình ngữ nghĩa này cung cấp thơng tin liên quan đến từng ký hiệu
được thao tác. Ví dụ, đối với một phương thức, API ngữ nghĩa sẽ cung cấp
dữ liệu hữu ích như chủ sở hữu của phương thức, cơng dụng của nó, các loại
tham số và loại trả về của nó, ngoại lệ mà nó có thể ném,...

1.2.2. Cơng cụ phân tích HuntBugs
Cơng cụ phân tích mã Java bytecode dựa trên cơng cụ Procyon Compiler với
mục đích để thay thế FindBugs. Cơng cụ có thể chạy với maven, ant, gradle hoặc là
một plugin của Eclipse. Phiên bản mới nhất hiện nay là 0.0.11. Hiện tại dự án đã bị
hủy và không được hỗ trợ trong tương lai.
HuntBugs có một điểm yếu lớn là nó khơng thể qt được các lỗi mã nguồn
trong khi phát triển, chúng ta phải dựng hoặc đóng gói thì mới có thể qt được.
Việc tích hợp HuntBugs rất nhanh và dễ hiểu, việc quét các tệp lỗi và xuất ra
tệp báo cáo cũng rất nhanh, có thể xem kết quả ngay trên IDE tích hợp HuntBugs.
HuntBugs khơng như các cơng cụ khác và có hạn chế khi chỉ hỗ trợ quét lỗi dự án thực
hiện bằng ngôn ngữ Java.
Việc chạy công cụ HuntBugs giúp phát hiện một vài lỗi trong hệ thống nhưng
vẫn cịn rất nhiều lỗi khơng bị phát hiện. Ngồi ra do hiện nay công cụ HuntBugs đã
không được hỗ trợ trong tương lai nên rất khó phát triển thêm.

1.2.3. Cơng cụ phân tích PMD [6]
PMD (Programming Mistake Detector) là một cơng cụ mã nguồn mở phân tích
mã nguồn tĩnh để tìm ra các vấn đề trong mã nguồn giúp cải thiện chất lượng mã

nguồn. PMD hỗ trợ các ngôn ngữ sau JavaScript, PLSQL, Apex, Python, Java.
PMD có thể phát hiện một số lỗi sau trong mã nguồn:
• Thân rỗng trong các khối lệnh try/catch/finally/switch và if/while.
• Mã nguồn khơng được sử dụng với các biến toàn cục, tham số, các hàm
mang tính chất đóng gói (private methods).


13
• Các biểu thức q phức tạp, khơng cần thiết cho các câu lệnh điều kiện (if),
vòng lặp for và while.
• Tối ưu việc sử dụng String/String Buffer.
• Trùng lặp mã nguồn.
PMD plugins cho một số IDE sau: eclipse, NetBeans, IntelliJ, Maven,
JDeveloper, JBuilder, SonarQube. PMD plugins mới nhất có version 6.17.0.
Cách thức hoạt động:
1. Khi bắt đầu thực hiện chạy phân tích mã nguồn của dự án sẽ chạy vào lớp
chính (class main): net.sourceforge.pmd.PMD.
2. Truyền tham số cho dịng lệnh net.sourceforge.pmd.cli.PMDParameters.
Đồng thời tải tập tin bộ nhớ đệm (cache) để tăng cường việc phân tích.
3. Tải các bộ luật đã được định nghĩa sẵn hoặc do mình định nghĩa lại.
4. Xác định ngơn ngữ mình thực hiện phân tích. (Mỗi ngôn ngữ được hỗ trợ
một số bộ luật riêng hoặc giữa các ngơn ngữ có nhưng bộ luật trùng nhau).
5. Xác định các tệp (sử dụng thư mục nguồn đã cho, lọc theo phần mở rộng tệp
ngôn ngữ).
6. Chuẩn bị cho quá trình kết xuất kết quả.
7. Sắp xếp các tệp tin (file) theo tên.
8. Kiểm tra xem có thể sử dụng bộ nhớ đệm (cache) để thực việc phân tích (nếu
các quy tắc thay đổi thì việc làm trên sẽ không hợp lệ).
9. Chuẩn bị SourceCodeProcessor dựa trên cấu hình.
10. Phân tích các tệp tin (đơn luồng hoặc đa luồng) thực hiện trong

net.sourceforge.pmd.Processor.PMDRunnable:
Tạo luồng đầu vào
Gọi bộ xử lý mã nguồn net.sourceforge.pmd.SourceCodeProcessor:
• Xác định ngơn ngữ.
• Kiểm tra bộ nhớ đệm (cache) tệp đã được phân tích hay có sẵn.
• Phân tích mã nguồn. Kết quả là nút AST gốc.
• Ln ln chạy khách truy cập SymbolFacade. Nó xây dựng phạm vi,
tìm khai báo và tập qn.
• Chạy DFA (phân tích luồng dữ liệu – nếu có ít nhất một quy tắc yêu cầu)
để xây dựng biểu đồ luồng điều khiển và các nút luồng dữ liệu.
• Chạy TypeResolution (nếu có ít nhất một quy tắc u cầu).
• Chạy phân tích đa biến (nếu ít nhất một quy tắc yêu cầu).
• Thực hiện quy tắc luật:
✓ Trước tiên hãy chạy các quy tắc đã chọn cho cơ chế chuỗi quy tắc.
✓ Chạy tất cả các quy tắc khác và để chúng đi qua AST. Các quy tắc có
thể sử dụng bảng ký hiệu, thông tin độ phân giải và các nút DFA.
✓ Các quy tắc sẽ báo cáo các vấn đề được tìm thấy như vi phạm quy tắc
(Rule Violations).


14
11. Kết xuất các vi phạm được tìm thấy thành định dạng mong muốn (XML,
văn bản, HTML).
12. Phân tích bộ nhớ đệm lưu trữ.
13. Tùy thuộc vào số lượng vi phạm được tìm thấy, thốt với mã 0 hoặc 4.

1.2.4. Cơng cụ phân tích IntelliJ IDE
IntelliJ IDEA là cơng cụ nhằm tạo ra những dự án lập trình cho điện thoại hoặc
cho với khả năng mã hóa sâu sắc và điều hướng nhanh phần mềm còn cung cấp cho
người dùng một danh sách các biểu tượng và ký hiệu phục vụ trong cơng việc lập trình

của người dùng.
IntelliJ IDEA thực hiện phân tích dịng dữ liệu đầu vào của người dùng, phần
mềm phân tích lưu lượng dữ liệu để đốn biểu tượng thể loại thời gian phần mềm thực
hiện phân tích kịch bản được đưa vào của người dùng với các để xuất khác nhau tự
động thêm các lớp phôi để phù hợp với chương trình mà bạn đang làm việc.
IntelliJ IDEA là một IDE Java để phát triển các phần mềm máy tính. Cơng cụ
được phát triển bởi JetBrains (trước đây gọi là IntelliJ), nó được cấp phép Apache 2
cho phiên bản cộng đồng, và một phiên bản thương mại độc quyền. Cả hai có thể được
sử dụng cho phát triển thương mại.
Những tính năng chính:
• Lập trình các dự án cho điện thoại, java,…
• So sánh tìm kiếm các đoạn mã trùng nhau.
• Phân tích dữ liệu.
• Tìm kiếm nhanh chóng.
• Ứng dụng rộng rãi.
Ở vai trị là một cơng cụ phân tích mã nguồn tĩnh thì IntelliJ IDE có rất nhiều
ưu điểm vượt trội đáng chú ý. IntelliJ IDE cung cấp cho người sử dụng bản sửa lỗi
nhanh và thơng minh. Vì vậy chất lượng mã nguồn luôn được đảm bảo ngay từ đầu mà
không làm gián đoạn quá trình viết mã nguồn theo yêu cầu của hệ thống. Từ đó giúp
cho các lập trình viên làm việc hiệu quả và tiết kiệm thời gian. Với hơn 600 mã nguồn
kiểm tra tự động giúp người dùng dễ dàng phát hiện các điểm mâu thuẫn khác nhau.
IntelliJ IDE chia các lỗi mã nguồn thành các nhóm lỗi để có thể xử lý tùy theo mục
đích của các dự án khác nhau. Sau đây học viên sẽ giới thiệu các nhóm lỗi mà IntelliJ
IDE đang chia ra [9]:
• Tìm lỗi có thể xảy ra: IntelliJ IDE phân tích mã người dùng đang nhập và
có khả năng tìm và sửa các lỗi có thể xảy ra khơng phải là “lỗi biên dịch”
ngay tức thì. Đây là một ví dụ về tình huống như vậy:


15

Hình 1.4: Lỗi NullPointer trước khi sửa
Ở đây, điều kiện if đầu tiên có thể dẫn đến ngoại lệ NullPointer được ném vào
if thứ hai, vì khơng phải tất cả các tình huống đều được ở trạng thái tốt nhất.
Tại thời điểm này, thêm một xác nhận để tránh NullPointer bị ném trong thời
gian chạy ứng dụng.

Hình 1.5: Lỗi NullPointer sau khi sửa
• Định vị, xác định mã nguồn khơng được sử dụng: IntelliJ IDEA làm nổi
bật trong phần biên tập của cái gọi là mã “chết”. Đây là mã không bao giờ
được thực thi trong thời gian chạy ứng dụng. Có lẽ, bạn thậm chí khơng cần
phần mã này trong dự án của mình. Tùy thuộc vào tình huống, mã như vậy
có thể được coi là một lỗi hoặc như một phần thừa. Dù sao nó cũng làm giảm
hiệu suất ứng dụng và làm phức tạp quá trình bảo trì. Đây là một ví dụ. Cái
gọi là “điều kiện khơng đổi” - ví dụ như điều kiện khơng bao giờ được đáp


16
ứng hoặc luôn luôn là “đúng”. Trong trường hợp này, mã chịu trách nhiệm
không thể truy cập được và thực sự là mã khơng được sử dụng (mã “chết”).

Hình 1.6: Mã nguồn khơng được sử dụng (mã “chết”)
• Phát hiện các vấn đề hiệu suất: IntelliJ IDE gợi ý cho người dùng một cách
dễ dàng để giải quyết các vấn đề liên quan đến hiệu suất trong toàn bộ dự án.
IntelliJ IDE biết rất nhiều tình huống trong đó có một số mẫu được biết là
được thực hiện nhanh hơn bất kỳ mẫu nào khác. Vì vậy, nó có thể đề xuất
các giải pháp để tăng hiệu suất. Sau đây là một ví dụ về hoạt động của chuỗi:

Hình 1.7: Mã nguồn trước khi xử lý chuỗi
IntelliJ IDE gợi ý một số hành động để cải thiện hiệu suất của hoạt động chuỗi

này. Cách xử lý thứ 2 được chọn vì nó được biết là hoạt động nhanh hơn.

Hình 1.8: Mã nguồn sau khi xử lý chuỗi
• Cải thiện cấu trúc mã và khả năng bảo trì: IntelliJ IDE thực hiện phân tích
nhanh các phụ thuộc thơng qua một dự án, module hoặc gói, phát hiện chúng


17
và giúp bạn kiểm sốt các phụ thuộc thơng qua việc chia nhỏ mã của bạn
thành các module, sử dụng các phụ thuộc theo chu kỳ tạm thời, đánh dấu lỗi.
IntelliJ IDE cũng tìm kiếm các bản sao cấu trúc, ngay cả các bản sao “mờ”.
• Tuân thủ các hướng dẫn và tiêu chuẩn mã hóa: IntelliJ IDE cho phép tìm
ra các điểm mâu thuẫn khác nhau liên quan đến nhiều hướng dẫn và tiêu
chuẩn mã hóa, từ các tiêu chuẩn Java phổ biến đến bất kỳ tiêu chuẩn cụ thể
nào của cơng ty. Tất cả những nơi, ví dụ, tìm thấy sự khơng nhất qn của
Javadoc, đều được đánh dấu trong trình chỉnh sửa khi đang di chuyển. Sau
đây là ví dụ:

Hình 1.9: Lỗi đặt vi pham quy tắc đặt tên biến
Trong trường hợp này, dự án đã xác định rằng tất cả các hằng số trong dự án
phải bắt đầu bằng ký hiệu “_”. Bóng đèn màu vàng báo động rằng hằng số
không phù hợp với tiêu chuẩn riêng mà dự án đặt cho các tên như vậy.
IntelliJ IDE có thể giúp giải quyết vấn đề. Chỉ cần nhấn Alt + Enter và chọn
để đổi tên biểu tượng. Tất cả các cách sử dụng của biểu tượng này trong mã
cũng sẽ được đổi tên.
• Tn theo thơng số kỹ thuật: IntelliJ IDE nêu bật tất cả các vi phạm đặc
điểm kỹ thuật, như EJB, JSP, JSF,…. Không giống như sự mâu thuẫn về
nguyên tắc, vi phạm thông số kỹ thuật dẫn đến việc không thể triển khai ứng
dụng trên máy chủ. Đó là lý do tại sao điều quan trọng là phải tìm những địa
điểm mã như vậy ngay lập tức. Đây là một ví dụ:

Hình 1.10: Vi phạm đặc điểm kỹ thuật EJB
Theo đặc điểm kỹ thuật của EJB, phương thức “create” sẽ đưa ra ngoại lệ
tương ứng. IntelliJ IDE nêu rõ vi phạm này và đề xuất cách khắc phục nhanh
chóng. Nếu chúng tơi khơng khắc phục, ứng dụng sẽ khơng thể triển khai ở
phía máy chủ.


18

Hình 1.11: Sau khi đã sửa vi phạm kỹ thuật EJB
1.2.5. Cơng cụ phân tích VCG [11]
VCG là một cơng cụ đánh giá bảo mật tự động sử dụng với các ngơn ngữ
C/C++, Java, C#, VB và PL/SQL. VCG có một vài tính năng hy vọng sẽ hữu ích cho
bất kỳ ai tiến hành đánh giá bảo mật.
Ngoài việc thực hiện một số kiểm tra phức tạp hơn, nó cịn có một tệp cấu hình
cho mỗi ngơn ngữ về cơ bản cho phép bạn thêm bất kỳ chức năng xấu nào (hoặc văn
bản khác) mà bạn muốn tìm kiếm, chẳng hạn như trong danh sách chức năng bị cấm
của Microsoft, các hàm Java xử lý đầu vào của người dùng thực hiện ngay lập tức
(Execute Immediate) trong PL/SQL.
Bản thân ứng dụng xử lý các nội dung phức tạp (tràn bộ đệm, so sánh có dấu
hoặc chứa ký tự,...) vì vậy các tệp cấu hình được đề cập ở trên về cơ bản cung cấp
thêm một lớp kiểm tra bổ sung mà người dùng có thể muốn hoặc khơng và có thể sửa
đổi cho phù hợp.
Kết quả được xếp hạng theo mức độ nghiêm trọng để hỗ trợ người dùng trong
quá trình đánh giá.
Quá trình quét mã lỗi được thực hiện theo ba cách:
• Chỉ nhận xét - VCG cố gắng xác định bất kỳ nhận xét nào cho biết mã hỏng
hoặc chưa hoàn thành dựa trên danh sách khoảng 16 cụm từ thường xuất hiện
trong các nhận xét đó.

• Chỉ mã nguồn - VCG quét và báo cáo về các vấn đề bảo mật mã tiềm ẩn và
bất kỳ chức năng nguy hiểm nào,... từ tệp cấu hình nằm trong mã.
• Chỉ các chức năng nguy hiểm - VCG chỉ quét và báo cáo về bất kỳ chức
năng nguy hiểm nào,... từ tệp cấu hình được tìm thấy trong mã.
• Mã, chức năng nguy hiểm và nhận xét - Còn được gọi là quét toàn bộ trong
danh sách quét, đây là một quá trình quét kết hợp cả mã và chú thích bao
gồm tất cả những điều trên.
Tệp cấu hình tồn tại cho từng ngôn ngữ trong số sáu ngôn ngữ mà VCG quét.
Chúng cung cấp một lớp quét bổ sung để bổ sung cho các bản quét phức tạp được tích
hợp sẵn cho mỗi ngơn ngữ.
Phân tích mã trực quan sẽ được hiển thị khi quá trình quét kết thúc. Kết quả
được ghi vào ngăn kết quả theo thứ tự chúng đã được định vị. Kết quả có định dạng
sau:
• SEVERITY: Vấn đề về mã.
• Số dịng - Tên tệp.
• Mơ tả.


19

1.2.6. Cơng cụ phân tích SpotBugs [8]
SpotBugs là một chương trình sử dụng phân tích tĩnh để tìm lỗi trong mã Java.
Nó tìm kiếm các trường hợp “mẫu lỗi” - các trường hợp mã có khả năng bị lỗi. Nó
cũng là người kế thừa tinh thần của FindBugs, tiếp tục phát triển từ thời điểm mà nó đã
khởi nghiệp với sự hỗ trợ của cộng đồng.
Để sử dụng SpotBugs, bạn cần có mơi trường thời gian chạy tương thích với
Java phiên bản 1.8 trở lên. SpotBugs là nền tảng độc lập và được biết là chạy trên nền
tảng GNU/Linux, Windows và MacOS X. Phải có ít nhất 512 MB bộ nhớ để sử dụng
SpotBugs. Để phân tích các dự án rất lớn, nhiều bộ nhớ hơn có thể cần thiết.
SpotBugs được xây dựng bởi JDK8 và chạy trên JRE8 và các phiên bản mới

hơn. SpotBugs có thể quét mã bytecode (tệp lớp) được tạo bởi JDK 8 và các phiên bản
mới hơn. Tuy nhiên, hỗ trợ cho Java 11 và mới hơn vẫn đang thử nghiệm. Truy cập
trình theo dõi sự cố để tìm các sự cố đã biết. SpotBugs không hỗ trợ bytecode (tệp lớp)
được tạo bởi JDK lỗi thời như 10, 9, 7 và các phiên bản cũ hơn.
Một số lỗi mà SpotBugs tìm ra:
• BAD_PRACTICE: Vi phạm thực hành mã hóa được khuyến nghị và cần
thiết. Ví dụ bao gồm mã băm và các vấn đề bằng thành ngữ có thể sao chép,
ngoại lệ bị loại bỏ, các vấn đề có thể sắp xếp thứ tự và sử dụng sai finalize.
• Quốc tế hóa (I18N): Các lỗi mã liên quan đến quốc tế hóa và ngơn ngữ.
• MALICIOUS_CODE: Dễ bị tấn công từ các phần mềm độc hại. Được cài
cắm từ các sơ hở của phần mềm.
• Hiệu suất hoạt động (PERFORMANCE): phát hiện các mã lỗi làm cho
chương trình giảm hiệu suất: như thừa mã, mã trùng lặp, sử dụng các cấu trúc
dữ liệu làm tăng hiệu suất chương trình,… đều được phát hiện và cảnh bảo
cho người dùng.
1.2.7. Cơng cụ phân tích Infer
Infer là một công cụ mã nguồn mở được sử dụng bởi Amazon, Facebook,
Uber,… Chương trình có khả năng bắt lỗi trong mã nguồn thuộc ngơn ngữ
Java/C++/Objective-C.
Infer có thể bắt được một số lỗi:
• Gọi các con trỏ giá trị null.
• Lỗi sử dụng đối tượng giá trị null trong danh sách thuộc loại đầu vào là các
đối tượng (C++/Objective-C).
• Rị rỉ tài ngun và bộ nhớ.
• Vịng lặp trả lại (A -> B và B -> A dẫn đến đối tượng không bị xóa kể cả khi
tất cả con trỏ ở bên ngồi đã bị hủy).
• An tồn luồng.
• Các biến khởi tạo nhưng khơng được sử dụng (Dead variable).
• Nhiều luồng đợi khóa ngược nhau dẫn đến treo (Deadlock).

20
Infer là công cụ tập trung vào lỗi hệ thống về null và dữ liệu, do đó nó khơng có
thơng báo một số lỗi thơng dụng hơn như:
• Lỗi trỏ ra ngồi mảng (Array bounds errors).
• Chuyển đổi kiểu dữ liệu lỗi từ kiểu này sang kiểu khác (Cast exceptions).
• Dùng dữ liệu khơng ổn (Leaking of tainted data). Ví dụ int a=0, b=a+b.
• Nhiều luồng sửa vào cùng nguồn dữ liệu vào cùng lúc (Concurrency race
conditions).
Cách thức hoạt động [2, 7]:
• Phương pháp tìm lỗi của chương trình dựa trên hai lý thuyết về hệ thống
chương trình - Separation và Bi-abduction.
✓ Separation dựa vào việc phân tích chương trình thành các hoạt động con
xử lý trên dữ liệu và sau đó kết hợp lại tất cả các hoạt động con này thành
trạng thái để có thể xem xét cuối cùng.
✓ Bi-abduction là phương pháp tìm kiếm các phần cần thiết để thỏa mãn
các ước đoán mà chúng ta cần kiểm tra.
• Cấu trúc này cho phép chương trình phân tích các đoạn mã một cách độc lập
và ít tương tác với nhau, đồng nghĩa với việc khi một khu vực mã bị thay đổi,
chỉ có các ước đốn và trạng thái của khu vực đó trở đi bị ảnh hưởng, tăng
tốc độ kiểm tra mã. Điểm yếu của nó là ở chỗ phương pháp này chỉ có thể áp
dụng cho các loại lỗi thuộc về cấu trúc, chứ không thể sử dụng cho tất cả các
loại lỗi có thể được phát hiện (ví dụ truy cập ngồi kích cỡ của mảng, chuyển
đổi kiểu giá trị gây ngoại lệ).
• Trong hoạt động thực tế (khi sử dụng lên các mã C++/Java), hệ thống chạy
bằng câu lệnh tương ứng, lúc này các công cụ biên dịch của hệ thống (clang,
javac, ant, make,...) sẽ bị thay bằng biên dịch của Infer để chạy phân tích.
Infer có 2 giai đoạn thực hiện:
✓ Chiếm lấy (Capture): Ở bước này, mã của chương trình sẽ được tạo
thành các đồ thị và hoạt động như trên, sau đó dữ liệu đó được lưu lại

trên đĩa cứng. Thông thường dữ liệu này ở thư mục infer-out, nhưng có
thể chọn được một thư mục khác bằng lệnh option -o. Lý do để có bước
này là bởi vì Infer hỗ trợ việc chỉ kiểm tra khu vực bị thay đổi thay vì
tồn bộ chương trình, do đó, cần phải lưu trữ dữ liệu từ các bước trước.
✓ Phân tích (Analyze): Ở bước này, dữ liệu từ bước chiếm lấy (Capture) sẽ
được phân tích để tạo ra báo cáo cần thiết. Nếu chỉ chạy cho phần dữ liệu
bị thay đổi, Infer sẽ được chạy với option --reactive, đưa đến tốc độ
nhanh hơn. Dù là kiểm tra toàn bộ hay cục bộ, phân tích sẽ in ra thơng tin
lỗi và cảnh báo ra bàn điều khiển (console - stdout) và tệp inferout/bugs.txt ngồi ra, infer cũng có report.csv mang thơng tin trên dưới
dạng tệp excel, csv.


21

1.3. Đánh giá hiệu suất
Trong phạm vi nghiên cứu luận văn học viên thực hiện nghiên cứu với các chỉ số
đo hiệu suất vì đây là các chỉ số thường được sử dụng trong nghiên cứu trước đây. Các
chỉ số được định nghĩa như sau [3]:
TP (True Positive): Chỉ sổ này để thể hiện phát hiện chính xác lỗi trong mã
nguồn. Mã chứa lỗi được phát hiện và được đưa ra báo cáo chính xác.
TN (True Negative): Chỉ số này để thể hiện phát hiện đúng khơng có lỗi trong
mã nguồn. Khơng có bất kỳ một lỗi nào tồn tại trong mã nguồn và không lỗi nào được
báo cáo.
FN (False Negative): Chỉ số thể hiện có lỗi trong mã nguồn nhưng mã chứa lỗi
khơng được tìm ra và khơng được đưa vào báo cáo.
FP (False Positive): Chỉ số thể hiện phát hiện lỗi trong mã nguồn khơng chính
xác. Khơng có lỗi nào tồn tại trong mã, nhưng lỗi được báo cáo.
Recall (Độ bao phủ): Chỉ số thể hiện phần trăm lỗi được phát hiện trong tổng số
các mã lỗi được báo cáo. Cơng thức tính:
Recall = TP / (TP + FN)

Precision (Độ chính xác): Chỉ số thể hiện phần trăm mã lỗi được phát hiện đúng
là có lỗi thực sự. Tức là khơng phải trường hợp mã nguồn tìm ra là lỗi nhưng thực tế
mã nguồn khơng có lỗi. Cơng thức tính:
Precision = TP / (TP + FP)
Discrimination: Chỉ sổ thể hiện số lượng tệp chứa mã nguồn lỗi tìm đúng mã lỗi
(TP) không tồn tại bất kỳ một mã nguồn nào bị báo cáo sai lỗi (FP).
Discrimination Rate: Chỉ số thể hiện tỷ lệ phần trăm các trường hợp thử nghiệm
mà một cơng cụ phân tích phân biệt. Cơng cụ phân tích phân biệt một lỗi trong mã
nguồn nếu chỉ báo cáo một kết quả tích cực thực sự về nó (TP) - kết quả đó chính là
Discrimination, nhưng khơng có kết quả phát hiện lỗ hổng khơng chính xác (FP) trong
cùng một tệp mã nguồn đó. Được tính bằng công thức:
Discrimination Rate = Discrimination / (TP + FN)

1.4. Bộ thử nghiệm (Test Suite)
Để nghiên cứu 7 công cụ phân tích mã nguồn tĩnh, người đánh giá cần có phần
mềm cho các cơng cụ để phân tích. Có hai loại phần mềm để lựa chọn: tự nhiên và
nhân tạo. Phần mềm tự nhiên là phần mềm không được tạo ra để kiểm tra các cơng cụ
phân tích tĩnh. Các ứng dụng phần mềm nguồn mở, chẳng hạn như máy chủ web
Apache (httpd.apache.org) hoặc bộ OpenSSH (www.openssh.com) là những ví dụ về
phần mềm tự nhiên. Phần mềm nhân tạo chứa các sai sót có chủ đích và được tạo ra
đặc biệt để kiểm tra các cơng cụ phân tích mã nguồn tĩnh.
CAS (Center for Assured Software - là trung tâm cải thiện sự đảm bảo của phần
mềm được sử dụng, tăng mức độ tin cậy rằng phần mềm khơng có lỗi cố ý và không
chủ ý [3]) quyết định rằng lợi ích của việc sử dụng mã nhân tạo lớn hơn những bất lợi
và do đó tạo ra mã nhân tạo để nghiên cứu các cơng cụ phân tích tĩnh. CAS tạo mã
nguồn như một tập hợp các trường hợp thử nghiệm. Mỗi trường hợp thử nghiệm chứa


22
chính xác một lỗi có chủ đích và thường ít nhất một cấu trúc khơng sai sót tương tự

như lỗ hổng có chủ đích – Tức là mã nguồn khơng có một lỗi nào cả để đối lập và
phân biệt với mã nguồn có lỗi trong bộ dữ liệu kiểm thử. Các cấu trúc khơng sai sót
được sử dụng để xác định xem liệu các cơng cụ có thể phân biệt sai sót với khơng sai
sót hay khơng. Ví dụ: một trường hợp thử nghiệm minh họa một loại lỗ hổng tràn bộ
đệm. Mã lỗi trong trường hợp thử nghiệm chuyển cho hàm C strcpy một bộ đệm đích
nhỏ hơn chuỗi nguồn. Cấu trúc khơng sai sót chuyển một bộ đệm đích đủ lớn để
strcpy. Các trường hợp thử nghiệm do CAS tạo ra và được sử dụng để nghiên cứu các
cơng cụ phân tích tĩnh được gọi là bộ thử nghiệm Juliet. Chúng được công bố rộng rãi
thông qua Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST) tại
/>Bộ dữ liệu Juliet Testsuite phiên bản 1.3 được chọn để đưa vào thử nghiệm vì nó
khơng chỉ giới hạn ở 10 lỗ hổng hàng đầu không giống như tập dữ liệu kiểm tra mã
nguồn chuẩn OWASP (OWASP là viết tắt của Open Web Application Security Project
– là tổ chức phi lợi nhuận và đưa ra chuẩn OWASP phục vụ công việc pentest hiệu quả
và chi tiết). Ngoài ra, bộ thử nghiệm được thiết kế cho tất cả các điểm yếu và không
chỉ giới hạn ở các điểm yếu dựa trên web như OWASP. Một trong những mục tiêu để
phát triển bộ thử nghiệm Juliet là cho phép nghiên cứu thực nghiệm dựa trên các bộ
thử nghiệm lớn. Các nhà nghiên cứu đã bắt đầu sử dụng các phiên bản của bộ thử
nghiệm Juliet để đánh giá phân tích mã nguồn [4, 12]. Bộ thử nghiệm Juliet phiên bản
mới nhất (phiên bản 1.3) tổng hợp 64099 trường hợp thử nghiệm trong C/C++ và
28881 trường hợp thử nghiệm trong Java.

1.5. Các lớp yếu điểm(CWE)
CWE là viết tắt của Common Weakness Enumeration - bảng liệt kê yếu điểm
chung của phần mềm do cộng đồng phát triển. Mục đích là phục vụ như một tiêu
chuẩn chung cho những người làm việc với phần mềm. Sau đây sẽ là một vài ví dụ để
hiểu hơn về các lỗi được định nghĩa trong CWE:
Ví dụ 1: Tràn bộ đệm dựa trên ngăn xếp (CWE-121) và tràn bộ đệm dựa trên lớp
(CWE-122) đều được đặt trong lớp điểm yếu xử lý bộ đệm. Do đó, tất cả các trường
hợp thử nghiệm liên quan đến các mục 121 và 122 của CWE được ánh xạ tới lớp điểm
yếu xử lý bộ đệm.

Ví dụ 2: SQL Injection là một kỹ thuật chèn mã có thể phá hủy cơ sở dữ liệu. Có
câu lệnh sau để khi thực hiện yêu cầu đăng nhập từ một hệ thống website
SELECT * FROM Users WHERE UserId = 105; người tấn cơng có thể bổ sung câu
như sau để câu lệnh trên luôn luôn thực hiện Select * from users where userId = 105 or
1 = 1; kỹ thuật tấn công như trên được định nghĩa với mã là CWE-89 (SQL Injection).


23

Chương 2. PHƯƠNG PHÁP VÀ TIẾN HÀNH THỰC NGHIỆM
2.1. Phương pháp nghiên cứu
Trong phần này học viên sẽ tóm tắt phương pháp nghiên cứu. Trong đó bao gồm
chiến lược nghiên cứu, phương pháp tạo dữ liệu và phương pháp phân tích dữ liệu.

2.1.1. Chiến lược nghiên cứu
Trong luận văn sử dụng phương pháp nghiên cứu thực nghiệm cài đặt các công
cụ được đề cập đến ở chương 1: SonarQube, PMD, IntelliJ IDE, VCG, SpotBugs,
HuntBugs, Infer. Sử dụng bộ dữ liệu kiểm thử Juliet TestCase phiên bản 1.3 như trong
một nghiên cứu tương tự của ông Tosin và đồng nghiệp [10]. Trong nghiên cứu của
ơng Tosin có sử dụng các cơng cụ FindSecBugs, FindBugs, Lapse++, Jlint,
Commercial, SonarQube và sử dụng các chỉ số TP, FP, FN, Recall, Precision,
Discrimination, Discrimination Rate để đo hiệu suất phát hiện lỗi của các công cụ trên
nhưng ông chỉ dừng lại việc đánh giá khả năng phát hiện lỗi của các công cụ. Nhưng
trong luận văn học viên sử dụng 7 công cụ khác để thực hiện đánh giá phát hiện lỗi của
các công cụ qua các chỉ số như ông Tosin dùng trong nghiên cứu thông qua bộ dữ liệu
kiểm thử Juliet Testsuite 1.3. Từ đó để thấy khả năng phát hiện lỗi của các công cụ,
những nhược điểm của các công cụ và để cải thiện chất lượng sản phẩm khi dùng các
công cụ trên để thực hiện phân tích lỗi phần mềm trước khi đưa vào sử dụng. Để cải
thiện việc phát hiện lỗi thì kết hợp các cơng cụ nào để tương thích với từng dự án. Sau
khi cài đặt và phân tích bộ dữ liệu kiểm thử kết quả của từng công cụ được lưu dưới

dạng csv. Các tệp dữ liệu kết quả sẽ được phân tích như phần 2.1.2 để đưa vào công cụ
do học viên tự viết để thực hiện tính tốn các chỉ sổ TP, FP, FN, Recall, Precision,
Discrimination, Discrimination Rate trong trường hợp đơn công cụ và tổ hợp các cơng
cụ.
Trong luận văn sử dụng chính các cơng cụ họ dùng để nghiên cứu để có thể so
sánh được cơng cụ có cải tiến hơn trước khơng bằng cách thực hiện đúng như phương
pháp họ đang dùng để đưa ra kết quả như ngày hôm nay. Bên cạnh đó bổ sung thêm
các cơng cụ mới để có sự đánh giá khách quan và chính xác hơn lý thuyết đang được
sử dụng. Nghiên cứu các công cụ phân tích từ lịch sử ra đời, cách sử dụng, cách thức
hoạt động, ưu và nhược điểm của các công cụ.

2.1.2. Phương pháp tạo dữ liệu
Sử dụng các công cụ phân tích ứng dụng tĩnh được đề cập đến ở chương 1 để
phân tích thành các dữ liệu chuẩn lưu dưới dạng tệp .csv. Tất cả các tệp dữ liệu kết quả
sẽ có những định dạng khác nhau theo theo từng công cụ tùy chỉnh nhưng tất cả các
công cụ đều cho ra tệp kết quả có 3 trường sau là chung: đường dẫn tệp lỗi trong bộ dữ
liệu kiểm thử, lỗi từ dòng trong tệp, lỗi đến dòng trong tệp. Dựa vào điểm chung đó để
chuẩn hóa các tệp dữ liệu theo chuẩn sau – Bảng 2.1:
Đường dẫn tệp tin lỗi

Lỗi từ dịng

Bảng 2.1: Bảng mẫu dữ liệu chuẩn hóa

Lỗi đến dòng


24
Tất cả các tệp dữ liệu đều được chuẩn hóa để trở thành dữ liệu đầu vào cho các
bước phân tích tiếp theo.

2.1.3. Phân tích dữ liệu
Đưa các tệp dữ liệu chuẩn làm dữ liệu đầu vào phân tích theo các tiêu chí đã
được đề cập ở trên. Phân tích theo từng cơng cụ, phân tích bằng cách tổng hợp dữ liệu
từ các công cụ theo kiểu tổ hợp một cơng cụ kết hợp với các cơng cụ cịn lại, kết hợp
hai công cụ, kết hợp ba công cụ,... từ đó đưa ra tổ hợp các cơng cụ nào sẽ cho kết quả
khả quan nhất. Tổng hợp so sánh các kết quả dưới dạng bảng.
Từ các kết quả phân tích để đưa ra đánh giá, gợi ý cho các nhà phát triển khi
thực hiện phân tích dự án cần sử dụng những công cụ nào sao cho phù hợp để đạt được
chất lượng và đảm bảo về mặt chi phí vận hành.

2.2. Tiến hành thử nghiệm
Là phần chính trong luận văn. Học viên sẽ tiến hành phân tích triển khai và
phân tích hạn chế đối với các cơng cụ phân tích tĩnh được tích hợp trong các IDE
nhằm tìm ra các lỗ hổng bảo mật cũng như những khuyết điểm trong mã nguồn theo
một số chuẩn chung.
Cấu trúc luận văn như sau. Phần 2.2 giải thích cách tiếp cận của học viên để
thực hiện nghiên cứu và cung cấp kết quả để từ đó đưa ra những kết luận đối với
những sự phát triển phần mềm sau này để đảm bảo được chất lượng sản phẩm, cũng
như mức độ an toàn và bảo mật của sản phẩm. Một phần luận văn thực hiện nghiên
cứu và chọn lọc các công cụ phân tích tĩnh như đã trình bày các kiến thức liên quan
của các công cụ trong chương 1. Trong phần 2.2.1, thực hiện nghiên cứu và chọn bộ
dữ liệu kiểm thử Juliet phiên bản 1.3 dành cho các ngôn ngữ java.

2.2.1. Bộ dữ liệu kiểm thử Juliet phiên bản 1.3
Cấu trúc của mã nguồn được chia thành các thư mục tên của mỗi thư mục là đại
diện cho các lớp điểm yếu (CWE). Dưới đây là hình ảnh đại diện một vài thư mục nằm
trong bộ mã nguồn.