SonarQube Security: Bắt lỗi bảo mật trước khi lên production

Mình nhớ hồi đầu đi làm, team mình có một anh senior hay nói câu này: "Code chạy được chưa chắc code an toàn." Lúc đó mình gật đầu cho có, nhưng thực ra chưa hiểu hết ý. Mãi đến khi một cái bug XSS lọt lên production và khách hàng phát hiện ra trước team mình, mình mới thấm thía câu đó đau đến mức nào.

Đó là lý do mình muốn nói về SonarQube cụ thể là góc độ security, không phải chỉ là tool check code style hay đếm technical debt như nhiều người vẫn nghĩ.

SonarQube thực ra làm gì với security?

Nói ngắn gọn: SonarQube là một SAST platform Static Application Security Testing. Tức là nó đọc thẳng vào source code của bạn, không cần chạy app lên, và tìm kiếm các pattern nguy hiểm.

Khi bạn trigger một lần scan, flow cơ bản trông như thế này:

1. SonarQube đọc toàn bộ source code của project
2. Apply bộ security rules tương ứng với ngôn ngữ đang dùng (Java, C#, JavaScript, Python...)
3. Phát hiện các pattern code có nguy cơ cao
4. Gán severity level cho từng issue
5. Đẩy kết quả lên dashboard để team review và assign

Cái hay ở chỗ nó không chỉ đơn thuần là "tìm thấy bug rồi báo". Nó còn giúp bạn track tiến độ fix, prioritize theo mức độ nguy hiểm, và assign cho đúng người. Về mặt workflow, cái này cực kỳ có giá trị khi team đông người.

Những lỗ hổng cụ thể mà SonarQube bắt được

Đây là phần mình thấy thực tế nhất. Không phải lý thuyết suông đây là những thứ SonarQube sẽ flag trong codebase của bạn:

SQL Injection, OS Injection, LDAP Injection Những chỗ mà user input được nhét thẳng vào query hoặc command mà không qua validation hay parameterization. Cái này kinh điển nhưng vẫn hay bị bỏ sót, đặc biệt trong legacy code.

Cross-Site Scripting (XSS) Khi untrusted data được render thẳng ra browser mà không escape. Mình đã thấy cái này trong nhiều project React mà dev cứ tưởng framework đã lo hết rồi.

Sensitive data exposure Hard-coded passwords, API keys, credentials nằm ngay trong code. Cái này nghe có vẻ ngớ ngẩn nhưng mình đảm bảo nếu bạn scan một codebase đủ lớn và đủ cũ, sẽ tìm thấy ít nhất một cái.

Risky authentication practices Ví dụ store password dạng plain text, dùng thuật toán hash đã lỗi thời như MD5.

Dangerous API usage Những chỗ dùng deserialization không an toàn, hoặc xử lý untrusted data theo cách có thể bị exploit.

Một điểm mình thấy khá thông minh là SonarQube phân biệt rõ hai loại:

Cái Security Hotspot này mình thấy khá hay nó không alarm giả loạn xạ, mà thay vào đó flag những chỗ có thể là vấn đề và cần con người xem xét thêm. Giảm được noise đáng kể so với một số tool khác mình từng dùng.

SAST, SCA, DAST Ba thứ này khác nhau chỗ nào?

Đây là câu hỏi mình hay gặp khi thảo luận với anh em. Nhiều người nhầm lẫn hoặc nghĩ một tool là đủ.

SonarQube về cơ bản là SAST. Nhưng SonarSource đã mở rộng thêm với SonarQube Advanced Security để cover thêm phần SCA tức là analyze cả dependencies và third-party libraries bạn đang dùng.

SonarQube Advanced Security Khi nào cần đến?

Theo kinh nghiệm của mình, với các project nhỏ hoặc internal tool, SonarQube Community/Developer edition là đủ. Nhưng nếu bạn đang build một product thực sự, có users, có data nhạy cảm thì Advanced Security đáng để xem xét.

Lý do chính: một phần lớn risk trong ứng dụng hiện đại không đến từ code bạn tự viết, mà đến từ dependencies. Bạn npm install một cái package, cái package đó pull thêm 50 transitive dependencies nữa ai biết trong đó có CVE gì không?

Advanced Security giải quyết hai vấn đề chính:

SCA (Software Composition Analysis) Scan toàn bộ dependency tree, phát hiện CVE đã biết, malicious packages, và một số vấn đề về open-source license.

Advanced SAST với cross-boundary vulnerability detection Đây là cái mình thấy thực sự ấn tượng. Có những lỗ hổng không xuất hiện trong code của bạn, cũng không xuất hiện trong library riêng lẻ nhưng lại xuất hiện ở chỗ giao nhau giữa hai cái. Advanced SAST track data flow xuyên qua cả code của bạn lẫn third-party code để phát hiện loại scenario phức tạp này.

Anh em lưu ý: cross-boundary vulnerability là thứ cực kỳ khó detect bằng tay hoặc bằng code review thông thường. Đây là một trong những chỗ mà tool thực sự tạo ra sự khác biệt.

Tích hợp vào CI/CD Đừng để SonarQube chạy một mình

Một sai lầm mình hay thấy là team setup SonarQube xong rồi... để đó. Dev push code, SonarQube scan, ra kết quả, nhưng không ai nhìn vào dashboard. Sau vài tuần thì issue stack lên hàng trăm cái, không ai muốn tackle nữa.

Cách làm hiệu quả hơn là integrate SonarQube vào CI/CD pipeline với Quality Gates. Quality Gate là tập hợp các điều kiện mà code phải pass trước khi được merge hoặc deploy. Ví dụ:

• Không có vulnerability mới với severity Critical hoặc High
• Security Hotspot review rate phải trên 80%
• Không introduce thêm code smells quá một ngưỡng nhất định

Khi Quality Gate fail, pipeline dừng lại. Developer phải fix trước khi merge được. Cách này biến security check từ "việc của ai đó sau này" thành "blocking condition ngay bây giờ" đó mới là DevSecOps thực sự.

Theo kinh nghiệm của mình, lần đầu setup Quality Gate nên để threshold khá loose, rồi dần dần siết chặt hơn theo thời gian. Nếu ngay từ đầu bạn set quá strict trên một codebase cũ, pipeline sẽ fail liên tục và team sẽ tìm cách bypass thay vì fix.

Một vài điều thực tế khi dùng SonarQube

Cuối cùng mình muốn chia sẻ một số thứ mà documentation không hay nói đến:

SonarQube không phải silver bullet. Nó là SAST tức là nó chỉ thấy những gì có thể phân tích tĩnh từ code. Những lỗ hổng chỉ xuất hiện ở runtime, hoặc phụ thuộc vào environment config, thì nó sẽ không bắt được. Đó là lý do DAST vẫn cần thiết trong một security strategy toàn diện.

False positive là có thật. Đặc biệt với Security Hotspot đôi khi SonarQube flag những chỗ mà thực ra team đã handle đúng cách rồi. Cần có người đủ kiến thức để review và mark "acknowledged" thay vì chỉ dismiss cho xong.

Customize rules theo project. SonarQube cho phép bạn tạo custom quality profiles bật/tắt specific rules, thay đổi severity. Anh em đừng ngại làm điều này, vì default ruleset đôi khi không phù hợp với context của từng project.

Và quan trọng nhất: SonarQube chỉ có giá trị khi team thực sự hành động dựa trên kết quả của nó. Tool tốt đến đâu mà không có culture và process đi kèm thì cũng vô nghĩa.