Ce mois-ci chez Cellenza, la Cybersécurité est à l’honneur ! Ce sujet est très en vogue pour la simple et bonne raison que la majorité des entreprises ont aujourd’hui conscience de son importance dans les projets en tout genre. Aujourd’hui, nous vous parlerons d’Azure Sphere, ce processeur signé Microsoft à la pointe de la technologie en matière de sécurité informatique.

 

Qu’est-ce qu’Azure Sphere ?

 

Présentation d’Azure Sphere

 

Azure Sphere est la dernière nouveauté de Microsoft autour de la sécurité co-développée avec Avnet. D’après la documentation officielle, « Azure Sphere est une plateforme d’applications sécurisée de haut niveau, avec des fonctionnalités intégrées de sécurité et de communication pour les appareils connectés à Internet. Il se compose d’une unité de microcontrôleur (MCU) sécurisée, multi utilisation et connectée, d’un système d’exploitation Linux personnalisé de haut niveau et d’un service de sécurité Cloud, qui offre une sécurité continue et renouvelable ».

Je vous invite d’ailleurs à survoler la description complète du produit !

 

Source: Documentation Microsoft

 

Cette plateforme est un petit bijou de sécurité. Elle permet d’intégrer dès le départ, en complément des composants logiciels fournis par Microsoft, tous les aspects de ce que l’on décrit comme étant un appareil sécurisé (je vous invite à consulter notre précédent article sur la sécurisation de votre flotte IoT). Si l’on ajoute à cela les composants d’Azure IoT Edge ainsi que des couches de sécurité propres à chaque entreprise, nous pouvons estimer avoir ici un appareil sécurisé.

 

Cette solution comprend trois composants fonctionnant ensemble pour protéger les dispositifs :

• Microcontrôleurs certifiés Azure Sphere : classe de MCU (Microcontroller Unit) combinant à la fois processeur applicatif et temps réels, embarquant les dernières technologies de sécurité par Microsoft, notamment basées sur les 20 ans d’expérience de la firme avec les Xbox.
• Système d’exploitation Azure Sphere OS : visant la défense en profondeur, cet OS embarque plusieurs niveaux de sécurité, contrairement aux OS temps réels (RTOS) classiques, en combinant les innovations de sécurité Windows, un moniteur de sécurité et un noyau Linux personnalisé.
• Service de sécurité Azure Sphere : un service Cloud clé en main qui protège l’intégralité du système en assurant une voie de communication fiable entre l’appareil et le Cloud grâce à des mises à jour automatiques, la détection des menaces et la génération des rapports en ligne.

 

Notons également que les composantes d’Azure Sphere OS sont open source (même les metas pour Yocto !).

Pour les obtenir, rendez-vous sur ce site de Microsoft, et entrez le filtre « Azure Sphere ».

A la date de publication de cet article, les résultats sont filtrés par ordre croissant sur leur version : descendez tout en bas.

 

Pourquoi Azure Sphere existe-t-il ?

 

Toujours pour faire référence à notre article précédent cité dans la partie ci-dessus, les cyberattaques sont de plus en plus nombreuses, de plus en plus perfides, intelligentes, osées. Aujourd’hui nous commençons tout juste à savoir nous protéger de manière efficace ; les entreprises commencent à être sensibilisées et à prendre sérieusement en compte l’aspect sécurité des développements dans les projets.

Cependant, le matériel utilisé vient souvent du marché, où les prix sont concurrentiels, et où la sécurité peut être l’un des aspects diminués, non seulement par souci d’économies, mais aussi par facilité d’utilisation pour le client final.

Microsoft a pris les devants pour permettre aux intégrateurs de disposer d’un appareil sécurisé ET facile à utiliser.

 

A qui l’Azure Sphere s’adresse-t-il ?

 

Industries actuelles

 

Azure Sphere s’adresse à tous les industriels et aux intégrateurs de projets IoT qui souhaitent faire de la sécurité informatique l’un des piliers de leur développement de produits.

 

Enjeux considérables

 

Connaître les risques encourus est souvent décisif lors d’un audit de projet, alors parlons des cyberattaques.

 

Les 5 attaques les plus connues au moment de publication de cet article sont :

