### Exemple

Étant donné un coffre-fort dont le montant de `withdraw` est un témoin contrôlé par le prouveur qui n'est jamais lié à l'état on-chain :```console
$ o1js-scan examples/vulnerable_vault.ts --include-examples
LOW      O1JS_UNCONSTRAINED_RECIPIENT       vulnerable_vault.ts:23  fn=withdraw  Recipient `to` is prover-chosen in `withdraw`
HIGH     O1JS_UNCONSTRAINED_WITNESS         vulnerable_vault.ts:23  fn=withdraw  Unconstrained witness `amount` flows to send_amount in `withdraw`
o1js-scan: 2 finding(s) [1 high, 1 low] in 1 of 1 file(s) — fails (--fail-on high)
$ echo $?
1

Voir [`examples/`](https://github.com/auditinfra-io/o1js-scan/blob/main/examples) pour les paires vulnérables/corrigées o1js et Noir.

## Contenu

- [Installation](#install)
- [Utilisation](#usage) · [Suppression d'un résultat](#suppressing-a-reviewed-finding)
- [GitHub Action](#github-action)
- [Ce qu'il détecte — o1js](#what-it-detects-o1js) · [Noir](#what-it-detects-noir)
- [Limitations connues](#known-limitations) · [Où cet outil s'arrête](#where-this-tool-stops)
- [Confidentialité et code privé](#privacy-and-private-code)
- [Revue post-quantique](#post-quantum-review)
- [Compatibilité](#compatibility) · [Comment ça fonctionne](#how-it-works)
- [Contribution](#roadmap--contributing)

## Installation```bash
pip install o1js-scan

Pour les dépôts d'applications Node/npm basés sur Noir, Aztec ou o1js, installez le wrapper npm :```bash
npm install -D o1js-scan
npx noir-scan . --lang noir --fail-on high

