Architecture and Data Flow

This page exists so a security reviewer can see the whole system at once. The interesting part is not what the diagram contains - it is what it does not.

The whole system in one diagram

The scanner ships as a single container. The Angular UI is built into the application JAR and served by the same Spring Boot process that serves the API, so there is no separate web server to deploy or secure.

What each arrow is

Arrow	Protocol	Why it exists
Browser to reverse proxy	HTTPS	Your proxy terminates TLS. The container itself serves plain HTTP - see Production Deployment.
Reverse proxy to application	HTTP, port 8080	The only port the container exposes.
Browser to identity provider	OIDC authorization code + PKCE	Users authenticate directly against your provider. See Identity Provider.
Application to PostgreSQL	JDBC	The only place the scanner persists anything.
Application to Jira	Jira REST API, read-only	The scan itself. No writes of any kind. See Security and Data Handling.
Application to identity provider	OIDC discovery and JWKS	The backend validates JWTs as an OAuth2 resource server. It fetches the provider's signing keys; it never sends user content.
Application to SMTP	SMTP	Only when reporting is configured. Report e-mails carry counts and links, never matched values.

There are no other outbound connections

That absence is the point of the diagram:

• No phone-home. Licensing is offline. Signature validation happens locally against a public key compiled into the application.
• No cloud AI and no external analysis. Pattern discovery runs locally.
• No telemetry and no usage analytics.
• No connection to arcsoft. No Jira content, no findings, and no metadata reach the vendor at any point.

Every endpoint in the diagram is one you configure. The scanner has no hard-coded external host. If you point it at a cloud identity provider or a hosted SMTP relay, that is your configuration decision, not something the product does on its own - and if you point it at nothing else, it runs in a network with no route to the internet at all.

Where each kind of data lives

Data	Where it lives	How it is protected	How long it is kept
Raw matched value (the secret itself)	Nowhere	Never written to the database, a log, an export, or the UI	Never stored
Matched text and its surrounding context	Nowhere	No excerpt of any kind is stored; a finding holds only a keyed fingerprint and a source locator	Never stored
Finding fingerprint	PostgreSQL	HMAC-SHA256 keyed with FINDING_FINGERPRINT_HMAC_SECRET, so a stolen database offers no dictionary attack	Retention window, ten years by default
Source locator (project, issue key, field, offsets)	PostgreSQL	Ordinary application data; points into Jira rather than copying from it	Retention window, ten years by default
Extracted attachment text	Process memory only	Held only while that one attachment is scanned, then discarded	Never persisted
Image bytes during OCR	Private temporary directory	Owner-only permissions; read by a separate, resource-limited OCR process without secrets; deleted after each image	Never stored
Manual reviews	PostgreSQL	Attachment file name, issue key, reason and reviewer decision; never image bytes or OCR text	Retention window, ten years by default
Jira service account credential	PostgreSQL	AES-256-GCM with JIRA_CREDENTIAL_ENCRYPTION_KEY; never returned by the API or shown in the UI after saving	Until you replace it - not subject to retention
SMTP password	PostgreSQL	Same encryption, same key	Until you replace it - not subject to retention
OIDC credentials	Nowhere	The backend only validates JWTs; it stores no user credential	Never stored
Audit events	PostgreSQL	Sanitized metadata, never raw values; not editable through the UI	Not purged by default

Details behind each row are in Security and Data Handling, Attachment Scanning, and Data Retention.

What the deployment does not do for you

The scanner is self-hosted, which means several controls a reviewer will ask about are yours to operate, not the product's:

• TLS termination happens at your reverse proxy. The container serves plain HTTP on port 8080 and terminates no TLS itself.
• Encryption at rest for the database is a property of your PostgreSQL deployment. The scanner encrypts the stored Jira and SMTP credentials at the application layer regardless, but the rest of the schema is protected only by whatever your database and storage provide.
• Backups and restore are yours. The scanner has no backup function and no restore path of its own.
• Patching means pulling a new container image; the scanner does not update itself and has no auto-update channel.
• Secret management for JIRA_CREDENTIAL_ENCRYPTION_KEY and FINDING_FINGERPRINT_HMAC_SECRET is yours. Both are permanent for the life of the installation - see Production Deployment.

These are stated plainly because a self-hosted product that leaves them unmentioned invites a reviewer to assume the vendor handles them.