Configuration de la génération de fichier IRX avec l'interface de ligne de commande

Utilisez un fichier de configuration pour la génération de fichier IRX, dans lequel vous pouvez indiquer des cibles individuelles, mais aussi inclure ou exclure des cibles. En outre, vous pouvez utiliser le fichier de configuration afin de spécifier des informations supplémentaires qui peuvent contribuer à générer un fichier IRX.

Utilisation des fichiers de configuration

Un fichier de configuration peut servir à indiquer les cibles à inclure ou exclure lorsque vous générez un fichier IRX. Vous pouvez également spécifier des répertoires contenant des artefacts générés, ainsi que des informations à utiliser lors de la génération de fichiers IRX (par exemple, vous pouvez utiliser ce paramètre pour spécifier un compilateur JDK ou JSP spécifique).
Remarque : Vous pouvez utiliser AppScan Go! pour créer un fichier de configuration. Voir Configuration d'un examen à l'aide d'AppScan Go!

Lorsque vous exécutez la commande appscan prepare (Windows) ou appscan.sh prepare (Linux et macOS) pour générer un fichier IRX, l'Utilitaire de ligne de commande Static Analyzer vérifie automatiquement s'il existe un fichier appscan-config.xml dans le répertoire en cours. Si le fichier est détecté, il est automatiquement utilisé.

Si vous disposez d'un fichier de configuration dans un autre répertoire ou d'un fichier qui porte un autre nom, vous pouvez utiliser ce fichier en incluant l'option -c lors de l'exécution de la commande appscan prepare ou appscan.sh prepare. Dans ce cas, exécutez appscan prepare -c <configuration_file> sur (Windows) ou appscan.sh prepare -c <configuration_file> sur (Linux et macOS), où <configuration_file> représente le chemin absolu et le nom du fichier de configuration.

Modèle de fichier de configuration et paramètres

Lorsque vous préparez le fichier de configuration, utilisez le modèle suivant :

<Configuration attributes="true/false">
  <Targets>
    <Target outputs-only="true/false" path="scan_target_path">
      <CustomBuildInfo build_info="info"/>
      <Include>string_pattern</Include>
      <Exclude>string_pattern</Exclude>
    </Target>
  </Targets>
</Configuration>
Utilisez les attributs de configuration facultatifs pour personnaliser un examen tiers et/ou SCA/open source comme suit :
  • enableSecrets="<true or false>" permet de rechercher des secrets dans tous les fichiers source. La valeur par défaut est false.
  • openSourceOnly="<true or false>" désactive l'examen de sécurité et n'exécute qu'une analyse Open Source. La valeur par défaut est false.
  • secretsOnly="<true or false>" désactive l'analyse statique et recherche les secrets dans les fichiers source uniquement. La valeur par défaut est false.
  • sourceCodeOnly="<true or false>" n'examine que les fichiers source et ignore les autres types de fichiers pris en charge (.dll, .exe). La valeur par défaut est false.
  • staticAnalysisOnly="<true or false>" désactive l'analyse Open Source et exécute uniquement l'analyse statique. La valeur par défaut est false.
  • thirdParty="<true or false>" permet d'examiner des artefacts tiers. La valeur par défaut est false.

