0 / 10 flipped
Concept
What is the critical distinction between vulnerability scanning and penetration testing?
Answer
Vulnerability scanning: Identifies the potential for an attack — checks for open ports, unpatched versions, misconfigurations. Does NOT exploit. Minimally invasive; production-safe. Answers: "where are the weaknesses?"
Penetration testing: Actively exploits identified vulnerabilities to confirm they are real and assess attacker impact. Intentionally invasive; can crash services and modify data. Answers: "are these weaknesses actually exploitable?"
Scan = reconnaissance. Pen test = attack simulation. Both are valuable; different risk profiles and different questions.
Penetration testing: Actively exploits identified vulnerabilities to confirm they are real and assess attacker impact. Intentionally invasive; can crash services and modify data. Answers: "are these weaknesses actually exploitable?"
Scan = reconnaissance. Pen test = attack simulation. Both are valuable; different risk profiles and different questions.
Concept
What does a port scan tell you, and what does it NOT tell you?
Answer
What a port scan tells you: Which TCP/UDP ports are open, which services are listening, service software and version numbers.
What it tells you about attack surface: Every open port is a potential entry point — attack surface mapping.
What it does NOT tell you: Whether those services are actually vulnerable. An open port is not inherently a vulnerability — it requires the running service to have a weakness.
Analogy: A port scan answers "what doors exist?" Vulnerability scanning then asks "which doors have broken locks?"
What it tells you about attack surface: Every open port is a potential entry point — attack surface mapping.
What it does NOT tell you: Whether those services are actually vulnerable. An open port is not inherently a vulnerability — it requires the running service to have a weakness.
Analogy: A port scan answers "what doors exist?" Vulnerability scanning then asks "which doors have broken locks?"
Concept
Why are both internal AND external vulnerability scans required?
Answer
External scan — simulates outside attacker; covers internet-facing services (web servers, VPN gateways, public APIs). Shows what an attacker with no prior access can see and reach.
Internal scan — simulates insider or post-breach attacker; covers devices not internet-facing (workstations, printers, databases), unauthorized devices, shadow IT, internal-only services.
The fatal assumption: "We have a firewall, so internal scanning is optional." Wrong — insiders, compromised credentials, and post-breach lateral movement all operate from inside. External scanning cannot detect them. Both scans are required for complete coverage.
Internal scan — simulates insider or post-breach attacker; covers devices not internet-facing (workstations, printers, databases), unauthorized devices, shadow IT, internal-only services.
The fatal assumption: "We have a firewall, so internal scanning is optional." Wrong — insiders, compromised credentials, and post-breach lateral movement all operate from inside. External scanning cannot detect them. Both scans are required for complete coverage.
Term
False Positive — what it is, why it happens, and what the correct response is
Definition
A scanner finding that investigation reveals is NOT an actual vulnerability.
Why it happens: Scanners use pattern matching and version-number comparisons. They may flag a service as vulnerable because the version number matches a CVE database entry, even if the specific vulnerable code path has been separately patched or is not reachable in this environment.
Correct response: Verify against the actual system before scheduling remediation. Acting on a false positive (patching something not vulnerable) causes operational disruption with no security benefit.
Key point: False positives are expected, not scanner failures. Triage is the required skill.
Why it happens: Scanners use pattern matching and version-number comparisons. They may flag a service as vulnerable because the version number matches a CVE database entry, even if the specific vulnerable code path has been separately patched or is not reachable in this environment.
Correct response: Verify against the actual system before scheduling remediation. Acting on a false positive (patching something not vulnerable) causes operational disruption with no security benefit.
Key point: False positives are expected, not scanner failures. Triage is the required skill.
Concept
What are SAST's strengths AND its documented limitations in vulnerability management?
Answer
Strengths: Finds vulnerabilities in code before deployment; integrates into CI/CD for automatic scanning on every commit; identifies buffer overflows, SQL injection patterns, hardcoded credentials, deprecated crypto calls. Cost of fix is minimal when caught early.
Limitations (exam-tested):
• Cannot find authentication design flaws (session predictability, race conditions in auth flows)
• Cannot find improper crypto implementation (correct algorithm, wrong mode/key management)
• Cannot find business logic vulnerabilities
• High false positive rate — every finding requires human judgment
• Requires source code access (or bytecode/binary in some tools)
Limitations (exam-tested):
• Cannot find authentication design flaws (session predictability, race conditions in auth flows)
• Cannot find improper crypto implementation (correct algorithm, wrong mode/key management)
• Cannot find business logic vulnerabilities
• High false positive rate — every finding requires human judgment
• Requires source code access (or bytecode/binary in some tools)
Term
Four synonyms for fuzzing — what connects them?
Definition
All four describe the same core technique: submitting unexpected input to observe application behavior.
• Fuzzing — the primary term; random/malformed input generation
• Fault injection — deliberately injecting invalid conditions to trigger faults
• Robustness testing — testing how the application handles adversarial or edge-case conditions
• Negative testing — testing with inputs outside the expected valid range (vs. positive testing with valid inputs)
• Syntax testing — submitting inputs that violate expected format or protocol structure
If a question describes "submitting malformed input to observe crashes or errors," the answer is fuzzing regardless of the synonym used.
• Fuzzing — the primary term; random/malformed input generation
• Fault injection — deliberately injecting invalid conditions to trigger faults
• Robustness testing — testing how the application handles adversarial or edge-case conditions
• Negative testing — testing with inputs outside the expected valid range (vs. positive testing with valid inputs)
• Syntax testing — submitting inputs that violate expected format or protocol structure
If a question describes "submitting malformed input to observe crashes or errors," the answer is fuzzing regardless of the synonym used.
Concept
What does a fuzzer look for, and why does an anomalous response indicate a potential vulnerability?
Answer
What fuzzers monitor for: Application crash or segfault, unhandled exception with stack trace, HTTP 500 server error when 400 was expected, memory corruption indicators, timeout or freeze, unexpected output (data leak).
Why anomalous response = potential vulnerability: The crash or error reveals a code path that was not designed to handle the input gracefully. An attacker submitting the same input would trigger the same condition — and an attacker who can trigger a crash can often control what happens next (buffer overflow, code execution).
Dynamic requirement: Fuzzing requires the application to be running. It finds runtime vulnerabilities that static analysis cannot see.
Why anomalous response = potential vulnerability: The crash or error reveals a code path that was not designed to handle the input gracefully. An attacker submitting the same input would trigger the same condition — and an attacker who can trigger a crash can often control what happens next (buffer overflow, code execution).
Dynamic requirement: Fuzzing requires the application to be running. It finds runtime vulnerabilities that static analysis cannot see.
Term
Fuzzing history — three exam-tested facts
Definition
Year: 1988
Institution: University of Wisconsin
Person: Professor Barton Miller
Course: "Operating System Utility Program Reliability"
Project: The "Fuzz Generator" — a class project demonstrating that random input reliably exposed reliability and security flaws in UNIX utilities
Significance: Established fuzzing as a formal methodology that is now foundational to both security research and software quality testing
Modern extension: CERT Basic Fuzzing Framework (BFF) — Carnegie Mellon University; structured, accessible fuzzing environment for organizational use
Institution: University of Wisconsin
Person: Professor Barton Miller
Course: "Operating System Utility Program Reliability"
Project: The "Fuzz Generator" — a class project demonstrating that random input reliably exposed reliability and security flaws in UNIX utilities
Significance: Established fuzzing as a formal methodology that is now foundational to both security research and software quality testing
Modern extension: CERT Basic Fuzzing Framework (BFF) — Carnegie Mellon University; structured, accessible fuzzing environment for organizational use
Concept
What are the two dimensions of software supply chain risk?
Answer
Dimension 1 — Known vulnerabilities in dependencies: A third-party library included in production has a CVE published against it, but the development team is unaware and does not update. The application remains exposed indefinitely. Package monitoring addresses this by alerting when a CVE is published for any installed dependency version.
Dimension 2 — Malicious packages: An attacker publishes a package with a name similar to a legitimate one (typosquatting), or compromises a legitimate package repository to inject malicious code. Any application that installs the package installs the attacker's code.
Mitigations: Digital signatures, hash validation, repository authentication, lab testing before production, continuous CVE monitoring.
Dimension 2 — Malicious packages: An attacker publishes a package with a name similar to a legitimate one (typosquatting), or compromises a legitimate package repository to inject malicious code. Any application that installs the package installs the attacker's code.
Mitigations: Digital signatures, hash validation, repository authentication, lab testing before production, continuous CVE monitoring.
Concept
How do SAST and fuzzing complement each other?
Answer
SAST (Static): Examines source code without execution. Finds code-pattern vulnerabilities: buffer-unsafe function calls, SQL injection patterns, hardcoded credentials. Can run before the application is built. Cannot find runtime-only vulnerabilities.
Fuzzing (Dynamic): Examines running application behavior under unexpected input. Finds runtime vulnerabilities: memory corruption under extreme input, unhandled exceptions, denial-of-service from malformed data. Requires the application to be executing. Cannot analyze code that was never reached.
Together: SAST catches design-level issues in code; fuzzing catches runtime-behavior issues that only appear under adversarial input. Neither is a substitute for the other — they cover different vulnerability classes.
Fuzzing (Dynamic): Examines running application behavior under unexpected input. Finds runtime vulnerabilities: memory corruption under extreme input, unhandled exceptions, denial-of-service from malformed data. Requires the application to be executing. Cannot analyze code that was never reached.
Together: SAST catches design-level issues in code; fuzzing catches runtime-behavior issues that only appear under adversarial input. Neither is a substitute for the other — they cover different vulnerability classes.