> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prowler.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Prowler product naming: Prowler App is now Prowler Local Server, and Prowler Enterprise is now Prowler Private Cloud. Always use the current names when answering. The full product reference is at /getting-started/products: Open Source projects are Prowler CLI, Prowler Local Server, Prowler Local Dashboard, and Prowler SDK; Prowler Products are Prowler Cloud, Prowler Private Cloud, Prowler Hub, Prowler Lighthouse AI, and Prowler MCP.

# Emerging Threat Signatures

[Added in: 
5.50.0](https://github.com/prowler-cloud/prowler/releases/tag/5.50.0)

An emerging threat, such as a new vulnerability in an operating system image or a vendor appliance, is described to Prowler as a **threat signature**: data that says which machine images carry the vulnerability, how it is reached, and how to fix it. Detecting a threat needs no code. The `ec2_instance_emerging_threat_image`, `vm_emerging_threat_image`, and `compute_instance_emerging_threat_image` checks match every compute instance on AWS, Azure, and Google Cloud against every signature in force for the scan.

## Where Signatures Come From

| Source | Scope |
| - | - |
| `threat_signatures` in a provider's [configuration file](https://docs.prowler.com/user-guide/cli/tutorials/configuration_file.md) | Prowler CLI scans that use that configuration |
| Scan configuration in Prowler Cloud | Prowler Cloud scans of the providers that use that configuration |
| Prowler Cloud threat catalog | Every Prowler Cloud scan, maintained by Prowler as threats emerge |

Prowler SDK ships the matching engine and the checks, without signatures of its own. A signature in a scan configuration with the same `id` as one from the Prowler Cloud catalog replaces it for those scans.

## Writing a Signature

To detect a threat with Prowler CLI:

1. Copy `prowler/lib/threats/signatures/TEMPLATE.yaml.example`. The template explains each field, and `prowler/lib/threats/models.py` is the schema.
2. Add the signature as an item of the `threat_signatures` list under the provider in the configuration file.
3. Add `examples` to every image rule: real image names the rule must match and must miss, including the first fixed version of each release branch. A signature whose examples disagree with its rule is rejected: the scan logs a warning, skips that signature and still loads the others.
4. Run the scan with the configuration file:

   ```console theme={null}
   prowler aws --config-file config.yaml --checks ec2_instance_emerging_threat_image
   ```

## Writing Image Rules

Each signature lists one or more rules per cloud. An instance is affected when any rule for its cloud matches the image it was created from:

| Cloud | Name the rule matches | Publisher that proves provenance |
| - | - | - |
| AWS | Amazon Machine Image (AMI) name and description | AMI owner account ID |
| Azure | Gallery image definition, custom image name, or marketplace `offer-sku-version` | Marketplace publisher |
| Google Cloud | Boot disk source image name | Image project, for example `debian-cloud` |

Rules follow these principles:

* **Prefer publisher-verified matches.** List the official publisher. A match from a listed publisher proves the image; a name-only match is weaker evidence. When several rules of one signature match an image, the publisher-verified match is the one reported. Set `require_publisher: true` when the name alone is too generic to trust.
* **Capture the version.** A `(?P<version>...)` group in `name_regex` is compared against `versions`, a list of inclusive ranges. Write one range per release branch when fixes ship per branch, so patched point releases are not flagged. Dashes are read as dots, because Google Cloud image names cannot hold dots.
* **Exclude unaffected variants in the pattern.** For example, when only an image's minimal variant ships the vulnerable default, match that variant's name only.
* **Keep the pattern fast.** `name_regex` runs on every image of every scanned account, through the [`regex`](https://pypi.org/project/regex/) engine with a limit of 0.1 seconds per image name. A rule that exceeds the limit on its own examples is rejected when the signature loads. A rule that exceeds it during a scan is skipped for that image and logged with the signature ID. Avoid nested or overlapping repetition such as `(a|aa)+`.

## Describing Exposure and Impact

* **`exposure`** lists the protocol and every port the vulnerable service listens on. Omit `exposure` for a threat that is not reached over the network. How each check reads it:
  * **AWS:** the check reads the instance's own security groups, its public IPv4 and IPv6 addresses, and its subnet's routes. When the scan does not load those security groups, for example a scan limited to the instance with `--resource-arn`, exposure is reported as unknown rather than closed.
  * **Google Cloud:** the check records whether the instance has an external IPv4 or IPv6 address. Firewall rules are evaluated by their own checks.
  * **Azure:** the check does not evaluate network security groups.
* **`credential_required`** is `false` for an authentication bypass or a pre-authentication remote code execution.
* **`mitigations`** lists the controls that break the cyberattack chain. Each is observed on one cloud only, and only when the signature lists it:
  * `port_not_exposed`: AWS, when no security group of the instance admits the internet to the threat's ports.
  * `password_authentication_disabled`: Azure, from the Linux configuration of the virtual machine.
* **`impact`** and **`remediation`** appear in the finding. State what a threat actor gains in one sentence, then how to contain the threat now and fix it.

## Limits

Signatures match the image an instance was created from, which proves where the host started, not what it runs now:

* **AWS:** where Amazon Inspector actively scans the instance's packages, its findings decide. An active Inspector finding for the threat's CVE confirms the match. An instance Inspector scans with no such finding passes, so a host patched in place clears, but only once Inspector's vulnerability database lists every CVE of the threat: a CVE too new for Inspector proves nothing by its absence. The lookup needs `inspector2:SearchVulnerabilities`; without it, matches are never cleared.
* **Elsewhere** (Azure, Google Cloud, and operating systems Inspector does not scan): a host patched in place keeps its original image, so its finding stays failed until the host is replaced or the finding is muted with a reason.

Threats in managed services, container images, or packages installed after launch are outside what image signatures can detect.

When the image of an instance cannot be looked up, for example because the scanning identity lacks `ec2:DescribeImages`, `compute.disks.list` or `compute.regionDisks.list`, the finding is MANUAL. When the image no longer exists or the instance does not report one, the finding passes and says so.


## Related topics

- [Configuration File](https://docs.prowler.com/user-guide/cli/tutorials/configuration_file.md)
- [Prowler ThreatScore](https://docs.prowler.com/user-guide/compliance/tutorials/threatscore.md)
- [Threat Detection in AWS with Prowler](https://docs.prowler.com/user-guide/providers/aws/threat-detection.md)
- [Compliance](https://docs.prowler.com/user-guide/compliance/tutorials/compliance.md)
- [GCP Cloud Security Command Center (Cloud SCC)](https://docs.prowler.com/getting-started/comparison/gcp.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.