Bonjour, je suis Mathias 👋

Interconnecter des trunks SIP d’opérateurs et des IPBX d’entreprise semble simple sur le papier. En pratique, c’est l’un des points de friction les plus coûteux d’une infrastructure VoIP : il faut sécuriser l’IPBX exposé sur Internet, gérer plusieurs opérateurs en parallèle, basculer en cas de panne, normaliser le routage, le tout sans grever le budget avec un SBC propriétaire opaque et fermé.

PK-SBC est une réponse open source à ce problème. Un Session Border Controller construit sur Kamailio, RTP Engine, Redis et PostgreSQL, conçu selon le principe KISS — Keep It Simple, Stupid — et éprouvé en production depuis 2012.

Deux releases le même jour, à vingt minutes d’intervalle : v1.0.1 puis v1.0.2. Les deux font le même travail — durcir pi-secured-setup lui-même. C’est un billet court pour expliquer ce qui a changé et pourquoi ça compte, parce qu’un outil de sécurité qui traîne ses propres vulnérabilités perd toute crédibilité.

Si vous découvrez le projet, l’article de présentation pose les bases : Guards, Scanners, audit trail.

v1.0.1 — amélioration qualité#

Trois axes :

pi en mode YOLO, c’est le filesystem sans frein, n’importe quelle commande exécutée, zéro garde-fou. Le créateur a fait ce choix sciemment. Mais quand votre projet contient des .env, des clés SSH ou un production.yaml, ce choix vous met en danger.

J’ai présenté pi-secured-setup il y a quelques jours. Guards, Scanners, audit trail, branchés dans l’agent. Depuis, j’ai regardé une autre extension : pi-permission-system, par MasuRii. Les deux sécurisent pi. Pas de la même façon.

Dans l’article précédent, j’ai présenté pi-secured-setup — une extension pi qui ajoute des Guards, des Scanners et un audit trail à votre agent de code IA. Elle est livrée avec des defaults pertinents : application de frontière, globbing de chemins protégés, classification de commandes bash, rédaction de secrets, vérification de skills.

Mais chaque projet a des risques uniques. Un shop Terraform n’a pas les mêmes règles qu’un monorepo Node.js. Une équipe avec des exigences de conformité strictes n’a pas la même granularité d’audit qu’un développeur solo.