Le guide 2026 pour sécuriser les applications PowerBuilder
Renforcer la sécurité, réduire les risques et démontrer la conformité
Un guide complet destiné aux équipes de développement, responsables sécurité et responsables conformité travaillant avec des applications PowerBuilder.
1. Introduction
À qui s’adresse ce guide
Aux équipes en charge des applications PowerBuilder : développeurs, architectes, chefs de projet et responsables d’exploitation. Il explique comment renforcer la sécurité des applications et sécuriser leur cycle de vie (dev/test/prod).
Aux équipes « sécurité » et « conformité » : responsables sécurité applicative, RSSI, équipes GRC, auditeurs internes ou externes. Il aide à évaluer le niveau de sécurité d’une application PowerBuilder et à préparer un audit ou une mise en conformité.
Pourquoi lire ce guide
Les applications PowerBuilder sont au cœur de processus critiques (finance, santé, logistique, industrie, secteur public). Elles doivent répondre maintenant à des exigences de sécurité et de conformité plus élevées qu'au moment de leur conception : protection du poste client, authentification forte, chiffrement, contrôle des accès, traçabilité, rapports d'audits, etc.
Dans ce contexte, les organisations doivent simultanément répondre à trois objectifs :
- Renforcer la sécurité sans réécrire l’application, en s’appuyant sur les versions récentes de PowerBuilder et des outils spécialisés.
- Identifier, prioriser et corriger les principaux risques afin de réduire l’exposition aux vulnérabilités et de passer les contrôles.
- Démontrer la conformité face à des standards et exigences internes ou externes (ISO, NIST, PCI, HIPAA, SOX, RGPD), en fournissant des preuves vérifiables.
Ce que vous allez obtenir
En lisant ce guide, vous disposerez :
- d’un plan d’action pour renforcer la sécurité de vos applications PowerBuilder, depuis l’intégrité des exécutables jusqu’au contrôle d’accès et à l’audit ;
- d’un fil conducteur “compliance” reliant ces mesures techniques aux attentes des standards et réglementations.
Ce guide est modulaire et peut être lu de façon sélective.
Chaque chapitre est indépendant et structuré pour faciliter une lecture rapide : contextes, menaces, objectifs techniques, fonctionnalités de chaque outil, conformité avec les principaux standards, éléments de preuve.
Il peut servir de base à un projet de sécurisation ou de mise en conformité.
Développeurs & architectes
Renforcer la sécurité du code et du cycle de vie de l'application, sans refonte complète.
Chapitres recommandés
2. Exécutables ·
3. Chiffrement ·
4. Protocoles ·
5. API ·
6. Navigateur ·
7. Build
RSSI & responsables sécurité
Évaluer le niveau de sécurité d'une application PowerBuilder et piloter le plan de remédiation.
Chapitres recommandés
2. Exécutables ·
8. Authentification ·
9. PowerServer ·
10. Conformité ·
Check-lists
Équipes GRC & auditeurs
Préparer un audit ou une mise en conformité et constituer le dossier de preuves associé.
2. Sécuriser les exécutables et les composants déployés
Contexte et risques : Les applications PowerBuilder sont souvent déployées via des mécanismes de distribution internes (partages réseau, packages, outils de déploiement généralistes) et sur une confiance implicite dans l'exécutable livré.
Avec le durcissement des postes de travail, un exécutable non signé ou non traçable est souvent bloqué, tandis qu’un binaire compromis peut être accepté si les contrôles sont faibles.
Ce risque dépasse la facilité de déploiement : il correspond à un scénario de compromission de la chaîne logicielle, comme l’illustre l’incident 3CX en 2023 : une application légitime a été infectée et diffusée à grande échelle, ouvrant la voie à de multiples intrusions avant détection.
Par ailleurs, les attaquants cherchent à tirer parti de la confiance accordée aux éléments signés : Sophos a documenté 133 pilotes Windows malveillants, dont 100 étaient signés via le programme WHCP.
La parade consiste à mettre en place une chaîne de confiance vérifiable : analyser avant publication, signer systématiquement les artefacts, tracer les versions déployées et limiter les droits de publication.
Avec le durcissement des postes de travail, un exécutable non signé ou non traçable est souvent bloqué, tandis qu’un binaire compromis peut être accepté si les contrôles sont faibles.
Ce risque dépasse la facilité de déploiement : il correspond à un scénario de compromission de la chaîne logicielle, comme l’illustre l’incident 3CX en 2023 : une application légitime a été infectée et diffusée à grande échelle, ouvrant la voie à de multiples intrusions avant détection.
Par ailleurs, les attaquants cherchent à tirer parti de la confiance accordée aux éléments signés : Sophos a documenté 133 pilotes Windows malveillants, dont 100 étaient signés via le programme WHCP.
La parade consiste à mettre en place une chaîne de confiance vérifiable : analyser avant publication, signer systématiquement les artefacts, tracer les versions déployées et limiter les droits de publication.
Objectifs
- Mettre en place un processus de compilation reproductible et versionné, associé à une version identifiable de l’application.
- Signer systématiquement les exécutables, bibliothèques et packages de déploiement à l’aide d’un certificat approuvé par l’organisation.
- Vérifier l’intégrité des artefacts (par exemple via un hash) avant leur diffusion.
- Tracer les versions déployées, leurs empreintes, leurs dates de mise en production et les responsables associés.
- Restreindre et auditer les droits de publication et d’administration liés au déploiement et à la sécurité.
Fonctionnalités et outils
| Intégrer la signature de code dans le processus de compilation et de déploiement, y compris pour les projets PowerServer et PowerClient. | PB |
| Utiliser des certificats à validation étendue (certificats EV) pour signer les applications, afin d’améliorer la confiance des utilisateurs et la compatibilité avec les politiques de sécurité modernes. | PB |
| Sécuriser les livraisons en analysant le code PowerBuilder et en détectant les vulnérabilités et mauvaises pratiques à l’aide de règles de sécurité (SAST) dédiées à PowerBuilder. | VE |
| Détecter les identifiants/mots de passe codés en dur, les clés de chiffrement et les adresses IP dans le code afin de réduire le risque de fuite par décompilation ou copie de scripts de déploiement. | VE |
Conformité
Ce chapitre couvre généralement les exigences liées à l’intégrité logicielle et au contrôle du cycle de publication, fréquemment présentes dans des standards tels qu’ISO 27001 et dans des environnements soumis à SOX. Standards de sécurité et conformité
Preuves
- Procédure de signature (certificat, horodatage, responsabilités) et preuve d’exécution dans la chaîne de build.
- Rapport Visual Expert associé à la version signée (vulnérabilités, niveaux de sévérité, corrections).
- Historique d’audit Visual Guard sur les opérations sensibles (administration, modifications des autorisations).
3. Chiffrer les données au repos et en transit
Contexte et risques : Les applications PowerBuilder traitent souvent des données sensibles (métier, personnelles, médicales, financières, etc.). Ces données transitent entre le client, la base de données et les composants intermédiaires. Elles se retrouvent également dans des exports, des fichiers temporaires, des journaux applicatifs et des sauvegardes.
La perte de disponibilité des systèmes et des données est un problème courant : les ransomwares sont présents dans 44 % des violations confirmées (Verizon 2025 DBIR).
Mais ces attaques peuvent s'accompagner d'une exfiltration préalable d'informations (« double extorsion ») : l'incident devient alors une fuite de données et une crise de conformité (CISA – Ransomware Guide).
Dans le secteur de la santé, l’affaire MD Anderson a conduit à de lourdes sanctions réglementaires en raison du stockage non chiffré (postes de travail, ordinateurs portables, supports amovibles).
La solution consiste à rendre les données illisibles hors de leur contexte : chiffrement au repos, chiffrement des communications, gestion rigoureuse des clés et limitation des privilèges associés.
La perte de disponibilité des systèmes et des données est un problème courant : les ransomwares sont présents dans 44 % des violations confirmées (Verizon 2025 DBIR).
Mais ces attaques peuvent s'accompagner d'une exfiltration préalable d'informations (« double extorsion ») : l'incident devient alors une fuite de données et une crise de conformité (CISA – Ransomware Guide).
Dans le secteur de la santé, l’affaire MD Anderson a conduit à de lourdes sanctions réglementaires en raison du stockage non chiffré (postes de travail, ordinateurs portables, supports amovibles).
La solution consiste à rendre les données illisibles hors de leur contexte : chiffrement au repos, chiffrement des communications, gestion rigoureuse des clés et limitation des privilèges associés.
Objectifs
- Identifier les données sensibles traitées par l’application et leurs emplacements (base de données, fichiers, exports, journaux, sauvegardes).
- Chiffrer les secrets et paramètres sensibles afin d’éviter leur apparition en clair dans le code, les scripts et les fichiers de configuration.
- Chiffrer les communications entre le poste client, les serveurs applicatifs et la base de données, en appliquant les modes de chiffrement recommandés par l’entreprise.
- Sécuriser le stockage local et les exports sensibles lorsque le poste client peut contenir des données critiques.
- Vérifier que les algorithmes, tailles de clés et paramètres cryptographiques utilisés sont conformes et maintenus.
Fonctionnalités et outils
| Chiffrer les propriétés de connexion des objets transaction et générer une chaîne de connexion chiffrée à l’aide du Secure Connection Encryptor, afin d’éviter les identifiants en clair dans les scripts ou fichiers. | PB |
| Chiffrer les connexions SQL Server en activant le chiffrement TLS/« Strict » dans le pilote SQL Server et côté base de données, et en validant les certificats. | PB |
| Encoder et chiffrer les données à l’aide des objets CoderObject et CrypterObject. | PB |
| Analyser le code PowerBuilder afin de détecter l’utilisation de DES/3DES, les fonctions de hachage obsolètes (SHA-1/MD5, etc.), les modes de chiffrement, les clés codées en dur ou les tailles de clés insuffisantes. | VE |
| Réduire l’exposition en contrôlant précisément l’accès aux données et fonctions sensibles via un modèle de permissions et de rôles. | VG |
| Journaliser l’accès aux données sensibles et les opérations critiques. Activer une traçabilité détaillée (qui a fait quoi, quand et depuis où). Traçabilité & audit | VG |
Conformité
Ce chapitre contribue aux exigences de confidentialité et de protection des données présentes dans ISO 27001, NIST SP 800-53, PCI DSS et, selon le contexte, HIPAA et RGPD. Standards de sécurité et conformité
Preuves
- Configuration du chiffrement des connexions (profils BD, paramètres applicatifs) et procédures de rotation des secrets.
- Rapport Visual Expert démontrant l’absence de secrets codés en dur et la réduction des risques liés à la cryptographie.
- Exports de la matrice des permissions et historiques d’audit Visual Guard pour les périmètres sensibles.
4. Adopter des protocoles réseau modernes et sécurisés
Contexte et risques : L’infrastructure des applications PowerBuilder a évolué au fil des années (drivers, middlewares, proxys, passerelles).
Les risques apparaissent en cas d’utilisation de protocoles anciens, de suites cryptographiques faibles ou de canaux non chiffrés : interception ou manipulation des flux (authentification, données, jetons), ou blocage de l’application si un proxy, un serveur ou une base de données impose TLS 1.2+ ou un mode strict. L’incident de sécurité devient alors un problème de production.
La publication NIST SP 800-52r2 recommande ainsi TLS 1.2 comme minimum et définit des exigences de configuration afin de réduire les attaques par rétrogradation et les erreurs de chiffrement.
En matière de conformité, PCI DSS impose l’utilisation d’une cryptographie robuste pour protéger les données de paiement lors de leur transmission sur des réseaux ouverts.
La solution consiste à inventorier les flux, renforcer les paramètres TLS et standardiser les composants réseau.
Les risques apparaissent en cas d’utilisation de protocoles anciens, de suites cryptographiques faibles ou de canaux non chiffrés : interception ou manipulation des flux (authentification, données, jetons), ou blocage de l’application si un proxy, un serveur ou une base de données impose TLS 1.2+ ou un mode strict. L’incident de sécurité devient alors un problème de production.
La publication NIST SP 800-52r2 recommande ainsi TLS 1.2 comme minimum et définit des exigences de configuration afin de réduire les attaques par rétrogradation et les erreurs de chiffrement.
En matière de conformité, PCI DSS impose l’utilisation d’une cryptographie robuste pour protéger les données de paiement lors de leur transmission sur des réseaux ouverts.
La solution consiste à inventorier les flux, renforcer les paramètres TLS et standardiser les composants réseau.
Objectifs
- Recenser les flux réseau utilisés par l’application et les protocoles effectivement négociés (versions TLS, suites cryptographiques, certificats).
- Éliminer les protocoles obsolètes et imposer des versions et configurations TLS alignées avec la politique de sécurité de l’organisation.
- Mettre en œuvre une authentification mutuelle (certificat client) lorsque le contexte l’exige, notamment pour des API internes ou des partenaires.
- Standardiser la validation des certificats et la gestion des erreurs afin d’éviter les contournements et dégradations silencieuses.
- Tester la compatibilité avec les proxys, passerelles et protections réseau afin d’éviter que les contrôles de sécurité ne bloquent la production.
Fonctionnalités et outils
| Prendre en charge TLS 1.3 et HTTP/2 avec les objets HTTPClient et RESTClient. | PB |
| Prendre en charge l’authentification TLS mutuelle (certificat client), par exemple pour des API internes ou des services partenaires. | PB |
| Identifier les points de communication du code (clients HTTP, appels à des services web, gestion des certificats). | VE |
| Détecter les usages ne prenant pas en charge des protocoles de sécurité modernes (par exemple, appels à des services SOAP/INET ou utilisation d’API d’authentification non sécurisées) afin de prioriser les refactorisations réseau. | VE |
| Utiliser des services web standardisés pour l’authentification, le contrôle d’accès et la journalisation via un serveur dédié, afin de centraliser les contrôles et de limiter la logique de sécurité côté client. | VG |
Conformité
Ce chapitre contribue aux contrôles liés à la sécurité des communications définis dans ISO 27001 et le NIST, et répond fréquemment aux exigences d’audit dans les secteurs de la finance et de la santé. Standards de sécurité et conformité
Preuves
- Paramétrage TLS (versions, suites, certificats, mTLS le cas échéant) et résultats des tests de connectivité.
- Liste des points d’exposition de l’application et justification des protocoles utilisés.
- Preuve d’intégration d’une authentification centralisée (Identity Server) pour les flux exposés. Comment utiliser l’API Identity Server ?
5. Sécuriser les échanges avec les services externes et les API
Contexte et risques : Suite à la modernisation des systèmes, de nombreuses applications PowerBuilder consomment des API, communiquent avec des plateformes SaaS ou automatisent des échanges via des services internes ou des mécanismes de messagerie.
Cette ouverture accélère les projets, mais elle crée aussi des points d’entrée : contrôles d’accès incomplets, jetons trop permissifs, validation insuffisante des entrées ou secrets partagés entre environnements. Une application appelant des API avec un jeton stocké localement ou partagé entre les environnements (dev/test/prod) peut ouvrir la voie à une attaque en cas de compromission d’un poste ou de fuite de configuration.
L’OWASP rappelle que la faiblesse la plus critique côté API reste l’absence de contrôles d’accès au niveau objet.
Du point de vue des processus métiers, le rapport FBI IC3 2024 chiffre les pertes liées aux emails business compromis à 2,77 Md$ (fraudes aux virements, détournement de factures, etc.).
L’incident Optus (2022), qui a touché environ 10 millions de clients, illustre l’ampleur de l’exposition lorsque des données clients deviennent accessibles via Internet.
La solution consiste à standardiser l’authentification, limiter les privilèges et la surface exposée, et contrôler les échanges.
Cette ouverture accélère les projets, mais elle crée aussi des points d’entrée : contrôles d’accès incomplets, jetons trop permissifs, validation insuffisante des entrées ou secrets partagés entre environnements. Une application appelant des API avec un jeton stocké localement ou partagé entre les environnements (dev/test/prod) peut ouvrir la voie à une attaque en cas de compromission d’un poste ou de fuite de configuration.
L’OWASP rappelle que la faiblesse la plus critique côté API reste l’absence de contrôles d’accès au niveau objet.
Du point de vue des processus métiers, le rapport FBI IC3 2024 chiffre les pertes liées aux emails business compromis à 2,77 Md$ (fraudes aux virements, détournement de factures, etc.).
L’incident Optus (2022), qui a touché environ 10 millions de clients, illustre l’ampleur de l’exposition lorsque des données clients deviennent accessibles via Internet.
La solution consiste à standardiser l’authentification, limiter les privilèges et la surface exposée, et contrôler les échanges.
Objectifs
- Identifier les intégrations (API, services internes, SMTP) et les données échangées.
- Mettre en œuvre une authentification standardisée entre systèmes (par exemple OAuth).
- Limiter strictement les privilèges associés aux jetons et aux comptes techniques.
- Supprimer les secrets codés en dur et organiser leur stockage, leur rotation et leur révocation.
- Éviter l’exposition d’informations sensibles dans les messages et les journaux.
- Contrôler et tracer les opérations à fort impact (exports, transmissions, actions critiques).
- Mettre en place des mécanismes de détection des abus.
Fonctionnalités et outils
| Privilégier les intégrations REST via RESTClient. Si SOAP est requis, utiliser HTTPClient avec TLS 1.2+ et une authentification forte, et éviter les implémentations SOAP héritées. | PB |
| Utiliser le protocole d’autorisation OAuth 2.0 afin de s’aligner sur les pratiques courantes d’intégration d’API. Objet RESTClient enrichi | PB |
|
Recourir à l’authentification par jeton (jetons OAuth 2.0 de type bearer) plutôt qu’à la transmission d’identifiants/mots de passe, et gérer les jetons via HTTPClient et OAuthClient (évolutions HTTPClient et OAuthClient – Nouveautés). |
PB |
| Prendre en charge nativement SMTP et utiliser des méthodes d’authentification modernes (dont XOAUTH2). Réduire les implémentations internes fragiles. Support natif de l’e-mail (client SMTP) | PB |
| Analyser le code afin d’identifier les attaques potentielles par injection de code SQL, commandes système ou chemins, ainsi que les secrets codés en dur, une gestion insuffisante des erreurs ou l’absence de contrôles sur les données échangées. | VE |
| Limiter les personnes autorisées à déclencher des appels sensibles (exports, envois, actions métiers). | VG |
| Tracer ces opérations à des fins d’audit et d’investigation. Surveiller en temps réel et déclencher des alertes en cas d’événements critiques ou inhabituels. | VG |
Conformité
Les contrôles liés aux intégrations contribuent aux exigences de sécurité et de traçabilité d’ISO 27001, du NIST, de PCI DSS et, selon le périmètre, d’HIPAA. Standards de sécurité et conformité
Preuves
- Inventaire des intégrations (API, SMTP, services internes) et des méthodes d’authentification utilisées (OAuth, certificats, etc.). Objet RESTClient enrichi – Nouveautés – Support natif de l’e-mail (client SMTP) – Nouveautés
- Rapport Visual Expert attestant de l’absence de secrets codés en dur et de la correction des principaux risques. Détecter les vulnérabilités de sécurité dans le code PowerBuilder
- Journaux Visual Guard montrant l’exécution des opérations sensibles et les éventuelles alertes. Traçabilité et audit
6. Réduire la surface d’attaque liée au navigateur embarqué
Contexte et risques : Le navigateur embarqué dans une application PowerBuilder peut être utilisé pour afficher du contenu HTML, intégrer un portail ou faciliter une authentification via une page web.
Ces intégrations reposent parfois sur des composants historiques. Microsoft a mis fin au support d’IE11 en juin 2022 et recommande désormais l’utilisation d’Edge en mode IE. Conserver d’anciens contrôles web crée un risque de vulnérabilités et d’exécution de contenu indésirable.
La documentation Microsoft rappelle aussi que le contrôle WebBrowser s’exécute en mode « full trust » et n’empêche pas l’exécution de scripts ou de contenus potentiellement dangereux provenant de serveurs externes.
Des vulnérabilités du moteur MSHTML ont déjà été exploitées lors d’attaques ciblées, comme CVE-2021-40444, qui a fait l’objet d’une alerte CISA.
Dans ce contexte, il est recommandé de limiter les contenus web accédés, d’isoler le composant et de migrer vers un moteur moderne et supporté.
Ces intégrations reposent parfois sur des composants historiques. Microsoft a mis fin au support d’IE11 en juin 2022 et recommande désormais l’utilisation d’Edge en mode IE. Conserver d’anciens contrôles web crée un risque de vulnérabilités et d’exécution de contenu indésirable.
La documentation Microsoft rappelle aussi que le contrôle WebBrowser s’exécute en mode « full trust » et n’empêche pas l’exécution de scripts ou de contenus potentiellement dangereux provenant de serveurs externes.
Des vulnérabilités du moteur MSHTML ont déjà été exploitées lors d’attaques ciblées, comme CVE-2021-40444, qui a fait l’objet d’une alerte CISA.
Dans ce contexte, il est recommandé de limiter les contenus web accédés, d’isoler le composant et de migrer vers un moteur moderne et supporté.
Objectifs
- Recenser les écrans utilisant un navigateur, les contenus attendus et les URL autorisées.
- Migrer vers un navigateur moderne et supprimer les composants non supportés.
- Limiter strictement la navigation, l’ouverture d’URL et l’exécution de scripts, en particulier pour les contenus provenant de serveurs externes.
- Superviser les échanges entre l’application et les pages web (interactions JavaScript) afin d’éviter toute exécution ou accès non souhaité.
- Désactiver le débogage à distance en production.
Fonctionnalités et outils
| Utiliser le contrôle WebBrowser modernisé basé sur Microsoft Edge WebView2, avec les améliorations fonctionnelles associées. | PB |
| Tirer parti des améliorations du WebBrowser pour l’exécution JavaScript et l’interaction avec les pages. | PB |
| Activer le débogage à distance du WebBrowser à des fins de diagnostic. Cette fonctionnalité doit être strictement contrôlée et désactivée en production. | PB |
| Détecter l’utilisation d’un navigateur OLE ou de composants obsolètes, plus exposés aux vulnérabilités et aux incompatibilités de sécurité. | VE |
| Recenser et analyser les usages du WebBrowser (ouverture d’URL, exécution de scripts, manipulation de contenu) afin d’identifier les écrans à risque et de prioriser les corrections. | VE |
| Restreindre l’accès aux écrans ou fonctions intégrant du contenu web. | VG |
| Tracer et auditer les opérations sensibles associées au navigateur. | VG |
| Surveiller en temps réel l’accès aux écrans et fonctions affichant du contenu web et notifier les équipes en cas de comportement anormal. | VG |
Conformité
Ce chapitre répond aux exigences liées à la réduction de la surface d’attaque et au contrôle des accès, généralement présentes dans ISO 27001 et le NIST. Standards de sécurité et conformité
Preuves
- Liste des écrans intégrant un WebBrowser, avec les mesures de durcissement appliquées (URL autorisées, débogage à distance désactivé en production).
- Rapport Visual Expert sur les points d’entrée web identifiés et les corrections apportées.
- Éléments de preuve Visual Guard attestant du contrôle d’accès et de l’audit sur ces écrans et fonctions. Traçabilité et audit
7. Sécuriser la chaîne de build et de déploiement
Contexte et risques : La sécurité d’une application ne se limite pas à son code source : elle dépend aussi de la chaîne qui produit et publie les artefacts (serveurs de build, scripts, dépendances, comptes de service, clés de signature, référentiels, processus de mise en production).
Lorsqu’un maillon est compromis, l’attaquant peut injecter un code malveillant dans une mise à jour et toucher l’ensemble des utilisateurs (serveur de build mutualisé, compte de service de déploiement, stockage des certificats ou des clés de signature, etc.).
L’incident SolarWinds a illustré ce scénario à grande échelle, via une compromission de la chaîne de fabrication et de distribution d’un logiciel largement déployé.
De façon plus générale, le DBIR 2025 souligne que l’implication d’un tiers est présente dans 30 % des violations analysées, contre environ 15 % l’année précédente, renforçant l’importance du contrôle des dépendances et des accès partagés.
La réponse recommandée combine des contrôles d’intégrité (signature, empreintes/hash, SBOM), la réduction des privilèges des comptes techniques et une gouvernance des secrets (rotation, détection des fuites, révocation) alignée avec les pratiques DevOps.
Lorsqu’un maillon est compromis, l’attaquant peut injecter un code malveillant dans une mise à jour et toucher l’ensemble des utilisateurs (serveur de build mutualisé, compte de service de déploiement, stockage des certificats ou des clés de signature, etc.).
L’incident SolarWinds a illustré ce scénario à grande échelle, via une compromission de la chaîne de fabrication et de distribution d’un logiciel largement déployé.
De façon plus générale, le DBIR 2025 souligne que l’implication d’un tiers est présente dans 30 % des violations analysées, contre environ 15 % l’année précédente, renforçant l’importance du contrôle des dépendances et des accès partagés.
La réponse recommandée combine des contrôles d’intégrité (signature, empreintes/hash, SBOM), la réduction des privilèges des comptes techniques et une gouvernance des secrets (rotation, détection des fuites, révocation) alignée avec les pratiques DevOps.
Objectifs
- Définir un pipeline standard intégrant le build, les tests, l’analyse de sécurité, la signature et le déploiement, avec des critères de passage explicites.
- Rendre les builds reproductibles en maîtrisant les versions des outils, les dépendances et les paramètres de compilation.
- Sécuriser les comptes de service, les secrets et les clés de signature utilisés par le pipeline, et en limiter les privilèges.
- Conserver les artefacts et rapports associés à chaque version afin de fournir des preuves d’audit et de faciliter les investigations.
Fonctionnalités et outils
| Passer au format solution afin de convertir le code en texte et de faciliter l’intégration avec les outils de versioning et d’automatisation. | PB |
| Utiliser PBAutoBuild pour simplifier les scripts de build et standardiser les pipelines. | PB |
| Réduire les conflits de fusion et faciliter les revues et la traçabilité avec PowerBuilder 2025. | PB |
| Industrialiser l’analyse statique des vulnérabilités (SAST) à chaque build : déclenchement, critères d’acceptation et tableaux de bord. | VE |
| Vérifier qu’aucune exception n’est ignorée et que les traces console ne sont pas utilisées en production. Détecter les vulnérabilités de sécurité dans le code PowerBuilder | VE |
| Automatiser le déploiement des paramètres de contrôle d’accès (droits, rôles, etc.) entre les environnements (dev/test/prod) afin de réduire les écarts et les erreurs. | VG |
Conformité
Ce chapitre contribue aux exigences de gouvernance et de traçabilité associées à ISO 27001 et, le cas échéant, aux exigences de contrôle interne (SOX). Standards de sécurité et conformité
Preuves
- Définition du pipeline (build, tests, analyse VE, signature, déploiement) et conservation des artefacts. PBAutoBuild s’intègre avec PBC
- Historique des rapports Visual Expert par version livrée, avec suivi des actions correctives. Détecter les vulnérabilités de sécurité dans le code PowerBuilder
- Exports Visual Guard (audit/droits) associés aux versions et aux environnements.
8. Renforcer l’authentification et le contrôle des accès
Contexte et risques : Pour authentifier leurs utilisateurs, beaucoup d'applications PowerBuilder utilisent encore des comptes de type « login/mots de passe » stockés dans la base de l'application.
La bonne stratégie consiste à centraliser les comptes utilisateurs sur un seul stockage d'identité — par exemple Active Directory ou Entra ID — et ajouter un niveau de protection supplémentaire pour les applications sensible avec une authentification forte (MFA).
- L'authentification par mot de passe offre un niveau de sécurité limité (mot de passe faible, comptes partagés) et introduit un risque, car l'identité est devenue un vecteur d'attaque important : 22 % des violations étudiées dans le DBIR 2025 ont débuté par l'usage d'identifiants compromis.
- Cette approche s'accompagne souvent d'une gestion de comptes utilisateurs spécifiques à chaque application (« Silo ») et augmente les couts d'administration.
- Elle augmente aussi le risque d'anomalies car les administrateurs ont plus de comptes à gérer et surveiller (comptes inactifs, privilèges excessifs, absence de séparation des tâches, etc.).
La bonne stratégie consiste à centraliser les comptes utilisateurs sur un seul stockage d'identité — par exemple Active Directory ou Entra ID — et ajouter un niveau de protection supplémentaire pour les applications sensible avec une authentification forte (MFA).
Objectifs
- Centraliser les identités utilisateurs. Réduire l’usage des comptes applicatifs locaux, par exemple en les remplaçant par des comptes Windows stockés dans Active Directory ou MS Entra ID.
- Déployer une authentification forte (MFA) pour les applications sensibles et les comptes à privilèges.
- Modéliser les droits via des rôles et autorisations cohérents, en appliquant le principe du moindre privilège.
- Mettre en œuvre la séparation des tâches pour les opérations critiques et gérer les conflits d’autorisation.
- Organiser des revues périodiques des droits et conserver des preuves d’audit des connexions et actions sensibles.
Fonctionnalités et outils
| Intégrer des mécanismes d’authentification modernes et basés sur des jetons lorsque l’application interagit avec des services d’identité, via les objets réseau PB HTTPClient/OAuth et RESTClient. | PB |
| Identifier les implémentations d’authentification et d’autorisation dans le code et détecter les vulnérabilités d’authentification. | VE |
| Mettre en œuvre l’authentification multifacteur (MFA) avec Windows, login/mot de passe ou en mode mixte. | VG |
| Gérer la fédération d’identités et la hiérarchie des groupes utilisateurs. | VG |
| Identifier les conflits via la séparation des tâches (SoD). | VG |
| Produire des rapports exploitables en audit en générant une matrice des droits. | VG |
Conformité
Ce chapitre répond directement aux exigences IAM et de gouvernance des accès définies dans ISO 27001, NIST SP 800-53 et PCI DSS, et est particulièrement pertinent pour les secteurs de la finance, de la santé et des entreprises cotées. (Standards de sécurité et conformité)
Preuves
- Matrice des droits par rôle/groupe/utilisateur et preuves des revues périodiques. (Matrice des droits)
- Règles de séparation des tâches (SoD) documentées, liste des conflits détectés et plan de remédiation. (Séparation des tâches (SoD))
- Journaux d’audit des connexions et opérations sensibles, avec conservation et export. (Activités d’audit)
9. Optionnel : évoluer vers une architecture moderne avec PowerServer
Contexte et risques :
Certaines applications PowerBuilder sont maintenant accessibles à distance (VPN, passerelles applicatives, virtualisation), tout en conservant un client lourd se connectant directement à la base de données et s’appuyant sur des paramètres stockés sur les postes utilisateurs.
Ce modèle induit certains risques, car les équipements situés au périmètre du réseau et les accès distants deviennent des points d’entrée critiques. Il devient également plus difficile de maîtriser, poste par poste, les secrets et paramètres de connexion.
Le DBIR 2025 indique que l’exploitation de vulnérabilités représente environ 20 % des accès initiaux. Il souligne que celles affectant les équipements d’accès distant sont particulièrement sensibles, car elles ne sont corrigées qu’à 54 % dans les 30 jours.
La réponse consiste à réduire la dépendance des postes et l’exposition de la base en évoluant vers une architecture à plusieurs niveaux, où un serveur d’applications expose des API .NET (PowerServer), avec une identité centralisée et des contrôles placés au bon endroit (authentification, journaux, segmentation réseau).
Objectifs
- Réduire l’accès direct à la base de données depuis les postes clients en centralisant les accès dans une couche serveur exposant des API.
- Centraliser les contrôles de sécurité côté serveur (authentification, autorisation, journalisation) afin de limiter la dépendance aux applications clientes et aux configurations locales.
- Standardiser l’authentification des API et la gestion des jetons, en cohérence avec les pratiques de l’organisation.
- Planifier une évolution progressive en priorisant les modules les plus sensibles.
Fonctionnalités et outils
| Utiliser PowerServer pour évoluer vers une architecture à plusieurs niveaux côté serveur et réduire l’accès direct à la base de données depuis les postes clients. | PB |
| Mettre en œuvre des mécanismes d’authentification tels qu’OAuth 2.0 ou JWT dans les Web API afin d’empêcher les accès non autorisés. | PB |
| Mettre à jour les composants serveur vers une version supportée de .NET. | PB |
| Cartographier l’application, identifier les dépendances et sécuriser le code existant avant, pendant et après un changement d’architecture. | VE |
| Utiliser des outils standards pour gérer les utilisateurs, les droits d’accès aux API et produire des rapports d’audit. | VG |
| Centraliser la sécurité de plusieurs applications afin d’obtenir une vision globale des identités et des droits, et de standardiser les contrôles, la journalisation et les audits. | VG |
Conformité
Ce chapitre s’inscrit dans une démarche d’alignement avec des architectures auditables et standardisées, fréquemment mises en avant dans ISO 27001 et le NIST. (Standards de sécurité et conformité)
Preuves
- Schéma d’architecture (zones réseau, Web API, proxy inverse, identité) et documentation des flux. (Web API PowerServer)
- Éléments de preuve des contrôles d’accès et des audits (Visual Guard) sur les opérations sensibles. (Traçabilité et audit)
- Rapports Visual Expert attestant de la correction des vulnérabilités avant le déploiement en production. (Détecter les failles de sécurité dans le code PowerBuilder)
10. Mettre les applications en conformité avec les standards modernes
Contexte et risques :
Dans les secteurs régulés (finance, santé, entreprises cotées), l’objectif n’est pas uniquement de renforcer la sécurité.
Ces organisations doivent démontrer la conformité de leurs applications à des standards modernes. Elle doivent aussi procéder à des contrôles concrets et vérifiables : qui peut accéder aux fonctions sensibles, quels droits ont été accordés, quelles actions ont été effectuées et quelles mesures protègent les données critiques.
Cette exigence a été renforcée par des obligations de transparence : aux États-Unis par exemple, la SEC demande aux sociétés cotées de déclarer certains incidents de cybersécurité "matériels" selon un procédure très encadrée.
Par ailleurs, le coût moyen mondial d’une violation de données atteint 4,88 M$, ce qui transforme un écart de conformité en risque financier direct.
Dans ce contexte, les organisations doivent maintenant systématiser les contrôles et produire des preuves : rapports, journaux, revues d’accès et traçabilité des changements.
Pour éviter les doublons de lecture et faciliter la préparation des audits, ce chapitre établit un lien entre les fonctionnalités décrites précédemment et les exigences de conformité.
Objectifs
- Définir les standards applicables et le périmètre attendu de conformité pour l’application (exigences internes et externes).
- Traduire ces exigences en contrôles mesurables, puis en preuves exploitables lors des audits.
- Mettre en place un référentiel de preuves (rapports, journaux, revues d’accès, etc.).
- Formaliser la gouvernance (revues d’accès, gestion des exceptions, traitement des conflits SoD) et préparer un dossier d’audit standardisé.
Fonctionnalités et outils
| Prendre en charge les exigences fréquentes : signature du code, chiffrement des connexions base de données/pilotes, protocoles réseau sécurisés et capacités d’intégration OAuth/REST. | PB |
| Fournir des analyses répétables et versionnées (notamment sur les règles de sécurité PowerBuilder), utiles pour démontrer la réduction des vulnérabilités et une démarche d’amélioration continue. | VE |
| Automatiser les contrôles et rapports de sécurité et la conformité aux standards modernes : IAM, RBAC, séparation des tâches, traçabilité, audit. | VG |
| Documenter « qui a accès à quoi » en publiant une matrice des droits. | VG |
| S’appuyer sur un référentiel de règles d’inspection afin de produire des résultats reproductibles pour la détection des vulnérabilités dans le code source. | VE |
Conformité
Visual Guard publie une cartographie des standards pris en charge (ISO 27001, NIST SP 800-53, NIST SP 800-63, CIS Controls, PCI DSS, RGPD, etc.) et précise les mécanismes associés (MFA, RBAC, SoD, journalisation, revues d’accès). (Standards de sécurité et conformité)
Preuves
- Matrice de correspondance : contrôle / exigence / fonctionnalité (PB, VE, VG) / preuve produite. (Standards de sécurité et conformité)
- Jeux de rapports standard : scans VE, exports de matrice des droits, journaux d’audit, procédures de signature. (Détecter les vulnérabilités de sécurité dans le code PowerBuilder) (Matrice des droits) (Utiliser les options de signature du code PowerBuilder)
- Processus de gouvernance : fréquence des revues d’accès, gestion des exceptions, traitement des conflits SoD. (Séparation des tâches (SoD))
Check-lists pour sécuriser une application PowerBuilder
Ces check-lists proposent une approche pragmatique : des actions applicables dans la plupart des contextes, suivies de mesures optionnelles à activer selon l’architecture de l’organisation et les contraintes réglementaires.
Checklist A — Mesures génériques (recommandées dans la plupart des cas)
| Chapitre | Mesure |
|---|---|
Transversal (prérequis) |
Recenser les applications, environnements, dépendances et flux (postes, serveurs, bases de données, etc.). |
| Classifier les données manipulées et formaliser les exigences de protection associées. | |
| Mettre en place un processus de remédiation (priorisation, délais cibles, validation, suivi). | |
| Appliquer les correctifs et maintenir à jour les composants exposés (OS, bases de données, middleware, bibliothèques, accès distants). | |
| Formaliser un plan de réponse aux incidents et tester le PRA/PCA (restauration, reprise). | |
2. Exécutables et composants |
Mettre en place un processus de build reproductible et versionné, lié à une livraison identifiable. |
| Signer tous les exécutables, bibliothèques et packages de déploiement avec un certificat approuvé par l’entreprise. | |
| Vérifier l’intégrité des artefacts avant diffusion (hash/empreinte) et conserver le résultat. | |
| Tracer les versions déployées (hash, date, responsable) et conserver l’historique. | |
| Restreindre et auditer les droits de publication et d’administration liés au déploiement. | |
| Analyser le code PowerBuilder avant livraison afin d’identifier les vulnérabilités et mauvaises pratiques. | |
| Détecter et supprimer les secrets codés en dur (identifiants, mots de passe, clés, IP) du code et des scripts. | |
3. Protection des données |
Identifier les données sensibles et leurs emplacements (base de données, fichiers, exports, journaux, sauvegardes). |
| Activer TLS sur le serveur de base de données et les pilotes PB afin d’utiliser TLS 1.2+, avec validation des certificats. | |
| Chiffrer les données sensibles au repos lorsque requis (base, fichiers, exports, sauvegardes). | |
| Protéger les clés de chiffrement (stockage, contrôle d’accès, rotation, révocation). | |
| Chiffrer les paramètres de connexion et générer des chaînes de connexion chiffrées (aucun secret en clair). | |
| Détecter et éliminer les chiffrements faibles (ex. DES/3DES). Imposer des modes robustes. | |
| Détecter et éliminer les fonctions de hachage obsolètes (ex. SHA-1/MD5) et imposer des alternatives robustes. | |
| Vérifier la robustesse cryptographique (tailles de clés, modes opératoires, padding) par rapport à la politique de sécurité. | |
| Réduire l’exposition aux données sensibles en limitant strictement les accès via rôles et droits. | |
4. Protocoles réseau |
Recenser les flux réseau et les protocoles effectivement négociés (versions TLS, suites, certificats). |
| Supprimer les protocoles obsolètes et aligner la configuration TLS sur la politique de l’entreprise. | |
| Valider les certificats et gérer correctement les erreurs (pas de contournement ni de dégradation silencieuse). | |
| Mettre en œuvre une authentification TLS mutuelle (mTLS) lorsque requis (API internes/partenaires). | |
| Tester la compatibilité avec les proxies, passerelles et protections réseau (RESTClient / HTTPClient). | |
| Détecter les appels réseau non conformes ou hérités et prioriser leur remplacement. | |
5. Échanges avec des services externes et API |
Recenser les intégrations (API, services internes, SMTP) et les données échangées. |
| Privilégier REST par rapport à SOAP/INET pour les intégrations (RESTClient). | |
| Si SOAP est requis, utiliser HTTPClient avec TLS 1.2+ et une authentification forte. Éviter les clients SOAP hérités. | |
| Utiliser une authentification par jeton plutôt que des identifiants/mots de passe, via HTTPClient / OAuthClient. | |
| Limiter strictement les privilèges des jetons et des comptes techniques (scopes, autorisations). | |
| Supprimer les secrets codés en dur et organiser leur stockage, rotation et révocation (par environnement). | |
| Détecter et corriger les risques d’injection (SQL, commandes OS, chemins) sur les entrées et paramètres. | |
| Valider les entrées et encoder les sorties sur les flux exposés (services, API, fichiers, emails). | |
| Tracer les opérations sensibles (exports, envois, actions critiques) et mettre en place supervision et alertes. | |
6. Navigateur embarqué |
Recenser les écrans intégrant un navigateur et définir les contenus attendus et les URL autorisées. |
| Migrer vers un moteur de navigateur moderne et supporté et supprimer les composants obsolètes. | |
| Limiter la navigation, l’ouverture d’URL et l’exécution de scripts pour les contenus non fiables. | |
| Encadrer les interactions JavaScript (ponts applicatifs) afin d’éviter toute exécution non souhaitée. | |
| Désactiver le débogage à distance en production et le réserver à des diagnostics contrôlés. | |
| Restreindre l’accès aux écrans « web ». | |
| Surveiller les accès web et déclencher des notifications en cas de comportement anormal (Traçabilité & audit). | |
7. Build et déploiement |
Définir un pipeline standard (build, tests, analyses, signature, déploiement) avec des critères de passage explicites. |
| Passer au format solution afin de simplifier le versioning et l’automatisation. | |
| Passer à PowerBuilder 2025+ afin de réduire les conflits de fusion et améliorer la traçabilité. | |
| Rendre les builds reproductibles (versions, dépendances, paramètres) et conserver artefacts et rapports par version. | |
| Sécuriser les comptes techniques du pipeline (moindre privilège, séparation des rôles, audit). | |
| Sécuriser les secrets et clés du pipeline (stockage sécurisé, accès restreint, rotation). | |
| Industrialiser l’analyse SAST à chaque build et bloquer la livraison si des règles critiques échouent. | |
| Éviter les pratiques risquées en production (ex. logs console) et ne pas ignorer les exceptions. | |
| Standardiser le déploiement des paramètres de sécurité entre dev/test/prod afin d’éviter les écarts. | |
8. Authentification et contrôle des accès |
Centraliser les identités (AD/Entra ID) et réduire les comptes applicatifs locaux. |
| Activer l’authentification multifacteur (MFA) pour les applications sensibles et les comptes à privilèges. | |
| Modéliser les droits via des rôles et autorisations alignés sur le principe du moindre privilège. | |
| Centraliser l’authentification, l’autorisation et la journalisation via un serveur dédié (Identity Server). | |
| Mettre en œuvre la séparation des tâches (SoD) pour les opérations critiques et traiter les conflits. | |
| Organiser des revues d’accès périodiques et conserver les preuves associées. | |
| Produire une matrice des droits exploitable en audit (qui a accès à quoi). | |
| Journaliser les connexions et actions sensibles (qui, quoi, quand, où) et centraliser la supervision. | |
10. Conformité aux standards modernes |
Définir les standards applicables et le périmètre de conformité de l’application. |
| Traduire les exigences en contrôles mesurables et en preuves attendues (rapports, journaux, revues d’accès). | |
| Mettre en place un référentiel de preuves et conserver l’historique par version/environnement. | |
| Standardiser la gouvernance (revues d’accès, gestion des exceptions, traitement des conflits SoD). | |
| Constituer un dossier d’audit réutilisable reliant exigences, contrôles, outils et preuves. |
Checklist B — Mesures optionnelles (dépendantes de l’architecture)
| Chapitre | Mesure |
|---|---|
5. Échanges avec des services externes et API |
Si l’application consomme des API : authentification forte et rotation des clés/jetons (OAuth 2.0). |
| Si l’application consomme des API : limiter les scopes et privilèges des jetons (OAuthClient). | |
| Si envoi d’emails : utiliser le support email natif et une authentification moderne (SMTP Client / XOAUTH2). | |
| Si envoi d’emails : sécuriser les relais (authentification, TLS), limiter les pièces jointes, tracer les envois sensibles (XOAUTH2). | |
6. Navigateur embarqué |
Si composants Web/HTML : contrôler les contenus et limiter les scripts non fiables (WebBrowser). |
| Si composants Web/HTML : remplacer les moteurs hérités par un moteur supporté (WebView2). | |
7. Build et déploiement |
En cas d’industrialisation : standardiser les scripts de build et l’orchestration des pipelines (PBAutoBuild). |
| Pour un QA renforcé : définir des critères d’acceptation basés sur les résultats d’analyse (SAST). | |
8. Authentification et contrôle des accès |
En cas de conflits d’autorisation : définir des règles SoD et un plan de remédiation (Séparation des tâches). |
| En cas d’organisation complexe : mettre en place une hiérarchie groupes/utilisateurs reflétant l’organisation afin de déléguer les droits. | |
| Si les identités sont réparties sur plusieurs annuaires : mettre en œuvre une fédération d’identités. | |
| En préparation d’audits : générer et exploiter une matrice des droits (Permission Matrix). | |
9. Architecture moderne avec PowerServer |
Si la base de données est accessible depuis les clients : migrer vers une architecture n-tiers avec PowerServer. |
| Si l’application expose ou consomme des API : standardiser l’authentification des API (OAuth 2.0). | |
| Si l’application expose ou consomme des API : utiliser des jetons standards et limiter les accès non autorisés (JWT). | |
| Centraliser les contrôles côté serveur (authentification, autorisation, journalisation). | |
| Planifier une évolution progressive en priorisant les modules les plus sensibles (migration progressive). | |
| Mettre à jour les composants serveur vers une version .NET supportée. | |
| Administrer les droits d’accès aux API et produire des rapports d’audit (Permissions / Audit Activities). | |
10. Conformité aux standards modernes |
En cas d’exigences fortes (finance, santé, etc.) : gouvernance de la conformité et contrôles formalisés (Audit Activities). |
| En cas d’exigences fortes : industrialiser la production et la conservation des preuves d’audit (Permission Matrix). |
Foire aux questions (FAQ)
Commencez par une vue d’ensemble : inventaire des composants (exécutable, DLL, OCX, scripts), des flux (poste ↔ serveur ↔ base), des données sensibles et des dépendances.
Lancez ensuite un scan SAST du code PowerBuilder pour identifier rapidement les vulnérabilités et les mauvaises pratiques.
Enfin, mettez en place les « fondations » : signature des binaires, chiffrement en transit, contrôle d’accès, journalisation et preuves d’audit.
Lancez ensuite un scan SAST du code PowerBuilder pour identifier rapidement les vulnérabilités et les mauvaises pratiques.
Enfin, mettez en place les « fondations » : signature des binaires, chiffrement en transit, contrôle d’accès, journalisation et preuves d’audit.
On voit fréquemment : secrets codés en dur (identifiants, mots de passe, clés), appels réseau hérités, contrôles d’accès implémentés « au cas par cas » et difficiles à auditer, validation insuffisante des entrées (risques d’injection SQL/commandes/chemins) et journalisation trop faible pour investiguer.
Un scan SAST PowerBuilder est efficace pour objectiver ces risques et cibler les corrections.
Un scan SAST PowerBuilder est efficace pour objectiver ces risques et cibler les corrections.
L’objectif est de chiffrer en transit entre le poste, les serveurs applicatifs éventuels et la base de données.
Vérifiez la configuration TLS (versions, suites, certificats) côté client et côté serveur.
Selon la base, activez les modes de chiffrement les plus stricts disponibles et testez la compatibilité en présence de proxies, passerelles ou politiques réseau renforcées.
Vérifiez la configuration TLS (versions, suites, certificats) côté client et côté serveur.
Selon la base, activez les modes de chiffrement les plus stricts disponibles et testez la compatibilité en présence de proxies, passerelles ou politiques réseau renforcées.
Le chiffrement en transit protège les données sur le réseau (interception, altération). Le chiffrement au repos protège les données stockées (base, fichiers, exports, logs, sauvegardes) en cas de vol, accès non autorisé ou compromission. Les deux sont complémentaires : un flux chiffré n'empêche pas une fuite via un export local non protégé, et un stockage chiffré n'empêche pas l'écoute réseau si les communications ne sont pas chiffrées.
Évitez DES/3DES, MD5 et SHA-1. Privilégiez des algorithmes modernes avec des paramètres robustes (taille de clés, mode opératoire) et une gestion des clés adaptée (stockage, rotation, révocation).
Mettez en place une chaîne de confiance : compilation reproductible et versionnée, signature systématique des artefacts, vérification d'intégrité (hash), et traçabilité des versions déployées (date, responsable, empreinte). Restreignez et auditez les droits de publication/déploiement. L'objectif est de réduire le risque de compromission de la distribution (supply chain) et de faciliter les investigations.
La compromission du pipeline permet d’injecter du code malveillant dans une version « légitime ». Il est essentiel de sécuriser les comptes, les secrets et les clés de signature, d’industrialiser les analyses SAST et de définir des critères d’acceptation des livraisons.
Centralisez les identités dans l’annuaire de l’entreprise et appliquez le MFA pour les applications sensibles. Adoptez une approche IAM cohérente : authentification centralisée, rôles et permissions, journalisation et production de preuves.
Il faut un modèle de rôles/permissions aligné sur le moindre privilège et une capacité à produire une vue complète et exploitable des habilitations. Organisez des campagnes de revue périodique, traitez les écarts et conservez la preuve de validation. Une "permission matrix" (ou équivalent) simplifie l'audit et accélère les revues.
La séparation des tâches empêche une même personne de détenir des droits incompatibles (par exemple créer et valider un paiement). Elle réduit le risque de fraude interne et renforce la conformité.
Définissez les standards applicables, traduisez les exigences en contrôles et en preuves. Construisez un mapping réutilisable « Exigence → Contrôle → Outil → Preuve » pour chaque audit.
Outils & ressources
PB PowerBuilder
VE Visual Expert
Bibliographie – sources citées dans ce guide
- Incident 3CX (2023) — CISA (DHS)
- 133 pilotes Windows malveillants — Sophos ; Auteur : Andrew Brandt
- Sécurité – Nouveautés — Appeon
- Détecter les vulnérabilités de sécurité dans le code PowerBuilder — Novalys (Visual Expert)
- Permissions — Novalys (Visual Guard)
- Normes de sécurité & conformité — Novalys (Visual Guard)
- Activités d’audit — Novalys (Visual Guard)
- DBIR Verizon 2025 – Synthèse exécutive — Verizon
- Guide CISA – Ransomwares — CISA (DHS)
- Affaire MD Anderson — U.S. HHS
- NIST SP 800-52r2 — NIST
- PCI DSS — PCI SSC
- Incident SolarWinds — CISA (DHS)
- Déclaration des incidents de cybersécurité « matériels » — U.S. SEC
- Coût moyen mondial d’une violation de données (4,88 M$) — IBM