Cette distribution des fichiers de définition de l'API SCAIFE comprend des fichiers formatés YAML, JSON et HTML. Dans la plupart des versions, il y a un fichier dans chaque format de fichier pour chacun des cinq modules SCAIFE.
Dans la version APIS SCAIFE de mars 2021, nous n'avons publié que les fichiers YAML. Cette version a tous nos modules mis à jour en utilisant le format OpenAPI version 3. À l'avenir, nous mettrons également à jour nos scripts qui effectuent une génération de code automatisée à JSON et HTML, pour travailler avec OpenAPI version 3.
Le fichier YAML spécifie la définition de l'API de la Framework Environment (SCAIFE) de l'analyse de code source [1, 2, 3, 5], dans un format que les développeurs peuvent facilement utiliser pour afficher, modifier et générer automatiquement du code à partir de (par exemple, avec l'éditeur Swagger et Swagger-Codegen [4]). Le fichier YAML a été presque entièrement créé manuellement par les développeurs SEI. Les seules choses qui ont été générées automatiquement par les outils Swagger dans le fichier YAML sont quelques-uns des exemples.
Les fichiers JSON ont été générés automatiquement en exécutant Swagger-Codegen sur les fichiers Swagger.yaml, car certains développeurs préfèrent consulter l'API dans JSON ou ont des outils de génération de code qui fonctionnent le mieux avec JSON.
Les fichiers HTML spécifient également la définition de l'API SCAIFE, dans un format lisible par des personnes qui préfèrent ne pas (ou n'ont pas d'outils pour lire les fichiers YAML. Les fichiers HTML peuvent être affichés dans n'importe quel navigateur Web standard. Les fichiers HTML contiennent des hyperliens, et le livre blanc référencé ci-dessous fournit des conseils sur la façon de comprendre les fichiers HTML.
Scaife est une architecture qui prend en charge la classification et la hiérarchisation des alertes de l'analyse statique. Il est conçu afin qu'une grande variété d'outils d'analyse statique puissent s'intégrer au système en utilisant la définition de l'API que nous développons. En ce qui concerne les versions API SCAIFE 2.0.0, nous avons ajouté des appels API pour permettre à SCAIFE de recevoir des mises à jour sur les validations de code et de nouvelles sorties d'analyse statique à partir de serveurs d'intégration continue (CI). Nous nous attendons à ce que l'API intéresse les organisations qui développent et / ou recherchent des outils d'analyse statique, des agrégateurs d'audit d'alerte d'analyse statique et d'autres cadres d'audit d'alerte d'analyse statique. Cette définition de l'API SCAIFE peut être référencée par les développeurs, pour les aider à estimer l'effort de développement qui serait nécessaire pour modifier les outils de leur organisation pour passer et répondre aux appels API SCAIFE. De plus, cette définition de l'API est en cours de publication dans le but de générer des commentaires de développeurs et d'organisations intéressés à mettre en œuvre l'API SCAIFE, afin d'améliorer l'API SCAIFE pour devenir plus facilement utilisable par les développeurs pour une grande variété d'outils d'analyse statique. Un système prototype qui met en œuvre a été distribué aux collaborateurs de projet de recherche.
L'architecture Scaife illustrée sur la figure comprend cinq serveurs. Le système est modulaire, conçu pour que chaque module puisse être instancié par différents outils / logiciels tandis que le système global doit conserver les mêmes fonctionnalités. Le module d'interface utilisateur a un front-end GUI qui permet l'affichage des alertes d'analyse statique (FFSA) et stocke les projets locaux. L'architecture SCAIFE est destinée à permettre une grande variété d'outils FFSA et d'outils d'agrégateur d'alerte pour obtenir des fonctionnalités de classification et de hiérarchisation en interagissant sous forme de module d'interface utilisateur avec le reste du système Scaife. Ces outils doivent instancier des appels d'API de module d'interface utilisateur vers les autres serveurs, pour le faire. Le module DataHub stocke les données (outil, alerte, projet, méta-données de la suite de tests, arbitres, etc.) à partir d'un ou plusieurs modules d'interface utilisateur et juge certaines méta-alertes. Le module statistique crée, exécute et stocke des classificateurs et des algorithmes heuristiques (apprentissage actif) adaptatifs et des algorithmes hyper-paramètres automatisés. Le module de hiérarchisation stocke les formules de priorisation et les champs de priorisation téléchargés par l'utilisateur. Le module d'enregistrement est utilisé pour l'authentification et le contrôle d'accès. Il génère des jetons d'enregistrement, et il fournit une authentification et une autorisation de base pour d'autres serveurs.
Sélectionnez l'un des cinq modules pour commencer l'inspection.: La plupart des développeurs d'outils d'outil FFSA et d'agrégateur d'alerte seront le plus intéressés par la définition de l'API du module d'interface utilisateur. Pour permettre à leur outil d'interagir avec le système SCAIFE, leur outil doit instancier l'API du module d'interface utilisateur. Cependant, certains chercheurs / développeurs se sont concentrés sur l'amélioration de la classification, l'apprentissage actif et l'optimisation automatisée des hyper-paramètres voudront plutôt se concentrer sur l'API du module statistique. Ils peuvent développer de nouveaux algorithmes et les incorporer modulairement dans un prototype que nous avons développé (s'ils sont notre collaborateur de recherche) ou simplement modifier leurs propres outils pour instancier l'API du module statistique, puis interagir avec un système Scaife avec d'autres modules développés par différentes personnes (par exemple, pour un module UI qu'ils pourraient utiliser la version d'échelle que nous avons développé pour travailler modulaire avec SCAIFE). De même, certains chercheurs / développeurs se concentrent sur l'amélioration des performances, de la sécurité, de la résilience et de l'évolutivité du stockage de données agrégé et finalement attendu. Ces personnes voudront se concentrer sur l'API du module Datahub. Nous nous attendons à un plus petit nombre de chercheurs / développeurs pour mettre en œuvre des modules d'enregistrement ou de hiérarchisation. Cependant, leurs API seront toujours utiles à l'examen, car d'autres serveurs doivent interagir avec eux, que ce soit dans un client ou un rôle de serveur.
Si vous le pouvez, nous vous encourageons à utiliser l'éditeur de fanfaronnade open source (et gratuit) [4] ou un outil de visualisation et d'édition API similaire. Ouvrez un fichier de définition API (.yaml ou .json) dans ce domaine. Swagger Editor fournit un moyen convivial pour afficher, faire des tests simples et modifier la définition de l'API.
Sinon, affichez le fichier de définition de l'API HTML dans un navigateur Web. De cette façon, les modèles et les méthodes sont accessibles en suivant les hyperliens associés à chaque ressource dans la section de définition de l'API SCAIFE ci-dessous.
Chaque section de définition de l'API est classée en fonction des modules source et de destination des appels API. Par exemple, la section de définition API des modules de modèles rapides et de connexion ne contient qu'une seule catégorie d'appels API sous l'UITORORISTRATION. La source (demande) des appels API provient du module d'interface utilisateur et les appels API sont transmis à la destination: le module d'enregistrement. Les modèles de données sont définis dans la section inférieure du fichier.
J'espère que vous n'inspecterez pas seulement l'API, vous l'utiliserez pour intégrer votre outil ou votre code dans un système SCAIFE. Vous pouvez générer automatiquement du code à partir de la définition de l'API YAML ou JSON de l'un des modules Scaife, en utilisant Swagger Codegen [4] ou des outils similaires. Cela a non seulement l'avantage d'accélérer et d'automatiser le développement du code, mais il garantit également que le code instancie l'API SCAIFE. Si vous avez un outil pour lequel vous souhaitez générer du code client (ce qui signifie que vous voulez du code qui passera un appel à un serveur Scaife défini dans la définition de l'API de ce serveur), des outils comme Swagger Codegen générent du code dans une grande variété de langues. Vous pouvez placer le code client généré dans votre propre code au bon endroit et utiliser vos propres variables comme paramètres. De même, vous pouvez générer automatiquement du code de serveur pour l'un des modules SCAIFE, y compris les talons de fonction du contrôleur pour chacun des appels de l'API vers ce serveur pour lequel vous étofferont ensuite le code interne.
Notes spéciales pour les réviseurs d'API: