1. Ce que fait réellement un guardrail de sécurité du code
OrcaRouter livre une famille de presetscode_security que vous appliquez
depuis le sélecteur de templates. Chacun est une règle de
guardrail ordinaire — à portée d’espace de travail,
ordonnée, attachable à n’importe quelle clé — réglée pour le code :
.env / Secret-File Block
Bloque les affectations de secrets de style
.env (DATABASE_URL=,
AWS_SECRET_ACCESS_KEY=, API_TOKEN=…) et les dumps de config multi-lignes
collés avant qu’ils n’atteignent le fournisseur. Se base sur la syntaxe
d’affectation, pas sur la valeur.License Compliance (copyleft)
Signale les requêtes transportant des en-têtes copyleft fort — tags SPDX GPL
/ AGPL / LGPL / SSPL ou noms de licence complets — afin qu’un relecteur
puisse confirmer que le code est sûr à mélanger dans une base de code
permissive. Flag-seulement.
GPL/AGPL Provenance (output)
Flag à l’étape output sur les suggestions du modèle qui portent des
signatures de provenance copyleft — un marqueur que le modèle a peut-être
régurgité des données d’entraînement copyleft dans le code généré.
Insecure-API Advisory
Annote le prompt d’un avis de sécurité lorsqu’il référence un sink à
haut risque —
eval( / exec( / os.system( / subprocess.run( /
pickle.loads( / child_process.exec(. Non-bloquant.Les presets
code_security sont déterministes — pure regex, aucun appel
réseau, sûrs sur le chemin à chaud. Les scanners réseau (recherche CVE, SBOM,
SAST) sont des connexions externes séparées, pas des presets. Voir
§3.2. Annotate — avertir le modèle sans changer le trafic
Les actions que vous configurez sur un guardrail sont block (rejeter l’appel, HTTP 400), mask (redacter la correspondance), et flag (journaliser seulement). La sécurité du code ajoute un quatrième comportement sous le capot : annotate, qui ne bloque ni ne masque. Quand une règle annotate correspond, la passerelle enregistre une courte note et le relais l’injecte en amont comme un avis système — afin que le modèle se voie dire, par exemple, “this request references a high-risk API (code eval, shell execution, or unsafe deserialization); prefer safer alternatives” — avant qu’il ne réponde. Le texte de l’utilisateur n’est jamais rejeté et jamais réécrit.Un exemple concret
Appliquez le preset Insecure-API Advisory à un guardrail et attachez-le à une clé. Puis envoyez du code qui appelle un sink dangereux :3. Décoration CVE et SBOM via scanners externes
La primitive d’avis se généralise. Connectez un scanner de sécurité du code comme fournisseur externe et ses findings empruntent le même chemin annotate :Recherche de CVE de dépendances (OSV)
Recherche de CVE de dépendances (OSV)
Extrait les imports et les pins de manifeste du texte de la requête et les
croise avec la base de données de vulnérabilités publique OSV. Un hit décore
le prompt avec, par exemple, “requests@2.0.0 has CVE-2014-1830 (HIGH).
Fixed in 2.20.0.” — afin que le modèle soit informé d’une vulnérabilité
connue dans un package qu’on lui a demandé d’utiliser. Gratuit et non
authentifié, donc il n’y a pas de champ de clé API. Par défaut annotate ;
vous pouvez le mettre sur flag ou block à la place.
Scanners SBOM et SAST
Scanners SBOM et SAST
Connectez un scanner SBOM (software bill-of-materials) ou SAST (analyse
statique) de la même façon que vous connectez n’importe quel fournisseur
externe — une URL de base plus des credentials, stockés chiffrés et masqués
en lecture. Chaque finding porte une identité stable, donc un finding que
vous avez déjà trié ne se redéclenche pas à chaque requête.
fail_open à false sur la règle pour fail closed
pour les politiques où un scan manqué est inacceptable.
4. Associer aux règles de secrets et de licence
Un guardrail de sécurité du code roule rarement seul. La forme courante est un guardrail avec quelques règles :| Objectif | Règle |
|---|---|
| Arrêter les credentials collés | .env / Secret-File Block (block) |
| Attraper les valeurs de secrets en ligne | Secrets Blocker (block) |
| Contrôler le code copyleft | License Compliance (flag) |
| Orienter les sinks dangereux | Insecure-API Advisory (annotate) |
5. Le configurer (console + rôles)
Tout ici est configuré dans la console, pas via la clé de relais. Les routes de gestion (/api/guardrail/*) s’authentifient avec votre session / token
d’accès, pas la clé de relais sk-. Les lectures — lister les guardrails et le
flux Matches — sont ouvertes à tout membre de l’espace de travail. Les
écritures (créer / modifier / supprimer) et le sandbox de test nécessitent
le rôle Developer ou au-dessus : le sandbox peut déclencher des appels de
modèle payants et des requêtes sortantes vers des fournisseurs, donc il est
contrôlé comme une écriture.
Créer le guardrail
Dans la console, ouvrez Guardrails → New guardrail. Le split-button vous
dépose dans la bibliothèque de templates — choisissez un preset Code
security comme point de départ.
Modifier librement
Un preset est une graine, pas un verrou. Réglez la regex, ajoutez une règle
Secrets Blocker, changez une action. Utilisez l’onglet Test pour prouver
qu’une règle se déclenche comme vous l’attendez contre un texte d’échantillon
avant de l’attacher à une clé.
Les findings atterrissent dans le flux Matches de l’espace de travail (type
de règle, action, étape, détail). La sous-chaîne correspondante n’est
enregistrée que lorsque Log raw content est activé — désactivé par défaut,
la posture conservatrice en matière de confidentialité. Voir
journalisation & confidentialité.
6. Où aller ensuite
- Bloquer les secrets — la règle compagne qui attrape les valeurs de credentials dans les arguments de requête.
- Actions — block, mask, flag, annotate et spotlight en profondeur.
- Compliance logger — gardez un enregistrement immuable de chaque finding de sécurité du code.
- Test & éval — prouvez que votre politique attrape le code connu-mauvais avant de la livrer.
- Référence Guardrails — le moteur complet.
- Sécuriser les agents IA — où les rails de sécurité du code s’inscrivent dans la pile de contrôle zero trust.