• “WannaCry”: plus grande cyberattaque à rançon de l’histoire, plus de 300 000 ordinateurs impactés, pour des dégâts de 4 à 8 milliards de dollars. C’est à cause de celle-ci que Windows ne demande plus la permission avant d’effectuer une mise à jour.
• “ExPetr”: plus de 10 milliards de dollars de dégâts.
• “Stuxnet”: destruction des centrifugeuses d’enrichissement en uranium d’Iran
• “DarkHotel”: falsification des réseaux Wi-Fi des hôtels
• “Mirai”: conséquence de la minimisation des efforts sur la sécurité IoT. Infection pendant des années d’appareils IoT du monde entier, tous contrôlables à distance par l’attaquant. Tout ceci parce que les fabricants ne voyaient pas l’intérêt de mettre des systèmes antivirus sur leurs appareils IoT.

 

Vous pouvez trouver plus de détails sur ces attaques dans notre précédent article sur la sécurisation de la flotte avec Microsoft Azure.

 

Nous ne le dirons jamais assez, protégez vos systèmes ! Il vaut mieux passer deux mois à peaufiner sa sécurité que deux ans à compenser les dégâts subis.

 

Principaux acteurs

 

Cet article n’est pas seulement destiné aux preneur.ses de décisions, mais à vous tous.tes, acteurs.rices du quotidien qui avez chacun.e le pouvoir de convaincre votre entourage, jusqu’à ce que le mot soit suffisamment entendu pour que la prise en compte de la sécurité des systèmes devienne majeure dans tout projet.

Prenons un exemple : si vous achetez un très beau vélo, vous allez évidemment investir dans un antivol. En termes de cybersécurité IoT c’est la même chose : investiriez-vous du temps et du budget pour concevoir un appareil sans le sécuriser ?

La solution : devenons nous-mêmes les acteurs.rices principales.aux de la cybersécurité !

 

Quand est-il utile d’intégrer Azure Sphere à son projet ?

 

Contexte d’un projet type

 

En plus d’être un atout considérable en sécurité informatique, Azure Sphere est un outil très performant malgré sa taille réduite en tant qu’intelligence embarquée pour IoT.

Pour des projets particulièrement contraignants, il pourrait toutefois se révéler insuffisant. Imaginez votre projet, avec en son cœur le traitement de données que vous souhaitez, avec l’appareil que vous souhaitez, mais le tout entouré et protégé par l’Azure Sphere : toutes les communications, tous les transferts, passeraient par lui, une sorte de « garde du corps personnel ». Cette image ne ferait-elle pas rêver pour votre futur projet ?

 

Exemple d’intégration avec Azure Sphere

 

A l’instant même où j’écris ces mots, je suis dans un train, alors prenons cet exemple.

Imaginons que chaque rame embarque son propre ordinateur de contrôle, et que tous communiquent entre eux, sauf un, à la tête du train, qui a pour unique rôle de gérer la communication entre les rames et le Cloud (scénario inventé, je ne sais pas si c’est vraiment le cas). Or, nous savons que les données récoltées par les appareils du monde entier sont très précieuses : ce sont ces données que les hackeurs cherchent à dérober. En toute logique, les ordinateurs de chaque rame sont reliés entre eux par voie filaire, pour empêcher toute intrusion par le Wi-Fi. Mais qu’en est-il de l’appareil qui doit communiquer avec le Cloud ? Et où devons-nous apposer le bloc de sécurité ?

Nous observons là deux risques : l’infiltration logiciel et le vol de données. Déjà, si la donnée est transmise par voie filaire, un hackeur doit avoir un accès physique aux appareils – ce qui est normalement protégé dans les trains – mais considérons qu’ils soient accessibles pour l’exemple. Les appareils communiquent forcément entre eux, que ce soit entre deux ordinateurs pour échanger des indications, ou avec l’ordinateur central pour transmettre la donnée vers le Cloud, mais nous devons empêcher un hackeur lambda d’accéder à ces données. Elles sont donc cryptées, avec une base matérielle protégée. C’est là qu’intervient Azure Sphere, qui nous permettra, dans la prochaine partie, non seulement de protéger les données en transit des rames, mais aussi d’empêcher l’infiltration du hackeur sur l’appareil.

 

 

 

Comment utiliser Azure Sphere dans un contexte Azure IoT Edge ?

 

Mise en place du scénario

 

