Security Questionnaire

These are the questions a security review normally sends as a spreadsheet, answered once in public. Every answer links to the page or the behaviour that makes it true. Where something is not implemented, this page says not implemented rather than leaving a blank.

Hosting and data residency

Where is the software hosted? In your infrastructure. Sensitive Data Scanner ships as a single container that you run on your own hardware or cloud, against your own database and your own Jira instance. There is no SaaS option and no vendor-hosted tenant. See Architecture and Data Flow.

Where does customer data reside? Wherever you choose to run the container and its PostgreSQL database. The vendor has no involvement in that choice and no visibility into it.

Does the vendor hold any customer data? No. No Jira content, no findings, and no metadata are transmitted to arcsoft at any point. This is a property of the software rather than a policy commitment - there is no outbound connection to the vendor to carry it. See Security and Data Handling.

Can the product run air-gapped? Yes. Licensing is offline and validated locally against a public key compiled into the application; there is no phone-home, no telemetry, and no external analysis service. The scanner is designed to run in a network with no route to the internet.

Can the vendor access our installation for support? Not implemented. There is no remote-support channel, no built-in screen sharing, and no vendor backdoor. Any diagnostic information reaches us only because you choose to send it.

Data protection

What does the product store about a detected secret? A keyed fingerprint and a source locator - project, issue key, the field, comment or attachment, the text variant, and the character offsets. Nothing else. There is no excerpt, masked or otherwise: nothing derived from the matched text or the text around it is stored. The raw matched value is never written to the database, never logged, never exported, and never displayed in the UI. To see the actual value you follow the link into Jira, where it already lives. See Security and Data Handling.

Is the fingerprint reversible? It is an HMAC-SHA256 keyed with FINDING_FINGERPRINT_HMAC_SECRET, not a plain hash, so a stolen database does not permit a dictionary attack against short matched values.

What happens to attachment content? It is downloaded, parsed in memory, scanned, and discarded. Extracted and OCR text is never written to the database or to logs, and is never fed into pattern discovery. Image attachments are written to a private temporary directory (owner-only permissions) for the duration of OCR and deleted afterwards. Manual reviews store the attachment file name, issue key and reason, never image bytes, thumbnails or OCR text. OCR runs in a separate process with memory, CPU and time limits and none of the scanner's secrets in its environment; its network access is not restricted, and Tesseract contains no network code. See Attachment Scanning.

How are credentials protected at rest? The stored Jira service account credential and the SMTP password are encrypted with AES-256-GCM using JIRA_CREDENTIAL_ENCRYPTION_KEY, which never leaves your environment. Neither is ever returned by the API, shown in the UI after saving, or included in an error message. No OIDC user credential is stored at all.

Is the database encrypted at rest? That is your responsibility, not the product's. The scanner encrypts the stored Jira and SMTP credentials at the application layer regardless of your database configuration, but the rest of the schema - findings, fingerprints, audit events - is protected only by whatever encryption your PostgreSQL deployment and its storage provide.

Is data encrypted in transit? Partly the product's responsibility and partly yours:

Connection	Who secures it
Browser to scanner	Yours. The container serves plain HTTP on port 8080 and terminates no TLS. You put it behind your own reverse proxy and terminate TLS there - see Production Deployment.
Scanner to Jira	Determined by the base URL you configure for the Jira connection. Configure an HTTPS URL.
Scanner to PostgreSQL	Determined by your JDBC URL and your PostgreSQL server configuration.
Scanner to SMTP	Determined by your SMTP host and port configuration.

The product does not force TLS on these connections and does not refuse to start without it.

Access control and authentication

How do users authenticate? Against your own OIDC identity provider. The backend validates JWTs as an OAuth2 resource server. There are no local accounts and no vendor-managed identities. See Identity Provider.

Does the product support MFA, SSO, password policies, or account lockout? These are delegated to your identity provider in full. The product stores no user credential and implements no authentication of its own, so whatever your provider enforces is what applies. The product itself implements none of them.

What authorization model is used? Two roles resolved from a claim in the OIDC access token. ADMIN has full access to every page and every action. USER is read-only and limited to the risk dashboard, the findings list and finding detail, and the suppression history: a USER cannot review a finding, cannot create or remove a suppression, and cannot control a scan. Every other page - scans, rules, the audit log, and every administration page - is ADMIN-only. The navigation hides what a USER cannot reach, and an unauthorized request is rejected with HTTP 403 carrying the same sanitized error body as the rest of the API. Findings outside the browsable scope are restricted - details hidden, not selectable for bulk action. That scope is what the configured Jira service account may browse, so it is the same for every signed-in user; the product does not restrict findings per user.

Is there more granular or per-project authorization? Not implemented beyond the restriction behaviour described above. There is no custom role editor and no per-field permission model.

