ldhnam
Công nghệ, kinh tế, và những suy nghĩ rời rạc.Technology, economics, and scattered thoughts.
← DevSecOps← DevSecOps
DevSecOpsDevSecOps19 Th7, 2026Jul 19, 202622 phút đọc17 min read

Công cụ kiểm thử bảo mậtSecurity Testing Tools

Thuộc bộ kiến thức DevSecOps Roadmap.

Tổng quan

Các công cụ kiểm thử bảo mật (security testing tools) giúp một đội ngũ xác minh rằng những biện pháp phòng thủ mà họ nghĩ là đã xây dựng thực sự hoạt động — thay vì giả định rằng một rule firewall, một bộ validate input, hay một mức patch nào đó là đúng, ta chủ động thăm dò hệ thống theo cách một kẻ tấn công sẽ làm và quan sát kết quả thực tế. Trong bối cảnh DevSecOps, các công cụ này phục vụ ba mục đích:

  1. Tìm ra misconfiguration và lỗ hổng trước khi kẻ tấn công tìm ra — một port đáng lẽ phải đóng nhưng lại mở, một form web không sanitize input, một host thiếu bản patch quan trọng, một service vẫn dùng credential mặc định.
  2. Xác minh rằng các control hoạt động đúng như thiết kế — kiểm tra xem TLS có thực sự được enforce hay không, một rule WAF có thực sự chặn được payload độc hại hay không, một network segment có thực sự không thể truy cập từ internet hay không.
  3. Cung cấp phản hồi liên tục, lặp lại được — giống như unit test bắt được regression trong code, các đợt scan bảo mật định kỳ và tích hợp trong pipeline bắt được regression trong tư thế bảo mật (security posture) khi hạ tầng và code thay đổi theo thời gian.

Mọi nội dung trong bài này đều giả định có sự cho phép rõ ràng (explicit authorization). Việc scan, capture traffic, intercept request, hoặc dò tìm lỗ hổng trên bất kỳ hệ thống, mạng, hay ứng dụng nào bạn không sở hữu — hoặc không có sự cho phép bằng văn bản rõ ràng để kiểm thử — là bất hợp pháp ở hầu hết các quốc gia (ví dụ theo Computer Fraud and Abuse Act của Mỹ, Computer Misuse Act của Anh, và các luật tương đương ở nơi khác) và gần như chắc chắn dẫn đến sa thải ở mọi tổ chức, kể cả khi ý định là vô hại. Mọi ví dụ trong bài này được viết để chạy trên lab riêng của bạn, một môi trường staging đã được cho phép, hoặc một hệ thống có văn bản authorization/rules of engagement (RoE) bao trùm hoạt động đó. Xem phần Best Practices để biết cách scope hóa sự cho phép này trong thực tế.

Bài này tập trung vào các công cụ kiểm thử động (dynamic) — những công cụ tương tác với một hệ thống đang chạy (mạng, host, hoặc ứng dụng) theo cách một người dùng hoặc kẻ tấn công thực sự sẽ làm, đây chính là bản chất của DAST (Dynamic Application Security Testing) và kiểm thử bảo mật mạng/hạ tầng. Nội dung này bổ sung cho, chứ không thay thế, phân tích tĩnh (static) trên source code và dependency, được trình bày ở Secure Coding and Web Application Security (SAST, code review) và CI/CD and Supply Chain Security (SCA, pipeline gate). Các công cụ scan chuyên biệt cho container và Kubernetes (image scanner, admission controller) được trình bày sâu ở Container and Kubernetes Security; bài này chỉ giới thiệu ngắn gọn để làm bối cảnh.

Kiến thức nền tảng

Các nhóm công cụ kiểm thử bảo mật

Công cụ kiểm thử bảo mật đại khái rơi vào một vài nhóm, mỗi nhóm trả lời một câu hỏi khác nhau:

NhómCâu hỏi nó trả lờiCông cụ tiêu biểu
Reconnaissance / network scanningCó những host và service nào tồn tại, chúng được expose ra sao?Nmap, Masscan
Packet/traffic analysisĐiều gì đang thực sự diễn ra trên đường truyền — dữ liệu có được mã hóa không, giao thức có hoạt động đúng không?Wireshark, tcpdump
Web application testing (proxy/DAST)Ứng dụng web có xử lý input không tin cậy một cách an toàn tại runtime không?Burp Suite, OWASP ZAP
Vulnerability scanningNhững CVE hoặc misconfiguration đã biết nào tồn tại trên các host/service này?Nessus, OpenVAS, Qualys
Image/container scanningImage container hay IaC manifest này có chứa lỗ hổng đã biết hoặc cấu hình không an toàn không?Trivy, Grype, Clair (xem Container and Kubernetes Security)