Reprenons donc le scénario précédent. Nous devons implémenter un ensemble d’appareils Azure Sphere, avec une passerelle centrale de communication vers le Cloud. Nous allons intégrer Azure IoT Edge à cette passerelle, pour toujours plus de sécurité, de fonctionnalités hors normes, de mises à jour à distance, de facilité de développement en équipes et de gestion des alertes au plus proche des sources, même hors connexion. Pour cette session, j’utilise l’Azure Sphere Starter Kit MT3620 d’Avnet.

 

Source de l’image

 

Prise en main d’Azure Sphere

 

En tant qu’expert IoT, je suis habitué à manipuler des appareils IoT, notamment dans le cadre de mes missions auprès des clients. J’ai été particulièrement surpris par la simplicité de prise en main d’Azure Sphere, dont l’utilisation sera possible par des personnes moins aguerries.

Avec un câble USB branché entre le kit et l’ordinateur Windows 11 (test non effectué sous d’autres distributions), un pont de plusieurs convertisseurs USB séries en parallèle sont créés automatiquement (visibles depuis l’explorateur de fichiers notamment).

Pour manipuler ce kit de développement, quelques outils sont nécessaires :

• Azure Sphere SDK : comme une installation classique sur Windows, téléchargez et installez le SDK à cette adresse (lien direct de téléchargement pour Windows). A partir de là, testez l’exécution de la commande “azsphere” sur un terminal (Windows Command Prompt ou PowerShell) pour vérifier l’installation. Si la commande n’existe pas, tentez de rouvrir le terminal, de vous reconnecter à votre session Windows, ou vérifiez que le lien vers l’exécutable soit bien présent dans les variables d’environnement système.
• Cmake et Ninja (seulement si vous comptez vous servir de Visual Studio Code ou Windows CLI) :
  • Lien de téléchargement pour Cmake : Download | CMake
  • Lien de la page Releases du GitHub de Ninja : Releases · ninja-build/ninja (github.com)
    Téléchargez le zip pour Windows, décompressez et placez l’exécutable à un endroit dont vous vous souviendrez (par exemple C:\Program Files\Ninja\)
  • Ajoutez les chemins absolus d’accès à Ninja et au dossier bin de Cmake aux variables d’environnement système
  • Pour être sûr que tous les éléments soient pris en compte, reconnectez votre session Windows, ou redémarrez votre ordinateur

 

Retrouvez la documentation pour l’installation des SDKs ici.

 

Une dernière chose avant de pouvoir utiliser l’appareil : il lui faut un lien de connexion vers Azure ! A partir de là, l’appareil doit être connecté à l’ordinateur (les LEDs de la carte doivent s’allumer).

 

Créons maintenant notre utilisateur pour l’appareil:

azsphere register-user --new-user <email-address>

 

Cette commande devrait ouvrir une fenêtre pour vous connecter à Azure.

 

Si vous avez déjà un utilisateur, utilisez directement :

azsphere login

 

Pour la protection de l’appareil, il est demandé (et obligatoire) de placer l’Azure Sphere dans un Tenant à part entière, ou encore, dans un Tenant spécifiquement dédié à vos appareils Azure Sphere, et uniquement ceux-ci.

Notez également qu’un appareil Azure Sphere peut servir à créer un seul et unique Tenant Azure, et ne peut être associé qu’à un seul et unique Tenant également ; ce sont deux opérations séparées, mais un appareil Azure Sphere peut être utilisé pour créer un et un seul Tenant, mais être plus tard associé à un autre. Pour en créer un, dans un terminal quelconque, exécutez la commande :

azsphere tenant create --name <tenant-name or tenant-ID>

 

Il est conseillé de donner un nom qui soit reconnaissable, pour ne pas l’utiliser pour autre chose que vos appareils Azure Sphere. Pour vérifier que la création et la sélection automatique ont bien eu lieu, utilisez la commande :

azsphere tenant show-selected

 

Si aucun tenant par défaut n’a été sélectionné, utilisez “azsphere tenant list” et “asphere tenant select” pour le faire.

Pour gérer vos tenants, voici un lien vers la documentation Microsoft concernée.

 

Il est temps d’associer définitivement notre appareil au Tenant :

azsphere device claim

 

Pour la suite, j’ai utilisé Visual Studio Code, mais il est possible de partir sur Visual Studio ou CLI : voir la Documentation complète.

