[TT-15942]: Integrate Sentinel One CNS scanner workflow.

[asutosh]

Description

This adds a github action workflow that will scan the code base for vulnerabilities, secrets, misconfigurations etc. on every pull request.
These can be manged based on centrally set up rules on the S1 console.

Related Issue

TT-15942

Motivation and Context

This is to integrate S1 with our repositories so that everything can be managed centrally in the S1 console.

How This Has Been Tested

This is not very testable, as it requires the workflow to be added and then run to actually see how it behaves.
But some scans have been done independently locally for testing.

Screenshots (if appropriate)

NA

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• I ensured that the documentation is up to date
• I explained why this PR updates go.mod in detail with reasoning why it's required
• I would like a code coverage CI quality gate exception and have explained why

[probelabs]

🔍 Code Analysis Results

Change Impact Analysis

1. What this PR accomplishes

This pull request integrates the SentinelOne Cloud Native Security (CNS) scanner into the project's CI/CD pipeline. It introduces a new GitHub Actions workflow that automatically scans the codebase for secrets, Infrastructure as Code (IaC) misconfigurations, and vulnerabilities on every pull request targeting the master branch. This change enhances the project's security posture by embedding automated security checks early in the development lifecycle.

2. Key technical changes introduced

• New GitHub Actions Workflow: A new workflow file is added at .github/workflows/s1-cns-scans.yml.
• Trigger Conditions: The workflow is configured to run on pull_request events (opened, reopened, synchronize) for the master branch.
• Containerized Scanning Environment: The job runs within a pingsafe/s1-shift-left-cli:0.5.3 Docker container, ensuring a consistent and isolated environment for the security scans.
• Multi-faceted Security Scanning: The workflow executes three distinct security scans using the SentinelOne CLI:
  1. Secret Detection: Scans the pull request changes for any exposed credentials or secrets.
  2. IaC Scanning: Analyzes Infrastructure as Code files for potential misconfigurations.
  3. Vulnerability Scanning: Checks the codebase for known software vulnerabilities.
• Security Gate Implementation: The workflow acts as a security gate. Individual scan steps are set to continue-on-error: true to ensure all scans complete. A final step then checks the outcome of all three scans; if any have failed, the entire workflow fails, thus preventing the merge of insecure code.
• Secure Configuration: The workflow leverages GitHub secrets (e.g., S1_API_TOKEN, S1_CONSOLE_URL) to securely authenticate with the SentinelOne management console.

3. Affected system components

• CI/CD Pipeline: This PR adds a new, mandatory security check to the pull request validation process. This will slightly increase the overall time required for CI checks to complete.
• Development Workflow: Developers will receive immediate feedback on security issues within their pull requests. They will be required to remediate any findings before their contributions can be merged into the master branch.
• No Runtime Impact: The changes are confined to the CI/CD process and have no direct impact on the application's runtime behavior, performance, or architecture.

---

Architecture Visualization

The following sequence diagram illustrates the process flow of the new SentinelOne CNS Scan workflow, from the initial pull request event to the final pass/fail status report.

sequenceDiagram
    participant Dev as Developer
    participant GitHub
    participant S1_Workflow as "SentinelOne Scan Workflow"
    participant S1_CLI as "s1-cns-cli"
    participant S1_Console as "SentinelOne Console"

    Dev->>GitHub: Opens/Updates Pull Request to master
    GitHub->>S1_Workflow: Triggers workflow on PR event

    activate S1_Workflow
    S1_Workflow->>S1_Workflow: 1. Checkout code (full history)
    S1_Workflow->>S1_CLI: 2. Configure CLI with S1 secrets
    
    S1_Workflow->>S1_CLI: 3. Run Secret Scan on PR diff
    activate S1_CLI
    S1_CLI-->>S1_Console: Publish Secret Scan Results
    S1_CLI-->>S1_Workflow: Scan complete
    deactivate S1_CLI

    S1_Workflow->>S1_CLI: 4. Run IaC Scan on repo
    activate S1_CLI
    S1_CLI-->>S1_Console: Publish IaC Scan Results
    S1_CLI-->>S1_Workflow: Scan complete
    deactivate S1_CLI

    S1_Workflow->>S1_CLI: 5. Run Vulnerability Scan on repo
    activate S1_CLI
    S1_CLI-->>S1_Workflow: Scan complete
    deactivate S1_CLI

    S1_Workflow->>S1_Workflow: 6. Aggregate and check scan outcomes
    alt Any scan failed
        S1_Workflow->>GitHub: Report Failure (Workflow fails)
    else All scans passed
        S1_Workflow->>GitHub: Report Success (Workflow succeeds)
    end
    deactivate S1_Workflow

