Vulnerability Scanning -- Quiz

Question 1 of 6

A security manager is explaining vulnerability management to a new analyst. The analyst asks: "Why do we run vulnerability scans instead of just doing penetration tests? Aren't they the same thing?" Which answer correctly describes the key difference?

They are functionally identical — vulnerability scans and penetration tests both attempt to exploit vulnerabilities to confirm they exist Vulnerability scanning is minimally invasive and identifies potential weaknesses without exploiting them; penetration testing actively exploits vulnerabilities and can cause service disruption — they answer different questions at different risk levels Vulnerability scanning is more thorough than penetration testing because it tests the actual exploitability of every finding, while pen testing only identifies potential issues without confirmation Penetration testing is always required before a vulnerability scan because the scan needs the pen test results to know which systems to target

Question 2 of 6

A security team performs monthly external vulnerability scans and remediates all findings promptly. They believe their vulnerability management program is complete. Six months later, incident responders discover an attacker has been operating inside the network for weeks, using a rogue wireless access point connected to an internal network jack. The external scans never detected it. What is the most accurate explanation for this gap?

The external scanner was misconfigured and missed the access point because its IP was not in the scan scope; correcting the scope would have found it The access point had a stealth mode that prevented external scanners from detecting it; only specialized wireless intrusion detection can find such devices External scans only cover internet-facing systems and cannot detect unauthorized devices inside the network perimeter; internal vulnerability scanning is required to identify such devices External scanners do not detect wireless devices by design; the team should have used a dedicated wireless scanner instead of a general vulnerability scanner

Question 3 of 6

A vulnerability scanner returns a Critical-severity finding on a production database server: a known remote code execution vulnerability in the database engine version currently installed. The security engineer investigates and determines that while the version number matches the vulnerable version in the CVE database, the vendor applied a backported security patch three months ago that closes the specific vulnerable code path. The finding is a false positive. What is the correct next action?

Apply the patch immediately anyway — a Critical finding should never be dismissed without remediation regardless of investigation findings Document the finding as a verified false positive, record the backported patch as the reason, and remove it from the active remediation queue — no operational change is needed Report the scanner as defective and replace it, since Critical findings should never produce false positives Defer the finding to the next patch cycle; since it is likely a false positive, it does not need verification documentation

Question 4 of 6

A development team uses SAST integrated into their CI/CD pipeline. A developer implements a new feature that uses AES encryption to protect sensitive data stored in the database. The SAST scan completes without flagging any findings related to the encryption code. However, a later security review reveals that the implementation uses AES in ECB mode — a mode that does not provide semantic security and leaks patterns in encrypted data. Why did SAST miss this?

SAST tools do not scan encryption-related code by default; a separate cryptography-specific scanner must be configured to detect cipher mode issues SAST identifies code patterns associated with known vulnerable functions and deprecated algorithms, but cannot evaluate whether the correct algorithm is used correctly — AES is not deprecated, so SAST did not flag the insecure mode selection The SAST tool was not configured with a cryptography rule set; enabling the optional crypto plugin would have detected the ECB mode usage SAST tools cannot analyze compiled bytecode where cryptographic operations occur; source-level SAST would have detected it if the source code were available

Question 5 of 6

A security engineer submits tens of thousands of malformed HTTP requests to a web application's file upload endpoint, including requests with oversized filenames, null bytes in path parameters, and files with mismatched MIME types and content. After 6,000 iterations, a specific combination causes the application to return an unhandled exception with a full stack trace. Which of the following best describes what the security engineer is doing, and what the stack trace indicates?

The engineer is performing SAST; the stack trace indicates the static analysis found a runtime code path that requires remediation The engineer is performing a penetration test; the stack trace is the intended output confirming that the target system has been compromised The engineer is performing fuzzing (dynamic analysis); the stack trace is an anomalous response indicating a gap in the application's input handling that an attacker could seek to exploit The engineer is performing a port scan; the stack trace reveals which network services are running on the target and their version numbers

Question 6 of 6

A software development organization uses dozens of open-source libraries in its main application. On a Monday morning, a critical CVE is published against version 1.8.2 of a JSON processing library — the exact version installed in production. The organization's security team is notified within 20 minutes of the CVE publication and begins assessment immediately. Without any additional context, which capability most likely made this rapid notification possible?

SAST integration — the static analysis tool scanned the library's source code at the time of CVE publication and automatically alerted the security team Continuous package monitoring — a tool tracking all installed dependency versions against CVE databases detected the newly published CVE matched an installed package version and triggered an automated alert External vulnerability scanning — the scheduled external scan ran within 20 minutes of the CVE publication and detected the vulnerable library on the internet-facing server Fuzzing — the fuzzing framework detected anomalous behavior in the JSON library that matched the CVE description and generated an alert

Matching

ndash;10. Match each vulnerability management scenario to the technique it best represents.

1. A security team probes the organization's public-facing infrastructure from an internet connection with no prior network access — checking which ports are reachable from outside, which services are running and at what version, and whether those services match any entries in the CVE database. The results show two internet-facing servers running end-of-life operating systems.

2. A security team runs a scan from inside the corporate network and discovers 14 devices that are not in the asset inventory: six personal laptops, five smart TVs in conference rooms, and three network-attached storage devices installed by individual departments. None of these devices are visible from the internet and none would appear in an external scan.

3. A security engineer feeds a running REST API thousands of automatically generated malformed inputs, including oversized strings, negative integers in quantity fields, and JSON structures with hundreds of levels of nesting. After 8,000 iterations, a specific deeply nested input causes the API to crash and return a stack trace revealing the underlying framework version. The engineer documents this as a potential denial-of-service vulnerability requiring input depth validation.

4. A financial services firm uses a tool that maintains a real-time inventory of all open-source dependencies installed across its applications, cross-referenced against vulnerability databases. When a new CVE is published for any library version present in production, the tool immediately generates an alert to the security team identifying which applications are affected and the severity of the finding.

1. 2. 3. 4.

A. External vulnerability scan

B. Internal vulnerability scan

C. Fuzzing

D. Package monitoring

Vulnerability Scanning — Quiz

Matching