[mvforgione]

Features

• Convert the app from the classic BaseConnector format to the Splunk SOAR SDK (splunk-soar-sdk 3.25.3). The existing appid is preserved, so version 1.3.0 installs as an upgrade over the classic 1.2.1 app. Requires Splunk SOAR 7.0 or later.
• All 13 classic actions are reimplemented with behavior preserved: test connectivity, lookup domain, lookup email, lookup hash, lookup string, lookup ip, lookup ipv6, lookup url, lookup mutex, lookup http request, upload evidence file, check evidence status, get evidence.
• 8 new actions for parity with the Analyst1 Cortex XSOAR integration: batch check, get indicator by id, get actor by id, get malware by id, get sensors, get sensor taskings, get sensor config, get sensor diff.
• Custom result views for every action: table views for list results (batch check, evidence, sensors, taskings, diff) and detail views for single entities (indicators, actors, malware, sensor config, evidence upload and status). Entity IDs link back to the configured Analyst1 server (indicators, actors, malware, sensors, evidence files).
• Unit test suite (145 tests) covering actions, output models, view rendering, HTML escaping, and the manifest.

Manual Documentation

• I have verified that manual documentation has been updated where appropriate

manual_readme_content.md documents both authentication methods (basic auth for the 1_0 API and OAuth2 client credentials for the 1_1 API).

Other information

• Local action runs are supported via the SDK CLI (python src/app.py ...), and the package builds with soarapps package build.
• Release notes for this version are in release_notes/unreleased.md.
• The app id static checks (app_package_name and valid_app_name_and_guid) depend on the registry mappings in Add Analyst1 app id to registry mappings phantomcyber/dev-cicd-tools#233, which registers this app id. Those two checks will fail on this PR until that one is merged.

[github-actions]

Thank you for your submission! We will take a look as soon as we can.

[mvforgione]

Following up now that phantomcyber/dev-cicd-tools#233 has merged: pre-commit is passing. Two notes on the remaining check failures, which both appear to be on the CI side rather than in the app:

• compile: the app builds successfully, but the job could not reach the internal test instance 10.1.64.115 (connection refused on all attempts). The previous run on July 10 installed this same code successfully on all three test instances, including that one.
• semantic-release-preview: the dry run attempts a push to the PR head repository, which is our fork, so the GitHub Actions token is denied. It looks like this new check may not currently be able to run on fork PRs.

Happy to retrigger or adjust anything on our side if needed.

[athreya-splunk]

Hi @mvforgione - I had a quick look at the Pr and I would like to highlight following issues that we might want to resolve before we can merge the PR. Here's the generated summary -

1. Validate path parameters before building URLs

     User input is inserted directly into API paths:
      - src/app.py:381 uses clean_id in /indicator/{clean_id}
      - src/app.py:489 uses uuid in /evidence/uploadStatus/{uuid}

     Please validate these values or URL-encode them with quote(value, safe="") before using them in the path. 

  2. Reject blank lookup values before calling the API

     Several lookup params default to empty strings:
      - src/app.py:1060-1134
      - Used by _do_indicator_lookup at src/app.py:1177

     Please strip and reject blank values locally with ActionFailure before making the Analyst1 API request.

  3. Add OAuth 401 retry for sensor config

     get_sensor_config_text makes a direct request for raw text:
      - src/app.py:423-436

     But it does not retry on OAuth 401 like get_evidence_upload_status does:
      - src/app.py:502-506

     Please add the same clear-token, refresh-token, retry-once behavior here.
     

[mvforgione]

Thanks for the review @athreya-splunk. All three items are addressed in 46b5d93:

1. Path parameters: the indicator id and evidence uuid are now URL-encoded with quote(value, safe="") before being inserted into the request path.
2. Blank lookups: lookup values are stripped, and blank input now fails locally with ActionFailure before any API call. This also matches the classic app, which marked these parameters as required.
3. Sensor config auth: get_sensor_config_text now has the same clear-token, refresh, and retry-once behavior on 401 as the evidence upload status call.

Each fix has test coverage (encoded-path assertions, blank rejection with no outbound request, and single-retry behavior on 401). Happy to adjust anything further.

One note on the CI run for this push: every job now fails at the checkout step with "Refusing to check out fork pull request code from a 'pull_request_target' workflow", which looks like a recent actions/checkout default change affecting fork PRs org-wide rather than anything in this branch. The previous run on July 20 checked out and ran normally.

[athreya-splunk]