Các nhóm này bổ sung cho nhau chứ không cạnh tranh — một đợt đánh giá thực tế thường kết hợp nhiều nhóm lại với nhau (xem Khái niệm chính → Các công cụ này khớp với SDLC ra sao).

Authorization là điều kiện tiên quyết, không phải chuyện làm sau

Trước khi đụng vào bất kỳ công cụ nào trong số này để nhắm vào thứ gì đó khác ngoài lab cá nhân, cần có sẵn ba thứ:

Phần này được mở rộng thêm ở Best Practices.

Khái niệm chính

Nmap — dò tìm mạng và quét cổng (port scanning)

Nmap (“Network Mapper”) là công cụ mã nguồn mở chuẩn để host discovery, port scanning, và service/version fingerprinting. Nó trả lời câu hỏi: cái gì đang “sống” trên mạng này, cổng nào đang mở, và cái gì đang lắng nghe trên chúng?

Các khả năng cốt lõi:

Một số câu lệnh ví dụ (chỉ chạy trên host/mạng bạn được phép quét):

# Chỉ host discovery — không port scan, chỉ tìm host đang sống trong subnet
nmap -sn 192.168.1.0/24

# Basic TCP connect scan trên 1000 cổng phổ biến nhất
nmap 192.168.1.10

# SYN ("half-open") scan trên một dải cổng cụ thể — cần quyền elevated
sudo nmap -sS -p 1-1000 192.168.1.10

# Service/version detection cộng thêm các NSE script mặc định (an toàn)
nmap -sV -sC 192.168.1.10

# Quét toàn bộ cổng (tất cả 65535)
nmap -p- 192.168.1.10

# Chạy nhóm script "vuln" của NSE để đánh dấu các dấu hiệu lỗ hổng đã biết
nmap --script vuln 192.168.1.10

Một vài lưu ý thực tế:

Wireshark — capture và phân tích gói tin

Wireshark là công cụ GUI chuẩn để capture và kiểm tra traffic mạng theo từng gói tin. Nếu Nmap cho bạn biết cái gì đang lắng nghe, thì Wireshark cho bạn biết thực sự cái gì đang được truyền tải trên đường dây.

Có hai loại filter khác nhau cần phân biệt:

Các display filter phổ biến:

FilterMục đích
ip.addr == 192.168.1.10Chỉ hiện traffic đến/từ một host cụ thể
tcp.port == 443Chỉ hiện traffic trên một cổng cụ thể
httpChỉ hiện HTTP request/response
http.request.method == "POST"Chỉ hiện HTTP POST request (thường mang dữ liệu form/login)
tcp.flags.syn == 1 && tcp.flags.ack == 0Chỉ hiện gói SYN ban đầu của TCP handshake
tls.handshake.type == 1Hiện gói TLS Client Hello (bắt đầu của TLS handshake)
ftp hoặc telnetHiện traffic FTP/Telnet — hữu ích để minh họa giao thức cleartext

Đọc TCP three-way handshake: filter theo tcp.port == 443 (hoặc cổng bất kỳ) vào lúc bắt đầu một kết nối và tìm chuỗi:

  1. Client → Server: SYN (client yêu cầu kết nối, đề xuất sequence number ban đầu)
  2. Server → Client: SYN, ACK (server xác nhận và đề xuất sequence number của riêng nó)
  3. Client → Server: ACK (client xác nhận; kết nối đã được thiết lập)

Wireshark gắn nhãn các gói này trong cột Info là [SYN], [SYN, ACK], [ACK], giúp dễ dàng nhận ra ba bước này bằng mắt.

