Except when the language itself is statically and strongly typed (a la Haskell).
Most dependencies are specified like "network-info >= 0.2" (taken from a random example: https://github.com/bitemyapp/blacktip/blob/master/blacktip.c...), which means you don't know which version will actually be used until you build the project. Which is our point in this blog post. If you just scanned that text file, you'd just be guessing at which versions of open source libraries are actually being used.
Basically, never try to guess what the package manager is going to resolve. Just let it do its job, just as it does for your production builds, and use that information to look up any associated vulnerabilities.
As an aside, and echoed by a few other comments in the thread, what you're calling "dynamic analysis" is what I know as "static analysis", like what I want Coverity to do (watch the build process, and monitor the source that actually goes into each of my build artifacts). "Dynamic analysis" brings to mind something more like Valgrind, or some other tool that monitors and profiles a program during execution.
(you could think of stack as analogous to ruby's Gemfile.lock plus rbenv, or python's virtualenv - it makes the whole build reproducible)