What access does the product need in Jira? Browse Projects on the projects in scope, and nothing more. No Jira administrator rights. The scanner installs no Jira plugin, never touches the Jira database, and issues no writes of any kind - no edits, comments, deletions, redactions, or field updates.

Logging and audit

Is there an audit trail? Yes. Every consequential action is recorded with actor, timestamp, action, target, and sanitized metadata: configuration and connection changes, license uploads, scan starts, review decisions, suppressions, rule changes and rollbacks, ruleset imports and exports, CSV exports, report runs, and retention purges. See Audit Log.

Can the audit trail be edited or deleted? Audit events cannot be edited through the UI. They are excluded from the retention purge by default, so they outlive the findings they describe. An operator with direct database access can of course modify them; the product does not provide tamper-evidence such as signing or an append-only store. That is not implemented.

Do logs contain sensitive values? No. Audit metadata never contains raw matched values, and the raw value is never written to any log. Jira and SMTP errors surfaced to users are sanitized specifically because raw response text can echo back hostnames and credentials.

Can logs be shipped to a SIEM? Application logs go to stdout, so your container platform's log pipeline can collect them. There is no built-in syslog, CEF, or SIEM integration, and no webhook for audit events. Audit events can be read through the UI and exported via CSV export.

Vulnerability management and disclosure

How do we report a vulnerability? Privately to info@arcsoft.ch, rather than as a public issue. We acknowledge reports and keep you updated while we work on a fix.

Is there a published remediation SLA? Not implemented. There is no contractual time-to-fix commitment.

Is a bill of materials available? Yes. A CycloneDX SBOM is generated from the build for each release - one for the backend's resolved Maven graph, in both JSON and XML, and one for the frontend's resolved dependency tree, in JSON. Both are deliberately generated rather than hand-maintained, and deliberately not committed to the repository, because a hand-written or committed SBOM goes stale silently and a stale SBOM is worse than none. Both are attached to the GitHub release for each tagged version, so you can download them yourself rather than asking us for them. The source repository is private, so if you do not have access to it, request the SBOM for a specific release at info@arcsoft.ch.

Is there automated dependency scanning? Yes. A Dependency Check workflow scans all three dependency trees - the backend's resolved Maven graph via its generated CycloneDX SBOM, the Angular frontend, and the documentation site - on every pull request, on every push to main, and once a week on a schedule.

The weekly run is the part that matters: a vulnerability is normally disclosed long after the dependency was added, so a check that runs only on code changes would never see it. Advisories with no fix yet available are reported rather than treated as failures, because failing on something that cannot be fixed only trains people to ignore the job. Both SBOMs are published as build artifacts, so you can also run your own scanner against a release rather than relying on ours.

Has the product been penetration tested? No. No third-party penetration test or security audit has been performed.

How are patches delivered? As a new container image. The product does not update itself and has no auto-update channel; applying a release is your operational step.

Secure development

What runs on every change? Changes reach main through a pull request, and these workflows run on the pull request and again on the merge:

Workflow	What it covers
Build and Test	Backend unit and integration tests, the ArchUnit rules that enforce the hexagonal boundaries, frontend unit tests, linting, and dependency-boundary checks
Dependency Check	Known vulnerabilities in the backend, frontend and website dependency trees, and SBOM generation
Code Scanning	CodeQL static analysis of the Java and TypeScript sources, and a gitleaks scan of the whole commit history

Dependency Check and Code Scanning also run weekly on a schedule, because most of what they find is disclosed long after the code stopped changing. The Playwright end-to-end suite runs on demand rather than on every change; it needs a published image to test against. Build Docker Image runs only after a successful Build and Test, so an image is never published from a build whose tests failed.

Is the source statically analysed? Yes. CodeQL runs over both languages - Java for the backend, TypeScript for the frontend - with GitHub's security-and-quality query suite, on every pull request, on every push to main, and weekly.

Do you scan your own repository for secrets? Yes. gitleaks runs over the entire commit history rather than the current files, so a credential that was committed and later deleted is still found. The check gates: a hit fails the build.

The repository's test fixtures, generated test corpora and planning documents contain synthetic secrets on purpose - they are what the detection rules are tested against - so those directories are allowlisted by path in .gitleaks.toml. A credential anywhere else fails the build.

Are the published images signed? Yes. Every image pushed to the registry is signed with cosign in keyless mode: the signing certificate is issued to the build workflow's own identity and expires within minutes, so there is no long-lived signing key held by anyone - including us. Signatures cover the image digest, not the tag, because tags move.

cosign verify arcsoftklg/sensitive-data-scanner:latest \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/lombold/project-risk-scanner/.github/workflows/publish-release.yml@'

Is there build provenance? Yes. Each image carries a SLSA provenance attestation generated by the builder, recording the source repository and commit, the workflow that built it, and the base image digests it was built from, plus an SBOM of the image as a second attestation.

docker buildx imagetools inspect arcsoftklg/sensitive-data-scanner:latest \
  --format '{{ json .Provenance }}'