Phát hiện plaintext credential (và vì sao TLS quan trọng): trên một giao thức không mã hóa — HTTP (không phải HTTPS), FTP, Telnet, hay một service nội bộ vô tình bỏ qua TLS — credential hiển thị dưới dạng cleartext cho bất kỳ ai có thể quan sát traffic (một mạng Wi-Fi dùng chung, một switch bị compromise, một span port bị cấu hình sai). Ví dụ, capture một lượt login FTP và filter theo ftp.request.command == "PASS" sẽ lộ ra mật khẩu ở dạng chữ nguyên văn trong panel chi tiết gói tin; capture một form HTTP submit (http.request.method == "POST") và dùng Follow → HTTP Stream sẽ lộ ra giá trị các field của form, bao gồm cả login credential, dưới dạng plaintext. Đây chính xác là rủi ro mà TLS (HTTPS) loại bỏ: một khi traffic được mã hóa, Wireshark chỉ hiện ciphertext mù mờ (thấy được trong các frame filter theo tls) trừ khi bạn nắm private key hoặc secret giải mã — đây là lý do vì sao enforce TLS ở mọi nơi, kể cả traffic service-to-service nội bộ, là một control cơ bản, không phải tùy chọn. Việc demo điều này trên một VM lab có server Telnet hoặc FTP là cách phổ biến và an toàn để làm rõ luận điểm “TLS quan trọng” với đội ngũ.

Burp Suite — intercepting proxy cho kiểm thử ứng dụng web

Burp Suite (của PortSwigger) là công cụ chuẩn mực trong ngành cho kiểm thử bảo mật ứng dụng web thủ công và bán tự động. Về mặt khái niệm, nó đóng vai trò một proxy nằm giữa trình duyệt của bạn và ứng dụng đích, nên mọi request và response đều đi qua nó và có thể được kiểm tra, chỉnh sửa, và gửi lại — dưới sự cho phép, nhắm vào một ứng dụng bạn được phép kiểm thử.

Các thành phần cốt lõi (ở mức khái niệm — bài này không đi sâu vào các kỹ thuật khai thác):

Lựa chọn thay thế miễn phí, mã nguồn mở với mô hình proxy/scanning tương tự là OWASP ZAP, ngoài ra còn hỗ trợ tự động hóa CI/CD mạnh (chế độ scan “baseline” và “full” chạy headless, được thiết kế để chạy trong pipeline).

Giá trị thực tế của một công cụ dựa trên proxy như Burp/ZAP trong DevSecOps là nó kiểm thử ứng dụng theo đúng cách một client thực sự làm — sau khi JavaScript phía client đã chạy, sau khi logic routing/API gateway đã được áp dụng, với session state thực — điều mà chỉ phân tích source code tĩnh không thể tái hiện đầy đủ. Nó là đối tác DAST tự nhiên của SAST và dependency scanning được trình bày ở Secure Coding and Web Application Security.

Vulnerability scanner: Nessus, OpenVAS, Qualys

Vulnerability scanner tự động hóa quy trình kiểm tra host, network service, và (ở một số sản phẩm) ứng dụng web dựa trên một cơ sở dữ liệu lớn, được cập nhật liên tục về lỗ hổng đã biết (CVE) và các mẫu misconfiguration. Thay vì kiểm thử thủ công từng vấn đề đã biết, scanner chạy hàng ngàn kiểm tra và báo cáo cái nào khớp.

ScannerNhà cung cấp / licenseGhi chú
NessusTenable — thương mại (có bản “Essentials” miễn phí cho scope nhỏ)Được dùng rộng rãi; feed plugin (check) lớn, cập nhật thường xuyên; mạnh về compliance/benchmark scanning
OpenVAS / Greenbone Vulnerability ManagementGreenbone — lõi mã nguồn mởFeed do cộng đồng đóng góp, miễn phí tự host, phù hợp làm baseline cho lab và tổ chức nhỏ
QualysQualys — thương mại, cloud/SaaSMạnh ở quy mô enterprise/fleet lớn, continuous asset inventory, dịch vụ PCI-DSS Approved Scanning Vendor (ASV)

Các khái niệm cốt lõi chung cho các công cụ này:

Các vulnerability scanner khớp với pipeline DevSecOps ra sao:

Image và container scanning (điểm qua ngắn gọn)

Việc scan image container (và các IaC manifest triển khai chúng) để tìm base image layer, package đã biết có lỗ hổng, và cấu hình không an toàn (ví dụ: chạy dưới quyền root, secret bị bake cứng vào layer) là một mảng liên quan nhưng khác biệt, thường được thực hiện bằng các công cụ như Trivy, Grype, hay Clair, thường như một pipeline gate trước khi một image được phép push lên registry hoặc deploy. Nội dung này được trình bày sâu, bao gồm cả admission control và runtime scanning đặc thù cho Kubernetes, ở Container and Kubernetes Security.

Các công cụ này khớp với SDLC ra sao

