Scan statique et attaque en marche
Two families of security analysis that look at different objects. **Static scanning** reads source code at rest and flags the patterns it recognises as dangerous: a hardcoded secret, a query built by concatenation, an input never validated. **Runtime attack testing** boots the application, sends it real hostile requests and watches what gives way: an auth flow replayed, an identifier swapped in the URL, a field returned that should not have been. The first sees what is written, the second sees what happens. A misplugged access rule exists nowhere in a file: it only appears once the parts are assembled and the service is running. That is why an all-green dashboard tells you nothing until you know which of the two produced it.
Strengths
- Separates two coverages that everyday vocabulary conflates, making the remaining gap legible
- Gives a usable sorting criterion: does the flaw fit in one line, or in a sequence?
Limitations
- The boundary blurs for interactive analysis, which instruments the code while it runs
- Knowing the distinction does not say what to fix first: it is a reading grid, not a prioritisation
Best for
- Developer shipping an API that handles user-owned data
- Product lead who has to read a security report without knowing what was measured