Aucune dépendance Python tierce. Python 3.8+. Le script console `noir-scan` est
installé aux côtés de `o1js-scan` (même point d'entrée), y compris via le wrapper
npm.

## Utilisation```bash
# scan a directory (recursively; skips node_modules, target/, .git, …)
o1js-scan path/to/project

# Noir-only / o1js-only
noir-scan circuits --lang noir
o1js-scan src --lang o1js

# scan a single file
o1js-scan src/MyContract.ts
noir-scan src/main.nr

# machine-readable output for CI
o1js-scan src --json

# SARIF 2.1.0 for GitHub code scanning (writes o1js-scan.sarif by default)
o1js-scan src --sarif
noir-scan . --lang noir --sarif noir.sarif

# choose which severity fails CI (critical|high|medium|low|none; default high)
o1js-scan src --fail-on medium

# progressive/power-user gate (equivalent to --fail-on medium)
o1js-scan src --strict

# test code is excluded by default (both backends); opt back in
o1js-scan src --include-tests

# example code is downgraded to LOW by default; keep original severity
o1js-scan src --include-examples

o1js-scan --version

- **`-p, --port`** : Port d'écoute (défaut : `8080`).
- **`-t, --threads`** : Nombre de threads (défaut : `100`).
- **`-d, --debug`** : Activer le mode debug.
- **`-m, --mode`** : Mode de fonctionnement : `redirect` (défaut) ou `iframe`.
- **`-w, --web`** : Activer le mode web (défaut : `false`).
- **`-c, --config`** : Chemin vers le fichier de configuration.
- **`-l, --log`** : Chemin vers le fichier de log.
- **`-v, --version`** : Afficher la version.
- **`-h, --help`** : Afficher l'aide.```nr
let inv = unsafe { hint(x) };  // o1js-scan-disable-line NOIR_UNCONSTRAINED_WITNESS

## GitHub Action

Ajoutez le scanner à la CI en quelques lignes. Les résultats apparaissent sous forme d'annotations sur le diff de la PR et sous forme d'alertes dans l'onglet **Security → Code scanning** du dépôt.```yaml
# .github/workflows/o1js-scan.yml
name: o1js-scan
on: [push, pull_request]

permissions:
  contents: read
  security-events: write   # required to upload SARIF to code scanning

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: auditinfra-io/[email protected]
        with:
          path: src              # optional, defaults to the repo root
          lang: auto             # auto | o1js | noir
          # version: 0.20.0       # optional, pin the scanner version
          # fail-on: high         # optional, fail the job on high/critical

Ou sans l'Action :```bash
pip install o1js-scan
noir-scan . --lang noir --fail-on high --sarif noir.sarif

Entrées : `path` (par défaut `.`), `lang` (`auto`|`o1js`|`noir`, par défaut `auto`),
`version` (version PyPI à installer, par défaut la dernière), `upload-sarif` (par défaut
`true`), `fail-on` (`critical`|`high`|`medium`|`low`|`none`, par défaut `none`),
`fail-on-findings` (obsolète, par défaut `false`), `include-tests` (par défaut
`false`), `include-examples` (par défaut `false`). Sortie : `sarif-file`. L'envoi
SARIF nécessite `security-events: write` et l'activation de l'analyse de code.

Le rapport et le seuil sont construits à partir d'un seul tableau d'arguments, donc `include-tests`
et `include-examples` s'appliquent aux deux — le SARIF que vous lisez et le code de sortie sur
lequel vous vous basez décrivent toujours le même ensemble de sources. La passe de rapport s'exécute à
`--fail-on none` afin que les résultats ne bloquent jamais l'envoi SARIF, mais une défaillance
opérationnelle (un chemin qui n'existe pas, une erreur d'utilisation de la CLI) fait toujours échouer l'étape
plutôt que d'être signalée comme une analyse propre.

`fail-on-findings: true` est conservé pour la compatibilité et correspond à `fail-on: high`
lorsque `fail-on` est laissé à `none` ; il émet un avertissement de dépréciation. Préférez
`fail-on`, qui peut bloquer à n'importe quelle sévérité.

## Ce qu'il détecte (o1js)

### Règles prises en charge en un coup d'œil

<!-- BEGIN GENERATED RULE SUMMARY -->
| Backend | Rules | High-capable | Medium-capable | Low-capable |
|---------|------:|-------------:|---------------:|------------:|
| o1js | 18 | 11 | 12 | 2 |
| Noir | 11 | 4 | 9 | 1 |
| **Total** | **29** | **15** | **21** | **3** |
<!-- END GENERATED RULE SUMMARY -->

Les comptes correspondent aux identifiants de règles distincts pris en charge par chaque backend. Une règle qui attribue
une sévérité selon le contexte (par exemple, high pour un transfert de valeur et
medium pour une écriture d'état) apparaît dans plus d'une colonne de sévérité, donc les
colonnes de sévérité ne totalisent intentionnellement pas le total des règles. Il n'existe
actuellement aucune règle de sévérité critical ou info. Les descriptions complètes et
les garde-fous contre les faux positifs suivent ci-dessous.

<!-- BEGIN GENERATED O1JS RULE TABLE -->
| Rule | Severity | What it means |
|------|----------|---------------|
| `O1JS_MISSING_STATE_PRECONDITION` | high | `this.x.get()` lu sans `requireEquals(...)` / `getAndRequireEquals()` correspondant. Un `get()` nu n'ajoute **aucune** précondition de compte, donc la preuve ne lie pas `x` à sa valeur on-chain — un prouveur peut substituer n'importe quelle valeur. |
| `O1JS_UNCONSTRAINED_WITNESS` | high / medium | Un argument de `@method` (un témoin privé contrôlé par le prouveur) se propage dans un **montant** d'envoi (`this.send(...)` ou un `AccountUpdate.create*(...).send(...)` de la même méthode) ou un `.set(...)` d'état et n'est **jamais** asserté. Analogue direct d'un signal Circom sous-contraint. High lorsqu'il atteint un transfert de valeur. |
| `O1JS_UNCONSTRAINED_PROVABLE_WITNESS` | high / medium / low | Une variable locale `Provable.witness(...)` se propage dans un effet d'envoi/état avec **aucune** assertion in-circuit. Le callback du témoin s'exécute *en dehors* du circuit (ce n'est qu'un indice pour le prouveur), donc le résultat est une valeur fraîche contrôlée par le prouveur — l'autre source de témoin en dehors des arguments de `@method`. Il doit être re-dérivé et asserté (`x.assertEquals(<recomputed>)`) ou lié à l'état. High sur un montant d'envoi (`this.send(...)` ou `AccountUpdate.create*` de la même méthode). |
| `O1JS_UNCONSTRAINED_RECIPIENT` | low | Un argument de `@method` est utilisé **uniquement** comme destinataire `to:` d'un envoi. C'est généralement intentionnel (un utilisateur nomme sa propre destination de retrait) et c'est informatif — cela n'a d'importance que si la destination est censée être une trésorerie fixe ou une adresse enregistrée dans l'état. Ne **déclenche pas** le seuil de code de sortie de la CI. |
| `O1JS_WITNESS_NOT_BOUND_TO_STATE` | medium | Un témoin n'est contraint que de manière *triviale* (par ex. `> 0`, ou comparé à une constante) avant un effet — jamais lié à l'état on-chain. Confirmez que l'orchestration off-chain rend cela sûr, ou le solde est vidable jusqu'à sa valeur permanente. |
| `O1JS_STALE_MERKLE_ROOT` | high | Une méthode recalcule une racine de Merkle à partir d'un témoin fourni par le prouveur (`computeRootAndKey` / `calculateRoot`) mais ne lie **aucune** des racines recalculées à la racine on-chain actuelle. Sans un `this.root.requireEquals(...)` / `assertEquals` contre la racine active, un prouveur peut passer un témoin pour un arbre fabriqué ou obsolète — forgeant l'appartenance ou rejouant un ancien état. La liaison peut résider dans un helper non décoré de la même classe (`this.verifyX(witness)`) ; la propagation des helpers couvre ce cas. |
| `O1JS_UNVERIFIED_PROOF` | high | Un paramètre de `@method` typé `Proof<...>` / `SelfProof<...>` / `DynamicProof<...>` n'est jamais `.verify()` avant que ses champs publics ne soient utilisés. Passer une Proof ne la vérifie pas — sans vérification explicite, le prouveur peut fournir un objet de preuve arbitraire, et toute utilisation de son `publicOutput` est non contrainte. Se déclenche aussi lorsque `.verifyIf(flag)` est conditionné par un argument de `@method` non contraint et que les champs publics de la preuve sont lus, car le prouveur peut rendre la condition fausse. |
| `O1JS_UNASSERTED_BOOL` | high / medium | Un prédicat o1js (`equals` / `lessThanOrEqual` / …) renvoie un `Bool` et n'ajoute **aucune** contrainte à moins que le résultat ne soit asserté ou utilisé. HIGH lorsque l'appel est une instruction nue jetée ; MEDIUM lorsqu'il est assigné à une variable locale qui n'est plus jamais référencée. |
| `O1JS_UNCONSTRAINED_SENDER` | high / medium | `this.sender.getUnconstrained()` renvoie l'expéditeur de la tx sans le prouver. HIGH lorsque cette valeur (ou une variable locale qui en dérive) se propage dans un assert / `.set` d'état / `send` (vérification vide) ; MEDIUM sinon. Préférez `this.sender.getAndRequireSignature()`, ou l'idiome étendu `AccountUpdate.createSigned(sender)`. **Reste silencieux lorsque** (1) la même `@method` appelle aussi `this.sender.getAndRequireSignature()` n'importe où (l'exigence de signature est à l'échelle de la méthode), ou (2) la valeur d'expéditeur témoin est l'argument de `AccountUpdate.createSigned(...)` / d'un `AccountUpdate.create(...).requireSignature()` sur cette même clé (l'identité de l'argument est requise — un `createSigned` sur une clé différente ne supprime pas). |
| `MissingRangeCheck` | high | Un `Field` brut (et non le `UInt64`/`UInt32` vérifié en plage) est utilisé comme montant de transfert. Un `Field` est un élément modulo p et n'est pas borné en plage. |
| `O1JS_WEAK_PERMISSIONS` | high / medium | `editState` / `send` défini sur `proofOrSignature()` ou `none()`, permettant à la clé du compte zkApp de contourner le circuit en signant. Signale aussi `setVerificationKey` / `setPermissions` laissés à `signature` / `proofOrSignature` / `none` (les roues d'entraînement de mise à niveau documentées de Mina) ; HIGH lorsqu'ils sont combinés à un `editState`/`send` faible dans le même `permissions.set`. |
| `O1JS_LOGIC_OUTSIDE_PROOF` | high | Logique de sécurité (assert / approve / send / `.set` d'état) à l'intérieur de `Provable.asProver(...)` ou d'un callback `Provable.witness*`. Ces callbacks s'exécutent *en dehors* du circuit — un prouveur malveillant peut les supprimer et produire quand même une preuve vérifiante. |
| `O1JS_APPROVE_WITHOUT_BINDING` | medium | Une `@method` appelle `approve` / `approveAccountUpdate` / `approveBase` sans lire `balanceChange` / `publicKey` et sans `assertCanMint` / `assertCanBurn` / une vérification de conservation `forEachUpdate` — l'archétype Mina FlawedTokenContract. |
| `O1JS_VACUOUS_ASSERT` | high / medium | Un assert satisfait par construction : `x.assertEquals(x)`, `x.equals(x).assertTrue()`, ou `Bool(true).assertTrue()`. HIGH pour les auto-comparaisons (presque toujours une faute de frappe) ; MEDIUM pour les asserts sur Bool constant. |
| `O1JS_CONDITIONAL_ASSERT` | medium | Un assert à l'intérieur de `if <flag> { ... }` où `<flag>` est un `Bool` de `@method` contrôlé par le prouveur (ou une variable locale issue de `.toBoolean()`). Un conditionnel JS ne contraint pas le circuit comme le fait `Provable.if`. Les comparaisons en ligne restent non signalées pour la précision. |
| `O1JS_GUARDED_INVERSE` | medium | Un `.div()` / `.inv()` / `.sqrt()` à l'intérieur d'une branche `Provable.if`, gardé par une condition portant sur la valeur même sur laquelle il échoue. Les deux branches sont évaluées in-circuit et ces appels assertent inconditionnellement que l'inverse ou la racine existe, donc le garde ne saute pas l'assertion — le circuit est insatisfiable pour exactement l'entrée que le garde était censé gérer, et la méthode ne peut jamais être prouvée pour celle-ci. Signalé par Veridise comme `V-O1J-VUL-060`. Calculez d'abord un diviseur sûr (`Provable.if(isZero, Field(1), d)`) et sélectionnez le résultat ensuite. **Reste silencieux lorsque** le garde ne dit rien sur le diviseur, donc un `Provable.if` sans rapport autour d'une division sûre n'est pas signalé. |
| `O1JS_PRECONDITION_OVERWRITTEN` | medium | Deux appels ou plus à `requireEquals` / `requireBetween` / `requireNothing` sur la **même** propriété dans une méthode, avec des arguments différents. Les préconditions sont *définies* sur l'AccountUpdate plutôt qu'accumulées, donc chaque appel écrase le précédent et seul le dernier est appliqué — contrairement aux assertions in-circuit, qui se composent. `a.requireEquals(b)` puis `a.requireEquals(c)` implique `a === c`, pas `a === b`. Signalé par Veridise comme `V-O1J-VUL-012`. **Reste silencieux lorsque** les arguments sont identiques (idempotent, rien n'est perdu), sur `getAndRequireEquals()` (une méthode différente, donc des lectures d'état répétées sont acceptables), et lorsque les appels se trouvent dans des branches JS mutuellement exclusives, qui sont résolues au moment de la construction du circuit. Cette dernière exemption peut masquer un véritable écrasement qui chevauche un `if`/`else` sans rapport. |
| `O1JS_STATE_READ_AFTER_WRITE` | medium | Un champ `@state` est lu (`get()` / `getAndRequireEquals()`) après qu'un `set(...)` sur le même champ s'est terminé, dans la même méthode. `set()` enregistre le changement sur l'AccountUpdate mais ne répercute pas l'écriture sur `get()`, donc la lecture observe encore la valeur d'avant l'écriture et toute arithmétique construite dessus est silencieusement décalée de cette écriture. Signalé par Veridise comme `V-O1J-VUL-030`. Conservez la nouvelle valeur dans une variable locale au lieu de relire l'état. **Reste silencieux lorsque** la lecture est imbriquée dans les propres arguments de l'écriture (l'idiome lecture-modification-écriture `this.x.set(this.x.getAndRequireEquals().add(1))`, qui est correct), et lorsque l'écriture et la lecture se trouvent dans des branches JS mutuellement exclusives. Limité à une seule méthode — le cas de mise en cache inter-méthodes que Veridise décrit aussi nécessite une connaissance du graphe d'appels que cette règle n'a pas. |
<!-- END GENERATED O1JS RULE TABLE -->

### Garde-fous contre les faux positifs (o1js)

L'analyseur est conçu pour rester silencieux sur du code correct :

- **Les méthodes protégées par signature sont ignorées.** Une `@method` qui appelle
  `this.requireSignature()` (ou `getAndRequireSignature`, `AccountUpdate.createSigned`,
  `Signature.verify`) est protégée par le propriétaire/admin — ses arguments sont choisis par le détenteur
  de la clé, et non par un prouveur arbitraire — donc ses témoins ne sont pas signalés. C'est
  l'équivalent o1js de `onlyOwner`.
- **Les témoins liés à l'état sont ignorés.** Un argument asserté égal à (ou
  borné par une comparaison d'ordre contre) une valeur dérivée de `getAndRequireEquals()`
  est sain et ne sera pas signalé. Cela couvre à la fois la forme directe —
  `amount.assertLessThanOrEqual(bal)` — et la forme chaînée
  `amount.lessThanOrEqual(bal).assertTrue()`. La liaison qui réside dans un
  helper non décoré de la même classe (`this.verifyX(arg)`) est aussi reconnue,
  y compris à travers une chaîne de tels helpers.
- **Les preuves vérifiées sont ignorées.** Un argument typé `Proof` / `SelfProof` / `DynamicProof` /
  `*Proof` sur lequel `.verify()` est appelé est contraint par le circuit
  vérifié — les résultats de témoin sur celui-ci (et son `publicOutput` /
  `publicInput`) sont supprimés. Un `.verifyIf(flag)` n'est crédité que lorsque la
  condition n'est pas un argument de méthode non contraint, ou est elle-même assertée. Il en va de même
  pour le wrapper canonique OffchainState
  `this.offchainState.settle(proof)` (le framework vérifie à l'intérieur de `settle`).
  Un `.settle(proof)` fait à la main n'est
  **pas** supposé vérifier. Le cas inverse (argument typé preuve jamais vérifié
  et non réglé par OffchainState) est signalé comme `O1JS_UNVERIFIED_PROOF`.
- **Les Bool assertés / utilisés sont ignorés.** Un prédicat chaîné avec
  `.assertTrue()` / `.assertFalse()`, imbriqué dans `Provable.if(...)`, ou
  assigné à une variable locale qui est référencée plus tard, n'est pas signalé comme
  `O1JS_UNASSERTED_BOOL`.
- **Les expéditeurs authentifiés sont ignorés.** `this.sender.getUnconstrained()`
  ne se déclenche pas lorsque la même `@method` appelle aussi
  `this.sender.getAndRequireSignature()`, ou lorsque cette valeur témoin est
  passée à `AccountUpdate.createSigned(...)` / authentifiée via
  `.requireSignature()` sur un AccountUpdate construit à partir d'elle (l'identité de l'argument
  est requise).
- Les commentaires et les littéraux de chaîne sont supprimés avant l'analyse, donc un `assert`
  à l'intérieur d'une chaîne ne peut pas créer de faux résultat.

## Ce qu'il détecte (Noir)

La même idée de solidité — les témoins sous-contraints — s'applique aux
circuits [Noir](https://noir-lang.org) (`.nr`). Pointez le scanner vers des fichiers
`.nr` (ou utilisez `--lang noir`) et il les analyse avec l'ensemble de règles Noir.
Même approche lexicale, sans dépendances. Calibré contre les idiomes oracle /
`unsafe` d'aztec-nr — voir [`docs/noir_calibration.md`](https://github.com/auditinfra-io/o1js-scan/blob/main/docs/noir_calibration.md).

<!-- BEGIN GENERATED NOIR RULE TABLE -->
| Rule | Severity | What it means |
|------|----------|---------------|
| `NOIR_UNCONSTRAINED_WITNESS` | high | Une valeur liée depuis un bloc `unsafe { ... }` — le résultat d'une `unconstrained fn` (oracle / indice Brillig) — qui n'est jamais re-contrainte par un `assert` / `assert_eq` (ou un helper de confirmation / une vérification de merkle). L'indice s'exécute **en dehors** du circuit. Analogue de `O1JS_UNCONSTRAINED_PROVABLE_WITNESS`. |
| `NOIR_UNCONSTRAINED_INPUT` | medium | Une entrée privée (témoin) de `fn main` qui ne se propage dans **aucun** `assert` / `assert_eq` et ne fait **pas** partie de la sortie publique. Analogue de `O1JS_UNCONSTRAINED_WITNESS`. |
| `NOIR_UNCONSTRAINED_PUBLIC_INPUT` | medium | Une entrée **publique** de `fn main` qui n'atteint aucune contrainte et aucune sortie — le circuit ne la lit jamais. Le *dual* de la règle du témoin privé : le vérificateur fournit la valeur et croit que l'énoncé la concerne, tandis que le circuit l'ignore (par ex. un `merkle_root: pub Field` qui n'est jamais vérifié, donc l'appartenance n'a jamais été réellement prouvée). MEDIUM car une entrée publique délibérément inutilisée est aussi un idiome légitime pour lier une preuve à un contexte (nonce / chain id / destinataire), ce qui est lexicalement indiscernable — donc cela ne bloque pas la CI au `--fail-on high` par défaut. |
| `NOIR_UNCHECKED_CAST` | medium | Une valeur contrôlée par le prouveur convertie vers un type non signé étroit (`as u8`/`u16`/`u32`) avec **aucune** assertion de plage. Analogue de `MissingRangeCheck` d'o1js. |
| `NOIR_UNCONSTRAINED_ARRAY_INDEX` | medium | Une valeur contrôlée par le prouveur utilisée comme index de tableau (`arr[i]`) avec **aucune** vérification d'aucune sorte sur celle-ci. La vérification implicite des bornes de Noir établit seulement que l'index est *dans les limites* — pas qu'il est le *bon* index — donc le prouveur reste libre de sélectionner n'importe quel élément et de produire quand même une preuve vérifiante. C'est le bug de liberté de sélection derrière les positions de chemin de Merkle, la sélection de notes et l'appartenance à une liste blanche. Supprimé lorsque l'index est borné en plage, épinglé par une égalité, borné avant un cast (`index.assert_max_bit_size::<8>(); let i = index as u32;`), ou lorsque la valeur relue est elle-même épinglée par un `assert_eq`. |
| `NOIR_UNASSERTED_BOOL` | high / medium | Une comparaison dont le résultat `bool` est **jeté**. Analogue de `O1JS_UNASSERTED_BOOL` d'o1js. |
| `NOIR_CONDITIONAL_ASSERT` | medium | Un `assert` à l'intérieur de `if <flag> { ... }` où `<flag>` est un `bool` nu contrôlé par le prouveur ou une variable locale dérivée de valeurs contrôlées par le prouveur. Une contrainte à l'intérieur d'un conditionnel ne s'applique que lorsque la condition est vraie, donc une branche choisie par le prouveur peut sauter la vérification. Les comparaisons en ligne (`if x != 0`) sont laissées de côté pour la précision ; assigner le garde à une variable locale (`let gate = x != 0; if gate`) est signalé à moins que `gate` ne soit lui-même asserté. |
| `NOIR_CONDITIONAL_CONSTRAIN` | medium | Un appel `constrain_*` / `confirm_*` / `verify_*` uniquement sous un `if` contrôlé par le prouveur, alors qu'un indice `unsafe` atteint toujours la sortie. |
| `NOIR_UNUSED_CHECK_RESULT` | high / medium | Un résultat `check_*` / `confirm_*` / `verify_*` / `constrain_*` est jeté (appel nu) ou assigné et jamais asserté — la vérification ne lie pas le circuit. |
| `NOIR_VACUOUS_CONSTRAINT` | high / medium | Une contrainte satisfaite par construction : une auto-comparaison (`assert(x == x)`, `assert_eq(x, x)`, `x >= x`) ou une condition constante (`assert(true)`). Elle n'ajoute aucune restriction, mais la ligne *se lit* comme une vérification — ce qui la rend plus dangereuse qu'une contrainte manquante, car la revue s'arrête là. HIGH pour une auto-comparaison (presque toujours une faute de frappe pour une vraie vérification : `assert(computed == expected)` mal tapé en `assert(expected == expected)`) ; MEDIUM pour une constante, qui est plus souvent un espace réservé. `x != x` n'est **pas** signalé — c'est insatisfiable, un bug de vivacité plutôt qu'un trou de solidité silencieux. |
| `NOIR_UNSAFE_MISSING_SAFETY` | low | Un bloc `unsafe { ... }` sans commentaire `// Safety:` adjacent. Informatif ; ne fait pas échouer la CI au `--fail-on high` par défaut. |
<!-- END GENERATED NOIR RULE TABLE -->

### Garde-fous contre les faux positifs (Noir)

- **Les helpers assert / let-hop / confirm du même fichier** lient les indices `unsafe`.
- **Les noms de site d'appel** `constrain_*` / `confirm_*` / `verify_*` /
  `check_(non_)membership*` / `public_data_storage_read` créditent les arguments (avec
  détection de résultat inutilisé pour les vérifications jetées).
- **Non contraint intentionnel documenté** (nécessite un `// Safety:` adjacent) :
  `random()`, `avm::…`, et le libellé différé kernel/rollup/discovery.
- **`let` de tuple + flags assertés** lient les témoins merkle passés dans les vérifications d'appartenance.

Exemple :```console
$ noir-scan examples/noir_unconstrained.nr --include-examples
HIGH     NOIR_UNCONSTRAINED_WITNESS         noir_unconstrained.nr:16  fn=main  Unconstrained `unsafe` result `inv` in `main`
LOW      NOIR_UNSAFE_MISSING_SAFETY         noir_unconstrained.nr:16  fn=  `unsafe` block without a `// Safety:` comment
noir-scan: 2 finding(s) [1 high, 1 low] in 1 of 1 file(s) — fails (--fail-on high)

$ noir-scan examples/noir_constrained.nr --include-examples
noir-scan: no findings in 1 o1js or Noir file(s) — passes (--fail-on high)

## Licence

Apache-2.0. Voir [`LICENSE`](https://github.com/auditinfra-io/o1js-scan/blob/main/LICENSE).