A mid-size company runs quarterly vulnerability scans. The security team performs only external scans, checking the internet-facing perimeter for open ports and unpatched services. The most recent scan returns 12 medium-severity findings, all of which are remediated. Six months later, incident responders investigate an anomalous data exfiltration event. During the investigation, they discover that an attacker had been inside the network for three months, operating from a Raspberry Pi device someone had plugged into a conference room network jack. The device never appeared in the external scan — it had no internet-facing services — and it was absent from the asset inventory because it was deployed without going through IT procurement.
The security team's reliance on external scanning alone reflects a critical gap. An internal scan would have detected the Raspberry Pi — it was attached to the internal network and reachable from any device on the same segment. Internal scans discover unauthorized devices regardless of whether those devices have internet-facing services. The device's absence from the asset inventory is a parallel failure: vulnerability scanning and asset management are interdependent. Devices not in the asset inventory are invisible to scheduled scans if the scan scope is defined by the inventory. This example illustrates why internal scanning is not optional: external scans cover the perimeter attacker model; internal scans cover the insider and post-breach lateral movement model. Both are required.
A vulnerability scanner returns a Critical-severity finding on a production web server: "Apache HTTP Server 2.4.49 — Path Traversal and Remote Code Execution (CVE-2021-41773)." The scanner identified the Apache version from the HTTP response headers and matched it against a known-vulnerable version. A junior analyst, seeing "Critical" and "Remote Code Execution," immediately begins scheduling an emergency maintenance window for Saturday night to apply the patch, which requires taking the e-commerce site offline for four hours. Before scheduling the outage, the senior security engineer investigates the actual server configuration. She discovers that the server is running Apache 2.4.49, but the vendor applied a backported patch months ago — the vulnerable code path is not present in this build. The version number matches, but the vulnerability does not exist.
This is a textbook false positive. Vulnerability scanners identify potential vulnerabilities based on version numbers and pattern matching; they cannot always detect whether a specific backported patch has been applied. The scanner correctly matched the version string to a known-vulnerable version, but the vulnerable code was absent from the actual build. Had the analyst acted on the unverified finding, the organization would have suffered a four-hour revenue impact and service disruption for no security benefit. The required workflow — verify against the actual system before scheduling remediation — saved both the outage and the false confidence that the patch had addressed a real risk. False positives are not scanner errors; they are an expected output that triage must handle.
A development team integrates a SAST tool into their CI/CD pipeline for a web application that handles customer order data. On a Tuesday afternoon, a developer commits a new search feature. The SAST scan runs automatically on the commit within 90 seconds. It flags one High-severity finding: the new database query is constructed by concatenating the user-supplied search term directly into the SQL string rather than using a parameterized query. The SAST tool identifies the string concatenation pattern as a SQL injection vulnerability. The developer receives the finding in her IDE within two minutes of committing. She rewrites the function using a prepared statement, commits the fix, and the SAST rescan returns no findings. Total time from finding to fix: 11 minutes. Total customer impact: zero.
This demonstrates the core value proposition of SAST integration in CI/CD pipelines: vulnerabilities found at commit time cost minutes to fix. The same SQL injection vulnerability discovered post-deployment would have required a security incident response, emergency patching, possible data breach notification to customers, and regulatory reporting under applicable privacy laws. The SAST tool identified the code pattern (string concatenation into a query) that characterizes SQL injection risk — exactly the class of vulnerability that static analysis is well-suited to find. Note what SAST did not catch in this example: the developer's overall authentication design, whether the session handling is secure, and whether the business logic correctly restricts which orders a customer can search. Those require additional techniques.
A security engineer is assessing a REST API before its production launch. She runs a fuzzing tool against the document upload endpoint, which accepts JSON payloads describing file metadata. The fuzzer generates thousands of malformed payloads: empty strings, null values, negative numbers where positive integers are expected, 50,000-character strings where a 255-character limit is documented, and JSON objects with unexpected nesting depths. After approximately 4,000 iterations, the fuzzer submits a payload with a deeply nested JSON structure (900 levels of nesting). The API server returns an HTTP 500 Internal Server Error and a stack trace revealing it is a Node.js application running an older version of a JSON parsing library. Further investigation confirms the deeply nested JSON triggers a stack overflow in the parser — a denial-of-service vulnerability that an attacker could use to crash the API server on demand.
This illustrates fuzzing's core strength: it finds edge cases that no developer thought to test. No developer would manually test a 900-level JSON nesting depth. The anomalous response — an HTTP 500 with a stack trace instead of the expected HTTP 400 validation error — is the signal the fuzzer monitors for. The stack trace in the response is itself an additional vulnerability: it reveals implementation details (language, library versions) that help attackers plan further attacks. This vulnerability would have been invisible to SAST — the JSON parsing code in the application may have been syntactically correct; the vulnerability was in the library's behavior under extreme input, which only manifests at runtime. This is the complementary relationship: SAST and fuzzing together cover classes of vulnerabilities that neither covers alone.
A company runs a Java-based internal application that uses a logging library as a dependency. On a Tuesday morning, a high-severity CVE is published for that specific version of the logging library, disclosing a remote code execution vulnerability. Within 15 minutes of the CVE publication, the organization's package monitoring tool (configured to watch all installed dependencies against the CVE database) triggers an automated alert: "CVE-2024-XXXXX: Critical severity. Affected version detected in: internal-app-prod, reporting-service. Upgrade to library version 2.17.1." The security team receives the alert, assesses the exploitability in their specific deployment context, confirms the vulnerability is reachable in production, and deploys the patched version within six hours. No exploitation occurs.
This is the purpose of continuous package monitoring: eliminating the gap between "CVE publicly disclosed" and "organization aware." Without monitoring, the organization would have learned about the vulnerability through a vulnerability scan run days or weeks later, or worse, through an incident after exploitation. The monitoring tool's value is not in finding the vulnerability (the CVE database did that) but in connecting the CVE to the organization's specific installed versions in near-real-time. The scenario also illustrates the correct post-alert response: assess exploitability in context (not all CVEs in installed packages are exploitable in every deployment), confirm risk, then remediate. The six-hour response from alert to patched production is the outcome package monitoring makes possible.