Analysis report rejected at submission when scanner token lacks Execute Analysis

Answer

sonar.forceAuthentication=false does not allow a scanner to submit an analysis report without a token. Execute Analysis is strictly required for report submission regardless of that setting. forceAuthentication only controls anonymous UI browsing.

When a token is present but submission still fails, the authoritative rejection is recorded in ce.log, the Compute Engine log. The scanner console shows a failure, but ce.log contains the definitive authorization decision.

For CI pipelines, a shared service account with Execute Analysis has a larger blast radius because one credential can submit to any project it can access. Project-scoped analysis tokens limit blast radius per project but create more points of rotation and a higher risk of silent pipeline failures when a token expires or is rotated.

Confirmed facts

• sonar.forceAuthentication governs anonymous UI access only. It does not bypass authentication for the Web API used by scanners.
• Scanner report submission requires a valid token that grants Execute Analysis on the target project. No token = rejection. Token without Execute Analysis = rejection.
• Rejection is an authorization check on the server side. Compute Engine logs the decision in ce.log. Scanner output mirrors the failure but ce.log is the authoritative record.

Likely explanation

The local analysis completes because analyzers run offline. Import is blocked at server-side report upload. Common causes are missing sonar.token, expired/rotated token, or a token/user that lacks Execute Analysis on that specific project. Newer scanner lines prefer sonar.token over sonar.login/sonar.password.

Steps needed for this case

1. Verify scanner configuration sends a token: sonar.token is set and non-empty in the CI run.
2. Confirm the token has Execute Analysis on the target project in SonarQube. User tokens need the permission on the project; project analysis tokens are scoped to that project by design.
3. Check ce.log for the submission attempt. Look for Forbidden / authorization entries around the scanner timestamp to confirm the rejection reason.
4. If the token is valid, test with a disposable project to isolate version-specific behavior, as token handling and logging vary across SonarQube major releases.

One missing diagnostic detail that changes the recommendation: SonarQube major version and whether the token in use is a user token or a project analysis token. The permission model and logging details differ between versions and token types.