Static analysis has gotten very good at a specific question: is this code wrong? It finds the null deref, the injection, the unsafe deserialization, the known-bad pattern. What it cannot ask is a different question entirely: does this change violate a duty that lives in a regulation?
Two different questions
A linter reasons about the code in front of it: types, control flow, taint, known vulnerability signatures. It is framework-blind by design, because the rules it enforces are universal, the same in every repo on earth.
Compliance is the opposite. Whether a change is a problem depends on facts the code does not contain: which frameworks your company must meet, what counts as personal data in your domain, how long you are allowed to keep it, where it is allowed to flow. The same diff can be perfectly compliant in one company and a finding in another.
The change that is correct and non-compliant at once
Add a log line that records the full request body to debug a checkout flow. The code is correct. It compiles, it runs, no linter objects, the tests pass. It also writes a customer email and address into your logs, which is more personal data than the purpose needs, and that is GDPR Art. 5(1)(c) territory.
No tool reasoning about code quality will flag that, because nothing about the code is low quality. The problem is only visible if you are reading the change against the data-protection duties the company actually has. That is the framework-aware layer linters do not have.
The missing layer, not a replacement
This is not an argument against linters or scanners. Keep them; they catch things heygrc never will. It is an argument that there is a whole category of risk sitting above them, framework obligations, that no amount of code-quality analysis can see.
heygrc is that layer. It reads the change against your frameworks and cites the specific control, so the framework-blind spot in your existing tooling gets a set of eyes. heygrc is in early access.