Utilisez l'élément Targets pour désigner les cibles à examiner lors de la génération du fichier IRX. Les attributs de cible (Target) et les éléments enfant sont utilisés comme suit :

  • L'attribut outputs-only de l'élément Target est uniquement utilisé lorsque vous souhaitez examiner un répertoire et forcer l'Utilitaire de ligne de commande à ne rechercher que les fichiers de sortie de génération (tels que les fichiers .jar, .war et .class). Par défaut, cet attribut est défini sur false. Autrement dit, l'Utilitaire de ligne de commande recherche le répertoire afin de déterminer s'il s'agit d'une cible (comme un serveur d'applications ou un espace de travail Eclipse), ou si le répertoire contient des éléments tels que des scripts de génération, des fichiers Maven .pom et des fichiers make. Si vous souhaitez que la cible de l'examen soit traitée comme un simple répertoire et que seuls les fichiers de sortie soient localisés, spécifiez outputs-only="true" dans l'élément Target.

    Par exemple, si vous spécifiez <Target outputs-only="false" path="C:\Tomcat">, l'Utilitaire de ligne de commande suppose que la cible est votre serveur d'applications Tomcat et recherche alors ses fichiers .war qu'il a déployés. En revanche, si vous spécifiez <Target outputs-only="true" path="C:\Tomcat">, l'Utilitaire de ligne de commande considère cet emplacement comme un répertoire et localise tous les fichiers de sortie de génération qu'il contient.

  • Utilisez l'attribut path de l'élément Target pour spécifier le chemin d'accès à une cible d'examen ou à un répertoire de cibles d'examen (<scan_target_path>). Lorsqu'un répertoire est indiqué, tous ses sous-répertoires sont inclus dans l'examen.

    Par exemple, si vous spécifiez <Target outputs-only="false" path="C:\WebSphere\AppServer85\profiles\AppSrv01">, l'Utilitaire de ligne de commande localise tous les fichiers .ear déployés dans le profil AppSrv01. Si vous spécifiez <Target outputs-only="false" path="C:\WebSphere\AppServer85">, l'Utilitaire de ligne de commande localise tous les fichiers .ear déployés dans tous les profils.

  • Vous pouvez aussi spécifier les sous-éléments Target facultatifs suivants :
    • Vous pouvez utiliser l'élément CustomBuildInfo pour définir les attributs. En utilisant cette partie du modèle,
      
      <CustomBuildInfo build_info="info"/>
      vous pouvez indiquer les informations de génération en fonction du langage cible. Pour certains langages, il est possible de définir plusieurs attributs. Vous pouvez, par exemple, définir <CustomBuildInfo build_info_1="info_1" build_info_2="info_2" build_info_3="info_3"/>, en fonction du langage cible.
      • Pour Java, vous pouvez définir les attributs suivants :
        <CustomBuildInfo additional_classpath="dependency_path"
          jdk_path="JDK_path" jsp_compiler="JSP_compiler_path" package_includes="namespaces" package_excludes="namespaces"/>
        • Spécifiez des chemins d'accès aux classes supplémentaires avec l'attribut additional_classpath. Sous Windows, séparez les chemins d'accès à différentes classes par un point-virgule. Sous Linux et macOS, séparez les chemins d'accès à différentes classes par deux-points.
        • Utilisez l'attribut jdk_path pour spécifier le chemin d'accès à votre installation JDK.
        • Utilisez l'attribut jsp_compiler pour spécifier le chemin d'accès à votre compilateur JSP, par exemple :
          jsp_compiler="C:\Tomcat"
          jsp_compiler="C:\Program Files (x86)\IBM\WebSphere\AppServer"
          jsp_compiler="C:\Oracle"
        • Utilisez l'attribut package_includes pour remplacer les exclusions de tiers existantes et n'examiner que les classes appartenant aux espaces de noms donnés. Utilisez des points-virgules pour délimiter la liste des espaces de noms. Exemple :
          package_includes="com.hcl.example;com.hcl.sample"
        • Utilisez l'attribut package_excludes pour ajouter les espaces de noms spécifiés à la liste existante des exclusions de tiers. Utilisez des points-virgules pour délimiter la liste des espaces de noms.
        • Utilisez l'attribut irx_minor_cache_home dans la balise <CustomBuildInfo> pour définir l'emplacement du cache de traitement parallèle Java. La valeur doit pointer vers l'emplacement utilisé pour le cache. Exemple :
          <CustomBuildInfo irx_minor_cache_home="X:/mycache"/>
      • Pour JSP sous le Tomcat fourni, vous pouvez définir les attributs suivants :
        <CustomBuildInfo jsp_compiler_args="-ARGUMENTS"/>
        • Utilisez l'attribut jsp_compiler_args pour spécifier des arguments de ligne de commande du compilateur JSP afin de définir ou d'écraser le compilateur JSP.
      • Pour .NET (Windows uniquement), vous pouvez définir les attributs suivants :
        <CustomBuildInfo references="assembly_references"
          configuration="build_configuration"/>
        • Ajoutez des références d'assemblage à l'aide de l'attribut references. Séparez les différentes références à l'aide d'un point-virgule.
        • Incluez une configuration de génération pour la découverte de la solution Visual Studio à l'aide de l'attribut configuration.
        • Utilisez l'attribut package_includes pour remplacer les exclusions de tiers existantes et n'examiner que les classes appartenant aux espaces de noms donnés. Utilisez des points-virgules pour délimiter la liste des espaces de noms. Exemple :
          package_includes="com.hcl.example;com.hcl.sample"
        • Utilisez l'attribut package_excludes pour ajouter les espaces de noms spécifiés à la liste existante des exclusions de tiers. Utilisez des points-virgules pour délimiter la liste des espaces de noms.
      • Pour C/C++ (Windows uniquement), vous pouvez définir les attributs suivants :
        <CustomBuildInfo configuration="build_configuration"
          include_paths="include_directories" macros="macros" compiler_opts=/>
        • Utilisez l'attribut configuration pour inclure une configuration de génération.
        • Spécifiez des chemins d'accès d'inclusion avec l'attribut include_paths. Séparez les différents chemins d'inclusion à l'aide d'un point-virgule.
        • Incluez des macros à l'aide de l'attribut macros. Séparez les différentes macros à l'aide d'un point-virgule.
        • Spécifiez des options de compilation à l'aide de l'attribut compiler_opts. Séparez les différentes options à l'aide d'un point-virgule.
    Remarque : les valeurs définies par ces attributs sont reportées sur des sous-cibles. Par exemple, si votre cible est un fichier EAR qui comprend des sous-cibles WAR et JAR, il est supposé que ces sous-cibles WAR et JAR ont les mêmes valeurs que celles définies pour le fichier EAR qui utilise ces attributs.
  • Utilisez l'élément enfant Include pour spécifier des modèles de fichiers (<string_pattern>) à inclure lors de la génération du fichier IRX. Le comportement Include dépend du type de cible, comme expliqué à la section Comportement d'inclusion et d'exclusion des cibles. Pour spécifier plusieurs modèles include, ajoutez chaque modèle dans sa propre balise <Include></Include>. Par exemple,
    <Include>string_pattern_1</Include>
    <Include>string_pattern_2</Include>
    Remarque : Si vous spécifiez des modèles include et exclude contradictoires, les modèles exclude ont la priorité.
  • Utilisez l'élément enfant Exclude pour spécifier des modèles de fichiers à exclure lors de la génération du fichier IRX. Le comportement Exclude dépend du type de cible, comme expliqué à la section Comportement d'inclusion et d'exclusion des cibles. Pour spécifier plusieurs modèles exclude, ajoutez chaque modèle dans sa propre balise <Exclude></Exclude>.
    Remarque : Si vous spécifiez des modèles include et exclude contradictoires, les modèles exclude ont la priorité.

