How Security Researchers Uncover Hidden Vulnerabilities

The rate of vulnerability reporting has been rapidly increasing over the past few years, yet attackers continue to exploit previously unknown flaws, enabling numerous successful malicious campaigns.

Many in the vulnerability management community are exploring new ways to enhance vulnerability research and discovery, particularly through the use of AI.

However, for now, these AI-powered methods are either supporting or complementing established methods of vulnerability discovery.

In this article, Infosecurity examines some of the most commonly used methods for detecting and identifying new vulnerabilities.

Vulnerability testers operate in one of three modes: black-box testing, white-box testing or gry-box testing. Here is what they mean:

• Black-box testing: vulnerability testing exercise during which testers have no prior knowledge of the system, just like in most real-world attacks
• White-box testing: vulnerability testing exercise during which testers have full access to source code, architecture and documentation
• Grey-box testing: vulnerability testing exercise during which testers have partial knowledge (e.g. credentials but no source code)

Static Application Security Testing (SAST) is a white-box testing method that analyses an application’s source code, bytecode, or binaries without executing the program.

Its primary goal is to identify security vulnerabilities early in the development lifecycle, such as SQL injection, buffer overflows, hardcoded secrets, insecure cryptographic practices and coding errors that could lead to exploits.

SAST is particularly useful for shift-left security, where security is integrated into the development process rather than treated as an afterthought.

SAST tools perform lexical, syntactic and semantic analysis of code to detect patterns associated with known vulnerabilities.

They often integrate with continuous integration/continuous delivery (CI/CD) pipelines, integrated development environment (IDEs), such as VS Code or IntelliJ, or version control systems (e.g. GitHub, GitLab) to provide real-time feedback to developers.

SAST does not require a running application and can therefore catch issues before deployment, reducing the cost and risk of fixes later in production.

Dynamic Application Security Testing (DAST) evaluates running applications (such as web apps, application programming interfaces (APIs), or microservices) by simulating real-world attacks from outside the system.

Unlike SAST, DAST does not require access to source code, making it ideal for black-box testing scenarios.

It detects vulnerabilities that only manifest when the application is executing, such as cross-site scripting (XSS), cross-site request forgery (CSRF), server misconfigurations and authentication flaws.

DAST tools send malicious payloads (e.g., SQL injection strings, malformed inputs) to the application and analyse responses for signs of vulnerabilities.

They can also crawl the application to discover hidden endpoints, APIs or parameters.

Since DAST tools operate in a live environment, they can identify runtime issues, such as session management flaws or insecure headers that SAST tools might miss.

Interactive Application Security Testing (IAST) bridges the gap between SAST and DAST by analysing applications during runtime while they process real or simulated attacks.

Unlike DAST, which only sees external behaviour, IAST uses agents or instrumentation embedded in the application to observe internal data flow, memory usage and execution paths. This makes it highly effective at detecting complex vulnerabilities (e.g. deserialization attacks, business logic flaws) with fewer false positives.

IAST tools monitor the application in real time as it interacts with test inputs from DAST tools, manual testers or automated tests, for instance.

They track how data moves through the system, identifying vulnerabilities like injection flaws, insecure direct object references (IDOR) and authentication bypasses.

IAST operates within the application, providing detailed context that can help developers resolve issues more quickly.

Network vulnerability scanning involves proactively probing networks, servers and devices for security weaknesses such as open ports, outdated software, misconfigurations and unpatched vulnerabilities.

Unlike application-focused testing (SAST/DAST), this method targets the underlying infrastructure (firewalls, routers, switches and services like SSH, FTP or RDP).

The goal of network scanning is to prevent unauthorized access, data breaches and lateral movement by attackers.

Network scanners send network requests to identify:

• Open ports
• Vulnerable services
• Default or weak credentials
• Misconfigured security controls

Typically, results are then compared against existing vulnerability databases to prioritize risks.

Container and cloud scanning focuses on securing modern infrastructure such as Docker images, Kubernetes clusters and cloud environments like Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP).

Unlike traditional network scanning, it addresses ephemeral, scalable and dynamic resources where vulnerabilities can be introduced through misconfigured cloud services, vulnerable base images or exposed secrets.

These tools perform a variety of tasks, including:

• Scanning container images for known vulnerabilities
• Checking Kubernetes manifests for insecure configurations
• Auditing cloud resources
• Detecting hardcoded secrets 

Fuzz testing (or fuzzing) is an automated technique that bombards an application with malformed, unexpected or random inputs to trigger crashes, memory leaks or vulnerabilities.

Its primary goal is to discover edge cases, buffer overflows and input validation flaws that could lead to remote code execution (RCE), denial-of-service (DoS) or information disclosure.

Fuzzers typically operate in two main modes:

1. Mutation-based fuzzing: Takes valid inputs and mutates them (for example, by inserting junk data)
2. Generation-based fuzzing: Creates new inputs from scratch based on grammar rules

When a crash occurs, fuzzers log the faulting input for debugging, often integrating with debuggers (GDB, WinDbg) or sanitizers (ASan, UBSan) to pinpoint the root cause.

Code review is a systematic examination of source code designed to identify security flaws, logical errors and compliance violations before they reach production.

It serves as a critical defence layer against vulnerabilities that automated static (SAST) or dynamic (DAST) testing might overlook, such as business logic flaws, backdoors or improper error handling.

The goals of code review are to enforce secure coding practices, reduce technical debt and prevent the introduction of exploitable weaknesses.

Code review can be conducted through manual inspection by human experts or automated tooling, with each approach offering distinct advantages.

Manual code review involves experienced developers or security auditors meticulously analysing code line by line to detect insecure functions, logical vulnerabilities (such as broken authentication flows or race conditions), hardcoded secrets (API keys, database credentials), and compliance gaps (e.g., improper data handling under GDPR).

This process is often embedded into collaborative workflows, such as pull request (PR) reviews in GitHub or GitLab, or conducted through pair programming sessions, where two developers jointly inspect code for quality and security.

In contrast, automated code review leverages specialized tools that scan codebases against predefined rulesets (e.g. OWASP guidelines, CWE listings) to flag known insecure patterns, anti-patterns and coding violations.

These tools can be integrated directly into IDEs, providing developers with real-time feedback as they write code. Alternatively, they can be embedded in CI/CD pipelines (e.g., GitHub Actions, Jenkins) to block unsafe code from merging into the main branch.

ADVERTISEMENT

Enjoyed this article? Make sure to share it!

Looking for something else?