Image scanning requires infrastructure-as-code:read scope despite not using IaC features

[DLTKYugalGarg]

Issue Description

The fcs-action@v2.0.2 fails with a 403 authorization error during FCS CLI download when using scan_type: image for container scanning. The error occurs because the Downloads API requires the infrastructure-as-code:read OAuth scope, even though the workflow only performs container image scanning and does not use any IaC features.

Environment

• Action Version: CrowdStrike/fcs-action@v2.0.2
• Runner: GitHub-hosted ubuntu-latest
• Scan Type: image (container scanning only)
• Python Version: 3.12.11
• FalconPy Version: 1.5.4
• Region: us-1

Error Output

============================================================
CrowdStrike FCS download with falconpy
============================================================
Configuration:
   Region: us-1
   Version: latest
ERROR: Error enumerating files: {
  'status_code': 403,
  'headers': {
    'Server': 'nginx',
    'X-Ratelimit-Limit': '6000',
    'X-Ratelimit-Remaining': '5886'
  },
  'body': {
    'errors': [
      {'code': 403, 'message': 'access denied, authorization failed'}
    ]
  }
}

FCS download failed!
Error: Process completed with exit code 1.

Root Cause Analysis

The error occurs in the fcs_download.py script when calling:

response = self.downloads.enumerate(platform=platform, category="fcs")

According to FalconPy documentation, the Downloads API enumerate operation requires the infrastructure-as-code:read OAuth scope.

However, our use case only requires container image scanning (scan_type: image), not Infrastructure as Code scanning. Our CrowdStrike account has container security features enabled but does not have IaC features/licensing, so the infrastructure-as-code scope is not available in the Falcon Console.

Current API Client Configuration

Scopes Configured (all confirmed present in Falcon Console):

• ✅ Falcon Container CLI: READ & WRITE
• ✅ Falcon Container Image: READ & WRITE
• ✅ Falcon Images Download: READ

Missing Scope (not available/visible in our Falcon Console):

• ❌ Infrastructure as Code: READ (required by Downloads API but unavailable)

Expected Behavior

When using scan_type: image, the action should:

1. Download/access the FCS CLI tool using scopes relevant to container operations
2. Perform container image vulnerability scanning
3. Generate scan reports

The action should NOT require IaC-related scopes when only performing container image scanning.

Actual Behavior

The action attempts to download the FCS CLI using the Downloads API, which requires infrastructure-as-code:read scope regardless of the scan_type parameter. This blocks users who:

• Only have container security features enabled
• Don't have IaC licensing/features on their CrowdStrike account
• Cannot access or enable the IaC scope in Falcon Console

Workflow Configuration

- name: CrowdStrike Container Security Scan
  uses: CrowdStrike/fcs-action@v2.0.2
  with:
    falcon_client_id: ${{ vars.FALCON_CLIENT_ID }}
    falcon_region: us-1
    scan_type: image                    # Container scanning only
    image: <registry>/<image>:<tag>
    output_path: ./scan-results.json
    report_formats: json
    fail_on: "critical=1,high=1"
  env:
    FALCON_CLIENT_SECRET: ${{ secrets.FALCON_CLIENT_SECRET }}

Suggested Solutions

Option 1: Separate Download Mechanisms (Preferred)

Implement different CLI download strategies based on scan_type:

• For scan_type: iac: Use current Downloads API (requires infrastructure-as-code:read)
• For scan_type: image: Use container-based binary extraction or alternative download method that only requires container-related scopes

This would align with PR #21 which moved away from API downloads to container extraction to avoid permission issues.

Option 2: Update Documentation

If the IaC scope is genuinely required for all scan types, update the README to clearly document:

## Required API Scopes

For **all scan types** (both IaC and image scanning):
- Infrastructure as Code: READ & WRITE
- Falcon Container CLI: READ & WRITE
- Falcon Container Image: READ & WRITE

Note: The Infrastructure as Code scope is required even for image-only 
scanning due to the CLI download mechanism using the Downloads API.

Option 3: Alternative Download Source

Provide a way to bypass the Downloads API entirely for image scanning:

• Allow users to specify a pre-installed FCS CLI path
• Download from a public registry that doesn't require IaC permissions
• Use a different API endpoint for CLI downloads that only requires container scopes

Related Context

Version History

• v1.0.6 (Oct 2024): PR fix: use bin from container to fix permission issues #21 implemented container-based binary extraction to avoid permission issues
• v2.0.0 (Aug 2025): Breaking change - Added image scanning support but appears to have reverted to API-based downloads
• v2.0.2 (Sep 2025): Current version with this authorization issue

Migration Impact

We are migrating from container-image-scan-action@v1 (now archived/deprecated) to fcs-action@v2.x. The old action worked successfully with our current API credentials, but the new action requires additional scopes that are not available to container-only accounts.

Questions

1. Is the IaC scope requirement for image scanning intentional or a bug?
2. Can the Downloads API be replaced with a container-only download method for image scanning?
3. For accounts without IaC features, what is the recommended approach for container scanning?
4. Is there a licensing requirement we're missing that would make the IaC scope available?

Workarounds Considered

Temporary alternatives we're evaluating:

1. Request IaC licensing/features to access the required scope (may have cost implications)
2. Use alternative container scanners (Trivy, Grype) until resolved
3. Temporarily disable container scanning in CI/CD (not ideal for security posture)

We prefer to continue using CrowdStrike's native tooling and would appreciate guidance on resolving this authorization issue.

Thank you for your assistance!

Additional Information

If helpful for troubleshooting, the workflow execution details show:

• Rate limiting is not an issue (5886/6000 requests remaining)
• Authentication succeeds (no 401 errors)
• Authorization fails specifically during file enumeration
• All other security scans in our pipeline (Checkmarx, BlackDuck, KICS) work correctly

[carlosmmatos]

@DLTKYugalGarg - this is being fixed by engineering internally. We will update the documentation here when that is completed.