> For the complete documentation index, see [llms.txt](https://firstoken.gitbook.io/api-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://firstoken.gitbook.io/api-docs/guides/implementing-monitor/resources-and-script-inventory/how-resources-inventory-works.md).

# How Resources Inventory Works

### Overview

Resources and Script Inventory automatically scans your payment pages to discover all JavaScript and CSS resources. The system generates incidents for new or modified resources and provides two ways to manage them: through the **Incidents** module or the **Resources** module.

***

### Automated Scanning Process

#### **Initial Scan**

When you enable Resources and Script Inventory:

* **Immediate execution**: Complete scan runs within minutes
* **Resource discovery**: Identifies all JavaScript and CSS files (internal and external)
* **Inventory creation**: Adds each resource to the Resources module
* **Status assignment**: Sets initial status based on CSP configuration (If you have it configured in your code)
* **Incident generation**: Creates incidents for all discovered resources

#### **Weekly Monitoring**

After the initial scan:

* **Fixed schedule**: Scans run automatically every week
* **Change detection**: Compares current resources against previous scan
* **Content verification**: Uses content hash to detect modifications
* **Incident creation**: Generates new incident for each change detected

#### **What Gets Scanned**

The system tracks only JavaScript and CSS resources:

| Resource Type             | Description                          | Example                                |
| ------------------------- | ------------------------------------ | -------------------------------------- |
| **JavaScript - External** | JS files from third-party domains    | `https://cdn.example.com/analytics.js` |
| **JavaScript - Internal** | JS files from your domain            | `https://yoursite.com/checkout.js`     |
| **CSS - External**        | Stylesheets from third-party domains | `https://fonts.googleapis.com/css2`    |
| **CSS - Internal**        | Stylesheets from your domain         | `https://yoursite.com/styles.css`      |

***

### Resource Status

Each resource has one of four possible statuses:

| Status             | Description                                    | When Applied                                       |
| ------------------ | ---------------------------------------------- | -------------------------------------------------- |
| **Pending**        | New resource awaiting review                   | Resource found but no CSP configuration            |
| **Pre-Authorized** | Resource allowed in CSP but needs confirmation | Resource found in `Content-Security-Policy` header |
| **Authorized**     | Approved for use with documented justification | Manually authorized by reviewer                    |
| **Not Authorized** | Rejected - should not be present               | Manually blocked by reviewer                       |

> **Pre-Authorized Status**
>
> When a resource is detected and you have CSP configured:
>
> * The system reads your `Content-Security-Policy` HTTP header
> * If the resource domain/URL is allowed in your CSP policy, status is set to **Pre-Authorized**
> * This indicates the resource is technically permitted but still requires manual review
> * You must review and either authorize or reject pre-authorized resources

***

### Two Ways to Manage Resources

#### **1. Incidents Module**

The **Incidents** page shows all security incidents including CSP violations, Security Headers issues, and Resources changes.

**What you can do here:**

* View all incident types in one list (no filtering available)
* Manage the **incident status**: Notified → Resolved or Ignored
* View resource details within the incident
* **Also manage the resource status**: Change to Authorized or Not Authorized
* Both incident actions and resource actions require documented reasons

**Characteristics:**

* Each incident starts with status **Notified**
* For Resource-type incidents, you'll see:
  * Resource URL and type (JavaScript/CSS)
  * Whether it's internal or external
  * Detection date
  * Current resource authorization status

**Managing through Incidents:**

1. **View incident details**: Click on a Resource-type incident
2. **Review resource information**: Examine URL, type, and context
3. **Manage the incident**: Choose Resolved or Ignored (requires reason)
4. **Optionally manage the resource**: Change status to Authorized or Not Authorized (requires reason)

**Note**: Changing resource status does NOT automatically change incident status, and vice versa. They are independent. Best practice is to authorize/reject the resource AND mark the incident as Resolved.

#### **2. Resources Module**

The **Resources** page provides a dedicated inventory view focused exclusively on resource management.

**What you can do here:**

* Search and filter your JavaScript and CSS inventory
* **Only manage resource authorization status** (cannot manage incidents here)
* View complete resource details
* Change authorization status with documented reasons

**Features:**

* **Search by name**: Find specific resources by URL
* **Filter by type**: JavaScript or CSS
* **Filter by origin**: Internal or External
* **Filter by status**: Pending, Pre-Authorized, Authorized, Not Authorized

**Managing through Resources:**

1. **Locate resource**: Use search or filters
2. **Review details**: Click resource to see information
3. **Change authorization status**: Select Authorized or Not Authorized (requires reason)
4. **Save**: Resource status updates

**Note**: When you change resource status here, the incident status is NOT automatically updated. You should separately go to Incidents and mark the incident as Resolved.

***

### Incident Status vs Resource Status

These are **independent systems** that track different things:

#### **Incident Status (in Incidents module)**

Tracks the **notification/alert** about a resource change:

* **Notified**: Initial status - you've been alerted about a resource
* **Resolved**: You've addressed the incident notification
* **Ignored**: You've acknowledged but chosen not to act

#### **Resource Status (in Resources module)**

Tracks the **authorization state** of the JavaScript/CSS file itself:

* **Pending**: Awaiting authorization review
* **Pre-Authorized**: Found in CSP, needs confirmation
* **Authorized**: Approved with justification
* **Not Authorized**: Rejected with reason

> #### **Key points:**
>
> * Changing resource status (Authorized/Not Authorized) does NOT automatically change incident status
> * Changing incident status (Resolved/Ignored) does NOT change resource status
> * **Best practice**: When you authorize or reject a resource, you should also mark the incident as Resolved
> * Both actions are independent but ideally should be coordinated

***

### Management Workflow

#### **When New Resources Are Detected**

Weekly scans generate incidents for new resources:

1. **Incident created**: Type "Resources" with status "Notified"
2. **Resource added**: Appears in Resources module with Pending or Pre-Authorized status
3. **Notification sent**: Alert via configured channels
4. **Review required**: Both incident and resource need attention

#### **Reviewing and Managing**

**Option A: Through Incidents Module (Can manage both)**

* Navigate to Incidents page
* Click Resource incident to view details
* You can do either or both:
  * **Manage incident**: Mark as Resolved or Ignored (requires reason)
  * **Manage resource**: Change to Authorized or Not Authorized (requires reason)
* **Best practice**: Do both - authorize/reject the resource AND mark incident as Resolved

**Option B: Through Resources Module (Can only manage resource)**

* Navigate to Resources module
* Find resource using search/filters
* Click resource and review details
* Change authorization status to Authorized or Not Authorized (requires reason)
* **Important**: This does NOT update the incident - you should separately mark the incident as Resolved in the Incidents module

#### **Complete Workflow Best Practice**

For proper incident tracking and compliance:

1. **Incident notification arrives** (new or modified resource)
2. **Investigate the resource** (via Incidents or Resources module)
3. **Make authorization decision**: Change resource status to Authorized or Not Authorized
4. **Close the incident**: Mark incident as Resolved in Incidents module
5. **Document both**: Provide reasons for both the resource decision and incident resolution

This ensures:

* Resources are properly authorized for PCI DSS 6.4.3
* Incidents are properly tracked and resolved
* Complete audit trail for both systems

#### **Authorization Requirements**

**Every decision requires documentation** - you cannot resolve an incident, ignore it, authorize a resource, or reject a resource without providing a reason.

**For Authorized resources**, explain:

* Business purpose (e.g., "Required for payment processing")
* Vendor information (e.g., "Stripe SDK - approved vendor")
* Security assessment reference (e.g., "Per InfoSec policy SEC-001")
* Approval details (e.g., "Approved by CTO on 2024-01-15")

**For Not Authorized resources**, explain:

* Security concern (e.g., "Unknown third-party script")
* Policy violation (e.g., "Not approved per policy SEC-002")
* Action taken (e.g., "Development team notified for removal")

**For Resolved/Ignored incidents**, explain:

* What action was taken or why no action is needed
* Any follow-up required
* Reference to resource authorization if applicable

***

### Modified Resources

When weekly scans detect content changes:

* **Incident generated**: New "Resources" incident created
* **Change detected**: Content hash is different from previous scan
* **Review required**: Verify modification is expected
* **Actions**:
  * If legitimate change: Mark incident Resolved with reason (resource remains Authorized)
  * If suspicious: Change resource to Not Authorized with reason
  * Document reasoning in incident resolution

***

### Frequently Asked Questions

{% columns %}
{% column width="41.66666666666667%" %}
**Can I filter incidents by type in the Incidents module?**
{% endcolumn %}

{% column width="58.33333333333333%" %}
No, the Incidents page currently shows all incident types (CSP, Headers, Resources) in one unified list without filtering options. To focus specifically on resource inventory, use the Resources module where you can search and filter.
{% endcolumn %}
{% endcolumns %}

{% columns %}
{% column width="41.66666666666667%" %}
**What's the difference between incident status and resource status?**
{% endcolumn %}

{% column width="58.33333333333333%" %}
They track different things:

* **Incident status** (Notified/Resolved/Ignored) = Status of the notification/alert
* **Resource status** (Pending/Pre-Authorized/Authorized/Not Authorized) = Authorization state of the actual JavaScript/CSS file

They are independent - changing one does NOT automatically change the other.
{% endcolumn %}
{% endcolumns %}

{% columns %}
{% column width="41.66666666666667%" %}
**Do I have to authorize Pre-Authorized resources?**
{% endcolumn %}

{% column width="58.33333333333333%" %}
Yes. Pre-Authorized status only means the resource is technically allowed in your CSP configuration. You must still review and explicitly authorize or reject it for PCI DSS 6.4.3 compliance. Pre-authorization is just a hint from your CSP, not final approval.
{% endcolumn %}
{% endcolumns %}

{% columns %}
{% column width="41.66666666666667%" %}
**If I authorize a resource in the Resources module, does the incident automatically resolve?**
{% endcolumn %}

{% column width="58.33333333333333%" %}
No. Incident status and resource status are independent. After authorizing/rejecting a resource, you should separately go to the Incidents page and mark the incident as Resolved. This ensures complete incident tracking.
{% endcolumn %}
{% endcolumns %}

{% columns %}
{% column width="41.66666666666667%" %}
**Can I mark an incident as Resolved without authorizing the resource?**
{% endcolumn %}

{% column width="58.33333333333333%" %}
Yes, technically you can. But this is not recommended because:

* The resource remains in Pending or Pre-Authorized status
* You haven't met PCI DSS 6.4.3 compliance requirements
* Best practice: authorize/reject the resource AND mark the incident as Resolved
  {% endcolumn %}
  {% endcolumns %}

{% columns %}
{% column width="41.66666666666667%" %}
**What happens if I mark an incident as Ignored?**
{% endcolumn %}

{% column width="58.33333333333333%" %}
The incident will be marked Ignored with your documented reason, but:

* The resource status does NOT change (remains Pending, Pre-Authorized, etc.)
* The resource still needs authorization for compliance
* You've only acknowledged the notification, not addressed the underlying resource

This creates a compliance gap. All resources must eventually be Authorized or Not Authorized.
{% endcolumn %}
{% endcolumns %}

{% columns %}
{% column width="41.66666666666667%" %}
**Which module should I use - Incidents or Resources?**
{% endcolumn %}

{% column width="58.33333333333333%" %}

* **Incidents module**: Use when you want to manage both the incident notification AND the resource authorization in one place
* **Resources module**: Use when you want to focus purely on resource inventory management with better search/filter capabilities

Many teams use Incidents for initial triage and Resources for ongoing inventory management.
{% endcolumn %}
{% endcolumns %}

{% columns %}
{% column width="41.66666666666667%" %}
**Can I change my authorization decision later?**
{% endcolumn %}

{% column width="58.33333333333333%" %}
No. You can't change resource status when you decided to Authorized or Not Authorized, you can't undone or change this action.
{% endcolumn %}
{% endcolumns %}

{% columns %}
{% column width="41.66666666666667%" %}
**Do "Not Authorized" resources get blocked on my page?**
{% endcolumn %}

{% column width="58.33333333333333%" %}
No. The "Not Authorized" status is for **tracking and compliance purposes only**—it documents that the resource should not be present. The system does not prevent the resource from loading. You must coordinate with your development team to actually remove Not Authorized resources from your code.
{% endcolumn %}
{% endcolumns %}

***

#### Support

Need help managing your resource inventory?

* **Technical Support**: Contact our team for assistance
* **Best Practices Guide**: Request detailed authorization workflow documentation
* **Compliance Support**: Ask about PCI DSS 6.4.3 audit preparation