5. Analyses

How to create a new analysis

To create a new analysis, the developer should create a class that inherits from the RuleVisitor. The new class should implement the abstract methods defined in the Rule Visitor and override the others if necessary (e.g. different way to check a Unit Block). We will also need to add to the ERRORS constant the identification codes and descriptions of the new issues being detected. The issues are grouped by their respective Visitor and the key being used is the string returned by the get_name method. In the main file, we need to import the new Visitor. Even though the Visitor seems to not be used, it is required to import it in order to add it to the options in the command-line tool.

Configurations

The GLITCH framework allows to define configurations in INI files. When using the command-line tool, the user may choose the configuration that they want. Configurations allow users to tweak the tool to best suit the needs of the IaC developers and to better adapt to each IaC technology. One example of usage is to define the keywords that trigger the detection of a certain smell. A default configuration is defined for GLITCH and should be changed when a new Visitor is added. The configuration is loaded by the config method implemented in each Visitor. We recommend the usage of the configparser package to read the INI file as shown in the example below.

    def config(self, config_path: str):
        config = configparser.ConfigParser()
        config.read(config_path)
        SecurityVisitor.__WRONG_WORDS = json.loads(config['security']['suspicious_words'])
        SecurityVisitor.__PASSWORDS = json.loads(config['security']['passwords'])
        SecurityVisitor.__USERS = json.loads(config['security']['users'])
        SecurityVisitor.__SECRETS = json.loads(config['security']['secrets'])
        SecurityVisitor.__MISC_SECRETS = json.loads(config['security']['misc_secrets'])

Smell checkers - Adding specific behavior

If specific behavior for a technology is required, the Visitors select, in their constructor and according to the chosen technology, objects called SmellChecker. These objects must implement a check method that returns a list of Errors and will be called in the implementation of the Visitor's methods to check the components of the intermediate representation.

For example, we may define in the constructor of the Visitor the following:

        if tech == Tech.ansible:
            self.imp_align = DesignVisitor.AnsibleImproperAlignmentSmell()
        elif tech == Tech.puppet:
            self.imp_align = DesignVisitor.PuppetImproperAlignmentSmell()
        else:
            self.imp_align = DesignVisitor.ImproperAlignmentSmell()

Later, we can call in the Visitor's method the respective SmellChecker to verify the Improper Alignment smell:

        errors += self.imp_align.check(u, u.path)