Configurons maintenant la partie réseau, pour donner à notre appareil la capacité de communiquer librement avec le Hub. Sur Visual Studio Code, installez l’extension Azure Sphere. Vous pouvez maintenant ouvrir Azure Sphere Explorer avec la palette de commandes (taper « View: Show Azure Sphere Explorer », ou « Azure Sphere: Open Welcome Page »), qui apparaîtra sur la bande gauche de VSCode.

 

 

A première vue, pas grand-chose, mais vous pouvez, depuis cet affichage, gérer quasiment toute la configuration utilisateur de l’appareil.

 

Un logo « + » est accessible à côté du réseau Wi-Fi sélectionné. Celui-ci vous permettra d’entrer un mot de passe, et le tour est joué : l’appareil Azure Sphere se connectera au Hub.

 

Certains appareils qui appartiennent à une ancienne version du kit de développement peuvent être amenés à mettre à jour l’OS manuellement. Veuillez vérifier en vous rendant sur la documentation Microsoft concernée.

 

Il ne reste plus qu’à lier l’appareil à Azure IoT Hub. Pour cela, on pourrait utiliser une chaîne de connexions, mais cela n’est pas la solution la plus sécurisée. Nous allons utiliser un certificat d’authenticité auprès d’Azure Device Provisioning Service.

 

Toujours via le terminal de commande de l’appareil :

azsphere ca-certificate download --destination CAcertificate.cer

Cela générera un certificat dans le dossier courant du terminal.

 

Sur le portail Azure, créez un IoT Hub et un DPS, et liez les deux en allant dans la section “IoT Hub liés” du DPS. Par la suite, dans la section “Certificats”, chargez le certificat précédemment créé. Ainsi, tous les appareils s’authentifiant au DPS pourront communiquer librement avec l’IoT Hub (consulter la Documentation complète).

 

L’appareil est maintenant prêt à être utilisé.

 

Implémentation d’Azure IoT Edge en passerelle (Gateway) transparente

 

La toute première étape de cette partie sera de préparer un appareil (en l’occurrence une Raspberry Pi 4B+ pour cet article), et donc d’y installer un OS 64-bit de Raspbian Lite ainsi qu’Azure IoT Edge.

 

Installation d’un OS 64-bit de Raspbian Lite

 

Avec une carte SD (de préférence un minimum de 16Gb) insérée dans votre ordinateur Windows 10/11, utilisez le logiciel “Rasperry Pi Imager“, se trouvant sur le site officiel de Raspberry Pi. Ce logiciel vous permettra d’implanter un OS sur la carte SD avec une facilité déconcertante. Il vous suffira, sur le logiciel, de sélectionner l’OS (ici, Rasperry Pi OS Lite 64-bit), et votre carte SD.

 

Une petite modification à faire : allez dans les paramètres de l’installation, cochez la cache “Enable SSH”, paramétrez votre propre utilisateur et insérez vos identifiants Wi-Fi.

 

Une fois ceci effectué, lancez l’installation ! L’opération devrait durer 2-3 minutes, à la suite de quoi vous pourrez insérer la carte SD dans l’appareil, et le démarrer.

Si vous ne connaissez aucune méthode d’identification de l’adresse IP de votre appareil, il vous est possible d’utiliser des logiciels comme ZenMap.

 

Installation d’Azure IoT Edge

 

Nous allons ici installer la dernière version à date (1.4) d’Azure IoT Edge sur notre appareil.

Trois étapes sont nécessaires :

• Configuration des sources de Microsoft ;
• Installation de l’orchestrateur Moby Engine ;
• Installation d’Azure IoT Edge.

 

En premier lieu, connectez-vous en SSH sur votre appareil. Pour cela, depuis un terminal, après avoir récupéré l’adresse IP de votre appareil, utilisez la commande :

sudo ssh <username>@<IP>

Entrez le mot de passe précédemment configuré : vous êtes maintenant prêt à avancer.

 

Configuration des sources de Microsoft

 

Sur ce même terminal :

 

Installation de l’orchestrateur Moby Engine

 

Installation d’Azure IoT Edge

sudo apt install -y aziot-edge defender-iot-micro-agent-edge

 

Si vous recevez une erreur disant vouloir supprimer le paquet « sudo », c’est que l’utilisateur super-admin « root » n’a pas de mot de passe enregistré. Pour cela, exécutez la commande « sudo passwd » pour donner un mot de passe à l’utilisateur administrateur « root ».

