Skip to content

Modules

Introduction

Information about the installed modules is collected from the Audit Agent every day. You can find a list of all of the installed third-party modules on the Modules page.

Module data

Modules We match each module against our central database of modules in order to provide you with useful information.

This includes:

  • Module name
  • Business purpose
  • Type of module (commercial, open source, bespoke, etc)
  • The version installed
  • The vendor's most recent version
  • A changelog showing the fixes, feature changes, etc between the installed and most recent versions.
  • Module location (app/code or vendor)
  • Concern

How concern is calculated for modules

A variety of factors determines how we set the Concern for each module. Some of these are as follows:

  • How old the module is compared to the most recent version available from the vendor.
  • Whether there are any security fixes for the module available from the vendor.
  • Any general concerns we have about the module (e.g. performance issues, security issues, coding problems).
  • Whether the module's hash value has changed.

Proactive module update availability notifications

We maintain a database of a huge number of Magento modules, covering commercial products and open source projects. This database is updated daily as vendors release updates to existing products, or launch entirely new products.

Our team researches the busines purpose of every module, and we maintain an accurate changelog for every module.

Therefore, if a vendor releases an update to a module that is installed on one or more websites, we will generate a message notification to you to let you know. This typically happens within a few business days of the update being released.

We manually review every module update in order to determine if there are any security updates or other important changes. If there are, then you will receive a "critical" message notification, so that you can take the appropriate action proactively for your client.

Code hashing / malicious change detector

The Audit Agent checks for changes to your codebase proactively every day. This helps detect security issues caused by unauthorised/malicious changes being made. This is especially useful when new exploits are used, in the period before services like Sansec eComscan are aware of how to detect the vulnerability.

We check every package in app/code and vendor (even non-Magento PHP libraries), and every theme in app/design. Each package is hashed to produce a unique value, which is sent to our platform by the Audit Agent. If this value changes between scans for a given directory, then this represents that the code has been changed.

We determine this to be of "Critical" concern, and you will receive an instant notification via a portal message, email and Slack (if you have it configured). You should then investigate the changed package and compare it against the code that you last deployed. Of course, the code change could be part of a known scheduled deployment, in which case you will simply ignore the message.

Bespoke modules

When our platform detects a module that it hasn't seen before across all of our clients, our team manually review it. If it is a new commercial or open source module, then we'll add this to our database within a few business days.

However, if it appears to be a module specific to your client's website then we'll mark it as bespoke.

Is the code of the modules transferred from the server?

No, the modules' code remains on your server at all times. We only transfer the list of modules, together with the version number and unique hashed checksum value of the module's files.