Resource Events

Resource events are available to customers who have purchased RiskIQ JavaScript Threats (view product description). They alert customers to newly added or changed dependent resources within covered asset sites that are malicious, suspicious, or constitute SRI (sub-resource integrity) violations. Tracking resource changes is fundamental to knowing your evolving attack surface and identifying malicious JavaScript attacks like Magecart for example.

When a policy violation is found, a Resource event is created in the workspace, which can be viewed in the the events dashboard and events list inside the RiskIQ web application, in an email alert, or via the RiskIQ events API. For a general introduction to events and other parts of the RiskIQ system, please see RiskIQ Platform Architecture.

Outlined below are tips on:

  1. How to read and interpret the information presented in a Resource event (field definitions)
  2. Suggested best practices for Resource event management, including user workflow and tagging
  3. How it works: Resource Event detection and system overview

Example: a Resource event alerting on a change in the content of a third party resource used RiskIQ uses for A/B testing on our main website,  While not an actual case of JavaScript attack on the site, in this case, the new content contained a site with a non-standard TLD / nTLD (.cloud), which is one of the suspicious change policies that is configured to trigger an alert for review.

Reading Resource Events - Field Definitions

Event List Item

This is how Resource events are represented in the Events section of the RiskIQ web application. Clicking on a list item brings up details for the event and user-initiated workflow actions. 

  • Event-type: Resource
  • Action: Whether the event was triggered for newly added resource or a changed existing resource
  • Ownership: Whether the resource associated to this event is self-hosted or third-party hosted
  • Status: current status of the event.
  • Created: date the event was generated.
  • Updated: date the event last changed status or was otherwise edited (most recent update recorded in the event history).
  • Tags (if any have been applied)

Event Header

At the top of each event's details is a header containing high-level information, as well as workflow actions.

  • Status: current event status and the ability to change the status of this event.
  • Tags: Tags applied to this event and the ability to add or remove tags (if any tags are configured for this event-type).
  • Owner: current event owner responsible for reviewing or tracking the event and the ability to assign a new owner for this event. 
  • Priority: current event priority and the ability to assign a new priority for this event. 
  • Email Event Details (via envelope icon at top right)

Summary Tab

The Summary provides basic information for assessing the event and deciding how to act on it. The Summary tab is organized into multiple sections:


  • A 1 sentence summary of the change/addition that occurred, ex. "The content of resource: changed on host"


  • Asset: The asset host on which the resource addition or change was detected
  • Resource URL: The URL of the JavaScript resource found within page content on the asset host
  • Resource Host: The hostname of the resource URL
  • Resource MD5: MD5 hash of the resource
  • Provider: Whether the resource is self-hosted (the resource host is also an asset host) or third-party hosted
  • Incident Date: Timestamp of the crawl that observed the resource addition or change that triggered this event
  • Resource URL First Seen: Timestamp of the crawl that first observed this resource present on the asset host
  • Dynamic Score: Score between 0 and 1 indicating how likely it is that a resource is dynamically generated. A higher score means that changes are expected to occur frequently, whereas events with a lower score might be viewed with more scrutiny as they show a change occurring to an otherwise relatively stable resource
  • Response Body Size: The size of the resource's response body. A very small response body typically means a lower risk of malicious content, whereas a larger one may be more suspicious
  • Blacklisted: (T/F) Whether a resource is believed to be malicious
  • Suspicious: (T/F) Whether a resource triggers one of the suspicious policy conditions (naked IP, nTLD, or newly observed host or domain)
  • Has SRI Violation: (T/F) Whether a resource's MD5 does not match the expected value (applicable only if expected values are provided in the site)

MALICIOUS (if applicable)

  •  Match Type: Whether the match is on a domain name, hostname, or URL
  • Correlation: Reputation or exact match
  • More Info: RiskIQ blacklist rule / description

SUSPICIOUS (if applicable)

  • Rule: Which suspicious policy was triggered (suspicious TLD, Newly observed domain or host, or bare IP address)
  • Matched: How many matches on the rule were found
  • Description: Text description of the rule
  • Matched On: What in the resource triggered the match
  • Component: Where the match was found (content of the resource of the resource URL)

HAS SRI VIOLATION (if applicable)

  • Last observed SRI Violation: Date/time of the most recent time this violation was observed
  • Expected SRI Hash: The hash value that was expected, but not found for this resource


  • Timeline of changes made to the event with the date, time, and name of the user who took each action, including:
    • Status changes 
    • Emails sent (with recipients)
    • Notes added
    • Tags added/removed

Crawls Tab

This section houses information on RiskIQ's observation of the page containing the resource when it was added or changed. 

Details provided about the crawl include: 

  • An overview providing metadata on the crawl performed by the virtual user
    • Global Unique Identifiers for the user session and the page within the user session
    • Date and time
    • Initial URL where the virtual user began the crawl
    • Browser used
    • Geographic location of the virtual user
    • Total number of pages visited during the user session
    • Total number of pages visited that returned error messages
    • URL of the event page
    • IP address
    • Response code and message returned by the event page
    • Page Content-type
    • Page Content length
    • Page response time
    • Window name
  • The original HTML response of the page
  • The rendered document object model after the page loaded in the user's browser
  • Headers

Managing Resource Events - User Review Decision Workflow and Tagging Best Practices

The flow chart below describes a decision tree encompassing best practices for reviewing Resource events. It describes in more detail the 'User Review' step in the system overview diagram at the end of this article.

  • Green represents steps taken automatically by the RiskIQ system
  • Pink represents steps taken by a human user
  • Blue represents a status and/or tag label

Tag Set

  • Requires Remediation
  • Acceptable Risk

Resource Event System Overview


The dependent resources within a page are recorded for each and every crawl that RiskIQ performs across the platform, and RiskIQ aggregates these observations in order to track at a higher level whether a particular resource URL (ignoring dynamic parameters in the URL path) has ever been seen being used on any pages for that hostname before, or whether the resource content has changed since the last time it was observed. 

If any of the hosts on which a new or changed resource was found are enterprise host assets in a client workspace where Resource events are enabled, then that occurrence is eligible to create a Resource event and is analyzed against the configured Resource event policies and exclusions.

*Exclusion rules are global and managed by the RiskIQ Research team.

Available Policies:

AssetMaliciousSuspicious SRI Violation
HostResource URL or content component has blacklist reputation or matches known malware signaturesResource URL or content contains
  • Non-standard TLD
  • Bare IP address
  • Newly observed domain or host
Resource expected and observed hash mismatch (only applicable if expected SRI values provided by site owner)

System Overview

The following diagram follows a Resource event through the RiskIQ system from detection through review and monitoring. 

  • Green represents steps taken automatically by the RiskIQ system
  • Pink represents steps taken by a human user
  • Blue represents a status and/or tag label

Monitoring and Resolution

  • While the asset sites from which Resource events are created are continually monitored, Resource events themselves are not. Resource events are based on a point in time change, which cannot be monitored or "re-observed" for resolution purposes. Thus, All Resource events must be manually resolved by a user. 
  • Any new changes or new added resources on the same site / page constitute new events of their own, not an update to a pre-existing event ID.