Một mô hình tư duy hữu ích là xác định mỗi cách tiếp cận kiểm thử hoạt động ở đâu trong vòng đời:

Cách tiếp cậnKiểm thử cái gìChạy khi nàoTrình bày ở
SAST (static analysis)Source code, không cần thực thiTại thời điểm commit / pull requestSecure Coding and Web Application Security
SCA (software composition analysis)Dependency bên thứ ba để tìm CVE đã biết và vấn đề licenseTại thời điểm build / commitCI/CD and Supply Chain Security
Image/IaC scanningImage container và IaC manifestTại thời điểm build, trước khi push/deployContainer and Kubernetes Security
DAST (bài này: Burp/ZAP, vulnerability scanner, kiểm thử hỗ trợ bởi Nmap/Wireshark)Một ứng dụng, host, hoặc mạng đang chạyNhắm vào staging (hoặc production, với kiểm soát chặt chẽ) sau khi deployBài này

DAST và SAST bổ sung cho nhau chứ không thay thế: SAST có thể phát hiện một mẫu code có lỗ hổng chưa bao giờ được thực thi ở runtime trong test hiện tại, trong khi DAST có thể phát hiện một lỗ hổng chỉ xuất hiện qua tương tác giữa nhiều thành phần (routing, middleware authentication, reverse proxy) mà phân tích tĩnh một file đơn lẻ không thể thấy được. Một pipeline DevSecOps trưởng thành chạy cả hai, đối chiếu kết quả, và coi sự đồng thuận giữa hai loại là tín hiệu mạnh để ưu tiên xử lý.

Bảng so sánh

Công cụNhómUse case điển hình
NmapReconnaissance / network scanningHost discovery, liệt kê cổng mở, service/version fingerprinting
WiresharkPacket/traffic analysisKiểm tra gói tin chuyên sâu, troubleshoot giao thức, xác minh mã hóa có thực sự được dùng
Burp SuiteWeb application (proxy / DAST)Kiểm thử thủ công và bán tự động input handling, authorization, session management của web app
OWASP ZAPWeb application (proxy / DAST)Lựa chọn mã nguồn mở thay thế Burp, hỗ trợ mạnh tự động hóa pipeline CI/CD
NessusVulnerability scannerScan host/network dựa trên CVE, kiểm toán benchmark compliance
OpenVAS / GreenboneVulnerability scannerScan CVE mã nguồn mở, tự host cho lab và môi trường nhỏ
QualysVulnerability scanner (cloud/SaaS)Continuous asset scanning quy mô enterprise, scan PCI-DSS ASV
Trivy / Grype / ClairImage/container scanningScan CVE và misconfiguration của image container và IaC trước khi deploy

Best Practices

Tài liệu tham khảo

Part of the DevSecOps Roadmap knowledge base.

Overview

Security testing tools let a team verify that the defenses they think they built actually work — instead of assuming a firewall rule, an input validator, or a patch level is correct, you probe the system the way an attacker would and observe the real result. In a DevSecOps context, these tools serve three purposes:

  1. Finding misconfigurations and vulnerabilities before attackers do — an open port that should be closed, a web form that doesn’t sanitize input, a host missing a critical patch, a service still using a default credential.
  2. Verifying that controls work as designed — confirming that TLS is actually enforced, that a WAF rule actually blocks a malicious payload, that a firewall segment really is unreachable from the internet.
  3. Providing continuous, repeatable feedback — the same way unit tests catch regressions in code, periodic and pipeline-integrated security scans catch regressions in security posture as infrastructure and code evolve.

Everything in this note assumes explicit authorization. Scanning, capturing traffic, intercepting requests, or probing for vulnerabilities on any system, network, or application you do not own — or do not have clear, written permission to test — is illegal in most jurisdictions (e.g., under the U.S. Computer Fraud and Abuse Act, the UK Computer Misuse Act, and equivalent laws elsewhere) and is a firing offense in virtually every organization, even when the intent is benign. Every example in this note is meant to be run against your own lab, a sanctioned staging environment, or a system with a signed authorization/rules of engagement covering the activity. See Best Practices for how that authorization should be scoped in practice.

This note focuses on dynamic testing tools — tools that interact with a running system (network, host, or application) the way a real user or attacker would, which is the essence of DAST (Dynamic Application Security Testing) and network/infrastructure security testing. This complements, but does not replace, static analysis of source code and dependencies, covered in Secure Coding and Web Application Security (SAST, code review) and CI/CD and Supply Chain Security (SCA, pipeline gates). Container and Kubernetes-specific scanning tools (image scanners, admission controllers) are covered in depth in Container and Kubernetes Security; this note only introduces them briefly for context.

