v4.1.0

Fixes report generation failing with a GraphQL timeout on repositories with a large dependency manifest.

The problem

The dependency graph query expanded dependencyGraphManifests.dependencies, which makes GitHub resolve every manifest's full dependency graph. On a repository with a large lockfile that exceeds GitHub's server-side GraphQL budget and fails the whole query:

##[error]Request failed due to following response errors:
 - timedout

No PDF was produced. In most workflows this went unnoticed because the report step runs with continue-on-error: true, so the job stayed green and the step reported success — the failure appeared only in the raw logs, followed by mv: cannot stat 'report.pdf'.

If you are seeing an empty report artifact, or a "No files were found with the provided path: ./*.pdf" warning after your CodeQL job, this is very likely the cause.

What changed

• Manifests are read with a metadata-only GraphQL query; the expensive nested connection is gone. It was never rendered by the report template.
• Dependencies now come from the repository's dependency-graph SBOM, via the asynchronous SBOM API (generate-report, then polling fetch-report). Polling is bounded and raises a clear error rather than hanging the job.
• The synchronous /dependency-graph/sbom endpoint is deprecated and scheduled for removal on 2026-11-13; it is retained only as a fallback for GitHub Enterprise Server instances without the async endpoint.
• The dependency count in the report is now accurate. It previously relied on dependenciesCount, which GitHub only populates as a side effect of the same expensive resolver, so it frequently read 0.

Behavior changes

These affect the JSON data shaping, not the rendered report or summary templates:

• Dependency versions are SBOM-resolved (1.3.0) rather than manifest ranges (^1.0.0).
• Dependency grouping keys come from the purl type (npm, githubactions, maven) rather than GraphQL's NPM / ACTIONS.
• Dependencies are no longer attributed to the manifest that introduced them; the SBOM does not carry that mapping. Manifest lists (processed / unprocessed) are unaffected.

If you use the legacy summary_old.html template, note it hardcodes dependencies.npm and dependencies.maven.

Upgrading

- name: Generate Security Report
  uses: rsdmike/github-security-report-action@v4.1.0
  with:
    template: report
    token: ${{ secrets.SECURITY_TOKEN }}

No input or output changes. Once upgraded, consider removing continue-on-error: true from the report step so future failures are visible.

Full Changelog: v4.0.1...v4.1.0