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

Can I filter incidents by type in the Incidents module?

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.

What's the difference between incident status and resource status?

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.

Do I have to authorize Pre-Authorized resources?

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.

If I authorize a resource in the Resources module, does the incident automatically resolve?

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.

Can I mark an incident as Resolved without authorizing the resource?

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

What happens if I mark an incident as Ignored?

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.

Which module should I use - Incidents or Resources?

  • 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.

Can I change my authorization decision later?

No. You can't change resource status when you decided to Authorized or Not Authorized, you can't undone or change this action.

Do "Not Authorized" resources get blocked on my page?

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.


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

Last updated