Fundamentals

Categories of security testing tools

Security testing tools roughly fall into a handful of categories, each answering a different question:

CategoryQuestion it answersRepresentative tools
Reconnaissance / network scanningWhat hosts and services exist, and how are they exposed?Nmap, Masscan
Packet/traffic analysisWhat is actually happening on the wire — is data encrypted, is a protocol behaving correctly?Wireshark, tcpdump
Web application testing (proxy/DAST)Does the web application handle untrusted input safely at runtime?Burp Suite, OWASP ZAP
Vulnerability scanningWhich known CVEs or misconfigurations exist on these hosts/services?Nessus, OpenVAS, Qualys
Image/container scanningDoes this container image or IaC manifest contain known vulnerabilities or insecure configuration?Trivy, Grype, Clair (see Container and Kubernetes Security)

These categories are complementary, not competing — a real assessment typically chains several of them together (see Key Concepts → How these tools fit together).

Authorization is a prerequisite, not an afterthought

Before touching any of these tools against anything other than a personal lab, three things should exist:

This is expanded further in Best Practices.

Key Concepts

Nmap — network discovery and port scanning

Nmap (“Network Mapper”) is the standard open-source tool for host discovery, port scanning, and service/version fingerprinting. It answers: what is alive on this network, what ports are open, and what is listening on them?

Core capabilities:

Example commands (run only against hosts/networks you are authorized to scan):

# Host discovery only — no port scan, just find live hosts on a subnet
nmap -sn 192.168.1.0/24

# Basic TCP connect scan of the most common 1000 ports
nmap 192.168.1.10

# SYN ("half-open") scan of a specific port range — requires elevated privileges
sudo nmap -sS -p 1-1000 192.168.1.10

# Service/version detection plus default (safe) NSE scripts
nmap -sV -sC 192.168.1.10

# Scan every port (all 65535)
nmap -p- 192.168.1.10

# Run NSE's "vuln" script category to flag known vulnerability signatures
nmap --script vuln 192.168.1.10

A few practical notes:

Wireshark — packet capture and analysis

Wireshark is the standard GUI tool for capturing and inspecting network traffic packet-by-packet. Where Nmap tells you what is listening, Wireshark tells you what is actually being said on the wire.

Two different kinds of filters matter:

Common display filters:

FilterPurpose
ip.addr == 192.168.1.10Show only traffic to/from a specific host
tcp.port == 443Show only traffic on a specific port
httpShow only HTTP requests/responses
http.request.method == "POST"Show only HTTP POST requests (often carrying form/login data)
tcp.flags.syn == 1 && tcp.flags.ack == 0Show only the initial SYN packets of TCP handshakes
tls.handshake.type == 1Show TLS Client Hello packets (start of a TLS handshake)
ftp or telnetShow FTP/Telnet traffic — useful for illustrating cleartext protocols

Reading a TCP three-way handshake: filter on tcp.port == 443 (or whatever port) at the start of a connection and look for the sequence:

  1. Client → Server: SYN (client requests a connection, proposes an initial sequence number)
  2. Server → Client: SYN, ACK (server acknowledges and proposes its own sequence number)
  3. Client → Server: ACK (client acknowledges; connection is now established)

Wireshark labels these in the Info column as [SYN], [SYN, ACK], [ACK], making the three steps easy to pick out visually.

Spotting plaintext credentials (and why TLS matters): on an unencrypted protocol — HTTP (not HTTPS), FTP, Telnet, or an internal service that mistakenly skips TLS — credentials are visible in cleartext to anyone who can observe the traffic (a shared Wi-Fi network, a compromised switch, a misconfigured span port). For example, capturing an FTP login and filtering on ftp.request.command == "PASS" reveals the literal password in the packet detail pane; capturing an HTTP form submission (http.request.method == "POST") and using Follow → HTTP Stream reveals form field values, including login credentials, in plain text. This is precisely the risk TLS (HTTPS) eliminates: once traffic is encrypted, Wireshark shows only opaque ciphertext (visible in tls filtered frames) unless you hold the private key or a decryption secret, which is why enforcing TLS everywhere — including internal service-to-service traffic — is a baseline control, not an optional one. Demonstrating this on a lab VM with a Telnet or FTP server is a common, safe way to make the “TLS matters” case concrete to a team.