Testez la commande “sudo iotedge version” pour vérifier l’installation.

Si le logiciel est correctement installé, il est temps de configurer l’accès à l’IoT Hub.

 

Configuration de l’appareil en passerelle transparente

 

Configuration de l’autorité de certification, génération des certificats de démonstration

 

Commençons par générer le certificat root CA, base de tous les autres :

 

Puis les certificats edge CA, qui serviront à générer des certificats pour vérifier l’identité des appareils sous-jacents :

Remplacez <CA cert name> par un nom de votre choix :

./certGen.sh create_edge_device_ca_certificate "<CA cert name>"

Ce script vous générera deux fichiers : le certificat <path>/certs/<name>.cert.pem, ainsi que sa clef <path>/private/<name>.key.pem

Dans le fichier de configuration IoT Edge de votre appareil, placez les paramètres en lien avec les certificats :

Sudo nano /etc/aziot/config.toml

(si le fichier config.toml n’existe pas encore, faites une copie du fichier “/etc/aziot/config.toml.edge.template”)

Décommentez le paramètre “trust_bundle_cert” et insérez un chemin absolu pour le certificat root (par exemple, nous les placerons plus tard dans le dossier “/etc/ssl/certs”).

Trouvez la section “[edge_ca]” et décommentez les trois lignes de cette section, en leur donnant des valeurs :

• Cert : le chemin absolu vers le certificat device CA
• Pk : le chemin absolu vers la clef.

 

Cependant, il n’est pas encore temps de copier les fichiers : vous devrez donc prévoir les chemins et bien les retenir.

 

Connexion à Azure IoT Hub

 

Pour connecter l’appareil à IoT Hub, passons par le Device Provisioning Service.

 

Pour une relative simplicité de démonstration, nous allons utiliser une clé symétrique de DPS pour enregistrer manuellement cet unique appareil.

Sur le service DPS du portail Azure, dans la section « Manage Enrollments », sélectionnez « Add individual enrollment », puis « Symmetric Key » comme Mécanisme.

Choisissez un ID d’inscription (le nom de l’appareil que vous souhaitez retrouver dans l’IoT Hub, et que vous devrez inscrire dans les paramètres sur l’appareil), sélectionnez « IoT Edge device » à Vrai, et enregistrez. Vous vous retrouverez ainsi avec la clé symétrique primaire à utiliser sur l’appareil.

 

Dans le fichier /etc/aziot/config.toml précédemment utilisé, trouvez la section “DPS provisioning with symmetric key”, et décommentez les lignes « [provisioning] », « source », « global_endpoint », « id_scope », « [provisioning.attestation] », « method », « registration_id », et « symmetric_key ».

 

Renseignez les valeurs du Scope ID (information disponible sur la page d’accueil du DPS utilisé), l’ID d’inscription utilisé, et la clé.

 

Une fois le fichier sauvegardé, utilisez la commande :

sudo iotedge config apply

 

En allant voir les logs « sudo iotedge system logs — -f », vous devriez voir l’appareil se connecter au Hub. Vous pouvez le vérifier en allant sur le portail d’IoT Hub après 1-2 minute(s).

 

Déploiement de Edge Hub et des routages

 

Normalement, sur un appareil IoT Edge qui n’a aucun déploiement, seul l’agent Edge est déployé automatiquement. Une fois que des modules sont déployés, le module Edge Hub l’est aussi. C’est lui qui gère les transferts de messages intermodules, ainsi que les transferts de messages vers le Hub ; il nous est donc indispensable dans une passerelle. Nous allons donc le déployer manuellement.

Pour cela, rendez-vous sur le portail, et plus précisément sur l’IoT Hub. Vous trouverez votre passerelle dans la section IoT Edge.

 

Sur cet appareil, utilisez la fonction « Set Modules ». Vu qu’on ne cherche à déployer que Edge Hub, il n’est pas nécessaire d’en rajouter d’autres. Allons directement à la section des Routes. Sur celle-ci, vous ajouterez deux routes :