@mvforgione thanks for fixing. Could you also please take a look at this PR and add them to this sdkfied code?
#4
It contains minor patches based on internal VULN tickets.
Everything else looks good to me otherwise.

[mvforgione]

Thanks @athreya-splunk. Both security items from #4 are covered on this branch:

1. Certificate verification defaults to enabled as of 500e53f (pushed yesterday), with the same guidance in the release notes: existing assets must trust the API server certificate chain or explicitly disable verification.
2. The credential fields (client secret and password) are already password fields in the SDK asset configuration, as they were in the published 1.2.1 app, so no rotation or re-entry is needed on upgrade.

The LICENSE, NOTICE, and dependency metadata changes in #4 are specific to the classic format; the SDK build generates those artifacts.

One sequencing note: #4 and this PR modify the same files, so whichever merges second will need a rebase. If it is simplest, this PR can carry the security changes and #4 can be closed, but happy to rebase either way.

[splunk-soar-semantic-release]

🎉 This PR is included in version 1.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[athreya-splunk]

I will create an internal request to release this app in splunkbase. I'll update here once it's released.

[mvforgione]

@athreya-splunk one flag before the Splunkbase release request goes out: this release was tagged 1.0.0, but Splunkbase already has Analyst1 at 1.2.1 under this app id, released before the app moved to GitHub. A 1.0.0 release would register as a downgrade and break the upgrade path for existing installs. The PR set the version to 1.3.0 for that reason; semantic-release recomputed it to 1.0.0 because the repo has no baseline tag from the pre-GitHub releases.

Could the release go out as 1.3.0? One option is to baseline the repo with a 1.2.1 tag on the pre-merge history and re-run the release so the commits compute to 1.3.0. Happy to help however is useful.

[athreya-splunk]

@athreya-splunk one flag before the Splunkbase release request goes out: this release was tagged 1.0.0, but Splunkbase already has Analyst1 at 1.2.1 under this app id, released before the app moved to GitHub. A 1.0.0 release would register as a downgrade and break the upgrade path for existing installs. The PR set the version to 1.3.0 for that reason; semantic-release recomputed it to 1.0.0 because the repo has no baseline tag from the pre-GitHub releases.

Could the release go out as 1.3.0? One option is to baseline the repo with a 1.2.1 tag on the pre-merge history and re-run the release so the commits compute to 1.3.0. Happy to help however is useful.

@mvforgione - I thought this was the first release of the app. Missed the description. I didn't see any past releases of this app. Could you please share splunkbase link so that I can take a look? I only see a splunk app https://splunkbase.splunk.com/app/6816 and not SOAR integration app.

[mvforgione]

You are right, and I should correct my earlier comment. This connector was never published on Splunkbase, so there is no link to share. App 6816 is a different product, our add-on for Splunk Enterprise (TA-Analyst1). Analyst1 distributed the SOAR connector directly to customers, and 1.2.1 is the version they are running today.

The 1.3.0 request is about those existing installs rather than a Splunkbase listing. Customer SOAR instances have the classic app installed under this same app id, which we kept so the SDK app upgrades those installs in place. Publishing as 1.0.0 would appear as a downgrade to them. The generated release notes for this release also state that version 1.3.0 replaces the classic Analyst1 app (v1.2.1), so the 1.0.0 tag does not match its own notes.

Would it be possible to release as 1.3.0? One approach is to tag the pre-merge commit as 1.2.1 so semantic-release computes 1.3.0 from the merged commits. Happy to help however is useful.

[athreya-splunk]

I’ll need to check internally whether we can publish the app as v1.3.0.
Given that Splunkbase already has an Analyst1 app, I don’t think we’ll be able to publish another app with the exact same name. We may need to rename this listing to something like “Analyst1 for Splunk SOAR” and release it as a new Splunkbase app. Would that work for you if the release version is v1.0.0 for the new app with the new name?
Since you mentioned that customers already have a directly distributed connector installed with this same app ID, we would also need to update the app UUID along with the app name. The customers can then move to this new app and slowly move away from the custom app that was shared earlier.

[mvforgione]

Thanks, the rename works for us. "Analyst1 for Splunk SOAR" would follow the convention other connectors use when the vendor already has a Splunk Enterprise app, for example GreyNoise for SOAR, TrackMe for Splunk SOAR, Dataminr Pulse for Splunk SOAR, and Censys for Splunk SOAR. Happy to use that, or a different name if you prefer one.

