feat: Adds Acceptance Test for ServiceNow

[davidhessler]

Description

Adds end-to-end acceptance tests for the ServiceNow integration with AWS Security Incident Response. The tests verify bidirectional synchronization between ServiceNow and AWS Security IR, including automated OAuth setup, CDK stack deployment, business rule creation, and incident replication in both directions.

Type of change (Choose 1)

• Bug Fix
• New Feature: Non-new Integration Target
• New Feature: New Integration Target
• Documentation update
• Security fix

Reason for this change

The ServiceNow integration lacked automated acceptance tests to validate the full integration flow. These tests ensure:

1. AWS Security IR cases properly replicate to ServiceNow incidents
2. ServiceNow incidents properly replicate to AWS Security IR cases
3. OAuth JWT authentication works correctly with the aws_integration service account
4. Business rules and webhook resources are properly configured
5. Role assignments (itil, sn_si.*, etc.) are correctly applied for both ITSM and IR modes

Related Issue (if applicable)

N/A

Contributor Task List

• I have reviewed the Contributing Guideline and Code of Conduct
• I have performed a self-review of my code
• I have added tests that prove my fix is effective or that my feature works
• New and existing tests pass locally with my changes
• The code coverage difference report check has passed
• Security considerations have been addressed

New Integration Target Questions

N/A - This is not a new integration target, it adds acceptance tests to the existing ServiceNow integration.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the MIT No Attribution license

[nshalabh]

I have requested for some changes that may be blocking, particularly the service_now_resource_setup lambda. We would need to test E2E scenarios between SIR and SNOW for the BR related changes.

[davidhessler]

Summary: sys_id vs user_id for ServiceNow JWT Authentication via Slack

Decision

The team decided to use sys_id instead of user_id for ServiceNow authentication.

Key Reasons

1. Performance

• Using sys_id skips internal ServiceNow fetch calls to linked tables
• user_id requires lookup queries to resolve the display value into a sys_id

2. Security & Permissions

• sys_id bypasses ACL (Access Control List) checks since it's a direct reference
• user_id triggers ACL exceptions because the lookup is essentially a GET request on sys_user table
• Field-level ACLs can block access to user_id fields, causing "security constraint" errors
• ServiceNow's "Two-Gate Model" requires passing both table-level and field-level Read ACLs for indirect lookups

3. Uniqueness & Stability

• sys_id is globally unique and immutable (primary key)
• user_id is only unique at the instance level and can be changed

4. Industry Practice
   Multiple platforms use sys_id for ServiceNow integrations:

• Genesys Cloud
• Harness SEI
• HackerOne
• Leena AI

Technical Details

• Reference fields in ServiceNow store only the 32-character sys_id GUID in the database
• Display values (like user_id) require explicit configuration to resolve
• Direct sys_id references avoid the lookup layer entirely, preventing permission-related failures