Skip to content

Scanning Engine v2 - Module - NoOp

Overview

The noop scanning module exists for testing purposes. Despite being a scanning module, it will not generate any network traffic. This module will emit its input arguments as output.

Targeting

This module produces no network traffic, but can still optionally target services. If the ports key of its module invocation doesn't contain any port definitions, this module will run on each target in a job. If the ports key is not empty, and port scans are disabled, this module will run on every requested port for every target. If the ports key is not empty, and port scans are enabled, this module will run on every requested port found to be open on a target. This targeting behavior is useful for checking how the system is building the task tree.

Schemas

The schema for the body object of all results generated with .task.module_name equal to noop can be found here. The schema for results is available both in standalone and bundled form.

Examples

These are examples of the .body object for results with .task.module_name equal to noop. Note that the noop module does not send or receive network traffic, so the output of all examples are purely the result of the module configuration.

No Configuration

This example was generated without passing any configuration to the module.

{
  "args": [
    "--target",
    ",1.2.3.4,TCP,80",
    "--success-probability",
    "1"
  ],
  "env": {
    "GOTRACEBACK": "none",
    "TARGETS_PER_SHARD": "128"
  }
}

Changelog

v1.2.0 (2025-07-14)

  • Add targeting library support for standardized argument parsing and target handling.
  • Update output schema to align with standard scan result format.
  • Replace target field with address, port, protocol, and ts fields.

v1.1.0 (2025-06-03)

  • Add the violate-schema configuration option, which adds a new violation field that is not allowed by the output schema.
  • Supports testing both advisory and enforced schema validation without breaking modules or schemas.

v1.0.0 (2025-05-05)

  • Initial release of versioning for each module. All modules are being tagged with version number 1.0.0. Going forward:
  • Major version should be changed when there are changes that impact consumers or clients of the modules.
  • Minor version should be changed when there are additions which enrich or enhance the module but shouldn't affect consumers or clients.
  • Patch version should be changed when there are bugfixes.