Reporting

Administration -> Reporting sends a periodic e-mail summary of open findings to the people who can actually act on them: the Jira project lead of each project in scope.

The whole point is that nobody has to log into the scanner to learn that their project has open findings. Reports contain project keys and severity counts only - never a matched value, and no excerpt of the text around it.

Mail server

Field	Notes
SMTP host	Hostname of your mail server.
SMTP port	Typically 587 with STARTTLS, or 25 on an internal relay.
SMTP username	Optional. Leave empty for an unauthenticated internal relay.
SMTP password	Optional. Stored encrypted at rest with the same key as the Jira credential, and never shown again after saving.
STARTTLS	Enable unless your relay explicitly does not support it.
From address	The sender address recipients will see and reply to.

Cadence

The schedule is a cron expression. A dropdown offers sensible defaults - Daily at 9 and Weekly at Monday 9 - and writes the matching expression into the field; editing the field yourself switches the dropdown to Custom.

Expressions use six fields: second minute hour day-of-month month day-of-week. They are evaluated in the server's time zone, and the page previews the next fire times so you can confirm you got what you meant.

• 0 0 9 * * * - every day at 09:00
• 0 0 9 * * MON - Mondays at 09:00
• 0 0 9 1 * * - the first of every month at 09:00

A warning appears if the expression fires more than once a day. It is allowed, but a report that arrives several times a day gets filtered into a folder and stops being read.

Sending is only active while Send reports on this schedule is switched on.

Reporting scope

There is nothing to choose here. Reporting is bound to a scan configuration, and the page shows that configuration and its project scope read-only: either all accessible projects, or the list of project keys the configuration carries. That scope decides which projects are considered when resolving recipients, so you change it by editing the scan configuration, not on this page.

Mails per minute (default 1,000) throttles delivery so a large run does not overwhelm your mail relay.

Who receives a report

Recipients are resolved from Jira: for each in-scope project, the scanner reads the project lead and their e-mail address through the Jira API.

Jira service-account access

There is no special project role for reporting. The Jira service account needs Browse Projects on every in-scope project and should have the Browse users and groups global permission so it can look up project leads.

Jira must also expose those users' e-mail addresses. Set Administration -> System -> General configuration -> User email visibility to Logged in users only (recommended) or Public. Hidden and Masked do not provide a usable recipient address. See Jira Connection configuration for the complete setup.

• One e-mail per person, not per project. Someone who leads six projects receives a single message covering all six.
• Recipients with no open findings are skipped. A "nothing to do" mail trains people to ignore the report, so it is not sent. The skipped count is shown on the latest run.
• Suppressed findings are excluded, exactly as they are in the findings list.
• Projects whose lead has no e-mail address, or whose address Jira does not disclose to the service account, cannot be reported on. They are counted as projects without owner e-mail so the gap is visible rather than silent.

What the e-mail contains

A subject line with the total open findings and project count, then per project: the project key, the open count, a breakdown by severity, and a link into the scanner's findings list pre-filtered to that project.

Those links are built from APP_BASE_URL. If it is unset, recipients receive localhost links they cannot open - see Production Deployment.

Latest run

The page shows the most recent run: status, trigger (scheduled or manual), start and finish time, e-mails sent, recipients skipped, projects without an owner e-mail, and a failure count with a sanitized summary.

A delivery failure for one recipient never aborts the run - the remaining recipients are still served, and the run is reported as failed so the problem is visible. Every run is written to the audit log as REPORT_RUN_COMPLETED.

Run report now triggers a run immediately, using the saved configuration. Useful for verifying a change without waiting for the schedule.

Send a test e-mail

Enter any recipient address and send. This exercises the SMTP settings alone - no findings, no Jira lookup - so it isolates mail-server problems from reporting logic. Failures return a sanitized error; SMTP responses can echo credentials, so the raw text is never surfaced.

Configure the mail server, save, then send a test e-mail before switching the schedule on.