Burp Suite — intercepting proxy for web application testing

Burp Suite (by PortSwigger) is the industry-standard tool for manual and semi-automated web application security testing. Conceptually, it sits as a proxy between your browser and the target application, so every request and response passes through it and can be inspected, modified, and replayed — under authorization, against an application you’re permitted to test.

Core components (at a conceptual level — this note does not walk through exploit techniques):

The free, open-source alternative with a similar proxy/scanning model is OWASP ZAP, which additionally has strong CI/CD automation support (a headless “baseline” and “full” scan mode designed to run inside pipelines).

The practical value of a proxy-based tool like Burp/ZAP in DevSecOps is that it tests the application the way a real client does — after client-side JavaScript has run, after routing/API gateway logic has applied, with real session state — which static source analysis alone cannot fully replicate. It is the natural DAST counterpart to the SAST and dependency scanning covered in Secure Coding and Web Application Security.

Vulnerability scanners: Nessus, OpenVAS, Qualys

Vulnerability scanners automate the process of checking hosts, network services, and (in some products) web applications against a large, continuously updated database of known vulnerabilities (CVEs) and misconfiguration patterns. Instead of manually testing for every known issue, a scanner runs thousands of checks and reports which ones matched.

ScannerVendor / licenseNotes
NessusTenable — commercial (free “Essentials” tier for small scope)Widely used; large, frequently updated plugin (check) feed; strong compliance/benchmark scanning
OpenVAS / Greenbone Vulnerability ManagementGreenbone — open source coreCommunity-driven feed, free to self-host, good baseline for labs and smaller organizations
QualysQualys — commercial, cloud/SaaSStrong at enterprise/large-fleet scale, continuous asset inventory, PCI-DSS Approved Scanning Vendor (ASV) service

Key concepts common to these tools:

How vulnerability scanners fit into a DevSecOps pipeline:

Image and container scanning (brief pointer)

Scanning container images (and the IaC manifests that deploy them) for known-vulnerable base image layers, packages, and insecure configuration (e.g., running as root, exposed secrets baked into a layer) is a related but distinct discipline, typically performed with tools like Trivy, Grype, or Clair, often as a pipeline gate before an image is allowed to be pushed to a registry or deployed. This is covered in depth, including Kubernetes-specific admission control and runtime scanning, in Container and Kubernetes Security.

How these tools fit into the SDLC

A useful mental model is where in the lifecycle each testing approach operates:

ApproachWhat it testsWhen it runsCovered in
SAST (static analysis)Source code, without executing itAt commit / pull request timeSecure Coding and Web Application Security
SCA (software composition analysis)Third-party dependencies for known CVEs and license issuesAt build time / commit timeCI/CD and Supply Chain Security
Image/IaC scanningContainer images and infrastructure-as-code manifestsAt build time, before push/deployContainer and Kubernetes Security
DAST (this note: Burp/ZAP, vuln scanners, Nmap/Wireshark-assisted testing)A running application, host, or networkAgainst staging (or production, with strict controls) after deploymentThis note

DAST and SAST are complementary rather than substitutes: SAST can find a vulnerable code pattern that never gets exercised at runtime in current tests, while DAST can find a vulnerability that only manifests through the interaction of multiple components (routing, authentication middleware, a reverse proxy) that static analysis of one file can’t see. A mature DevSecOps pipeline runs both, correlates their findings, and treats agreement between the two as a strong signal for prioritization.

Comparison table

ToolCategoryTypical use case
NmapReconnaissance / network scanningHost discovery, open port enumeration, service/version fingerprinting
WiresharkPacket/traffic analysisDeep packet inspection, protocol troubleshooting, verifying encryption is actually in use
Burp SuiteWeb application (proxy / DAST)Manual and semi-automated testing of web app input handling, authorization, session management
OWASP ZAPWeb application (proxy / DAST)Open-source alternative to Burp with strong CI/CD pipeline automation
NessusVulnerability scannerCVE-based host/network scanning, compliance benchmark auditing
OpenVAS / GreenboneVulnerability scannerOpen-source CVE scanning, self-hosted labs and smaller environments
QualysVulnerability scanner (cloud/SaaS)Enterprise-scale continuous asset scanning, PCI-DSS ASV scans
Trivy / Grype / ClairImage/container scanningCVE and misconfiguration scanning of container images and IaC before deploy

Best Practices

References