[TT-17509]: Update s1 cns cli to the latest 1.0.4 version.

[asutosh]

Jira Ticket

TT-17509

Description

• Updates the sentinel one docker image hash to use the latest version.
• The latest version has some breaking changes, and this fixes it too, by switching from scan tags to policy id for scans.
• S1 has now also added the capability to publish vulnerability scan results to S1 console, and this is enabled as well.
• Do not fail on finding vulnerabilities. Earlier behaviour was to fail the workflow if vulnerabilities were found, based on the upstream policy on S1. Now we do not fail by default, as failing the workflow doesn't achieve anything, apart from having an undesired red on the workflow status.

Type of Change

• Version bump

Changes Made

Testing

• Manually triggered the affected workflow(s) and verified expected behaviour
  https://github.com/TykTechnologies/tyk-analytics/actions/runs/31079849361
• Checked that existing workflows are not broken

[probelabs]

This PR updates the s1-cns-scan.yml reusable workflow to use the latest version (v1.0.4) of the pingsafe/s1-shift-left-cli Docker image, upgrading from v0.5.4. This update introduces significant, breaking changes to the workflow's inputs and error handling logic.

Key changes include replacing the tag input with a new, mandatory policy_id input for configuring the scan policy. A new boolean input, vuln_fail, has been added to control whether the workflow fails upon detecting vulnerabilities, defaulting to false.

The execution logic is now more robust: individual scan steps (secret, IaC, vulnerability) are configured with continue-on-error: true to ensure all scans complete. A final step aggregates the outcomes to determine the overall success or failure of the job, failing only if secret/IaC scans fail, or if the vulnerability scan fails and vuln_fail is set to true.

Files Changed Analysis

• File: .github/workflows/s1-cns-scan.yml
• Changes: 25 additions, 9 deletions.
• Summary: All modifications are confined to the SentinelOne reusable workflow. The changes align the workflow's inputs, CLI arguments, and error handling with the breaking changes introduced in version 1.0.4 of the s1-cns-cli tool.

Architecture & Impact Assessment

• What this PR accomplishes: It upgrades the SentinelOne security scanning tool to the latest version, introduces more granular control over failure conditions, and enhances reporting by enabling the publishing of results directly to the SentinelOne console.
• Key technical changes introduced:
  • Breaking Change: The tag input is removed and replaced with a new, mandatory policy_id input.
  • The pingsafe/s1-shift-left-cli Docker image is updated to a new SHA256 digest corresponding to v1.0.4.
  • A new vuln_fail input is added to make vulnerability-related failures optional.
  • Error handling is refactored to use continue-on-error for each scan, with a final step to conditionally fail the workflow based on the results.
• Affected system components: This change directly affects the s1-cns-scan.yml reusable workflow. Any CI pipeline in other repositories that calls this workflow will fail until it is updated to pass the new policy_id input instead of tag.

Scope Discovery & Context Expansion

• The immediate scope is limited to the s1-cns-scan.yml file.
• The broader impact is significant, affecting all other repositories and CI/CD pipelines that utilize this reusable workflow. The mandatory switch from tag to policy_id will cause build failures for all downstream consumers. It is critical to identify all consumers of this workflow (e.g., by searching for uses: TykTechnologies/github-actions/.github/workflows/s1-cns-scan.yml) and coordinate the update across all dependent projects to prevent disruption.

Metadata

• Review Effort: 2 / 5
• Primary Label: chore

---

Powered by Visor from Probelabs

Last updated: 2026-08-06T07:47:45.648Z | Triggered by: pr_updated | Commit: 46ca7f5

💡 TIP: You can chat with Visor using /visor ask <your question>

[probelabs]

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/s1-cns-scan.yml:103-104	The failure condition logic is inconsistent across different scan types. The workflow is hardcoded to fail if secret or IaC scans have a 'failure' outcome, but failure for vulnerability scans is configurable via the `vuln_fail` input. This creates an inconsistent interface for the reusable workflow and limits its flexibility for consumers who may want to control the failure policy for all scan types. 💡 Suggestion To create a more consistent and flexible design, introduce `secrets_fail` and `iac_fail` boolean inputs, similar to `vuln_fail`. This would allow consumers of the workflow to configure the failure policy for each scan type independently. The default values could preserve the current behavior (e.g., `secrets_fail: true`, `iac_fail: true`). The if condition would then be updated to: if: (steps.secret-detector.outcome == 'failure' && inputs.secrets_fail) || (steps.iac-scanner.outcome == 'failure' && inputs.iac_fail) || (steps.vuln-scanner.outcome == 'failure' && inputs.vuln_fail)

✅ Performance Check Passed

No performance issues found – changes LGTM.

\n\n

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/s1-cns-scan.yml:103-104	The failure condition logic is inconsistent across different scan types. The workflow is hardcoded to fail if secret or IaC scans have a 'failure' outcome, but failure for vulnerability scans is configurable via the `vuln_fail` input. This creates an inconsistent interface for the reusable workflow and limits its flexibility for consumers who may want to control the failure policy for all scan types. 💡 Suggestion To create a more consistent and flexible design, introduce `secrets_fail` and `iac_fail` boolean inputs, similar to `vuln_fail`. This would allow consumers of the workflow to configure the failure policy for each scan type independently. The default values could preserve the current behavior (e.g., `secrets_fail: true`, `iac_fail: true`). The if condition would then be updated to: if: (steps.secret-detector.outcome == 'failure' && inputs.secrets_fail) || (steps.iac-scanner.outcome == 'failure' && inputs.iac_fail) || (steps.vuln-scanner.outcome == 'failure' && inputs.vuln_fail)

\n\n ### ✅ Performance Check Passed

No performance issues found – changes LGTM.

\n\n

✅ Quality Check Passed

No quality issues found – changes LGTM.

---

Powered by Visor from Probelabs

Last updated: 2026-08-06T07:47:17.982Z | Triggered by: pr_updated | Commit: 46ca7f5

💡 TIP: You can chat with Visor using /visor ask <your question>