Security invariants
The rules your own code already follows, derived once and re-checked on every commit.
An invariant is something true about your application that should stay true: every mutating route requires a session, every tenant lookup is scoped, no private key reaches the browser, the price comes from the server. AppScan derives these from your code rather than asking you to write them.
| State | Meaning |
|---|---|
| Holding | Re-checked and still true on the current commit. |
| Broken | Violated by a change, with the file and line that broke it. |
| Not verifiable | The code moved somewhere the analyzer cannot follow. Said plainly rather than guessed. |
Reconciliation
After a refactor the invariants are re-derived rather than reported as broken en masse. Renaming a helper should not produce fifteen security alerts.
“We always scope by tenant” is an opinion until it is stored as a fact and re-checked automatically. Then a change that breaks it is a broken fact, not a matter of who reviewed the diff.
Questions
Can I add an invariant by hand?
Not today. They are derived from patterns your code already follows, which is what keeps them honest and specific to you.
Why did an invariant become “not verifiable”?
Usually because the logic moved behind something the analyzer cannot follow - dynamic dispatch, a wrapper built at runtime, or code in a language it does not parse. The invariant is not silently dropped; it is shown in that state.
Something here wrong, missing or out of date? Tell us and we will fix the page.