Probabilmente è inverosimile (e certamente speculativo), ma pubblicherò spero che stimoli idee negli altri:
Nella progettazione software tradizionale, la dipendenza dai percorsi di codice era chiara e non determinata in modo dinamico. Pertanto, qualsiasi analisi di sicurezza [statica] basata sull'analisi della traccia del sink di origine è stata "facile". (Ad esempio, trovare un percorso di codice tramite analisi statica che utilizza l'input dell'utente in un SQL senza passare attraverso una funzione di pulizia, o l'input dell'utente che riflette nell'apertura dell'output a XSS o password che lo rende capace di registrare i file in chiaro).
Tuttavia, con modelli di design moderni come IoC e la natura dinamica di alcuni linguaggi come JavaScript, l'analisi dei sink di origine diventa intrinsecamente "difficile" poiché fonti e sink non sono ancora [ancora] connessi in fase di compilazione.
Quindi una cosa che un compilatore JIT potrebbe, almeno in teoria, fare è identificare nuovi percorsi sink di origine che sono stati creati e eseguire almeno un'analisi di tipo rudimentale, o magari generare un evento che un'app di monitoraggio della sicurezza potrebbe intrappolare ed eseguire analisi approfondite in fase di esecuzione.
L'ostacolo qui non è solo l'identificazione del source-sink basata su JIT in modo economico, ma anche che l'analisi del tipo di sicurezza su di esso è [attualmente] proibitivamente lenta (AFAIK). Ma forse alcune rudimentali analisi di tipo possono essere fatte in fase di runtime con una ragionevole spesa per le prestazioni.