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 withaddress
,port
,protocol
, andts
fields.
v1.1.0 (2025-06-03)¶
- Add the
violate-schema
configuration option, which adds a newviolation
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.