ibcsc.beSite public, pages, formulaires et interfaces web servies directement par l’IBCSC.
Tests manuels ou automatisés à faible cadence, sans compte tiers, sans altération et sans effet sur la disponibilité.
Chercher avec mesure · signaler en sécurité
Une vulnérabilité mérite un canal clair, pas le silence.
L’IBCSC autorise la recherche de sécurité menée de bonne foi sur le périmètre explicitement indiqué ci-dessous. Cette politique fixe ce qui peut être vérifié, ce qui doit rester intact et la manière de coordonner un correctif sans exposer les utilisateurs.
Version 1.0
25 juillet 2026
Autorisation limitéeUniquement les actifs listés et les actions nécessaires, proportionnées et non destructives.
Canal directUn contact identifiable avec objet CVD, sans passer par le formulaire général d’incident.
Suivi annoncéAccusé de réception, qualification, correction et clôture avec objectifs de délai.
Aucune primeLa politique n’est pas un bug bounty et ne promet aucune rémunération.
Le périmètre est explicite.
Un domaine visible n’implique pas une autorisation générale. Si un actif n’est pas listé comme ouvert, demandez une confirmation avant toute action.
Autres actifsSous-domaines non listés, adresses IP, réseau local, équipements, comptes sociaux et services de fournisseurs.
Aucune autorisation. Contactez le propriétaire concerné ou demandez une confirmation écrite à l’IBCSC.
Toujours hors périmètre
- Données et comptes appartenant à un autre utilisateur
- Postes, téléphones et comptes personnels des membres
- Fournisseurs, hébergeurs, registrars et services reliés par un lien externe
- Bâtiments, accès physiques, personnes et ingénierie sociale
- Réseaux ou adresses IP qui ne sont pas explicitement attribués dans cette page
- Toute activité interdite par le droit applicable
Prouver le risque sans créer un nouvel incident.
La démonstration doit s’arrêter dès que l’existence du problème peut raisonnablement être établie. Une preuve minimale vaut mieux qu’une exploitation complète.
Ce que vous pouvez faire
- Consulter et manipuler uniquement vos propres données et comptes de test
- Utiliser des requêtes manuelles ou un scanner à faible cadence
- Vérifier une hypothèse avec le minimum de requêtes nécessaires
- Conserver des captures expurgées et des horodatages utiles
- Tester une validation d’entrée avec une charge inoffensive
- Signaler un contrôle d’accès sans ouvrir le contenu d’un tiers
- Demander une confirmation écrite lorsque le périmètre est ambigu
Ce qui reste interdit
- Déni de service, test de charge ou saturation de ressources
- Bruteforce, credential stuffing ou contournement répété d’une limite
- Phishing, prétexte, appel trompeur ou autre ingénierie sociale
- Accès, copie, modification ou suppression de données de tiers
- Installation de malware, persistance, porte dérobée ou commande distante
- Pivot, mouvement latéral ou exploration d’un réseau interne
- Envoi massif de courriers, spam ou test des comptes de messagerie
- Publication d’un secret ou de détails exploitables avant coordination
- Dégradation de journaux, traces, sauvegardes ou mécanismes de sécurité
Règle d’arrêt : si des données personnelles, un secret, une session tierce ou un accès non prévu apparaît, arrêtez immédiatement, ne poursuivez pas l’exploration et signalez uniquement le minimum nécessaire.
Envoyer un rapport exploitable et sobre.
Utilisez le courrier électronique pour le premier contact et placez [CVD] dans l’objet. Ne joignez pas de dump, mot de passe, clé privée ou ensemble de données. Si un transfert sensible est réellement nécessaire, l’IBCSC proposera un canal adapté après l’accusé de réception.
Contact sécurité info@ibcsc.beUne adresse de réponse peut être pseudonyme. Elle doit toutefois permettre la coordination pendant le traitement.
Contact lisible par les outils/.well-known/security.txt
Le rapport devrait contenir
- 01
L’actif et l’URL exacte concernés
- 02
Un résumé du comportement attendu et du comportement observé
- 03
Les étapes minimales permettant de reproduire le problème
- 04
L’impact plausible sur la confidentialité, l’intégrité ou la disponibilité
- 05
La date, l’heure, le navigateur ou l’environnement utilisé
- 06
Une preuve expurgée qui ne contient ni secret ni donnée de tiers
- 07
Votre préférence concernant le suivi, le crédit public ou l’anonymat
Le rapport suit une chaîne de responsabilité.
Chaque étape produit un état compréhensible. Une vulnérabilité ne disparaît pas dans une boîte de réception et une correction n’est pas annoncée avant vérification.
-
01
Réception
Le rapport est enregistré, son périmètre vérifié et les pièces manifestement excessives isolées.
-
02
Qualification
L’IBCSC tente de reproduire le problème avec une méthode proportionnée et évalue son impact.
-
03
Mesure immédiate
Une limitation temporaire peut être appliquée lorsque le risque d’exploitation justifie une action rapide.
-
04
Correction
Le correctif est développé, testé, déployé et documenté avec les dépendances concernées.
-
05
Clôture
Le déclarant reçoit un état final et la publication éventuelle est coordonnée selon le risque.
Objectifs de communication
Ces délais sont des objectifs de service, pas une garantie de correction. Ils peuvent varier selon la gravité, les dépendances et les capacités de l’association.
- Accusé de réception humain
- 5 jours ouvrables
- Première qualification
- 10 jours ouvrables
- Mise à jour lorsque le dossier reste ouvert
- Tous les 15 jours ouvrables
- Fenêtre de coordination envisagée
- Jusqu’à 90 jours
La priorité dépend de l’impact vérifiable.
L’évaluation considère la facilité d’exploitation, les droits requis, l’étendue, les données concernées et les conséquences sur le service. Un score automatique ne remplace pas le contexte.
Critique
Compromission directe et reproductible de données sensibles, d’administration ou d’un service essentiel.
Action immédiateÉlevée
Accès significatif, prise de compte ou altération importante avec conditions réalistes.
Traitement prioritaireModérée
Impact limité, conditions multiples ou contrôle compensatoire déjà disponible.
Planification rapideFaible
Exposition réduite, information mineure ou amélioration de défense en profondeur.
Suivi normalUn signal de scanner n’est pas toujours une vulnérabilité.
L’IBCSC examine chaque rapport de bonne foi, mais demande un impact concret et reproductible. Cette règle limite le bruit sans écarter un risque réel.
Généralement insuffisant sans impact démontré
- En-tête HTTP manquant présenté sans scénario d’exploitation
- Version ou bannière logicielle sans vulnérabilité applicable
- Rapport automatisé brut sans validation manuelle
- Self-XSS qui nécessite que la victime exécute elle-même le code
- Clickjacking sur une page sans action sensible
- Recommandation de configuration ou de chiffrement sans risque pratique identifié
Une combinaison de plusieurs faiblesses peut modifier l’évaluation. Expliquez la chaîne et arrêtez-vous avant d’accéder à une donnée ou fonction non autorisée.
La publication est une décision coordonnée.
Le premier objectif est de réduire le risque pour les utilisateurs. La confidentialité, le crédit et le calendrier sont discutés avec le déclarant, sans promesse automatique de publication.
Confidentialité
L’IBCSC limite l’accès au rapport aux personnes qui en ont besoin pour analyser, corriger ou défendre un droit.
Publication
Aucun détail exploitable ne doit être publié avant une coordination écrite. Si la procédure légale du CCB est utilisée, ses règles d’autorisation de publication restent applicables.
Crédit
Une mention publique peut être proposée après correction, uniquement avec l’accord du déclarant et sans révéler une information dangereuse.
Désaccord
En cas de difficulté de coordination, l’une ou l’autre partie peut demander l’aide du CCB en tant que coordinateur de confiance.
Conservation
Les rapports et preuves sont minimisés, protégés et conservés selon leur utilité de sécurité, de preuve et les règles de confidentialité du site.
La procédure belge du CCB reste disponible.
Une personne qui souhaite utiliser la procédure légale belge doit notifier à la fois l’organisation responsable et le CCB, respecter les conditions de nécessité et de proportionnalité et suivre les délais officiels.
- 24 hNotification simplifiée
Après la découverte raisonnable d’une vulnérabilité potentielle, transmettre l’identification du système et une description simple à l’organisation et au CCB.
- 72 hNotification complète
Compléter le signalement auprès de l’organisation et du CCB conformément à la procédure publiée par celui-ci.
Cette page décrit la politique interne de l’IBCSC et fournit une orientation générale. Elle ne constitue pas un conseil juridique et ne remplace pas les conditions officielles du CCB, notamment celles relatives à la publication publique.
Questions avant de commencer.
En cas de doute sur le périmètre ou une méthode, demandez une confirmation écrite avant le test.
Puis-je utiliser un scanner automatique ?
Oui sur ibcsc.be, à faible cadence et sans test de charge, bruteforce ou exploitation automatique. Un rapport doit ensuite être vérifié manuellement et expliquer l’impact.
L’IBCSC paie-t-il une récompense ?
Non. Cette politique n’est pas un bug bounty et aucune rémunération n’est prévue. Une reconnaissance publique peut être discutée après correction.
Puis-je publier après 90 jours ?
Pas automatiquement. Le calendrier doit être coordonné par écrit. Si vous utilisez la procédure légale belge, les conditions et autorisations du CCB concernant la publication s’appliquent.
Que faire si la vulnérabilité concerne un tiers ?
Arrêtez tout test sur ce tiers et contactez son propriétaire. Le CCB peut également agir comme coordinateur de confiance lorsque la bonne destination est difficile à identifier.
Un bon signalement réduit le risque dès le premier message.
Vérifiez le périmètre, conservez une preuve minimale et utilisez le canal CVD. Pour une attaque en cours ou une victime, utilisez plutôt les voies officielles d’incident présentées par l’Observatoire.