On the app UUID, could you confirm the upgrade behavior for us? Our understanding is that if the UUID stays the same, a customer running the classic app gets an in-place upgrade with their assets and playbooks intact, and that if the UUID changes they get a parallel install instead, leaving the old app on the instance and requiring assets to be recreated with their credentials and playbooks repointed. If that is right, keeping the UUID would spare existing customers that migration, and a rename alone should be enough to resolve the listing name.

For what it is worth, Recorded Future appears to have taken that route: the connector was renamed from "Recorded Future" to "Recorded Future For Splunk SOAR" in 4.1.0 and kept appid 6efe0e1b-76ac-4ffd-8fa0-ac58fd6efd77 from its earlier versions.

The version request follows from the same answer. If the UUID stays, the published version would need to be above 1.2.1 so existing installs see an upgrade. If the UUID has to change, then 1.0.0 is correct and I will drop the request.

How would you like the rename delivered? I can open a follow-up PR against main is that is easiest.

[athreya-splunk]

@mvforgione -

I think there are two separate questions here.

Keeping the same UUID while renaming the app is one decision, and Recorded Future is a useful precedent for that. It was renamed to a SOAR-specific app name while retaining the same app UUID.

The version request is different. Our connector release flow is automated through semantic-release: the workflow computes the next version from the repository’s release/tag history and then updates the app metadata during publish. Since the earlier Analyst1 builds were distributed outside this GitHub/Splunkbase release flow, I’d prefer not to manually add release artifacts, tags, or metadata only to make the first public release come out as 1.0.3.

Given that this is a conversion to the SOAR SDK,if we keep the same UUID and treat this as the next version of the existing customer-distributed connector, then this should be a major version release, e.g. 2.0.0.

My preference is to treat this as a clean new Splunkbase SOAR app: update the app UUID and app name in phantomcyber/dev-cicd-tools, splunk-soar-connectors/.github, and this repo, then let the automated release flow publish the first public version from that new app lineage. Existing customers would need to create a new asset and repoint playbooks, but I think that is cleaner long term and avoids mixing private distribution history with the public Splunkbase release history.

[mvforgione]

Thanks for laying out both options. Would it be possible to keep the same UUID and release as 2.0.0, the version you indicated for that path?

Our concern with the new UUID is the existing installs. Every customer running the current connector would have to install the new app alongside the old one, recreate each asset and re-enter its credentials, and repoint each Analyst1 action block in their visual playbooks. Keeping the UUID would make it an ordinary upgrade, with assets and playbooks left in place.

On the release-history point, this would not require backfilling anything from the private distribution. No tags, artifacts, or metadata behind the existing 1.0.0 tag. The follow-up PR would just need to carry a breaking change commit so the flow computes 2.0.0 from that tag, which seems reasonable given the SDK conversion and the move to a 7.0 minimum.

Happy to open the follow-up PR against main with the rename whenever you decide. I think the appid_to_name entry in dev-cicd-tools would need the new name as well, since the app name check compares against it, and I can open that PR too if it helps.

[athreya-splunk]

Hey @mvforgione - could you please create a PR renaming the app to Analyst1 for Splunk SOAR? We need 2 PRs, phantomcyber/dev-cicd-tools, splunk-soar-connectors/.github

I've created a PR to bump version to 2.0.0 #5. I'll merge once we rename the app.

[mvforgione]

Both registry PRs are open, and the rename is #6.

phantomcyber/dev-cicd-tools#256 renames the entry, and splunk-soar-connectors/.github#620 adds it. That file was missing this app id, so it is an addition there rather than an edit. appid_to_package_name.json needs no change, since the package name comes from the pyproject project name and stays phantom_analyst1.

#6 will show a red static-tests until #256 merges, because check_valid_app_name_and_guid reads the registry from dev-cicd-tools main at run time. A re-run after #256 merges should go green without a rebase or a new commit.

One question on sequencing. Should the rename commit carry the breaking change marker so it publishes 2.0.0 on merge, or stay non-releasing so #5 does the bump? I ask because the build and enqueue-publish jobs do not look gated on semantic-release producing a new version, and I was not sure whether a non-releasing merge would re-enqueue 1.0.0. It is a chore: commit right now and I can amend it either way.

#6 also touches release_notes/unreleased.md, since the release notes hook requires content there, so it will conflict with #5. Glad to drop my line and keep yours.

[athreya-splunk]

@mvforgione - https://splunkbase.splunk.com/app/9495 app released to splunkbase with the available versions starting from 2.0.0