• Name: allMessagesToHub    Value: ‘FROM /messages/* INTO $upstream’
• Name: allDownstreamToHub     Value: ‘FROM /messages/* WHERE NOT IS_DEFINED ($connectionModuleId) INTO $upstream’

 

Vous pouvez à présent valider le déploiement.

 

Configuration des ports de la passerelle

 

Comme l’Azure Sphere utilise le protocole MQTT pour communiquer, et donc le port 8883, il est nécessaire de l’ouvrir sur notre passerelle.

Sur l’appareil, nous allons d’abord vérifier si le port est ouvert:

sudo ufw allow 8883

Cette commande va générer une règle de sécurité spécifique pour ce port.

 

Configuration du nom de domaine de la passerelle

 

Pour trouver la valeur du nom de domaine (FQDN / Fully Qualified Domain Name) pour notre appareil, il suffit d’aller sur le portail Azure, sur la page de notre appareil IoT Edge, et copier la valeur du paramètre « DNS Name ».

Utilisez cette valeur dans le fichier /etc/aziot/config.toml, pour le paramètre « hostname » en tout début de fichier.

Redémarrez ensuite le service IoT Edge avec la commande suivante :

sudo iotedge system restart

 

Sélection de l’appareil IoT Edge comme parent d’Azure Sphere

 

Pour que l’appareil IoT Edge soit considéré comme passerelle par Azure Sphere, nous lui fournissons l’identifiant de l’appareil IoT Edge comme « parent ».

Pour cela, rendez-vous sur la page IoT Hub de l’Azure Sphere précédemment provisionné, et sélectionnez la passerelle dans Device ID -> No parent device.

 

Transfert du certificat tenant CA de l’appareil Azure Sphere vers l’appareil IoT Edge

 

Pour que l’appareil IoT Edge puisse vérifier l’authenticité des appareils Azure Sphere, il doit lui-même avoir une copie des certificats Tenant CA.

Avec l’appareil Azure Sphere connecté à votre ordinateur, utilisez les commandes suivantes :

azsphere login

azsphere ca-certificate download --destination Cacertificate.cer

 

Pour convertir ce certificat au format PEM, plusieurs solutions existent, mais sur un ordinateur Windows, procédons comme suit :

• Double cliquer sur le fichier dans un explorateur
• Dans la section Details, sélectionner « Copy to file »
• Dans l’outil « Certificate Export », sélectionner « Next »
• Sélectionner le format ‘Base 64 encoded X.509 (CER)’, et aller à la page suivante
• Entrer le nom du fichier pour l’exportation, puis suivant.
• Enfin, terminer l’outil.
• Renommer le fichier téléchargé pour avoir l’extension .pem

 

Nous devons maintenant ajouter le contenu de notre certificat au root CA créé plus tôt.

Sur l’appareil IoT Edge:

• Localiser le certificat root CA
• Ouvrir le certificat CA au format PEM créé précédemment dans un éditeur de texte, et copier/coller le contenu à la fin du certificat Root CA
• Sauvegarder les changements, et redémarrer le service IoT Edge

 

Transfert en retour du certificat root CA par des paquets d’applications

 

De même que l’appareil IoT Edge doit pouvoir vérifier l’authenticité de l’appareil Azure Sphere, ce dernier doit pouvoir le faire en retour également.

Localisez le certificat root d’origine créé au début de ce tutoriel et copiez dans l’appareil Azure Sphere dans vos futurs projets d’application.

Il est maintenant également temps d’importer les certificats Edge CA configurés dans le fichier de configuration d’IoT Edge, à l’endroit que vous aurez indiqué dans ce dernier.

 

Aller plus loin sur Azure Sphere

 

A partir de cet instant, vos deux appareils sont prêts à communiquer ensemble avec IoT Hub. Il ne vous reste plus qu’à développer vos applications sur ce dispositif sécurisé !

Vous trouverez des exemples sur le GitHub d’Azure.

 

Vous souhaitez en savoir plus sur la cybersécurité et la sécurité dans le Cloud ? Consultez dès à présent nos autres articles de cette série :

• La cybersécurité : un enjeu stratégique pour les entreprises
• Les enjeux de la cybersécurité face à l’évolution des systèmes d’information
• Déléguer la gestion des utilisateurs et des équipements dans Azure AD et Intune
• La gestion des identités dans Azure Kubernetes Services (AKS)
• Pourquoi se former sur la cybersécurité ?
• Concilier Agilité et Sécurité : le manifeste Agile et l’OWASP à notre secours !
• La sécurité dans GitHub