You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’ve been experimenting with Solidity security analysis focused on exploitability rather than pattern-based warnings.
While testing existing developer workflows (including Foundry-style projects), I noticed that many tools either:
• rely primarily on fuzzing and testing, or
• produce broad static warnings without clear exploit context or severity
This can make it difficult to distinguish real security risks from non-critical findings.
The idea
An optional security analysis layer for Foundry focused on:
• exploit paths (symbolic execution)
• interprocedural data flow
• taint-aware analysis
• clear severity classification (CRITICAL / HIGH / MEDIUM)
The goal is not to replace fuzzing or testing, but to complement them by improving security signal and reducing alert fatigue.
Why this might fit Foundry
• Foundry users value precision over noise
• False positives are costly in CI and audit workflows
• An opt-in security layer aligns well with Foundry’s philosophy
Possible integration directions:
• CLI command (e.g. forge security scan)
• CI-friendly output (fail on CRITICAL only)
• Experimental plugin or feature flag
Proof of concept
I’ve built a working prototype and ran it on deliberately vulnerable contracts, including both simple and more complex interprocedural cases.
I’ve prepared:
• a short presentation outlining the idea
• detailed PDF test cases with reproducible code and side-by-side comparisons
Happy to share links if this is the right place for that.
Closing
I’d love to hear whether this kind of exploit-oriented analysis:
• aligns with Foundry’s roadmap, or
• would be better discussed in a different format (issue, RFC, etc.)
Thanks for the great work on Foundry — the tooling quality is what motivated me to explore this direction.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hi Foundry team 👋
I’ve been experimenting with Solidity security analysis focused on exploitability rather than pattern-based warnings.
While testing existing developer workflows (including Foundry-style projects), I noticed that many tools either:
• rely primarily on fuzzing and testing, or
• produce broad static warnings without clear exploit context or severity
This can make it difficult to distinguish real security risks from non-critical findings.
The idea
An optional security analysis layer for Foundry focused on:
• exploit paths (symbolic execution)
• interprocedural data flow
• taint-aware analysis
• clear severity classification (CRITICAL / HIGH / MEDIUM)
The goal is not to replace fuzzing or testing, but to complement them by improving security signal and reducing alert fatigue.
Why this might fit Foundry
• Foundry users value precision over noise
• False positives are costly in CI and audit workflows
• An opt-in security layer aligns well with Foundry’s philosophy
Possible integration directions:
• CLI command (e.g. forge security scan)
• CI-friendly output (fail on CRITICAL only)
• Experimental plugin or feature flag
Proof of concept
I’ve built a working prototype and ran it on deliberately vulnerable contracts, including both simple and more complex interprocedural cases.
I’ve prepared:
• a short presentation outlining the idea
• detailed PDF test cases with reproducible code and side-by-side comparisons
Happy to share links if this is the right place for that.
Closing
I’d love to hear whether this kind of exploit-oriented analysis:
• aligns with Foundry’s roadmap, or
• would be better discussed in a different format (issue, RFC, etc.)
Thanks for the great work on Foundry — the tooling quality is what motivated me to explore this direction.
— Niko
Independent security researcher
References:


• Scanner website: https://smartshield-demo-m0tw.onrender.com/#scanner
• GitHub repository: https://github.com/doi-qw/SmartShield-DEMO-
Beta Was this translation helpful? Give feedback.
All reactions