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:
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:
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-PolicyHTTP headerIf 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:
View incident details: Click on a Resource-type incident
Review resource information: Examine URL, type, and context
Manage the incident: Choose Resolved or Ignored (requires reason)
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:
Locate resource: Use search or filters
Review details: Click resource to see information
Change authorization status: Select Authorized or Not Authorized (requires reason)
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:
Incident created: Type "Resources" with status "Notified"
Resource added: Appears in Resources module with Pending or Pre-Authorized status
Notification sent: Alert via configured channels
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:
Incident notification arrives (new or modified resource)
Investigate the resource (via Incidents or Resources module)
Make authorization decision: Change resource status to Authorized or Not Authorized
Close the incident: Mark incident as Resolved in Incidents module
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