Both are attached to the image in the registry, so they travel with it: pulling by digest and verifying the signature tells you the image came from this repository's build and has not been altered since.

Subprocessors and third parties

Who are the subprocessors for customer data? There are none, because no customer data reaches the vendor. The product makes no outbound connection to arcsoft, and there is no vendor-side storage or processing to subcontract.

What third parties are involved at all? Only for the vendor's own business, never for scanner data:

• Licensing. To issue a license file, arcsoft processes the business contact details you supply. See the Privacy Policy.
• This website. Hosted on GitHub Pages. It sets no tracking or advertising cookies, uses no analytics, and loads no external fonts or CDNs. The documentation site is not part of the product and your installation does not contact it.

Does the product use any cloud AI or external analysis service? No. Detection and pattern discovery run locally inside your container.

Business continuity and vendor risk

What happens if arcsoft ceases to operate? You keep a working container and a perpetual license for the version you hold; nothing deactivates and no license server needs to be reachable. You would receive no further fixes, releases, or support. There is no source escrow arrangement.

What is the support commitment? Business hours, Swiss time, best effort, by e-mail. There is no 24/7 support and no published SLA or contractual response time.

What is the disaster recovery plan for our data? Yours to define. The scanner has no backup function and no restore path of its own; your database backups are the recovery mechanism. Note that JIRA_CREDENTIAL_ENCRYPTION_KEY and FINDING_FINGERPRINT_HMAC_SECRET must be backed up alongside the database - without the first, the stored Jira credential cannot be decrypted; without the second, every finding changes identity and loses its review history.

Is the product highly available? It can run as multiple instances against one PostgreSQL database without double-firing scheduled scans or reports, because scheduling and work distribution claim work through the database. Availability beyond that - load balancing, failover, database HA - is your infrastructure's concern.

Compliance

Are you GDPR or revFADP compliant? Compliance is a property of your deployment rather than of software the vendor cannot see. What can be stated factually is that arcsoft receives no personal data your scanner processes, so for that data you remain the sole controller and arcsoft is not a processor. arcsoft KLG is established in Zürich, Switzerland. The published Privacy Policy carries a notice that it has not yet been reviewed by a lawyer; read it with that caveat.

Can the product help us demonstrate compliance? It can contribute evidence, and only that. It records what its configured rules matched, how a reviewer classified each finding, and when - in an audit trail that stays in your database.

It does not establish compliance and it cannot tell you an instance is clean. A scan finds what its rules match in the content it was able to read, so an empty result means nothing matched - not that nothing is there. Detection is rule-based, rules can miss, and some attachments are not readable at all - see Attachment scanning for what is skipped and why. Whether the resulting evidence satisfies a particular obligation is a judgement for you and your auditor.

Data retention and deletion

How long is data kept? Findings, occurrences, review events, scan runs, scan work items, and superseded rule versions are hard-deleted once older than the configured retention window, which is set with retention.window as an ISO-8601 period and defaults to ten years (P10Y). A zero or negative window is refused at startup. See Data Retention.

Are audit events purged? Not by default. retention.purge-audit-events defaults to false, so the audit log outlives the findings it describes. Set it to true if your own policy requires audit entries to expire; they then use the same window, as there is no separate one for them.

Is deletion a hard delete? Yes, not a soft flag. Rules, scan configurations, suppressions, the Jira connection, the license, and reporting settings are not subject to retention and persist until you remove them.

Can we delete our data on demand? Yes. Administrators can trigger a purge immediately through an admin-only API endpoint rather than waiting for the daily 03:00 run. Beyond that, the database is yours and you can drop it.

How do we get our data out? Through CSV export, which is itself audited, or directly from your own database.

Incident response

Is there a documented incident response plan with defined timelines? Not implemented. There is no published IR plan and no contractual notification window.

Who would notify whom in a breach? For data your scanner processes, the question does not arise for the vendor: arcsoft holds none of it and would have nothing to disclose. Detection and notification for your installation are yours, as they would be for any software you run yourself. For a vulnerability discovered in the product, arcsoft notifies affected customers via the contact address on file and publishes the fix as a new release.

Legal agreements

Is a DPA or AVV available? Not published. A data processing agreement is a legal document that needs review by a qualified lawyer, and shipping an unreviewed template would be worse than shipping none - particularly here, where the more interesting question is whether one is required at all, given that arcsoft receives none of the personal data your scanner processes. Raise it with info@arcsoft.ch and it will be handled as a contract matter.

What licence governs the software? Your licence agreement with arcsoft KLG, supplied with your licence file. The Terms of Service on this site govern the website only and carry their own notice that they have not been reviewed by a lawyer.

Something missing?

If your review asks something this page does not answer, write to info@arcsoft.ch. An answer that has to be invented on the spot is exactly the kind that turns out to be wrong later, so expect either a documented answer or a plain "not implemented".