Security and Data Handling

A tool that hunts for secrets must not become the place secrets leak from. This page states exactly what Sensitive Data Scanner does and does not keep.

For a security review

If you are assessing this product rather than operating it, start here:

• Architecture and Data Flow - every component, every outbound connection, and where each kind of data lives.
• Security Questionnaire - pre-filled answers to the usual review questions, including the ones where the answer is no.
• Software Bill of Materials - a CycloneDX SBOM is generated from the build for each release: the backend's resolved Maven graph in JSON and XML, and the frontend's resolved dependency tree in JSON. Both are attached to the GitHub release for each tagged version, and are never committed to the repository, because a stored SBOM goes stale silently. If you cannot reach the release, request the SBOM for a specific version at info@arcsoft.ch.
• Signed images and build provenance - every published image is signed with cosign in keyless mode and carries a SLSA provenance attestation and an SBOM attestation. The security questionnaire has the verification commands.
• What runs on every commit - tests and architecture rules, dependency scanning, CodeQL, and a gitleaks scan of the full commit history. Also in the security questionnaire.

The core guarantee: raw values are never persisted

When a rule matches, the scanner stores exactly two things:

• A keyed fingerprint - an HMAC-SHA256 of the match, used to recognise the same finding across scans so review decisions and suppressions carry forward.
• A source locator - project, issue key, the field, comment or attachment, the text variant, and the character offsets.

That is the whole record. There is no excerpt of any kind - not a masked one, not a truncated one, not the surrounding context. Nothing derived from the matched text is stored, exported, logged, or displayed anywhere: not on the finding detail page, not on the dashboard, not in a CSV export, not in an e-mail report. A finding tells you where to look and which rule fired, and nothing else. To see the actual value you follow the link to the Jira issue and read it in Jira, where it already lives.

The fingerprint is keyed, not a plain hash. Without FINDING_FINGERPRINT_HMAC_SECRET a stolen database offers no dictionary attack against short matched values.

Read-only against Jira

The scanner reaches Jira exclusively through the Jira REST API using a service account. It installs no Jira plugin and never touches the Jira database. It issues no writes at all: no edits, no comments, no deletions, no redaction, no field updates. The service account needs only Browse Projects on the projects in scope - no Jira administrator rights.

Attachment content is downloaded, parsed in memory, scanned, and discarded; extracted and OCR text are never stored. Image attachments are the one exception to "in memory only": for the duration of OCR, the image bytes are written to a private temporary directory (owner-only permissions) and deleted afterwards. Manual reviews store the attachment file name, issue key and reason - never image bytes or OCR text. OCR runs in a separate, resource-limited process that receives none of the scanner's secrets; that process's network access is not restricted. See Attachment scanning.

Credentials at rest

Credential	Protection
Jira service account credential	AES-256-GCM encrypted with JIRA_CREDENTIAL_ENCRYPTION_KEY, which never leaves your environment.
SMTP password for reporting	Same encryption, same key.
OIDC	No credential is stored. Users authenticate against your identity provider; the backend only validates JWTs as an OAuth2 resource server.

Neither credential is ever returned by the API, shown in the UI after saving, or included in an error message. The Jira connection test and the reporting test e-mail both return sanitized errors for exactly this reason: raw SMTP and Jira response text can echo back hostnames and credentials.

No outbound calls

• No phone-home. Licensing is offline: signature validation happens locally against a public key compiled into the application. See License.
• No cloud AI, no external analysis. Pattern discovery runs locally.
• No telemetry, no usage analytics.

The only outbound connections the scanner makes are to your Jira instance, your identity provider, your database, and - if you configure reporting - your SMTP server. The scanner is designed to run in a network that cannot reach the internet at all.

Access control

Two roles, resolved from a claim in the OIDC access token:

• ADMIN - full access to every page and every action.
• USER - read-only access to the Risk Dashboard, the Findings list and finding detail, and the Suppressions history. A USER cannot review or classify a finding, cannot create or remove a suppression, and cannot start, pause, resume, or cancel a scan.

Every other page is ADMIN-only: Scans, Rule Catalog, Create Custom Rule, Audit Log, Jira Connection, License, Scan Configuration, Ruleset Transfer, Reporting, and the hidden pattern discovery pages. The navigation hides what a USER cannot reach, and a request that is not authorized is rejected with HTTP 403 and the same sanitized error body the rest of the API returns.

Findings outside the browsable scope are restricted: their details are hidden and they cannot be selected for bulk action. The check asks Jira what the configured service account may browse, not what the signed-in user may browse - so every signed-in user sees the same findings, and restriction narrows them to the scope, not per user. Per-user restriction needs Jira user impersonation, which the product does not implement. See Identity Provider.

Audit trail

Every consequential action is recorded with actor, timestamp, action, target, and sanitized metadata: configuration changes, connection changes, license uploads, scan starts, review decisions, suppressions, rule changes and rollbacks, ruleset imports and exports, CSV exports, report runs, and retention purges. Audit metadata never contains raw sensitive values, and audit events cannot be edited through the UI. See Audit Log.

Data lifetime

Findings, occurrences, review events, scan runs, and superseded rule versions are hard-deleted once they are older than the configured retention window, which defaults to ten years. Audit events are not purged unless an operator opts in. See Data Retention.

Self-hosted by design

The scanner runs entirely inside your infrastructure: your container, your database, your network. No Jira content, no findings, and no metadata are sent to arcsoft or to any third party at any point.

Reporting a vulnerability

If you believe you have found a security vulnerability in Sensitive Data Scanner, please report it privately to info@arcsoft.ch rather than opening a public issue. Include the affected version, what you observed, and the steps to reproduce it. We will acknowledge your report and keep you updated while we work on a fix.

Please do not test against systems you do not own or operate.