Comportement d'inclusion et d'exclusion des cibles

Tableau 1. Comportement d'inclusion et d'exclusion des cibles

Ce tableau décrit le comportement des paramètres include et exclude, par type de cible.

Type de cible Comportement Exemples
.dll Si votre cible est un fichier .dll, l'inclusion ou l'exclusion de cibles n'a aucun impact sur l'examen, étant donné que ces fichiers ne peuvent pas contenir de cibles.
.jar Si votre cible est un fichier .jar, vous pouvez exclure des fichiers .class dans le fichier .jar. *MyClass.class
.war Si votre cible est un fichier .war, vous pouvez exclure .class, .jsp et des types de fichiers JavaScript, ainsi que des fichiers .jar dans WEB-INF/lib.
Remarque : Par défaut, les fichiers .jar sont considérés comme du code tiers et ajoutés au chemin d'accès aux classes du fichier .war (et exclus par défaut).
com.ibm.*.jar
.ear Si votre cible est un fichier .ear, vous pouvez inclure ou exclure des fichiers .jar et .war.
  • com.ibm.*.jar
  • JSPWiki.war
répertoire Si votre cible est un répertoire, vous pouvez inclure ou exclure le chemin ou le nom du fichier de n'importe quelle cible, n'importe quel type de cible ou fichier d'examen.
Remarque : La barre oblique de fin est requise lors de la spécification des répertoires.
  • com.ibm.*.jar
  • test/: inclut ou exclut l'ensemble du contenu du répertoire test/ et de ses sous-répertoires.
  • test/*.jar: inclut ou exclut tous les fichiers .jar du répertoire test/, mais pas de ses sous-répertoires.
  • myFile.js
Serveur Web (voir Configuration système requise pour en savoir plus sur les serveurs Web pris en charge) Si votre cible est un serveur Web, vous pouvez inclure ou exclure le nom de fichier de toutes les applications déployées sur le serveur.
  • JSPWiki.war
  • MyApp.ear
  • *.war (Lorsque la cible est un serveur Tomcat)
.sln (.NET) Si votre cible est un fichier de solution Visual Studio qui contient des projets .NET, vous pouvez inclure ou exclure le nom de fichier de tous les assemblages .NET produits par un projet dans la solution.
  • *\MyLib.dll
  • *\MyApp.exe
.sln (C/C++) Si votre cible est un fichier de solution Visual Studio qui contient des projets C/C++ non gérés, vous pouvez inclure ou exclure le nom de fichier de tous les projets.
  • *\myProject.vcxproj

Exemple de fichier de configuration

<Configuration>
  <Targets>
    <Target path="C:\test\MyApplication.ear">
      <CustomBuildInfo additional_classpath="C:\java\lib;C:\java2\lib"
        jdk_path="C:\Program Files\Java\jdk1.7" jsp_compiler="C:\Tomcat"/>
      <Include>ShoppingCart.war</Include>
      <Include>*Account.jar</Include>
      <Exclude>thirdPartyJars/</Exclude>
      <Exclude>*test*</Exclude>
    </Target>
  </Targets>
</Configuration>
Dans ce fichier de configuration :
  • C:\test\MyApplication.ear est la cible.
  • C:\java\lib et C:\java2\lib sont analysés afin de rechercher d'éventuelles dépendances de fichiers de classe nécessaires à la compilation.
  • C:\Program Files\Java\jdk1.7 sert à localiser des dépendances.
  • Le compilateur C:\Tomcat est utilisé pour la compilation JSP au lieu de l'application Apache Tomcat version 7 incluse avec l'Utilitaire de ligne de commande Static Analyzer.
  • Lorsque le fichier IRX est généré, le fichier ShoppingCart.war est inclus, tout comme tous les fichiers qui se terminent par *Account.jar. Dans le fichier EAR, l'ensemble du contenu de thirdPartyJars/ est exclu, tout comme tous les fichiers qui comportent la chaîne test dans leur nom. En cas de conflits, les modèles exclude ont la priorité. Par exemple, si le fichier EAR contient un fichier testCustomerAccount.jar, il est exclu, étant donné que le modèle de test exclude a la priorité sur le modèle *Account.jar include.