Gains:
- Ability to recognize common vulnerability patterns such as reentrancy, access control, oracle manipulation and front-running and scan them with a static analysis tool + artificial intelligence + human
- Ability to distinguish between AI strengths in explaining tool output and prioritizing false positives and weaknesses in MEV and business logic
- Understand that a 'clean scan' is not a security certificate, that scanning is just one layer of control
We saw the holistic discipline of auditing in the previous unit. In this unit, we focus on a more technical topic: vulnerability scanning — the systematic search for known vulnerability patterns in code. Here we will use AI, together with static analysis tools, as an assistant that scans and describes known vulnerability patterns. The goal: to get to know the most common vulnerabilities in depth and distinguish where AI is reliable and where it is inadequate in scanning them.
Static and dynamic scanning
Scanning is of two types. Static analysis — examining the code without running it: Tools such as Slither and Mythril scan the contract code and flag known patterns. Dynamic/symbolic analysis (running the code with different inputs or exploring it mathematically): fuzzing (bombarding with random input) and symbolic execution (exploring all possible paths) fall into this group.
AI does not replace these tools, it complements them: when the vehicle issues a warning, AI explains the warning in plain language; AI can remind when the tool misses a pattern; But AI alone cannot guarantee how much it scans. The right workflow: tool + AI + human.
Tip: Give the AI the output of a static analysis tool (e.g. Slither report) and ask “explain each alert in plain language, which are real risks and which could be false positives?” ask. AI is invaluable in making raw tool output understandable and prioritizable to humans.
Most common vulnerability patterns
1. Reentrancy. If a function calls an external contract without updating its state, the called contract can go back, trigger the same function again and withdraw the fund multiple times. Solution: checks-effects-interactions order and reentrancy guard.
2. Lack of access control. A critical function (withdrawal, withdrawal, upgrade) is accidentally made public. It is one of the most common and expensive mistakes.
3. Oracle manipulation. The contract's blind reliance on an external price source (oracle). The attacker manipulates the price instantly and deceives the protocol. Solution: time-weighted average price (TWAP), multi-source.
4. Integer overflow/underfall. When a number exceeds the maximum allowed value and returns to the beginning. Modern Solidity catches most of it automatically, but the risk remains in low-level (assembly) code.
5. Front-running. Transactions appear in the public pool (mempool) before they are confirmed; The attacker can see your transaction and insert his own transaction in front of it. MEV (Maximal Extractable Value — the value extracted from the transaction sequence) is the general name of this subject.
6. Denial of Service (DoS). A loop becomes too expensive and makes the function unusable, or a dependency on an address becomes locked.
7. Upgrade risks. Storage collision and abuse of authority in upgradable contracts.
vulnerability
AI scanning trust
Why
reentrancy
high
Well-known, clear pattern
access control
high
Mold can be scanned
Integer operations
high
standard control
Oracle manipulation
medium
Requires context
Front-running/MEV
Medium-Low
protocol specific
business logic error
low
Authentic, contextual
Weak prompt / Strong prompt
Weak prompt:
Is there a loophole in this code?
Powerful prompt:
Your role: security screening assistant. Scan the contract below for the following known patterns and "at risk/no/unsure" for each: reentrancy, access control, integer operations, oracledependency, front-running, DoS, upgrade security. Link each determination to the relevant line and explain why there is a risk. These are hypotheses that WILL be VERIFIED with a static analysis tool and auditor. Note that there may be false positives.
Four copyable templates
1) Tool output description:
Below is the report of a static analysis tool (Slither). Explain each alert in plain language: what does it mean, is it a real risk or a possible false positive, what should be its priority? Don't make a firm decision; Prioritize for auditor confirmation.
2) Reentrancy focused screening:
Find all functions that make external calls in this contract. Examine whether the checks-effects-interactions order is followed for each of them and whether there is a reentrancy guard. Show the risky ones with a line. Mark if you are not sure; Generating exploit code.
3) Access control map:
List all external/public functions in this contract and specify "who can call" (everyone/owner/role) for each. Perform critical operations (withdraw, print, upgrade) and mark those with weak access control. Present it with a table.
4) False positive elimination:
Consider why this scan warning might not be a REAL risk (false positive): what context or code condition would invalidate this warning? But don't say "there is absolutely no problem"; List the points that need confirmation.
Three mini cases (in numbers)
Case 1 — Vehicle + AI doubled efficiency. One team ran Slither on a 12-contract project and received 140 warnings. Once we had the AI explain and prioritize the alerts, it turned out that 95 of the 140 alerts were false positives; The team focused on 45 real candidates. Triage time decreased from 2 days to 5 hours. Lesson: AI is powerful at humanizing vehicle output.
Case 2 — AI hijacked MEV. In a DEX (decentralized exchange) contract, the AI found the standard patterns clean but failed to detect a front-running vulnerability; because this was specific to the protocol's order of operations. Human auditor and simulation captured. Lesson: Protocol-specific risks like MEV/front-running are AI's weak area.
Case 3 — Avoided wasting time on a false positive. The team was spared an unnecessary rewrite when the AI explained that a reentrancy warning was actually a false positive (the function was already guarded). But the team still confirmed it with a single test. Lesson: AI prioritizes; Confirmation again comes with testing.
Limits of scanning
The scan finds known patterns. Neither the tool nor the AI is guaranteed to detect a new, unique or protocol-specific vulnerability. Therefore, screening is part of the audit; not himself. The idea that "the scan is clean, so it means it is safe" is one of the most dangerous misconceptions in this field. Dredging picks up the low-hanging fruit; For deep and unique risks, human expertise, testing, fuzzing and formal auditing are essential.
Caution: A “clean” report of a scanning tool or AI is not a security certificate. Presenting it that way — especially to investors — is misleading and unethical.
Common mistakes
- Substituting screening for inspection. Scanning is one layer, not the whole.
- Using AI without tools. Static analysis + AI + human work together.
- Eliminating false positives without confirmation. Each screen is tested/human verified.
- Bypassing protocol-specific risks (MEV) by relying on AI. AI's weak area.
- Thinking "clean scan" = "safe". It cannot find the unknown.
- Generating exploit code. Only defensive risk description is legitimate.
In summary
- Vulnerability scanning looks for known vulnerability patterns with vehicle + AI + human.
- AI is powerful at explaining and prioritizing static analysis tool output.
- Reliable in clear patterns such as reentrancy and access control; Weak in MEV and business logic.
- Even eliminating false positives requires confirmation.
- A "clean scan" is not a security certificate; It is not a substitute for supervision.
Application task
Run a static analysis tool on a sample contract (if possible) or find a ready-made Slither report. Apply the "tool output description" prompt to the AI. Evaluate whether the AI: (1) correctly explains warnings, (2) makes sense in distinguishing between false positives, and (3) misses a protocol-specific risk. Fill in the “vehicle found / AI explained / human confirmed” columns in a table.
checklist
- [ ] I positioned the hatch as a layer of the control.
- [ ] I used static analysis tool + AI + human together.
- [ ] I searched category by category for known patterns.
- [ ] I eliminated false positives with confirmation.
- [ ] I relied on humans in weak areas such as MEV/business logic.
- [ ] I did not offer "clean sweep" as assurance.
- [ ] I worked only for defense purposes; I did not create exploits.