A pull request adds a new dependency. A static analysis tool scans the source in under 90 seconds and flags a SQL injection pattern on line 214 of a controller file. A dynamic analysis tool, running against the deployed staging build, fires roughly 4,000 fuzzed HTTP requests overnight and confirms the same endpoint returns a 500 error that leaks the database driver version in a stack trace. Both tools found the same vulnerability. One found it by reading code that hadn't executed yet; the other found it by watching the application actually run. That distinction — inspecting source without execution versus observing behavior during execution — is the entire static analysis vs dynamic analysis question, and it decides which bugs your pipeline catches before a CVE gets assigned and which ones show up in an incident report instead.
What is static analysis, and what does it actually catch?
Static analysis (SAST) scans source code, bytecode, or binaries without running them, and it catches structural, pattern-based flaws — SQL injection (CWE-89), hardcoded credentials (CWE-798), buffer overflows (CWE-120), insecure deserialization — by matching code shape and data flow against known-bad patterns. Tools like Semgrep, CodeQL, SonarQube, and Checkmarx work this way: CodeQL ships more than 400 default queries mapped to CWE categories, and a scan of a 100,000-line repo typically finishes in a few minutes because it never has to spin up a runtime environment. The tradeoff shows up in accuracy. The OWASP Benchmark Project, which runs thousands of known-vulnerable and known-safe test cases against commercial and open-source SAST tools, has repeatedly measured true-positive rates ranging from roughly 20% to 90% depending on the tool and rule set — meaning a sizable share of "vulnerabilities" a static scanner reports never execute in a way that's actually reachable by an attacker.
What is dynamic analysis, and how is it different from static analysis?
Dynamic analysis (DAST, IAST, fuzzing) tests a running application by sending it real inputs and observing real outputs, and it differs from static analysis because it exercises actual runtime behavior — memory state, authentication flow, server configuration — instead of parsing code structure on disk. Heartbleed (CVE-2014-0160), disclosed on April 7, 2014, is the canonical example: the flawed bounds check in OpenSSL's heartbeat extension only mattered once a live TLS connection sent a malformed heartbeat request and the server leaked up to 64KB of process memory per request. No amount of reading the source in isolation demonstrated the blast radius the way watching a live exploit did. Tools like OWASP ZAP, Burp Suite, and Contrast Security operate this way today, crawling a deployed app and firing thousands of payloads at each discovered endpoint and parameter.
Static analysis vs dynamic analysis: which produces more false positives?
Static analysis produces more false positives, because it flags code paths without knowing whether they're actually reachable at runtime, while dynamic analysis trends toward false negatives, because it only tests the inputs and routes it actually exercises during a scan window. A static scanner sees every function in a codebase, including dead code, admin-only paths, and functions guarded by feature flags that never ship — and it flags all of them equally. A dynamic scanner sees only what got crawled: if a DAST run discovers and tests 30 endpoints out of 200 in an API, the other 170 — including anything behind an auth wall the crawler couldn't log into — simply never get evaluated. Neither failure mode is hypothetical; it's the reason security teams routinely triage SAST backlogs in the thousands of findings while DAST reports stay comparatively short but miss entire sections of an application.
Can static and dynamic analysis be combined in one pipeline?
Yes — mature application security programs run static analysis on every commit and pull request, then run dynamic analysis against a deployed staging or QA build on a scheduled or release-gated basis, layering code-level checks before merge with runtime checks before release. NIST's Secure Software Development Framework (SP 800-218, published February 2022) explicitly recommends multiple testing types across the SDLC rather than relying on one. In practice that looks like a SAST job that gates a PR in under 5 minutes, followed by a nightly DAST crawl-and-fuzz cycle against staging that takes 45–90 minutes depending on API surface area, followed by IAST instrumentation during QA regression runs that correlates the two by watching which SAST-flagged functions actually get hit by live traffic.
Which one matters more for software supply chain security?
For software supply chain risk, static analysis — specifically software composition analysis (SCA) and SBOM tracking — matters more day to day, because most supply chain exposure comes from third-party code your own team never directly exercises in a dynamic test suite. Log4Shell (CVE-2021-44228), disclosed December 9, 2021, is the clearest case: the vulnerable Log4j 2.x library sat four or five dependency layers deep in an estimated hundreds of thousands of Java applications, many of which never called the affected JndiLookup class directly and would never have surfaced the flaw through a company's own DAST scan of its own endpoints. The same pattern played out with MOVEit Transfer (CVE-2023-34362), a SQL injection disclosed May 31, 2023 and exploited by the Cl0p ransomware group against more than 2,700 organizations — the vulnerable code lived inside a vendor's file transfer appliance, not inside any application a victim organization could dynamically scan. An accurate SBOM, checked against a live vulnerability feed the moment a CVE like that publishes, catches exposure that no amount of testing your own running application would ever reach.
When should each type run in a CI/CD pipeline?
Static analysis should run on every commit and pull request because it's fast and doesn't need a live environment, while dynamic analysis should run against staging or pre-production builds on a nightly or release-gated schedule because it needs something deployed to attack. A typical pipeline: SAST and SCA run as a required PR check (2–5 minutes for a mid-sized service), a container and IaC scan runs at build time before an image is pushed, and DAST runs post-deploy against staging, gating the promotion to production if it turns up a critical finding. Running dynamic analysis on every commit is rarely practical — spinning up a full environment and crawling it takes far longer than a static pass — which is exactly why most teams get the ordering backwards and end up finding runtime issues only after a customer does.
How Safeguard Helps
Safeguard doesn't force a choice between static and dynamic analysis — it connects them. Reachability analysis takes every static finding and checks it against your actual call graph, so a CVE in a transitive dependency that's never invoked gets deprioritized instead of sitting in a backlog next to real exposure, directly attacking the 20–90% true-positive variance that plagues traditional SAST/SCA tools. SBOM generation and ingest give you a live, queryable inventory of every dependency across your services, so when the next Log4Shell or MOVEit-style CVE publishes, Safeguard tells you within minutes which of your systems actually run the affected version. Griffin AI layers reasoning on top of that data — correlating reachability, exploit maturity, and runtime signals to rank what genuinely needs attention today versus next sprint. When a fix exists, Safeguard opens an auto-fix pull request with the minimum version bump or patch needed, so the gap between "static analysis found it" and "it's actually shipped" closes in one review cycle instead of one backlog grooming meeting.