SOCRadar v2.3.0: Add complete integration suite

[Radargoger]

Contributing to Cortex XSOAR Content

Make sure to register your contribution by filling the contribution registration form

The Pull Request will be reviewed only after the contribution registration form is filled.

Status

• In Progress
• Ready
• In Hold - (Reason for hold)

Related Issues

Description

This PR adds three new integrations to the SOCRadar pack (v2.2.2):

1. SOCRadar Rapid Reputation - Fast reputation checking for IPs, domains, URLs, and file hashes with bulk support (up to 100 indicators) and automatic rate limiting.

2. SOCRadar IoC Enrichment - Deep threat intelligence enrichment with signal strength, confidence levels, activity labels, premium feeds, relations, and optional AI insights.

3. SOCRadar Threat Feed - Collection-based IoC feed integration for automated indicator ingestion using collection UUIDs with incremental feed capability and comprehensive geolocation data.

All integrations follow Cortex XSOAR best practices, include comprehensive documentation, and are production-ready.

Must have

• Tests - Unit tests included for Threat Feed (14 test cases, all passing)
• Documentation - Complete README files for all three integrations with commands, examples, and configuration guides

Changes

• Added Integrations/FeedSOCRadarThreatFeed/ (new)
• Added Integrations/SOCRadarRapidReputation/ (new)
• Added Integrations/SOCRadarIoCEnrichment/ (new)
• Updated pack_metadata.json to version 2.2.2
• Updated main README.md with all three integrations
• Added ReleaseNotes/2_2_2.md

Testing

All integrations have been tested with valid SOCRadar API keys:

• API connectivity verified
• All commands tested and working
• DBot score integration validated
• Error handling confirmed
• Rate limiting verified (Rapid Reputation)
• Feed ingestion tested (Threat Feed)

relates: https://jira-dc.paloaltonetworks.com/browse/CIAC-16413

[content-bot]

Thank you for your contribution. Your generosity and caring are unrivaled! Make sure to register your contribution by filling the Contribution Registration form, so our content wizard @kamalq97 will know the proposed changes are ready to be reviewed.
For your convenience, here is a link to the contributions SLAs document.

[content-bot]

Hi @Radargoger, thanks for contributing to the XSOAR marketplace. To receive credit for your generous contribution please follow this link.

[content-bot]

🤖 AI-Powered Code Review Available

Hi @kamalq97, @MosheEichler, you can leverage AI-powered code review to assist with this PR!

Available Commands:

• @marketplace-ai-reviewer start review - Initiate a full AI code review
• @marketplace-ai-reviewer re-review - Incremental review for new commits

[Radargoger]

Hi @MosheEichler ,

Thank you for the review and the feedback!

I have addressed all the review comments and made the necessary changes.

Just a quick heads-up regarding the time.sleep() function in the code: I added it specifically to prevent hitting the API rate limits (rapid reputation API). I know this sometimes gets flagged in code reviews or automated checks, so I wanted to clarify its purpose beforehand.

Please let me know if there is anything else needed.

Thanks again!
Burak

[Radargoger]

Hi @MosheEichler ,
I wanted to give you a quick update on the AI Reviewer's comments.
All other review items have been fully addressed — including ContentClient migration attempts, DBotScore outputs, description files, unit tests, pack metadata, assert removal, demisto.params() placement, raise_for_status error handling, and the rest. The PR is otherwise ready.
We'd just like to align on the following 3 points before we consider it complete:

1. BaseClient → ContentClient
   We attempted to migrate all 3 integrations (FeedSOCRadarThreatFeed, SOCRadarIoCEnrichment, SOCRadarRapidReputation) from BaseClient to ContentClient, but this change caused pre-commit hook failures in the CI. We'd appreciate your guidance on the correct migration path — happy to fix it with your direction.
2. time.sleep(1) in SOCRadarRapidReputation.py
   The Rapid Reputation API enforces a hard rate limit of 1 request per second. The time.sleep(1) is intentionally placed in the bulk check flow (socradar-bulk-reputation command), which processes multiple indicators in a single call. Without the delay, consecutive API requests within the same batch would hit the rate limit and result in 429 errors. This is a necessary safeguard for the bulk query feature — if there's a preferred XSOAR pattern for rate limiting (e.g., retry with backoff), we're open to adopting it.
3. API Key type: 4 vs type: 9
   The AI Reviewer suggested switching to type: 9 with displaypassword. However, type: 9 renders a "Password" label in the UI, which would be misleading — users are entering an API key, not a password. We kept type: 4 intentionally for clarity. If type: 9 is a must requirement, we can explore adding a custom display label to keep it accurate.
   If these 3 points are acceptable as-is, we're ready to move forward. Otherwise, just let us know and we'll adjust accordingly.
   Thanks!
   Burak

[MosheEichler]

Hi @Radargoger, thanks for the detailed status — replying inline on the 3 open items so we can move forward:

1. BaseClient → ContentClient migration

Since the migration broke pre-commit and the current code passes, let's leave BaseClient as-is in this PR. Please open a separate follow-up PR for the ContentClient migration so we don't block the v2.3.0 release on it.

2. time.sleep(1) in SOCRadarRapidReputation.py (bulk reputation)

Please remove time.sleep() and use the platform's built-in HTTP retry mechanism instead — it handles rate limiting (429) cleanly via Retry-After / exponential backoff:

📖 https://xsoar.pan.dev/docs/integrations/code-conventions#http-call-retries

In short, pass these to BaseClient._http_request (or set them on the client):

self._http_request(
    method="POST",
    url_suffix="/...",
    json_data=payload,
    retries=3,
    status_list_to_retry=[429],
    backoff_factor=1,   # 1s, 2s, 4s ...
)

This replaces the hard-coded 1-second sleep with proper, server-driven backoff and is the XSOAR-preferred pattern.

3. API Key — type: 4 vs type: 9

Please switch to type: 9 with displaypassword — that gives you the security of an encrypted credential and lets you keep the user-facing label as "API Key" (no misleading "Password" label). You can also add hiddenusername: true to hide the unused username field.

Reference example from the AHA pack:
https://github.com/demisto/content/blob/master/Packs/AHA/Integrations/AHA/AHA.yml#L19-L25

- name: apikey
  displaypassword: API Key
  required: true
  type: 9
  hiddenusername: true
  additionalinfo: "API Key to access the SOCRadar service."

Apply this pattern to all 3 integrations (FeedSOCRadarThreatFeed, SOCRadarIoCEnrichment, SOCRadarRapidReputation).

---

Once # 2 and # 3 are addressed (and # 1 is deferred to a follow-up PR), we should be good to move forward. Thanks!

[Radargoger]

Hi @MosheEichler, thanks for the detailed review!

1. BaseClient → ContentClient migration
Acknowledged — leaving BaseClient as-is in this PR. Will open a separate follow-up PR for the ContentClient migration to avoid blocking v2.3.0.

2. time.sleep(1) → HTTP retry mechanism
Done. Removed import time and the time.sleep(1) block from socradar_bulk_check_command. Added retry parameters directly to _http_request in the get_entity_reputation method so all calls (including bulk check) benefit from server-driven backoff:

retries=3,
status_list_to_retry=[429],
backoff_factor=1,

3. API Key — type: 4 → type: 9
Done for all three integrations (FeedSOCRadarThreatFeed, SOCRadarIoCEnrichment, SOCRadarRapidReputation). Applied the pattern from the AHA pack:

- name: apikey
  displaypassword: API Key
  required: true
  type: 9
  hiddenusername: true
  additionalinfo: API Key to access the SOCRadar service.

Also updated the corresponding Python files to read the credential correctly via params.get("apikey", {}).get("password") as required by the type 9 credentials object.

All changes are in the latest commit 7f1cfbda3c. Let me know if anything needs adjustment!

[MosheEichler]

Hi @Radargoger, the code looks good!

We're ready for a demo. Please check this page, and let me know when you're available for one over DFIR.
Feel free also to send me a recording of a demo.

[Radargoger]

Hi @MosheEichler, attaching a full demo recording of the v2.2.2 / v2.3.0 pack for your review.

What the GIF covers (end-to-end)

1. Instance configuration — all three integrations Test passing

• SOCRadar Rapid Reputation → Success
• SOCRadar IoC Enrichment → Success
• SOCRadar Threat Feed → Success

API Key uses type: 9 (encrypted credential, masked in UI), and the "Switch to credentials" link is visible on each instance for credential reuse.

2. SOCRadar Rapid Reputation commands (Playground / War Room)

• !ip ip="45.142.212.100" → FindingSources from Kaspersky / Abuse.ch ThreatFox / USOM / Cisco-Talos / AlienVault OTX / Threatview.io, Score 31.9, IsWhitelisted=false
• !ip ip="1.1.1.1" → IsWhitelisted=true, empty FindingSources (whitelist behavior verified)
• !domain, !url, !file → all return populated tables
• ⭐ !socradar-bulk-check (new) — mixed indicator list in a single call (45.142.212.100,malware-domain.ru,http://45.142.212.100/payload.exe,1.1.1.1), automatic per-indicator type detection, per-indicator result tables, and ScoreRange flagging "Whitelisted" correctly for 1.1.1.1

3. SOCRadar IoC Enrichment

• !socradar-ioc-enrichment indicator="45.142.212.100" → ASN/ASNCode, Activity timeline (Last1Day / Last7Days / Last30Days), CIDR, Categorization flags (CDN / Cloud / Cryptocurrency), Classifications (Country: Moldova), FirstSeen 2021-07-14, Score 54.49, related indicators from SOCRadar Threat Exchange Services

4. SOCRadar Threat Feed

• !socradar-get-indicators collection_uuids="..." limit=10 → 10 IOCs from Cyber Threat Alliance and Internal Malware Information and Threat Sharing Platform feeds, Domain type, with FeedMaintainerName / FirstSeenDate / LastSeenDate / Score columns
• The instance also fetched 7,224 indicators successfully (visible in the instance status row)

5. Error handling / validation

• !file file="notahash" → both Rapid Reputation and IoC Enrichment return Hash "notahash" is not a valid hash (graceful, no traceback)
• !ip ip="not-an-ip" and !domain domain="not a domain!!" produce equivalent validation messages

Notes

• The SOCRadarThreatFusion returned an error entries visible in the recording are from the legacy Partner Contribution integration, not part of this PR.
• Recording is 1393×868, 50 frames covering the full flow.

Let me know if you'd like a focused recording for any specific edge case or flow.

[github-actions]

Thank you for your contribution. Your external PR has been merged and the changes are now included in an internal PR for further review. The internal PR will be merged to the master branch within 3 business days.