Loading

---

Powered by Visor from Probelabs

Last updated: 2025-10-08T10:26:14.787Z | Triggered by: synchronize | Commit: fe143e2

[probelabs]

🔍 Code Analysis Results

Security Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/s1-cns-scans.yml:12	The workflow uses a mutable Docker image tag (`pingsafe/s1-shift-left-cli:0.5.3`). This creates a supply-chain risk, as the tag can be overwritten with a different or malicious image. Using an immutable digest (SHA hash) ensures that the exact same image is used in every workflow run, preventing unexpected changes or potential compromises. 💡 Suggestion Pin the container image to its immutable SHA256 digest instead of a tag. You can retrieve the digest from your container registry or by using a tool like Docker CLI (`docker inspect pingsafe/s1-shift-left-cli:0.5.3`). Example: container: image: pingsafe/s1-shift-left-cli@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/s1-cns-scans.yml:25	The workflow is configured with `fetch-depth: 0`, which instructs the checkout action to clone the entire Git history. For repositories with a large number of commits, this can significantly increase the time and network bandwidth required for the checkout step, slowing down the overall CI pipeline. While this is often a requirement for security tools that scan commit history for secrets, it represents a direct trade-off between scan thoroughness and CI performance. 💡 Suggestion Confirm whether the SentinelOne scanner requires the full git history for its analysis. If a shallow clone is sufficient (e.g., if it only scans the current state of the code), consider changing `fetch-depth` to a small number like `1` to dramatically improve checkout speed. If the full history is indeed required, this is an acceptable performance trade-off, but the impact on CI execution time should be monitored.

Quality Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/s1-cns-scans.yml:56	The final `Check for failures` step uses a single `if` condition and a generic `exit 1`. If the workflow fails, it does not provide any context in the summary about which of the three scans (secret, IaC, or vulnerability) was the cause. This forces developers to manually search through the logs of each preceding step to identify the root cause, which is inefficient and hinders rapid debugging. 💡 Suggestion To improve debuggability, modify the final step to provide a clear error message indicating exactly which scan(s) failed. This can be achieved by using a script that checks each step's outcome individually and prints a descriptive error message for each failure. Example: - name: Check for failures if: failure() run: | if [ ${{ steps.secret-detector.outcome }} == 'failure' ]; then echo "::error::SentinelOne Secret Detector scan failed." fi if [ ${{ steps.iac-scanner.outcome }} == 'failure' ]; then echo "::error::SentinelOne IaC Scanner scan failed." fi if [ ${{ steps.vuln-scanner.outcome }} == 'failure' ]; then echo "::error::SentinelOne Vulnerability Scanner scan failed." fi exit 1

Style Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/s1-cns-scans.yml:25	The workflow uses `fetch-depth: 0`, which clones the entire Git history for the repository. While this is often required for thorough secret scanning that includes historical commits, it can significantly increase the CI job's execution time, especially for repositories with a long and active history. This step could become a performance bottleneck, delaying feedback to developers. 💡 Suggestion Confirm whether the SentinelOne scanner requires the full git history for all its scan types. If a shallow clone is sufficient for the IaC and vulnerability scans, consider splitting the job or finding a way to perform a shallow clone initially and only deepen it if required. If the full history is non-negotiable, this is an acceptable trade-off, but the impact on CI execution time should be monitored as the repository grows.

✅ Dependency Check Passed

No dependency issues found – changes LGTM.

✅ Connectivity Check Passed

No connectivity issues found – changes LGTM.

---

Powered by Visor from Probelabs

Last updated: 2025-10-08T10:26:15.764Z | Triggered by: synchronize | Commit: fe143e2