getZipUrl() crashes with "Cannot read properties of undefined (reading 'find')" when GitHub API returns error response

[mangler]

Describe the bug
When the task attempts to download “latest” Dependency-Check CLI, it calls the GitHub releases API and assumes the JSON has an assets array. If GitHub returns an error payload (e.g., rate limited or transient error), assets is undefined and the task crashes with:
TypeError: Cannot read properties of undefined (reading 'find')

The failure occurs before the CLI runs and is unrelated to Java/CLI execution.

To Reproduce

1. Run a pipeline on a Microsoft-hosted agent (windows-latest) using dependency-check-build-task@6 with default settings (dependencyCheckVersion not set, i.e., “latest”).
2. The task reaches “Downloading Dependency Check latest installer from GitHub..”.
3. If the GitHub API responds with an error payload (commonly due to anonymous rate limiting), the task throws.
4. See error.

Minimal YAML to reproduce:

- task: dependency-check-build-task@6
  displayName: 'OWASP Dependency Check (SCA)'
  inputs:
    projectName: '$(Build.Repository.Name)'
    scanPath: '$(Build.SourcesDirectory)'
    format: 'HTML,JSON,JUNIT,SARIF'
    # dependencyCheckVersion not set -> defaults to 'latest'

Expected behavior
• The task should handle non-200 or unexpected GitHub responses gracefully:
◦ Detect missing assets and surface a clear, actionable error like:
“Failed to retrieve latest Dependency-Check release from GitHub (HTTP ): ”
• Optionally retry with backoff and/or suggest pinning a specific version.
• Support using a GitHub token to avoid anonymous rate limits.

Screenshots
N/A

Logs

Excerpt from a failing run:
Starting Dependency Check...
Setting report directory to D:\a\1\TestResults\dependency-check
Creating report directory at D:\a\1\TestResults\dependency-check
Downloading Dependency Check latest installer from GitHub..
Cannot read properties of undefined (reading 'find')
##[error]Cannot read properties of undefined (reading 'find')
##[error]Unhandled error condition detected.
Ending Dependency Check...

Additional context
• Task version: 6.3.0
• Agent: Microsoft-hosted windows-latest
• Repro depends on GitHub API behavior; it’s most visible during/after hitting anonymous rate limits.

Code location and root cause
• File: Tasks/DependencyCheck/dependency-check-build-task.ts
• Function: getZipUrl() (lines ~297–308)
• Problem: releaseInfo['assets'] is used without checking it exists.

Relevant snippet:

async function getZipUrl(version: string): Promise<string> {
    let url = `${releaseApi}/tags/v${version}`;
    if (version == 'latest') url = `${releaseApi}/${version}`;

    const response = await client.get(url);
    const releaseInfo = JSON.parse(await response.readBody());
    const asset = releaseInfo['assets'].find((asset: { [x: string]: string; }) =>
        asset['content_type'] == 'application/zip');

    return asset['browser_download_url'] as string;
}

Why this fails
• When version == 'latest', the code calls:
https://api.github.com/repos/dependency-check/DependencyCheck/releases/latest
• On rate limit or other errors, GitHub returns an error JSON (e.g., with message/documentation_url) that does not include assets.
• Calling .find() on undefined throws the TypeError above.

Suggested fix
• Add response status and shape checks before parsing/using assets:
◦ Check response.message.statusCode is 200.
◦ Safely parse JSON and verify it has a non-empty assets array.
◦ If missing, throw a descriptive error and avoid TypeError.
• Consider adding:
◦ Automatic retry with backoff on 429/5xx.
◦ Input support for a GitHub token to increase rate limits.
◦ A fallback that queries /releases and selects the first non-prerelease asset if /releases/latest fails.

Workarounds we verified
• Pin a specific CLI version via dependencyCheckVersion (e.g., '10.0.4' or a current v12.x if Java ≥ 11 is available). This uses the tag endpoint (/releases/tags/vX.Y.Z) but can still fail the same way on API errors—guarding assets is still needed.
• Bypass the wrapper by downloading the CLI directly from the release asset URL and running it, which avoids the JSON parsing path that triggers the crash.